[U-Boot-Users] outline of bootm script

[Kumar Gala]

On Aug 6, 2008, at 2:55 PM, Jerry Van Baren wrote:

> 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.

This is a buyer-beware kinda of situation.  Think about a case that we  
are booting a kernel at a location of memory that NO hw (usb,  
interrupts, etc) would be touching.  In that case you an reasonable  
'bootm restore'

>> 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).

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?

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