Possible issue with iMX6 Platform SDK stack alignment at startup.

[EdSutter]

I've been wrestling with stability issues as I am trying to reuse portions of the iMX6 Platform SDK in my boot loader.  What I've found is that the memory map setup and the way stack is initialized, its possible that the stack pointer will not be double-word aligned.  Apparently it is important to start off with this double-word alignment, because I've found that when I build my boot loader and the "top_of_stack" location is NOT double-word aligned (divisible by 8), then my system doesn't boot; however, if I adjust the memory map to force that to a double-word aligned address it does boot.

While I don't fully understand the need for this double-word alignment, there is some information here...

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.faqs/ka4127.html

Anyway, the easy fix for this is to simply force this alignment in the linker file...

    .stacks (NOLOAD) :

    {

       . = ALIGN (8);          <<<<<< Add this line

        __stacks_start = .;

        . += 48K;

        __stacks_end = .;

        top_of_stacks = .;

    } > DDR

This apparently is not a problem for folks using the SDK (perhaps something else in the build is forcing this alignment that I'm not aware of), so I'd like to get feedback on this post to see if folks agree or disagree with this suggested change.

[maheshmahadeva1]

Found the below code in sdk/core/src/startup.S which should take care of this:

	/*
	* fill the stacks with a pattern
	* the stack must be 8 byte aligned
	*/
	ldr	r1,=__stacks_start	@ stack region start address
	ldr	r2,=top_of_stacks	@ stack region end address
	bic	r2,r2,#0x7	@ round length down to nearest 8 byte alignment
	ldr	r3,=.Ldeadfeed	@ get fill pattern address
	ldr	r3,[r3]	@ read fill pattern into r3
	mov	r4,r3	@ copy fill pattern to r4
1:  cmp	r1,r2	@ the fill loop
	stmltia r1!,{r3-r4}
	blt	1b

Best regards,

-Mahesh

[EdSutter]

This does initialize the stack (which is good), but the important thing here is that the stack pointer itself be initialized with a value that is aligned.  So I think my original post (showing the ALIGN(8) in the loader file) actually solved the problem for me. Actually, in my boot monitor code, I use the BIC instruction to adjust what ultimately is used as the stack pointer... 

    ldr     r0, = (MonStack + MONSTACKSIZE - 4)

    bic r0, r0, #15

    mov     sp, r0

Doing it this way (in code, rather than depending on an aligned tag) eliminates the need to care where the stack memory is.  If you disagree, please let me know.  I've had this fix in place for weeks now and it has been working just fine.

[maheshmahadeva1]

Looks like the SDK misses aligning the address written to sp.

Best regards,

-Mahesh

[EdSutter · Accepted solution]

Right!

The quick fix is to do the ALIGN(8) that I show at the top.

The better fix is to apply the BIC instruction to all assignments of SP in that startup.S code...

   @ set stacks for all other modes

   msr     CPSR_c, #MODE_FIQ | I_BIT | F_BIT

   bic     r0, r0, #15

   mov     sp, r0

   sub     r0, r0, r1

   msr     CPSR_c, #MODE_IRQ | I_BIT | F_BIT

   bic     r0, r0, #15

   mov     sp, r0

   sub     r0, r0, r1

   msr     CPSR_c, #MODE_ABT | I_BIT | F_BIT

   bic     r0, r0, #15

   mov     sp, r0

   sub     r0, r0, r1

   msr     CPSR_c, #MODE_UND | I_BIT | F_BIT

   bic     r0, r0, #15

   mov     sp, r0

   sub     r0, r0, r1

   msr     CPSR_c, #MODE_SYS | I_BIT | F_BIT

   bic     r0, r0, #15

   mov     sp, r0

   sub     r0, r0, r1

   @ Set SVC mode stack with interrupts disabled

   msr     CPSR_c, #MODE_SVC | I_BIT | F_BIT

   bic     r0, r0, #15

   mov     sp, r0

   sub     r0, r0, r1

[PaulDeMetrotion]

What is the file name to be edited?

[EdSutter]

Under the sdk directory:

apps/common/basic_sdk_app.ld.S