Главная Форум Статьи Файлы F.A.Q.


Последние активные темы форума

 
Софт для USB модемов (255) 13.09.17 11:48 kuhtikov
Модемы Alcatel (169) 23.08.17 13:35 swintys
Восстановление модемов с помощью Z_Flasher-Reanimator_modem v-05 «NEW_RAW_RELEASE» (1881) 01.08.17 13:59 palexxx
Тарифы (34) 30.07.17 09:31 sweetiepoly
   
Huawei E3131 (7) 24.07.17 14:19 getmejiayu
ZTE MF112 (616) 21.07.17 02:07 studio120
ZTE MF192 от МТС (121) 18.07.17 05:24 sergey67
Переделка МОДЕМОВ под внешние антенны. (322) 17.07.17 21:12 telez
 

Профиль

   
Логин: Пароль: Забыли пароль?Регистрация


Анатомия NAND - часть первая. Ведение в восстановление.
Форум > Работа с JTAG > Анатомия NAND - часть первая. Ведение в восстановление.

Страницы:
Автор Сообщение
 dumper4k
Ukraine
сообщений: 19
#1 Дата 29 июля 2011 02:20
В большенстве справочной литературы описания NAND будет описано технически достоверно но в данном случае
мы коснемся вопросов восстановления деффектов прошивок и бад блоков нанда в простейшем общем понимании.

структура NAND подобна структуре вашего HDD , есть загрузочная область (qscbl),
обрасть разметки (partition) и область данных (amss, efs, fota ..) но многого вам знать не нужно,
достаточно минимальных знаний для осознавания проводимых действий.


Для примера рассмотрим NAND модема ZTE MF180 - 64MB

Физическая структура NAND имеет разметку на две основные константы - блоки и страницы.
Эти две величины выбранны для управления разметкой файловой системы.

Если в краце , есть единица именуемая_блок, есть под_единицы именуемые страницами. А сам блок состоит из страниц.

Конечно же большенство из вас не программисты поэтому мы немного упростим ваше понимание структуры NANDа.

Итак чтоже вам нужно знать : 1. Размер флеши. 2. Размер блока. пока что этого достаточно.

Флеши используемые в модемах могут быть как 128MB так и 64MB.

Программный код исполняемый в NAND подобен живому оргнизму, где данные динамически перемещаются.


Есть также система контроля целостности, которая смещает данные при возникновении деффекта в блоке.


Работает она примерно так [блок 0] [блок 1] [блок 2] [блок 3] [блок 4] [блок 5] [блок 6].
Если все ок то РОМ процессора переносит нулевой блок Нанда в РАМ и там его запускает, затем последующие.

На первый взгляд все тривильно, но предположем что блок номер 5 у нас деффектный и не позволяет себя считать.

В таком случае файловая система запускает файл_проверки и восстанавливает целостность программного файла
посреддством переноса содержимого пятого блока в шестой ,шестого в седьмой итд..
[блок 0] [блок 1] [блок 2] [блок 3] [блок 4] [блок 5=6] [блок 6=7].. до конца файла даные которого повреждены.
После этого файл_проверки заносит данные о номере деффектного блока в соответствующую таблицу
в которой описаны номера блоков которые нужно пропускать при переносе по в РОМ.


Иногда случается так что перенос данных из деффектного блока в последующий не выполнился,
например это вызвано какой либо ошибкой которая нам неизвестна,
в результате модем "труп или полутруп висящий в режиме программирования" .

Восстановить модемы зависшие в режиме программирования можно двумя способами, житагом или дорогостоящим по стоимостью более 500 евро.
Модемы не подающие признаков жизни можно восстановить исключительно только житагом, описанием чего мы сейчас и займеся.


Сперва сделаем анализ отчитанного дама из деффектного модема,
затем откроем дамп программой X-PARSER или аналогичной программой которая покажет разметку файловой системы.

Для примера лог программы х-парсер.

MyDump.bin
Partition detected! - method 1

