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:
- AVP boot code, to start the main CPU complex
- Main CPU low-level initialization
- 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?