Ultra96-v2: Add a new community support board

[pimartos]

Hi, I would like to add the ultra96-v2 board to the list of community supported boards because it's popular, so more people could contribute to the ROS 2 HAWG

regards, Pedro

[vmayoral]

Thanks @pimartos, as pointed out at https://discourse.ros.org/t/announcing-the-hardware-acceleration-wg-meeting-1/20826/6?u=vmayoral, it should be fairly easy and consist basically on creating the firmware artifacts required for the new board and organizing them in a structured manner so that the hooks we've created for the ROS 2 meta build system and meta build tools pick the board automatically.

This way, it'll become transparent and seamless to anyone willing to re-use this or any other board (while we ensure a somewhat organized extensibility)

It'll take a few weeks but expect me to push to the community README instructions on how to include new boards.

[pimartos]

Hi, Ok, thanks. May I help in some way? I have a Ultra96-V2 board so I can do some tests if you need.

regards, Pedro

[vmayoral]

Ok, thanks. May I help in some way? I have a Ultra96-V2 board so I can do some tests if you need.

@pimartos to follow up on this, instructions to proceed with the port is somewhat reflected in https://github.com/ros-infrastructure/rep/pull/324. An example firmware repo is available at https://github.com/ros-acceleration/acceleration_firmware_kv260.

I'm pushing this back to you. Feel free to launch questions in here if you have any specific ones.

[pimartos]

Hi, Ok, I will work with 0.6.0 (last time I checked v0.6.0 was in alpha, good to see that is prerelease) :-)

[vmayoral]

That's right! 0.6.0 was shipped in KRS's alpha. Ping me if you struggle with anything.

[pimartos]

Ok, my path should be 1) Install KRS and its dependencies 2) Build examples (Unfortunatelly I cann't test it with real hardware) 3) Create a repo acceleration_firmware_Ultra96V2 4) Port acceleration_firmware_kv260 to target Ultra96V2 5) Build the examples using ultra96v2 firmware 6) Integrate to KRS. Do you agree with this?

[vmayoral]

@pimartos that's an awesome first list. Thanks for puting it together. So that it can be translated to others, my recommendation for the official adding new boards to HAWG should be as follows:

1. Check out the Initial draft of REP-2008 - ROS 2 Hardware Acceleration Architecture and Conventions
2. Create your own firmware repository (e.g. acceleration_firmware_Ultra96V2) for the corresponding board (see acceleration_firmware_kv260 for an example)
3. Once the firmware repo is finalized, assess the capabilities of the hardware according to REP-2008 and create a table in the README.md that argues about it (see example here)
4. Submit a PR to ros-acceleration/community to add your board to the community, with the corresponding support level according to REP-2008

---

Aligned to this, regarding your suggested path above:

1) Install KRS and its dependencies 2) Build examples (Unfortunatelly I cann't test it with real hardware)

I not done already, I would really encourage you to review REP-2008 PR, familiarize with it and send feedback.

I think installing KRS and playing a bit with the examples with it will indeed help you familiarize with the architecture. Note you can launch some examples using emulation targets, so no real need for the KV260 hardware to evaluate this.

3) Create a repo acceleration_firmware_Ultra96V2 4) Port acceleration_firmware_kv260 to target Ultra96V2

Yeap, correct.

5) Build the examples using ultra96v2 firmware

Correct.

6) Integrate to KRS.

This last step is not needed. Instead, I think we could simply submit a PR to ros-acceleration/community to add your board to the community, with the corresponding support level according to REP-2008.

Let me know if you need further clarifications @pimartos.

[kscharan]

Hello @pimartos , I have an Ultra96-V2 board with me. Is there anything I can contribute to here?

[pimartos]

Hello @pimartos , I have an Ultra96-V2 board with me. Is there anything I can contribute to here?

Hi, I am starting, I installed ros and krs and I am triying to build the examples. If you didn't do it yet, do the same, so we can have a build enviaron mente

Regards, Pedro

[pimartos]

Let me know if you need further clarifications @pimartos. @vmayoral, hi, I installed KRS and downloaded the examples (I openend an issue about not having vitis_common). I am not able to build the samples, I receive this error:

$ colcon build --build-base=build-kv260 --install-base=install-kv260 --merge-install --mixin kv260 --packages-select ament_vitis vadd_publisher

Starting >>> ament_vitis Finished <<< ament_vitis [0.18s]
Starting >>> vadd_publisher --- stderr: vadd_publisher
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message): The C compiler

"/tools/Xilinx/Vitis/2021.1/gnu/aarch64/lin/aarch64-linux/bin/aarch64-linux-gnu-gcc"

is not able to compile a simple test program.

It fails with the following output:

Change Dir: /home/usuario/krs_ws/build-kv260/vadd_publisher/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/make cmTC_44b65/fast && /usr/bin/make -f CMakeFiles/cmTC_44b65.dir/build.make CMakeFiles/cmTC_44b65.dir/build
make[1]: se entra en el directorio '/home/usuario/krs_ws/build-kv260/vadd_publisher/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_44b65.dir/testCCompiler.c.o
/tools/Xilinx/Vitis/2021.1/gnu/aarch64/lin/aarch64-linux/bin/aarch64-linux-gnu-gcc --sysroot=/home/usuario/krs_ws/install/../acceleration/firmware/kv260/sysroots/aarch64-xilinx-linux    -o CMakeFiles/cmTC_44b65.dir/testCCompiler.c.o   -c /home/usuario/krs_ws/build-kv260/vadd_publisher/CMakeFiles/CMakeTmp/testCCompiler.c
Linking C executable cmTC_44b65
/usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_44b65.dir/link.txt --verbose=1
/tools/Xilinx/Vitis/2021.1/gnu/aarch64/lin/aarch64-linux/bin/aarch64-linux-gnu-gcc --sysroot=/home/usuario/krs_ws/install/../acceleration/firmware/kv260/sysroots/aarch64-xilinx-linux      CMakeFiles/cmTC_44b65.dir/testCCompiler.c.o  -o cmTC_44b65 
/tools/Xilinx/Vitis/2021.1/gnu/aarch64/lin/aarch64-linux/x86_64-petalinux-linux/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-ld.real: cannot find crtbeginS.o: No such file or directory
/tools/Xilinx/Vitis/2021.1/gnu/aarch64/lin/aarch64-linux/x86_64-petalinux-linux/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-ld.real: cannot find -lgcc
collect2.real: error: ld returned 1 exit status
make[1]: *** [CMakeFiles/cmTC_44b65.dir/build.make:87: cmTC_44b65] Error 1
make[1]: se sale del directorio '/home/usuario/krs_ws/build-kv260/vadd_publisher/CMakeFiles/CMakeTmp'
make: *** [Makefile:121: cmTC_44b65/fast] Error 2

CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:2 (project)

---

Failed <<< vadd_publisher [1.08s, exited with code 1]

Summary: 1 package finished [1.42s] 1 package failed: vadd_publisher 1 package had stderr output: vadd_publisher

I suspect that the problem is that I don't have kv260 bsp files installed; I downloaded it from xilinx, but I am not able to install it using petalinux-upgrade
By the way, the downloaded bsp file is "xilinx-k26-starterkit-v2021.1-final.bsp"; but it seems to be a gzipped file. How should I deal with it? Thanks in advance for your support

best regards,
Pedro

[vmayoral]

@pimartos it indeed seems like you are not installing kv260 files appropriately.

Can you confirm you're following the 6 steps at https://xilinx.github.io/KRS/sphinx/build/html/docs/install.html appropriately? I uploaded a video to help navigate the process, have a look.

Also, to debug your setup, inspect the following:

colcon acceleration list  # this should list the deployed firmware resources
                          # you should see at least 'kv260' listed

Also, manually, have a look at the following directory <your-workspace>/acceleration/firmware/kv260. Ensure all firmware files are there.

Note the process of installing (https://xilinx.github.io/KRS/sphinx/build/html/docs/install.html) and running a first example (https://xilinx.github.io/KRS/sphinx/build/html/docs/examples/1_hello_xilinx.html) are detailed in KRS documentation.

[vmayoral]

I suspect that the problem is that I don't have kv260 bsp files installed; I downloaded it from xilinx, but I am not able to install it using petalinux-upgrade

No need to use PetaLinux for evaluating KV260 (though you'll will need to rely on it for building the firmware files of Ultra96v2, but with its corresponding BSP). I specifically pushed for abstracting Yocto/PetaLinux aspects from the user.

By the way, the downloaded bsp file is "xilinx-k26-starterkit-v2021.1-final.bsp"; but it seems to be a gzipped file. How should I deal with it? Thanks in advance for your support

Not sure what you mean by this, as pointed out above. You don't need to use anything else but KRS's instructions for getting up to speed. PetaLinux BSP for KV260 is already abstracted within https://github.com/ros-acceleration/acceleration_firmware_kv260. It's made this way so that embedded expertise is avoided in the process.

[pimartos]

Hi @vmayoral Yes, I can do the install without problem (it builds all 14 packages); I have the files under /acceleration/firmware/kv260; and colcon acceleration list gives kv260* The problem is when I try to build the first sample (0: ROS 2 Publisher); when I try to build the package with (as stated in the sample):

colcon build --build-base=build-kv260 --install-base=install-kv260 --merge-install --mixin kv260 --packages-select ament_vitis vadd_publisher

I get the mentioned output Googling about "cannot find crtbeginS.o: No such file or directory"; gives me answer record 73705 (https://support.xilinx.com/s/article/73705?language=en_US); thats the reason that I suspected a petalinux issue; but if all the petalinux stuff is inside firmware, I don't know where could be the problem. :-(

[vmayoral]

From what you've shared @pimartos, it seems cross-compilation is failing because it doesn't find the right resources (this one hints about missing ones in the sysroot). This, again, goes back to firmware not properly deployed. I experienced issues like those in the past while developing, when firmware wasn't properly installed.

https://github.com/Xilinx/KRS/issues/10 confirmed a few hours ago that he built successfully with the latest changes.

My recommendation will be to start over with the instructions. Clean up the workspace and start over. There's probably something wrong in your ROS 2 workspace and firmware deployment. So that the experience is useful for debugging, can you do it while asciinema-yourself? Share back in here a link to the recording if it still fails.

[pimartos]

@vmayoral finally I solved it; I was using vitis 2021.1 (because I wanted to try vitis AI), I installed vitis 2020.2 and the first example compiled. When I tried to generate the sdcard (just to check that it is possible), the sd_card.img file was generated, but I had this message:

$ colcon acceleration linux vanilla --install-dir install-kv260
SECURITY WARNING: This class invokes explicitly a shell via the shell=True argument of the Python subprocess library, and uses admin privileges to manage raw disk images. It is the user's responsibility to ensure that all whitespace and metacharacters passed are quoted appropriately to avoid shell injection vulnerabilities.
- Creating a new base image using /home/usuario/krs_ws/acceleration/firmware/select/rootfs.cpio.gz ...
[sudo] contraseña para usuario: 
mkfs.fat: warning - lowercase labels might not work properly with DOS or Windows
- Image successfully created
- Confirmed availability of raw image file at: /home/usuario/krs_ws/acceleration/firmware/select/sd_card.img
[25.389s] ERROR:colcon:colcon acceleration: can only concatenate str (not "NoneType") to str
Traceback (most recent call last):
  File "/usr/lib/python3/dist-packages/colcon_core/command.py", line 528, in verb_main
    rc = context.args.main(context=context)
  File "/home/usuario/krs_ws/install/lib/python3.8/site-packages/colcon_acceleration/subverb/linux.py", line 466, in main
    mount_rawimage(rawimage_path, 1)
  File "/home/usuario/krs_ws/install/lib/python3.8/site-packages/colcon_acceleration/subverb/__init__.py", line 395, in mount_rawimage
    "Something went wrong while fetching the raw image UNITS.\n"
TypeError: can only concatenate str (not "NoneType") to str

Should I discard it?

UPDATE: I found what was that "Something went wrong while fetching the raw image UNITS.\n" error.... I have a spanish (latin america) ubuntu install, so the output of fdisk is "Unidades" not "Units"; so the script fails because search for the string "Units" and the output is in spanish "Unidades". What should be the best way to manage this?

[pimartos]

@vmayoral With the spanish "Unidades" in .py scripts, Now I can build sd_card-img for Hello Xilinx, but when I try to run in the emulator with $ colcon acceleration emulation sw_emu install-kv260 I get:

SECURITY WARNING: This class invokes explicitly a shell via the shell=True argument of the Python subprocess library, and uses admin privileges to manage raw disk images. It is the user's responsibility to ensure that all whitespace and metacharacters passed are quoted appropriately to avoid shell injection vulnerabilities.
- Verified that install/ is available in the current ROS 2 workspace
- Confirmed availability of raw image file at: /home/usuario/krs_ws/acceleration/firmware/select/sd_card.img
- Finished inspecting raw image, obtained UNITS and STARTSECTOR P1/P2
- Image mounted successfully at: /tmp/sdcard_img_p2
- Successfully cleaned up prior overlay ROS 2 workspace at: /tmp/sdcard_img_p2/ros2_ws
- Copied 'install-kv260' directory as a ROS 2 overlay workspace in the raw image.
- Umounted the raw image.
- Generated PMU and QEMU files.
- Launching emulation...
cd /home/usuario/krs_ws/acceleration/firmware/select/emulation && /tools/Xilinx/Vitis/2020.2/bin/launch_emulator -device-family ultrascale -target sw_emu -qemu-args-file /home/usuario/krs_ws/acceleration/firmware/select/emulation/qemu_args.txt -pmc-args-file /home/usuario/krs_ws/acceleration/firmware/select/emulation/pmu_args.txt -sd-card-image /home/usuario/krs_ws/acceleration/firmware/select/sd_card.img -enable-prep-target $*
Running SW Emulation
INFO :  [LAUNCH_EMULATOR] pl_sim_dir option is not provided.
Starting QEMU
 - Press <Ctrl-a h> for help 
Waiting for QEMU to start. qemu_port 9194
Qemu_pids 87327 87328
qemu-system-aarch64: -chardev socket,path=./qemu-rport-_pmu@0,server,id=pmu-apu-rp: info: QEMU waiting for connection on: disconnected:unix:./qemu-rport-_pmu@0,server
QEMU started. qemu_pid=87327.
Waiting for PMU to start. Qemu_pids 87331 87332
qemu-system-aarch64: -chardev socket,id=pl-rp,host=127.0.0.1,port=7495,server: info: QEMU waiting for connection on: disconnected:tcp:127.0.0.1:7495,server
PMC started. pmc_pid=87331
Starting PL simulation.Generating PLLauncher commandline
running PLL Launcher
qemu-system-aarch64: Could not set up host forwarding rule 'tcp:127.0.0.1:2222-10.0.2.15:22'
qemu-system-microblazeel: /pmu@0: Disconnected clk=3915984112 ns

[LAUNCH_EMULATOR] INFO: 22:41:43 : PMU/PMC-QEMU  exited
[LAUNCH_EMULATOR] INFO: 22:41:45 : PS-QEMU exited
[LAUNCH_EMULATOR] INFO: 22:41:45 : PMU/PMC-QEMU exited
[LAUNCH_EMULATOR] INFO: 22:41:45 : Trying to kill PLLauncher forcefully because QEMU exited
[LAUNCH_EMULATOR] INFO: 22:41:45 : PLLauncher exited by force
Please refer PS /simulate logs at /home/usuario/krs_ws/acceleration/firmware/kv260/emulation for more details.
DONE!
INFO: Emulation ran successfully
Finalized successfully.

How can I solve this error? qemu-system-aarch64: Could not set up host forwarding rule 'tcp:127.0.0.1:2222-10.0.2.15:22' Thanks in advance for your help

UPDATE: It was a qemu issue, it was working as daemon since I was working with a bad image because the spanish "Unidades" issue, killed and restarted and I was able to run Hello Xilinx in emulated mode, so if something goes bad with qemu, is necessary to kill the process...

[vmayoral]

@pimartos, glad to see the progress! Thanks for the updates and for answering your hurdles, that helps a lot future users. I took the liberty of slightly editing your comments using Markdown syntax. Feel free to have a look at it, it may help the readibility of future queries.

Regarding:

I found what was that "Something went wrong while fetching the raw image UNITS.\n" error.... I have a spanish (latin america) ubuntu install, so the output of fdisk is "Unidades" not "Units"; so the script fails because search for the string "Units" and the output is in spanish "Unidades". What should be the best way to manage this?

Shame on me for not having considered this given that I'm from Spain! This is coded in the colcon-acceleration extensions. Particularly, Units is fetched in https://github.com/ros-acceleration/colcon-acceleration/blob/main/colcon_acceleration/subverb/__init__.py#L389 and https://github.com/ros-acceleration/colcon-acceleration/blob/main/colcon_acceleration/subverb/__init__.py#L661. A quick fix is to support both languages by extending the grep from grep 'Units' to grep "[Unidades|Units]". This would do for now but a better way forward would be to add a language-agnostic one, so that regardless the system preferences it'll work.

This is a good first contribution. @pimartos would you like to make the changes yourself and submit a Pull Request?

[pimartos]

This is a good first contribution. @pimartos would you like to make the changes yourself and submit a Pull Request?

OK, I will do it :-D Now I can start porting :-) (Should I modify something in the header of the files? Add a contribution under author?)

[vmayoral]

@pimartos I took a look at https://github.com/ros-acceleration-ultra96v2 in search for updates regarding this effort. Do you think you could join us this Wednesday at the HAWG meeting and give a short update?

If not, could you share with in here some notes so that I discuss it with the rest of the group?

[pimartos]

Hi Victor, I have all the intention to be in the meeting, but unfortunately there is a chance that I have another meeting at the same time because of my work, so I will give you a status of the ultra96:

I started cloning all the hw-acceleration repositories because I thought that it would be necessary to touch them to make the port to ultra96, but looking at the examples, the “hello Xilinx” example works in two different boards, so there is no need to touch the repositories and all the information should be inside accelerationfirmware.

So I downloaded the zip files acceleration_firmware_kv260 and acceleration_firmware_zcu102 and made a diff to see what files to touch. There are about 1900 files in each acceleration_fimware, but only 81 files are different. About 10 of them are the configuration files that need to be adapted to build for ultra96, the rest of the files are the PS system hardware description, boot files, kernel files, and linux filesystem files. I will start porting from the acceleration_firmware_zcu102 because those boards use parts from the same family (ultra96 uses ZU3EG and zcu102 uses ZU9EG).

Currently I am blocked because I need Petalinux to build the ultra96 version of the linux files, but Petalinux needs about 50/100 GB of disk space, I have 20GB in my laptop, but isn’t enough space, I tried to make the Petalinux temporary working directory in an external drive, but the build process hangs when I do this (When I build using only my laptop’s disk, the build process ends because it runs out of disk space). I also tried to fetch the files from a ultra96 boot image in sdcard, but the image files from avnet use the elf format for the files and I need the bin format, so I need to build them from the BSP using Petalinux

Yesterday I installed vitis/vivado/Petalinux in another machine with a 1TB disk, but the build process still hangs (probably I missed something in the install process, I did it at 10pm). In this week I am planning to build the Petalinux image in the 1TB machine (as soon as I discover why the build process hangs in the new workstation) and generate the ultra96 version of the linux files. Then I will modify the configuration files to make the build for ultra96 and see if I can run the hello Xilinx example in ultra96 in hardware or emulated mode

Hope to see you in the meeting Pedro

[vmayoral]

Thanks for the update @pimartos!

[vmayoral]

@pimartos, now that I've processed a bit slower your update, here's a bit of feedback:

I started cloning all the hw-acceleration repositories because I thought that it would be necessary to touch them to make the port to ultra96, but looking at the examples, the “hello Xilinx” example works in two different boards, so there is no need to touch the repositories and all the information should be inside accelerationfirmware.

Indeed 👍. There's no need to duplicate everything. The only thing needed is the acceleration_firmware_ultra96v2 repo. Happy to create that for you in this organization and give you privileges if that helps.

Yesterday I installed vitis/vivado/Petalinux in another machine with a 1TB disk, but the build process still hangs (probably I missed something in the install process, I did it at 10pm). In this week I am planning to build the Petalinux image in the 1TB machine (as soon as I discover why the build process hangs in the new workstation) and generate the ultra96 version of the linux files. Then I will modify the configuration files to make the build for ultra96 and see if I can run the hello Xilinx example in ultra96 in hardware or emulated mode

Fantastic progress! Sounds like we're getting there. Please keep in mind while installing Vitis to use version 2020.2.2, this is the one we're currently using for development and what's best to remain aligned.

[pimartos]

Hi @vmayoral An update of the status: Finally I managed to get the ultra96 version of the linux files (I think so). I have a bootable sdcard made from the avnet ultra96 BSP and I builded it locally with Petalinux, so I will start porting the configuration files and try to build acceleration_firmware_ultra96v2. As soon as I have a working build, I would ask for the repository in the organization.

For the brave of heart that want to go with Petalinux: The build used 70 GB of disk space. So I had to use an external USB 3 drive with a linux ext4 partition, with a Windows FAT32/NTFS partitions the build hangs because the massive file transfers (is around 500.000 files). My workstation is a i7 10th gen with 32 GB RAM using Ubuntu 20.04 and the build took 12 hours, so use a 8-core machine, the script starts one build process for each core available . Half of the build time was chromium build, so it would be great to disable it (I will investigate how to do it). A very stable internet connection is needed also (if the script fails to get a source, the process hangs), so forget wifi and use a wired connection.

I obtained the ultra96v2 BSP from here

To build I followed UG1144, but for the petalinux build command, you need to specify the avnet image with this command:

petalinux-build -c avnet-image-minimal

If you use only petalinux-build the build hangs two hours later...

To make the sdcard, I followed the instruccions from here starting from the boot image build command (BOOT.BIN, using petalinux-package...), but is necessary to make bootable the boot partition (I used gparted to do that) and add the boot.scr file to the boot partition, so I used the command.

sudo cp ./images/linux/boot.scr /media/<path-to-the-boot-partition-mount-point>/BOOT/

after the other cp commands.

Petalinux works like Gentoo Linux, it builds everything from sources, that’s the reason for the massive file transfers, the amount of disk space needed, and the time to build. If someone tries to replicate the process, I will very happy to help.

[vmayoral]

An update of the status: Finally I managed to get the ultra96 version of the linux files (I think so). I have a bootable sdcard made from the avnet ultra96 BSP and I builded it locally with Petalinux, so I will start porting the configuration files and try to build acceleration_firmware_ultra96v2. As soon as I have a working build, I would ask for the repository in the organization.

Thanks for letting us know @pimartos and great work!

[pimartos]

Hi @vmayoral I made some progress with acceleration_firmware_ultra96v2, so I have good and bad news:

The good news: After modifying the build scripts and use the linux files from my Petalinux build, the sequence

colcon build --merge-install

source install/setup.bash

colcon acceleration select ultra96v2

colcon build --build-base=build-ultra96v2 --install-base=install-ultra96v2 --merge-install --mixin ultra96v2 --packages-select publisher_xilinx

colcon acceleration linux vanilla --install-dir install-ultra96v2

Generates the _sdcard.img image file without errors or warnings, and that file flashed in a sd card using balena etcher boots the ultra96v2 board right up to the login prompt (:-D

The bad news: 1) The image generated doesn’t have ROS inside. :-( I suspect that the problem is because Petalinux adds ROS to the rootfs file during the build, but in my Petalinux build (from avnet) I don’t have a reference for ROS. I think that because in the setup.sh script there is a static path reference to a petalinux build made with ROS for each board (each board has it’s own setup.sh with a different static reference). Am I right about that? One workaround could be to install ROS manually after booting the board; I will try it tomorrow.

2) Running a software emulation hangs qemu before booting. I suspect that the linux boot files for sd and qemu should be different (I am using the same in the boot and qemu directories inside platform) I will investigate about generate qemu linux boot files

Regards, Pedro

[vmayoral]

Thanks for the update @pimartos. Glad to hear you're now able to create images with the colcon extensions and have them working out nicely. It sounds like you set up the Vitis platform successfully and got the basic things set to build acceleration kernels.

The bad news: 1) The image generated doesn’t have ROS inside. :-( I suspect that the problem is because Petalinux adds ROS to the rootfs file during the build, but in my Petalinux build (from avnet) I don’t have a reference for ROS. I think that because in the setup.sh script there is a static path reference to a petalinux build made with ROS for each board (each board has it’s own setup.sh with a different static reference). Am I right about that? One workaround could be to install ROS manually after booting the board; I will try it tomorrow.

That's probably because you don't have ROS 2 meta-layers into your Yocto/PetaLinux project. You can add them yourself manually, that' part of the firmware enablement process, of course.

The ROS 2 yocto recipes are maintained and available at https://github.com/ros/meta-ros/tree/zeus. That's the zeus branch, because I'm guessing you're using Vitis 2020.2, but if you're using a different version, with different Yocto support, adapt as appropriate.

2) Running a software emulation hangs qemu before booting. I suspect that the linux boot files for sd and qemu should be different (I am using the same in the boot and qemu directories inside platform) I will investigate about generate qemu linux boot files

Let me help tackling this. I created acceleration_firmware_ultra96v2 for you and give you privileges. Could you push firmware to the repo following the guidelines of REP-2008 PR? The simplest thing to do is to take acceleration_firmware_kv260 as a reference example and imitate it (note that if files are above 1 GB you may want to push it all as a release).

Once that's ready, I'll find some time to reproduce your results and try helping setting up the firmware appropriately to gain additional capabilities hardware acceleration-wise.

[pimartos]

Hi @vmayoral Thanks, I will add ROS to my petalinux build. Thanks for the acceleration_firmware_ultra96v2 repository. Should I upload a .zip release as is now or could be better to add ROS first, before the upload, so in the repository will be something functional in real hardware to play with?

[vmayoral]

Thanks, I will add ROS to my petalinux build. Thanks for the acceleration_firmware_ultra96v2 repository. Should I upload a .zip release as is now or could be better to add ROS first, before the upload, so in the repository will be something functional in real hardware to play with?

I'd say, give it a try to the meta-ros layers. Here're my notes from when I enabled it in the past (they are not meant to be a tutorial, so things will likely fail since this was solely for myself). Refer to the official build instructions if you need further intuition:

some (informal) notes while setting it up

#### Fetch the meta-layers Clone [https://gitlab.com/xilinxrobotics/meta-ros](https://gitlab.com/xilinxrobotics/meta-ros) at `/project-spec/`. #### Configure ROS 2 Foxy After cloning the meta-layer (layer of layers) into a PetaLinux project, the layer can be added to the build by editing `bblayers.conf` as appropriate. For the particular example of foxy, the following sub-layers need to be enabled: ``` ${SDKBASEMETAPATH}/../../project-spec/meta-ros/meta-ros2-foxy \ ${SDKBASEMETAPATH}/../../project-spec/meta-ros/meta-ros2 \ ${SDKBASEMETAPATH}/../../project-spec/meta-ros/meta-ros-common \ ${SDKBASEMETAPATH}/../../project-spec/meta-ros/meta-ros-backports-dunfell \ ``` In addition, add the following as well to `bblayers.conf`: ```bash # define the ROS 2 Yocto target release ROS_OE_RELEASE_SERIES = "zeus" # define ROS 2 distro ROS_DISTRO = "foxy" ``` To build the ROS rootfs image as `petalinux-build` consider adding the following recipe to ``: #### Define "petalinux-image-minimal.bbappend" ```bash cd project-spec/meta-user mkdir -p recipes-images/images; cd recipes-images/images touch project-spec/meta-user/recipes-images/images/petalinux-image-minimal.bbappend ``` with content: ```bash require ${COREBASE}/../meta-petalinux/recipes-core/images/petalinux-image-minimal.bb SUMMARY = "A image including a bare-minimum installation of ROS 2 and including some basic pub/sub examples. It includes two DDS middleware implementations, FastDDS and Cyclone DDS" DESCRIPTION = "${SUMMARY}" inherit ros_distro_${ROS_DISTRO} inherit ${ROS_DISTRO_TYPE}_image ROS_SYSROOT_BUILD_DEPENDENCIES = " \ ament-lint-auto \ ament-cmake-auto \ ament-cmake-core \ ament-cmake-cppcheck \ ament-cmake-cpplint \ ament-cmake-export-definitions \ ament-cmake-export-dependencies \ ament-cmake-export-include-directories \ ament-cmake-export-interfaces \ ament-cmake-export-libraries \ ament-cmake-export-link-flags \ ament-cmake-export-targets \ ament-cmake-gmock \ ament-cmake-gtest \ ament-cmake-include-directories \ ament-cmake-libraries \ ament-cmake \ ament-cmake-pytest \ ament-cmake-python \ ament-cmake-ros \ ament-cmake-target-dependencies \ ament-cmake-test \ ament-cmake-version \ ament-cmake-uncrustify \ ament-cmake-flake8 \ ament-cmake-pep257 \ ament-copyright \ ament-cpplint \ ament-flake8 \ ament-index-python \ ament-lint-cmake \ ament-mypy \ ament-package \ ament-pclint \ ament-pep257 \ ament-pycodestyle \ ament-pyflakes \ ament-uncrustify \ ament-xmllint \ cmake \ eigen3-cmake-module \ fastcdr \ fastrtps-cmake-module \ fastrtps \ git \ gmock-vendor \ gtest-vendor \ pkgconfig \ python-cmake-module \ python3-catkin-pkg \ python3-empy \ python3 \ python3-nose \ python3-pytest \ rcutils \ rmw-implementation-cmake \ rosidl-cmake \ rosidl-default-generators \ rosidl-generator-c \ rosidl-generator-cpp \ rosidl-generator-dds-idl \ rosidl-generator-py \ rosidl-parser \ rosidl-runtime-c \ rosidl-runtime-cpp \ rosidl-typesupport-c \ rosidl-typesupport-cpp \ rosidl-typesupport-fastrtps-cpp \ rosidl-typesupport-interface \ rosidl-typesupport-introspection-c \ rosidl-typesupport-introspection-cpp \ foonathan-memory-vendor \ libyaml-vendor \ " IMAGE_INSTALL_append = " \ ros-base \ examples-rclcpp-minimal-action-client \ examples-rclcpp-minimal-action-server \ examples-rclcpp-minimal-client \ examples-rclcpp-minimal-composition \ examples-rclcpp-minimal-publisher \ examples-rclcpp-minimal-service \ examples-rclcpp-minimal-subscriber \ examples-rclcpp-minimal-timer \ examples-rclcpp-multithreaded-executor \ examples-rclpy-executors \ examples-rclpy-minimal-action-client \ examples-rclpy-minimal-action-server \ examples-rclpy-minimal-client \ examples-rclpy-minimal-publisher \ examples-rclpy-minimal-service \ examples-rclpy-minimal-subscriber \ demo-nodes-cpp \ demo-nodes-cpp-rosnative \ demo-nodes-py \ cyclonedds \ rmw-cyclonedds-cpp \ tmux \ byobu \ python3-argcomplete \ glibc-utils \ localedef \ rt-tests \ stress \ xrt-dev \ xrt \ zocl \ opencl-headers-dev \ opencl-clhpp-dev \ ${ROS_SYSROOT_BUILD_DEPENDENCIES} \ " IMAGE_LINGUAS = "en-us" GLIBC_GENERATE_LOCALES = "en_US.UTF-8" ```

[pimartos]

Hi, I am trying to build ROS inside Petalinux, but I don't have access to gitlab to clone meta-ros from there. Should I clone from https://github.com/ros/meta-ros/tree/zeus? Regards

[vmayoral]

Yes, that’s the official one. Use that one indeed. Ours is just a private fork that builds on top of the official meta-ros one and AFAIK most changes have been contributed upstream, so you’re good to go with meta-ros.

El El mié, 10 nov 2021 a las 18:34, pimartos @.***> escribió:

Hi, I am trying to build ROS inside Petalinux, but I don't have access to gitlab to clone meta-ros from there. Should I clone from https://github.com/ros/meta-ros/tree/zeus? Regards

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ros-acceleration/community/issues/1#issuecomment-965576840, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAKPYDUVLJPXQRRNEZKV7T3ULKUJZANCNFSM46KKJKUQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[pimartos]

Hi @vmayoral I included meta-ros layer in the petalinux project, I builded it (it took another 12 hours) and I have a rootfs-wic file with the root filesystem, but the rootfs.ext4 and rootfs.ext4.gz files are not created, what could I have been missed?

[vmayoral]

@pimartos, AFAIK those rootfs formats are enabled with petalinux-config (possibly with petalinux-config -c rootfs, or maybe with petalinux-config -c kernel, I don't rememer specifically).

You may have disabled them, or perhaps the recipe you're building does so. Nevertheless, I'm not using neither of those files to build the acceleration_firmware_* ROS 2 packages. See the ARTIFACTS.md file on any of the releases of either KV260 or ZCU102. I'm using the compressed rootfs CPIO image format (rootfs.cpio.gz).

Artifacts being used

| # | Artifact | Description | |---|----------|-------------| | 0 | BOARD | Text file containing the board whose firmware is in this branch. E.g. `kv260` | | 1 | kernel/Image | Linux Kernel Image version 5.4.0 from the Xilinx Linux kernel fork targeting the KV260. More specifically, a FIT image including the kernel | | 2 | kernel/Image_PREEMPT_RT_5.4.0 | Linux kernel FIT image version 5.4.0 with the PREEMPT_RT patch-5.4.10-rt4 applied (`5.4.0-rt4-xilinx-v2020.2`). | | 3 | kernel/image.ub | FIT image including the kernel, DTB and rootfs | | 4 | boot_scripts/boot.scr.default | boot script that provides U-boot commands to boot the default setup/kernel (works for both vanilla and PREEMPT_RT patched ones). Will NOT work for Xen-based systems. | | 5 | boot_scripts/boot.scr.sd | simple boot script for non-Xen raw images produced with disk_image script | | 6 | bootbin/BOOT.BIN.default | ZynqMP boot BIN file for default setup, including vanilla and PREEMPT_RT patched kernels. | | 7 | bootbin/BOOT.BIN.xen | ZynqMP boot BIN file for Xen-based setups. | | 8 | device_tree/system.dtb.default | Device-tree Blob (DTB) used for default Linux kernels (no hypervisor involved). | | 9 | device_tree/system.dtb.xen | Device-tree Blob (DTB) used for Xen-based architectures. | | 10| bl31.bin | Arm trusted firmware BIN file | | 11| bl31.elf | Arm trusted firmware ELF file | | 12| pmufw.elf | pmu firmware ELF | | 13| pxelinux.cfg | pxelinux.cfg directory with default configuration file for pxe boot | | 14| initrd.cpio | Minimalistic (only busybox) ramdisk, rootfs CPIO image | | 15| rootfs.cpio.gz | Compressed rootfs CPIO image used for FIT image (image.ub) | | ~~16~~ | ~~rootfs.ext4~~ | ~~Rootfs ext4 file with 1GB free space which can flashed to sd card ext4 partition~~ | | 17| sdk.sh | Compressed version of Yocto Project SDK to develop applications. It has sysroot of the rootfs in the tar | | 18| u-boot.bin | U-boot bin | | 19| u-boot.elf | U-boot ELF | | 20| zynqmp_fsbl.elf | First stage bootloader ELF | | 21| zynqmp-qemu-arm.dtb | qemu device-tree blob file for single arch | | 22| zynqmp-qemu-multiarch-arm.dtb | qemu device-tree blob file for multi arch and it has information of a53 and other devices | | 23| zynqmp-qemu-multiarch-pmu.dtb | qemu device-tree blob file for multi arch and it has information of microblaze nodes | | 24| data | Data for emulation. Created by `v++ -p -t sw_emu ...`. *This data for emulation seems to be specific for the architecture and agnostic to the application itself.* | | 25 | platform | Base hardware platform. See [Vitis Embedded Base Platforms](https://www.xilinx.com/support/download/index.html/content/xilinx/en/downloadNav/embedded-platforms.html) for official ones, or their corresponding [sources](https://github.com/Xilinx/Vitis_Embedded_Platform_Source). | | 26 | ramdisk.cpio.gz.u-boot | K26 specific ramdisk required to maintain the default boot flow. | Added from other Xilinx's packages: | # | Artifact | Description | |---|----------|-------------| | 27| pmu_rom_qemu_sha3.elf | PMU kernel ELF file | | 28| zynqmp-arm-cosim.dtb | ZU+ PL-PS co-simulation device-tree. *Guess* | Built artifacts that need to be patched: | # | Artifact | Description | |---|----------|-------------| | 29| lib/libfoonathan_memory-0.6.2.a | libfoonathan, required by FastRTPS. TODO, remove this DDS impl. | Other git submodules: | # | Artifact | Description | |---|----------|-------------| | 30| ipxe | the "swiss army knife" of network booting. Supports both HTTPS and iSCSI, has a script engine for fine grained control of the boot process and can provide a command shell. | | 31| imagebuilder | collection of scripts to build embedded virtualized systems with one or multiple domains. |

[pimartos]

HI @vmayoral I found the problem: in the petalinux-image-minimal.bbappend file I tried to build over avnet-image-minimal.bb but this created some kind of circular reference and the rootfs.* root file system files were not created, I changed to petalinux-image-minimal.bb and now I have the rootfs files. I am updating the _acceleration_firmwareultra96v2 with these new linux files.

[vmayoral]

HI @vmayoral I found the problem: in the petalinux-image-minimal.bbappend file I tried to build over avnet-image-minimal.bb but this created some kind of circular reference and the rootfs.* root file system files were not created, I changed to petalinux-image-minimal.bb and now I have the rootfs files. I am updating the _acceleration_firmwareultra96v2 with these new linux files.

Yeah, that makes sense and matches with previous indications. Glad you got it!

[pimartos]

@vmayoral Finally I have the hello_xilinx example working on the ultra96v2 board =) I am happy, it's a very good ending for the week Attached are the tty capture and the full boot log from putty Next week I will try the other examples Happy weekend! :-)

ultra96v2.log

[vmayoral]

This fantastic! Congratulations @pimartos, happy to see this. I'd recommend you try and build some simple accelerated ROS 2 Node among the ones available in acceleration_examples. That will offer the ultimate validation that the architecture is scalable and works across SOMs/custom-boards.

Happy to suport with that.

In addition, I'd say that I'd be interesting to pick your brain and collect your experience in the working group. Would you be interested in giving a small presentation during December's HAWG meeting about your experience porting the architecture to the Ultra96v2? Besides the presentation, another good contribution would be to extend https://github.com/ros-acceleration/community#adding-your-board in the community repo with instructions from your side, including all sorts of details you believe should be considered while porting it to new boards. I'll be glad to review the Pull Request and iterate to improve existing guidelines.

(ping @GugliZan, you may want to review this thread and considering to open your own ticket with the appropriate name/board)

[GugliZan]

Hi @vmayoral , thank you for pointing me there. I will review this part before considering to open a ticket, such that we can organize a priori the work and be more efficient. Thank you @pimartos for your great initiative and work!

[pimartos]

Hi @vmayoral Yesterday I had some issues to build the hardware accelerated examples, but I think that's because I tweaked the workspace, Today I will start a new workspace from the ground up. Ok, I would like to make a small presentation about the experience porting to the ultra96v2 board, I think that 5 minutes will be enougth, And I will be very happy contributing to the adding new boards section also.

[pimartos]

@vmayoral I started a new workspace and I am having issues building offloaded_doublevadd_publisher First I have a lot of warnings saying /tools/Xilinx/Vitis/2020.2/gnu/aarch64/lin/aarch64-linux/x86_64-petalinux-linux/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-ld.real: /media/usuario/SeagateLinux/krs_ws/install/lib/libvitis_common.a(utilities.cpp.o): Relocations in generic ELF (EM: 62)

and finally this error: /tools/Xilinx/Vitis/2020.2/gnu/aarch64/lin/aarch64-linux/x86_64-petalinux-linux/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-ld.real: /media/usuario/SeagateLinux/krs_ws/install/lib/libvitis_common.a: error adding symbols: file in wrong format

What could be wrong with libvitis.common.a? _vitiscommon builds without problems...

Edit1: One problem was that I need to modify the CMakeLists.txt to point to a new ultra96v2.cfg file for the new platform. Now the example is building

Edit2: The ultra96v2.cfg file generates a missing vadd.xclbin file (I didn't see that error before the warnings), but the libvitis.common.a error still happens

[vmayoral]

First I have a lot of warnings saying /tools/Xilinx/Vitis/2020.2/gnu/aarch64/lin/aarch64-linux/x86_64-petalinux-linux/usr/bin/aarch64-xilinx-linux/aarch64-xilinx-linux-ld.real: /media/usuario/SeagateLinux/krs_ws/install/lib/libvitis_common.a(utilities.cpp.o): Relocations in generic ELF (EM: 62)

@pimartos, vitis_common builds fine in my workspace and generates the appropriate libraries. Have you tried inspecting the build directory?

Edit1: One problem was that I need to modify the CMakeLists.txt to point to a new ultra96v2.cfg file for the new platform. Now the example is building

Right! I missed that one. Yes, we currently need to provide indications to the Vitis compiler about the platform and those are provided through the .cfg file in the current implementation. In the future, the platform should be automatically picked from the firmware directory removing the need of .cfg files. Glad you overcame that.

I tried reproducing your setup but saw that https://github.com/ros-acceleration/acceleration_firmware_ultra96v2 is still empty. Can you push there your current firmware and provide instructions on how to reproduce your current roadblocks?

[pimartos]

Hi @vmayoral The _vitiscommon problem seems to be that when I build targetting ultra96v2, the libvitis_common.a is taken from install instead of install-ultra96v2 so it's a x86_64 version

I messed up my petalinux project, I am in the process of rebuilding it, as soon as I recover it, I will upload acceleration_firmware_ultra96v2 to the repository

By the way: the image_proc_adaptive example doesn't build in foxy, could be possible that needs a component from rolling?

About the next HAWG meeting: Probably I will have a videocall at the same time. Would be ok if I make a small presentation in video telling my experience? (sorry for not being available at the meeting :'( )

[vmayoral]

Thanks for the update @pimartos.

The _vitiscommon problem seems to be that when I build targetting ultra96v2, the libvitis_common.a is taken from install instead of install-ultra96v2 so it's a x86_64 version

Mmm, that's pretty weird. Have you applied/sourced the workspace as an overlay of the workspace (source install/setup.bash)? I'd need to reproduce this to help you.

By the way: the image_proc_adaptive example doesn't build in foxy, could be possible that needs a component from rolling?

I see the problem in here. You're building the latest (main) branch of https://github.com/ros-acceleration/acceleration_examples, which I'm using as a development branch and will often contain additional dependencies (as in the case of image_proc_adaptive) which you need to manually fetch into the workspace. I'd recommend you don't build your port on main but instead, use one of the stable tags (e.g. use 0.2.0). With 0.2.0, you should be good to go.

About the next HAWG meeting: Probably I will have a videocall at the same time. Would be ok if I make a small presentation in video telling my experience? (sorry for not being available at the meeting :'( )

Let's skip your presentation for next week then. I'd love to have you explain your experience, hurdles and things we need to improve directly, and give the audience the chance to interact. How about we move your presentation to next month? (December). I'll coordinate with you offline to find a good date and time.

[pimartos]

Hi @vmayoral

Mmm, that's pretty weird. Have you applied/sourced the workspace as an overlay of the workspace (source install/setup.bash)? I'd need to reproduce this to help you.

Yes, I sourced the workspace; If I don't solve it today, I will start the Petalinux Project from scratch, now occupies 98% of a 160GB partition and fails to build because it runs out of space; I extended the partition to 260GB, but I think that something is wrong inside the project (probably a mixing between recipes avnet-image-minimal and petalinux-image-minimal). The good news is, if I do this, I will document it and will be helpful for others to port boards (petalinux is the bottleneck to make a port).

I see the problem in here. You're building the latest (main) branch....

Yes, I took the main branch of the acceleration examples, I will stay in 0.2.0 tag (forgot the -b 0.2.0 when clonning).

Let's skip your presentation for next week then. I'd love to have you explain your experience, hurdles and things we need to improve directly, and give the audience the chance to interact. How about we move your presentation to next month? (December). I'll coordinate with you offline to find a good date and time.

Yes, I think so. It will be better to do the presentation in the december meeting. Up to now, the examples only work in software in the board (no hardware acceleration yet). I will try to rebuild the petalinux project in the weekend, so I could upload the acceleration_firmware_ultra96v2-0.0.1-alpha release to the repository and it's available by the HAWG meeting (with the limitation that only ROS 2 Publisher and Hello Xilinx examples were tested working in the board)

[pimartos]

Hi @vmayoral I made the alpha release of the acceleration_firmware_ultra96v2. Please check that everything is fine. This release works with the software examples (ROS 2 publisher, Hello Xilinx and HLS in ROS 2), but with the hardware accelerated example (Offloading ROS 2 publisher) the example builds ok, but the directory /lib/firmware/xilinx/ is not created in the sd image.

By the way: the colcon acceleration tag in the install instructions (the krs.repos file) doesn't include the Units/Unidades issue, would be good to make a new release?

[vmayoral]

Thanks for putting that together @pimartos. I gave it a quick try and here're a few comments:

• ✅ acceleration_firmware_ seems to be properly structured, the package builds well and deploys files where appropriate, connecting nicely with the colcon acceleration extensions:

xilinx@xilinx:~/ros2_ws$ colcon acceleration list
kv260
ultra96v2*
zcu102

• ✅ rootfs creation/handling tools seem to be just fine, I could successfully create simple images using a Linux vanilla kernel
  • since only that kernel's available in the firmware, other extensions aren't available such as the use of the Xen hypervisor or fully preemptible kernels, but that can come later in a future release.
• ❌ emulation targets need a bit more of extra work indeed. This is probably related to the QEMU args provided while launching the emulation. My first thought is to look at the <your_ws>/acceleration/firmware/select/emulation/qemu_args.txt file and figure out which arguments are appropriate for the Ultra96v2.
• ⚠️ the lack of /lib/firmware/xilinx/ in the sd image is probably releated to the fact that the Ultra96v2 Yocto BSP is missing dfx-mgrd daemon. I am using https://github.com/Xilinx/dfx-mgr/tree/release-2020.2.2_k26 in the firmware layer for the KV260 to abstract resources for dynamic deployment of accelerator across Vitis platforms (.xpfm files). You'll need this if you want to use DFX. One easy way to bypass it for testing is to load the kernels yourself manually as part of the BOOT.bin file if your platform/environment allows for it.

We can discuss this during the meetings if you have questions.

By the way: the colcon acceleration tag in the install instructions (the krs.repos file) doesn't include the Units/Unidades issue, would be good to make a new release?

Thanks! Noted. Let me bring this back inside and see what I can do.

[pimartos]

Hi @vmayoral

emulation targets need a bit more of extra work indeed. This is probably related to the QEMU args provided while launching the emulation. My first thought is to look at the /acceleration/firmware/select/emulation/qemu_args.txt file and figure out which arguments are appropriate for the Ultra96v2.

I am able to run qemu from the petalinux project with petalinux-boot --qemu --prebuilt 3 When I try with _colcon acceleration emulation swemu --no-install; it hangs with the message Starting PL simulation - Running PLL Laucher. This seems to be related to this, I will investigate more By the way: Why emulation with kv260 has install-kv260and emulation with zcu102 has --no-install?

the lack of /lib/firmware/xilinx/ in the sd image is probably releated to the fact that the Ultra96v2 Yocto BSP is missing dfx-mgrd daemon. I am using https://github.com/Xilinx/dfx-mgr/tree/release-2020.2.2_k26 in the firmware layer for the KV260 to abstract resources for dynamic deployment of accelerator across Vitis platforms (.xpfm files). You'll need this if you want to use DFX. One easy way to bypass it for testing is to load the kernels yourself manually as part of the BOOT.bin file if your platform/environment allows for it.

I will try to add dfx-mgrd to the petalinux project. I can add the kernel and rebuild BOOT.bin, but I think it will be better to include dfx-manager

[pimartos]

Hi @vmayoral

I will try to add dfx-mgrd to the petalinux project. I can add the kernel and rebuild BOOT.bin, but I think it will be better to include dfx-manager

I added dfx-manager and dfxlib to the image and dfx-mgr daemon starts; but when I do $ ros2 acceleration list; the returned list is empty. The _offloaded_doublevaddpublisher is in /lib/firmware/xilinx and when I do $ ros2 run offloaded_doublevadd_publisher offloaded_doublevadd_publisher I get the same text than the example but with a

Error: Result mismatch i = 16 CPU Result = 3535 Device result = 0

What could be missing?

[vmayoral]

How about we get together in a quick call @pimartos and we peer-debug your issues? If you agree, let's bring the conversation to e-mail an we agree on a date/time.

[pimartos]

Hi @vmayoral First, thanks for your time with the call, it was very helpful. I am trying to see why dfx-mgr doesn't see the _offloaded_doublevaddpublisher kernel; so I would like to know how does dfx-mgrd noticed about the accelerators available. It just look inside _/libfirmware/xilinx? Is this a hardcoded path or is inside some config file? I am using mainbranch of dfx-mgr could be possible that this is the reason because the package is not loaded?

[pimartos]

Hi @vmayoral I am stuck with this :-( I tried the release-2020.2.2_k26 of dfx-mgr but it doesn't build (has a implicit declaration error):

/media/usuario/SeagateLinux/ProyectosPetalinux/u96v2_sbc_base_2020_2/build/tmp/work/aarch64-xilinx-linux/dfx-mgr/1.0-r0/git/example/sys/linux/dfx-mgr-client.c:214:2: error: implicit declaration of function 'lws_cmdline_option_handle_builtin' [-Werror=implicit-function-declaration] 214 | lws_cmdline_option_handle_builtin(argc, argv, &info); | ^~~~~~~~~ cc1: all warnings being treated as errors

Should I try to fix this release or could I use masterbranch without problems?