Kumar Gala wrote:
On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:
[snip]
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).
except for locating the fdt at the right location and dealing w/initrd (but that could possibly be fixed).
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...
This DOES NOT WORK... sorry I'm trying to make progress on this and I'm not getting suggestions on a solutions just gripes about what I'm suggesting.
The problem with breaking things up is that you HAVE to disable interrupts and USB before you can reasonable load the OS image. Are we could to add a command for each "prereq". How does a user know if they need to "disable_caches" on their board or not?
Understood, there are some things that inherently must be done in bootm. That is why it is a philosophy and not a rule. ;-)
Also there is logic in the bootm that knows how to layout the images based on the constraints of memory. Let use an example (assume OS image will be loaded at 0):
bootm 1000000 - fff00000
we load to 0, the resulting size is 1234151 bytes. So we set "filesize" to 0x12D4E7. Since the fdt is in flash we have to copy it to memory.
So what address do we copy it to? 0x12D4E7? No because we have to be 8-byte aligned. So 0x12D4F0? No because we have to ensure space for the kernel .bss. So we have to encode all that logic in the script? That's just asking for pain.
- k
I agree with you, ideally the script would be just a sequence of cmd && cmd && cmd && cmd with no conditionals other than, if a cmd failed, it aborts the sequence (I'm assuming the last "cmd" would be where the point of no return is embedded: copying the image over the interrupt vectors, etc.).
My thoughts are that addresses would be handled by setting env variables initially and/or as a side effect of a cmd (yeah, side effects are yucky) and what is currently hard-coded as conditionals in the code would be re-scripted as /n/ scripts, where /n/ is some subset of the permutations of however many conditionals the current bootm has.
We will have to see how it plays out in reality... gvb