- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#11
A64 / A64-OLinuXino-2Ge16G-IND: U-Bo...
Last post by Brati - May 18, 2026, 04:52:36 PMI am developing a Yocto 5.0 (Scarthgap) Linux image for the A64-OLinuXino-2Ge16G-IND board and have encountered a critical issue with warm reboot that I have been unable to resolve.
Issue:
The board hangs on every reboot (warm reset and cold reset) after the following boot log line:
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
[HANG - no U-Boot output]
First cold power-on always works correctly. The hang occurs every time after any reboot command.
Setup:
- Board: A64-OLinuXino-2Ge16G-IND
- U-Boot: 2024.01 (mainline, from Yocto Scarthgap / poky)
- TF-A: 2.10.4 with SUNXI_PSCI_USE_NATIVE=1 SUNXI_PSCI_USE_SCPI=1
- Crust SCP: v0.6.0 (a64-olinuxino_defconfig)
- Kernel: Linux 6.6.85
- Boot device: SD card (mmcblk0)
What I have tried:
- Added Crust SCP firmware (scp.bin embedded in U-Boot SPL)
- Added R_WDOG fix for A64 in reset_cpu() in board.c
- Added PLL6 lock timeout in clock_init_safe() in clock_sun6i.c
- TF-A rebuilt with LOG_LEVEL=40 - confirmed BL31 completes successfully and hands off to U-Boot at 0x4a000000
- U-Boot freezes before printing a single character
The hang is confirmed to be between BL31 exit and U-Boot's first UART output.
Question:
Can anyone please share which U-Boot version and if any specific patches you use in your Olimage builds for the A64-OLinuXino to make reboot work correctly?
Any guidance would be greatly appreciated.
Best regards,
Bratiranjan Acharya
bratiranjan12@gmail.com
Issue:
The board hangs on every reboot (warm reset and cold reset) after the following boot log line:
INFO: BL31: Preparing for EL3 exit to normal world
INFO: Entry point address = 0x4a000000
INFO: SPSR = 0x3c9
[HANG - no U-Boot output]
First cold power-on always works correctly. The hang occurs every time after any reboot command.
Setup:
- Board: A64-OLinuXino-2Ge16G-IND
- U-Boot: 2024.01 (mainline, from Yocto Scarthgap / poky)
- TF-A: 2.10.4 with SUNXI_PSCI_USE_NATIVE=1 SUNXI_PSCI_USE_SCPI=1
- Crust SCP: v0.6.0 (a64-olinuxino_defconfig)
- Kernel: Linux 6.6.85
- Boot device: SD card (mmcblk0)
What I have tried:
- Added Crust SCP firmware (scp.bin embedded in U-Boot SPL)
- Added R_WDOG fix for A64 in reset_cpu() in board.c
- Added PLL6 lock timeout in clock_init_safe() in clock_sun6i.c
- TF-A rebuilt with LOG_LEVEL=40 - confirmed BL31 completes successfully and hands off to U-Boot at 0x4a000000
- U-Boot freezes before printing a single character
The hang is confirmed to be between BL31 exit and U-Boot's first UART output.
Question:
Can anyone please share which U-Boot version and if any specific patches you use in your Olimage builds for the A64-OLinuXino to make reboot work correctly?
Any guidance would be greatly appreciated.
Best regards,
Bratiranjan Acharya
bratiranjan12@gmail.com
#12
New Product Ideas / Re: can a lime 2 or pico 2 xxl...
Last post by LubOlimex - May 18, 2026, 02:50:40 PMAll three of the boards that you mentioned can run completely open source software. Yet there is major difference between the Raspberry Pi product and Olimex products - Raspberry Pi Zero W is not open-hardware, while Olimex provides files used to manufacture their products, when it comes to A20-OLinuXino-LIME2 and PICO2-XXL. These are open-hardware products.
About the software - the official Linux image provided by Olimex for A20-OLinuXino-LIME2 is truly open-source software, and contains no binary blobs. This is mentioned in the Olimage guide here:
https://github.com/OLIMEX/OLINUXINO/blob/master/DOCUMENTS/OLIMAGE/Olimage-guide.pdf
PICO2-XXL doesn't come with own software, the software Olimex provides for PICO2-XXL is based on the RPi SDK, so expect similar software as what Raspberry Pi Zero W uses.
About the software - the official Linux image provided by Olimex for A20-OLinuXino-LIME2 is truly open-source software, and contains no binary blobs. This is mentioned in the Olimage guide here:
https://github.com/OLIMEX/OLINUXINO/blob/master/DOCUMENTS/OLIMAGE/Olimage-guide.pdf
PICO2-XXL doesn't come with own software, the software Olimex provides for PICO2-XXL is based on the RPi SDK, so expect similar software as what Raspberry Pi Zero W uses.
#13
ESP32 / ESP32-PoE-ISO UART1 issue
Last post by bartgrefte - May 17, 2026, 06:54:41 PMMy apologies for the kick.
@ninousf and @_AndreaS_ , did you end up solving it? Running the 16MB build of ESPEasy here, I'm trying to use the MOD-RS485-ISO with HW serial1 on GPIO's 36 (Rx) and 4 (Tx).
So far no luck.
@ninousf and @_AndreaS_ , did you end up solving it? Running the 16MB build of ESPEasy here, I'm trying to use the MOD-RS485-ISO with HW serial1 on GPIO's 36 (Rx) and 4 (Tx).
So far no luck.
#14
New Product Ideas / can a lime 2 or pico 2 xxl run...
Last post by oeren - May 17, 2026, 05:13:02 PMhttps://www.crowdsupply.com/open-tools/open-printer
In the following I am assuming that the software which is running the open printer is free software.
Unfortunately the open printer people decided to go with a rpi zero w. The rpi zero w requires non free software in order to work. In result free software people do not want to use the open printer. On the other hand should it be possible to replace the rpi zero w with a computer able to run entirely on free software the open printer would get relevant for free software people.
Both lime 2 and pico 2 xxl can run entirely on free software correct? If so can I get to know if the lime 2 and pico 2 xxl are candidates for replacing a rpi zero w?
Please do not provide answers if you are not familiar with what free software is in the context of the free software foundation. Thank you.
In the following I am assuming that the software which is running the open printer is free software.
Unfortunately the open printer people decided to go with a rpi zero w. The rpi zero w requires non free software in order to work. In result free software people do not want to use the open printer. On the other hand should it be possible to replace the rpi zero w with a computer able to run entirely on free software the open printer would get relevant for free software people.
Both lime 2 and pico 2 xxl can run entirely on free software correct? If so can I get to know if the lime 2 and pico 2 xxl are candidates for replacing a rpi zero w?
Please do not provide answers if you are not familiar with what free software is in the context of the free software foundation. Thank you.
#15
A64 / Re: Debian GNU/Linux 13 (Trixi...
Last post by mossroy - May 14, 2026, 10:36:02 PMFor information, I've described a different procedure to install Debian 13 on my A64-OLinuXino-2Ge8G-IND boards: https://blog.mossroy.fr/2026/05/14/debian-13-sur-a64-olinuxino-2ge8g-ind/ (it's written in French).
It's far from perfect, but works fine for my use-case
It's far from perfect, but works fine for my use-case
#16
A64 / Re: Bookworm upgrade availabil...
Last post by mossroy - May 14, 2026, 10:30:52 PMIf anyone is interested, I've posted on my blog (in French) my procedure to install Debian 13 on A64-OLinuXino-2Ge8G-IND boards: https://blog.mossroy.fr/2026/05/14/debian-13-sur-a64-olinuxino-2ge8g-ind/
#17
New Products release / Re: Introducing the ESP32-P4-P...
Last post by LubOlimex - May 11, 2026, 10:30:55 AMThis is no the proper place for this reply. Anyway, ESP32-P4-PC has no BAT1 led. Do you mean CHARGE1 LED? Do you have any battery attached to the BAT1 connector?
#18
New Products release / Re: Introducing the ESP32-P4-P...
Last post by bishoff7 - May 11, 2026, 03:04:19 AMHi .why does the BAT1 led costantly have a very dim glow to it constatntly and every second gets slightly brighter then back to very dim again.Regards Chris
#19
A64 / Re: Debian GNU/Linux 13 (Trixi...
Last post by Roman - May 10, 2026, 09:05:36 PMSo, it looks like the u-boot has to be written manually anyway, either with the script from u-boot-sunxi or directly.
The offset is 8 in case of MBR and 128 in case of GPT.
Now it boots as expected untill "Starting kernel ..."
Code Select
# apt install u-boot-sunxi
# dd if=/usr/lib/u-boot/a64-olinuxino-emmc/u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1k seek=128The offset is 8 in case of MBR and 128 in case of GPT.
Now it boots as expected untill "Starting kernel ..."
#20
A64 / Re: Debian GNU/Linux 13 (Trixi...
Last post by Roman - May 10, 2026, 06:30:56 PMHere is my first attempt at installing Debian Trixie for testing.
I downloaded Debian u-boot for a64-olinuxino and the Debian installer root filesystem.
I mounted the root filesystem.
There are two devicetrees for A64-OLinuXino, depending on whether it has eMMC or not. I chose the eMMC version because my board has it. I have not tried leaving it unspecified, even though I was going to install to the microSD card.
I added the overlay from my previous post to fix download issues during installation.
I unmounted the image.
I found the microSD card device path, wiped its table, and overwritten it with the u-boot and the filesystem. If you want to try the following commands, use the actual path on your system instead of /dev/sdX below.
I installed Debian normally and used the defaults. No issues with connectivity when downloading packages.
However, when rebooting after installation, it failed and fell back to booting from eMMC. I inspected the expected offsets on the microSD for u-boot and couldn't find it. It looks like the installer either didn't write it to the correct offset or overwritten it. For a GPT partition table, the offset should be 128KB.
I chrooted into the installation, installed "u-boot-sunxi" package, which wasn't installed for some reason, and was surprised by the installation script when trying to run it.
"man u-boot-install-sunxi64" states that "GPT partition tables are incompatible with the layout used on sunxi devices". This is wrong for Allwinner A64 SoC in general and for A64-OLinuXino specifically. But I wonder why the installer even chose GPT.
So, Debian only supports MBR. It is necessary to partition the storage manually instead of trusting the installer.
I downloaded Debian u-boot for a64-olinuxino and the Debian installer root filesystem.
Code Select
$ wget2 https://deb.debian.org/debian/dists/trixie/main/installer-arm64/current/images/netboot/SD-card-images/firmware.a64-olinuxino.img.gz
$ wget2 https://deb.debian.org/debian/dists/trixie/main/installer-arm64/current/images/netboot/SD-card-images/partition.img.gz
$ gunzip firmware.a64-olinuxino.img.gz
$ gunzip partition.img.gzI mounted the root filesystem.
Code Select
$ sudo losetup -Pf partition.img
$ losetup -a
/dev/loop0
$ sudo mount /dev/loop0 /mntThere are two devicetrees for A64-OLinuXino, depending on whether it has eMMC or not. I chose the eMMC version because my board has it. I have not tried leaving it unspecified, even though I was going to install to the microSD card.
Code Select
$ ls /mnt/dtbs/allwinner/sun50i-a64-olinuxino*.dtb
/mnt/dtbs/allwinner/sun50i-a64-olinuxino.dtb /mnt/dtbs/allwinner/sun50i-a64-olinuxino-emmc.dtb
$ echo "fdt /dtbs/allwinner/sun50i-a64-olinuxino-emmc.dtb" | sudo tee -a /mnt/extlinux/extlinux.confI added the overlay from my previous post to fix download issues during installation.
Code Select
$ sudo cp sun50i-a64-rx-delay.dtbo /mnt/dtbs/
$ echo "fdtoverlays /dtbs/sun50i-a64-rx-delay.dtbo" | sudo tee -a /mnt/extlinux/extlinux.confI unmounted the image.
Code Select
$ sudo umount /mnt
$ sudo losetup -d /dev/loop0I found the microSD card device path, wiped its table, and overwritten it with the u-boot and the filesystem. If you want to try the following commands, use the actual path on your system instead of /dev/sdX below.
Code Select
$ lsblk
$ sudo umount /dev/sdX1
$ sudo wipefs -a /dev/sdX
$ cat firmware.a64-olinuxino.img partition.img | sudo dd of=/dev/sdX bs=1M status=progress
$ syncI installed Debian normally and used the defaults. No issues with connectivity when downloading packages.
However, when rebooting after installation, it failed and fell back to booting from eMMC. I inspected the expected offsets on the microSD for u-boot and couldn't find it. It looks like the installer either didn't write it to the correct offset or overwritten it. For a GPT partition table, the offset should be 128KB.
Code Select
(parted) print
Model: SD SA08G (sd/mmc)
Disk /dev/mmcblk0: 7745MB
Sector size (logical/physical): 512B/512B
Partition Table: gpt
Disk Flags:
Number Start End Size File system Name Flags
1 1049kB 17.8MB 16.8MB
2 17.8MB 876MB 858MB ext4 legacy_boot
3 876MB 6973MB 6097MB ext4
4 6973MB 7744MB 771MB linux-swap(v1) swapI chrooted into the installation, installed "u-boot-sunxi" package, which wasn't installed for some reason, and was surprised by the installation script when trying to run it.
Code Select
# u-boot-install-sunxi64 /dev/mmcblk0
/usr/bin/u-boot-install-sunxi64: device/image (/dev/mmcblk0) uses GPT partition table, unusable on sunxi64"man u-boot-install-sunxi64" states that "GPT partition tables are incompatible with the layout used on sunxi devices". This is wrong for Allwinner A64 SoC in general and for A64-OLinuXino specifically. But I wonder why the installer even chose GPT.
So, Debian only supports MBR. It is necessary to partition the storage manually instead of trusting the installer.