[U-Boot] OMAP (4) boot_params

[Albert ARIBAUD]

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 at 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,
-- 
Albert.