Hi Lukas,
On 7/2/24 2:58 PM, Lukas Funke wrote:
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-...@weidmueller.com wrote:
From: Lukas Funke <lukas.fu...@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.
Yes, but this isn't an indirection the project has to support. We
currently support scripts that are in the images node to source. We
would need to support automatically running the script if it's in a conf
node and that'd be it.
To be clear, I am not blocking this (and I don't have any veto power
anyway :) ), just wanted to raise that something else already exists and
could be extended to fit your usecase.
Cheers,
Quentin
