On 08/05/2013 02:08 PM, Tom Rini wrote:
On Mon, Aug 05, 2013 at 01:21:50PM -0600, Stephen Warren wrote:
On 07/30/2013 02:00 PM, Stephen Warren wrote: ... (discussion of instantiating/initializing I2C devices from device tree, and the fact U-Boot attempts to do that before .data or malloc can be touched/used, which doesn't work) ...
It seems like much of U-Boot's initialization architecture simply wasn't designed to accommodate dynamically initializing devices from DT.
I thought about this a little over the weekend. I think the solution here may be to break up U-Boot initialization steps more explicitly, even into more separate binaries.
Have you seen the 'TPL' code Freescale has been posting? That might be a handy concept, but I'm concerned we're going to be heading towards N separate little programs, and that's possibly a big complex (and thus fragile) web.
TPL is certainly similar, but the implementation is pretty different.
On Tegra, the boot ROM initializes SDRAM, so there aren't any max size requirements on SPL/U-Boot; they're concatenated together in flash and both placed into SDRAM by the boot ROM in all cases. SPL+U-Boot is just one big binary as far as our boot ROM is concerned, but just happens to be made out of a few chunks that are concatenated together as far as the U-Boot build process is concerned.
So, my proposal to further split up the U-Boot binary was more to allow:
a) A more obvious boundary for various restrictions, such as lack of .data access, to applied or lifted.
b) Re-using some of the component parts of U-Boot to build other things.
Freescale's TPL patches are all about limitations on the size of the various components. Hence, each of SPL, TPL is a separate entity in flash too, and each contains a flash driver to read the next component in the chain.
I suppose the two concepts could be unified by simply having SPL/TPL on Tegra not contain any flash drivers, and both use the "jump to hard-coded address" method of dispatching to the next binary just as we do today for the SPL->u-boot.bin handoff. However, I'd still rather explicitly call out what each component binary is for with a per-board/soc list, rather than re-using the names SPL/TPL to do different things on different systems.
Not that I likely have any time to actually implement any of this:-(