[U-Boot] RFC: Aligning arch initialisation sequences

[Graeme Russ]

On Mon, Nov 15, 2010 at 7:05 AM, Albert ARIBAUD <albert.aribaud at free.fr> wrote:
> Le 14/11/2010 20:34, Graeme Russ a écrit :
>>
>> On 15/11/10 06:23, Wolfgang Denk wrote:
>>>
>>> Dear Albert ARIBAUD,
>>>
>>> In message<4CE0221A.7030502 at free.fr>  you wrote:
>>>>
>>>> Alright, then I think we should document how we comply, or do not
>>>> comply, with GNU EABI / AAPCS (maybe a README.arm that people could read
>>>> up) -- and I think if there is a way to access GD both before and after
>>>> relocation without making a register unavailable to the whole u-boot
>>>> code, then we should use it.
>>>
>>> By the way - it should be not difficult to use a normal extern pointer
>>> to reference the global data; see
>>> "arch/powerpc/include/asm/global_data.h":
>>>
>>> 194 #if 1
>>> 195 #define DECLARE_GLOBAL_DATA_PTR     register volatile gd_t *gd asm
>>> ("r2")
>>> 196 #else /* We could use plain global data, but the resulting code is
>>> bigger */
>>> 197 #define XTRN_DECLARE_GLOBAL_DATA_PTR    extern
>>> 198 #define DECLARE_GLOBAL_DATA_PTR     XTRN_DECLARE_GLOBAL_DATA_PTR \
>>> 199                                     gd_t *gd
>>> 200 #endif
>>
>> I think you will find this peculiar to PowerPC
>
> I don't think Wolfgang's idea is actually processor-specific.
>
> Each processor has a way to define globals, which end up in the initialized
> data or bss area. BSS is not available before relocation, but initialized
> data is, and remains so after relocation.
>
> So if we define gd as an initialized pointer (residing in the initialized
> data area), it will be available both before and after relocation.
>
> Before relocation, this pointer will be read-only. We can set it at compile
> time if we know for each arch (or board) a good address in RAM or IRAM where
> gd can exist.
>
> After relocation, the pointer becomes read-write: we can copy gd content
> from (I)RAM to RAM if necessary and then update the gd pointer.
>
>> What you are talking about is exactly how x86 defines gd, but for x86, gd
>> is not accessible until after relocation
>
> Could it become accessible with the idea I expose above?
>

Well, I do not have CONFIG_SYS_INIT_SP_ADDR but I guess I could add it

What about in board.c

	gd_t global_data;
	gd_t *gd = &global_data;

Oh, PowerPC comment is wrong...

 * Be aware of the restrictions: global data is read-only, BSS is not
 * initialized, and stack space is limited to a few kB.

And then it does a whole lot of writing to gd starting with:

 /* Clear initial global data */
 memset ((void *) gd, 0, sizeof (gd_t));

OK bad idea :)

So we seem to have two perfectly valid theories which cannot co-exist:

 1) Make gd_t *gd static and hard code it's initial value to some known
    location in RAM (SRAM, Cache etc). After relocation, it can be written
    to
 2) Use a register as we do now and potentially move initial global data
    onto the stack in init_board_f()

Option #1 means I do not have to do any crazyness with my Global Descriptor
Table in asm (self modifying code, FS calculations etc) but seems to mess
araound with code size on some arches

Option #2 means there is no need for GENERATED_GBL_DATA_SIZE or hard-coded
memory location but does rely on there being no global data access prior to
calling board_init_f()

Well, both have their pro's and con's - I'll leave that decision to Wolfgang ;)

Regards,

Graeme