This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Running code from external ram on the AT91SAM7SE


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]