[ECOS] Running code from external ram on the AT91SAM7SE

[ECOS] Running code from external ram on the AT91SAM7SE

[Tom Deconinck]

Hello,

I having problems running code out of external SDRAM on the
AT91SAM7SE512. This is a CPU similar to the AT91SAM7S family, but it
has an external bus interface and an integrated SDRAM controller.
So far I have tried an eCos minimal setup and a 'normal' hello world
application, both without any success.
My setup is as follows: I have a BDI2000 that sets up and configures
the SDRAM controller, then I use GDB to load in the ELF file (via the
BDI probe) and then I start the program.
My ecos configuration is identical to the one I use to boot from ROM,
except I changed the startup type to RAM. (The ROM setup works like a
charm) I also added the required linker settings:

MEMORY
{
ram : ORIGIN = 0x20000000, LENGTH = 0x2000000
    sram : ORIGIN = 0x00200000, LENGTH = 0x8000
    rom : ORIGIN = 0x00100000, LENGTH = 0x80000
}

SECTIONS
{
    SECTIONS_BEGIN
    CYG_LABEL_DEFN(__reserved_bootmon) = 0x00000000; . =
CYG_LABEL_DEFN(__reserved_bootmon) + 0x01000;
    SECTION_rom_vectors (ram, 0x20200000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x1), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixed_vectors (ram, 0x20000040, LMA_EQ_VMA)
    SECTION_data (ram, ALIGN (0x4), FOLLOWING (.gcc_except_table))
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}


I think I tracked down the problem to this code in
/arm/arch/current/src/vectors.S:
<snip>
start:
       LED 5
#if defined(CYG_HAL_STARTUP_RAM) && \
    !defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)
// If we get restarted, hang here to avoid corrupting memory
        ldr     r0,.init_flag
        ldr     r1,[r0]
1:      cmp     r1,#0
        bne     1b
        ldr     r1,init_done
        str     r1,[r0]
#endif
</snip>
Could someone explain what this code is supposed to do? According to
me, it just spins forever, but my assembly is kinda rusty.

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Running code from external ram on the AT91SAM7SE

[Andrew Lunn]

On Tue, Nov 06, 2007 at 11:13:24AM +0100, Tom Deconinck wrote:
> Hello,
> 
> I having problems running code out of external SDRAM on the
> AT91SAM7SE512. This is a CPU similar to the AT91SAM7S family, but it
> has an external bus interface and an integrated SDRAM controller.
> So far I have tried an eCos minimal setup and a 'normal' hello world
> application, both without any success.
> My setup is as follows: I have a BDI2000 that sets up and configures
> the SDRAM controller, then I use GDB to load in the ELF file (via the
> BDI probe) and then I start the program.

So you don't have a ROM eCos running first? eCos RAM images are
generally expecting that an eCos ROM image ran first and setup stuff
which the RAM image then does not touch. I don't know if this is true
for AT91SAM7, since i rarely used RAM startup, and when i did, i had
redboot running first. It might work, it might not....

> My ecos configuration is identical to the one I use to boot from ROM,
> except I changed the startup type to RAM. (The ROM setup works like a
> charm) I also added the required linker settings:
> 
> MEMORY
> {
> ram : ORIGIN = 0x20000000, LENGTH = 0x2000000
>     sram : ORIGIN = 0x00200000, LENGTH = 0x8000
>     rom : ORIGIN = 0x00100000, LENGTH = 0x80000
> }
> 
> SECTIONS
> {
>     SECTIONS_BEGIN
>     CYG_LABEL_DEFN(__reserved_bootmon) = 0x00000000; . =
> CYG_LABEL_DEFN(__reserved_bootmon) + 0x01000;
>     SECTION_rom_vectors (ram, 0x20200000, LMA_EQ_VMA)
>     SECTION_text (ram, ALIGN (0x1), LMA_EQ_VMA)
>     SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
>     SECTION_fixed_vectors (ram, 0x20000040, LMA_EQ_VMA)
>     SECTION_data (ram, ALIGN (0x4), FOLLOWING (.gcc_except_table))
>     SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
>     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
>     SECTIONS_END
> }
> 
> 
> I think I tracked down the problem to this code in
> /arm/arch/current/src/vectors.S:
> <snip>
> start:
>        LED 5
> #if defined(CYG_HAL_STARTUP_RAM) && \
>     !defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)
> // If we get restarted, hang here to avoid corrupting memory
>         ldr     r0,.init_flag
>         ldr     r1,[r0]
> 1:      cmp     r1,#0
>         bne     1b
>         ldr     r1,init_done
>         str     r1,[r0]
> #endif
> </snip>
> Could someone explain what this code is supposed to do? According to
> me, it just spins forever, but my assembly is kinda rusty.

The C equivalent would be

void start() {
     static init_flag = 0;

     if (init_flag) {
loop:
        goto loop:
     }             
     init_flag = init_done;
}

