Hi Quentin,
On 02.07.2024 13:37, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 1:01 PM, Lukas Funke wrote:
Hi Quentin,
On 02.07.2024 11:16, Quentin Schulz wrote:
Hi Lukas,
On 7/2/24 8:48 AM, lukas.funke-oss@weidmueller.com wrote:
From: Lukas Funke lukas.funke@weidmueller.com
This series enables U-Boot to import environment variables from the selectd FIT configuration. One use-case is that the overall build process enriches the FIT configuration node with dm-verity information which should be injected into the kernel commandline. U-Boot will then read these (possibly signed) environment variables and put them into the actual Kernel commandline using variable replacement (see CONFIG_BOOTARGS_SUBST).
Example:
Config: CONFIG_BOOTARGS_SUBST=y CONFIG_ENV_IMPORT_FIT_CONF=y
FIT: configurations { default = "conf-1"; conf-1 { kernel = "kernel-1"; fdt = "fdt-1"; env,dm-verity-args = "dm-mod.create=..."; env,bar = "someothervalue"; }; };
U-Boot cmdline: => env set bootargs="rootfstype=squashfs root=/dev/xyz ${dm-verity-args} ro" => boot
Kernel cmdline: Kernel command line: rootfstype=squashfs ... dm-mod.create= ...
I think FIT supports storing U-Boot scripts and running those via `source` command (usually the file extension is .scr).
I do not know if there's support for automatically loading this .scr as part of a config node though, but if there isn't I guess it'd make more sense to support this case than to come up with yet another implementation?
What do you think?
I wasn't aware of this, thanks for pointing it out!
This patch was mainly inspired by the dm-vertiy use-case which requires just env-variables and no (complex) scripts.
There is currently no mechanism to source/run such scripts automatically.
How would you distinguish between scripts that should run automatically und scripts which are sourced by a specific board/shell-script implementation? I guess there are good reasons to not run such scripts
Scripts in conf would be automatically run? Scripts not in conf needs to be executed via `source` command for example?
Not sure what to do if you want a script linked to a conf but not run automatically though (and what would be the use-case?). I guess you could have a script automatically run (so in conf node) that sets a variable to know where to look for the other script that isn't automatically executed?
Sounds like yet another level of indirection. Not sure if this a good or a bad thing, but makes things definitely more complicated.
per default. I would also change current behaviour. For env variables I see no harm.
If the env properties in the FIT image are part of the checksum and signature of the conf node, which is necessary for secure boot, I guess "no harm" fits the bill.
To my current knowledge the configuration node itself is signed. Thus, all env-properties are signed. Please correct me if I'm wrong.
Cheers, Quentin