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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
