[U-Boot] [PATCH v3 8/9] tegra: i2c: Enable new CONFIG_SYS_I2C framework

[Stephen Warren]

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:-(