[U-Boot] OMAP (4) boot_params

[Albert ARIBAUD <albert.u.boot@aribaud.net>]

Hi Michael,

On Wed, 3 Apr 2013 09:45:19 -0400, Michael Cashwell
<mboards@prograde.net> wrote:

> On Apr 3, 2013, at 1:56 AM, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> 
> > (please wrap your line around 70 chars max)
> 
> I've never understood why this is useful. [...]

... but apparently you managed to do it, thanks.

> > On Tue, 2 Apr 2013 18:39:17 -0400, Michael Cashwell
> > <mboards@prograde.net> wrote:
> > 
> >> 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.
> >> 
> >> ...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.
> 
> Yes, that was my thinking too. Surely clearing data after code has set
> it can't be right.

With all due respect, the documentation can with greater legitimately
turn your admonition around and ask that you please refrain from
setting BSS or data variables when the C runtime environment has not
been set. :)

IOW, what is wrong here is writing to a BSS variable before you're
allowed to as per the rules under which your code is running.

> > 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).
> 
> OK, here we have an unfortunate name overloading. The boot_params here
> is specifically an OMAP handoff from the CPU's internal boot ROM to SPL
> and then from SPL to u-boot. (The same code paths are involved.) It's
> totally unrelated to the the boot_params passed to the Linux kernel.
> 
> Since it's confusing maybe a renaming is called for as well.

Indeed. Plus, if it is shared data, it should definitely be mapped at a
fixed memory location or copied from stage to stage (the latter only if
the former is impossible)

> Best regards,
> -Mike

Amicalement,
-- 
Albert.