[PATCH v2 00/11] imagemap: on-demand FIT loading from storage
Daniel Golle <[email protected]>
| Newsgroups | org.u-boot-project.lists.u-boot |
|---|---|
| Message-ID | <[email protected]> |
This series adds "imagemap", a small layer for reading FIT images directly
from storage on demand instead of copying the whole image into RAM first.
It keeps a translation table of the byte ranges already loaded, so a
header probe, signature verification and the final load can reuse a single
read, and it hooks transparently into fit_image_load() so all existing
verification and decompression paths run unchanged for both RAM- and
storage-backed images.
An imagemap device is created over a partition of a block device. That
covers more than raw disks: an MTD partition is reached through mtdblock
and a UBI volume through ubiblock, each exposed as a named block-device
partition, so imagemap carries no storage-specific code of its own. NAND
bad-block handling and wear-levelling stay with UBI, as they do elsewhere
in U-Boot; on NOR a partition is read linearly with end-to-end integrity
guaranteed by the FIT hash or signature.
To make those two paths reachable and testable, the first patches fill in
the missing block devices: a non-NAND MTD master now gets an mtd_blk
device automatically (patch 1), and attaching UBI now binds a ubi_blk
device on any flash (patch 3, which makes the SPI-NAND-only eager binding
redundant, dropped in patch 4).
The read path is built on the SPL struct spl_load_info abstraction and a
new spl_load_region() helper. imagemap is full-U-Boot only; the SPL FIT
loader is unaffected.
Testing (sandbox): "ut imagemap" (13 tests) covers the translation-table
core plus real end-to-end reads of a NOR partition through mtd_blk and a
UBI volume through ubiblock; a CONFIG_IMAGEMAP=n build is unaffected. The
whole series passes CI [1].
On hardware it has been tested end-to-end on a BananaPi R3 (mt7986),
booting a dm-verity-protected rootfs from every storage path the board
exposes: eMMC and SD (block partition), SPI-NAND (UBI volume via
ubiblock) and SPI-NOR (raw MTD partition via mtdblock). The first
in-tree consumer, a bootmeth for OpenWrt-style FIT firmware, will follow
as a separate series.
Changes in v2 (since v1 [2]):
- Add two prerequisite fixes for the UBI block driver that enabling
CONFIG_UBI_BLOCK in sandbox exposes: make it depend on CMD_UBI (its
ubi_volume_read()/write() live in cmd/ubi.c, so a CONFIG_CMDLINE=n
build otherwise fails to link), and stop the UBI partition scan from
claiming any readable block device or dereferencing a NULL ubi_device.
- include/spl.h: express the block-length field directly with
#if IS_ENABLED(CONFIG_SPL_LOAD_BLOCK) || CONFIG_IS_ENABLED(IMAGEMAP)
instead of a SPL_LOAD_INFO_HAS_BL_LEN helper macro, and fold the note
into the existing struct comment (per Tom Rini).
- boot: fit: fix a continuation-line alignment in fit_image_load()
flagged by checkpatch (per Tom Rini).
This series began as part of a combined RFC that also carried the OpenWrt
boot method and its bootdevs [3]. Following the review there it has been
reworked substantially:
- Build on U-Boot's existing SPL external-data loading path rather than
a new abstraction: imagemap now uses struct spl_load_info and a new
spl_load_region() helper (suggested by Marek Vasut).
- Do not extend the bootm command with a storage source; on-demand
loading hooks into fit_image_load() transparently, and the in-tree
consumer is a bootstd boot method reached through
bootflow/bootdev/bootmeth rather than new bootm syntax (per Tom Rini).
- Move the storage-backed path out of the long fit_image_load() into its
own helper, gated with if()/tools_build() instead of an inline #if
(per Simon Glass).
- Collapse the three storage-specific backends (block, MTD and UBI) into
a single block backend: NOR is read through mtd_blk and SPI-NAND
through UBI/ubiblock, so imagemap holds no storage-specific code.
- Send the on-demand loading core on its own; the OpenWrt boot method,
the MTD/UBI bootdevs and board enablement follow as separate series
once this lands.
A note on that follow-up: to tell Linux which FIT it booted, U-Boot uses
the install-uuid mechanism of [4], which [5] could supersede. Both have
stalled.
[1] https://git.u-boot-project.org/u-boot/contributors/dgolle/u-boot/-/pipelines/1067
[2] https://lore.kernel.org/u-boot/[email protected]/
[3] https://lore.kernel.org/u-boot/[email protected]/
[4] https://github.com/open-source-firmware/flat-image-tree/pull/40
[5] https://github.com/open-source-firmware/flat-image-tree/pull/44
Daniel Golle (11):
mtd: bind an mtd_blk device for non-NAND MTD masters
mtd: nand: sandbox: forbid sub-page writes
cmd: ubi: create a ubi_blk device when attaching UBI
mtd: nand: spi: drop the eager ubi_blk binding
mtd: ubi: block: build only with CONFIG_CMD_UBI
mtd: ubi: block: only claim UBI block devices in the partition scan
boot: add imagemap on-demand loading from storage
boot: fit: support on-demand loading in fit_image_load()
configs: sandbox: enable imagemap and its storage backends
test: boot: add imagemap unit tests
doc: imagemap: document on-demand loading framework
MAINTAINERS | 9 +
arch/sandbox/dts/test.dts | 29 ++
boot/Kconfig | 16 +
boot/Makefile | 2 +
boot/bootm.c | 70 +++-
boot/image-fit.c | 109 +++++-
boot/imagemap.c | 451 +++++++++++++++++++++
cmd/ubi.c | 27 ++
configs/sandbox_defconfig | 6 +
doc/develop/imagemap.rst | 100 +++++
doc/develop/index.rst | 1 +
drivers/mtd/mtdcore.c | 24 ++
drivers/mtd/nand/raw/sand_nand.c | 2 +
drivers/mtd/nand/spi/core.c | 3 -
drivers/mtd/ubi/Kconfig | 1 +
drivers/mtd/ubi/part.c | 9 +
include/bootm.h | 2 +
include/dm/uclass-id.h | 1 +
include/image.h | 2 +
include/imagemap.h | 136 +++++++
include/spl.h | 38 +-
test/boot/Makefile | 2 +
test/boot/imagemap.c | 645 +++++++++++++++++++++++++++++++
test/cmd_ut.c | 2 +
24 files changed, 1671 insertions(+), 16 deletions(-)
create mode 100644 boot/imagemap.c
create mode 100644 doc/develop/imagemap.rst
create mode 100644 include/imagemap.h
create mode 100644 test/boot/imagemap.c
base-commit: 8841b7b292c74864acf4ed0bd8ce05839252c1f2
--
2.55.0