Skip to content

Commit 0d5f7dd

Browse files
committed
Add explicit support for multi-step loading
There are cases where multiple FITs must be loaded to complete a boot, e.g. where the first FIT contains devicetrees and the second contains the OS. At present this is not permitted, since every FIT must contain a bootable kernel (or firmware). Add a new 'load-only' property to indicate that a configuration can be loaded but not booted. Describe how this works in the 'usage' section. Signed-off-by: Simon Glass <[email protected]>
1 parent decd707 commit 0d5f7dd

File tree

2 files changed

+44
-1
lines changed

2 files changed

+44
-1
lines changed

source/chapter2-source-file-format.rst

Lines changed: 14 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -574,10 +574,15 @@ Mandatory properties
574574
description
575575
Textual configuration description.
576576

577+
Conditionally mandatory property
578+
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
579+
577580
kernel or firmware
578581
Unit name of the corresponding :index:`kernel` or :index:`firmware`
579582
(u-boot, op-tee, etc) image. If both "kernel" and "firmware" are specified,
580-
control is passed to the firmware image.
583+
control is passed to the firmware image. For `load_only`_ images, these two
584+
properties are optional.
585+
581586

582587
Optional properties
583588
~~~~~~~~~~~~~~~~~~~
@@ -621,6 +626,14 @@ compatible
621626
Note that U-Boot requires the :index:`CONFIG_FIT_BEST_MATCH` option to be
622627
enabled for this matching to work.
623628

629+
.. _load_only:
630+
631+
load-only
632+
Indicates that this configuration does not contain an executable image,
633+
i.e. kernel or firmware. The configuration may be loaded into memory for
634+
use by the executable image, which comes from another configuration or FIT.
635+
See see :ref:`multi_step`.
636+
624637
The FDT blob is required to properly boot FDT-based kernel, so the minimal
625638
configuration for 2.6 FDT kernel is (kernel, fdt) pair.
626639

source/chapter3-usage.rst

Lines changed: 30 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -192,6 +192,36 @@ before SPL), then TPL will only load images with a phase of "spl". This allows
192192
all images to be provided in a single FIT, with each phase pulling out what is
193193
needed as the boot proceeds.
194194

195+
.. _multi_step:
196+
197+
Multi-step loading
198+
------------------
199+
200+
The most common use of a FIT is where each configuration contains everything
201+
needed to boot. For example, on ARM systems a configuration contains a kernel,
202+
devicetree(s) and a ramdisk if needed. This approach is widely used on embedded
203+
systems.
204+
205+
This approach is not always desirable, however, particularly when the firmware
206+
and the OS are supplied by different parties. In that case, the devicetree may
207+
be provided by the firmware with the other pieces coming from the OS. This
208+
means that FIT may omit the devicetree images.
209+
210+
With devicetree in particular, it is common for the OS to provide its own
211+
version, or perhaps a devicetree overlay to add some new nodes and properties.
212+
213+
Obviously if the OS has to provide a devicetree for every device, the OS files
214+
would become very large. A middle path could be that the hardware vendor
215+
provides a FIT on a boot partition, containing devicetrees for hardware
216+
supported by that vendor. Then the bootloader can load that FIT to get just the
217+
devicetree, followed by the main FIT to load the OS.
218+
219+
To enable this last case, add a :ref:`load_only` property to the configuration.
220+
This signals to the bootloader that it should not require an executable (i.e.
221+
kernel or firmware), nor should it try to boot with this configuration. Booting
222+
then becomes a two-step process: load one FIT to obtain the devicetree, then
223+
another to obtain the OS. Only the second FIT is booted.
224+
195225
Security
196226
--------
197227

0 commit comments

Comments
 (0)