- Partition in dump detected, start parsing...
---------------------------------------------------------------
Flash size 64MB : $4000 -- здесь программа определит размер флеши
Bad_Block MAP vers : 00000001
Bad_Block counter : 00000001 -- тут покажет колличество бад блоков и ниже их адреса.

Bad_Block1 : 00000284 00A10000 in flash - собствено вот это и есть то что нам нужно, номер и место во флеше.

QCSBL_Size : 0000B2B6 45750_dec
OEMSBL_Size : 0003D51B 251163_dec
AMSS_Size : 00E1A5FF 14788095_dec
NANDPRG_Size : 0001A180 106880_dec

- Autoanalyse real size for QCSBL OEMSBL AMSS - ok.

0:MIBIB : Found!
Nand_Page : 00000000
Nand_Size : 0000000A
Fls_Address : 00000000
File_Size : 00028000

0:SIM_SECURE : Found!
Nand_Page : 0000000A
Nand_Size : 00000006
Fls_Address : 00028000
File_Size : 00018000

0:QCSBL : Found!
Nand_Page : 00000010
Nand_Size : 00000005
Fls_Address : 00040000
File_Size : 00014000

0:OEMSBL1 : Found!
Nand_Page : 00000015
Nand_Size : 00000012
Fls_Address : 00054000
File_Size : 00048000

0:OEMSBL2 : Found!
Nand_Page : 00000027
Nand_Size : 00000012
Fls_Address : 0009C000
File_Size : 00048000

0:AMSS : Found!
Nand_Page : 00000039
Nand_Size : 00000521
Fls_Address : 000E4000
File_Size : 01484000

0:FOTA : Found!
Nand_Page : 000005DE
Nand_Size : 00000047
Fls_Address : 01778000
File_Size : 0011C000

0:FTL : Found!
Nand_Page : 00000625
Nand_Size : 00000040
Fls_Address : 01894000
File_Size : 00100000

0:EFS2 : Found!
Nand_Page : 00000665
Nand_Size : FFFFFFFF
Fls_Address : 01994000
File_Size : FFFFC000


Для восстановления используем два основных параметра:
Размер флеши 64MB : $4000
И номер деффектного блока : 00000284, где его начало в дампе по адресу 00A10000.

Для флешей 64мб размер блока равен 16 килобайт, для флешей 128мв размер блока равет 131 килобайт.

Теперь беремся за расчеты. Для удобства будем использовать десятичную систему счисления.

Адрес начала блока Hex_00A10000 = 10.551.296 байт, то есть чуть более 10ти мегабайт.

В файловой структуре квалкома деффектные блоки заносятся в таблицу разметки целостности.
После этого деффектные блоки заполняются нулями.

Оптимальный вариант редактирования дампа HexWorkshop, он более простой, хотя это вопрос удобства и привычки.
Для восстановления понадобится полноценный дамп отчитанный с нормального модема без деффектных блоков с такойже версией по модема.


И так что мы имеем, размер флеши, размер блока для 64мб флеши = 16384 байт и адрес начала деффектного блока
Hex_00A10000 = 10.551.296 который подпадает под пространство файла AMSS
0:AMSS : Found!
Nand_Page : 00000039
Nand_Size : 00000521
Fls_Address : 000E4000 - это адрес начала файла во флеше.
File_Size : 01484000 - это размер файла.

Не забываем о том что парсер показывает "грязный" размер файла, это означает наличие квоты межфайлового пространства
котороое используется для развертывания и переноса данных в случае возникновения деффектных блоков.
Если использовать X-PARSER то он может показать точный размер файлов на примере AMSS_Size : 00E1A5FF 14788095_dec


Из проверенного дампа делаем вырезку файла в котором обнаружен деффектный блок.
в нашем случае вырезаем от адреса 000E4000 размер файла с отведенным ему пространством 01484000 .

Получаем дамп размером 01484000 что в десятичной системе 21.512.192 мегабайта.

