如何在ARM架构硬件上进行内存testing? (像Memtest86)

有没有办法做android设备内存完整的内存testing?

我正在开发一个驱动程序,但在ramdom时间,我得到了错误的价值导致司机进入错误的状态的某些物理地址。 当我遇到问题时,我试图从RAM中读取数据。 我认为我的设备上的RAM的某些部分已损坏。

Solutions Collecting From Web of "如何在ARM架构硬件上进行内存testing? (像Memtest86)"

完整是一个含糊的词。 这可能意味着不同的温度,电压以及具有不同元件容差的一系列器件。 当你站点MemTest86 ,我想我明白了。 我看到的大多数项目都是基于C的,不能测试所有的东西。

这是一个在Linux运行http://www.madsgroup.org/~quintela/memtest/

有算法记录,如步行位等。很多取决于你的RAM类型。 我想你有一些类型的SDRAM。 SDRAM有许多不同的周期。 有单节拍读/写,银行间转账,终止连发等。

就个人而言,我们有一个系统,有5%的电路板在通过以太网(DMA)进行SSH传输时会出现问题。 SSH涉及CPU /内存密集型的加密,并且DMA引擎通常与CPU(带有缓存)不同的SDRAM循环。

这里有一些要求,

  1. 代码驻留的非SDRAM内存。
  2. 裸机框架(无缓存,中断,DMA等)
  3. 关掉DCache。
  4. 打开代码的ICache。

另一个限制性要求是运行时间 。 一个完整的 SDRAM测试可能需要几年时间才能在单个电路板上运行。 我发现一个伪随机地址/数据测试很好。 只要把与SDRAM大小相关的数字作为增量使用即可。 最简单的情况是1 。 您可能希望找到其他人不断更改rowsbanks和设备的大小; bank size-1例如; 然而,素数会更好,因为你有不同数量的位变化。 在关闭缓存的情况下,可以使用charshortintlong long指针来测试一些不同的突发长度。 这些测试会很慢。 你将需要使用ldm/stm对模拟一个完整的SDRAM突发 ,这些在缓存上更常见,所以你应该用ldm/stm来模拟它们。 这也是最快的测试之一。

 typedef unsigned char b8;
 typedef unsigned short b16;
 typedef unsigned long b32;
 typedef unsigned long long b64;

 / *使用宏来加速代码。 编译器将使用常量
  * _incr和_wrap而不是引起溢出的寄存器。 一个
  *宏集中存储器测试逻辑。
  * /
 #define MEMTEST(name,type,_incr,_wrap)...

 / *顺序测试。  * /
 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)

 / *随机测试。 这些测试尝试随机化数据和
  *地址访问。
  * /

字符为/ * 97 / 0x61,素数为9999991 / 0x989677。  * /
 MEMTEST(do_mem_rnd8,b8,97,9999991)
 / * 50839 / C697大素数为64k和9999991 / 0x989677素数为64MB。  * /
 MEMTEST(do_mem_rnd16,b16,50839,9999991)
 / * 3999971 / 3D08E3素数和9999991 / 0x989677素数为64MB。  * /
 MEMTEST(do_mem_rnd32,b32,3999971,9999991)
 / * 3999971 / 3D08E3素数和9999991 / 0x989677素数为64MB。  * /
 MEMTEST(do_mem_rnd64,b64,3999971,9999991)

incr是数据增量, wrap是地址增量。 突发的算法将是相同的。 这里有一些内联的gcc汇编器

  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)) ); \ 

这些测试很简单,应该适合代码缓存,这将最大化RAM的压力。 我们的主要问题是DQS延迟,这对于DDR-SDRAM是非常关键的,可以取决于温度和电压,并且会随着PCB布局和材料而变化。

如果您正在使用SDRAM芯片优化存储器控制器寄存器,则可以使用Cachbench 。 它也可能对测试有用。

另请参阅: Unix协议栈交换(同一问题) 。 我在Linux下使用了这些基于C的测试套件,但是在我们的案例中他们没有暴露任何问题。 memtest86算法可能不像上面描述的那样紧张(针对PCB毛刺); 尽管测试7burnBX测试是接近的。 我认为memtest86迎合了DRAM芯片问题,而不是电路板设计问题。

编辑:另一个问题是瞬态/与SDRAM芯片串扰。 如果您的设备驱动程序是高电流或高频设备,则由于电源变化,SDRAM接口可能会发生串扰,或获得双时钟 。 因此, RAM测试可能不会显示问题,并且只有在使用硬件的特定部分时才会发生SDRAM错误。 另外要注意Android设备不使用动态时钟并更改SDRAM频率。 随着时钟变化,信号可能会发生共振。