PetaLinux v2022.2 bug report: FSBL recipe in `meta-user` doesn't affect the `zynqmp_fsbl.elf`

[michalfita]

Some details about my problem: Forum Post

As I can't find other means to report a bug in PetaLinux I'm reporting it here.

What are my steps:

1. Start patch of ZynqMP FSBL by petalinux-devtool modify fsbl
2. Implement changes, commit
3. Build the project with petalinux-build
4. Pack the boot.bin with petalinux-package ...
5. Put the boot.bin into the first partition of the SD Card
6. Boot the system and we see our changes acting in the output
7. Finish the patch via petalinux-devtool finish fsbl <absolute-path-to-project>/project-spec/meta-user (why absolute is required here?)
8. Pack the boot.bin with petalinux-package ... --force
9. Put the boot.bin into the first partition of the SD Card
10. Boot the system and we see just the vanilla default FSBL is running, no our changes

I assume there's bug in PetaLinux or its recipes as I've tried couple times with no success (we have project creation and build process automated in CI as PetaLinux project cannot be easily committed to Git).

I even asked OpenGPT for help, but it didn't suggested anything else that I'm already doing, so a live brain that knows PetaLinux inside out is required to help with this.

Thank you.

[mhatle]

You need to check two things. The first is it could be an issue where your local changes are not triggering a rebuild, so it just keeps re-using the older version.

petalinux-build -c fsbl -x cleanall
petalinux-build -c fsbl-firmware -x cleanall

Run your build and check if your change is in the binary. If it's not, check the working directory in the project build. (This might be automatically cleared, if so. petalinux-build -c fsbl-firmware -x compile )

The work directory is usually build/tmp/work//fsbl-firmware// somewhere in there should be the sources did your modification actually get applied?

If that works, then the petalinux-package happens outside of the Yocto Project build and may be using a reference board specific FSBL. If that is the case then the forum (you referenced) is the right place to report the issue. I'm only able to help with the Yocto Project specific part of the workflow.

[michalfita]

Thank you, @mhatle, for your quick response. I've did all three steps with the recipe in project-spec/meta-user/recipes-bsp/embeddedsw/fsbl-firmware_%.bbappend in place (the one from petalinux-devtool) and I found one of file supposed to be patched in three places:

build/tmp/work/zynqmp_generic-xilinx-linux/fsbl-firmware/2022.2+gitAUTOINC+5330a64c8e-r0/git/lib/sw_apps/zynqmp_fsbl/src/xfsbl_board.c
build/tmp/work/zynqmp_generic-xilinx-linux/fsbl-firmware/2022.2+gitAUTOINC+5330a64c8e-r0/git/fsbl-firmware/fsbl-firmware/xfsbl_board.c
build/tmp/work/zynqmp_generic-xilinx-linux/fsbl-firmware/2022.2+gitAUTOINC+5330a64c8e-r0/git/fsbl-firmware/fsbl-firmware_plat/zynqmp_fsbl/xfsbl_board.c

None of these contains changes from the patch supposed to add lines to that file.

The recipe content:

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

SRC_URI += "file://0001-OPTDEV-2283-Build-patcheset-recipe-with-devtool.patch"

What I've noticed in components/yocto/layers/meta-xilinx-tools/recipes-bsp/embeddedsw/fsbl-firmware_2022.2.bbappend is that:

# Should not need any external patches
SRC_URI = "${EMBEDDEDSW_SRCURI}"

which (to my understanding) will clear out any existing SRC_URI depending on sequence of recipes application. Is this correct?

Any other hints?

[pftbest]

I got the same exact issue on Petalinux version 2023.1

The workaround is to append your patches to EMBEDDEDSW_SRCURI instead of SRCURI

My recipe project-spec/meta-user/recipes-bsp/embeddedsw/fsbl-firmware_%.bbappend

FILESEXTRAPATHS:prepend := "${THISDIR}/${PN}:"

EMBEDDEDSW_SRCURI:append = " file://0001-Add-Genesys-ZU-fsbl-patches.patch"

I agree it's very confusing that it's not possible to append to SRCURI like any normal package.