Kumar Gala wrote:
On Aug 5, 2008, at 9:33 PM, Jerry Van Baren wrote:
Kumar Gala wrote:
here's a rough start at an outline for the bootm script based on the code (I've only outlined the Linux/PPC boot case its seems the most complicated). One of the first things we clearly need is a imload command. Thoughts on the various disable_{interrupts, usb, caches} ?
- k
Another rough start on an outline (only cmd_bootm.c, need to add image.c information): http://www.denx.de/wiki/view/U-Boot/UBootFdtInfo#Refactoring_bootm
Goal is to identify the major pieces of the sequence, identify what commands we have and what we need to make a scripted equivalent sequence for (ultimately) each path through the sequence.
I added a few bullets about functionality I'd like to see the new sequence to be capable of it.
Thanks for updating the page.
one idea is having "stages" of bootm handled as sub commands:
bootm start <args> bootm prep (disable interrupts, stop usb, disable caches) 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])
fdt boardsetup - absolutely!
bootm load_initrd bootm jump
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.
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.
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.
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 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...)
Also, bootm would be the sequence of: bootm start <args> bootm prep bootm load_os bootm load_fdt bootm load_initrd bootm jump
comments?
- k
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.
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).
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...
Thanks, gvb