[U-Boot-Users] outline of bootm script

[Kumar Gala]

On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote:

> In message <5E53E387-237D-480E- 
> A046-68AD7F9B90A5 at kernel.crashing.org> you wrote:
>>
>> one idea is having "stages" of bootm handled as sub commands:
>>
>> bootm start <args>
>> bootm prep    (disable interrupts, stop usb, disable caches)
> --- Point of no return here ---
>> 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])
>> bootm load_initrd
>> bootm jump
>>
>> bootm restore (undo anything prep did, reset state tracking)
>
> Note that you cannot recover / restore after starting to uncompress
> the image, because usually you will overwrite the exception vectors.

Normally that is true.. however there are some situations that its  
feasible.  For example if you are booting a kernel at a non-zero  
address.  We do this on 85xx HW.  Or if you are trying to boot a  
kernel on the second core of a dual core setup (at a non-zero  
address).  Both of these cases we can 'bootm restore' out of.

>> 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.
>
> Sounds like Fortran to me - let's have a big COMMON section ;-)
>
> I'm not sure if this leads to good design.

I'm trying to reduce have A LOT of control logic in the script.  There  
is a fair amount of state needed between the various 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", ...)
>
> I have to admit that I have no idea why "bootm_size" or "bootm_low"
> are needed. If we can drop these, all the better.

We use them for booting at non-zero locations.

> "verify" and "autostart"  must  be  kept  as  environment  variables,
> because that's the way how the user can influence the boot behaviour.
> Even  if you find a better way to implement this, they will be needed
> for backward compatibility.

Ok.  What did we decide 'autostart' means with regards to bootm?

>> Also, bootm would be the sequence of:
>>   bootm start <args>
>>   bootm prep
>>   bootm load_os
>>   bootm load_fdt
>>   bootm load_initrd
>>   bootm jump
>
> I'm asking myself if that order is technically necessary. IMHO it
> should be possible as well to move the load_fdt step before load_os
> and eventually before prep, too.

If you know the layout of memory than its not fully needed.  The issue  
is knowing how big the uncompress kernel is.

- k