From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3216 invoked by alias); 21 Jan 2009 02:13:31 -0000 Received: (qmail 3206 invoked by uid 22791); 21 Jan 2009 02:13:30 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from hagrid.ecoscentric.com (HELO mail.ecoscentric.com) (212.13.207.197) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 21 Jan 2009 02:13:24 +0000 Received: from localhost (hagrid.ecoscentric.com [127.0.0.1]) by mail.ecoscentric.com (Postfix) with ESMTP id E3EDB3B40040; Wed, 21 Jan 2009 02:13:21 +0000 (GMT) Received: from mail.ecoscentric.com ([127.0.0.1]) by localhost (hagrid.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8TuxABhBwS7Y; Wed, 21 Jan 2009 02:13:18 +0000 (GMT) Message-ID: <497684C5.8020900@eCosCentric.com> Date: Wed, 21 Jan 2009 02:13:00 -0000 From: Jonathan Larmour User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc3.4.legacy (X11/20060515) MIME-Version: 1.0 To: Andrew McKay CC: eCos developers Subject: Re: Redboot hanging during boot on EP9302 References: <49765D66.6090801@iders.ca> In-Reply-To: <49765D66.6090801@iders.ca> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact ecos-devel-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: ecos-devel-owner@ecos.sourceware.org X-SW-Source: 2009-01/txt/msg00035.txt.bz2 Hi Andrew, You misaddressed this to ecos-devel-owner instead of ecos-devel. I've CC'd it to ecos-devel for you in case anyone can help. For what it's worth, in the 9 times out of 10 it works, is it solid? Might it be worth trying out the eCos "heaptest" test (perhaps increasing the iterations) to verify the stability of SDRAM in case the timings are marginal? Jifl Andrew McKay wrote: > Hey guys, > > I'm having issues with our EP93xx hanging during reboots with an > external watchdog. It crashes 1 out of every 10 reboots or so. I the > code is crashing in two places (that I've found so far). The first is > when the code attempts to jump to code in RAM copied out of flash. The > second is when the Intel Strata flash driver copies it's routine to RAM > and tries to jump to it. The second case is a bit silly because the > code is already executing from RAM. I think that it makes the > assumption that it is executing in Flash, that's why the driver makes > another copy of a routine in RAM. > > The EP93xx code I'm using is from Cirrus Logic's 1.3.0 patches that they > supplied with the processor. I also have their 1.4.5 patches, though > we're not using that code for our current bootloader. On a quick look > it didn't appear that there was any major differences in SDRAM setup and > configuration. > > Anyways the ep93xx's platform set up code the following happens: > > ldr r0,=__rom_vectors_lma // Relocate FLASH/ROM to RAM > ldr r1,=__rom_vectors_vma // ram base & length > ldr r2,=__ram_data_end > 20: ldr r3,[r0],#4 > str r3,[r1],#4 > cmp r1,r2 > bne 20b > > //Jump to ram > // > ldr r0,=30f > mov pc,r0 > nop > nop > nop > nop > 30: > // Turn on Green LED, Turn off the Red LED. > // > ldr r1, =EP9312_LED_DATA > ldr r0, [r1] > eor r0, r0, #(EP9312_LED_GREEN_ON | EP9312_LED_RED_ON) > strb r0,[r1] > > .endm > > In cases where it fails it never gets to the code in RAM. > > I added a check in between the copy and the jump. > > //lets do a compare of copied data! > ldr r0,=__rom_vectors_lma > ldr r1,=__rom_vectors_vma > ldr r2,=__ram_data_end > 25: ldr r3,[r0],#4 > ldr r4,[r1],#4 > cmp r3,r4 > beq 26f > //If we get here our copy was corrupted! Turn on LEDs to warn!!! > ldr r3,=0x80840040 > ldr r4,=0x0 > str r4,[r3] > 26: cmp r1,r2 > bne 25b > > When the board crashes booting up, the LEDs I turn on in this code are > on signaling that the copy failed. > > I suspect there is possibly an issue initializing the SDRAM on a warm > boot. I don't suspect it's an issue with NOR flash for two reasons. > First, I have checked the setup for NOR Flash and it is running with the > most conservative timings possible. Secondly, code is executing out of > NOR flash prior to the jump to RAM. > > I'm currently going through the SDRAM initialization code to see if I > can find a problem, but so far I haven't. Though I'm not through all of > it with a fine tooth comb yet. > > I can work around the problem by using an external watchdog to reboot > the system if the jump isn't successful. However I don't like that as a > permanent solution because it's coving up an underlying issue with SDRAM > as far as I can tell. > > Does anyone have any ideas, solutions, or recommendations? Any help at > all would be greatly appreciated. > > Andrew McKay > Iders Inc. > -- eCosCentric Limited http://www.eCosCentric.com/ The eCos experts Barnwell House, Barnwell Drive, Cambridge, UK. Tel: +44 1223 245571 Registered in England and Wales: Reg No 4422071. ------["The best things in life aren't things."]------ Opinions==mine