Есть ли способ выполнить полную проверку памяти в ОЗУ устройства Android?
Я разрабатываю драйвер, но в разное время я получаю определенные физические адреса с неправильным значением, заставляя драйвер переходить в неправильное состояние. Я пытаюсь читать из ОЗУ, когда я попал в проблему. Я думаю, что некоторые порции RAM на моем устройстве повреждены.
Завершение - это двусмысленное слово. Это может означать разные температуры, напряжения и различные устройства с различными допусками компонентов. Как вы думаете, сайт MemTest86, я думаю, я понимаю. Большинство проектов, которые я видел, основаны на C и не могут проверить все.
Вот один работает под Linux - http://www.madsgroup.org/~quintela/memtest/
Существуют алгоритмы, описанные как ходячие биты и т.д. Многое зависит от вашего типа RAM. Я думаю, у вас есть какой-то тип SDRAM. Существует много разных циклов с SDRAM. Есть однобитовые чтения/записи, банковские переводы, завершенные всплески и т.д.
Лично у нас была система, 5% из плат отображали проблемы при передаче SSH через Ethernet (DMA). SSH включает в себя шифрование, которое интенсивно связано с CPU/памятью, а механизм DMA часто выполняет разные циклы SDRAM, чем процессор (с кешем).
Вот некоторые требования,
Другим ограничивающим требованием является время запуска. Полный тест SDRAM может занять годы, чтобы работать на одной плате. Я обнаружил, что тест псевдослучайных адресов/данных работает хорошо. Просто возьмите числа, которые являются относительными первичными по размеру SDRAM и используют это как прирост. Простейшим случаем является 1. Возможно, вы захотите, чтобы другие постоянно меняли rows, banks и размер устройства; bank size-1 например; однако простые числа будут работать лучше, поскольку у вас есть разные количества бит, меняющихся все время. Если вы отключите кеш, вы можете использовать указатели char, short, int и long long для проверки некоторых разных длин пакетов. Эти тесты будут медленными. Вам нужно будет использовать пары ldm/stm для имитации полного пакета SDRAM, это чаще встречается с кешем, поэтому вы должны имитировать их с помощью ldm/stm. Это также один из самых быстрых тестов.
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)
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)) ); \
Эти тесты просты и должны вписываться в кеш-код, который максимизирует нагрузку на ОЗУ. Нашей основной проблемой была задержка DQS, которая имеет решающее значение для DDR-SDRAM и может быть зависимой от температуры и напряжения и будет меняться в зависимости от компоновки печатной платы и материалов.
Cachbench можно использовать, если вы оптимизируете регистры контроллера памяти с помощью чипов SDRAM. Он также может быть полезен для тестирования.
Смотрите также: Unix Stack Exchange (тот же вопрос). Я использовал эти тестовые комплекты на базе C под Linux, но в нашем случае они не выявили никаких проблем. memtest86 алгоритмы могут быть не такими стрессовыми (для сбоев PCB), как я описываю выше; хотя тест 7 или тест burnBX близок. Я думаю, memtest86 может найти проблемы с чипами DRAM, а не проблемы с дизайном платы.
Изменить: Другая проблема - переходные/перекрестные разговоры с чипами SDRAM. Если ваш драйвер устройства является высокоточным или высокочастотным устройством, интерфейс SDRAM может поднять межсоединение или получить двойные часы из-за изменений в поставке. Таким образом, тест RAM может не обнаруживать проблем, и ошибка SDRAM возникает только при использовании определенной части аппаратного обеспечения. Также будьте осторожны, чтобы устройство Android не использовало динамическое синхронизацию и не меняло частоту SDRAM. Сигналы могут пересекать резонанс по мере изменения часов.