Hi Michael,
On Wed, 3 Apr 2013 09:45:19 -0400, Michael Cashwell
<mboa...@prograde.net> wrote:
> On Apr 3, 2013, at 1:56 AM, Albert ARIBAUD <albert.u.b...@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
> > <mboa...@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.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
