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,