[U-Boot] Linux boot and list loading feature

[Heiko Schocher <hs@denx.de>]

Hello Aneesh,

Aneesh V wrote:
> Hi Simon,
> 
> On Monday 01 August 2011 07:43 PM, Simon Schwarz wrote:
>> Hi Aneesh,
>>
>> On 08/01/2011 02:56 PM, Aneesh V wrote:
>>> Hi Simon,
>>>
>>> On Monday 01 August 2011 04:50 PM, Simon Schwarz wrote:
>>>> Hi Aneesh,
>>>>
>>>> I am working on the OS booting right now and have a bigger change of
>>>> your code in spl.c in mind.
>>>>
>>>> Hope you can say one or two words what you think about it.
>>>>
>>>> THE PROBLEM
>>>> For the direct OS boot and in some other situations - env image e.g., I
>>>> have to load more than one image in SPL.
>>>>
>>>> This can be done by hardcoding these cases and use #ifdef or ifs to
>>>> switch between them. Or I can implement a general image loading with
>>>> lists.
>>>> (This was discussed here:
>>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345)
>>>
>>> At the outset, wonder why we can not use the default bootargs string in
>>> the kernel image instead of passing it from the bootloader. For direct
>>> kernel boot from SPL, that looks like the best option for me. Then we
>>> will not need all this. Am I missing something?
>>>
>>  From the documentation it is mandatory for ARM to pass ATAGS (or FDT I
>> assume): http://www.arm.linux.org.uk/developer/booting.php
>>
>> So I think your solution would work - but IMHO would be too simple.
>>
>> The beauty is that we can save the config of ATAGS/FDT directly in
>> u-boot and pass this image at the next boot to the SPL. This means we
>> can boot the exact same configuration with the SPL as with standard
>> u-boot - without recompiling the kernel. Trade-off: a more complex SPL.
> 
> If my suggestion works I would still prefer that. If you want better
> configurability you can always use u-boot! Direct kernel boot from SPL
> is likely to be used in production systems for improved boot-time,
> where it should be OK to hard-code the boot-args. Using u-boot seems to
> be a better option if changing bootargs frequently is a requirement.
> 
> Please note that any scheme that you comes up with should also work for
> FAT boot from SD/MMC card, which means you need to have a way of

Does this actually work?

> converting your ATAGS list into a file, reading it and so on. A lot of
> trouble without much value-add in my opinion(assuming that hard-coded
> bootargs works).
> 
> In the worst case I would prefer hard-coding bootargs in SPL in a
> config flag and using it to build the list in SPL.
> 
> I would love to hear others' views on this.

The pro for the way I pointed out here:
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/102345

is that we have no fix coded solution, instead we can add a list of
"binaries" to load in mem, and jump to the destination address.
In future we will have DT instead of ATAGS maybe + Ramdisk, or not
Linux, maybe an other OS, which needs n other binaries in mem
before starting ...

Or we can parse the state from a GPIO and load an u-boot instead
Linux ...

that was just an idea ...

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany