- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
ESP32 / Re: ESP32-POE-ISO-EA-16MB full...
Last post by LubOlimex - Today at 01:54:26 PMIt is a good idea to also look at a ready 3D designs, there are many box designs online for ESP32-POE-ISO that can be used as basis. Our boxes also have 3D design files available for download:
https://www.olimex.com/Products/IoT/ESP32/BOX-ESP32-POE-ISO/
Now for the ESP32-POE-ISO I have exported STEP here:
https://ftp.olimex.com/TEMP/ESP32-PoE-ISO-step-export/ESP32-PoE-ISO_Rev_L.step
Notice that I haven't double checked if the dimensions in the export are 100% consistent with each component. We don't need component height during manufacturing so some components can be a bit off. My advice is to also always compare the STEP file with the real board (empirically measure heights).
In future you can export from KiCAD on your won, it is the free software we use to design these boards. Install KiCAD and download the sources from the GitHub page for ESP32-POE-ISO, open the project file in KiCAD, open the PCB layout editor, and click File -> Export and chose one of the formats. Furthermore, there is a built-in 3D viewer in KiCAD, again open the PCB and navigate to View -> 3D Viewer.
https://www.olimex.com/Products/IoT/ESP32/BOX-ESP32-POE-ISO/
Now for the ESP32-POE-ISO I have exported STEP here:
https://ftp.olimex.com/TEMP/ESP32-PoE-ISO-step-export/ESP32-PoE-ISO_Rev_L.step
Notice that I haven't double checked if the dimensions in the export are 100% consistent with each component. We don't need component height during manufacturing so some components can be a bit off. My advice is to also always compare the STEP file with the real board (empirically measure heights).
In future you can export from KiCAD on your won, it is the free software we use to design these boards. Install KiCAD and download the sources from the GitHub page for ESP32-POE-ISO, open the project file in KiCAD, open the PCB layout editor, and click File -> Export and chose one of the formats. Furthermore, there is a built-in 3D viewer in KiCAD, again open the PCB and navigate to View -> 3D Viewer.
#2
ESP32 / ESP32-POE-ISO-EA-16MB full ass...
Last post by Ol!mexGoody - April 22, 2026, 06:13:46 PMI have the ESP32-POE-ISO-EA-16MB and would like a full assembly .step file so I can design a rack mount for it in Fusion.
I found this https://github.com/OLIMEX/ESP32-POE/tree/master/HARDWARE and tried to make sense of KiCad to extract the full assembly, but I keep running into export errors.
Is the full assembly of the ESP32-POE-ISO-EA-16MB available anywhere in .step and/or .stl without requiring knowledge of how to navigate KiCad?
I found this https://github.com/OLIMEX/ESP32-POE/tree/master/HARDWARE and tried to make sense of KiCad to extract the full assembly, but I keep running into export errors.
Is the full assembly of the ESP32-POE-ISO-EA-16MB available anywhere in .step and/or .stl without requiring knowledge of how to navigate KiCad?
#3
A64 / Re: Debian GNU/Linux 13 (Trixi...
Last post by LubOlimex - April 22, 2026, 08:24:17 AMI can't remember what required it, but maybe it is this hardware change in revision E:
"Serial resistors were added to the Ethernet PHY's Tx lines for better EMI suppression and RLC filters to the clock lines."
But there was a lot of routing changes also with placement of components to reduce EMI from the Ethernet, so it could be just the routing changed and required different delays.
"Serial resistors were added to the Ethernet PHY's Tx lines for better EMI suppression and RLC filters to the clock lines."
But there was a lot of routing changes also with placement of components to reduce EMI from the Ethernet, so it could be just the routing changed and required different delays.
#4
A64 / Re: Debian GNU/Linux 13 (Trixi...
Last post by Roman - April 21, 2026, 07:04:25 PMThank you for your write up! I will be sharing it with another person who is interested in instructions for installing Debian on A64-OLinuXino.
The device tree file for A64-OLinuXino in Debian comes from upstream U-Boot and mainline Linux. Both have been reported to work with A64-OLinuXino without issues. However, when I got mine earlier this year, which is revision H as yours, I had the same issues as you. They are caused by the RX delay value not set, so that the Ethernet signal is not timed properly.
The upstream device tree file does not set an RX delay value. The same device tree files "sun50i-a64-olinuxino.dts" and "sun50i-a64-olinuxino-emmc.dts" in OLIMEX/linux-olimex repository on GiHub do not set it too. But the repository also contains additional device tree files for specific variants of the board. Those include "sun50i-a64-olinuxino-1G.dts", which sets the RX delay to 200 picoseconds for all variants. Those files were added on 18 May 2023.
Setting the RX delay is enough to fix the issue with the Internet connection dropping lots of packets and running slow.
This makes me wonder, if it was unnecessary to set it in the mainline Linux device tree file, when did it become necessary? Which revisions of the board require it besides revision H?
Per the bill of materials (BoM) and schematics of A64-OLinuXino in OLIMEX/OLINUXINO repository on GitHub, revisions of the board starting with revision B have KSZ9031RNXCC (consumer) or KSZ9031RNXIC-TR (industrial). It shows up in dmesg as "Micrel KSZ9031 Gigabit PHY". However, revision A of the board had RTL8211CL-GR instead. Is it the cause of the difference?
It is necessary to understand this to be able to choose the device tree correctly.
Edit: I have just noticed that the page for "Olimex A64-OLinuXino" at linux-sunxi wiki indicates that revision D in 2017 was fully supported by the upstream Das U-Boot and the mainline Linux kernel. However, revision D and revision H seem to have the same Gigabit PHY chip. So, the chip change is not the cause of the different device tree file being required. But what is the cause then?
Quote from: Gast-2026-04-08 on April 08, 2026, 05:01:39 PMThe second problem is the Ethernet-connection. After the first few megabytes, the throughput drops to less than 100 KB/s. And stays that way. It does not stop, it just gets really slow. I encountered the same phenomenon when I first tried to install via netboot/netinst. During installation, the first operations went through (getting the package-lists and getting the first packages), but then it turned incredibly slow. The system did not hang, it responded normally. But the Ethernet-connection appeared to be slow (but no timeout).
The device tree file for A64-OLinuXino in Debian comes from upstream U-Boot and mainline Linux. Both have been reported to work with A64-OLinuXino without issues. However, when I got mine earlier this year, which is revision H as yours, I had the same issues as you. They are caused by the RX delay value not set, so that the Ethernet signal is not timed properly.
The upstream device tree file does not set an RX delay value. The same device tree files "sun50i-a64-olinuxino.dts" and "sun50i-a64-olinuxino-emmc.dts" in OLIMEX/linux-olimex repository on GiHub do not set it too. But the repository also contains additional device tree files for specific variants of the board. Those include "sun50i-a64-olinuxino-1G.dts", which sets the RX delay to 200 picoseconds for all variants. Those files were added on 18 May 2023.
Code Select
&emac {
pinctrl-names = "default";
pinctrl-0 = <&rgmii_pins>;
phy-mode = "rgmii";
phy-handle = <&ext_rgmii_phy>;
phy-supply = <®_dcdc1>;
allwinner,tx-delay-ps = <600>;
allwinner,rx-delay-ps = <200>;
status = "okay";
};
Setting the RX delay is enough to fix the issue with the Internet connection dropping lots of packets and running slow.
This makes me wonder, if it was unnecessary to set it in the mainline Linux device tree file, when did it become necessary? Which revisions of the board require it besides revision H?
Per the bill of materials (BoM) and schematics of A64-OLinuXino in OLIMEX/OLINUXINO repository on GitHub, revisions of the board starting with revision B have KSZ9031RNXCC (consumer) or KSZ9031RNXIC-TR (industrial). It shows up in dmesg as "Micrel KSZ9031 Gigabit PHY". However, revision A of the board had RTL8211CL-GR instead. Is it the cause of the difference?
It is necessary to understand this to be able to choose the device tree correctly.
Edit: I have just noticed that the page for "Olimex A64-OLinuXino" at linux-sunxi wiki indicates that revision D in 2017 was fully supported by the upstream Das U-Boot and the mainline Linux kernel. However, revision D and revision H seem to have the same Gigabit PHY chip. So, the chip change is not the cause of the different device tree file being required. But what is the cause then?
#5
FPGA / Re: SPI Programming Sequence f...
Last post by olin - April 15, 2026, 07:25:59 PMHi cdan,
can you clarify what you try to do? Is it:
a) program the Flash IC on iCE40HX8K via SPI?
or
b) execute the FPGA bitstream on iCE40HX8K via SPI?
These are 2 different things.
If you do option b) you need to swap MOSI and MISO lines on your MCU.
Also, to execute bitstream you need to keep the SPI_CS low BEFORE you raise
the C_RESET pin High (during FPGA reset), or else the FPGA will try to use Flash IC to read the bitstream from.
Swapping MISO and MOSI lines is easy on some MCUs (like ESP32) because it is software defined. On others MCUs that is not so simple, and Olimex designers though about it, and added a hardware option on their EVB board to swap MISO / MOSI lines. See note 2 on the schematic, it says:
"2. When iCE40HX8K Direct SRAM programming is used, unmount R9 and populate R19!"
That seems like a good option, but it is quite hard for a hobbyist with intermediate soldering skills to solder 0201 resistor in a tiny space. The 2 resistors (R9/R19) should have been designed as 0805 (or at least 0603) for that option to be useful.
can you clarify what you try to do? Is it:
a) program the Flash IC on iCE40HX8K via SPI?
or
b) execute the FPGA bitstream on iCE40HX8K via SPI?
These are 2 different things.
If you do option b) you need to swap MOSI and MISO lines on your MCU.
Also, to execute bitstream you need to keep the SPI_CS low BEFORE you raise
the C_RESET pin High (during FPGA reset), or else the FPGA will try to use Flash IC to read the bitstream from.
Swapping MISO and MOSI lines is easy on some MCUs (like ESP32) because it is software defined. On others MCUs that is not so simple, and Olimex designers though about it, and added a hardware option on their EVB board to swap MISO / MOSI lines. See note 2 on the schematic, it says:
"2. When iCE40HX8K Direct SRAM programming is used, unmount R9 and populate R19!"
That seems like a good option, but it is quite hard for a hobbyist with intermediate soldering skills to solder 0201 resistor in a tiny space. The 2 resistors (R9/R19) should have been designed as 0805 (or at least 0603) for that option to be useful.
#6
ESP32 / Re: Is anyone using the ESP32-...
Last post by tonytero - April 14, 2026, 03:45:41 PMHi,
Thanks for the quick reply. As you suggest, I think this may be a problem with the overlay and I am working on reducing things to the bare minimum to get a clean build, with my own overlay file.
Still, if anyone has an example project to use as a reference, it would be really helpful.
Thanks,
-- Tony T
Thanks for the quick reply. As you suggest, I think this may be a problem with the overlay and I am working on reducing things to the bare minimum to get a clean build, with my own overlay file.
Still, if anyone has an example project to use as a reference, it would be really helpful.
Thanks,
-- Tony T
#7
ESP32 / Re: Is anyone using the ESP32-...
Last post by LubOlimex - April 14, 2026, 08:17:12 AMAre you using the config for ESP32-EVB as explained here: https://docs.zephyrproject.org/latest/boards/olimex/olimex_esp32_evb/doc/index.html
Maybe check the overlays for the board and see if the pinout is proper. ESP32-EVB uses GPIO0 for Ethernet clock.
Report to the Zephyr GitHub the issue and if you want to move faster maybe create own overlay for the Ethernet for ESP32-EVB with own declarations.
Maybe check the overlays for the board and see if the pinout is proper. ESP32-EVB uses GPIO0 for Ethernet clock.
Report to the Zephyr GitHub the issue and if you want to move faster maybe create own overlay for the Ethernet for ESP32-EVB with own declarations.
#8
FPGA / Re: Niceprog: new programmer f...
Last post by LubOlimex - April 14, 2026, 08:10:40 AMNice, thank you for this project and sharing it!
#9
ESP32 / Is anyone using the ESP32-EVB ...
Last post by tonytero - April 13, 2026, 07:49:15 PMHello All,
I was wondering if anyone is using the ESP32-EVB with Zephyr? It seems to be supported, but I've run into problems getting the wired Ethernet interface to work.
I haven't been able to find much information on the DT_HAS_ESPRESSIF_ESP32_ETH_ENABLED option. I was wondering if anyone had, or knew of, a working example of a Zephyr project using Ethernet that they could share?
Thanks,
-- Tony T
I was wondering if anyone is using the ESP32-EVB with Zephyr? It seems to be supported, but I've run into problems getting the wired Ethernet interface to work.
Code Select
The message that I get during the build is:
warning: ETH_ESP32 (defined at drivers/ethernet/Kconfig.esp32:6) was assigned the value 'y' but got the value 'n'. Check these unsatisfied dependencies: DT_HAS_ESPRESSIF_ESP32_ETH_ENABLED (=n). See http://docs.zephyrproject.org/latest/kconfig.html#CONFIG_ETH_ESP32 and/or look up ETH_ESP32 in the menuconfig/guiconfig interface. The Application Development Primer, Setting Configuration Values,
and Kconfig - Tips and Best Practices sections of the manual might be helpful too.
[/size]I haven't been able to find much information on the DT_HAS_ESPRESSIF_ESP32_ETH_ENABLED option. I was wondering if anyone had, or knew of, a working example of a Zephyr project using Ethernet that they could share?
Thanks,
-- Tony T
#10
TERES DIY Laptop / Anyone wants my Teres 1?
Last post by khumarahn - April 12, 2026, 02:22:13 PMHi all. Wonder if anyone still reads this forum... I'm moving, getting rid of things I haven't been using (which means almost everything). Does anyone want my Teres? I would sell it for your own price + shipping.