[yocto] Yocto-ish upgrade-in-place strategy

[Craig McQueen]

I’m working on this for a BeagleBone Black type system, which uses eMMC (i.e. disk partitions). I’m considering:

Partition 1: FAT16 “BOOT”, with MLO, u-boot.img, and custom uEnv.txt (U-Boot rules to append)
Partition 2: ext4 “KERNEL1”, which contains a zImage with attached initramfs, and device tree
Partition 3: ext4 “KERNEL2”, which contains a zImage with attached initramfs, and device tree
Partition 4: ext4 “DATA”, a read/write filesystem

The DATA partition should contain a SquashFS file named /lib/firmware/rootro1 and/or rootro2.

At boot up, U-Boot loads the custom rules from uEnv.txt. That checks for the presence of a BOOT2 file on the DATA partition. If it exists, it boots the kernel from KERNEL2, otherwise from KERNEL1. It passes kernel arguments:
    rootrw=/dev/mmcblk1p4
    rootro=/mnt/rootrw/lib/firmware/rootro1 -- or rootro2 depending on whether booting KERNEL1 or KERNEL2.

The kernel contains an initramfs (using initramfs-framework) which mounts the DATA partition as /mnt/rootrw. Then it mounts a SquashFS partition /mnt/rootrw/lib/firmware/rootro1 according to the passed kernel argument ‘rootro’, as /mnt/rootro. Then it mounts an OverlayFS with the rootrw mount over the rootro mount.

This is development in-progress, but it seems to be working well for me so far.

Then, I need to have an upgrade image which is an archive of:

·         SquashFS rootro image

·         Kernel with attached initramfs

·         Device tree

·         Any metadata for the upgrade, README, etc

The user can upload it onto the device through a web interface, or something like that. Then it gets processed after upload:


·         The integrity is verified somehow (e.g. hash)

·         The kernel and device tree are copied to the KERNEL1 or KERNEL2 partition that’s not currently in-use.

·         The SquashFS rootro gets copied to /lib/firmware/rootro1 or rootro2, whichever is not currently in-use.

·         The partition 4 file BOOT2 is created or deleted, as needed, to cause U-Boot to boot the “other image”.

·         Reboot

The BeagleBone Black U-Boot implements an incrementing ‘bootcount’, stored in RTC scratch, I believe. A Linux kernel driver could be written which allows for this to be reset to 0 by the kernel or userspace app. Then, U-Boot could do some alternative action if bootcount gets too big (meaning it’s not successfully booting)—such as revert to the other older image, if present.


I should also mention that I used a kernel bbappend file with:

    RDEPENDS_kernel-base = ""

That results in my rootfs image (which is the SquashFS rootfs) NOT containing the kernel and device tree in its /boot directory—since in this setup the kernel and device tree are in a different location KERNELx partition.

Currently, I’m wondering how to get Yocto to build the upgrade image for me. I am not sure whether I can use a custom “image” which has just 4 or 5 files in it. Or maybe if the “wic” tool is suitable for this purpose. Or if I should just use my own script. One possible complication is if I want to use encryption. If so, I probably need to encrypt the archive except for the metadata, README. And I would need to save the encryption keys somehow securely in my build system.

Craig McQueen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20150505/ed880535/attachment.html>