Dear Aneesh,
In message 4E080733.2030001@ti.com you wrote:
I wonder why do we need this whole spl thing in the first place (well, surely I know what they are used for but why do we need a separate entity for this)? Isn't it just the same U-Boot in, well, very special configuration (minimal set of drivers, no shell, etc)? Why do we need a whole shadow tree at spl/ instead of just providing the _configuration_?
Am I missing something?
The reason is that the regular U-Boot is not configurable enough to build the extremely small images that should fit in internal RAM. The last time I attempted, I ended up getting an ~60KB image for OMAP4(that too without any of the hardware initialization I am adding in my SPL work).
This statement does not make much sense to me. If we can do it in the spl/ directory, we should be able to do it in any other directory as well. The worst to happen is that we have to keep two setsof object files separated, but chosing a different suffix should be sufficient.
BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL.
Yes, but AFAIR he never followed up to the requested changes.
That can be integrated with my work and we will get an SPL that supports both MMC and NAND. I guess Simon Schwarz is also doing some work lately on OMAP3.
OK, so we have all the more reason to do this thorougly now.
Best regards,
Wolfgang Denk