In message 489A01A3.6000800@ge.com you wrote:
bootm restore (undo anything prep did, reset state tracking)
Ooo, that sounds hard. If we are only re-enabling interrupts/usb/caches it probably is manageable, but my hackles.
ACK. And if we really restore anything, than just interrupts and caches, but not any interfaces.
We could also have some "bootm query <foo>" to expose the internal state if that's useful. We could completely get rid of the various "env" vars that impact bootm and just make them state variables ("verify", "autostart", "bootm_size", "bootm_low", ...)
State is bad.
ACK.
Aside: verify should be an image verify command, not a env variable flag (see below). This is probably true of most of the current env
We alreay have a verify command. It's called "imls".
variables: the reason we need them is because we kept throwing stuff into "bootm" and then controlling it with env variables rather than having a sequence and controlling it with what commands are in the sequence. (Part of my simplification argument...)
Hint: keep it backwards compatible, please.
I also was thinking we should invent a new major/minor command as you outlined, but it didn't occur to me that "bootm" would be a good major command. This is a good idea: a bare "bootm <addr> (<addr>|-) <addr>" could be used for backward compatibility and "bootm <subcmd>" for New Improved[tm] functionality.
How do your differentiate beween <addr> and <subcmd> then?
Having said that, I was thinking and would advocate pushing functionality out of bootm and into other commands, as appropriate. As an example, bootm doesn't need to do *any* fdt stuff, the "fdt" built-in has all the capability we need (or should). The same may be also true about load_os and load_initrd - they are copy-with-(optional)- decompression operations (we may need additional commands for these).
ACK.
Philosophy: bootm should do only bootm stuff. It (probably) should not do any image stuff (find/copy/decompress/verify). It (probably) should not do any fdt stuff (board fixup, other?). Etc...
ACK.
Best regards,
Wolfgang Denk