[U-Boot-Users] outline of bootm script

[Kumar Gala]

On Aug 6, 2008, at 3:26 PM, Wolfgang Denk wrote:

> In message  
> <B754896C-6D4C-43B0-8F84-062884E569C2 at kernel.crashing.org> you wrote:
>>
>>> 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.
>
> Agreed. But compare the benefit of such a soft recovery (versus a
> reset of the board) against the added complexity and irregular user
> interface - on this board you can write to low RAM, on the other board
> you crash the system; on one board the system recovers after a failed
> attempt to load a kernel, but maybe not always, just in certain cases,
> on another board it always resets the board.
>
> KISS. Define a point of no return, and after that, recovery == reset.

Its not about recovery.  Its about using the mechanism to setup the  
memory state to run and than using another command to jump.  In a dual  
core setup we can run u-boot on core0 and use all the bootm commands  
but 'jump' to setup the state of memory.  Than we can use the 'cpu'  
command to 'release' core1 to run that OS.

>>> 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.
>
> Why is this needed?

We have customers that want to run at non-zero address.  Think of a  
dual core chip with a custom OS that 0 and Linux running at 256M.  (We  
allow this and have customers running in such situations).

>>> "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?
>
> Yes, of course we did. It means exactly what's documented in the
> manual.

ok.

- k