- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
ESP32 / Re: ESP32-P4 micropython port
Last post by puhuri - November 14, 2026, 09:07:10 PMNow had time to look at it more.
The modifications and instructions from kerekesg is a good base. The major issue is that one need build PRE_REV3 variant.
So my workflow was following. Clone both the micropython and the above repo according to their instructions.
Copy modified files over:
I used docker image (with podman) for interactive session (did run low with diskspace so need to check old photos had been backup to NAS
).
Then within container commandline run:
And once compilation completed without major error (reported some re#defines warnings), just cd ports/esp32/build-OLIMEX_ESP32_P4-PRE_REV3 and write to board.
I'm using MQTT_AS package, so one needs to install github:peterhinch/micropython-mqtt/mqtt_as_eth instead and define
. Next up some soldering, but that is for later.
The modifications and instructions from kerekesg is a good base. The major issue is that one need build PRE_REV3 variant.
So my workflow was following. Clone both the micropython and the above repo according to their instructions.
Copy modified files over:
Code Select
cd micropython
cp -r ../micropython-olimex-esp32-p4/board-files/OLIMEX_ESP32_P4 ports/esp32/boards/
cp ../micropython-olimex-esp32-p4/board-files/sdkconfig.p4 ports/esp32/boards/
cp ../micropython-olimex-esp32-p4/board-files/sdkconfig.riscv ports/esp32/boards/
cp ../micropython-olimex-esp32-p4/board-files/dependencies.lock.esp32p4 ports/esp32/lockfiles/
cp ports/esp32/boards/ESP32_GENERIC_P4/mpconfigvariant_PRE_REV3.cmake ports/esp32/boards/OLIMEX_ESP32_P4/
I used docker image (with podman) for interactive session (did run low with diskspace so need to check old photos had been backup to NAS
).Code Select
docker run --rm -v $PWD:/project -w /project -e HOME=/tmp -it espressif/idf:release-v5.5
Then within container commandline run:
Code Select
cd ports/esp32 && make BOARD=OLIMEX_ESP32_P4 BOARD_VARIANT=PRE_REV3
And once compilation completed without major error (reported some re#defines warnings), just cd ports/esp32/build-OLIMEX_ESP32_P4-PRE_REV3 and write to board.
Code Select
PORT=/dev/serial/by-id/usb-Espressif*
esptool --port $PORT --chip esp32p4 -b 460800 --before default-reset --after hard-reset write-flash "@flash_args"
I'm using MQTT_AS package, so one needs to install github:peterhinch/micropython-mqtt/mqtt_as_eth instead and define
Code Select
import mqtt_as_eth in python initialization. The normal mqtt_as does use WLAN-dependent code that won't work. Successfully connects to MQTT server and communicates messages . Next up some soldering, but that is for later. #2
Neo6502 / Re: Prophet server for the Neo...
Last post by béné - November 14, 2026, 12:51:21 AMHi Ralf,
Thanks for the detailed report, it helped a lot. I need to correct what I said earlier: the Olimex UART WiFi module is not unsupported at the protocol level. The network client speaks standard AT commands (ATE0, AT+CIPSTART, AT+CIPSEND, +IPD) at 115200 8N1.
The likely cause of the error flood is on Trinity's side. The module plugs into the UEXT, which is the same UART (uart0, GPIO 28/29) as Trinity's debug port, also at 115200 baud. Trinity sent a status line every second on it. The ESP8266 answers "ERROR" to that text, and everything received on that UART was fed into the keyboard queue. NeoDOS therefore typed the module's answers (hence the files like "ER" and "ROR") and echoed them back, which created a feedback loop.
I have changed the debug port so that it stays silent and ignores incoming bytes until it is deliberately woken up. The fix is in Trinity 0.16.103, now on the Prophet server:
You can also build it from source: https://github.com/benedictemarty/Neo6502firmware/tree/trinity-v0.16.103
Please note that this is a test build. It was compiled and tested in an emulator only, not on a real board. I do not have the Olimex module, so I have never tried it myself and cannot confirm that it works.
If you are willing to try it with the module plugged into the UEXT, the expected result is no error flood and no stray files. Could you also tell me which port/pins the module is connected to, and whether the files still appear?
Thanks again for testing Trinity so thoroughly.
béné
Thanks for the detailed report, it helped a lot. I need to correct what I said earlier: the Olimex UART WiFi module is not unsupported at the protocol level. The network client speaks standard AT commands (ATE0, AT+CIPSTART, AT+CIPSEND, +IPD) at 115200 8N1.
The likely cause of the error flood is on Trinity's side. The module plugs into the UEXT, which is the same UART (uart0, GPIO 28/29) as Trinity's debug port, also at 115200 baud. Trinity sent a status line every second on it. The ESP8266 answers "ERROR" to that text, and everything received on that UART was fed into the keyboard queue. NeoDOS therefore typed the module's answers (hence the files like "ER" and "ROR") and echoed them back, which created a feedback loop.
I have changed the debug port so that it stays silent and ignores incoming bytes until it is deliberately woken up. The fix is in Trinity 0.16.103, now on the Prophet server:
- client settings: set server prophet.3617.fr and set port 8998
- entry firmware/trinity, file trinity.uf2, to be copied onto the RPI-RP2 drive in BOOTSEL mode
- SHA-256: 36cfd174113d254ceb078aab75c133ed5d9db0c68a6a55a7a038bab7f163fc35
You can also build it from source: https://github.com/benedictemarty/Neo6502firmware/tree/trinity-v0.16.103
Please note that this is a test build. It was compiled and tested in an emulator only, not on a real board. I do not have the Olimex module, so I have never tried it myself and cannot confirm that it works.
If you are willing to try it with the module plugged into the UEXT, the expected result is no error flood and no stray files. Could you also tell me which port/pins the module is connected to, and whether the files still appear?
Thanks again for testing Trinity so thoroughly.
béné
#3
New Products release / OpenFest 2026 Soldering worksh...
Last post by olimex - November 10, 2026, 02:50:15 PMOpen Fest Soldering Workshop for beginners recap https://olimex.wordpress.com/2026/11/10/openfest-2026-soldering-workshop-recap/ #oshw #soldering #embedded #electronics #maker #stem #openfest2026
#4
A20 / ### ERROR ### Please RESET the...
Last post by laskov - November 10, 2026, 11:01:36 AMHello,
I tested two images on different microSD cards and the result is the same. Booting stops with:
U-Boot SPL 2021.04+olimex-1-20250305.102147 (Mar 05 2025 - 10:22:57 +0000)
DRAM: 0 MiB
### ERROR ### Please RESET the board ###
U-Boot SPL 2013.10-rc2-08400-g8a4621c (Oct 29 2013 - 15:24:26)
Board: A20-OLinuXino_MICRO
DRAM: ? ? 0 MiB
### ERROR ### Please RESET the board ###
Please help! What could the problem be, and how can I fix it?
A20-Olinuxino-Micro Rev. G
I tested two images on different microSD cards and the result is the same. Booting stops with:
U-Boot SPL 2021.04+olimex-1-20250305.102147 (Mar 05 2025 - 10:22:57 +0000)
DRAM: 0 MiB
### ERROR ### Please RESET the board ###
U-Boot SPL 2013.10-rc2-08400-g8a4621c (Oct 29 2013 - 15:24:26)
Board: A20-OLinuXino_MICRO
DRAM: ? ? 0 MiB
### ERROR ### Please RESET the board ###
Please help! What could the problem be, and how can I fix it?
A20-Olinuxino-Micro Rev. G
#5
A64 / SPI Bus on UEXT connector on A...
Last post by winfried - November 10, 2026, 12:30:43 AMWant to drive the Olimex ADS1262 (ADC converter) on the UEXT connector,
on my A64-OLinuXino-2Ge8G-IND, running OLIMAGE with kernel 5.10.180-olimex:
running `olinuxino-overlay`and selecting "spi0-spidev.dtbo" and reboot did not bring up the "/dev/spidev0.0" .
With help of "GPT-6.1 Terra" I got a solution, I do not understand at all, so I ask here if this is a valid/good solution ?
Here the summary:
---
A64-OLinuXino: SPI overlay in uEnv.txt was added.
No /dev/spidev* device appeared, and both SPI controllers were still marked disabled in the running device tree.
What was wrong:
This image boots from a FIT image (/boot/kernel.itb). Although /boot/boot.cmd imports uEnv.txt, it does not apply the fdtoverlays list in the FIT boot path. The FIT configuration for my board included the I²C0 overlay, but not the SPI overlays.
Also, two SPI0 overlays are needed:
sun50i-a64-spi0.dtbo enables the SPI0 controller.
spi0-spidev.dtbo adds the userspace SPI device on chip select 0.
The spi0-spidev overlay alone does not enable its parent controller.
What worked:
I backed up /boot/kernel.itb and edited the FIT template at /usr/lib/olinuxino/kernel.its:
Added an image entry for spi0-spidev.dtbo.
Added both the existing SPI0 controller overlay and the new spidev overlay to the config-8861 FDT list, keeping the existing I²C0 overlay.
Rebuilt /boot/kernel.itb and rebooted.
After reboot, /dev/spidev0.0 appeared.
The practical lesson for this image is that adding overlays to uEnv.txt was not sufficient: they had to be included in the FIT configuration actually used to boot the board. The same issue may affect other overlays listed only in uEnv.txt, such as a DS3231 RTC overlay.
---
I remember years ago, it was working with the "olinuxino-overlay", so I am not sure this is the right fix.
mfg winfried
Appendix patch:
on my A64-OLinuXino-2Ge8G-IND, running OLIMAGE with kernel 5.10.180-olimex:
running `olinuxino-overlay`and selecting "spi0-spidev.dtbo" and reboot did not bring up the "/dev/spidev0.0" .
With help of "GPT-6.1 Terra" I got a solution, I do not understand at all, so I ask here if this is a valid/good solution ?
Here the summary:
---
A64-OLinuXino: SPI overlay in uEnv.txt was added.
No /dev/spidev* device appeared, and both SPI controllers were still marked disabled in the running device tree.
What was wrong:
This image boots from a FIT image (/boot/kernel.itb). Although /boot/boot.cmd imports uEnv.txt, it does not apply the fdtoverlays list in the FIT boot path. The FIT configuration for my board included the I²C0 overlay, but not the SPI overlays.
Also, two SPI0 overlays are needed:
sun50i-a64-spi0.dtbo enables the SPI0 controller.
spi0-spidev.dtbo adds the userspace SPI device on chip select 0.
The spi0-spidev overlay alone does not enable its parent controller.
What worked:
I backed up /boot/kernel.itb and edited the FIT template at /usr/lib/olinuxino/kernel.its:
Added an image entry for spi0-spidev.dtbo.
Added both the existing SPI0 controller overlay and the new spidev overlay to the config-8861 FDT list, keeping the existing I²C0 overlay.
Rebuilt /boot/kernel.itb and rebooted.
After reboot, /dev/spidev0.0 appeared.
The practical lesson for this image is that adding overlays to uEnv.txt was not sufficient: they had to be included in the FIT configuration actually used to boot the board. The same issue may affect other overlays listed only in uEnv.txt, such as a DS3231 RTC overlay.
---
I remember years ago, it was working with the "olinuxino-overlay", so I am not sure this is the right fix.
mfg winfried
Appendix patch:
Code Select
--- /usr/lib/olinuxino/kernel.its.before-spi 2026-06-30 10:45:19.000000000 +0100
+++ /usr/lib/olinuxino/kernel.its 2026-11-09 21:53:39.849073203 +0000
@@ -153,6 +153,19 @@
algo = "sha1";
};
};
+overlay-4 {
+ data = /incbin/("/usr/lib/olinuxino-overlays/sun50i-a64/spi0-spidev.dtbo");
+ type = "flat_dt";
+ arch = "arm64";
+ compression = "none";
+ load = <0x4FA40000>;
+ hash-1 {
+ algo = "crc32";
+ };
+ hash-2 {
+ algo = "sha1";
+ };
+};
};
configurations {
@@ -178,7 +191,7 @@
description = "Boot Linux kernel ${VERSION} with A64-OLinuXino-2Ge8G-IND";
kernel = "kernel-1";
ramdisk = "ramdisk-1";
- fdt = "fdt-3", "overlay-1";
+ fdt = "fdt-3", "overlay-1", "overlay-2", "overlay-4";
compatible = "olimex,a64-olinuxino-2ge8g-ind";
};
Code Select
cd /boot
sudo sh -c 'sed "s/\${VERSION}/$(uname -r)/g" \
/usr/lib/olinuxino/kernel.its > /boot/kernel-spi-test.its'
sudo mkimage -f /boot/kernel-spi-test.its /boot/kernel-spi-test.itb
#6
A64 / Re: Realtime scheduling for au...
Last post by winfried - November 10, 2026, 12:11:12 AMIntermediate result: Until now, I installed jackd and puredata as service: it runs for 2 Weeks and is stable , everything seems fine.
#7
ESP32 / Re: ESP32-P4 micropython port
Last post by puhuri - November 07, 2026, 01:33:58 PMI was testing ESP-P4-DevKit (rev D1) ethernet on micropython. Seems that I cannot find the right set of parameters to initialize connection.
With vanilla Micropython ESP32_P4 v1.29 (PRE_V3 variant:(sysname='esp32', nodename='esp32', release='1.29.0', version='v1.29.0 on 2026-08-24', machine='Generic ESP32P4 with pre revision 3 chip with ESP32-P4')) the error message is OSError: esp_eth_driver_install failed with invalid argument for all the cases.
With kerekesg firmware (sysname='esp32', nodename='esp32', release='1.27.0-preview', version='v1.27.0-preview.339.gbe4892097e.dirty on 2025-10-23', machine='Olimex ESP32-P4-DevKit with ESP32-P4') the error is a bit more useful:
but that fails with above error. With kerekesg firmware there seems to be an issue with GPIO configuration as Pin(52) results "ValueError: invalid pin" (Pin(32) works fine, for example).
The ref_clock_mode is a bit guess, 0 is input AFAIK but tried also 1.
Would just want to use wired network connection for a location as the wifi connection there is a bit spotty.
Have not yet tried to compile own firmware (with updated micropython), just trying to first check that it is not something trivial I'm missing here.
With vanilla Micropython ESP32_P4 v1.29 (PRE_V3 variant:(sysname='esp32', nodename='esp32', release='1.29.0', version='v1.29.0 on 2026-08-24', machine='Generic ESP32P4 with pre revision 3 chip with ESP32-P4')) the error message is OSError: esp_eth_driver_install failed with invalid argument for all the cases.
With kerekesg firmware (sysname='esp32', nodename='esp32', release='1.27.0-preview', version='v1.27.0-preview.339.gbe4892097e.dirty on 2025-10-23', machine='Olimex ESP32-P4-DevKit with ESP32-P4') the error is a bit more useful:
Code Select
E (30570) esp_eth: esp_eth_driver_install(209): can't set eth->mac or eth->phy to null
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
I've tried several intialization parameters but no luck (leaving some parameters out and trying out variations). The most correct I think is (based on schematic and micropython source):Code Select
lan=network.LAN(0, mdc=Pin(31), mdio=Pin(52), phy_type=network.PHY_IP101, phy_addr=1, reset=Pin(51), ref_clk=Pin(50), ref_clk_mode=0)but that fails with above error. With kerekesg firmware there seems to be an issue with GPIO configuration as Pin(52) results "ValueError: invalid pin" (Pin(32) works fine, for example).
The ref_clock_mode is a bit guess, 0 is input AFAIK but tried also 1.
Would just want to use wired network connection for a location as the wifi connection there is a bit spotty.
Have not yet tried to compile own firmware (with updated micropython), just trying to first check that it is not something trivial I'm missing here.
#8
New Products release / Ethernet for PICO and PICO2
Last post by olimex - November 04, 2026, 03:40:38 PMNew OSHW board adds 100MB Ethernet for RP2040, RP2350 and ESP32-S3/C3/C5/C6. ESPHome example auto-discovery in Home Assistant, OTA over Ethernet and a ready-to-flash UF2, with no Wi-Fi needed. #HomeAssistant #ESPHome #RP2040 #OSHW
https://www.olimex.com/Products/Modules/Ethernet/UEXT-CH390/open-source-hardware
https://www.olimex.com/Products/Modules/Ethernet/UEXT-CH390/open-source-hardware
#9
A20 / Re: Wich board to correctly mo...
Last post by oly - November 04, 2026, 01:37:56 PMAny clue about origin of this ?
#10
A20 / Re: Wich board to correctly mo...
Last post by oly - October 31, 2026, 02:23:32 PMHi,
I burnt the base img on SD then boot from it with no HDD connected => OK, boot from SD OS
I burnt the base img on SD then boot from it with HDD connected => OK, boot from SD OS
Then I burnt the minimal img on the SD and boot from it with no HDD connected => The system boot many times then I got prompt from SD.
I try 'findmnt -no SOURCE / reports /dev/mmcblk0p1' => nothing visible
lsblk shows only mmcblk0p1
I boot from this SD with HDD connected => OS is loaded from HDD.
The boot screen shows this :
With
EDIT 20261101:
I re rownload 20-OLinuXino-bookworm-minimal-20260323-113959.img
Re verify md5sum
Reburn it on the same SD
Try to boot with no HDD => OK
Try to boot with HDD connected => KO, boot from HDD
All these inspire me perplexity
I burnt the base img on SD then boot from it with no HDD connected => OK, boot from SD OS
I burnt the base img on SD then boot from it with HDD connected => OK, boot from SD OS
Then I burnt the minimal img on the SD and boot from it with no HDD connected => The system boot many times then I got prompt from SD.
I try 'findmnt -no SOURCE / reports /dev/mmcblk0p1' => nothing visible
lsblk shows only mmcblk0p1
I boot from this SD with HDD connected => OS is loaded from HDD.
The boot screen shows this :
Code Select
switch to partitions #0, OK
mmc0 is current device
scanning mmc 0:1 ...
Found U-Boot script /boot/boot.scr
2274 bytes read in 3mms (740.2 KiB/s)
## Executing script at 43100000
Bott script loaded from mmc
Checking for /uEnv.txt...
Checking for /boot/uEnv.txt
1156 bytes read in 2 mms
Boot script loaded from mmcWith
Code Select
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 111,8G 0 disk
└─sda1 8:1 0 111,8G 0 part /
mmcblk0 179:0 0 14,8G 0 disk
└─mmcblk0p1 179:1 0 14,8G 0 part
EDIT 20261101:
I re rownload 20-OLinuXino-bookworm-minimal-20260323-113959.img
Re verify md5sum
Reburn it on the same SD
Try to boot with no HDD => OK
Try to boot with HDD connected => KO, boot from HDD
All these inspire me perplexity