Теперь от конца дампа отсчитываем назад 16384 байта и вырезаим их.
Если вырезанный кусок еще в памяти то не спешим его удалять, открываем вкладку создать новый файл
и вставляем в него 16384 байт, которые выделяем мышкой и заполняем нулями. Это будет наш деффектный блок.

После этого в нашем дампе из которого вырезали 16384 байта встаем на позицию Hex_00A10000 = 10.551.296
и вставляем наш деффектный блок заполненный нулями. сохраняем дамп и записываем его житагом с адреса 000E4000.

На этом все, в 90% случаев ваш модем готов .


выдержка из инженерного руководства Mkey - SmartFlasher
 dumper4k
Ukraine
сообщений: 19
#2 Дата 29 июля 2011 02:26
Второй пост страницы зарезервированн под программу X-PARSER, которую положу когда переделаю внутренний функционал в демку которой можно просматривать адресное описание системы.
 dumper4k
Ukraine
сообщений: 19
#3 Дата 06 авг. 2011 04:25
Видимо пост отредактировать не получается, ссылка на скачивание X-Parser

http://www.mkey-support.com/public/software/X-Parser_FreeEdition.zip

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

все остальное убрано поскльку предназначено исключительно для внутреннего использования.

в зипе пример куска флеши с одним бад блоком чтоб можно было потренироватся.


х-парсер писался для углубленного анализа флешей модемов на процессоре мсм6246-6290, проверенн на хуавеях, зте, алькатель, водафон, тошиба итд..

софт как есть с убранной бинорезкой и отключенной функцией пересчета ефс, это только для меня :) а остальное дарю как есть..
 
Отредактировано: dumper4k 06 авг. 2011 04:29
 B0BA
Хабаровск
сообщений: 68
#4 Дата 11 авг. 2011 15:17
цитата dumper4k:
и восстанавливает целостность программного файла

вот здесь не ясно.Откуда система берёт избыточные данные для восстановления?
цитата dumper4k:
В таком случае файловая система запускает файл_проверки и восстанавливает целостность программного файла
посреддством переноса содержимого пятого блока в шестой ,шестого в седьмой итд..
[блок 0] [блок 1] [блок 2] [блок 3] [блок 4] [блок 5=6] [блок 6=7].. до конца файла даные которого повреждены.
После этого файл_проверки заносит данные о номере деффектного блока в соответствующую таблицу
в которой описаны номера блоков которые нужно пропускать при переносе по в РОМ.


честно говоря файловую систему тупее этой трудно себе представить, это тоже самое, как например если в досовской файловой системе не существовало бы FAT как таковой и для удаление файла по среди диска (для упрощения фрагментацию опустим, пусть файлы могут представлять собой только цельный кусок данных) пришлось перемещать влево все следующие за ним куски -потресающе глупо ! представляете сколько бы длилось удаление файла в 1 кб на диске размером в несколько сот гигабайт ! кстати это очень яркий пример того что излишнее быстродействие современного железа позволяет программистам слишком много вольностей и делает из них дураков. гораздо логичнее было бы сделать массив при размере элемента WORD он бы занимал 128 кб памяти и мог бы адресовать до 1Гб при размере блока в 16кб, где индекс означал номер блока,а значение указывало бы на адрес, куда он перемещён (примерно такой принцип кстати заложен в системе FAT), или ещё проще (тк нет фрагментации и быстродействие здесь не критично ввиде таблицы, наподобие рамапа организованной ввиде массив из двойных слов, где младшая часть содержит номер деффектного блока,а старшая номер блока в который он перенесён. как то так

Отредактировано: B0BA 11 авг. 2011 15:22
 dumper4k
Ukraine
сообщений: 19
#5 Дата 13 авг. 2011 19:06
цитата B0BA:
цитата dumper4k:
и восстанавливает целостность программного файла

вот здесь не ясно.Откуда система берёт избыточные данные для восстановления?
цитата dumper4k:
В таком случае файловая система запускает файл_проверки и восстанавливает целостность программного файла
посреддством переноса содержимого пятого блока в шестой ,шестого в седьмой итд..
[блок 0] [блок 1] [блок 2] [блок 3] [блок 4] [блок 5=6] [блок 6=7].. до конца файла даные которого повреждены.
После этого файл_проверки заносит данные о номере деффектного блока в соответствующую таблицу
в которой описаны номера блоков которые нужно пропускать при переносе по в РОМ.


честно говоря файловую систему тупее этой трудно себе представить, . как то так




1. есть служебная область спара. то есть болк в реале четок больше. OEMSBL + QSCBL переносит файлы.

2. как по мне файловая система квалкома очень даже отлажена причем неплохо, это я говорю как разработчик.

в прочем без нанда это врядли бы могло быть.



 Energizer
администратор
глухая деревня
сообщений: 1190
#6 Дата 13 авг. 2011 21:18
цитата dumper4k:
то есть болк в реале четок больше.


Вы имеете в виду что он больше за счет каждой странички в нем??
то есть не 200h голых данных кода в нанд, а 210h ?? которые тоже видно в буфере
квалкома.. Вы не могли бы чут подробней об этом рассказать.. если это конечно не военная тайна ;-) и еще очень интересно кто занят настройкой работы RAM или опять ктото из этих OEMSBL --QSCBL // - вы их ковыряли?? мне очень интересно узнать об ини опер памяти плбольше ;-)

