Patch Detail
get:
Show a patch.
patch:
Update a patch.
put:
Update a patch.
GET /api/patches/2197006/?format=api
{ "id": 2197006, "url": "http://patchwork.ozlabs.org/api/patches/2197006/?format=api", "web_url": "http://patchwork.ozlabs.org/project/uboot/patch/afd86ec997b452bfe8fd03fb6d090f666244f6be.1771275704.git.daniel@makrotopia.org/", "project": { "id": 18, "url": "http://patchwork.ozlabs.org/api/projects/18/?format=api", "name": "U-Boot", "link_name": "uboot", "list_id": "u-boot.lists.denx.de", "list_email": "u-boot@lists.denx.de", "web_url": null, "scm_url": null, "webscm_url": null, "list_archive_url": "", "list_archive_url_format": "", "commit_url_format": "" }, "msgid": "<afd86ec997b452bfe8fd03fb6d090f666244f6be.1771275704.git.daniel@makrotopia.org>", "list_archive_url": null, "date": "2026-02-16T21:23:09", "name": "[RFC,12/20] doc: bootm: document direct storage boot", "commit_ref": null, "pull_url": null, "state": "new", "archived": false, "hash": "2e7eaecccc41757ea1139463c605a1bd29abe401", "submitter": { "id": 64091, "url": "http://patchwork.ozlabs.org/api/people/64091/?format=api", "name": "Daniel Golle", "email": "daniel@makrotopia.org" }, "delegate": null, "mbox": "http://patchwork.ozlabs.org/project/uboot/patch/afd86ec997b452bfe8fd03fb6d090f666244f6be.1771275704.git.daniel@makrotopia.org/mbox/", "series": [ { "id": 492351, "url": "http://patchwork.ozlabs.org/api/series/492351/?format=api", "web_url": "http://patchwork.ozlabs.org/project/uboot/list/?series=492351", "date": "2026-02-16T21:21:14", "name": "boot: add OpenWrt boot method and on-demand FIT loading", "version": 1, "mbox": "http://patchwork.ozlabs.org/series/492351/mbox/" } ], "comments": "http://patchwork.ozlabs.org/api/patches/2197006/comments/", "check": "pending", "checks": "http://patchwork.ozlabs.org/api/patches/2197006/checks/", "tags": {}, "related": [], "headers": { "Return-Path": "<u-boot-bounces@lists.denx.de>", "X-Original-To": "incoming@patchwork.ozlabs.org", "Delivered-To": "patchwork-incoming@legolas.ozlabs.org", "Authentication-Results": [ "legolas.ozlabs.org;\n spf=pass (sender SPF authorized) smtp.mailfrom=lists.denx.de\n (client-ip=2a01:238:438b:c500:173d:9f52:ddab:ee01; helo=phobos.denx.de;\n envelope-from=u-boot-bounces@lists.denx.de; receiver=patchwork.ozlabs.org)", "phobos.denx.de;\n dmarc=none (p=none dis=none) header.from=makrotopia.org", "phobos.denx.de;\n spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de", "phobos.denx.de; dmarc=none (p=none dis=none)\n header.from=makrotopia.org", "phobos.denx.de;\n spf=pass smtp.mailfrom=daniel@makrotopia.org" ], "Received": [ "from phobos.denx.de (phobos.denx.de\n [IPv6:2a01:238:438b:c500:173d:9f52:ddab:ee01])\n\t(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)\n\t key-exchange x25519)\n\t(No client certificate requested)\n\tby legolas.ozlabs.org (Postfix) with ESMTPS id 4fFG5F3tv6z1xwD\n\tfor <incoming@patchwork.ozlabs.org>; Tue, 17 Feb 2026 08:25:05 +1100 (AEDT)", "from h2850616.stratoserver.net (localhost [IPv6:::1])\n\tby phobos.denx.de (Postfix) with ESMTP id 50B4883E70;\n\tMon, 16 Feb 2026 22:23:43 +0100 (CET)", "by phobos.denx.de (Postfix, from userid 109)\n id A7EA583D3D; Mon, 16 Feb 2026 22:23:31 +0100 (CET)", "from pidgin.makrotopia.org (pidgin.makrotopia.org\n [IPv6:2a07:2ec0:3002::65])\n (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))\n (No client certificate requested)\n by phobos.denx.de (Postfix) with ESMTPS id 385CA83E60\n for <u-boot@lists.denx.de>; Mon, 16 Feb 2026 22:23:29 +0100 (CET)", "from local\n by pidgin.makrotopia.org with esmtpsa (TLS1.3:TLS_AES_256_GCM_SHA384:256)\n (Exim 4.99) (envelope-from <daniel@makrotopia.org>)\n id 1vs63k-000000002lq-3lOo; Mon, 16 Feb 2026 21:23:13 +0000" ], "X-Spam-Checker-Version": "SpamAssassin 3.4.2 (2018-09-13) on phobos.denx.de", "X-Spam-Level": "", "X-Spam-Status": "No, score=-1.9 required=5.0 tests=BAYES_00,\n RCVD_IN_DNSWL_BLOCKED,SPF_HELO_NONE,SPF_PASS autolearn=ham\n autolearn_force=no version=3.4.2", "Date": "Mon, 16 Feb 2026 21:23:09 +0000", "From": "Daniel Golle <daniel@makrotopia.org>", "To": "Tom Rini <trini@konsulko.com>, Simon Glass <sjg@chromium.org>,\n Quentin Schulz <quentin.schulz@cherry.de>,\n Daniel Golle <daniel@makrotopia.org>,\n Kory Maincent <kory.maincent@bootlin.com>,\n Mattijs Korpershoek <mkorpershoek@kernel.org>,\n Martin Schwan <m.schwan@phytec.de>, Anshul Dalal <anshuld@ti.com>,\n Ilias Apalodimas <ilias.apalodimas@linaro.org>,\n Sughosh Ganu <sughosh.ganu@arm.com>, Aristo Chen <jj251510319013@gmail.com>,\n\t=?utf-8?b?54mbIOW/l+Wujw==?= <Zone.Niuzh@hotmail.com>,\n Marek Vasut <marek.vasut+renesas@mailbox.org>,\n Heinrich Schuchardt <xypron.glpk@gmx.de>,\n Wolfgang Wallner <wolfgang.wallner@at.abb.com>,\n Frank Wunderlich <frank-w@public-files.de>,\n David Lechner <dlechner@baylibre.com>,\n Osama Abdelkader <osama.abdelkader@gmail.com>,\n Mikhail Kshevetskiy <mikhail.kshevetskiy@iopsys.eu>,\n Michael Trimarchi <michael@amarulasolutions.com>,\n Miquel Raynal <miquel.raynal@bootlin.com>,\n Andrew Goodbody <andrew.goodbody@linaro.org>,\n Yegor Yefremov <yegorslists@googlemail.com>,\n Mike Looijmans <mike.looijmans@topic.nl>,\n Weijie Gao <weijie.gao@mediatek.com>,\n Alexander Stein <alexander.stein@ew.tq-group.com>,\n Neil Armstrong <neil.armstrong@linaro.org>,\n Mayuresh Chitale <mchitale@ventanamicro.com>,\n Paul HENRYS <paul.henrys_ext@softathome.com>, u-boot@lists.denx.de", "Cc": "John Crispin <john@phrozen.org>, Paul Spooren <mail@aparcar.org>", "Subject": "[RFC PATCH 12/20] doc: bootm: document direct storage boot", "Message-ID": "\n <afd86ec997b452bfe8fd03fb6d090f666244f6be.1771275704.git.daniel@makrotopia.org>", "References": "<cover.1771275704.git.daniel@makrotopia.org>", "MIME-Version": "1.0", "Content-Type": "text/plain; charset=utf-8", "Content-Disposition": "inline", "Content-Transfer-Encoding": "8bit", "In-Reply-To": "<cover.1771275704.git.daniel@makrotopia.org>", "X-Mailman-Approved-At": "Mon, 16 Feb 2026 22:23:42 +0100", "X-BeenThere": "u-boot@lists.denx.de", "X-Mailman-Version": "2.1.39", "Precedence": "list", "List-Id": "U-Boot discussion <u-boot.lists.denx.de>", "List-Unsubscribe": "<https://lists.denx.de/options/u-boot>,\n <mailto:u-boot-request@lists.denx.de?subject=unsubscribe>", "List-Archive": "<https://lists.denx.de/pipermail/u-boot/>", "List-Post": "<mailto:u-boot@lists.denx.de>", "List-Help": "<mailto:u-boot-request@lists.denx.de?subject=help>", "List-Subscribe": "<https://lists.denx.de/listinfo/u-boot>,\n <mailto:u-boot-request@lists.denx.de?subject=subscribe>", "Errors-To": "u-boot-bounces@lists.denx.de", "Sender": "\"U-Boot\" <u-boot-bounces@lists.denx.de>", "X-Virus-Scanned": "clamav-milter 0.103.8 at phobos.denx.de", "X-Virus-Status": "Clean" }, "content": "Add user and developer documentation for the bootm storage loading\nfeature.\n\ndoc/usage/fit/storage-boot.rst:\n User-facing documentation with syntax reference, examples for MMC,\n MTD, and UBI, description of how the on-demand loading works, how\n filesystem sub-images are skipped, and the relevant Kconfig options.\n\ndoc/develop/bootm-storage.rst:\n Developer documentation covering the image_loader architecture,\n translation table design, API reference (map, map_to, lookup,\n cleanup), storage backend interface with step-by-step guide for\n adding new backends, FIT integration points in boot_get_kernel()\n and fit_image_load(), and testing instructions.\n\nSigned-off-by: Daniel Golle <daniel@makrotopia.org>\n---\n doc/develop/bootm-storage.rst | 210 +++++++++++++++++++++++++++++++++\n doc/develop/index.rst | 1 +\n doc/usage/fit/index.rst | 1 +\n doc/usage/fit/storage-boot.rst | 201 +++++++++++++++++++++++++++++++\n 4 files changed, 413 insertions(+)\n create mode 100644 doc/develop/bootm-storage.rst\n create mode 100644 doc/usage/fit/storage-boot.rst", "diff": "diff --git a/doc/develop/bootm-storage.rst b/doc/develop/bootm-storage.rst\nnew file mode 100644\nindex 00000000000..d779049388a\n--- /dev/null\n+++ b/doc/develop/bootm-storage.rst\n@@ -0,0 +1,210 @@\n+.. SPDX-License-Identifier: GPL-2.0+\n+\n+On-Demand Image Loading from Storage\n+=====================================\n+\n+This document describes the ``image_loader`` framework that enables\n+``bootm`` to load FIT images directly from storage devices without first\n+copying the entire image into RAM.\n+\n+Architecture Overview\n+---------------------\n+\n+The framework is built around ``struct image_loader``\n+(``include/image-loader.h``), which provides:\n+\n+``read(ldr, src, size, dst)``\n+ Backend callback that reads ``size`` bytes starting at byte offset\n+ ``src`` within the source image into the RAM buffer at ``dst``.\n+\n+``cleanup(ldr)``\n+ Optional callback to release device references, free private state,\n+ etc. Called at the end of the boot attempt.\n+\n+``priv``\n+ Opaque pointer to backend-specific context (block device descriptor,\n+ MTD device, UBI volume info, etc.).\n+\n+``regions[]``\n+ Translation table of ``struct image_loader_region`` entries. Each\n+ entry records that bytes ``[img_offset, img_offset + size)`` of the\n+ source image have been loaded into RAM at address ``ram``.\n+\n+``nr_regions``\n+ Number of entries currently used in the translation table.\n+\n+``alloc_ptr``\n+ Next free RAM address for scratch allocations. Advanced (aligned to\n+ ``ARCH_DMA_MINALIGN``) after each new mapping.\n+\n+API Reference\n+-------------\n+\n+``image_loader_map(ldr, img_offset, size)``\n+ Ensure that image bytes ``[img_offset, img_offset + size)`` are\n+ accessible in RAM. Returns a pointer to the data.\n+\n+ - If the range is fully covered by an existing translation table\n+ entry, returns the cached pointer (no I/O).\n+ - If an entry exists at the same base offset but is smaller, the\n+ entry is extended in place (re-read to the same RAM base).\n+ - Otherwise, allocates from ``alloc_ptr``, reads from storage,\n+ records the new mapping, and advances ``alloc_ptr``.\n+\n+``image_loader_map_to(ldr, img_offset, size, dst)``\n+ Like ``map()`` but reads into a caller-specified RAM address instead\n+ of allocating from the scratch area. Used when the sub-image has a\n+ known load address (zero-copy path).\n+\n+``image_loader_lookup(ldr, img_offset, size)``\n+ Check the translation table for an existing mapping. Returns the\n+ RAM pointer on hit, ``NULL`` on miss. Does not trigger any I/O.\n+\n+``image_loader_cleanup(ldr)``\n+ Call the backend ``cleanup`` callback (if set) and reset all loader\n+ state. Safe to call multiple times.\n+\n+Storage Backends\n+----------------\n+\n+Each backend implements an ``image_loader_init_*()`` function that\n+resolves the device, installs ``.read()`` and ``.cleanup()`` callbacks,\n+and stores backend-specific context in ``.priv``.\n+\n+Block (``boot/image-loader-blk.c``)\n+ ``image_loader_init_blk(ldr, ifname, dev_part_str)``\n+\n+ Resolves the partition via ``part_get_info_by_dev_and_name_or_num()``\n+ and reads via ``blk_dread()``. Handles unaligned head/tail via a\n+ bounce buffer.\n+\n+MTD (``boot/image-loader-mtd.c``)\n+ ``image_loader_init_mtd(ldr, name)``\n+\n+ Resolves via ``get_mtd_device_nm()`` and reads via\n+ ``mtd_read_skip_bad()``. On NAND, bad blocks are transparently\n+ skipped.\n+\n+UBI (``boot/image-loader-ubi.c``)\n+ ``image_loader_init_ubi(ldr, vol_name)``\n+\n+ Auto-attaches a UBI device from the device tree (scanning\n+ ``linux,ubi`` compatible nodes) if not already attached. Reads via\n+ ``ubi_volume_read()``.\n+\n+Writing a New Backend\n+^^^^^^^^^^^^^^^^^^^^^\n+\n+To add support for a new storage type:\n+\n+1. Create ``boot/image-loader-foo.c``.\n+\n+2. Define a private context struct and a read callback::\n+\n+ struct foo_priv { ... };\n+\n+ static int foo_read(struct image_loader *ldr, ulong src,\n+ ulong size, void *dst)\n+ {\n+ struct foo_priv *p = ldr->priv;\n+ /* read 'size' bytes at offset 'src' into 'dst' */\n+ return 0; /* or negative errno */\n+ }\n+\n+3. Optionally define a cleanup callback::\n+\n+ static void foo_cleanup(struct image_loader *ldr)\n+ {\n+ struct foo_priv *p = ldr->priv;\n+ /* release resources */\n+ free(p);\n+ }\n+\n+4. Implement the init function::\n+\n+ int image_loader_init_foo(struct image_loader *ldr, ...)\n+ {\n+ struct foo_priv *p = calloc(1, sizeof(*p));\n+ if (!p)\n+ return -ENOMEM;\n+ /* resolve device, fill p->... */\n+ ldr->read = foo_read;\n+ ldr->cleanup = foo_cleanup;\n+ ldr->priv = p;\n+ return 0;\n+ }\n+\n+5. Add the prototype to ``include/image-loader.h``.\n+\n+6. Add a Kconfig symbol in ``boot/Kconfig`` and build rule in\n+ ``boot/Makefile``.\n+\n+7. Add the keyword dispatch in ``bootm_init_loader()`` in\n+ ``cmd/bootm.c``.\n+\n+FIT Integration\n+---------------\n+\n+External Data vs. Embedded Data\n+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\n+\n+The selective loading optimisation is only possible with **external-data**\n+FIT images (built with ``mkimage -E``). In this layout, the FDT\n+structure is a compact metadata-only blob and each sub-image's payload is\n+stored at a separate offset recorded via ``data-position``/``data-offset``\n+and ``data-size`` properties.\n+\n+When ``fit_image_load()`` encounters a sub-image with external data and\n+``images->loader`` is set, it reads only that sub-image's payload from\n+storage — the code path is gated on ``external`` being true (i.e.\n+``data-position`` or ``data-offset`` exists in the node).\n+\n+With **embedded-data** FIT images, all payloads live inside FDT ``data``\n+properties. The entire FDT — including all payloads — is loaded when\n+``boot_get_kernel()`` maps the FDT structure. The storage-backed path\n+still works (the image is valid), but:\n+\n+- No RAM is saved because the full image is read as the \"FDT structure\".\n+- ``IH_TYPE_FILESYSTEM`` sub-images cannot be skipped since their data\n+ is embedded in the FDT blob.\n+- ``fit_image_load()`` takes the normal embedded-data code path (the\n+ ``data`` property points into the already-loaded FDT) and the\n+ ``image_loader`` is not involved for individual sub-images.\n+\n+Backend developers do not need to handle this distinction — it is\n+managed entirely by ``boot_get_kernel()`` and ``fit_image_load()``.\n+\n+Access Points\n+^^^^^^^^^^^^^\n+\n+**Access Point 1: boot_get_kernel() (boot/bootm.c)**\n+\n+When ``images->loader`` is set, ``boot_get_kernel()`` uses\n+``image_loader_map()`` to read the first 64 bytes for format detection,\n+then extends to the full ``fdt_totalsize()`` for FIT images. For\n+external-data images this is just the compact metadata; for embedded-data\n+images this is the entire file. This replaces the normal\n+``map_sysmem(img_addr, 0)`` path.\n+\n+**Access Point 2: fit_image_load() (boot/image-fit.c)**\n+\n+When processing a FIT sub-image with external data and\n+``images->loader`` is set, ``fit_image_load()`` uses\n+``image_loader_map()`` or ``image_loader_map_to()`` to load just the\n+sub-image data on demand. Sub-images of type ``IH_TYPE_FILESYSTEM`` are\n+skipped entirely. Verification uses ``fit_image_verify_with_data()`` to\n+check hashes against the loaded data.\n+\n+For embedded-data sub-images, the existing in-memory code path is taken\n+since the data is already present in the FDT mapping from Access Point 1.\n+\n+Testing\n+-------\n+\n+Unit tests are in ``test/boot/image_loader.c`` and can be run via::\n+\n+ ./u-boot -T -c \"ut image_loader\"\n+\n+The tests use a mock backend that copies from a RAM buffer, exercising\n+all core logic paths: mapping, caching, extending, lookup, table-full\n+handling, and cleanup.\ndiff --git a/doc/develop/index.rst b/doc/develop/index.rst\nindex 3c044e67927..90bd6e8ac8a 100644\n--- a/doc/develop/index.rst\n+++ b/doc/develop/index.rst\n@@ -32,6 +32,7 @@ Implementation\n \n directories\n bloblist\n+ bootm-storage\n bootstd/index\n ci_testing\n commands\ndiff --git a/doc/usage/fit/index.rst b/doc/usage/fit/index.rst\nindex 6c78d8584ed..d3ad4595892 100644\n--- a/doc/usage/fit/index.rst\n+++ b/doc/usage/fit/index.rst\n@@ -26,6 +26,7 @@ images that it reads and boots. Documentation about FIT is available in\n sign-configs\n sign-images\n source_file_format\n+ storage-boot\n uefi\n update3\n update_uboot\ndiff --git a/doc/usage/fit/storage-boot.rst b/doc/usage/fit/storage-boot.rst\nnew file mode 100644\nindex 00000000000..55b1d6090de\n--- /dev/null\n+++ b/doc/usage/fit/storage-boot.rst\n@@ -0,0 +1,201 @@\n+.. SPDX-License-Identifier: GPL-2.0+\n+\n+Booting from Storage Devices\n+============================\n+\n+Overview\n+--------\n+\n+Traditionally, ``bootm`` expects a FIT image to already be present in RAM\n+at a given address. This requires a separate ``load`` command (e.g.\n+``fatload``, ``nand read``, ``ubi read``) to bring the entire image into\n+memory before ``bootm`` can inspect it.\n+\n+With storage-backed boot, ``bootm`` can read a FIT image directly from a\n+block device partition, MTD partition, or UBI volume. Only the metadata\n+(FDT structure) is loaded initially; sub-images (kernel, device tree,\n+ramdisk, loadables) are loaded on demand as ``bootm`` processes them.\n+Filesystem sub-images (``IH_TYPE_FILESYSTEM``) are never read at all.\n+\n+This is particularly useful for:\n+\n+- Boards with limited RAM where loading the full image is impractical\n+- FIT images containing large filesystem sub-images that should not be\n+ loaded into RAM\n+- Simplifying boot scripts by combining the load and boot steps\n+\n+Syntax\n+------\n+\n+.. code-block:: none\n+\n+ bootm mmc <dev>:<part>[#conf[#overlay...]] [initrd [fdt]]\n+ bootm mtd <name>[#conf[#overlay...]] [initrd [fdt]]\n+ bootm ubi <volume>[#conf[#overlay...]] [initrd [fdt]]\n+\n+The device-type keyword (``mmc``, ``mtd``, ``ubi``) selects the storage\n+backend. The device specifier identifies the source:\n+\n+============ ======================================\n+Keyword Device specifier\n+============ ======================================\n+``mmc`` ``<dev>:<part>`` or ``<dev>#<name>`` — partition by number or name\n+``mtd`` MTD device or partition name\n+``ubi`` UBI volume name\n+============ ======================================\n+\n+The optional ``#conf`` suffix selects a FIT configuration by name,\n+exactly as with the traditional ``bootm addr#conf`` syntax. Additional\n+``#overlay`` suffixes select device-tree overlays to apply on top of the\n+base configuration.\n+\n+Examples\n+--------\n+\n+Boot from eMMC partition 4::\n+\n+ bootm mmc 0:4\n+\n+Boot from eMMC partition 4, selecting FIT configuration ``config-2``::\n+\n+ bootm mmc 0:4#config-2\n+\n+Boot from eMMC with a configuration and two overlays::\n+\n+ bootm mmc 0:4#config-1#overlay-wifi#overlay-lcd\n+\n+Boot from an MTD partition named ``firmware``::\n+\n+ bootm mtd firmware\n+\n+Boot from an MTD partition with a specific configuration::\n+\n+ bootm mtd firmware#config-1\n+\n+Boot from a UBI volume named ``kernel``::\n+\n+ bootm ubi kernel\n+\n+Boot from a UBI volume with a configuration::\n+\n+ bootm ubi kernel#config-1\n+\n+How It Works\n+------------\n+\n+1. ``bootm`` detects the device-type keyword and initialises an\n+ ``image_loader`` with the corresponding backend.\n+\n+2. The first 64 bytes of the image are read to detect the image format.\n+\n+3. For FIT images, the full FDT structure (metadata) is loaded so that\n+ all sub-image nodes, hashes, and configuration references are\n+ accessible.\n+\n+4. As ``bootm`` processes each sub-image (kernel, FDT, ramdisk,\n+ loadables), ``fit_image_load()`` reads only the needed data from\n+ storage — either to the sub-image's load address or to a scratch\n+ area.\n+\n+5. A translation table tracks which regions have already been loaded,\n+ avoiding redundant reads. Overlapping or sub-range requests are\n+ served from the existing mapping.\n+\n+6. After the boot attempt completes (whether successful or not), the\n+ loader's cleanup callback releases any held device references.\n+\n+Image Requirements: External Data\n+---------------------------------\n+\n+Selective sub-image loading **requires** that the FIT image is built with\n+**external data** (``mkimage -E``). In an external-data FIT, the FDT\n+structure (metadata) and the sub-image payloads are stored in separate\n+regions of the file:\n+\n+.. code-block:: none\n+\n+ +------------------+\n+ | FDT structure | ← metadata: image descriptions, hashes, configs\n+ | (compact) |\n+ +------------------+\n+ | padding |\n+ +------------------+\n+ | kernel data | ← loaded on demand\n+ +------------------+\n+ | fdt data | ← loaded on demand\n+ +------------------+\n+ | ramdisk data | ← loaded on demand\n+ +------------------+\n+ | rootfs data | ← skipped (IH_TYPE_FILESYSTEM)\n+ +------------------+\n+\n+Each sub-image node in the FDT records its ``data-position`` (or\n+``data-offset``) and ``data-size``, allowing the loader to seek directly\n+to the needed payload without reading any other sub-image data.\n+\n+To create a FIT with external data::\n+\n+ mkimage -E -f image.its image.itb\n+\n+The ``-E`` flag places sub-image payloads after the FDT structure. An\n+optional ``-p <pad>`` argument inserts extra padding between the FDT and\n+the data area for later in-place signing or updates.\n+\n+With **embedded data** (the default when ``-E`` is omitted), all sub-image\n+payloads are stored inline within the FDT ``data`` properties. The\n+entire FDT structure — including all payloads — must be loaded to parse\n+even the metadata. This means:\n+\n+- The ``bootm`` storage path will still work, but it loads the entire\n+ FIT blob (metadata + all payloads) into RAM when it reads the FDT\n+ structure. There is no selective loading benefit.\n+- Filesystem sub-images embedded in the FDT cannot be skipped — they\n+ are part of the FDT blob that must be read to access the metadata.\n+\n+In summary:\n+\n+================ =============== ================ ====================\n+FIT type Selective load Skip filesystem RAM savings\n+================ =============== ================ ====================\n+External data Yes Yes Significant\n+Embedded data No No None (full image)\n+================ =============== ================ ====================\n+\n+**Recommendation:** Always use ``mkimage -E`` when building FIT images\n+intended for storage-backed boot.\n+\n+Filesystem Sub-images\n+---------------------\n+\n+FIT images may contain sub-images of type ``IH_TYPE_FILESYSTEM`` (e.g. a\n+root filesystem squashfs). These are intended to remain on the storage\n+device and be mounted at runtime — not loaded into RAM.\n+\n+The storage-backed boot path recognises this type and skips it entirely:\n+no data is read from storage and no RAM is consumed. This is one of the\n+key advantages over the traditional ``load`` + ``bootm`` flow, where the\n+entire image (including any large filesystem blobs) must fit in RAM.\n+\n+Configuration\n+-------------\n+\n+The feature is gated by several Kconfig options:\n+\n+``CONFIG_BOOTM_STORAGE``\n+ Master switch. Depends on ``CMDLINE``, ``FIT``, and\n+ ``IMAGE_LOADER``.\n+\n+``CONFIG_IMAGE_LOADER``\n+ The core on-demand loading framework.\n+\n+``CONFIG_IMAGE_LOADER_BLK``\n+ Block device backend (MMC, SATA, USB, etc.).\n+\n+``CONFIG_IMAGE_LOADER_MTD``\n+ MTD backend (SPI-NOR, SPI-NAND, parallel NAND, etc.).\n+\n+``CONFIG_IMAGE_LOADER_UBI``\n+ UBI volume backend.\n+\n+At least one backend must be enabled for ``CONFIG_BOOTM_STORAGE`` to be\n+useful.\n", "prefixes": [ "RFC", "12/20" ] }