Hi Wolfgang, On Thu, 22 Oct 2020 at 06:32, Wolfgang Denk <w...@denx.de> wrote: > > Dear Simon, > > In message > <capnjgz2vn3owahy71smw-+fro28hua0k32dp6fpogtjtk3x...@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