Wie führen Sie Speicher-test auf Arm-Architektur Hardware? (so etwas wie Memtest86)

Komplette ist ein vieldeutiges Wort. Es kann bedeuten, verschiedene Temperaturen, Spannungen und in einer Reihe von Geräten mit unterschiedlichen Bauteil-Toleranzen. Wie Sie Webseite MemTest86, ich glaube, ich verstehe. Die meisten Projekte, die ich gesehen habe, sind C basiert und kann nicht alles testen.

Hier ist man unter Linux - http://www.madsgroup.org/~quintela/memtest/

Gibt es algorithmen dokumentiert, wie walking bits, etc. Viel hängt davon ab, Ihre RAM-Typ. Ich denke, Sie haben irgendeine Art von SDRAM. Es gibt viele verschiedene Zyklen mit SDRAM. Es gibt Einzel-beat liest/schreibt, bank-zu-bank-überweisungen, terminierte platzt, etc.

Persönlich, hatten wir ein system, wurden 5% der boards, die zeigen würde, Probleme, die beim durchführen einer SSH-transfer über Ethernet (DMA). Die SSH-Verschlüsselung beinhaltet, die CPU - /Speicher-intensiv und die DMA-engine oft hat verschiedene SDRAM-Zyklen als die CPU (mit cache).

Hier sind einige Anforderungen,

1. Nicht-SDRAM-Speicher für code gespeichert werden.
2. Bare-metal-Rahmen (kein cache, interrupts, DMA, usw)
3. Schalten Sie den DCache.
4. Schalten Sie den ICache für den code.

Anderen einschränkenden Voraussetzung ist die Zeit zu laufen. Ein komplette SDRAM test könnte Jahre dauern, zu laufen, auf einer einzigen platine. Ich habe festgestellt, dass ein pseudo-random-Adress - /Daten-test gut funktioniert. Nehmen Sie einfach die zahlen, die relativ prim zu der Größe der SDRAM und verwenden, die als eine Schrittweite. Der einfachste Fall ist 1. Möchten Sie vielleicht finden Sie die andere ständig ändern rows, banks - und Geräte-Größe; bank size-1 Beispiel, aber Primzahlen arbeiten besser als Sie haben unterschiedliche Mengen von bits ändern die ganze Zeit. Mit dem cache deaktivieren, können Sie char, short, int, und long long Zeiger zum testen einige verschiedene burst-Längen. Diese tests werden langsam. Benötigen Sie ldm/stm Paare, um zu simulieren eine full SDRAM burst, diese sind häufiger mit der cache auf so sollten Sie simulieren mit ldm/stm. Dies ist auch eine der schnellsten Prüfungen.

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

/* Verwenden Sie ein makro, um die Geschwindigkeit der code. Der compiler benutzen Konstanten für 
* _incr und _wrap anstelle von Registern, die Ursache zu verschütten. Ein 
* makro Zentralisierung der Speicher-test-Logik. 
*/
#define MEMTEST(name,Typ,_incr,_wrap) ... 

/* Laufende 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. Diese test versuchen Sie, mischen Sie sowohl die Daten als auch die 
* Adresse zugreifen. 
*/

/* 97/0x61 prime für char und 9999991/0x989677 prime für 64MB. */
MEMTEST(do_mem_rnd8,b8,97,9999991) 
/* 50839/C697 große prime für 64k und 9999991/0x989677 prime für 64MB. */
MEMTEST(do_mem_rnd16,b16,50839,9999991) 
/* 3999971/3D08E3 prime und 9999991/0x989677 prime für 64MB. */
MEMTEST(do_mem_rnd32,b32,3999971,9999991) 
/* 3999971/3D08E3 prime und 9999991/0x989677 prime für 64MB. */
MEMTEST(do_mem_rnd64,b64,3999971,9999991) 

incr ist die data-increment-und wrap ist die Adresse Inkrementieren. Der Algorithmus für die burst wird die gleiche sein. Hier einige gcc-inline-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)) );                    \

Diese tests sind einfach und sollten fit in den code-cache die Maximierung der Belastung auf den RAM. Unser Hauptproblem war die DQS-Verzögerung, die kritisch für DDR-SDRAM und kann Temperatur und Spannung abhängig und variieren mit PCB-layout und Materialien.

Cachbench kann verwendet werden, wenn Sie die Optimierung der Speicher-controller registriert mit der SDRAM-chips. Es kann auch nützlich sein für die Prüfung.

Siehe auch: Unix-Stack Exchange (gleiche Frage). Ich habe diese C basierten test-suites unter Linux, aber Sie nicht setzen Sie alle Probleme, die in unserem Fall. Die memtest86 algorithmen vielleicht nicht so stressig (für PCB glitches) wie was ich oben beschreiben; obwohl test 7 oder die burnBX test ist in der Nähe. Ich denke, memtest86 bietet finden DRAM-chip-Ausgaben im Gegensatz zum board-design.

Edit: ein Weiteres Problem ist der Transienten - /cross-talk mit den SDRAM-chips. Wenn Ihr Gerätetreiber ist ein hoher Strom oder hohe-Frequenz-Gerät, das SDRAM-interface kann möglich abholen cross-talk -, oder erhalten Sie einen Doppel-Uhr aufgrund von Angebot Variationen. So ein RAM-test zeigen keine Probleme und der SDRAM-Fehler geschieht nur, wenn ein bestimmter Teil der hardware verwendet wird. Auch darauf achten, dass das Android-Gerät nicht verwenden die dynamische Taktung und ändern Sie die SDRAM-Frequenz. Signale können cross-eine Resonanz, die Uhr änderungen.