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

[Lukas Funke]

Hi Quentin,

On 02.07.2024 15:05, Quentin Schulz wrote:
> 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-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 
>>>
>>> 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.

Thanks for the clarification, I appreciate your input.

Yeah, I guess it works somehow using the current 'source'-cmd approach. 
Yocto even supports the integration of a U-Boot environment into the 
kernel FIT-image. However, I think the integration for some dm-vertiy 
env variables is quite cumbersome using this approach. I'd rather prefer 
to have the variables directly in the fit-configuration since they have 
no script character. But this might just be personal preference.

> 
> Cheers,
> Quentin