[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Daniel Hobi]

Hi Prafulla,

In commit 0b20ed76 (Kirkwood: Changes specific to ARM relocation
support), you set CONFIG_SYS_INIT_SP_ADDR to 0xC8012000 which is
supposed to lie within the internal Security SRAM.

However, the Kirkwood Functional Specification (chapter 2.13 Default
Address Map) and arch/arm/include/asm/arch-kirkwood/cpu.h suggest that
the Security SRAM is mapped to 0xC8010000. Given the size of 2 KiB, the
upper end would be 0xC8010800.

So I am wondering whether the value 0xC8012000 works at all.

In addition, "CONFIG_SYS_INIT_SP_ADDR should point to RAM with enough
space for global data above and enough stack space below", as Reinhard
Meyer points out in:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/87490

Since you use quite a large print buffer (CONFIG_SYS_PBSIZE > 1 KiB), I
assume something like 0xC8010700 might work.

@Heiko: include/configs/km_arm.h may have the same problem.

Best regards,
Daniel

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Heiko Schocher]

Hello Daniel,

Daniel Hobi wrote:
> In commit 0b20ed76 (Kirkwood: Changes specific to ARM relocation
> support), you set CONFIG_SYS_INIT_SP_ADDR to 0xC8012000 which is
> supposed to lie within the internal Security SRAM.
> 
> However, the Kirkwood Functional Specification (chapter 2.13 Default
> Address Map) and arch/arm/include/asm/arch-kirkwood/cpu.h suggest that
> the Security SRAM is mapped to 0xC8010000. Given the size of 2 KiB, the
> upper end would be 0xC8010800.
> 
> So I am wondering whether the value 0xC8012000 works at all.
> 
> In addition, "CONFIG_SYS_INIT_SP_ADDR should point to RAM with enough
> space for global data above and enough stack space below", as Reinhard
> Meyer points out in:
> 
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/87490
> 
> Since you use quite a large print buffer (CONFIG_SYS_PBSIZE > 1 KiB), I
> assume something like 0xC8010700 might work.
> 
> @Heiko: include/configs/km_arm.h may have the same problem.

I made a patch for this, see:

http://lists.denx.de/pipermail/u-boot/2010-November/081275.html

but you are right, looking in Kirkwood Functional Specification
(chapter 2.13 Default Address Map) internal Security SRAM is mapped
from 0xc8010000-0xc801ffff with the note, that only 2kb sram are
implemented) ... so your question is right, why this is working ...
I just can say, it works on the suen3 ... Prafulla, do you have
an idea for this (maybe the sram is mirrored?)

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

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Daniel Hobi]

Hi Heiko,

On 10.11.2010 15:15, Heiko Schocher wrote:
> Daniel Hobi wrote:
>> @Heiko: include/configs/km_arm.h may have the same problem.
> 
> I made a patch for this, see:
> 
> http://lists.denx.de/pipermail/u-boot/2010-November/081275.html

Reading your patch, I noticed that we don't align the early stack
pointer to an 8-byte boundary which may lead to the problem described here:

http://article.gmane.org/gmane.comp.boot-loaders.u-boot/69342

Since you seem to be the author of the relevant assembly code, could you
please prepare a fix (adding "bic sp, sp, #7")?

Best regards,
Daniel

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Heiko Schocher]

Hello Daniel,

Daniel Hobi wrote:
> Hi Heiko,
> 
> On 10.11.2010 15:15, Heiko Schocher wrote:
>> Daniel Hobi wrote:
>>> @Heiko: include/configs/km_arm.h may have the same problem.
>> I made a patch for this, see:
>>
>> http://lists.denx.de/pipermail/u-boot/2010-November/081275.html
> 
> Reading your patch, I noticed that we don't align the early stack
> pointer to an 8-byte boundary which may lead to the problem described here:
> 
> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/69342

This article is from 2009-10-06 06:44:22 GMT (1 year, 5 weeks, 2 hours and 15 minutes ago)

> Since you seem to be the author of the relevant assembly code, could you
> please prepare a fix (adding "bic sp, sp, #7")?

We do this, since relocation is introduced, now here:

http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/lib/board.c;h=1fd5f8362f7a3e1a076c44e9f554e6c0297dfdb0;hb=0c0892be0d93a5a892b93739c5eb3bf692fed4ff

line 405

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

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Daniel Hobi]

Hi Heiko,

On 10.11.2010 16:02, Heiko Schocher wrote:
> Daniel Hobi wrote:
>> Reading your patch, I noticed that we don't align the early stack
>> pointer to an 8-byte boundary which may lead to the problem described here:
>>
>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/69342
> 
> This article is from 2009-10-06 06:44:22 GMT (1 year, 5 weeks, 2 hours and 15 minutes ago)
> 
>> Since you seem to be the author of the relevant assembly code, could you
>> please prepare a fix (adding "bic sp, sp, #7")?
> 
> We do this, since relocation is introduced, now here:
>
> [link to arch/arm/lib/board.c]

Yes, I know.

But you also added assembly code to setup the initial stack pointer in
arch/arm/cpu/*/start.S (ie commit ab86f72c for arm926ejf) which reads:

/* Set stackpointer in internal RAM to call board_init_f */
call_board_init_f:
	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)

CONFIG_SYS_INIT_SP_ADDR may not be aligned properly, especially with
your latest patch to km_arm.h:

#define CONFIG_SYS_INIT_SP_ADDR	(0xC8012000 - GENERATED_GBL_DATA_SIZE)

Best regards,
Daniel

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Heiko Schocher]

Hello Daniel,

Daniel Hobi wrote:
> On 10.11.2010 16:02, Heiko Schocher wrote:
>> Daniel Hobi wrote:
>>> Reading your patch, I noticed that we don't align the early stack
>>> pointer to an 8-byte boundary which may lead to the problem described here:
>>>
>>> http://article.gmane.org/gmane.comp.boot-loaders.u-boot/69342
>> This article is from 2009-10-06 06:44:22 GMT (1 year, 5 weeks, 2 hours and 15 minutes ago)
>>
>>> Since you seem to be the author of the relevant assembly code, could you
>>> please prepare a fix (adding "bic sp, sp, #7")?
>> We do this, since relocation is introduced, now here:
>>
>> [link to arch/arm/lib/board.c]
> 
> Yes, I know.
> 
> But you also added assembly code to setup the initial stack pointer in
> arch/arm/cpu/*/start.S (ie commit ab86f72c for arm926ejf) which reads:
> 
> /* Set stackpointer in internal RAM to call board_init_f */
> call_board_init_f:
> 	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
> 
> CONFIG_SYS_INIT_SP_ADDR may not be aligned properly, especially with
> your latest patch to km_arm.h:
> 
> #define CONFIG_SYS_INIT_SP_ADDR	(0xC8012000 - GENERATED_GBL_DATA_SIZE)

Ah, good catch.

Then we should add this alignment into the generation of
GENERATED_GBL_DATA_SIZE.

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

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Daniel Hobi]

Hi Heiko,

On 10.11.2010 16:40, Heiko Schocher wrote:
> Daniel Hobi wrote:
>> But you also added assembly code to setup the initial stack pointer in
>> arch/arm/cpu/*/start.S (ie commit ab86f72c for arm926ejf) which reads:
>>
>> /* Set stackpointer in internal RAM to call board_init_f */
>> call_board_init_f:
>> 	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
>>
>> CONFIG_SYS_INIT_SP_ADDR may not be aligned properly, especially with
>> your latest patch to km_arm.h:
>>
>> #define CONFIG_SYS_INIT_SP_ADDR	(0xC8012000 - GENERATED_GBL_DATA_SIZE)
> 
> Ah, good catch.
> 
> Then we should add this alignment into the generation of
> GENERATED_GBL_DATA_SIZE.

Hm? The stack pointer needs alignment, not GENERATED_GBL_DATA_SIZE. What
happens if I define:

#define CONFIG_SYS_INIT_SP_ADDR	(0xC8012004 - GENERATED_GBL_DATA_SIZE)

Why not add alignment to start.S?

 /* Set stackpointer in internal RAM to call board_init_f */
 call_board_init_f:
 	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
+	bic	sp, sp, #7

Best regards,
Daniel

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Albert ARIBAUD]

Le 10/11/2010 16:46, Daniel Hobi a ?crit :
> Hi Heiko,
>
> On 10.11.2010 16:40, Heiko Schocher wrote:
>> Daniel Hobi wrote:
>>> But you also added assembly code to setup the initial stack pointer in
>>> arch/arm/cpu/*/start.S (ie commit ab86f72c for arm926ejf) which reads:
>>>
>>> /* Set stackpointer in internal RAM to call board_init_f */
>>> call_board_init_f:
>>> 	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
>>>
>>> CONFIG_SYS_INIT_SP_ADDR may not be aligned properly, especially with
>>> your latest patch to km_arm.h:
>>>
>>> #define CONFIG_SYS_INIT_SP_ADDR	(0xC8012000 - GENERATED_GBL_DATA_SIZE)
>>
>> Ah, good catch.
>>
>> Then we should add this alignment into the generation of
>> GENERATED_GBL_DATA_SIZE.
>
> Hm? The stack pointer needs alignment, not GENERATED_GBL_DATA_SIZE. What
> happens if I define:
>
> #define CONFIG_SYS_INIT_SP_ADDR	(0xC8012004 - GENERATED_GBL_DATA_SIZE)
>
> Why not add alignment to start.S?
>
>   /* Set stackpointer in internal RAM to call board_init_f */
>   call_board_init_f:
>   	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
> +	bic	sp, sp, #7
>
> Best regards,
> Daniel

Bad solution IMO: if the symbol is used elsewhere, one would have to 
always remember that it should be aligned down to a multiple of eight. 
We may not need to make it a generated constant, but we definitely need 
to make sure it is correctly aligned wherever it is used, e.g. by 
defining it as

#define CONFIG_SYS_INIT_SP_ADDR	(0xC8012004-GENERATED_GBL_DATA_SIZE)&~7

(spacing squashed to avoid funny line breaks)

Amicalement,
-- 
Albert.

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Heiko Schocher]

Hello Daniel,

Daniel Hobi wrote:
> On 10.11.2010 16:40, Heiko Schocher wrote:
>> Daniel Hobi wrote:
>>> But you also added assembly code to setup the initial stack pointer in
>>> arch/arm/cpu/*/start.S (ie commit ab86f72c for arm926ejf) which reads:
>>>
>>> /* Set stackpointer in internal RAM to call board_init_f */
>>> call_board_init_f:
>>> 	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
>>>
>>> CONFIG_SYS_INIT_SP_ADDR may not be aligned properly, especially with
>>> your latest patch to km_arm.h:
>>>
>>> #define CONFIG_SYS_INIT_SP_ADDR	(0xC8012000 - GENERATED_GBL_DATA_SIZE)
>> Ah, good catch.
>>
>> Then we should add this alignment into the generation of
>> GENERATED_GBL_DATA_SIZE.

looked in the generation of GENERATED_GBL_DATA_SIZE:

./lib/asm-offsets.c

        /* Round up to make sure size gives nice stack alignment */
        DEFINE(GENERATED_GBL_DATA_SIZE,
                (sizeof(struct global_data)+15) & ~15);

this is ok.

> Hm? The stack pointer needs alignment, not GENERATED_GBL_DATA_SIZE. What
> happens if I define:
> 
> #define CONFIG_SYS_INIT_SP_ADDR	(0xC8012004 - GENERATED_GBL_DATA_SIZE)

