[PATCH 0/2] Import environment variables from FIT configuration

Lukas Funke lukas.funke-oss at weidmueller.com
Tue Jul 2 13:01:19 CEST 2024


Hi Quentin,

On 02.07.2024 11:16, Quentin Schulz wrote:
> Hi Lukas,
> 
> On 7/2/24 8:48 AM, lukas.funke-oss at weidmueller.com wrote:
>> From: Lukas Funke <lukas.funke at 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 
per default. I would also change current behaviour. For env variables I 
see no harm.

Please let me know what you think.

Cheers
  - Lukas

> 
> Cheers,
> Quentin



More information about the U-Boot mailing list