I'm using "mtest" to test the sdram somewhat, but parts of the ram is ofcourse left untested doing so - due to stack- and u-boot positioning.
Not to forget exception vectors.
Oki :-)
So, I would like to make a new u-boot binary that offered me the possibility to test the first part - from "0x0" to "0x108F" and from "0x3f8af37" to "0x3ffffff".
Ummm... I seriously doubt if this is worth the effort. Typical problems like unconnected or shorted data or address lines or crosstalk will show up very reliably with the existing test.
But couldn't there be an error for a specific address segment - say "0x3ff0000"-"0x3ff00ff", which contains u-boot data never being used in u-boot, and not possible to test with mtest?
And the really nasty problems usually happen with burst mode accesses, and these are *not* covered by any such memory test at all. In my opinion the test as is is good enough as is to find coarse problems, and if you really want to stress test your memory just boot Linux with root file system mounted over NFS and compile a Linux kernel on the target. No smiley here, I really mean it.
Yes, but that would take days, if at all possible, on my 133 Mhz PPC405EP with 32 megs.
Then, I would rather have a "similar" memory exhausting test-application for Linux...
BR, Martin Egholm