Skip to content

[V2] Generate boot image

Hugo Grostabussiat requested to merge Bonstra/image-builder:generate-boot-image into master

This MR adds support to build-image for producing an additional image containing all the boot software which is not part of the OS. It is then up to the flasher to decide whether to merge the two images or flash them to separate locations.

This feature is enabled by the want_boot_image board config variable. Until it is set to 1, the build-image script will still generate a single image combining both the boot firmware and the OS, for compatibility purposes, until the devkit tools are ready.

The rationale for this change is to allow flashing the boot firmware on one of the eMMC boot HW partitions instead of having it merged with the OS image on the eMMC user area.

About the eMMC partitions:

The eMMC ICs, at least since revision 4.4 of the standard, have additional hardware partitions, seen as distinct non-overlapping block devices by the host. Those partitions include: the user area (i.e. the main storage space) and 2 small (typically 4MiB) boot partitions.

Storing the boot firmware in an eMMC boot partition has the following benefits:

  • it prevents accidental modification by the user (e.g. changes in the partition layout) since Linux sets the block device corresponding to the eMMC boot partitions read-only

  • it enables safe bootloader updates. When the eMMC is set to boot from a boot partition, that partition is the "active" one, the other is the "inactive" one ("active" and "inactive" is not official terminology; just used here to clarify a bit). The "active" partition is the one used by the SoC to boot; it contains the current boot firmware. The "inactive" partition is used to write the new boot firmware, it must not be used for other purposes as its content will be erased on a boot FW update. When the new boot firmware is written to the "inactive" partition and verified, the roles are swapped atomically between the "active" and "inactive" partitions. That makes the update process resilient to power failures, as the active boot partition is not changed until the updater verified the new boot FW integrity.

  • it removes all the SoC-specific constraints from the eMMC user area. The SoC bootrom expects the boot image to be placed at a hardcoded LBA on the storage medium. Obviously, the area used by the boot image cannot be used for other purposes. If the eMMC is set to boot from the user area, it means the boot image must be stored there, at that SoC-specific offset. Extreme care must be taken when partitioning the storage space to reserve space for the boot image. It it needlessly tedious, and for instance, greatly complicates the use of a GPT partition scheme. However, if the eMMC is configured to boot from one of its boot partitions, all the SoC-specific constraints only apply to that partition, meaning the full user area can be used freely by the OS. You can use the standard tools without having to pass magic parameters to reserve sectors for the boot firmware.

There are some considerations to be aware of before using the eMMC boot partition:

  • the boot firmware must be small (< 4MiB)
  • specific software must be written to change the active eMMC boot partition from within Linux (using IOCTLs to send raw MMC commands)

Merge request reports