- Welcome to Olimex Support Forum.
Olimex Support Forum
Recent posts
#1
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?
#2
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
#3
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 ..."
#4
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.
#5
A64 / Re: Status of CVE-2026-31431
Last post by mossroy - May 08, 2026, 08:51:06 PMAnd same for Dirty Frag (2026-43284)
#6
FPGA / Re: Stability Issue with GateM...
Last post by charon030 - May 07, 2026, 08:56:14 AMHi,
I did some more investigations.
With the design I sent you, core voltage drops from 1.098V to 1.097V. Not a big change, but a change.
I checked the voltage converters and can see that the Olimex board uses converters with 2A output current maximum. At 1.1V this corresponds to 2.2W. However, in the GateMate datasheet they consume already 2W with LFSR shift registers, see page 162 of DS1001. The headroom might be too small, in particular if there are peaks in power consumption. Just as a reference, on the Cologne Chips Devboard they use voltage converters with 3A.
Best regards
Matthias
I did some more investigations.
With the design I sent you, core voltage drops from 1.098V to 1.097V. Not a big change, but a change.
I checked the voltage converters and can see that the Olimex board uses converters with 2A output current maximum. At 1.1V this corresponds to 2.2W. However, in the GateMate datasheet they consume already 2W with LFSR shift registers, see page 162 of DS1001. The headroom might be too small, in particular if there are peaks in power consumption. Just as a reference, on the Cologne Chips Devboard they use voltage converters with 3A.
Best regards
Matthias
#7
ESP32 / Re: ESP32-POE-ISO-EA-16MB full...
Last post by Ol!mexGoody - May 06, 2026, 05:54:37 PMQuote from: LubOlimex on May 06, 2026, 10:39:40 AMI found the 3D step component for the antenna variant, I replaced the original one with it. You can find both the export and only the component here:
https://ftp.olimex.com/TEMP/ESP32-PoE-ISO-revision-M/
Thanks! I updated the Fusion file with it.
#8
FPGA / Re: Stability Issue with GateM...
Last post by charon030 - May 06, 2026, 11:13:21 AMHi,
thanks for the offer. Note that I'm trying to gain experience with the GateMate ecosystem. The design I'm using is not for production or something but more a tool to get to know your board as well as the tool flow.
I can't upload the bit file here but added it to my cloud storage:
https://drive.proton.me/urls/PRH4ANX41R#DGguScyKprlV
You can load it with the "openFPGAloader -c dirtyJtag fract_controller.bit"
All you need to replicate is the following:
- a VGA monitor connected
- a PS/2 keyboard connected
The bit stream internally uses 16 pixel computation units with multipliers and adders.
The design achieves timing closure with 50 MHz target clock (54 MHz timing with "typical" timing setting). Utilization is still moderate:
Info: CPE_LT: 22480/ 40960 54%
Info: CPE_FF: 9949/ 40960 24%
Info: CPE_RAMIO: 15/ 40960 0%
Info: RAM_HALF: 0/ 64 0%
What you can see is that there are actually pixels changing their colors but the picture should be really stable. This indicates already that the computations do not finish within one clock period. The reason can be that either the timing models of Cologne Chip are too optimistic in the "typical" case or that the power supply/consumption is causing issues.
What's more: When you move the screen to an area where more computations happen (more toggling in the FPGA), the screen goes black completely. This looks really like an issue with power supply. The screen area causing this is the inner of the fractal (lots of green on the screen). To interact with the fractal, use the keyboard (cursor keys, or F1/F2 to zoom or space for automatic zoom).
If I reapeat the same test with a different parameterization (8 or 12 pixel computation units => less utilization of the FPGA), I neither see the wobbling pixels nor the screen going black.
If you need anything else, let me know.
Thanks a lot
Matthias
thanks for the offer. Note that I'm trying to gain experience with the GateMate ecosystem. The design I'm using is not for production or something but more a tool to get to know your board as well as the tool flow.
I can't upload the bit file here but added it to my cloud storage:
https://drive.proton.me/urls/PRH4ANX41R#DGguScyKprlV
You can load it with the "openFPGAloader -c dirtyJtag fract_controller.bit"
All you need to replicate is the following:
- a VGA monitor connected
- a PS/2 keyboard connected
The bit stream internally uses 16 pixel computation units with multipliers and adders.
The design achieves timing closure with 50 MHz target clock (54 MHz timing with "typical" timing setting). Utilization is still moderate:
Info: CPE_LT: 22480/ 40960 54%
Info: CPE_FF: 9949/ 40960 24%
Info: CPE_RAMIO: 15/ 40960 0%
Info: RAM_HALF: 0/ 64 0%
What you can see is that there are actually pixels changing their colors but the picture should be really stable. This indicates already that the computations do not finish within one clock period. The reason can be that either the timing models of Cologne Chip are too optimistic in the "typical" case or that the power supply/consumption is causing issues.
What's more: When you move the screen to an area where more computations happen (more toggling in the FPGA), the screen goes black completely. This looks really like an issue with power supply. The screen area causing this is the inner of the fractal (lots of green on the screen). To interact with the fractal, use the keyboard (cursor keys, or F1/F2 to zoom or space for automatic zoom).
If I reapeat the same test with a different parameterization (8 or 12 pixel computation units => less utilization of the FPGA), I neither see the wobbling pixels nor the screen going black.
If you need anything else, let me know.
Thanks a lot
Matthias
#9
ESP32 / Re: ESP32-POE-ISO-EA-16MB full...
Last post by LubOlimex - May 06, 2026, 10:39:40 AMI found the 3D step component for the antenna variant, I replaced the original one with it. You can find both the export and only the component here:
https://ftp.olimex.com/TEMP/ESP32-PoE-ISO-revision-M/
https://ftp.olimex.com/TEMP/ESP32-PoE-ISO-revision-M/
#10
FPGA / Re: Stability Issue with GateM...
Last post by LubOlimex - May 06, 2026, 08:50:50 AMCan you think of a way we can replicate it here? Can you give us a project or a file to load and steps to replicate the hang?
We are not very proficient with FPGA and FPGA software development, so if you can provide us with step by step guide to replicate it we are willing to test and perform hardware changes to see if the behavior improves with bigger capacitors and the same software as you.
We are not very proficient with FPGA and FPGA software development, so if you can provide us with step by step guide to replicate it we are willing to test and perform hardware changes to see if the behavior improves with bigger capacitors and the same software as you.