[U-Boot] [PATCH 01/10] Move board_init_f_mem() into a common location

Simon Glass sjg at chromium.org
Sat Apr 18 00:56:06 CEST 2015


Hi Jeroen,

On 16 April 2015 at 03:32, Jeroen Hofstee <jeroen at myspectrum.nl> wrote:
> Hello Simon,
>
> On 16-04-15 03:14, Simon Glass wrote:
>>
>> +
>> +DECLARE_GLOBAL_DATA_PTR;
>> +
>> +ulong board_init_f_mem(ulong top)
>> +{
>> +       /* TODO(sjg at chromium.org): Figure out how x86 can use this */
>> +#ifndef CONFIG_X86
>> +       /* Leave space for the stack we are running with now */
>> +       top -= 0x40;
>> +
>> +       top -= sizeof(struct global_data);
>> +       top = ALIGN(top, 16);
>> +       gd = (struct global_data *)top;
>> +       memset((void *)gd, '\0', sizeof(*gd));
>> +
>
>
> Above piece of code is on my TODO list as well. Like x86, clang cannot
> directly assign gd. What I still need to check is why this reassignment is
> needed in the first place. Typically, at least for ARM, allocating an
> initial
> gd in _main and copying it over in relocate suffices for common boards.
>
> This doesn't work if there is a valid use case for needing gd before calling
> main, but I am not aware of any (but haven't found time to google for any
> as well, so it doesn't mean there isn't any).
>
> That said, if there is valid reason to reassign gd, clang could do that if
> there
> was a macro e.g. set_gd(new_gd) instead of a direct assignment. Since this
> is a
> cross arch patchset, that might be something to consider (and likely solves
> the
> "Figure out how x86 can use this" as well).

Yes. I'm fiddling with x86 again so may figure something out here for v2.

Regards,
Simon


More information about the U-Boot mailing list