Updating a Raspberry boot partition

This workaround, which i believe also requires this recipe to work, was suggested as a way to update the FAT boot partition on Raspberry devices.

It looks like it updates the following files :

  • *.elf
  • bootcode.bin
  • *.dat
  • bcm2835-bootfiles-XXXXXX.stamp
  • *.dtb
  • *.dtbo

Doesn’t this leave the following — and possibly stale — boot files intact ?

  • cmdline.txt
  • config.txt
  • uImage
  • boot.scr
  • kernelX.img (renamed from u-boot.bin during image build)

Has anyone implemented a more complete solution they can share?
@mirzak what are your thoughts on this problem since working on this back in 2018? I see you chose not to merge your workaround.

Maybe this thread can be used to share further work on working around these limitations.

Best
G

3 Likes

I have made some progress, even though the whole thing still smells brittle & convoluted. After a lot of backtracking, I now understand where each file in the boot partition comes from :

  • meta-raspberrypi/recipes-bsp/rpi-u-boot-scr
    • boot.scr
  • meta-raspberrypi/recipes-bsp/bootfiles/bcm2835-bootfiles
    • bootcode.bin
    • *.dat
    • *.elf
    • bcm2835-bootfiles-xyz.stamp
  • meta-raspberrypi/recipes-kernel/linux/linux-raspberrypi
    • cmdline.txt
    • uImage
    • *.dtb
    • overlays/*.dtbo
  • meta-raspberrypi/recipes-bsp/bootfiles/rpi-config_git
    • config.txt
  • meta/recipes-bsp/u-boot/u-boot.inc
    • kernel7.img (renamed from u-boot.bin during image build)

All recipes have a do_deploy task which sends the file to the {DEPLOYDIR} directory. Mender then copies the files to the boot partition during the do_image tasks. Only a few of these files are packaged with regular do_install/do_package tasks since most of the recipes above inherit the nopackages bbclass.

From what I understand of Yocto, this means that we have to recreate do_install/do_package tasks for all the files above.

If there is another cleaner/simpler way — with a do_populate_sysroot, sysroot_stage_all or do_image task for example — I’d love to hear about it. After brief glances, they all looked like dead ends.


Right. Now, here is what I’m doing.

I have created a bcm2835-bootfiles.bbappend.

# Revert nopackages.bbclass
addtask do_package after do_install
addtask packagedata before do_build after do_package
addtask do_package_setscene
addtask do_packagedata_setscene
addtask do_packagedata after do_package
addtask package_write_rpm after do_packagedata do_package

do_install() {
    install -d ${D}/boot/bcm2835-bootvolume
    for i in ${S}/*.elf ; do
        cp $i ${D}/boot/bcm2835-bootvolume
    done
    for i in ${S}/*.dat ; do
        cp $i ${D}/boot/bcm2835-bootvolume
    done
    for i in ${S}/*.bin ; do
        cp $i ${D}/boot/bcm2835-bootvolume
    done
    # Add stamp in deploy directory
    touch ${D}/boot/bcm2835-bootvolume/${PN}-${PV}.stamp
}
FILES_${PN} += "/boot/bcm2835-bootvolume/*"
INSANE_SKIP_${PN} += "arch"

And a rpi-u-boot-scr.bbappend

# Revert nopackages.bbclass
addtask do_package after do_install
addtask packagedata before do_build after do_package
addtask do_package_setscene
addtask do_packagedata_setscene
addtask do_packagedata after do_package
addtask package_write_rpm after do_packagedata do_package

do_install() {
    install -d ${D}/boot/bcm2835-bootvolume
    cp boot.scr ${D}/boot/bcm2835-bootvolume
}
FILES_${PN} += " /boot/bcm2835-bootvolume/boot.scr"
INSANE_SKIP_${PN} += "arch"

However, I’m having a hard time figuring out the kernel tasks and how to install & package the files generated by linux-raspberrypi (i.e. cmdline.txt, uImage, *.dtb and overlays/*.dtbo).

Pointers anyone ?

2 Likes

Hi @guillaumekh,

Looking in to this again, there is actually a much simpler way to gather the files instead of trying to do it per package (which you have noticed is quite tedious). I probably could have saved you a bit trouble if I had the chance to look in to this earlier but at least here it is.

As all the files that we would like to include in the rootfs are available in the deploy directory one can gather them all in one location as such,

rpi_install_firmware_to_rootfs() {
    install -d ${IMAGE_ROOTFS}/boot/firmware/overlays

    cp ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/* ${IMAGE_ROOTFS}/boot/firmware/
    cp ${DEPLOY_DIR_IMAGE}/*.dtb ${IMAGE_ROOTFS}/boot/firmware/
    cp ${DEPLOY_DIR_IMAGE}/*.dtbo ${IMAGE_ROOTFS}/boot/firmware/overlays/
    cp ${DEPLOY_DIR_IMAGE}/u-boot.bin ${IMAGE_ROOTFS}/boot/firmware/${SDIMG_KERNELIMAGE}
    cp ${DEPLOY_DIR_IMAGE}/boot.scr ${IMAGE_ROOTFS}/boot/firmware/
}
ROOTFS_POSTPROCESS_COMMAND += "rpi_install_firmware_to_rootfs; "

This will put all the files in the /boot/firmware directory in the rootfs.

2 Likes

Ah I was really hoping there would be a cleaner solution like this one. Thanks @mirzak !

I created a PR for this, https://github.com/mendersoftware/meta-mender/pull/953

Note that I found that my previous suggestion copied some extra files to the boot part, and here is the “improved” post processing command

rpi_install_firmware_to_rootfs() {
    install -d ${IMAGE_ROOTFS}/boot/firmware/overlays

    cp ${DEPLOY_DIR_IMAGE}/bcm2835-bootfiles/* ${IMAGE_ROOTFS}/boot/firmware/

    # To exclude files such as bcm2710-rpi-3-b-1-4.19.88+git0+988cc7beac-r0-raspberrypi3-20200323173633.dtb
    # as only the link names are actually valid and searched for on the device.
    find ${DEPLOY_DIR_IMAGE}/ -type l \( -iname "*.dtb" \) -exec cp {} ${IMAGE_ROOTFS}/boot/firmware/ \;
    find ${DEPLOY_DIR_IMAGE}/ -type l \( -iname "*.dtbo" \) -exec cp {} ${IMAGE_ROOTFS}/boot/firmware/overlays/ \;

    cp ${DEPLOY_DIR_IMAGE}/u-boot.bin ${IMAGE_ROOTFS}/boot/firmware/${SDIMG_KERNELIMAGE}
    cp ${DEPLOY_DIR_IMAGE}/boot.scr ${IMAGE_ROOTFS}/boot/firmware/
}
ROOTFS_POSTPROCESS_COMMAND += "rpi_install_firmware_to_rootfs; "
1 Like

For anyone stumbling upon this thread, check out how to use INHERIT += "rpi-update-firmware" to enable boot partition updates. Official tutorial is available here: Updating Raspberry Pi boot firmware files using Yocto Project and Mender

This was merged in master a few day ago (PR#953), and should be merged in warrior soon (PR#957).

2 Likes