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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot