summaryrefslogtreecommitdiff
path: root/contrib/apps/httpserver
diff options
context:
space:
mode:
authorRasmus Villemoes <[email protected]>2026-06-02 23:30:11 +0200
committerTom Rini <[email protected]>2026-06-11 07:56:45 -0600
commit7779540f093d8d09ee29e127c8b6a7cc455db27c (patch)
tree0a9df420cf49c7a56f829ceeb7b08dbda6d16814 /contrib/apps/httpserver
parentc8523795d7967729c64292f9800d06952ee7b7ba (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