In message 5E53E387-237D-480E-A046-68AD7F9B90A5@kernel.crashing.org you wrote:
one idea is having "stages" of bootm handled as sub commands:
bootm start <args> bootm prep (disable interrupts, stop usb, disable caches)
--- Point of no return here ---
bootm load_os (decompress OS image) bootm load_fdt(relocates fdt to proper place, setup bootargs, initrd prep, board setup?? [or do via fdt boardsetup command]) bootm load_initrd bootm jump
bootm restore (undo anything prep did, reset state tracking)
Note that you cannot recover / restore after starting to uncompress the image, because usually you will overwrite the exception vectors.
And we keep state around so the next stage can run w/o a lot of arguments and you have to execute these in order, and only once. But you can intermix other commands between the stages.
Sounds like Fortran to me - let's have a big COMMON section ;-)
I'm not sure if this leads to good design.
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", ...)
I have to admit that I have no idea why "bootm_size" or "bootm_low" are needed. If we can drop these, all the better.
"verify" and "autostart" must be kept as environment variables, because that's the way how the user can influence the boot behaviour. Even if you find a better way to implement this, they will be needed for backward compatibility.
Also, bootm would be the sequence of: bootm start <args> bootm prep bootm load_os bootm load_fdt bootm load_initrd bootm jump
I'm asking myself if that order is technically necessary. IMHO it should be possible as well to move the load_fdt step before load_os and eventually before prep, too.
Best regards,
Wolfgang Denk