[U-Boot] Linux boot and list loading feature

[Simon Schwarz <simonschwarzcor@googlemail.com>]

Hi Aneesh,

sorry for answering this late...

On 08/02/2011 02:41 PM, 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.

I see your point. I will try both approaches in my BA.

>
> 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
> 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).

This was something I didn't have on the radar. I haven't used FAT in 
u-boot. So we have a read-only implementation?

How are the chances to get this into mainline if it supports only NAND 
at first - but is designed to be able to be used with others also?

>
> 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.
>

So in conclusion: I will implement it. I will have to do this anyway for 
my BA. I know that there is some interest for this feature - so a 
prototype to base the discussion on is not too bad I think.

As soon as there is something runnable I will post it for discussion.

Regards
Simon