[U-Boot] [PATCH] ARM: allocate pre-relocation global_data on pre-relocation stack
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));
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?
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
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 Meyeru-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,
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 Meyeru-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
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,
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
participants (3)
-
Albert ARIBAUD -
Reinhard Meyer -
Wolfgang Denk