[U-Boot-Users] outline of bootm script

[Jerry Van Baren <gerald.vanbaren@ge.com>]

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