Porting of petalinux meta-user recipes

Support
1

Hi all,

Which forum should I use to post questions, this one https://discuss.pynq.io/ or the older Redirecting to Google Groups?

My particular issue is concerned with porting petalinux_bsp meta-user layer configurations to PYNQ builds. The method is described in the Readme.md file located in the PYNQ sdbuild directory. The document states “Meta-user configurations can be added to the myboards/Myboard/petalinux_bsp
folder so the patches will be applied to the new BSP.” I have tried this for root image apps and u-boot configurations and both appear to not work.

I have tried this with both the ZCU111 and pynq-z2 targets and was unable to get it to work. Taking the pynq-z2 example.

I added a simpleapp and peekpoke as per ug1144 to the petalinux rootfs. The associated petalinux project is called pnfs and is located at ~/pynq-z2/pnfs on my system. I also setup pnfs to use a NFS share. I tested the resulting petalinux build and it worked correctly.

Using the tool petalinux-package --bsp I used the resulting bsp to generate the PYNQ image. This was done by using the both the image_from_prebuilt.sh and manually. Both methods failed to produce an img with the NFS options as specified by petalinux or produce the sampleapp. Next I tried to add the petalinux recipes to the petalinux_bsp/meta-user directory for the board. Same issue, none of the petalinux configurations and apps where ported to the boot and rootfs of the PYNQ. In all cases the PYNQ build process completed and produced an image.

The content of the PYNQ-pnfs.spec file is

ARCH_PYNQ-pnfs := arm
BSP_PYNQ-pnfs := pnfs.bsp
BITSTREAM_PYNQ-pnfs := cz2_wrapper.bit
STAGE4_PACKAGES_PYNQ-pnfs := pynq boot_leds peekpoke sampleapp ethernet

pnfs.bsp is the bsp generated from executing in the associated SDK hardware directory
petalinux-package --bsp -p ~/peta-z2/pnfs/ --hwsource . --output pnfs.bsp

The meta-user directory is located in
~/PYNQ/boards/PYNQ-pnfs/petallinux_bsp/

Content of meta-user is same as content in the equivalent petalinux project pnfs.

I am starting to conclude that the petalinux recipes cannot be used to install programs on the PYNQ rootfs and that the package flow which uses the qemu tools is used instead. I also think the u-boot used by PYNQ is not currently configurable by using a base petalinux recipe. For example, the u-boot built for the ZCU111 has no tftpboot or NFS support while the version for the pynq-z2 does. I used the meta-user BSP recipes for the pynq-z2 for u-boot but the u-boot built for the ZCU111 did not change. Similarly, when I altered the petalinux configuration to support NFS for the pynq-z2 and changed the associated meta-user bsp layer, the changes were not reflected in the PYNQ build.

I would therefore be grateful if anyone could advise me of how it is done. Use of the package flow for root image apps will be okay but we need to alter the ZCU111 u-boot to support NFS and TFTP booting.

Regards

Walter

2

PYNQ image has a petalinux kernel, but a ubuntu-based rootfs. So the apps you added in petalinux bsp will not work. If you add apps in petalinux bsp, it will appear in petalinux rootfs, but PYNQ is using ubuntu rootfs.

You will have to create customized qemu packages and put those in the spec files.
For your example,

STAGE4_PACKAGES_PYNQ-pnfs := pynq boot_leds peekpoke sampleapp ethernet

The peekpoke, sampleapp will need to have their associated qemu packages in the board folder.

3

Hi Rock,

Thank you for your reply. There are two issues we are trying to resolve, one porting of petalinux rootfs apps and the other, altering the u-boot to support TFTP booting and NFS files systems on the ZCU111 platform. We can as you suggest and as was also mentioned in our post use the packages method to add the apps into the rootfs.

However, the bigger issue is the changing of the uboot which should as I understand it port the Xilinx Kernel and u-boot configurations from the underlying petalinux meta-user layers. This does not appear to be working on the current ZCU111 or pynq-z2 release.

Regards

Walter

4

To make u-boot patches, you will need to something like this:

PYNQ sdbuild flow can pick it up and patch it to the existing bsp. The github repo to patch is usually something like:

5 
Thanks for getting back.

The README.md file located in the PYNQ/sdbuild states at around line 141
"
#### (2) Starting from a BSP

You may already have a BSP downloaded somewhere, or constructed
previously. In that case, you can just specify `BSP_Myboard` in
the `*.spec` file, and the SD build flow will take that BSP file in and build
the boot files.

