怎么办内存测试ARM架构的硬件？ （类似的Memtest86） [英] How to do memory test on Arm Architecture Hardware? (something like Memtest86)
问题描述
有没有办法做到完全内存测试Android设备内存？
Is there a way to do complete memory test on android device RAM?
我正在开发一个驱动程序，但在ramdom时候我得到错误的值使驱动器进入错误状态一定的物理地址。我试图从RAM读取时，我打的问题。我觉得我的设备上RAM的某些部分已损坏。
I'm developing a driver but at ramdom times I get certain physical addresses with wrong value causing the driver to go into wrong state. I'm trying to read from RAM when I hit the problem. I Think certain portions of ram on my device are corrupted.
推荐答案
的完成的是一个模糊的词。这可能意味着不同的温度，电压和在一系列具有不同的组件的公差装置。当你的网站的的Memtest86 的，我想我明白。我所看到的大多数项目都的 C 的基础，不能检验一切。
Complete is an ambiguous word. It may mean different temperatures, voltages and across a range of devices with different component tolerances. As you site MemTest86, I think I understand. Most project I have seen are C based and can not test everything.
下面下的的Linux 的运行一个 - <一个href=\"http://www.madsgroup.org/~quintela/memtest/\">http://www.madsgroup.org/~quintela/memtest/
Here is one running under Linux - http://www.madsgroup.org/~quintela/memtest/
有记录的算法，比如走位的等。这在很大程度上取决于你的内存类型。我猜你有某种类型的SDRAM。没有与 SDRAM 许多不同的周期。有单拍读/写，银行到银行转账，合同终止阵阵，等等。
There are algorithms documented such as walking bits, etc. A lot depends on your RAM type. I guess you have some type of SDRAM. There are many different cycles with SDRAM. There are single beat reads/write, bank-to-bank transfer, terminated bursts, etc.
就个人而言，我们有一个系统都做了以太网（DMA）的SSH传输时，电路板的5％将显示问题。该SSH加密涉及到这是CPU /内存密集型和DMA引擎经常做不同的SDRAM周期比CPU（带缓存）。
Personally, we had a system were 5% of the boards would show problems when doing an SSH transfer over Ethernet (DMA). The SSH involves encryption which is CPU/memory intensive and the DMA engine often does different SDRAM cycles than the CPU (with cache).
下面是一些要求，
- 非SDRAM内存为code驻留。
- 裸机架构（无缓存，中断，DMA等）
- 关闭数据缓存。
- 打开ICACHE为code。
另一个限制要求是的时间的运行。 A 完整的SDRAM测试可能需要几年时间才能在一块电路板上运行。我已经发现一个伪随机地址/数据测试效果很好。只取是相素到SDRAM的大小和使用，作为增量编号。最简单的例子是 1 。你可能希望找到其他人不断地改变行，银行和器件尺寸; 银行规模-1 例如;然而，质数将作为你有不同的数量每时每刻都在变化的位更好。与缓存关闭，您可以使用字符，短， INT 和长长指针测试一些不同的突发长度。这些测试将是缓慢的。您将需要使用 LDM / STM 对来模拟一个完整的 SDRAM爆的，这些都是用的更常见于所以你应该用 LDM / STM 。这也是最快的一个测试
Another limiting requirement is the time to run. A complete SDRAM test could take years to run on a single board. I have found that a pseudo random address/data test works well. Just take numbers that are relative prime to the size of the SDRAM and use that as an increment. The simplest case is 1. You might wish to find the others to constantly change rows, banks and device size; bank size-1 for example; however prime numbers will work better as you have different amounts of bits changing all the time. With the cache off, you can use char, short, int, and long long pointers to test some different burst lengths. These tests will be slow. You will need to use ldm/stm pairs to simulate a full SDRAM burst, these are more common with the cache on so you should simulate them with ldm/stm. This is also one of the fastest tests.
typedef unsigned char b8;
typedef unsigned short b16;
typedef unsigned long b32;
typedef unsigned long long b64;
/* Use a macro to speed code. The compiler will use constants for
* _incr and _wrap instead of registers which cause spilling. A
* macro centralizes the memory test logic.
*/
#define MEMTEST(name,type,_incr,_wrap) ...
/* Sequential tests. */
MEMTEST(do_mem_seq8, b8, 97, 1)
MEMTEST(do_mem_seq16, b16, 50839, 1)
MEMTEST(do_mem_seq32, b32, 3999971, 1)
MEMTEST(do_mem_seq64, b64, 3999971, 1)
/* Random tests. These test try to randomize both the data and the
* address access.
*/
/* 97/0x61 prime for char and 9999991/0x989677 prime for 64MB. */
MEMTEST(do_mem_rnd8,b8,97,9999991)
/* 50839/C697 large prime for 64k and 9999991/0x989677 prime for 64MB. */
MEMTEST(do_mem_rnd16,b16,50839,9999991)
/* 3999971/3D08E3 prime and 9999991/0x989677 prime for 64MB. */
MEMTEST(do_mem_rnd32,b32,3999971,9999991)
/* 3999971/3D08E3 prime and 9999991/0x989677 prime for 64MB. */
MEMTEST(do_mem_rnd64,b64,3999971,9999991)
增量是数据的增量和包装是地址增量。对突发算法的将是相同的。下面是一些的内联汇编GCC 的
incr is the data increment and wrap is the address increment. The algorithm for the burst will be the same. Here is some inline gcc assembler,
register ulong t1 asm ("r0") = 0; \
register ulong t2 asm ("r4") = t1 + incr; \
register ulong t3 asm ("r6") = t2 + incr; \
register ulong t4 asm ("r8") = t3 + incr; \
/* Run an entire burst line. */ \
__asm__ (" stmia %[ptr], {%0,%1,%2,%3}\r\n" : : \
"r" (t1), "r" (t2), "r" (t3), "r" (t4), \
[ptr]"r" (start + (addr<<2)) : \
"memory" ); \
/* Read four 32 bits values. */ \
__asm__ (" ldmia %[ptr], {%0, %1, %2, %3}\r\n" : \
"=r" (t1), "=r" (t2), "=r" (t3), "=r" (t4) : \
[ptr]"r" (start + (addr<<2)) ); \
这些测试很简单，应该适合在code高速缓存，这将最大限度地对RAM的压力。我们的主要问题是，DQS延迟是用于DDR-SDRAM关键，可以是温度和电压相关的，并与印刷电路板的布局和材料而变化。
These tests are simple and should fit in the code cache which will maximize stress on the RAM. Our main issue was the DQS delay which is critical for DDR-SDRAM and can be temperature and voltage dependent and will vary with PCB layout and materials.
Cachbench 可以，如果你正在优化与SDRAM芯片的内存控制器寄存器中。它也可用于测试是有用的。
Cachbench can be used if you are optimizing the memory controller registers with the SDRAM chips. It may also be useful for testing.
参见：<一href=\"http://unix.stackexchange.com/questions/38887/how-can-i-test-the-ram-for-data-corruption-on-an-arm-based-system\">Unix堆栈交易所（相同的问题）。我用这些的 C 的Linux环境下基于测试套件，但他们并没有在我们的案例中暴露的问题。该的Memtest86算法可能没有压力（印制电路板故障）正如我上面描述;虽然测试的的 7 的或 burnBX 测试接近。我觉得的Memtest86 迎合找到DRAM芯片的问题，而不是板的设计问题。
See also: Unix Stack Exchange (same question). I used these C based test suites under Linux, but they didn't expose any issues in our case. The memtest86 algorithms may not be as stressful (for PCB glitches) as what I describe above; although test 7 or the burnBX test is close. I think memtest86 caters to find DRAM chip issues as opposed to board design issues.
的 修改的的另一个问题是与SDRAM芯片瞬变/串扰。如果您的设备驱动程序是一个高电流或高频设备，SDRAM接口能够尽可能拿起串扰，或获得的双时钟由于供应的变化。所以一个的 RAM测试的可能显示没有问题和SDRAM错误仅在使用硬件的特定部分发生的情况。另外要注意的Android设备不使用动态时钟和改变SDRAM频率。信号可以跨过谐振作为时钟的更改。
Another issue is transients/cross talk with the SDRAM chips. If your device driver is a high current or high frequency device, the SDRAM interface can possible pick up cross talk, or get a double clock due to supply variations. So a RAM test may show no issues and the SDRAM error only happens when a particular portion of hardware is used. Also be careful that the Android device doesn't use dynamic clocking and change the SDRAM frequency. Signals may cross a resonance as the clock changes.
这篇关于怎么办内存测试ARM架构的硬件？ （类似的Memtest86）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