Отредактировано: Energizer 13 авг. 2011 22:25
 dumper4k
Ukraine
сообщений: 19
#7 Дата 15 авг. 2011 19:59
цитата Energizer:то есть болк в реале четок больше.

[/quote]

Да.


цитата Energizer:
еще очень интересно кто занят настройкой работы RAM или опять ктото из этих OEMSBL --QSCBL // - вы их ковыряли?? мне очень интересно узнать об ини опер памяти плбольше ;-)




Не совсем понимаю суть вопроса.

Есть АМСС - это сновное тело=программа, тот анлок что мы делаем - мы делаем через рам и вносим изменения в ефс в случае обычного по , или в амсс в случае кустомизированного по закрытого для анлока через коды.
 Energizer
администратор
глухая деревня
сообщений: 1190
#8 Дата 15 авг. 2011 22:07
попробую более правильно задать вопрос..
анлок мне не интересен пока вообще..
вот что мне очень интересно сейчас--
при входе в дебаг мы можем попадать в гости к контроллеру в разном его состоянии
в зависимости от момента на чем мы его тормознули.. соответственно и его восприятие команд может быть весьма разным.. и что больше всего меня интересует какой из загрузчиков занят инициализацией контроллера в целом
и RAM в частности ...
или ею вообще занимается код из внутренней Оси записанной в ROM ??
почему спрашиваю,да по тому что при написании программы для работы внутри квалкома столкнулся порой с неадекватными реакциями на команды засылаемыми в контрольные регистры управления нанд.. а иногда с не возможностью размещения исполняемого кода в RAM , что наводит на мысль о не завершенной иниц. (слишком рано вломился в дебаг оттормозив поспешно проц)
соответственно интересно можно ли исполнить простейшую предварительную настройку контроллера без угадывания момента входа в дебаг с помощью задержек ??
можно ли например простой записью значений в регистры по секретным адресам
исполнить начальную инц..контролера и RAM
(например по средствам скриптов -до начала отправки и исполнения кастом кода)
наверное как то так должен был звучать правильный вопрос ;-)
 dumper4k
Ukraine
сообщений: 19
#9 Дата 16 авг. 2011 04:27
ты ведь о житаге говориш ?

или о работе с нандом через лоадер ?
 Energizer
администратор
глухая деревня
сообщений: 1190
#10 Дата 16 авг. 2011 07:21
конечно о житаге.. и о работе самопальной програмки- в RAM для обмена данными с хостом по житагу
и разумеется эта программка хочет командовать нандом как у себя дома ;-)
Страницы:
Перейти на другой форум:
Сайт управляется SiNG cms © 2010-2015