From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32385 invoked by alias); 6 Nov 2007 16:12:41 -0000 Received: (qmail 32376 invoked by uid 22791); 6 Nov 2007 16:12:40 -0000 X-Spam-Check-By: sourceware.org Received: from wr-out-0506.google.com (HELO wr-out-0506.google.com) (64.233.184.229) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 06 Nov 2007 16:12:33 +0000 Received: by wr-out-0506.google.com with SMTP id 50so791043wra for ; Tue, 06 Nov 2007 08:12:30 -0800 (PST) Received: by 10.142.48.14 with SMTP id v14mr1609448wfv.1194365549809; Tue, 06 Nov 2007 08:12:29 -0800 (PST) Received: by 10.142.251.9 with HTTP; Tue, 6 Nov 2007 08:12:29 -0800 (PST) Message-ID: Date: Tue, 06 Nov 2007 16:12:00 -0000 From: "Tom Deconinck" To: andrew@lunn.ch, ecos-discuss@ecos.sourceware.org In-Reply-To: <20071106103413.GG16191@lunn.ch> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20071106103413.GG16191@lunn.ch> Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Running code from external ram on the AT91SAM7SE X-SW-Source: 2007-11/txt/msg00035.txt.bz2 On 11/6/07, Andrew Lunn 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: > > > > 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 > > > > 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