Re: [U-Boot] Special memory test Question
Dear Martin, please keep the ML on Cc:. In message [EMAIL PROTECTED] you wrote: Is there by chance any watchdog on your system that mith have such a timeout / reset period? ... 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. However if I type loop .b Flash memory address e.g. loop . 4 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 -- 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: [EMAIL PROTECTED] Don't hit a man when he's down - kick him; it's easier. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Special memory test Question
Haavard Skinnemoen [EMAIL PROTECTED] wrote: 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. Nope, it's a user error. Try running this command instead: loop.b 1040 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 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Special memory test Question
Dear Haavard Skinnemoen, 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. dcache, and subsequent accesses will simply read it from the dcache and not cause any memory accesses. Maybe, maybe not. 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 -- 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: [EMAIL PROTECTED] Faith: not *wanting* to know what is true.- Friedrich Nietzsche ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Special memory test Question
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 1040
That's without a length specification, right?
(1040 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 1040 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 1040 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
Re: [U-Boot] Special memory test Question
Dear Martin Jarman, In message [EMAIL PROTECTED] 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? 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 1040 (1040 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 -- 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: [EMAIL PROTECTED] Your own mileage may vary. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
