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