[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Reinhard Meyer]

That removes the need to reserve memory above the stack
and also removes the need for GENERATED_GBL_DATA_SIZE.
Alignment is automatically "right" provided stack is
aligned.

Signed-off-by: Reinhard Meyer <u-boot@emk-elektronik.de>
---
 arch/arm/lib/board.c |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index 1fd5f83..53e0f4f 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -274,11 +274,12 @@ void board_init_f (ulong bootflag)
 	init_fnc_t **init_fnc_ptr;
 	gd_t *id;
 	ulong addr, addr_sp;
+	gd_t auto_gd;
 
 	/* Pointer is writable since we allocated a register for it */
-	gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
+	gd = &auto_gd;
 	/* compiler optimization barrier needed for GCC >= 3.4 */
-	__asm__ __volatile__("": : :"memory");
+	/* __asm__ __volatile__("": : :"memory"); */
 
 	memset ((void*)gd, 0, sizeof (gd_t));
 
-- 
1.5.6.5

[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Wolfgang Denk]

Dear Reinhard Meyer,

In message <1289750861-23050-1-git-send-email-u-boot@emk-elektronik.de> you wrote:
> That removes the need to reserve memory above the stack
> and also removes the need for GENERATED_GBL_DATA_SIZE.
> Alignment is automatically "right" provided stack is
> aligned.
> 
> Signed-off-by: Reinhard Meyer <u-boot@emk-elektronik.de>

Has this patch been tested?  If so, in which way and on which SoCs and
boards?

[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Reinhard Meyer]

> That removes the need to reserve memory above the stack
> and also removes the need for GENERATED_GBL_DATA_SIZE.
> Alignment is automatically "right" provided stack is
> aligned.
> 
> Signed-off-by: Reinhard Meyer <u-boot@emk-elektronik.de>
> ---
>  arch/arm/lib/board.c |    5 +++--
>  1 files changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
> index 1fd5f83..53e0f4f 100644
> --- a/arch/arm/lib/board.c
> +++ b/arch/arm/lib/board.c
> @@ -274,11 +274,12 @@ void board_init_f (ulong bootflag)
>  	init_fnc_t **init_fnc_ptr;
>  	gd_t *id;
>  	ulong addr, addr_sp;
> +	gd_t auto_gd;
>  
>  	/* Pointer is writable since we allocated a register for it */
> -	gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
> +	gd = &auto_gd;
>  	/* compiler optimization barrier needed for GCC >= 3.4 */
> -	__asm__ __volatile__("": : :"memory");
> +	/* __asm__ __volatile__("": : :"memory"); */
>  
>  	memset ((void*)gd, 0, sizeof (gd_t));
>  

Are there any objections to this patch now?
I can provide a V2 where the "compiler optimization barrier" stuff is
completely removed.

Tested on: at91sam9xe / arm926ejs / top9000 and at91sam9xe-ek boards.

Best Regards,
Reinhard

[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Albert ARIBAUD]

Le 18/11/2010 14:53, Reinhard Meyer a ?crit :
>> That removes the need to reserve memory above the stack
>> and also removes the need for GENERATED_GBL_DATA_SIZE.
>> Alignment is automatically "right" provided stack is
>> aligned.
>>
>> Signed-off-by: Reinhard Meyer<u-boot@emk-elektronik.de>
>> ---
>>   arch/arm/lib/board.c |    5 +++--
>>   1 files changed, 3 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>> index 1fd5f83..53e0f4f 100644
>> --- a/arch/arm/lib/board.c
>> +++ b/arch/arm/lib/board.c
>> @@ -274,11 +274,12 @@ void board_init_f (ulong bootflag)
>>   	init_fnc_t **init_fnc_ptr;
>>   	gd_t *id;
>>   	ulong addr, addr_sp;
>> +	gd_t auto_gd;
>>
>>   	/* Pointer is writable since we allocated a register for it */
>> -	gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
>> +	gd =&auto_gd;
>>   	/* compiler optimization barrier needed for GCC>= 3.4 */
>> -	__asm__ __volatile__("": : :"memory");
>> +	/* __asm__ __volatile__("": : :"memory"); */
>>
>>   	memset ((void*)gd, 0, sizeof (gd_t));
>>
>
> Are there any objections to this patch now?
> I can provide a V2 where the "compiler optimization barrier" stuff is
> completely removed.
>
> Tested on: at91sam9xe / arm926ejs / top9000 and at91sam9xe-ek boards.

