In message dm1a2e$cdt$1@sea.gmane.org you wrote:
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?
In theory there could be such a problem. But 99% of all RAM memory errors fall into different patterns - at least from what I've seen.
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.
No. It takes 2...3 hours on a MPC860 with 50 MHz, so you might be done with approx. one hour or so (assuming a 2.4 kernel tree). And of course you can stop any time you like - as long as the system does not crash you are fine.
Then, I would rather have a "similar" memory exhausting test-application for Linux...
It's not just "memory exhaustion". It's the combination of context switches, code fetching, DMA going on all simultaneously. I have yet to find any other test code that produces back-to-back burst mode accesses in such a density. It's really difficult to come up with a similar strong memory test.
And bythe way - if you're testing your memory you *want* to have this test running for a long time, probably changing operational parameters like temperature, voltages, ... while runnign the test. Or injecting EM "noise" if you're testing for EMC...
Best regards,
Wolfgang Denk