Hi, On Thu, 26 Feb 2026 at 11:45, Tom Rini <[email protected]> wrote: > > On Wed, Feb 25, 2026 at 11:49:23PM +0000, Daniel Golle wrote: > > On Wed, Feb 25, 2026 at 04:16:11PM -0600, Tom Rini wrote: > > > On Wed, Feb 25, 2026 at 02:34:05PM +0000, Daniel Golle wrote:
[..] > > One thing which I'm anaway not interely decided about is whether to > > build fit_verity_build_params() (the function which reads the dm-verity > > parameters from FIT and generates the Linux cmdline arguments from that) > > on top of bootflow_cmdline_set_arg() or to just generate the whole > > string and use env_get(), env_set() on the "bootargs" env variable. > > > > > > Not using bootflow_cmdline_set_arg() would also mean that in the case of > > bootmeth_openwrt nothing would be using it, and that would free 688 > > bytes, while fit_verity_build_params() might get a very tiny bit larger, > > certainly less than that. > > > > The thing is that it looks to me like bootflow/bootmeth is meant to ignore > > "bootargs" and overwrites it just before boot. On the other hand, having > > a generic feature such as generting the dm-mod.create=... Linux kernel > > cmdline parameter from the values stored in FIT depend on bootmeth, or > > even a specific bootmeth, also seems wrong. > > > > I'd be happy to hear your opinion about that. > > It should probably exist outside of the bootflow/bootmeth code, yes. As > we start expanding the real usage of bootflow/bootmeth we do need to > make sure that it's not doing things that violate user expectations, so > I'm not 100% sure if we are or aren't doing anything odd with bootargs, > depending on the flow. We do have 'bootflow read' which reads the files and sets things up ready to boot. Bootstd is designed to keep the bootargs env var aligned which whatever is the current bootflow (bootflow select). But yes, it is useful to be able to do things 'manually' and we should try to avoid something which is automatic but cannot be decomposed for debugging, etc. [..] Regards, Simon