I'm probably lagging behind... How do you ensure that the pre-relocation 
GD content ends up in the post-relocation GD (which cannot be that stack 
variable since the stack is going to be somewhere else)?

> Best Regards,
> Reinhard

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Reinhard Meyer]

Dear Albert ARIBAUD,
> Le 18/11/2010 14:53, Reinhard Meyer a ?crit :
>>> That removes the need to reserve memory above the stack
>>> and also removes the need for GENERATED_GBL_DATA_SIZE.
>>> Alignment is automatically "right" provided stack is
>>> aligned.
>>>
>>> Signed-off-by: Reinhard Meyer<u-boot@emk-elektronik.de>
>>> ---
>>> arch/arm/lib/board.c | 5 +++--
>>> 1 files changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
>>> index 1fd5f83..53e0f4f 100644
>>> --- a/arch/arm/lib/board.c
>>> +++ b/arch/arm/lib/board.c
>>> @@ -274,11 +274,12 @@ void board_init_f (ulong bootflag)
>>> init_fnc_t **init_fnc_ptr;
>>> gd_t *id;
>>> ulong addr, addr_sp;
>>> + gd_t auto_gd;
>>>
>>> /* Pointer is writable since we allocated a register for it */
>>> - gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);
>>> + gd =&auto_gd;
>>> /* compiler optimization barrier needed for GCC>= 3.4 */
>>> - __asm__ __volatile__("": : :"memory");
>>> + /* __asm__ __volatile__("": : :"memory"); */
>>>
>>> memset ((void*)gd, 0, sizeof (gd_t));
>>>
>>
>> Are there any objections to this patch now?
>> I can provide a V2 where the "compiler optimization barrier" stuff is
>> completely removed.
>>
>> Tested on: at91sam9xe / arm926ejs / top9000 and at91sam9xe-ek boards.
>
> I'm probably lagging behind... How do you ensure that the pre-relocation GD content ends up in the post-relocation GD (which cannot be that stack variable since the stack is going to be somewhere else)?

Check the function yourself:
there is a memcpy of this GD to an area in SDRAM at the end...

Best Regards,
Reinhard

[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Albert ARIBAUD]

Le 18/11/2010 21:43, Reinhard Meyer a ?crit :

>> I'm probably lagging behind... How do you ensure that the pre-relocation GD content ends up in the post-relocation GD (which cannot be that stack variable since the stack is going to be somewhere else)?
>
> Check the function yourself:
> there is a memcpy of this GD to an area in SDRAM at the end...

Apologies: I *was* indeed lagging behind.

> Best Regards,
> Reinhard

Amicalement,
-- 
Albert.

[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack

[Reinhard Meyer]

Dear Albert ARIBAUD,
> Le 18/11/2010 21:43, Reinhard Meyer a ?crit :
>
>>> I'm probably lagging behind... How do you ensure that the pre-relocation GD content ends up in the post-relocation GD (which cannot be that stack variable since the stack is going to be somewhere else)?
>>
>> Check the function yourself:
>> there is a memcpy of this GD to an area in SDRAM at the end...
>
> Apologies: I *was* indeed lagging behind.

So what is going to happen about this patch?
I see no objections or complaints anywhere, but I see boards
getting fixed using GENERATED_GBL_DATA_SIZE.

Note that using GENERATED_GBL_DATA_SIZE does not break with my patch,
it just wastes space.

Best Regards,
Reinhard