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

[Stephen Warren]

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.

There are at least the following separate things going on right now
(admittedly some of these are slightly loosely defined, and some are
currently lumped into the main image's _f _r steps/tables):

* Basic CPU initialization.

* Initializing SDRAM controller (not required on Tegra; boot ROM already
does this). This is what the SPL is typically used for.

* Tegra-specific: Run code on the AVP (boot) CPU which starts the main
CPU complex running. On Tegra, we've hijacked the SPL to do this
separate step.

* Copying U-Boot to SDRAM now it's available and/or performing
initialization steps that require SDRAM.

* Sizing SDRAM, perhaps by

* Relocating the U-Boot binary to top of RAM (at least if relocation is
enabled).

* The main U-Boot binary.

Some more steps I've probably forgotten while I write this email!

Now, obviously some of those steps run in a very restricted environment.

For example, on systems where the boot ROM doesn't exist or doesn't
enable SDRAM, then steps before U-Boot initializes it can't touch
.data/malloc etc.

It's probably not a good idea to make the code that initializes and
probes SDRAM have to retrieve information about the SPD I2C controller
(if one exists) from DT; it'd probably be better to hard-code the I2C
controller information into that part of U-Boot, and defer any complex
dynamic stuff to later. This is at least partially fallout from the
previous point.

The order of some of those bullet points above might even vary a little
depending on the SoC.

For example, on Tegra, we have to do basic CPU initialization on two
different CPUs; once on the AVP when we first start running any code at
all, and separately on the main CPU complex after it has been booted.
Those two CPUs are different ARM architectures too. And on Tegra we
don't have to initialize SDRAM at all; the boot ROM does it.

So, I wonder if it wouldn't be worth splitting U-Boot up into more
separate binaries for these steps, so that any restrictions on the steps
can be much better defined and segregated. Then, the final U-Boot binary
can be constructed not just by:

cat spl.bin u-boot.bin

But perhaps more like:

cat sdram-init.bin relocater.bin u-boot.bin

or something like that?

Everything in sdram-init.bin would use no .data (the linker script could
enforce this) and hard-coded devices. Everything in u-boot.bin could
immediately assume that SDRAM and .data was available, and use DT for
everything, and not need any pointer relocation fixup phase, since there
would be nothing in .data to fix up.

Each board or SoC could define a list of the steps they need, their
order, and the restrictions on their execution (e.g. no .data, ROMable
code, hard-coded vs. dynamic devices possibly from DT, etc.)

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.