[PATCH 0/2] allow control DTB to double as "FIT image"

[Quentin Schulz]

Hi Rasmus,

On 5/12/26 6:16 PM, Rasmus Villemoes wrote:
> The commit message for patch 1 explains what it is I'd like to be able
> to do, but here's some more background:
> 

For reference:

"""
Writing those scripts in the built-in environment leads to
backslatitis and missing or wrong quoting and is generally not very
readable or maintainable.
"""

> For a long time, we've embedded the boot script in the U-Boot binary
> by building a bootscript.itb, and using a .dtsi like
> 
>    / {
>            config {
>                   bootscript = /incbin/("/path/to/bootscript.itb");
>            };
>    };
> 
> which in turn is mentioned in CONFIG_DEVICE_TREE_INCLUDES, that
> bootscript.itb FIT image has been embedded in U-Boot's control
> dtb. Running that was then a matter of doing
> 
>    fdt addr ${fdtcontroladdr} && fdt get addr bsaddr /config bootscript && source ${bsaddr}
> 
> There are a couple of advantage of having the bootscript (and other
> script logic) embedded in the U-Boot binary. First, there's no need to
> figure out some separate partition to store the script in, and making
> sure that gets updated whenever the bootloader itself does. Second,
> one doesn't need to worry about verifying the script; whatever steps
> one needs to take to implement secure boot for U-Boot itself will by
> necessity also cover the control dtb (if nothing else then because
> that's where the public key for the kernel verification lives).
> 
> Now with the stricter requirements of libfdt starting from v2026.04,
> the above command no longer worked, or only half the time, because the
> embedded FIT image may not land on an 8-byte aligned address. So that
> line had to be changed a little (line breaks added)
> 
>    fdt addr ${fdtcontroladdr}
>      && fdt get addr bsaddr /config bootscript
>      && fdt get size bssize /config bootscript
>      && cp.b ${bsaddr} ${loadaddr} ${bssize}
>      && source ${loadaddr}
> 
> which is getting quite unwieldy.
> 
> Then it struck me that one could perhaps simplify all of this quite a
> lot: Cut out the intermediate bootscript.itb, just create a .dtsi
> which directly puts a /images node inside the control dtb
> 
> / {
>    	images {
> 		default = "bootscript";
> 		bootscript {
> 			description = "Boot script";
> 			data = /incbin/("/path/to/bootscript.sh");
> 			type = "script";
> 			compression = "none";
> 		};
> 	};
> };
> 
> and treat the control dtb itself as a FIT image; so the command to put
> in $bootcmd becomes simply
> 
>    source ${fdtcontroladdr}:bootscript
> 
> and embedding other pieces of callable scripts is quite trivial.
> 
> And that almost works out-of-the-box, except for the fit_check_format() sanity check.
> 
> I realize this is a bit of a hack, but I do think it's somewhat
> elegant, and avoids inventing a whole lot of extra infrastructure for
> allowing one to embed larger scripts and invoke them from the shell. I
> am of course happy to put this exemption for gd->fdt_blob under a
> CONFIG_ knob if that is deemed necessary.
> 

Have you tried to use the text-based environment mechanism as described 
in 
https://docs.u-boot.org/en/latest/usage/environment.html#text-based-environment? 
(I've learned about this only very recently with the Apple devices being 
migrated to it)

Cheers,
Quentin