Skip to content

Commit 1be2a60

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. Add a table indicating how this should be implemented. Describe how the option works in the 'usage' section. Signed-off-by: Simon Glass <[email protected]>
1 parent decd707 commit 1be2a60

File tree

2 files changed

+57
-1
lines changed

2 files changed

+57
-1
lines changed

source/chapter2-source-file-format.rst

Lines changed: 15 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,13 +626,22 @@ 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 necessarily contain an executable
633+
image, i.e. kernel or firmware. The configuration's images may be loaded
634+
into memory for use by the executable image, which comes from another
635+
configuration or FIT. 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

627640
Older, 2.4 kernel and 2.6 non-FDT kernel do not use FDT blob, in such cases
628641
'struct bd_info' must be passed instead of FDT blob, thus fdt property *must
629642
not* be specified in a configuration node.
630643

644+
631645
Configuration-signature nodes
632646
-----------------------------
633647

source/chapter3-usage.rst

Lines changed: 42 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -192,6 +192,48 @@ 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+
225+
Specifically, the 'load-only' property adjusts the meaning of loading a FIT, so
226+
that implementors should follow the following behaviour:
227+
228+
=================== ================== ====================
229+
'load-only' present Executable present Behaviour
230+
=================== ================== ====================
231+
no no Raise an error
232+
yes no Only load the images
233+
no yes Execute binary
234+
yes yes Execute binary
235+
=================== ================== ====================
236+
195237
Security
196238
--------
197239

0 commit comments

Comments
 (0)