For some reason start is being called twice and the second time is an
error case, so it just loops allowing you to get in with a debugger
to figure out what went wrong.

I don't know if this is an intelligent question or not: Which start is
getting called? The ROM or the RAM one? What happened that start got
jumped into? Is init_flag actually zero on the first entry to start?

       Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Running code from external ram on the AT91SAM7SE

[Tom Deconinck]

On 11/6/07, Andrew Lunn <andrew@lunn.ch> wrote:
> On Tue, Nov 06, 2007 at 11:13:24AM +0100, Tom Deconinck wrote:
> > Hello,
> >
> > I having problems running code out of external SDRAM on the
> > AT91SAM7SE512. This is a CPU similar to the AT91SAM7S family, but it
> > has an external bus interface and an integrated SDRAM controller.
> > So far I have tried an eCos minimal setup and a 'normal' hello world
> > application, both without any success.
> > My setup is as follows: I have a BDI2000 that sets up and configures
> > the SDRAM controller, then I use GDB to load in the ELF file (via the
> > BDI probe) and then I start the program.
>
> So you don't have a ROM eCos running first? eCos RAM images are
> generally expecting that an eCos ROM image ran first and setup stuff
> which the RAM image then does not touch. I don't know if this is true
> for AT91SAM7, since i rarely used RAM startup, and when i did, i had
> redboot running first. It might work, it might not....
>
> > My ecos configuration is identical to the one I use to boot from ROM,
> > except I changed the startup type to RAM. (The ROM setup works like a
> > charm) I also added the required linker settings:
> >
> > MEMORY
> > {
> > ram : ORIGIN = 0x20000000, LENGTH = 0x2000000
> >     sram : ORIGIN = 0x00200000, LENGTH = 0x8000
> >     rom : ORIGIN = 0x00100000, LENGTH = 0x80000
> > }
> >
> > SECTIONS
> > {
> >     SECTIONS_BEGIN
> >     CYG_LABEL_DEFN(__reserved_bootmon) = 0x00000000; . =
> > CYG_LABEL_DEFN(__reserved_bootmon) + 0x01000;
> >     SECTION_rom_vectors (ram, 0x20200000, LMA_EQ_VMA)
> >     SECTION_text (ram, ALIGN (0x1), LMA_EQ_VMA)
> >     SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
> >     SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
> >     SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
> >     SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
> >     SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
> >     SECTION_fixed_vectors (ram, 0x20000040, LMA_EQ_VMA)
> >     SECTION_data (ram, ALIGN (0x4), FOLLOWING (.gcc_except_table))
> >     SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
> >     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
> >     SECTIONS_END
> > }
> >
> >
> > I think I tracked down the problem to this code in
> > /arm/arch/current/src/vectors.S:
> > <snip>
> > start:
> >        LED 5
> > #if defined(CYG_HAL_STARTUP_RAM) && \
> >     !defined(CYGDBG_HAL_DEBUG_GDB_INCLUDE_STUBS)
> > // If we get restarted, hang here to avoid corrupting memory
> >         ldr     r0,.init_flag
> >         ldr     r1,[r0]
> > 1:      cmp     r1,#0
> >         bne     1b
> >         ldr     r1,init_done
> >         str     r1,[r0]
> > #endif
> > </snip>
> > Could someone explain what this code is supposed to do? According to
> > me, it just spins forever, but my assembly is kinda rusty.
>
> The C equivalent would be
>
> void start() {
>      static init_flag = 0;
>
>      if (init_flag) {
> loop:
>         goto loop:
>      }
>      init_flag = init_done;
> }
>
> For some reason start is being called twice and the second time is an
> error case, so it just loops allowing you to get in with a debugger
> to figure out what went wrong.
>
> I don't know if this is an intelligent question or not: Which start is
> getting called? The ROM or the RAM one? What happened that start got
> jumped into? Is init_flag actually zero on the first entry to start?
>
>        Andrew
>

Thanks for the assembly clarification.
I've verified it: it's the RAM startup that gets called. I'm getting
into start because the start address is set in the ELF file (first,
the CPSR register is set and then the start is called)

The init_flag is not zero, not even the first time the code gets
called, that explains the looping.

I'm going to try it using redboot first tomorrow, I hope that does the trick.
If that works, I'll only have a problem with my final hardware,
because that will run the AT91SAM7SE32 which has only 32Kb of Flash,
unless I could squeeze redboot into that size.

Tom

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Running code from external ram on the AT91SAM7SE

[Andrew Lunn]

> Thanks for the assembly clarification.
> I've verified it: it's the RAM startup that gets called. I'm getting
> into start because the start address is set in the ELF file (first,
> the CPSR register is set and then the start is called)
> 
> The init_flag is not zero, not even the first time the code gets
> called, that explains the looping.

That is significant and probably indicates a bigger problem.

