[U-Boot-Users] outline of bootm script

Kumar Gala
2008-08-06T20:05:17Z

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