Andrew Davis <a...@ti.com> writes: >>>>>>>> * uEnv.txt processing >>>>>>> >>>>>>> What command can do this? >>>>>>> >>>>>> >>>>>> run envboot; >>>>>> >>>>>> https://source.denx.de/u-boot/u-boot/-/blob/master/include/env/ti/mmc.env?ref_type=heads#L20 >>>>> >>>>> This could be a new bootmeth which looks for uenv.txt on available >>>>> devices. It might be better to put the env in a FIT or something with >>>>> a checksum. >> >> We use non-FIT boot as well for our non HS platforms, I think the new >> bootmeth might be helpful as you mentioned, would have to look at this >> more as I thought bootmeth is supposed to boot a platform at the end >> only but it seems like here we'll be combining this bootmeth ( that'll >> just import the env ) and then other bootmeth will actually boot Linux. >> > > As long as bootmeths can perform an action then continue with other > bootmeths that could work. This might require complex logic though. > For instance the uenv.txt bootmeth would only need run on some subset > of available bootdevs, and it should scan all those devs for uenv.txt > first, before the Linux finding bootmeths start. >
It doesn't make sense to treat envboot as a bootmeth because it's really not about a way of booting but more often just used to modify environment variables before going through another boot flow (although you could define/run env variables that performs it's own boot). It may be better to think of it as a preprocessing step before a bootflow scan. Some other thoughts - envboot is more of a hacky way to solve things: 1) As we move more towards secure boot as the standard, we should understand what use cases the hacks are working around and properly support those use cases. 2) But I don't think we should just remove it altogether because it is a very powerful 'feature' during the development phases to try out changes without modifying/rebuilding/reflashing u-boot. 3) This is a TI feature. Are others solving this need in a better way? Jon
