In the v82 LmP release we delivered a new powerful feature - Boot Software Updates. It provides a mechanism for updating all boot artifacts, including SPL/TF-A/OP-TEE/U-Boot proper and custom M4 firmware images.
Trivia
Currently the Boot Software Updates feature is supported only by iMX6/7/8M SoC families. It leverages SoC specific low level features, that permit one to have two copies of bootloader images in SD/eMMC and switch between them. The switch can be triggered either by the BootROM in case the bootloader image is faulty or can be enforced by the user. The latter is a mechanism which can be used for validation of updated boot software artifacts.
More details about this feature can be found in Boot Software Updates technical article.
Boot artifacts overview and updates
It's common that we seek after the standardized boot image layout, which consists of two major images: SPL and signed FIT image.
SPL is the first software loader generated by the i.MX U-Boot build. It’s usually in charge of DDR initialization steps, setting up clocks/pinmux to access boot media and further loading/verifying U-Boot FIT image and extracting its components.
U-boot FIT-image is a generic name for the signed FIT-image that contains U-Boot proper (u-boot.bin) and a host of other firmware. This file is verified by SPL via a public key stored in SPL’s dtb. This artifact may be signed (on closed boards) as a part of CI and can be included automatically in a boot software OTA package.
It includes:
- U-boot-nodtb.bin
- U-boot.dtb
- OP-TEE
- Arm Trusted Firmware (ARMv8)
- M4 firmwares (optional)
- Boot.cmd script (new)
boot.cmd script, which is responsible for loading Linux, was moved to FIT from the first boot partition so it’s possible to update it alongside with other boot artifacts.
MMC boot image layout adjustments
For correct functioning of boot software updates there were adjustments made in eMMC/SD boot partition layout. Now we have two copies of boot artifacts in the boot0 partition (eMMC) or user partition (SD): Primary (A) and Secondary (B) sets of boot images. Primary set by default is used as a stable boot path, which is booted by BootROM after POR. Secondary is used as temporary storage of updated boot images, so we can validate the full boot sequence before committing them to the primary boot path.
Here is an example of adjusted eMMC boot image layout (i.MX8M):
There is also an additional image at offset 0x8200, which is called Secondary Image Table (SIT), which contains secondary image set area offset and additional meta information.
Boot process and updates
All boot image updates (SPL/imx-boot and U-Boot FIT) are delivered via libostree sysroot updates and are stored in ${ostree_root}/usr/lib/firmware/.
The actual update is done in U-Boot while executing boot.cmd script. There is a new flag introduced, called bootupgrade_available, which is set by aktualizr-lite during update and triggers boot image update procedure in U-Boot. U-Boot detects the need for a boot software upgrade by checking bootupgrade_available flag and then uses boot artifacts from the new ostree sysroot. As this feature requires multiple phases and reboots, boot.cmd now implements a simple state machine that consists of multiple boot software upgrade phases, including validation of boot software updates and committing updates to stable path.
To handle different exceptional situations like software hangs during boot software validation phase, watchdog timers are enabled by default, so in the worst case scenario we can boot back into the primary (stable) boot path again.
Future
In the future LmP releases we plan to add rollback protection support, whic will protect against known security flaws. This feature will prohibit rolling back to old versions of boot software and deny booting if an old boot software were flashed manually by tampering with the boot partition.
We also plan to extend the list of supported SoCs, adding support for i.MX8QM and Xilinx Zynq® UltraScale+™ MPSoC.