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?

Solution 1

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.

Solution 2

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.

Comments

[Admin]

Note that this is an ARM CPU, not a x86 one; unfortunately, Memtest86+ will not work in this case.

[Admin]

I got memtester. Any other tests/ approaches I could use?

[Admin]

@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)

[Admin]

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.

[Cees]

OK I got memtester. Any other test I can do?

[Cees]

Any other test approaches I could try? I am thinking of testing RAM from uboot.

[sunnysideup]

@abc ok i added a note about uboots mtest command

[Cees]

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:

[m__]

u-boot have support for two different mtest. Compile with CONFIG_SYS_ALT_MEMTEST for a more extensive memory testing than default.

[Gilles 'SO- stop being evil']

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).