From: Martin Egholm Nielsen <martin@egholm-nielsen.dk>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Re: Moving u-boot location in ram to do full mem-test?
Date: Wed, 23 Nov 2005 10:46:25 +0100 [thread overview]
Message-ID: <dm1dph$mrc$1@sea.gmane.org> (raw)
In-Reply-To: <20051123092105.3DA8E353DEA@atlas.denx.de>
Hi Wolfgang,
>>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.
Ok...
I have a specific board acting strange, so I was for starters suspecting
memory. But I will solder in a new memory chip to see if that indeed was
the problem...
>>>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.
Right...
>>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.
I see your point...
> 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...
Sure - but this is really too extensive for the individual board.
We're doing EMC test for a couple of units to the see the general
picture, but all units will run a 24h burnin test at 50 degrees Celcius...
Ok, for now I'll abandon the idea of expanding the mtest area, and
change the chip on the board that is causing me headaches...
Thanks,
Martin
next prev parent reply other threads:[~2005-11-23 9:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-22 15:43 [U-Boot-Users] Moving u-boot location in ram to do full mem-test? Martin Egholm Nielsen
2005-11-22 23:32 ` Wolfgang Denk
2005-11-23 8:42 ` [U-Boot-Users] " Martin Egholm Nielsen
2005-11-23 9:21 ` Wolfgang Denk
2005-11-23 9:46 ` Martin Egholm Nielsen [this message]
2005-11-23 10:16 ` Wolfgang Denk
2005-11-23 10:40 ` Martin Egholm Nielsen
2005-11-23 11:04 ` Wolfgang Denk
2005-11-24 13:14 ` Martin Egholm Nielsen
2005-11-24 14:31 ` Wolfgang Denk
2005-11-24 14:36 ` Martin Egholm Nielsen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='dm1dph$mrc$1@sea.gmane.org' \
--to=martin@egholm-nielsen.dk \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox