Recent posts

#1

FPGA / Re: Stability Issue with GateM...

Last post by charon030 - Today at 12:43:29 PM

Hi Lub,

Thanks for your prompt response.

Actually, I'm running the board in speed mode already and I measured 1.098V.

The only thing I'm guilty of is running timing analysis in typical mode instead of worst mode. Otherwise I don't achieve timing closure, running the design at 50 MHz.

Still, the CologneChip board uses capacitors with much higher capacitance, not only for the core voltage but also for the IP banks and SERDES.

Best regards

#2

FPGA / Re: Stability Issue with GateM...

Last post by LubOlimex - Today at 08:45:23 AM

Hello,

Can you check how is the VDD_CORE_SET1 jumper set? Is it as per default in position 2-1? Position 2-1 is "economy mode" and sets the voltage of the VDD core to 1.0V. This jumper is the rightmost at the bottom, just next to the UEXT1 connector.

Try to change it to position 3-2 (e.g. move it to the left two pins). This is "speed mode" and raises the voltage of the VDD core to 1.1V. Then test again.

Let me know if that fixes the issue.

Best regards,
Lub/OLIMEX

#3

FPGA / Stability Issue with GateMateA...

Last post by charon030 - Today at 12:01:13 AM

Hi,

My FPGA design becomes unstable when I fill the FPGA like 50% with a compute intensive design and have varying loads.

I was wondering whether the power supply could cause this an checked the schematic. I found that the capacitors on the VDD pins are much smaller than what CologneChip is using in their Evaluation board. For instance, Olimex uses plenty of 1nF capacitors which seems very optimistic from my point of view.
The chain of capacitors being 2.2uF, 100nF, multiple 1nF.
In contrast the CologneChip board:
2.2uF, 470nF, 2x 100nF, 2x 10nF.

Could this be causing the issues I'm seeing?

I didn't use the SERDES yet, but also for the VDD_SER, the difference in dimensioning the capacitors is huge.

Thanks

#4

A64 / Re: Debian GNU/Linux 13 (Trixi...

Last post by Roman - May 04, 2026, 12:20:37 PM

1. If we could do it, we would but as it is we focused solely on Olimage Linux, the main problem is the audio and video support. They contain some blobs that will never be accepted by mainline and when a customer buys a board with HDMI connector and audio jack he expects to see video output and audio output.

If you mean that HDMI video used to be broken, there must have been progress upstream because it works now "out-of-the-box". Stereo output over audio jack works as well. Neither require any proprietary blobs with deblobbed Linux-libre on Guix System. However, Olimage also enables HDMI audio output. linux-sunxi wiki indicates effort to implement HDMI audio in mainline, so it must be incomplete indeed.

Anyway, your explanation is very helpful. I make the following conclusions from it.

• The new devicetree files are not new devicetrees, but a duplication in order to separate local development and configuration from upstream.
• There are local changes which are not relevant to upstream, such as HDMI audio support.
• There are local changes that are relevant to upstream but were not upstreamed by Olimex due to the developers' focus on Olimage, such as setting RX delay.
• There may be local changes which may or may not be relevant to upstream, such as changes in voltages.

I will probably focus on resolving the RX delay issue for now. It is relatively clear and affects ability to install other distributions due to downloads stalling and breaking.

2. Yes, latest image should work with all older revisions of the board.

Assuming that you do not receive reports of older revisions of the board experiencing Internet issues after RX delay was added to devicetrees in Olimage, I deduce that it must have been declared or implied in another place before that, possibly in the driver. I notice that RGMII modes were implemented for the driver the preceding year (2020). So, it must have been a change in the kernel that required setting the RX delay, not a change in the board itself.

3. We do that in our images. We read the EEPROM. EEPROM is prepared during testing.

It is useful to know that the value is populated during testing. So, the heuristics in the SPL in Olimage for determining the revision based on RAM, SPI, and eMMC sizes are probably a fallback.

I noticed a function querying the EEPROM for revision, but I do not see it being used for A64-OLinuXino. I conclude that it should not be necessary to take the revision of A64-OLinuXino into account for its proper configuration.

4. There is but maintainers are lazy and it is probably incomplete: https://images.olimex.com/changelog.txt

However, all changes can be seen at the GitHub sources for the u-boot, kernel, etc.

Unfortunately, the commit description from May 18, 2023 does not explain why the change was necessary.

Code Select Expand

dts: a64: emac: add rx-delay
But, per the Olimage changelog, the commit coincides with an update to Linux kernel 5.10.23 in images 20210318-122357 on 2021-03-18, which reinforces my conclusion that the change must have been due to a change in the kernel.

#5

ESP32 / Re: ESP32-POE-ISO-EA-16MB full...

Last post by LubOlimex - May 04, 2026, 11:00:47 AM

Nice, thank you for sharing it! Pretty neat job!

It'd be great if I could update it with a rev M external antenna board. For bonus points, do you have the external antenna modeled as well?

I am not sure if I understand the first request. Do you want me to export the hardware revision M board, it is pretty much the same and the ESP32e module has the same size just a provision for the u.FL connector.

We don't have a 3D model for the antenna, we purchase it and the manufacturer didn't share one. But these are pretty generic antennas I am sure there should be one available somewhere online.

[It'd be great if I could update it with a rev M external antenna board. For bonus points, do you have the external antenna modeled as well?]

#6

ESP32 / Re: ESP32-POE-ISO-EA-16MB full...

Last post by Ol!mexGoody - May 02, 2026, 08:34:43 PM

Thanks!

It 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/

I didn't want to make a box, rather an AV rack mount.

Here is the finished project.

https://www.printables.com/model/1701766-parametric-olimex-esp32-poe-iso-ea-av-rack-mount-1

It'd be great if I could update it with a rev M external antenna board. For bonus points, do you have the external antenna modeled as well?

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.

Yeah, I tried exporting from KiCad, but like I said I kept running into export errors.

#7

ESP32 / Re: ESP32-POE-ISO-EA-16MB full...

Last post by Ol!mexGoody - May 02, 2026, 08:28:46 PM

@faraz, Are you kidding me!? Start your own post!

#8

A64 / Status of CVE-2026-31431

Last post by mossroy - May 01, 2026, 10:37:09 AM

Are Olinuxino devices affected by this serious kernel vulnerability?

https://copy.fail/

The kernel module algif_aead is enabled by default on my Olinuxino A64 devices (installed with bullseye official image from Olimex).

For now, I've applied the workaround of disabling algif_aead kernel module.

#9

New Products release / TuxCon 2026 is approaching!

Last post by olimex - April 28, 2026, 02:40:20 PM

Join the open-source community on May 16–17 in Plovdiv for a free conference dedicated to Linux, open hardware, and open-source software.

14 Talks and 2 Workshops: May 16
Soldering Workshop : May 17

Free entry.
Whether you're into embedded, IoT, or FOSS—this is the place to be.

More info: https://tuxcon.mobi
#TuxCon #OpenSource #FOSS #Linux #Plovdiv

#10

A64 / Re: Microphone noise with USB ...

Last post by LubOlimex - April 28, 2026, 08:43:33 AM

There is some logic behind this happening, what you can easily try is use extension USB cable so that the USB-WIFI adapter is not plugged next to the board and away from the microphone. Using extension cable will help you determine where the distortion comes from empirically.