[U-Boot] Special memory test Question

Haavard Skinnemoen haavard.skinnemoen at atmel.com
Fri Oct 10 13:32:10 CEST 2008


"Martin Jarman" <mjarman at 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


More information about the U-Boot mailing list