cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
843 Views
Registered: ‎08-13-2019

Multiple boards with petalinux

Hi, 

What is the recommended way to support multiple target boards in petalinux? We have a multiple versions of a design we want to support. It appears in vanilla Yocto you can simply specify the board with the MACHINE variable; however, in petalinux this seems to be set by petalinux itself (that is, it's set in the build/conf/plnxtool.conf directory). Our boards have differing device trees, but we want to use the same image recipe for both, if possible.

0 Kudos
7 Replies
626 Views
Registered: ‎01-09-2020

Bump on this question. Is there a recommended way to support multiple HW platforms from a single petalinux project repo?

0 Kudos
jrhtech
Voyager
Voyager
605 Views
Registered: ‎10-04-2017

You can set the machine name with petalinux-config; however, I think the bigger issue may be multiple device trees.  I haven't done this but I think you could also use the fpga-manger and device-tree overlays.  This provides support for loading new bitstreams AND device-trees from linux.

 

jeff

0 Kudos
stephenm
Moderator
Moderator
506 Views
Registered: ‎09-12-2007

As @jrhtech said, the main issue is the DT. You kernel can be unified with all the drivers needed. With DT overlays, you are disabling the PL dtsi, and then depending on your design you would overlay a specific dto. However, this assumes that your only differences are in the PL?

You can also just provide a DTSI for each iteration of your design, and specify this in petalinux-config -> DTG Settings -> (your design) MACHINE_NAME

This can be passed to petalinux as a patch.

For example, 

  • git clone https://github.com/Xilinx/device-tree-xlnx
  • cd device-tree-xlnx
  • git checkout xilinx-v2020.1

Add your DTSI files here:

device-tree-xlnx\device_tree\data\kernel_dtsi\2020.1\BOARD

To create the patch

  • git diff xilnx_v2020.1 > 0001_add_custom_dtsi.patch

Copy the patch to project-spec/meta-user/recipes-bsp/device-tree/files and update the device-tree.bbappend as follows:

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
 
SRC_URI += "file://system-user.dtsi"
 
SRC_URI_append += " file://0001_add_custom_dtsi.patch"

 

For testing your DTSI files:

https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/341082130/Quick+guide+to+Debugging+Device+Tree+Generator+Issues

0 Kudos
474 Views
Registered: ‎01-09-2020

Thank you stephenm for your suggestions.

I think a solution like this provides a good starting point for our design. I had a few questions.

Q: Is there any way to have the MACHINE_NAME chosen ('machine_name_1', 'machine_name_2', ...) in 'petalinux-config' control if the patch is applied, or have it select between different system-user.dtsi files? Could we use a generic/shared system-user.dtsi file which includes a .dtsi file (machine_name_1.dtsi, machine_name_2.dtsi, ...) selected based on the configured MACHINE_NAME?

Q: Is it possible to have the 'CONFIG_xxx' settings of project-spec/configs/config be overridden by environmental variables or some other means to modify them during build time?

Q: Is it possible to have a non-GUI driven 'petalinux-config --get-hw-description'? We are trying to automate the PL build sequence when we have new designs (hdf files).

Thanks

0 Kudos
dtesone
Visitor
Visitor
229 Views
Registered: ‎07-13-2015

Hi Steve - I was curious if you can share whether this worked out for you? Do you have any advice from experience on this topic. My company is in the same situation where we support many different boards with many using the same Xilinx Zynq SOC and we also have other boards now designed with Xilinx UltraScale+.  We are trying to architect the build system to share as much as the "common" stuff as possible. When Xilinx moved to YOCTO, it sounded like all of this would now be possible...but we have been struggling to find the right way to organize things to integrate the differences between boards at build time (recipe overlays and such). I really think Xilinx needs to offer a tech write up for this situation. They apparently feel that all customers only build 1 board configuration. YOCTO is a pretty sophisticated build system and it would be nice if Xilinx would offer some guidance as to what the expected approach should be for this situation. Until such time Xilinx can offer this information, I have to resort to trolling the forums to see if anyone else has had the same trials and tribulations we have had. Looks like you were in the same boat. Were you ever able to achieve the goal of multiple boards under 1 build system? Were there any epiphanies that you would be willing to share to make this all work? Was the guidance suggested above the way you achieved your goal or did you need to find your own path? Thank you for any information you would be willing to share! -Dan

Tags (2)
0 Kudos
216 Views
Registered: ‎08-13-2019

Steve, I think I can answer your third question:

Add `--silentconfig` to your petalinux-config invocation. When I update HDFs I use this command line:
`rm -r <project-dir>/components/ && petalinux-config --get-hw-description <new-hdf-dir> --silentconfig && petalinux-build -c device-tree -x cleansstate && petalinux-build -c all`

 

I find that the components directory needs to be removed if there are dtsi changes, and for some reason the device-tree recipe doesn't always detect changes. The `all` recipe is a convenience one that brings in the top level targets we need

-Ben 

0 Kudos
hokim
Scholar
Scholar
155 Views
Registered: ‎10-21-2015

0 Kudos