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

["Tom Deconinck" <t dot deconinck at gmail dot com>]

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