Накопитель определяется только через ТП
Pачитаться не дает:


Может кому то удавалось подобное побороть?

Был в ремонте i9300 с такой же задачей. Необходимо было вычитать дынные из памяти KMVTU000LM-B503. Через TestPoint у меня тоже ничего не получилось вычитать. Возможно этот режим предназначен только для сервисных операций ? Т.к. клиент не хотел ждать восстановил память через TestPoint и выдал восстановленный аппарат. Но вопрос достаточно интересный аппараты с такой задачей частенько заходят.

Все верно, тест поинт только для восстановления firmware контроллера (режим восстановления будет rev 0x56). В z3x есть еще кнопочка VTU00M repair 000000. через нее vtu00m восстанавливаются (не всегда) без потери инфы, с другими флешками нужно проверять, но как минимум эта кнопочка уронит ее в режим, отличный от 0x56 и из-под него вполне возможно что получится что-то считать

со сбойным firmware eMMC наверно только так

После восстановления проши , через ТП, кто-то фулл пробывал вычитывать?
Заливаются ноли ?(

Много не вычитывал, но с самого начала идут одни нули.

Дабы не раводили тут люди догадки.

всегда с потерей инфы.

Итак немного теории: EMMC состоит из NAND Flash, и контроллера с прошивкой. Прошивка запускается и отвечает на комманды извне. Для работы прошивка использует небольшой кусок спецпамяти называемой "таблицей размещения секторов", в которой хранится соответствие "логического" адресного пространства "физическому". Это необходимо для равномерного "износа" ячеек Flash при операциях записи. Кроме прочего, прошивка контроллера имеет в себе еще и EEPROM, в котором собирает информацию типа S.M.A.R.T. Существуют также "ремапы" Bad Sector'ов.

Теперь о boot режиме (через ТП). в Boot микросхема падает сама, если не может запустить основное firmware или через ТП - принудительно. firmware boot имеет значение 0x56. В режеме Boot (0x56) нету доступа к NAND накопителю и таблице размещения секторов. Кроме boot есть случаи, когда у микросхемы NAME 000000 - бывает когда прописывается firmware, но не прописывается CID. тогда можно принудительно вписать CID.

Теперь о восстановлении firmware Flash - после восстановления firmware обязательно происходит Wipe - переинициализация таблицы размещения секторов со стиранием Flash

Если сделать спец прошивку, залить firmware без Wipe - мы просто получим сильно или не очень перемешанный мусор. Собирать данные не зная, где находится следующий сектор, т.е. без "таблицы размещения" нереально. т.е. такую прошивку сделать можно, практически же толка от нее нет.
То, что флешка упала в boot или не детектится как раз говорит о том, что firmware из-за своего несовершенства запороло эту таблицу и не может с ней разобраться. Поэтому раз таблица запорота, то тут 2 варианта - или давать флешке команду Wipe - на переинициализацию её или обмануть микросхему, получив доступ к внутреннему накопителю без этой таблицы. Во втором случае будет то, что я писал выше - каша, которую нереально собрать.

Layder,
все написано правильно, за исключением одного маленького но. кнопочка vtu00m repair работает по-другому принципу. Она выводит именно эту флеш из режима 00000 убирая какой-то баг в прошивке инфу при этом не трогает. у меня было несколько раз такое, а именно VTU00M с 000000 при нажатии на данную кнопочку флеш становилась частично рабочей с родным бут-конфигом, родной разметкой и насколько смог судить инфа была на месте. Клиентам был озвучен ценник за извлечение инфы получен отказ и после я благополучно затер эти флешки и восстановил телефоны.

будет еще подобная я сниму процесс восстановления именно этой кнопочкой обязательно

как будет на других еммц я не знаю решение именно для VTU00M

pc3000 flash справляется с этой задачей успешно в большинстве случаев, вот вычитать содержимое внутреннего нанда пока нечем.

Штук 5 со сбойным именем (00000) микросхем VTU00M после операции "reset 00000" - разметка на месте, а в userdata пусто. Это на практике. Вариант "ушития" предыдущими ребятами не исключен (до сброса имени в 00000)

она работае по тому же принципу - заливает firmware 0xf1 (или 0xf0, точно не помню) и восстанавливает CID.
возможно если до этого там была такая же прошивка, то сохраняется таблица рамещения файлов и не происходит ее (таблицы) переинициализации.

Все случаи Repair 00000 у меня были с потерей всех данных - я раз 5 пробовал. Потом просто стал делать firmware upgrade, потому что при нем прошивка поновее и безглючней.

возможно в случае с NAND, pc3000 получает доступ к этой таблице и с ее помощью "наводит порядок". потому как без этой таблице попросту создать порядок блоков можно сказать невозможно. это равносильно тому что вы возьмете файл допусти 16 мегабайт , поделите его на секторы в допустим 2кБ и перемещаете 10-20 процетов секторов местами. Да у вас будет файл в 16Мб, с перемешанными секторами. Скажите как pc3000 "догадается и восстановит" правильную последовательность секторов? Я допустим не могу это понять, проясните мне.

Чтобы было понятно, я приведу вам аналогию. Допустим у нас есть автоматизированый автомобильный многоэтажный гараж (ячейки памяти). Сделаем аналогию с домом. есть 5 этажей, по 4 парковочных места, 3 подъемника. первый подъемник обслууживает места 1-20, второй с 21 по 40, третий с 41 по 60, по аналогии с подъездами дома. Вы привозите машину на въезд в дом, отдаете швейцару (контроллеру (прошивке)) он вам сообщает, что что ваша машина на 5 месте, и вы ее постоянно ставите на 5 место, оно за вами забронировано. допустим в сутки в гараже стоит всего по 30 машин. Через некоторое время хозяин (швейцар, прошивка) понимает, что первый подъемник изнашивается, а 2 и 3-й простаивает. Что он делает. Он вашу машину начинает ставить на 45 место, а у себя помечает, что места 41-50 физическое соответствуют 1-10. Вам же все равно где ваша машина, а хозяину нужен равномерный износ оборудования. Вот когда хозяин помер, а его каракули никто разобрать не может найти машину сложно.

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

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

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

В любом случае пока не будет дампа внутренней nand emmc, ничего достоверно сказать нельзя, как там что устроено, Точно можно сказать только что выводы ее выведены наружу и китайцы знают pinout
Был бы дамп можно было бы натравить на него pc3000 и посмотреть что выйдет

serviceman, PC3000 хорош только в том случае, если есть таблица размещения секторов. Если ее нет - то ничего он не сделает, увы но это факт. Насчет узнать распин накопителя- рентген в помощь, но в моем случае клиент не готов расстаться с внушительной суммой, поэтому пока вопрос снимается ( до появления новых наработок с меньшими затратами ресурсов).