Are you sure your data section is getting loaded? Do an
arm-elf-objdump --headers on your image and see what flags are on the
data section.

     Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Running code from external ram on the AT91SAM7SE

[Tom Deconinck]

On 11/6/07, Andrew Lunn <andrew@lunn.ch> wrote:
> > Thanks for the assembly clarification.
> > I've verified it: it's the RAM startup that gets called. I'm getting
> > into start because the start address is set in the ELF file (first,
> > the CPSR register is set and then the start is called)
> >
> > The init_flag is not zero, not even the first time the code gets
> > called, that explains the looping.
>
> That is significant and probably indicates a bigger problem.
>
> Are you sure your data section is getting loaded? Do an
> arm-elf-objdump --headers on your image and see what flags are on the
> data section.
>
>      Andrew
>

I have checked the flags on the data section: (see below for the
complete output of objdump --header)

 15 .data         00000264  20000180  202047d0  00010180  2**2
                  CONTENTS, ALLOC, LOAD, DATA

The one thing I find strange is that it says DATA and not CODE. I
would have expected to see CODE. My experience with PowerPC based
platforms is that the data section is flagged as CODE, is this perhaps
different for ARM?

Tom

main:     file format elf32-littlearm

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .debug_aranges 000006d0  00000000  00000000  000103e4  2**0
                  CONTENTS, READONLY, DEBUGGING
  1 .debug_pubnames 00000be7  00000000  00000000  00010ab4  2**0
                  CONTENTS, READONLY, DEBUGGING
  2 .debug_info   0000a004  00000000  00000000  0001169b  2**0
                  CONTENTS, READONLY, DEBUGGING
  3 .debug_abbrev 00001970  00000000  00000000  0001b69f  2**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_line   000055c5  00000000  00000000  0001d00f  2**0
                  CONTENTS, READONLY, DEBUGGING
  5 .debug_frame  00001180  00000000  00000000  000225d4  2**2
                  CONTENTS, READONLY, DEBUGGING
  6 .debug_str    000026ea  00000000  00000000  00023754  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .rom_vectors  00000040  20200000  20200000  00008000  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  8 .text         000045b4  20200040  20200040  00008040  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  9 .fini         00000000  202045f4  202045f4  00025e3e  2**0
                  CONTENTS
 10 .rodata       000001da  202045f4  202045f4  0000c5f4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 11 .rodata1      00000000  202047d0  202047d0  00025e3e  2**0
                  CONTENTS
 12 .fixup        00000000  202047d0  202047d0  00025e3e  2**0
                  CONTENTS
 13 .gcc_except_table 00000000  202047d0  202047d0  00025e3e  2**0
                  CONTENTS
 14 .fixed_vectors 00000140  20000040  20000040  00025e40  2**5
                  CONTENTS, READONLY
 15 .data         00000264  20000180  202047d0  00010180  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 16 .bss          000081e0  200003e4  200003e4  000003e4  2**5
                  ALLOC
 17 .comment      00000168  00000000  00000000  00025f80  2**0
                  CONTENTS, READONLY
 18 .debug_ranges 000000c8  00000000  00000000  000260e8  2**0
                  CONTENTS, READONLY, DEBUGGING

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Running code from external ram on the AT91SAM7SE

[Andrew Lunn]

> I have checked the flags on the data section: (see below for the
> complete output of objdump --header)
> 
>  15 .data         00000264  20000180  202047d0  00010180  2**2
>                   CONTENTS, ALLOC, LOAD, DATA

DATA is O.K.

However what is strange is the VMA and LMA addressing being different.
Look at all the other segments:


> Sections:
> Idx Name          Size      VMA       LMA       File off  Algn
>   7 .rom_vectors  00000040  20200000  20200000  00008000  2**0
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   8 .text         000045b4  20200040  20200040  00008040  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   9 .fini         00000000  202045f4  202045f4  00025e3e  2**0
>                   CONTENTS
>  10 .rodata       000001da  202045f4  202045f4  0000c5f4  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>  11 .rodata1      00000000  202047d0  202047d0  00025e3e  2**0
>                   CONTENTS
>  12 .fixup        00000000  202047d0  202047d0  00025e3e  2**0
>                   CONTENTS
>  13 .gcc_except_table 00000000  202047d0  202047d0  00025e3e  2**0
>                   CONTENTS
>  14 .fixed_vectors 00000140  20000040  20000040  00025e40  2**5
>                   CONTENTS, READONLY
>  15 .data         00000264  20000180  202047d0  00010180  2**2
>                   CONTENTS, ALLOC, LOAD, DATA
>  16 .bss          000081e0  200003e4  200003e4  000003e4  2**5
>                   ALLOC
>  17 .comment      00000168  00000000  00000000  00025f80  2**0
>                   CONTENTS, READONLY
>  18 .debug_ranges 000000c8  00000000  00000000  000260e8  2**0
>                   CONTENTS, READONLY, DEBUGGING

It might be worth exploring this...

   Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss