This is the mail archive of the
mailing list for the eCos project.
Re: Redboot hanging during boot on EP9302
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Andrew McKay <amckay at iders dot ca>
- Cc: eCos developers <ecos-devel at ecos dot sourceware dot org>
- Date: Wed, 21 Jan 2009 02:13:25 +0000
- Subject: Re: Redboot hanging during boot on EP9302
- References: <49765D66.firstname.lastname@example.org>
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?
Andrew McKay wrote:
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
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
20: ldr r3,[r0],#4
//Jump to ram
// 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)
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!
25: ldr r3,[r0],#4
//If we get here our copy was corrupted! Turn on LEDs to warn!!!
26: cmp r1,r2
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.
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