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?


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?

  • 2
    Note that this is an ARM CPU, not a x86 one; unfortunately, Memtest86+ will not work in this case. – Renan May 18 '12 at 2:56
  • I got memtester. Any other tests/ approaches I could use? – abc May 18 '12 at 17:47
  • 1
    @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. 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

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.

  • OK I got memtester. Any other test I can do? – abc May 18 '12 at 17:47
  • 1
    Any other test approaches I could try? I am thinking of testing RAM from uboot. – abc May 25 '12 at 5:27
  • @abc ok i added a note about uboots mtest command – Ulrich Dangel May 25 '12 at 5: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: – abc Jun 1 '12 at 0: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 3 '13 at 6:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.