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