Да, но алгоритм вычисления ECC полностью аналогичен нашему (проверено)!

Сергей из soft-center.ru говорит, что если "изменить ECC на один байт (в предалах кооректирующей способности кода), то контроллер возможно пересчитает его на верный", кто первый проверит? gregorio куда то пропал.

в качестве поддержки продукта или по доброте душевной?

по доброте душевной, потому как за утилиту по расчету он просит 10000руб, либо за расчет одного блока 4000руб!

пробовал менять целиком, карта работать перестаёт.
на один байт менять не пробовал, сегодня займусь

Yokel, будут гарантии, скинемся, говновопрос.

Yokel, ну это ведь только для одной карты по сути.. ибо на всех он в разных местах лежит

gregorio добавил 24.11.2011 в 16:31
поменял один байт в ecc, интересно себя ведёт. возможно из-за непропая, щас проверю еще

gregorio добавил 24.11.2011 в 16:42
мило. после изменения одного байта ecc заработала(правда потребовалал себя форматнуть)

gregorio добавил 24.11.2011 в 16:51
но увы, на особой карте, файлы которой очень привередливы к карте памяти она в очередной раз выдала NG((((

что выдала, какой NG? Выпаяй микруху посмотри что с блоком!

Yokel, байт как был изменён, так и остался)

gregorio, карта перестала работать или, что с ней случилось?

Yokel, карта как карта работает, мсид правильный выдаёт, но как сервисная не работает(ошибку выдаёт)

gregorio добавил 24.11.2011 в 19:47
почти полностью уверен что с известным всем значением msid она всё-равно будет работать, и прошивать консоль. но для моих целей вариант не подходит.

Я думаю, что смена ECC ни к чему не приведёт. Это равнозначно, что смена MSID, как и смена ECC.
И в том и в другом случае ECC будет неадекватна.
Поэтому контроллёр занесёт такой блок в bad-block.

Я считаю, что ECC должен подсчитать сам контроллёр или научиться подсчитывать его самостоятельно.
А чтобы контроллёр подсчитывал ECC, нужно логически через него записывать этот блок/сектор. Тогда контроллёр сам подсчитает контролку всем переданным через него секторам.

Это можно сделать, только если ему разрешить запись в защищённую сервисную область.
Но, как мы знаем, эта область защищена от перезаписи.
Чтобы разрешить запись, нужно замкнуть ножку протектора на землю.

ErikPshat, правильно мыслите товарищ)
а по теме, щас займусь поиском. после ремонта своей приставки, убил тестами этих карт ей картридер.(

Кто в Си шарит? Вот исходники Рида-Соломона http://www.schifra.com/downloads/schifra.zip надо их курить! По екзамплу получается для 249 байт данных рассчитать 6 байт ECC, по котором можно потом опять данные восстановить!

Yokel, так... там каличный оутпут получается... Вылетает тот-жэ файл с 6-тибайтным смещением, походу и есть ващ ЕСС. Щас попробую сделать почеловечески, если нет, то научу патологоанатомии)

Ммм... карочи нет тайма жевать... Вот енкодер, как я сказал ужё, каличный (атач).
Как его кушать разобраться несложно. Прикол в другом. В оутпутном файле выдаётся тот же инпут, но со смещением в 6-байт: с 0x9F по 0xFE - сместитель (сместитель = ваш ЕСС). Тот файл, что я кинул для теста в инпут, мне первым подруку попался, заменяйте на свои... удачной паталогоанатомии... надеюсь - это то что вы хотели. Если то, то скажите я сделаю нормальный енкодер... а так, нет времени.

Простите, что вмешиваюсь.
Вот еще занятная штука, хотя может уже видели.
http://www.elnec.com/sw/an_elnec_nand_flash.pdf
http://www.elnec.com/sw/samsung_ecc_...m_for_512b.pdf
В последнем документе расписывается структура 16-байтного ECC для 512-байт блоков.
1,2,3 байты - номер блока
4, 5 - зарезервировано
6 - метка бэд-блока
7,8,9 - ECC code for Main area data, алгоритм вычисления тоже описан
10, 11 - ECC code for LSN data (ECC для номера блока) - заметьте, вычисляется отдельно и независимо от основных данных. Здесь уже предлагалось записать на карточку блок с нужными данными и подсмотреть его ECC, не прокатило - но что если здесь так же, то есть надо заменять не весь ECC а часть отвечающую за именно данные в блоке?
12-16 - зарезервировано.
с другой стороны, это только пример, и то от самсунга. Еще там написано что это для 64м-1гб нандов, для 2гб алгоритм может быть другим.

это не наш формат!

Yokel добавил 25.11.2011 в 18:16
Ты просто откомпилил что было. в примере он обрабатывает 255 байт данных а нам надо 518, и ECC нам надо не 6 байт, а 10!

Ага, на выходе получается белиберда, даже не учитывая сместившихся 6-ти байт.

Вот чем Samsung пользуется: Hamming code ECC is recommended to recover the error.

Источник

Карта 2 Гига имеет 2 банка по 1 Гигу.

1 Гб = 1073741824 байт.
Значит 2097152 секторов.
Получается 524288 страницы.
А это всего лишь 8192 блоков.
Значит в двух банках 16384 блоков или 0х4000.

Нудя.. понял, поработаю.

Frostegater, вот здесь какой-то пак:

http://rscode.sourceforge.net/
http://sourceforge.net/projects/rscode/

Вот пару валидных блоков 518/10 для проверки.

Рид-Соломон больше 255 байт не может обрабатывать.

Frostegater, всё правильно - 255, но туда ещё входят Parity байты, которые вставляются по формуле степеней 2 в степени m = 2, 4, 8, 16, 32...
Да и при том, что у каждого производителя контроллёров, алгоритм подсчёта свой CustomRS.
Насколько я понял, для рассчёта ECC в основном используется код Hamming'a, конечно же базирующийся на коде RS.
Так что здесь не всё так радужно.

А чё он у меня тогда 518 требует?..)))
Плин. Ты подавил мой тонус... Короче, железячники, дампите контроллер, мы, программисты, реверсанём.

Зечем контроллер дампить? ФлешЭкстрактор софт-центра в обратную сторону все считает! (по ЕСС восстанавливает данные)

алгоритмы ЕСС в нандах устройств от Texas Instruments:
http://processors.wiki.ti.com/index....ily_of_Devices
Есть готовое приложение GenECC.
Есть исходники на C#.
http://sourceforge.net/projects/dvfl...d?source=files
На каждые 512 байт получается, как и здесь, 80 бит ECC-кода по риду-соломону.
Но все равно результат не тот. Этих реализаций до черта, и в каждой видимо по своему делается.

дак дело не в нандах как я понимаю а в контроллере флешки(вернее даже не в самом контроллере а в его прошивке, потому как на одном и том же контроллере можно разные алгоритмы реализовать)

Конечно в контроллере, это же он все расчеты производит. ЕCC различается даже на разных мемористиках.
Вон на форуме флеш-экстрактора народ какие-то значения для ECC к разным флешкам подбирает.
http://flash-extractor.com/forum/vie...er=asc&start=0
что бы они значили...

Кто то юзал карты на контроллере кроме UD1X? Потому что в этих точно адрес участвует в расчете ЕСС, может на других контроллерах не участвует?

Здесь ещё интересная статья: http://processors.wiki.ti.com/index.php/Raw_NAND_ECC

Yokel, я пользую карты на другом контроллере

и че? участвует адрес?

Yokel, кстати не уверен. дамп залить куда-нибудь?

два блока с одинаковыми данными но разными адресами надо!

Да, даже одинаковые данные на разных стиках, вернее с разным контроллёром, имеют разный ECC. То есть, там явно видно, что идёт совершенно другая структура ECC.

Взять даже обычный Nand-Dump PSP, а он снимается так же в RAW-формате вместе с этим избыточным кодом.

Я думаю лучше нужно полностью забить флешку до байтика.
Если флешка 2 Гб, то нужно:

1. Создать файл, размером ровно 2 Гб (2147483648 байт)
2. Полностью сделать на него Fill одним и тем же байтом, например буквой Z.
3. Потом в первый сектор каждого блока записать один и тот же сектор служебной области с MSID.
4. Потом залить на карту по USB и снова снять RAW-дамп.

Таким образом, на карте не окажется случайных данных.

Ведь даже при быстром форматировании, данные не удаляются и этот мусор будет мешать изучению.
При полном форматировании, данные удаляются, но перезаписываются другим мусором.

Таким образом будет видно, как изменится ECC в разных блоках, как будет происходить нумерация блоков.
И соответственно будет чётко видно нашу "Z" и его ECC в разных блоках.
Так же, мы сможем сравнить сектор MSID оригинальный системный и этот же сектор в разных других несистемных областях.
Потом сделать вывод о данных ECC.

На вкус и цвет все фломастеры... Ой, не об этом же =) У всех производителей пользовательские 2ГБ разные. И чаще всего это 1.90 ГБ (x1024) либо ~200000000 байт (x1000).

Yoti, а ну да. Я замерял размер дампа флешки 2 Гб, она ровно байт в байт = 2 Гб (2147483648 байт).

Но это надо учитывать, что там служебная область забирает место и + избыточные 16 байт у каждого сектора.
Тут надо математикой заняться поглубже ))) ну 16 байт у каждого сектора, значит избыточных данных ровно 67108864 байт, которые нужно вычесть. И по моему там только один служебный блок.

ErikPshat, есть двушка и четвёрка подходящие под сервисные. могу сказать точный размер или скинуть дамп в хексе. поправишь его или сделаешь свой. зальём и проверим. если что я буду в асе(и дома) после половины первого, пиши если спать не будешь. как раз у меня будет время на всё

gregorio добавил 26.11.2011 в 23:29
и заодно есть чем проверить работоспособность) ведь по всеобщему мнению просто именно сами карты дохнут, а у меня некий софт на них работать отказывается.

gregorio добавил 26.11.2011 в 23:33
и именно из-за несовпадения контрольной суммы

gregorio добавил 26.11.2011 в 23:34
и еще, для общего развития, зануление ECC на кое-каких картах работает. и всё заново подсчитывается. но они редкие и довольно сложно пишутся

gregorio, ок, ася включена.

Проще конечно манипулировать 2 Гб картой.
Размер логического диска можно посмотреть через свойства, чем высчитывать: 2'033'942'528 байт = 3'972'544 секторов = 62071 блока.

Я подготовил сырой образ, забитый "X", потому что "Z" означает 5A, а это символ метки MBR карты.
От тебя нужен только сектор MSID от той карты, на которой будет производиться эксперимент.

ErikPshat, ща в асю приду, но дома буду только пол первого, и займусь