"Martin Jarman" <[EMAIL PROTECTED]> 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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
