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

[Simon Glass]

Hi Wolfgang,

On Thu, 22 Oct 2020 at 06:32, Wolfgang Denk <wd at denx.de> wrote:
>
> Dear Simon,
>
> In message <CAPnjgZ2Vn3oWAHy71smw-+fRo28HUA0K32DP6FPoGtjtK3XoFQ at mail.gmail.com> you wrote:
> >
> > 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.
>
> Hm... I fear that this is rather cementing the zboot support so we
> never get rid of it...
> >
> > 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.
>
> How about a command that takes this existing command line and
> "imports" it into a standard bootargs variable?
>
> > 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.
>
> Yes, we can.
>
> => env print commandline bootargs
> ## Error: "commandline" not defined
> ## Error: "bootargs" not defined
> => env set commandline 'This is a %A test for %U replacement.'
> => setexpr bootargs gsub %A boring "${commandline}"
> bootargs=This is a boring test for %U replacement.
> => setexpr bootargs gsub %U '${uuid}'
> bootargs=This is a boring test for ${uuid} replacement.
> => env print bootargs
> bootargs=This is a boring test for ${uuid} replacement.
>
> > 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:
>
> But we have all this already, even with regular expressions and
> (simple) backreferences.
>
>
> > > 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.
>
> Just insert a "run" there, and you are done with it.
>
> > 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.
>
> I think this is not so much a bootargs question (or at least it
> should not be it).  bootargs is just another environment variable
> without any specific properties except that it's content is being
> passed to the kerenl, so you want to have the needed variable
> substituion doen before that.
>
> It was an intentional decison not to do this automagically, based on
> the thinking that accorsing to UNNIX philosophy it is not each
> individual command which implements things like wildcard or variable
> substitution, but rather this is something the shell does for you,
> and the commands are dumb in this respect.  This works reasonably
> well, except that we don't pass bootargs as argument to the bootm
> command - rather it is done internally by default, this lacking the
> variable substituion.
>
> You may call this a design bug, and I will accept the blame for it.
>
> To me the obvious fix would be to correct this behavious such that
> we extend bootm to accept the bootargs argument as a command line
> parameter, thus enabling variable substitution there, too.
>
> As far as I'm concenred, I don't think this is necessary as all it
> takes to work around this is a single call of a "run" command which
> can do exactly that, too.
>
> But I agree, this is just a workaround, and it would be more
> consistent to pass bootargs as argument directly.
>
>
> And this is also the direction I see how the zboot stuff should be
> fixed:  import the Linux command line into the environment, modify
> it as needed (if necessary using regular expression matching /
> string substituion to fix it up to use common U-Boot variable
> names), and then pass it like the rest of the world to the kernel.
>
> > Can we step past the %U business? I think we can use the ${var} stuff
> > with some substitution.
>
> Don't we have that already?  What exactly is it you miss?

I have sent a new version of this series that uses ${var}.

Regards,
Simon