Unable to generate DMA controller IP core in CI/CD build pipeline due to libgtk display issue

Hello all,

I’m trying to modify the baremetal DMA example [1] to have a data producer write directly to DDR memory. I began by just cloning the repo in [1], downloading the CI/CD build artifacts, and changing the gateware on the beagle. I could see the new memory access gateware in the device tree and run the uio-dma-interrupt script to test the PL SRAM and DDR memory access successfully.

I wrote a TCL script to generate a modifed FIC_0_PERIPHERALS smartdesign that looks like this:

I then edited my_custom_fpga_design.yaml to specify that the FIC_0_PERIPHERALS smartdesign with the DMA controller be built and connected to the MSS. At this point, the CI/CD script fails [2] with the following error messages:

...
Reading file '/home/beagle/builds/UqLYJU_q/home/beagle/Microchip/common/vault/Components/Actel/DirectCore/COREAXI4DMACONTROLLER/2.2.107/fs/p1f7/Standalone/tgi/executables/linux/CoreAXI4DMAGenerator.exe: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory
...
Error:  Generator 'LINGENERATOR' for instance 'DMA_CONTROLLER_0' of 'Actel:DirectCore:COREAXI4DMACONTROLLER:2.2.107' failed.
Error:  Unable to generate design "DMA_CONTROLLER" due to errors.
        Generation of hardware IP core(s) failed.
        
         [OK]
Error:  Could not configure component 'DMA_CONTROLLER'.
Error:  The command 'create_and_configure_core' failed.

After googling this, I found the reason for the failure [3]:

Certain IP Cores (i.e. CoreFIFO) in Libero catalog require a monitor or DISPLAY setting variable to be set in order to configure them via TCL. These older cores still use gfx (simple C library for graphics) when called to configures cores even in a TCL flow.
Use the below command to set the Display variable on a Linux machine:
export DISPLAY=:0.0
echo $DISPLAY=:0.0
Above solution may not work on a Linux Machine when there is no display hardware, and no physical input devices present. Use following workaround:
The Xvfb Package for Linux provides an X server that can run on machines with no display hardware and no physical input devices. It emulates a dumb framebuffer using virtual memory.
When running on a Linux system with no display hardware you can install the xvfb package on the machine:
Ie. For Ubuntu: sudo apt install xvfb
Then execute the following command:
nohup Xvfb :99 > /dev/null 2>&1 &
export DISPLAY=:99
Once this is done the cores can be built in a TCL flow on a Linux Machine with no display hardware and no physical input devices.

Following the post, I modified my CI/CD pipeline to export the display variable and echo it to the terminal, but the script still fails to generate the DMA controller core because of the libgtk issue.

My questions are therefore:

  1. Why does the gateware (including the DMA controller) build without issue when not specified in the my_custom_fpga_design.yaml file? Does the DMA controller IP core not have to be generated and configured to be added to the device tree?
  2. Has anyone encountered this error with the CI/CD build before? I looked through the forums and could not find another instance of anyone running into this issue
  3. Is there a way to add the xvfb to the build stage somehow to test if this solves the issue?

I guess I can just use my local installation of Libero to build the project from the TCL script since that seems to work, but I’d rather not deal with Libero if I can help it…

Sorry for the long post, and thanks in advance for any help with this.

[1] https://forum.beagleboard.org/t/polarfire-soc-linux-examples-dma-test-on-beaglev-fire/38980
[2] https://openbeagle.org/amitra/gateware/-/jobs/50609
[3] Microchip Lightning Support

I do NOT have the board you are referring to and don’t have a clue in the world what is going on with the V board.

Can tell you the env variable

for x and gtk+3

$export DISPLAY=:0

Wayland

$export WAYLAND_DISPLAY=/run/wayland

Not sure what the :0.0 is unless it is specific to your V board.

Hi and thanks for your reply.

Not sure what the :0.0 is unless it is specific to your V board.

To be clear, I’m just following the instructions from Microchip themselves. The CI/CD pipeline also does not work with just export DISPLAY=:0, either.

This isn’t a board-related issue, but rather a toolchain issue. It seems as though Libero will not be able to create certain IP cores on headless machines without to aforementioned workarounds.

That would be assumed to be correct, also make sure that is numeral zero not letter O.

Sorry, I was not able to help you on this. Hope you get it running.

Might try a

$pstree

And see exactly what is running.

@ammitra give me a few minutes.

voodoo@bbbio-ci-ubuntu-2004-0:~$ sudo apt install xvfb
[sudo] password for voodoo: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
xvfb is already the newest version (2:1.20.13-1ubuntu1~20.04.18).
0 upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
voodoo@bbbio-ci-ubuntu-2204-0:~$ sudo apt install xvfb
[sudo] password for voodoo: 
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following NEW packages will be installed:
  xvfb
0 upgraded, 1 newly installed, 0 to remove and 11 not upgraded.
Need to get 864 kB of archives.
After this operation, 2,294 kB of additional disk space will be used.
Get:1 http://192.168.1.10:3142/us.archive.ubuntu.com/ubuntu jammy-updates/universe amd64 xvfb amd64 2:21.1.4-2ubuntu1.7~22.04.12 [864 kB]
Fetched 864 kB in 1s (962 kB/s)
Selecting previously unselected package xvfb.
(Reading database ... 191293 files and directories currently installed.)
Preparing to unpack .../xvfb_2%3a21.1.4-2ubuntu1.7~22.04.12_amd64.deb ...
Unpacking xvfb (2:21.1.4-2ubuntu1.7~22.04.12) ...
Setting up xvfb (2:21.1.4-2ubuntu1.7~22.04.12) ...
Processing triggers for man-db (2.10.2-1) ...

Sorry, yeap was missing on the newer “2204” ci’s…

Regards,

@RobertCNelson Thanks for updating the runners to have that package. I modified my CI/CD yaml script, but unfortunately the issue persists in the job. I would just use python create_release.py to build the gateware locally (which is what’s run in the pipeline), but unfortunately there is a riscv compiler issue that’s present on my local machine even after multiple fresh installs of Libero (on Ubuntu 24.04) that forces me into the CI/CD pipeline.

Have you ever run into this issue before? In the earlier beagle-v fire example I built off of, the build completed successfully so long as the CI/CD pipeline was not asked to build this gateware component directly. I’m not sure how the previous author managed to get it working, but unfortunately I’ve been unsuccessful, even when cloning their repo directly.

Sorry for the hassle, and thanks a lot for the reply!

Hi, I’ve seen this error before! I think those IP configurators use a very old X11 library for some reason. Installing that should get that working.

You need to install softconsole for those risc-v libraries, instructions are present on docs.beagleboard.org

You can find the working DMA example right here too Zain Siddavatam / memory-access-gateware · GitLab