[U-Boot] arm, omap3, beagle: initial stack pointer setup

[U-Boot] arm, omap3, beagle: initial stack pointer setup

[Heiko Schocher]

Hello Steve,

today morning I tried actual u-boot on the beagle board, and I couldn;t
compile it because a problem with the GENERATED_GBL_DATA_SIZE changes.

In this context the question raised, if the

#define CONFIG_SYS_INIT_SP_ADDR         (LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE)

setup with using LOW_LEVEL_SRAM_STACK @ 0x4020FFFC is OK?

The address
a) it is not aligned
b) We should use CONFIG_SYS_INIT_RAM_SIZE and CONFIG_SYS_INIT_RAM_ADDR

So my question:

shouldn;t we add in "arch/arm/include/asm/arch-omap3/omap3.h" or
"include/asm/arch/cpu.h"? this 2 missing defines (described in b)),
and change in all omap3 plattforms

#define CONFIG_SYS_INIT_SP_ADDR         (LOW_LEVEL_SRAM_STACK - GENERATED_GBL_DATA_SIZE)

to

#define CONFIG_SYS_INIT_SP_ADDR	(CONFIG_SYS_INIT_RAM_ADDR + \
				CONFIG_SYS_INIT_RAM_SIZE - \
				GENERATED_GBL_DATA_SIZE)

With

CONFIG_SYS_INIT_RAM_ADDR	(SRAM_VECT_CODE)
                                 ^
                                 0x4020f800
CONFIG_SYS_INIT_RAM_SIZE	0x7f0

What do you think?

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] arm, omap3, beagle: initial stack pointer setup

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4CC7C628.70402@denx.de> you wrote:
> 
> CONFIG_SYS_INIT_RAM_ADDR	(SRAM_VECT_CODE)
>                                  ^
>                                  0x4020f800
> CONFIG_SYS_INIT_RAM_SIZE	0x7f0

Why that? From the current settings I would expect something like

	CONFIG_SYS_INIT_RAM_ADDR	0x4020f800
	CONFIG_SYS_INIT_RAM_SIZE	0x800

I see no reason to substract the top 16 bytes?

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
"What is wanted is not the will to believe, but the will to find out,
which is the exact opposite." - Bertrand Russell, _Sceptical_Essays_,
1928

[U-Boot] arm, omap3, beagle: initial stack pointer setup

[Steve Sakoman]

On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote:
> Dear Heiko Schocher,
> 
> In message <4CC7C628.70402@denx.de> you wrote:
> > 
> > CONFIG_SYS_INIT_RAM_ADDR	(SRAM_VECT_CODE)
> >                                  ^
> >                                  0x4020f800
> > CONFIG_SYS_INIT_RAM_SIZE	0x7f0
> 
> Why that? From the current settings I would expect something like
> 
> 	CONFIG_SYS_INIT_RAM_ADDR	0x4020f800
> 	CONFIG_SYS_INIT_RAM_SIZE	0x800
> 
> I see no reason to substract the top 16 bytes?

Agreed.  I saw this issue last night, but didn't have enough time to
prepare a fix.

I'll generate and test a patch on the OMAP boards which have implemented
relocation.

Steve

[U-Boot] arm, omap3, beagle: initial stack pointer setup

[Heiko Schocher]

Hello Steve,

Steve Sakoman wrote:
> On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote:
>> Dear Heiko Schocher,
>>
>> In message <4CC7C628.70402@denx.de> you wrote:
>>> CONFIG_SYS_INIT_RAM_ADDR	(SRAM_VECT_CODE)
>>>                                  ^
>>>                                  0x4020f800
>>> CONFIG_SYS_INIT_RAM_SIZE	0x7f0
>> Why that? From the current settings I would expect something like
>>
>> 	CONFIG_SYS_INIT_RAM_ADDR	0x4020f800
>> 	CONFIG_SYS_INIT_RAM_SIZE	0x800
>>
>> I see no reason to substract the top 16 bytes?
> 
> Agreed.  I saw this issue last night, but didn't have enough time to
> prepare a fix.
> 
> I'll generate and test a patch on the OMAP boards which have implemented
> relocation.

Ok, thanks!

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] arm, omap3, beagle: initial stack pointer setup

[Steve Sakoman]

