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

[Simon Glass]

Hi Lukas,

On Wed, 3 Jul 2024 at 02:29, Lukas Funke
<lukas.funke-oss at weidmueller.com> wrote:
>
> 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.

This ended up in my queue.

Is this used with boot scripts? We are trying to move boards to
bootstd and get rid of the scripts, for common cases.

If you are wanting to specify the verity hash, I think it would be
better to add that information. VBE[1] has the concept of 'OS
requests' - see static bootmeth_vbe_ft_fixup() for the implementation.

Here it seems we have a request for the verity hash? So can we add it
that way? Are there any other features you are needed?

Using environment variables seems a bit ad-hoc to me.

Regards,
Simon

[1] https://docs.u-boot.org/en/latest/develop/vbe.html