This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: Running code from external ram on the AT91SAM7SE
- From: Andrew Lunn <andrew at lunn dot ch>
- To: Tom Deconinck <t dot deconinck at gmail dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Tue, 6 Nov 2007 11:34:13 +0100
- Subject: Re: [ECOS] Running code from external ram on the AT91SAM7SE
- References: <e37cb5250711060213h651ab1a5id4e2bf00e4f917bc@mail.gmail.com>
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