Again, meta-user configurations can be added to the
`myboards/Myboard/petalinux_bsp` folder so the patches will be applied to the 
new BSP. For more details about customising the
boot files please refer to the Petalinux documentation.

".
For sake of description, my petalinux project is located at ~/pnfs and the PYNQ board directory is located in ~/PYNQ/boards/ZCU1111.  The petalinux build works as expected supporting TFTPBoot as required.

As I understand this means that a working u-boot recipe transferred from a petalinux project should override the default u-boot built for the ZCU111 PYNQ target.  This should be possible with just the BSP file as that should have all the necessary u-boot configurations contained within?   The BSP on its own didn't port the u-boot configuration so I next tried to do it using the meta-user route.   I understand that the recipe (which patches and builds u-boot)  taken from ~/pnfs/project-spec/meta-user/recipes-bsp/u-boot should port to the PYNQ build if it is placed in ~/PYNQ/ZCU111/petalinux_bsp/meta-user/recipes-bsp/u-boot? 

This does not appear to be happening which suggests to me that the README.md needs more detail or there is a potential bug in the build tools.  Perhaps the kernel recipe from the pnfs is also required?

Any idea if there are any log files located for the PYNQ build as it might help in locating where PYNQ is getting its u-boot configuration from?


Regards


Walter
6 
Hi all

As a further test to porting petalinux projects, in particular using the output of bsp packaging tool, i.e.

petalinux-package --bsp -p <plnx-proj-root>  --hwsource <hw-project-root> --output MY.BSP

In my specific case this the hardware project route is at
~/zcu111/rdf0476-zcu111-RFdc-eval-tool-2018-3/pl/MTSDesign_8x8/project/zcu111_rfsoc_trd.sdk

$ petalinux-package --bsp -p ~/pnfs/ --hwsource . --output pnfs.bsp

I then created a new petalinux project based on this bsp to see if the u-boot configurations would port to the new petalinux project frombsp.

petalinux-create -t project -s pnfs.bsp -n frombsp .

All worked, ported over the correct u-boot with tftpboot and NFS rootfs.  No further petalinux configuration was required.  

I therefore conclude, that supplying the pfns.bsp to the ZCU111 PYNQ build should be sufficient for the PYNQ tools to replicate the u-boot, kernel and hardware configurations for the underlying PYNQ petalinux  system components.  In other words supplying the pnfs.bsp and this board spec file should be sufficient to replicate the u-boot, kernel, and hardware configurations.

ARCH_ZCU111 := aarch64
BSP_ZCU111 := pnfs.bsp       

STAGE4_PACKAGES_ZCU111 := pynq xrfclk xrfdc ethernet

I will have a look at the PYNQ script files associated with the BSP porting to see if I can determine the reason why the petalinux configurations contained in the pnfs.bsp are not being included in the PYNQ build.

Regards

Walter
7 
Hi all

Digging deeper it appears the tools are hardwired to use xilinx-zcu111-2018.3.bsp.

Before describing the output I modified the script create_bsp.sh to add some debug information.  The modified script is 

#!/bin/bash
script_dir=$(dirname ${BASH_SOURCE[0]})
set -x
set -e

board=$1
template=$2

if [ ! -z "$BSP" ]; then
	echo "wm !!! BSP Found: BSP:= ${BSP}, BSP_ABS:= ${BSP_ABS}, BSP_BUILD:= ${BSP_BUILD}, BSP_PROJECT:= ${BSP_PROJECT}"
	cp -f $BSP_ABS $BSP_BUILD
	cd $BSP_BUILD
	old_project=$(echo $(tar -xvf $BSP) | cut -f1 -d" ")
	rm -f $BSP
	cd $old_project
	echo "wm !!! old_project:= ${old_project}"
	rm -rf components hardware pre-built
	if [ -d "$board/petalinux_bsp/meta-user" ]; then
		cp -rf $board/petalinux_bsp/meta-user/* \
			$BSP_BUILD/$old_project/project-spec/meta-user
	fi
	cd $BSP_BUILD
	tar -czvf $BSP_PROJECT.bsp $old_project
	echo "wm !!! BSP_PROJECT.bsp: ${BSP_PROJECT}.bsp"
else
	echo "wm !!! BSP not found, BSP_BUILD:= ${BSP_BUILD}, BSP_PROJECT:= ${BSP_PROJECT}"
	cp -rf $board/petalinux_bsp/* $BSP_BUILD
	cd $BSP_BUILD/hardware_project
	if [ -e "makefile" ]; then make; fi
	cd $BSP_BUILD
	petalinux-create --type project --template $template --name $BSP_PROJECT
	cd $BSP_PROJECT
	petalinux-config --get-hw-description=$BSP_BUILD/hardware_project \
		--oldconfig
	if [ -d "$board/petalinux_bsp/meta-user" ]; then
		cp -rf $board/petalinux_bsp/meta-user/* \
			$BSP_BUILD/$BSP_PROJECT/project-spec/meta-user
	fi
	cd $BSP_BUILD
	petalinux-package --force --bsp -p $BSP_PROJECT \
		--output $BSP_PROJECT.bsp
fi

Now looking at the contents of the board directory the output of the make.


<prompt>:~/PYNQ/sdbuild$ make clean
if [ -e /home/developer/PYNQ/sdbuild/build/gcc-mb ]; then chmod u+w -fR /home/developer/PYNQ/sdbuild/build/gcc-mb; fi
rm -rf /home/developer/PYNQ/sdbuild/build/gcc-mb
rm -rf /home/developer/PYNQ/sdbuild/build
rm -rf /home/developer/PYNQ/sdbuild/output
<prompt>:~/PYNQ/sdbuild$ cd ../boards/ZCU111/
<prompt>:~/PYNQ/boards/ZCU111$ cat ZCU111.spec 
ARCH_ZCU111 := aarch64
BSP_ZCU111 := pnfs.bsp
BITSTREAM_ZCU111: fpga.bit 
STAGE4_PACKAGES_ZCU111 := pynq xrfclk xrfdc ethernet
<prompt>:~/PYNQ/boards/ZCU111$ ls
fpga.bit  packages  pnfs.bsp  ZCU111.spec
<prompt>:~/PYNQ/boards/ZCU111$ grep -Hrn "xilinx-zcu111-2018.3" .
<prompt>:~/PYNQ/boards/ZCU111$ cd ../../sdbuild/
<prompt>:~/PYNQ/sdbuild$ grep -Hrn "xilinx-zcu111-2018.3" .
<prompt>:~/PYNQ/sdbuild$ make boot_files > buildLog.txt


Looking at the first few lines of buildLog.txt the environment variable BSP_PROJECT appears to be fixed to xilinx-zcu111-2018.3.  However, this does not appear in any of the greps.
This would explain why it is not porting the configuration settings from pnfs.bsp.   

developer@smoz:~/PYNQ/sdbuild$ cat buildLog.txt 
/opt/qemu/bin/qemu-aarch64-static -version | fgrep 2.8.0
qemu-aarch64 version 2.8.0
which vivado | fgrep 2018.3
/tools/Xilinx/Vivado/2018.3/bin/vivado
which sdx | fgrep 2018.3
/tools/Xilinx/SDx/2018.3/bin/sdx
which petalinux-config | fgrep 2018.3
/tools/pkg/petalinux/2018.3/tools/common/petalinux/bin/petalinux-config
which arm-linux-gnueabihf-gcc
/tools/pkg/petalinux/2018.3/tools/linux-i386/gcc-arm-linux-gnueabi/bin/arm-linux-gnueabihf-gcc
which microblaze-xilinx-elf-gcc
/tools/pkg/petalinux/2018.3/tools/linux-i386/microblaze-xilinx-elf/bin/microblaze-xilinx-elf-gcc
which ct-ng
/opt/crosstool-ng/bin/ct-ng
which python | fgrep /usr/bin/python
/usr/bin/python
sudo -n mount > /dev/null
bash /home/developer/PYNQ/sdbuild/scripts/check_Env.sh
bash /home/developer/PYNQ/sdbuild/scripts/check_mounts.sh
mkdir -p /home/developer/PYNQ/sdbuild/build/ZCU111
cp /home/developer/PYNQ/sdbuild/boot/image_aarch64.its /home/developer/PYNQ/sdbuild/build/ZCU111/image.its
rm -rf /home/developer/PYNQ/sdbuild/build/ZCU111/petalinux_bsp
mkdir -p /home/developer/PYNQ/sdbuild/build/ZCU111/petalinux_bsp
BSP=pnfs.bsp BSP_BUILD=/home/developer/PYNQ/sdbuild/build/ZCU111/petalinux_bsp BSP_ABS=/home/developer/PYNQ/sdbuild/../boards/ZCU111/pnfs.bsp **BSP_PROJECT=xilinx-zcu111-2018.3 /home/developer/PYNQ/sdbuild/scripts/create_bsp.sh** /home/developer/PYNQ/sdbuild/../boards/ZCU111 zynqMP
wm !!! BSP Found: BSP:= pnfs.bsp, BSP_ABS:= /home/developer/PYNQ/sdbuild/../boards/ZCU111/pnfs.bsp, BSP_BUILD:= /home/developer/PYNQ/sdbuild/build/ZCU111/petalinux_bsp, BSP_PROJECT:= xilinx-zcu111-2018.3
wm !!! old_project:= pnfs/

Will keep on searching

Regards

Walter

8

Hi all

After some more digging this is what appears to be happening after a make clean.
1. # Create the top level build directory using the Board Name contained in the associated spec file.mkdir -p /home/user/PYNQ/sdbuild/build/ZCU111
2. # Copy a predefined image.its file into this directory. This file image_aarch64.its is basically a device tree source file. cp /home/user/PYNQ/sdbuild/boot/image_aarch64.its /home/user/PYNQ/sdbuild/build/ZCU111/image.its
3. #Remove existing petalinux_bsp project directory and create a new empty one.
rm -rf /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_bsp
mkdir -p /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_bsp
4. #Run the script create_bsp with the desired target board file and architecture set to zynqMP /home/user/PYNQ/sdbuild/scripts/create_bsp.sh /home/user/PYNQ/sdbuild/…/boards/ZCU111 zynqMP
5. # This script copies the original BSP (pnfs.bsp) to the /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_bsp directory, #unpacks it, deletes any components, hardware and pre-built directory. Next the script compresses the remaining contents into a#new BSP named xilinx-zcu111-2018.3.bsp. At this point, the resulting xilinx-zcu111-2018.3.bsp can still be used to generate a complete working #equivalent petalinux project. I mention this because essentially there is no real difference between the original (pnfs.bsp) and the new #xilinx-zcu111-2018.3.bsp.
6. #The next stage is to use the xilinx-zcu111-2018.3.bsp to create the pynq associated petalinux project.rm -rf /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_project
cd /home/user/PYNQ/sdbuild/build/ZCU111 && petalinux-create -t project -s /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_bsp/xilinx-zcu111-2018.3.bsp -n petalinux_project.
7. #At this point the associated petalinux project has settings the same as the original pnfs.bsp.
8. #The next steps create the issue w.r.t. porting a bsp. Essentially the petalinux configuration is overwritten and forced to use the meta-pynq layer defined in #/home/user/PYNQ/sdbuild/boot/meta-#pynq while also forcing the storage medium and ethernet configurations.
echo ‘CONFIG_USER_LAYER_0="’/home/user/PYNQ/sdbuild/boot/meta-pynq’"’ >> /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_project/project-spec/configs/config
echo ‘CONFIG_SUBSYSTEM_ROOTFS_SD=y’ >> /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_project/project-spec/configs/config
echo ‘CONFIG_SUBSYSTEM_ETHERNET_MANUAL_SELECT=y’ >> /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_project/project-spec/configs/config
petalinux-config --oldconfig -p /home/user/PYNQ/sdbuild/build/ZCU111/petalinux_project
9. As has been mentioned in a previous post, user-user layers are not to be used for adding rootfs features. Instead the package qemu based workflow is recommend. Similarly, as can be seen from the above analysis, any meta-user layers aimed at customizing the BSP and kernel layers are also hampered by forced configurations post port. Therefore I suggest that the sdbuild/README.md statement
"#### (2) Starting from a BSP

You may already have a BSP downloaded somewhere, or constructed
previously. In that case, you can just specify `BSP_Myboard` in
the `*.spec` file, and the SD build flow will take that BSP file in and build
the boot files.

Again, meta-user configurations can be added to the
`myboards/Myboard/petalinux_bsp` folder so the patches will be applied to the 
new BSP. For more details about customising the
boot files please refer to the Petalinux documentation."

Really needs a lot more elaboration because you cannot use it to change rootfs content and it is more or less overridden when a change to the recipes_bsp is required.  

I now think a possible way forward is to build a petalinux project with the meta-pynq layer and remove step 8 from the build process.  Again our issue is that the built target that results from using these tools  does not support TFTPBoot and NFS as well as using our own custom fpga hardware design and associated device trees.  Any help on these issues would be most appreciated.


Regards

Walter
9

Hi,

I would like to integrate my custom petalinux rootfs /apps (remoteboot) in my custom pynq workflow.

In petalinux, the meta-user/recipes_apps/remoteboot has remoteboot.bb and files folder(A5.elf etc…).
How can one create the ‘‘associated qemu packages’’ for my remoteboot app.