Indeed, that would be bad ... don;t do it ;-)

> Why not add alignment to start.S?
> 
>  /* Set stackpointer in internal RAM to call board_init_f */
>  call_board_init_f:
>  	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
> +	bic	sp, sp, #7

Hmm.. because we do in board_init_f:

 gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);

Hmm.. maybe we should call board_init_f with the info, where to
find the stack, but this would be a change for all architectures,
not only arm ...

opinions?

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

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Daniel Hobi]

Hi Albert and Heiko,

On 10.11.2010 17:46, Heiko Schocher wrote:
> Daniel Hobi wrote:
>> Why not add alignment to start.S?
>>
>>  /* Set stackpointer in internal RAM to call board_init_f */
>>  call_board_init_f:
>>  	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
>> +	bic	sp, sp, #7
> 
> Hmm.. because we do in board_init_f:
> 
>  gd = (gd_t *) (CONFIG_SYS_INIT_SP_ADDR);

gd (struct global_data) does not require the same alignment as the stack
pointer. If CONFIG_SYS_INIT_SP_ADDR is 4-byte aligned, but not 8-byte
aligned, 4 bytes between these two are unused. If you care about that,
just 8-byte align gd in the assignment above. It makes sense to at least
4-byte align gd anyway.

> Hmm.. maybe we should call board_init_f with the info, where to
> find the stack, but this would be a change for all architectures,
> not only arm ...

We would tell board_init_f where to find the global_data, not the stack.
If other architectures also use the same computation for stack (in
start.S) and global_data (in board_init_f), this change should be
considered.

On 10.11.2010 17:29, Albert ARIBAUD wrote:
> Bad solution IMO: if the symbol is used elsewhere, one would have to 
> always remember that it should be aligned down to a multiple of
> eight. We may not need to make it a generated constant, but we
> definitely need to make sure it is correctly aligned wherever it is
> used, e.g. by defining it as
> 
> #define CONFIG_SYS_INIT_SP_ADDR
>   (0xC8012004-GENERATED_GBL_DATA_SIZE)&~7

I think it's much less error-prone to align CONFIG_SYS_INIT_SP_ADDR
wherever it is used. It should be used only at two places anyway: to
initialize the early stack pointer and the global_data pointer.

As a reminder: it was extremely difficult the find the misaligned stack
pointer (resulting in the patch from 2009-10-06) given the symptoms. And
since you cannot expect board maintainers to spend an equal amount of
time to solve this problem over and over again, we definitely need to
align CONFIG_SYS_INIT_SP_ADDR where it is used, and not where it is defined.

Best regards,
Daniel

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4CDABCF8.901@denx.de> you wrote:
> 
> Then we should add this alignment into the generation of
> GENERATED_GBL_DATA_SIZE.

No.  GENERATED_GBL_DATA_SIZE is just a size.  As you don't really know
the alignment of the base address that GENERATED_GBL_DATA_SIZE is
added to or substracted from, you cannot add the alignment
requirements here.

This must be done where they are neede d- whichis also much better to
make the code readable / understandable.

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
He'd been wrong, there _was_ a light at the end of the tunnel, and it
was a flamethrower.                         - Terry Pratchett, _Mort_

[U-Boot] kirkwood: CONFIG_SYS_INIT_SP_ADDR wrong?

[Wolfgang Denk]

Dear Heiko Schocher,

In message <4CDACC7C.3040609@denx.de> you wrote:
> 
> looked in the generation of GENERATED_GBL_DATA_SIZE:
> 
> ./lib/asm-offsets.c
> 
>         /* Round up to make sure size gives nice stack alignment */
>         DEFINE(GENERATED_GBL_DATA_SIZE,
>                 (sizeof(struct global_data)+15) & ~15);
> 
> this is ok.

I know that I let me talk into adding this. It was a bad idea. Let's
get rid of this and fix it properly instead.

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 the gods would destroy they first submit to  an  IEEE  standards
committee.