"Martin Jarman" mjarman@cabledoc.co.uk wrote:
I have an Atmel atngw100 development board and a standalone application that crashes within 10 to 30 seconds of starting. I have just discovered that the special memory test described in 5.9.2.10 of DULG also crashes the board after a similar amount of time.
With a fresh copy of the Atmel's release of the U-boot binary installed (version 1.1.3-00248-gae9bc0c), I press SPACE to abort autoboot, and then type:
loop .b 10400000
That's without a length specification, right?
(10400000 is an address in SDRAM) Nothing happens for about 20 Seconds, then there is an 'Unhandled exception' and the processor reboots.
From a quick scan, do_mem_loop() looks seriously buggy. No validation whatsoever is performed on the arguments to the function, so if the address and/or length can't be parsed as numbers, it will just continue anyway.
I think the problem is that "loop .b" should really be written as "loop.b". Otherwise, it will parse ".b" as a number and end up with zero, and use 10400000 as the length.
That will cause this code
if (size == 4) { for (;;) { longp = (uint *)addr; i = length; while (i-- > 0) junk = *longp++; } }
to start at physical address zero and scribble over the entire physical address range of the processor until it eventually tries to access an invalid physical address and gets a bus error exception.
This is confirmed by the error message:
Bus error at address 0x24008000
which is the address directly following the end of the internal SRAM, and the lowest invalid physical address.
I also believe it will completely overwrite u-boot itself on the way, but that probably doesn't cause any problems becase the infinite loop is running out of the icache.
I don't want to think about what this thing did to the NOR flash on the way though...
Assuming I don't have a hardware fault, does the above show that the configuration provided by Atmel does not work properly (or am I missing something)?
Nope, it's a user error. Try running this command instead:
loop.b 10400000 4
It's been running on my board for several minutes without crashing.
But IMO do_mem_loop() really ought to catch such things.
Note: U-boot will also crash if I did the loop test on an address in the ap7000's internal SRAM, but I assume the actual code for running the loop test is in SDRAM. So, if SDRAM is not being initialized correctly, this may be the reason the loop test crashes.
The code is indeed stored in SDRAM, but it's running from the icache.
Haavard