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
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
