[U-Boot-Users] Re: Moving u-boot location in ram to do full mem-test?

[Wolfgang Denk]

In message <dm1a2e$cdt$1 at 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

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The joys of love made her human and the  agonies  of  love  destroyed
her.
	-- Spock, "Requiem for Methuselah", stardate 5842.8