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