On Aug 6, 2008, at 2:41 PM, Wolfgang Denk wrote:
> In message <5E53E387-237D-480E-
> [EMAIL PROTECTED]> 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
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
U-Boot-Users mailing list
U-Boot-Users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/u-boot-users
