Hi Aneesh,
On 27.06.2011 08:29, Aneesh V 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).
Yes, surely I understand that currently U-Boot is not configurable enough to meet hard SPL constraints. But why don't we add the required configuration options instead of implementing the SPL thing separately? Again, maybe I'm missing something but it looks like not very difficult task to add the required configuration options and this approach seems to be more straight to me...
Aneesh, what's the state of your patches? I'm especially interrested in OMAP3 (AM3517) support. Maybe I will be able to help you.
I should be able to send out an updated revision of my series once we finalize on the new framework for SPL.
BTW, John Rigby had sent out a series sometime back for OMAP3 NAND SPL. 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.
Thanks for the pointers, I will take a look.
Regards, Ilya.