On Wed, 2010-10-27 at 14:23 +0200, Heiko Schocher wrote:
> Hello Steve,
> 
> Steve Sakoman wrote:
> > On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote:
> >> Dear Heiko Schocher,
> >>
> >> In message <4CC7C628.70402@denx.de> you wrote:
> >>> CONFIG_SYS_INIT_RAM_ADDR	(SRAM_VECT_CODE)
> >>>                                  ^
> >>>                                  0x4020f800
> >>> CONFIG_SYS_INIT_RAM_SIZE	0x7f0
> >> Why that? From the current settings I would expect something like
> >>
> >> 	CONFIG_SYS_INIT_RAM_ADDR	0x4020f800
> >> 	CONFIG_SYS_INIT_RAM_SIZE	0x800
> >>
> >> I see no reason to substract the top 16 bytes?
> > 
> > Agreed.  I saw this issue last night, but didn't have enough time to
> > prepare a fix.
> > 
> > I'll generate and test a patch on the OMAP boards which have implemented
> > relocation.
> 
> Ok, thanks!

Now that I have some coffee, I think I see the actual reason that the
build was broken.

If you look at the error output:

start.S: Assembler messages:
start.S:175: Error: missing ')'
start.S:175: Error: missing ')'
start.S:175: Error: garbage following instruction -- `ldr sp,=((0x4020f800+0x800-#96))'

It is apparent that the assembler does not like that GENERATED_GBL_DATA_SIZE is defined as "#96"

I tried without the # symbol and the build completes successfully.

I'll prepare a patch to use CONFIG_SYS_INIT_RAM_ADDR and
CONFIG_SYS_INIT_RAM_SIZE on the OMAP boards with relocation, because
that is still a good idea, but we also need to deal with the prepended #
symbol.

I'm guessing that the PPC tools don't complain about the # symbol?

Steve

[U-Boot] arm, omap3, beagle: initial stack pointer setup

[Heiko Schocher]

Hello Steve,

Steve Sakoman wrote:
> On Wed, 2010-10-27 at 14:23 +0200, Heiko Schocher wrote:
>> Hello Steve,
>>
>> Steve Sakoman wrote:
>>> On Wed, 2010-10-27 at 09:14 +0200, Wolfgang Denk wrote:
>>>> Dear Heiko Schocher,
>>>>
>>>> In message <4CC7C628.70402@denx.de> you wrote:
>>>>> CONFIG_SYS_INIT_RAM_ADDR	(SRAM_VECT_CODE)
>>>>>                                  ^
>>>>>                                  0x4020f800
>>>>> CONFIG_SYS_INIT_RAM_SIZE	0x7f0
>>>> Why that? From the current settings I would expect something like
>>>>
>>>> 	CONFIG_SYS_INIT_RAM_ADDR	0x4020f800
>>>> 	CONFIG_SYS_INIT_RAM_SIZE	0x800
>>>>
>>>> I see no reason to substract the top 16 bytes?
>>> Agreed.  I saw this issue last night, but didn't have enough time to
>>> prepare a fix.
>>>
>>> I'll generate and test a patch on the OMAP boards which have implemented
>>> relocation.
>> Ok, thanks!
> 
> Now that I have some coffee, I think I see the actual reason that the
> build was broken.
> 
> If you look at the error output:
> 
> start.S: Assembler messages:
> start.S:175: Error: missing ')'
> start.S:175: Error: missing ')'
> start.S:175: Error: garbage following instruction -- `ldr sp,=((0x4020f800+0x800-#96))'
> 
> It is apparent that the assembler does not like that GENERATED_GBL_DATA_SIZE is defined as "#96"
> 
> I tried without the # symbol and the build completes successfully.

Already fixed here:

http://lists.denx.de/pipermail/u-boot/2010-October/080455.html

> I'll prepare a patch to use CONFIG_SYS_INIT_RAM_ADDR and
> CONFIG_SYS_INIT_RAM_SIZE on the OMAP boards with relocation, because
> that is still a good idea, but we also need to deal with the prepended #
> symbol.

Ok, thanks.

bye,
Heiko
-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

[U-Boot] arm, omap3, beagle: initial stack pointer setup

[Wolfgang Denk]

Dear Steve Sakoman,

In message <1288181563.2342.98.camel@quadra> you wrote:
>
> > Why that? From the current settings I would expect something like
> > 
> > 	CONFIG_SYS_INIT_RAM_ADDR	0x4020f800
> > 	CONFIG_SYS_INIT_RAM_SIZE	0x800
> > 
> > I see no reason to substract the top 16 bytes?
> 
> Agreed.  I saw this issue last night, but didn't have enough time to
> prepare a fix.

Um... on PowerPC, we need to initialize the stack with a final stack
frame (on PPC 2 x 32 bit zero) so that stack backtraces terminate
cleanly.  Eventually the reserved space was intended for similar
purposes, but if so, I cannot see that from the code.

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
The first thing we do is kill all the lawyers.
(Shakespeare. II Henry VI, Act IV, scene ii)