Recent posts

#51

FPGA / Re: Stability Issue with GateM...

Last post by charon030 - May 06, 2026, 11:13:21 AM

Hi,
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

#52

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

Last post by LubOlimex - May 06, 2026, 10:39:40 AM

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

#53

FPGA / Re: Stability Issue with GateM...

Last post by LubOlimex - May 06, 2026, 08:50:50 AM

Can 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.

#54

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

Last post by Roman - May 05, 2026, 11:02:44 PM

Here is the devicetree overlay which I am currently using in order to fix the Ethernet download issue. I am using it together with sun50i-a64-olinuxino-emmc.dtb devicetree on Guix System originating from the mainline Linux. It should work on Debian too. If you try the overlay, please share how it goes and which revision of the board you use. Choose one of the two devicetrees which Debian ships depending on whether your board has eMMC or not.

Code Select Expand

/dts-v1/;
/plugin/;

/ {
    compatible = "allwinner,sun50i-a64";

    fragment@0 {
        target-path = "/soc/ethernet@1c30000";
        __overlay__ {
            allwinner,rx-delay-ps = <200>;
        };
    };
};
You can build it with dtc.

Code Select Expand

$ dtc -@ -I dts -O dtb -o sun50i-a64-rx-delay.dtbo sun50i-a64-rx-delay.dts
You should put it somewhere where the bootloader can find it, possibly in /boot, and configure the bootloader to apply it.

#55

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

Last post by Ol!mexGoody - May 05, 2026, 05:48:17 PM

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.

Yes, the revision M board (less important) with the U.FL connector instead of the PCB antenna (more important)

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.

OK, thanks.

#56

FPGA / Re: Stability Issue with GateM...

Last post by charon030 - May 05, 2026, 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

#57

FPGA / Re: Stability Issue with GateM...

Last post by LubOlimex - May 05, 2026, 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

#58

FPGA / Stability Issue with GateMateA...

Last post by charon030 - May 05, 2026, 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

#59

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.

#60

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 ESP32-WROOM-32UE module cuts at the PCB edge and has a provision for the u.FL connector.

Edit 06.05 - the ESP32-WROOM-32UE is actually shorter and cuts at PCB's edge.

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.