[PATCH 11/11] bootm: Support string substitution in bootargs

[Simon Glass]

Hi Wolfgang,

On Wed, 21 Oct 2020 at 01:16, Wolfgang Denk <wd at denx.de> wrote:
>
> Dear Simon,
>
> In message <CAPnjgZ1SfwRa_LXh0zu3Oug=GLEUQx5MdCCvqW90-FV5hvX9uw at mail.gmail.com> you wrote:
> >
> > > Yes, it takes one additional step, but it's simple and does not need
> > > extra code.
> >
> > It is actually not simple, for three reasons:
> >
> > 1. With zboot the args come from the kernel setup.bin and must be modified
>
> Don't use zboot, then.  In my opinion, zboot is crap and should
> never have been added, but there were so many requests for it.
> Nevertheless, the use of crippleware is a sin that carries with it
> its own punishment.
>
> Don't do it, then.
>
> Or, if you feel there is some value in zboot that should be
> conserved, fix it to work like the rest of U-Boot.

Well my series does that to a large extent. It is much more like bootm
now, in that it is properly split into stages. I think it would be
possible to combine parts of it into bootm as a future step, although
it is non-trivial, and I think we should build out more tests first.

But zboot does make use of an existing command line and does all the
weird x86 processing, so I don't know how we could get rid of it.

>
> > 2. With Chrome OS the args come from the kernel partition and must be
> > augmented / substituted
>
> OK.  But then why can we not still use the standard variable
> substitution mechanism we already have?

I don't think the actual mechanism is a big deal. We could do a string
replace (does U-Boot support that?) of %U with ${uuid} for example, to
make it work for my case.

Or we could go with an idea I previously rejected, to just provide a
simple string replace feature, with any special characters in the
search string. For example:

setenv bootargs_repl "%U=${uuid} %P=${partid}"

>
> > 3. The above command cannot be in the same env var as anything else,
> > since substitution breaks in that case
>
> Sorry, I don't understand what you mean heare.  What is "the same
> env var" versus "anything else"?  Maybe you can give a specific example?

Did you see the 'run regen_scripts' script?

At present I can do

setenv uuid blah; setenv partid blah; bootm

but with your scheme I need the 'run regen_script' to set the
variables correctly, which is a real pain as my example shows.

>
>
> > So you end up with a really complicated mess of environment variables
> > and scripts that is barely manageable. I want it to be simple.
>
> Again, I can't follow you.  Why must there be a mess?
>
> > See here for example (this only deals with 3 above, not 1 and 2, which
> > would still need custom code without my series)
> >
> > https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/refs/heads/chromeos-v2013.06/include/configs/chromeos.h#204
>
> Sorry - all I see there is some complex settings if these make sense
> I can't tell) - but how would things be better if you could - for
> example - use "%U" instead of "${uuid}" as you suggested?

My point here is not about %U, it is about the pain of multiple stages
to get the variables right. WIth bootargs substitution we can just set
the variables and boot.

>
> Also, is your approach not necessarily limited? You can now think of
> a handful of variables you may want to pass, say root device, root
> partition, uuid, maybe MAC address etc.  But the next user will need
> kernel args that you did not think of - so how do we proceed?  Add
> all features anybody needs to that new code?  That certainly does
> not scale.  Or mix "%FOO" and "${foo}" style arguments?  That's even
> worse.  I really fail to see the benefits, I see only ugliness and
> problems.

These scripts are board-specific, so each board can do what it likes
here. But the nice thing is not having to manually build up the
bootargs.

Can we step past the %U business? I think we can use the ${var} stuff
with some substitution.

Regards,
Simon