How can I test the RAM for data corruption on an ARM-based system?

Question

I have an embedded device. It is ARM based, with Linux 2.6.31 and has 256 MB RAM.

I wanted to get some ideas/tips on what is the most effective way to test the device RAM for data corruptions. Is there a test/software that someone can suggest?

Note:

I have memtester now. I got it after suggestion from Ulrich Dangel (below).

I also have mtest set up from the uboot now.

Any other tests / approaches I could use?

Note that this is an ARM CPU, not a x86 one; unfortunately, Memtest86+ will not work in this case. — Renan, May 18 '12 at 02:56
@abc what else do you want? i think you have some other issues if these method won't produce the result you want. `mtest` basically does the same as memtest86+. You basically have different options, run the memory test from your operating system like linux (this would be `memtester` but you may have problems testing the whole physical region). You can also use some mini system (uboot) to test your memory (`mtest`) — Ulrich Dangel, May 30 '12 at 12:17
Is the processor from Marvell? I have the same question on a marvell network processor, which is exactly the same configuration (ARM/256MB RAM/Linux 2.6.31) as yours. — Tim Wu, Apr 28 '13 at 17:58
Here is a [similar stack overflow question](http://stackoverflow.com/questions/11640062/how-to-do-memory-test-on-arm-architecture-hardware-something-like-memtest86). All of the tests here can find some problems. They will not find all problems and in fact, this is very difficult to do. Only very good board simulation tools and modelling can verify this; not software. If this is done then the only problem will be a DDR chip (or possibly host controller) and *memtester* and *mtest* may find these. However, if they do say everything is fine; don't 100% rule out a DDR issue. — artless noise, Dec 28 '14 at 17:11

Ulrich Dangel · Answer 1 · 2012-05-30T12:36:36.697

22

The general solution to test memory is to write a specific pattern like 0xFFFFFFFF to your memory and read it afterwards and compare the result. You can and should of course alter the pattern to discover problems. Some solutions like memtest86+ also generate random patterns and change the direction they use to write to the memory. For more detailed information about the used algorithms in memtest86 have a look at their tech page. All solutions provided in this post are using basically the same underlying idea.

If you want to run your test from within Linux (you mentioned Linux in your post) have a look at memtester and the memtest suite which both should work with arm. To get started you should use memtester as it basically does exactly what you want.

Testing your memory from within Linux has some disadvantages like you can't really test all of your physical memory as the kernel also needs memory. To test the memory with uboot (it is much smaller than the linux kernel) have a look at the integrated mtest command. It allows you to specify the address range, pattern and iteration. With mtest you should be able to do pretty extensive testing without relying on a operating system. You just have to make sure you are using valid memory ranges otherwise it may be possible that you overwrite the uboot memory region.

If the testing provided by mtest is not enough you can of course just extend uboot and integrate additional memory testing features into uboot.

edited May 30 '12 at 12:36

answered May 17 '12 at 19:33

Ulrich Dangel

25,079
3
80
80

OK I got memtester. Any other test I can do? – Ankur Agarwal May 18 '12 at 17:47
1

Any other test approaches I could try? I am thinking of testing RAM from uboot. – Ankur Agarwal May 25 '12 at 05:27
@abc ok i added a note about uboots mtest command – Ulrich Dangel May 25 '12 at 05:36
1

I started using uboot commands and now I am seeing that memory display uboot command gets stuck in the middle `bist > md.w 0x00000023 10 00000023:` – Ankur Agarwal Jun 01 '12 at 00:04
u-boot have support for two different mtest. Compile with CONFIG_SYS_ALT_MEMTEST for a more extensive memory testing than default. – m__ Jul 03 '13 at 06:50
Testing RAM is much more complex than writing a pattern and reading it afterwards. Often defective RAM works for that, but fails if you access it in certain ways (e.g. address range R1 then address range R2 in close succession). – Gilles 'SO- stop being evil' Jun 03 '15 at 21:08

score 1 · Accepted Answer · answered Aug 16 '20 at 22:48

Das U-Boot is perhaps the most widely used boot loader on ARM boards, and it includes some memory test features.

Interestingly, its README suggests an alternative approach that might be more portable and/or more effective:

The best known test case to stress a system like that is to boot Linux with root file system mounted over NFS, and then build some larger software package natively (say, compile a Linux kernel on the system) - this will cause enough context switches, network traffic (and thus DMA transfers from the network controller), varying RAM use, etc. to trigger any weak spots in this area.

While you're building the linux kernel, you might be interested in the CONFIG_MEMTEST=y option, which causes the built-in memory test to be built. This used to be for x86 architecture only, but I believe recent versions support it on other architectures as well, perhaps even ARM.

The memtester tool is already built and available in some linux distributions, for various architectures, including ARM.

The kernel-memtest project might interest you as well.

Bear in mind that no tool can test the memory that it's running from (so a program in a running OS will have significant blind spots) and basic read/write tests won't reveal every type of defect or other error. Set your expectations accordingly, and if you have reason to suspect bad memory, consider trying several different test tools.

How can I test the RAM for data corruption on an ARM-based system?

2 Answers2

Linked