[U-Boot] previous two e-mails are RFC/demonstration!

[U-Boot] previous two e-mails are RFC/demonstration!

[Reinhard Meyer]

Best Regards,
Reinhard

[U-Boot] previous two e-mails are RFC/demonstration!

[Wolfgang Denk]

Dear Reinhard Meyer,

and - do they compile? Do they work?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Es ist nicht genug zu wissen, man mu? auch anwenden; es ist nicht ge-
nug zu wollen, man mu? auch tun.   -- Goethe, Maximen und Reflexionen

[U-Boot] previous two e-mails are RFC/demonstration!

[Reinhard Meyer]

Dear Wolfgang Denk,
> Dear Reinhard Meyer,
>
> and - do they compile? Do they work?

Compile and work on top9000 = at91sam9xe = arm926ejs.

Since no tricks are used anymore, it is very likely
this will work on all other ARM variants or even on all
architectures with a similar GLOBAL_DATA method.

I made this patch as demo/reference to show how simple it is.
Honestly, it should have sprung into someones' eyes long ago,
but sometimes simple solutions hide themselves well :)

TODOs:

1. I am quite sure that in arm/lib/board.c
__asm__ __volatile__("": : :"memory");
was never needed and definitely is not needed anymore.
Can anyone shed some light on why this was added?
Probably just copied from other architectures where some trickery
around gd was done?

2. All board config files (for ARM) should be similarly updated:
-#define CONFIG_SYS_INIT_SP_ADDR \
-	(ATMEL_BASE_SRAM + 0x4000 - GENERATED_GBL_DATA_SIZE)
+#define CONFIG_SYS_INIT_SP_ADDR (ATMEL_BASE_SRAM + 0x4000)
However, having the subtraction does not hurt except for wasted
memory.

3. After this, GENERATED_GBL_DATA_SIZE is not needed anymore
(for ARM).

4. start.S need just set the SP to CONFIG_SYS_INIT_SP_ADDR,
if one wants to be over-cautious extra alignment *can* be done.

5. Test the change for other architectures.

Best Regards,
Reinhard

[U-Boot] previous two e-mails are RFC/demonstration!

[Albert ARIBAUD]

Le 14/11/2010 20:42, Reinhard Meyer a ?crit :

> 1. I am quite sure that in arm/lib/board.c
> __asm__ __volatile__("": : :"memory");
> was never needed and definitely is not needed anymore.
> Can anyone shed some light on why this was added?
> Probably just copied from other architectures where some trickery
> around gd was done?

This kind of barrier is needed when the compiler might reorder code 
without seeing a dependency (I met such a case in the Marvell egiga 
driver code). Here, I don't see the reason offhand.

> 4. start.S need just set the SP to CONFIG_SYS_INIT_SP_ADDR,
> if one wants to be over-cautious extra alignment *can* be done.

Currently start.S sets the stack twice, once before calling 
board_init_f, and once in relocate_code. Are you suggesting we remove 
the second sp setting?

> Best Regards,
> Reinhard


Amicalement,
-- 
Albert.

[U-Boot] previous two e-mails are RFC/demonstration!

[Reinhard Meyer]

Dear Albert ARIBAUD,
> Le 14/11/2010 20:42, Reinhard Meyer a ?crit :
>
>> 1. I am quite sure that in arm/lib/board.c
>> __asm__ __volatile__("": : :"memory");
>> was never needed and definitely is not needed anymore.
>> Can anyone shed some light on why this was added?
>> Probably just copied from other architectures where some trickery
>> around gd was done?
>
> This kind of barrier is needed when the compiler might reorder code without seeing a dependency (I met such a case in the Marvell egiga driver code). Here, I don't see the reason offhand.
>
>> 4. start.S need just set the SP to CONFIG_SYS_INIT_SP_ADDR,
>> if one wants to be over-cautious extra alignment *can* be done.
>
> Currently start.S sets the stack twice, once before calling board_init_f, and once in relocate_code. Are you suggesting we remove the second sp setting?

No, of course not.

Extra alignment code need not be added (to the first setting of SP)
anymore since CONFIG_SYS_INIT_SP_ADDR is well aligned when set
to the end of the storage area.

Adding extra alignment code was proposed in discussions a few days ago,
when GENERATED_GBL_DATA_SIZE was still subtracted.

Best Regards,
Reinhard

[U-Boot] previous two e-mails are RFC/demonstration!

[Wolfgang Denk]

Dear Albert ARIBAUD,

In message <4CE04585.807@free.fr> you wrote:
> 
> Currently start.S sets the stack twice, once before calling 
> board_init_f, and once in relocate_code. Are you suggesting we remove 
> the second sp setting?

As relocation can move the stack to some completely different location
the SP has to be re-initialized (in this setup, after copying the
global data to their new location).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"A little knowledge is a dangerous thing."                - Doug Gwyn

[U-Boot] previous two e-mails are RFC/demonstration!

[Reinhard Meyer]

Dear All,
> Dear Albert ARIBAUD,
>
> In message<4CE04585.807@free.fr>  you wrote:
>>
>> Currently start.S sets the stack twice, once before calling
>> board_init_f, and once in relocate_code. Are you suggesting we remove
>> the second sp setting?
>
> As relocation can move the stack to some completely different location
> the SP has to be re-initialized (in this setup, after copying the
> global data to their new location).

In the *most general* case stack and gd will have to be relocated
to SDRAM, since the pre-relocation memory *could* be locked data cache
or some buffer memory that is not free anymore when u-boot is up.

Of course, on SoCs like AT91SAM9 where several (4k - 32k) of SRAM are
available it would be tempting to keep stack and gd just in SRAM. But we
don't want to specialize, we want to generalize...

Best regards,
Reinhard