diff options
| author | Rasmus Villemoes <[email protected]> | 2026-06-02 23:30:11 +0200 |
|---|---|---|
| committer | Tom Rini <[email protected]> | 2026-06-11 07:56:45 -0600 |
| commit | 7779540f093d8d09ee29e127c8b6a7cc455db27c (patch) | |
| tree | 0a9df420cf49c7a56f829ceeb7b08dbda6d16814 /contrib/apps/httpserver | |
| parent | c8523795d7967729c64292f9800d06952ee7b7ba (diff) | |
image-fit.c: introduce CONTROL_DTB_AS_FIT config knob
Having scripts embedded one way or the other in the U-Boot binary
means they are automatically verified/trusted by whatever mechanism
verifies U-Boot.
Writing those scripts in the built-in environment leads to
backslatitis and missing or wrong quoting and is generally not very
readable or maintainable.
Maintaining scripts in external files allows one
to have both syntax highlighting and to some extent apply shellcheck
on it (though U-Boot's shell is of course not quite POSIX sh, so some
'#shellcheck disable' directives are needed). Getting those into the
U-Boot binary is then a matter of having a suitable .dtsi file such as
/ {
images {
default = "boot";
boot {
description = "Bootscript";
data = /incbin/("boot.sh");
type = "script";
compression = "none";
};
factory-reset {
description = "Script for performing factory reset";
data = /incbin/("factory-reset.sh");
type = "script";
compression = "none";
};
};
};
and making that part of CONFIG_DEVICE_TREE_INCLUDES, so that U-Boot's
control DTB effectively doubles as a FIT image containing a few
"script" entries. At run-time, one's default bootcommand can then
simply be
source ${fdtcontroladdr}:boot
Except of course that the control DTB is in fact not quite a FIT
image. The lack of timestamp and description properties could
potentially be worked around (by just adding those via that same
.dtsi), but the no-@ check is not possible to get around. But since
the control dtb is by definition trusted, we can make an exception for
that particular address, if the new CONTROL_DTB_AS_FIT config option
is enabled.
One can of course build an ordinary FIT image with those
scripts. However, that requires extra steps in the boot command for
loading that script from storage, requires one to use "configurations"
for pointing at a single script to run, and signing the FIT image
using the same key used for verifying the kernel. Moreover, in certain
situations, such as bootstrapping/production, there is no place to
load that FIT image from, and it is much simpler to just have the
necessary scripts be part of the U-Boot image itself.
Reviewed-by: Simon Glass <[email protected]>
Signed-off-by: Rasmus Villemoes <[email protected]>
Diffstat (limited to 'contrib/apps/httpserver')
0 files changed, 0 insertions, 0 deletions
