Special memory test Question
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
(10400000 is an address in SDRAM)
Nothing happens for about 20 Seconds, then there is an 'Unhandled exception' and the processor reboots.
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)?
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.
Any comments, help or advice will be greatly appreciated.
Martin Jarman
Dear "Martin Jarman",
Quoted 2 lines · In message <000801c929c5$01d37060$4201a8c0@amil> you 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
Are other applications (including U-Boot itself and maybe Linux) running fine?
Quoted 7 lines
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:
Quoted 5 lines
loop .b 10400000
(10400000 is an address in SDRAM)
Nothing happens for about 20 Seconds, then there is an 'Unhandled exception' and the processor reboots.
Is there by chance any watchdog on your system that mith have such a timeout / reset period?
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Your own mileage may vary.
A message that is not in the archive (sent off-list or not yet received): 001201c92a17$ee1381c0$4201a8c0@amil
Dear Martin,
please keep the ML on Cc:.
Quoted 3 lines · In message <001201c92a17$ee1381c0$4201a8c0@amil> you wrote:
Quoted 3 lines
Is there by chance any watchdog on your system that mith have such a timeout / reset period?
...
Quoted 11 lines
Thank you for your quick reply. U-Boot appears to work properly apart from the "loop" command. I have not run Linux, but different versions of my application will normally fail in a similar way to what happens when using the loop command (but after different periods of time i.e 0 to 30 seconds).
If I type
loop .b <SDRAM address>
or
loop .b <internal SRAM address>
U-boot, after about 20 seconds, produces the dump copied below.
Quoted 6 lines
However if I type
loop .b <Flash memory address>
e.g. loop . 40000
the code appears to go into an infinate loop.Would a dump be produced if the loop command was terminated by a watchdog?
No, not as you describe.
I think there are two likely reasons for your problem remaining: (1) incorrect initialization of your RAM (see FAQ # 1), and (2) a hardware problem.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de Don't hit a man when he's down - kick him; it's easier.
Quoted 10 lines · Martin Jarman
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?
Quoted 3 lines
(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:
Quoted 1 line
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...
Quoted 3 lines
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.
Quoted 4 lines
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
Quoted 3 lines · Haavard Skinnemoen
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.
Actually, that's wrong. It won't scribble over anything since it only does reads. But it will access an invalid address and get a bus error exception eventually.
Quoted 5 lines
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.
Btw, that command won't actually test the SDRAM since do_mem_loop() accesses cacheable memory. The first access will load the data into the dcache, and subsequent accesses will simply read it from the dcache and not cause any memory accesses.
What is this command supposed to test anyway? It's highly unlikely that it will find any SDRAM problems by simply reading an address without checking the result...
Haavard
Dear Haavard Skinnemoen,
Quoted 3 lines · In message <[email protected]> you wrote:
Btw, that command won't actually test the SDRAM since
do_mem_loop()accesses cacheable memory. The first access will load the data into the
This depends on your board configuration. Date cache may be globally enabled or not, or anabled or not for the specific address range in question.
Quoted 2 lines
dcache, and subsequent accesses will simply read it from the dcache and not cause any memory accesses.
Maybe, maybe not.
Quoted 3 lines
What is this command supposed to test anyway? It's highly unlikely that it will find any SDRAM problems by simply reading an address without checking the result...
The command is not restricted on reading from SDRAM, but works on any other address ranges, too. SOmetimes it's pretty helpful to see read cycles from a certain address (range) without anything other traffic on the bus - it makes it easy to analyze timings and signal quality, etc.
Best regards,
Wolfgang Denk
Signature · 4 lines
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de "Faith: not *wanting* to know what is true." - Friedrich Nietzsche
----- Original Message -----
From: "Haavard Skinnemoen" <[email protected]>
To: "Martin Jarman" <[email protected]>
Cc: <[email protected]>
Sent: Friday, October 10, 2008 12:43 PM
Subject: Re: [U-Boot] Special memory test Question
Quoted 20 lines
Quoted 3 lines · Haavard Skinnemoen
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.
Actually, that's wrong. It won't scribble over anything since it only does reads. But it will access an invalid address and get a bus error exception eventually.
Quoted 5 lines
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.
Btw, that command won't actually test the SDRAM since
do_mem_loop()accesses cacheable memory. The first access will load the data into the dcache, and subsequent accesses will simply read it from the dcache and not cause any memory accesses.
Quoted 5 lines
What is this command supposed to test anyway? It's highly unlikely that it will find any SDRAM problems by simply reading an address without checking the result...
Haavard
Thank you for your replies, and I accept my 'user error' (head hung in shame) and can confirm the test appears to run correctly when called with the proper arguments. I note Wolfgang has answered your question about what the test is for.
best regards
Martin Jarman