Hi Michael,
(please wrap your line around 70 chars max)
I won't comment on the 'u-boot' part of your message as it is quite SPL-vs-U-Boot- and OMAP-specific, and I prefer to leave this to people better suited for this. However, on the low level init front:
On Tue, 2 Apr 2013 18:39:17 -0400, Michael Cashwell mboards@prograde.net wrote:
Greetings,
I've been fighting with SPL passing not boot_params properly to u-boot on OMAP4. There are many layers to this onion but I've tracked the bulk of the problem down to the following issues.
--- SPL ---
arch/arm/cpu/armv7/omap-common/hwinit-common.c sets a pointer to the SPL's &boot_params correctly (cpu_init_crit->lowlevel_init->s_init) but the definition of that pointer in common/spl/spl.c:
u32 *boot_params_ptr = NULL;
puts it into the spl bss section (in SDRAM) which is cleared long after cpu_init_crit(). Making that:
u32 *boot_params_ptr __attribute__ ((section(".data")));
allows the pointer to be in SPL data section (SRAM) and still have its value by the time image_entry() is called. But common/spl/spl.c is not omap-specific so changes there are a concern.
If I'm not mistaken, lowlevel_init() is not supposed to use BSS at all, as the C runtime has not been initialized yet -- precisely, the BSS clearing loop long after the cpu_init_crit() call belongs to the code that sets up this environment.
Besides, it seems like SPL does not jump directly to Linux but to U-Boot, so U-Boot itself should set up the boot params, not SPL, which can at best prepare and store values in static RAM not mapped as data or BSS in either SPL or U-Boot (this is normally done through GD).
Next, image_entry() is called with the argument being indirected an extra time: u32 boot_params_ptr_addr = (u32)&boot_params_ptr; image_entry((u32 *)boot_params_ptr_addr);
That extra level of indirection is never dealt with (on ARM anyway) and it ends up passing junk to u-boot. I've tested replacing those lines with: image_entry((u32 *)boot_params_ptr);
and that passes a correct address in r0 to lowlevel_init.S in u-boot.
This has to be investigated indeed.
Amicalement,