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

[Tom Rini]

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.

[snip]
> Another thing that made me think of this: I briefly experimented with
> getting Tegra's U-Boot SPL to jump directly to a Linux zImage. A few
> things were missing, since Tegra's SPL runs on the AVP CPU not the main
> CPU, and hence never initializes anything on the main CPU, leaving that
> responsibility to the main U-Boot binary). Hence, some main-CPU cache
> setup was missing from Tegra's SPL. Solving this issue requires 3
> separate binaries:
> 
> 1) AVP boot code, to start the main CPU complex
> 2) Main CPU low-level initialization
> 3) Main U-Boot binary
> 
> To boot U-Boot, all 3 steps would be used.
> 
> To directly boot a zImage, only steps (1) and (2) would be needed.
> 
> Right now, we need to hack up a separate binary for (2) for the
> boot-a-zImage-directly case, and hence concatenate SPL, CPU init,
> zImage. It'd be nice if the "CPU init" part of that set of binaries was
> something we could easily pull out of the U-Boot build process, rather
> than something custom.

So I guess you're trying to do something that's not quite falcon mode
here?

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20130805/f9e55fec/attachment.pgp>