Platform and Application tool flow with Xilinx Tools over Zynq Ultrascale+ MPSoC EV

[treavor.glbert]

I am working with the ZCU104 dev board and the context of my question is set with the following goals in mind:

1. I would like to boot Linux on the APU using the Petalinux workflow.
2. I would like to run a basic app like HelloWorld on Linux running on the APU.
3. I would like to run a basic app on the RPU over Bare Metal.
4. I'd like to boot all of the above from an SDCard.

I have assumed the following flow:

1. Create custom hardware design in Vivado, export the design as an input for remaining steps.
2. APU Application:
   1. Use the hardware design as an input to a petalinux project.
   2. Create a petalinux outputs based on provided workflows.
   3. Create an APU application that will run over the petalinux outputs.
3. RPU Application:
   1. Create a hardware definition in Xilinx SDK from Vivado output.
   2. Create a BSP from the hardware definition within Xilinx SDK.
   3. Create an RPU application that will run (bare metal) using the BSP.
4. Create a FSBL or similar that can be placed on my SD card to boot linux and the APU app over the APU and also boot the RPU app on the RPU.

Where I am hoping to gain some clarifications:

Configuring Petalinux based on my custom hardware design

Using Xilinx provided guides I have come across the following steps to initiate a Petalinux project (noted that this example is for 102 hardware):

$ petalinux-create -t project -s <xilinx-zcu102-v2018.2-final.bsp>
$ cd xilinx-zcu102-2018.2
$ petalinux-config --get-hw-description=<path containing edt_zcu102_wrapper.hdf>/

I have also encountered cases where the first of these commands is omitted.  What is currently unclear to me is what is achieved by sourcing the BSP here when the hardware description is also set?  And is the BSP in fact a requirement when I am referencing a custom hardware description?  I first assumed that I would need to create a BSP based on my hardware design in the SDK and then use that as an input here, however it appears that the two usages of "BSP" are not necessarily the same, and as far as I can tell the SDK does not generate a .BSP file that can be used as an input for a new petalinux project.

Second to this, I am trying to decipher the correct flow for creating an application in the SDK that will run over my petalinux distribution.  What seems clear is that my application will need to reference my custom Linux system and I assume this is achieved by setting my OS platform as linux and then setting the Linux System Root location.  That said, the tool-tip for this references the location of <Petalinux Proj Dir>/build/linux/rootfs/stage (see attached image), and this location does not exist when following the guide to build my linux outputs.  I later stumbled across the commands:

petalinux-build --sdk
petalinux-package --sysroot

And when run, it appears the System Root can then be referenced at: <Petalinux Proj Dir>/images/linux/sdk/sysroots/aarch64-xilinx-linux.  Is this however correct and all that is needed to create an environment for my APU application development?

I am using Xilinx SDK 2018.2 on a Linux Ubuntu host.

Thanks ahead of time for any help in this matter.

[ibaie · Accepted solution]

Hi @treavor.glbert

The meaning of BSP within SDK and Petalinux are slightly different so let try to clarify it first of all. Within SDK the BSP is just a project containing all the peripheral drivers, boot code and configuration. In Petalinux is just a preconfigured Petalinux project usually targeting our evaluation boards, although you can package a custom project as BSP to share it afterwards.

Regarding the Petalinux project creating method the answer is just depends... If you are using an evaluation platform like ZCU102 you should always use the BSP first and then configure with your own HDF file. Why? As previously described the BSP package is a preconfigured project where BOARD LEVEL details have been included for example in the device-tree definition. If you do not source the BSP then that information will be missing (as board level components like ethernet phy...) are not described within the HDF file exported from Vivado. When a custom board is used it does not take too much sense to use the BSP but then manual work is required to configure the project according to the custom hardware requirements.

Finally regarding SDK project generation for Linux application those two settings are bit optional. The SDK by itself already includes a basic sysroot so as far as you are not using non include libraries (i.e. libz....) you don't need to use custom sysroot folders. In the same way you already have a toolchain so as long as you don't need to use the SAME toolchain built within the petalinux project you don't need that neither.

Regards

[treavor.glbert]

Thanks for the response and clarifications.

[stephenm]

Also, you if you are not using the BSP but are building an image for a development board, you can set the MACHINE_NAME in petalinux-config. For example:

petalinux-create -t project --template zynqMP -n zcu102_linux

cd zcu102_linux

petalinux-config --get-hw-description=<path to HDF>

DTG Settings -> (zcu102-rev1.0) MACHINE_NAME

[kenny@stealthspacecompany.com]

And if I am using zlib? Do I generate a sysroot and then point the SDK at that?