On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote:
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.
Normally that is true.. however there are some situations that its feasible. For example if you are booting a kernel at a non-zero address. We do this on 85xx HW. Or if you are trying to boot a kernel on the second core of a dual core setup (at a non-zero address). Both of these cases we can 'bootm restore' out of.
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.
I'm trying to reduce have A LOT of control logic in the script. There is a fair amount of state needed between the various stages.
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.
We use them for booting at non-zero locations.
"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.
Ok. What did we decide 'autostart' means with regards to bootm?
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.
If you know the layout of memory than its not fully needed. The issue is knowing how big the uncompress kernel is.
- k