[U-Boot-Users] outline of bootm script

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

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