[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.

No, I'll go try and find it and take a look.

> [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?

I thought it was very similar to falcon mode, but reading
doc/README.falcon, it's actually pretty different.

My use-case is that as a kernel developer, I want to repeatedly boot
new kernels. I can do the following now:

* Copy new kernel to SD card, put it in the target system, reboot it
* Copy new kernel to TFTP server, reboot target

Either of these are slower than I'd like either due to swapping SD
cards about, or slow TFTP transfers. Tegra at least has another boot
option: When the system boots, it can immediately go into special mode
whereby a USB-hosted protocol can be used download arbitrary code to
SDRAM and execute it. I want to make that downloaded code be the
zImage, perhaps with some stuff concatenated on the front to do a
little basic initialization first, e.g. setting up caches, setting r2
to point at a DTB, etc.

Now, I was hoping to re-use some code from U-Boot as the stuff I
concatenate with the zImage, so I wouldn't have to maintain it
separately. The bits I need area almost just the SPL, although since
our SPL and main U-Boot run on different CPUs, I also need a bit extra
CPU initialization, so for now I hacked up a very simple stub to do this.

Finally, I was then hoping to be able to burn that concatenated image
into flash and have the system always boot it. This is the part that's
most similar to falcon mode, I think.

My use case here is for that flashed kernel/initrd be able to choose a
boot target (SD, TFTP, ...), get a kernel from there, and kexec it.
That would make the kernel+initrd replace the main U-Boot binary. Then
I can write bash/... scripts and use kernel features for my boot menu,
rather than U-Boot scripts.