Yokel, ты рассматриваешь код в 16-ричном редакторе в 16 столбиков или в 17?
Может у тебя просто контроллёр другой или память.
Я рассматриваю тот, что в шапке с контроллёром UD1F.
Хотя во многих дампах видел тоже самое, но может быть и по другому, смотря какая геометрия.
Кстати, мы с gregorio ночью всё-таки провели эксперимент по заливке данных через USB.
Сейчас только вот получили данные и рассматриваем. Результат потом огласим.
Но сдаётся мне, уже при беглом просмотре, что в ECC не участвуют первые 6 байт.
Yokel, ты рассматриваешь код в 16-ричном редакторе в 16 столбиков или в 17?
Может у тебя просто контроллёр другой или память.
Я рассматриваю тот, что в шапке с контроллёром UD1F.
Хотя во многих дампах видел тоже самое, но может быть и по другому, смотря какая геометрия.
Кстати, мы с gregorio ночью всё-таки провели эксперимент по заливке данных через USB.
Сейчас только вот получили данные и рассматриваем. Результат потом огласим.
Но сдаётся мне, уже при беглом просмотре, что в ECC не участвуют первые 6 байт.
Контроллер у меня такой же как у тебя! Вот тебе служебка: 00 07 00 FD FF FF 62 38 0F 4B 50 04 3B F4 83 5E
Контроллер у меня такой же как у тебя! Вот тебе служебка:
00 07 00 FD FF FF 62 38 0F 4B 50 04 3B F4 83 5E
О_о у меня в дампе такого нет. У меня встречаются или 00 или FF.
Хотя может я напутал, может 5-ый байт отвечает.
Просто вчера рылся по документациям и в нескольких местах встречал раскладку по байтам, как оно должно быть.
У меня в основном в таком виде все сектора помечены:
Но сдаётся мне, уже при беглом просмотре, что в ECC не участвуют первые 6 байт.
Нет, всё не так. Видать всю ночь сидели с gregorio и уже галюники пошли.
Сегодня выспался и заново рассмотрел, что мы там нахимичили.
В общем структура данных сервисной области такая:
Сначала идёт сектор с самим MSID
Следом идут 3 сектора, полностью забитых FFFFFFFF
Затем идёт сектор с PID|VID+Размер(4Гб)+Формат_FAT(32)
То есть, структура идёт по формуле 1+3 - один сектор первичный, затем 3 вторичных сектора, потом опять первичный и 3 вторичных. И так вся карта.
Как мы знаем, 4 сектора - это одна страница. Вот и получается постраничная организация.
У Гриши попалась такая хитрая карта на 4 Гб, что в области MSID избыточные данные не имеют нумерации блоков. Там первые 4 байта просто FF FF FF FF, затем 2 байта FF FF и далее идёт 10 байтов ECC.
В общем, процесс происходил в следующем порядке:
Отпаяли микросхему памяти.
Сняли программатором дамп первого Банка(их там 4 Банка по 1 Гб).
Физический размер дампа вышел 1,03 ГБ (1 107 296 256 байт), что оказалось как бы больше размера, заявленного производителем. Но, если взяться за арифметику, то выясняется, что эта разница как раз составляет эти 16 байт избыточного кода, приклеиваемого к каждому сектору. А логический размер, без избыточного кода, вплоть до байтика равен ровно 1 Гб (1 073 741 824 байт).
Сохранили эти 5 служебных секторов с MSID/3хFFFFFFFF/PID|VID... отдельно
Удалили у каждого сектора служебку с ECC - по 16 байт. Правда 3 сектора по FFFFFFFF не имеют контрольной суммы, но избыточный код всё равно присутствует, просто все 16 байт тоже забиты FF-ками, поэтому конечно же тоже избавляемся от него. Собственно нас интересует только один сектор, где предположительно требуется смена MSID, но, для полноты эксперимента, забираем все 4 сектора + 5ый сектор, содержащий PID|VID|Format|Size
В итоге получилось 5 чистых логических секторов ровно по 512 байт.
Затем, имея в виду, что один блок содержит 256 секторов по 512 байт каждый - подсчитываем размер блока = 131072 байт.
Ложим эти 5 секторов в начало блока и забиваем оставшиеся 251 секторов блока символом "X" (58 в хексе) для наглядности. Таким образом у нас получился один цельный логический блок, размером 131072 байт (без ECC конечно)
Теперь копируем и размножаем этот шаблон блока до размера первоначально снятого дампа - 1,03 ГБ (1 107 296 256 байт). С размером умышленно переборьщили, рассчитывая на то, чтобы полностью переписался первый банк и чтобы не мешал оставшийся мусор, учытывая, что контроллёр сам подсчитает к каждому сектору свои 16 байт избыточного кода.
Таким образом, начало каждого блока у нас начинается с этих 5 секторов с MSID и далее забит просто "X-ами". Это делалось специально для того, чтобы проверить, действительно ли ECC меняется в каждом блоке.
Припаяли микросхему обратно на карту памяти, ничего не меняя в ней.
Подключаем по USB и заливаем этот файл Blank.bin, весом более 1 Гб в корень карты, с надеждой на то, что весь 1-ый Банк заполнится и останется без лишнего мусора.
Потом опять отпаиваем микросхему и снимаем дамп.
Проверяем и видим, что действительно в каждом блоке ECC меняется в виду того, что первые 4 байта имет нумерацию этого блока. С другой стороны, нумерация блока проставляется только в каждом первом секторе, каждой страницы. НО!!! В остальных 3-ёх секторах страницы нумерация в первых 4-ёх байтах отсутствует, но отлична от FF FF FF FF, там выставлено EF FF FF FF (а это печально, потому что мы могли бы подсчитывать ECC к MSID сектору). И таким образом, ECC у младших 3-ёх секторов по всему дампу одинакова, не зависимо от номера блока.
Вот этот заново снятый дамп, после заливки по USB поблочного файла. (Осторожно! после разархивации 1 Гб)
Можете сами посмотреть структуру и как сменяется ECC в зависимости от нумерации блока.
Итог:первые 4 байта избыточного кода - участвуют в формировании контрольной суммы ECC.
Потом я снял дамп со своей карты памяти с микрухой HY27UY08AG5M и контроллёром 0805-0
Но у меня первые 4 байта в системной области всё-таки пронумерованы.
Зато ECC не содержит нигде!
Скриншот
Последний раз редактировалось ErikPshat; 28.11.2011 в 20:27.
27.11.2011, 07:13
(3)
Комбинированный вид
![C чего начать? ⇒ ⇒ ⇒ [ЧАВО] - ответы на ЧАсто задаваемые ВОпросы](../forum/images/panel_start.png "C чего начать? ⇒ ⇒ ⇒ [ЧАВО] - ответы на ЧАсто задаваемые ВОпросы")
