[U-Boot] OMAP (4) boot_params

Michael Cashwell mboards at prograde.net
Wed Apr 3 16:59:23 CEST 2013


On Apr 3, 2013, at 10:36 AM, Albert ARIBAUD <albert.u.boot at aribaud.net> wrote:

> Hi Michael,
> 
> On Wed, 3 Apr 2013 09:45:19 -0400, Michael Cashwell
> <mboards at prograde.net> wrote:
> 
>> I've never understood why this is useful. [...]
> 
> ... but apparently you managed to do it, thanks.

With extra effort that could be better applied to other work, but yes. :-)

>>>> ...Making that:
>>>> 
>>>> u32 *boot_params_ptr __attribute__ ((section(".data")));
>> 
>> 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.

I think we're in agreement, but it's not my code doing it. The code,
as it exists in mainline is writing early to space in bss. My change
avoids that by moving the variable from the default bss to data:

diff --git a/common/spl/spl.c b/common/spl/spl.c
index 6715e0d..1d84535
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -42,7 +42,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #define CONFIG_SYS_MONITOR_LEN (200 * 1024)
 #endif
 
-u32 *boot_params_ptr = NULL;
+u32 *boot_params_ptr __attribute__ ((section(".data")));
 struct spl_image_info spl_image;
 
 /* Define board data structure */

>> 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)

Yes, I'm exploring that now. The differences between SPL and U-boot are
subtle.

Best regards,
-Mike



More information about the U-Boot mailing list