Hi Wolfgang, On Wed, 21 Oct 2020 at 01:16, Wolfgang Denk <w...@denx.de> wrote: > > Dear Simon, > > In message > <CAPnjgZ1SfwRa_LXh0zu3Oug=gleuqx5mdccvqw90-fv5hvx...@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