Andrew Davis afd@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?re...
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