Re: Был ли у кого опыт удачной замены флеш-памяти на Asus A500KL
#26
Если затык в некорректной GPT, то его не сильно сложно устранить.
Warning! Disk size is smaller than the main header indicates! Loading
Ругается, что физический размерносителя меньше, чем это прописано в главной GPT зпписи в начале носителя (Речь явно о заголовке основной GPT, поск. строкой ниже речь идет о заголовке Backup GPT).
Caution: invalid backup GPT header, but valid main header!
Если фулл заливался не полностью (в прямом смысле "фуллом" не был) - только начало носителя, то так и будет, ведь резервная копия GPT хранится в самом конце и она окажется от старого аппарата, с которого сдували eMMC. Кроме того, еслим новый носитель меньше старого на 4МБ, то Backup GPT не поместится, даже если пытаться залить весь фулл - 16ГБ, ведь она хранится в последних секторах носителя (и поиск ее, в случае краха, идет от конца носителя - по логике стандарта, что, однако, не означает, что везде этот стандарт реализован в полном объеме и PBL вообще станет искать Backup GPT). В любом случае, на нужном месте в конце носителя корректной Backup GPT не окажется.
Warning! Main and backup partition tables differ!n
Собственно, констатация написанного чуть выше.
Warning! One or more CRCs don't match. You should repair the disk!
Не вполне ясно где и почему слетели контрольные суммы.
Однако, совет более чем разумный. Если они слетели, GPT не валидна и работать с ней софт, скорее всего не будет (точнее это зависит от заложенной в него реакции на такую ситуацию). Софтом, работающим с GPT, в данном случае, в момент старта является PBL аппарата. Так что его "нервная реакция" в виде выпадения в 9008, вполне себе, вероятна в случае инвалидности GPT. К сожалению из лога не ясно где и какие CRC слетели. Любой софт, позволяющий редактировать GPT как структуру, понятно, их пересчитает после редактирования.
Partition table scan:
GPT: damaged
Опять ругается на поврежденную GPT
Caution: Found protective or hybrid MBR and corrupt GPT.
Тут все в порядке, первый (вернее нулевой) сектор занимает заглушка MBR, в которой прописано в Partition table, что весь объем диска занят одним "нестандартным" разделом, с единственной целью - дабы устаревший софт не посчитал диск пустым и не пытался его разбить на разделы под MBR. Актуально это, скорее, для жестких дисков, которые "суют" под разные "чужие", устаревшие ОС, но стандарт есть стандарт. Занятно, что при "подсовывании" Qualcomm-based под Windows XP (а может и 7), в режиме 9006 ("eMMC наружу") Винда, внезапно, считает носитель "не инициализированным" и предлагает "инициализировать" (соотв., с порчей данных), что является абсурдом, поск. увидев "заглушку" должна "отвалить" и не трогать единственный "чужеродный" раздел (неизвестной ОС), прописанный в MBR.
Real (Hardware) Disk/Image size: 1D5A000 sectors 14.7 GiB
Soft (Partitioned) Disk/Image size: 1D5BFBC sectors 14.7 GiB
Тут, собственно, выявляется расхождение в размерах между разбивкой, прописанной в GPT и реальным размером носителя, который чуть меньше. Ситуацию эту должен автоматиески и с легкостью обработать заводской загрузчик прошивок (скрипт или структура, описанная в xml), поск размер последнего раздела UserData он высчитывает как разницу между размером флеши и адресом конца предпоследнего раздела System, после чего сам этот раздел и создает (или патчит) под нужный размер. Однако, заводской комплект, к сожалению, до сих пор никто не выложил, соотв бесплодное топтание на месте, вопреки интересам всех, кроме производителя (включая ОСЦ, неспособных восстанавливать данные модема, поск "им недоверяют" даже "секреты Полишинеля", что весьма показательно), нагло и противоправно, вопроеки открытым лицензиям, антимонопольному законодательству, законам о правах потребителей и здравому смыслу, выворачивающего руки всему сообществу продолжится. То, как выполняется разбивка скриптом или по описанию в xml, Вы можете поглядеть в прошивках для аналогичных аппаратов, однако загрузчиков MPRG (входящих в заводскую/сервисную прошивку, и, наверное, подписанных/заточенных под этот Asus) для данного устройства нет (поэтому, например, вопользоваться переделанными скриптами от др устройства не удастся, хотя, кто знеает, может какие-то для данного SoC от аналогичного аппарата и подойдут).
Для исправления указанных проблем (не могу достоверно знать приведет ли это к решению проблемы со стартом), достаточно подключить образ всего диска (файл фулла) в качестве виртуального "жесткого диска" (к любой системе - Windows/Linux, иной вариант - загнать сам аппарат в 9006, если получится, с помощью загрузчиков, и он отдаст носитель наружу по USB, после чего на нем можно, точно также редактировать любые сектора и структуры) и отредактировать GPT любым редактором разделов с поддержкой GPT, желательно не слишком "самовольным" и, тем более, предпочитающим "думать за пользователя", ибо такой может "не понять" всей "тонкой сути" пропрайетарных реазделов, присущих подобным устройствам на базе Android и тупо их "как нибудь" удалить, переместить или еще как "оптимизировать". В идеале нужен редактор, который лишь правит записи GPT без попыток что либо форматировать, переразмещать итп. Например, DMDE поможет отредактировать любые поля GPT в весьма наглядной, подробной форме. Необходимо, чтобы редактор поддерживал и резервную копию GPT в конце носителя (вообще, все должны, это положено по стандарту GPT), имеющую неск иной бинарный формат (записи идут в обратном порядке). Исправить необходимо размер последнего раздела UserData. Стоит проверить также любые иные поля на корректность и соответствие параметрам носителя. Иной вариант - отредактировать непосредственно бинарные структуры GPT (т.е. в "Hex", после чего, тем не менее, необходимо будет как-то пересчитать CRC описаний разделов и GPT таблиц в целом). Если PBL так нервно реагирует на не совпадение GPT и физических параметров носителя, что отказывается монтировать носитель (его разделы) и вываливается в 9008 (куда ж еще, если носителя "нет"?), трудно сказать какие именно параметры его "травмируют", а какие нет. Диагностика то отсутствует. Достоверно узнать можно лишь анализом листинга дизассемблера (либо получив доступ к исходникам), отладкой, либо экспериментальным путем. Однако, если проблема в GPT, то, наверное, следует ожидать, что PBL ее сожрет если она будет соответствовать стандарту. Собственно, в этом направлении и стоит попробовать действовать.
Ну и последний момент. Если все заработает, после переразбивки на другой размер нельзя будет бездумно заливать образы разделов или иные фуллы с целью перепрошивки. Следует помнить, что GPT была неск изменена, размер UserData чуть отличается. При этом прошивка другой сборки в пофайловом режиме никаких проблем вызывать не должна. Собственно таким образом проходят и обновления производителя, и бакап-восстановление с помощью стоковых и кастомных рикавери (они льют крупные ExtFS разделы - System/Data/Cache пофайлово, мелкие пропрайетарные целиком, если это требуется).
Стоит упомянуть также, что, теоретичеки, проблемы может создавать некая "мудреная" "залочка бутлоудера", хранящая "флажки" в других "аппаратных" разделах eMMC, либо реализованная с помощью кастомного фирмвера eMMC, как это делали в старых "копро-HTC". Впрочем, Asus, вроде бы, не был замечен в подобных "извращениях".
Что касается данных модема, то восстановить их можно двумя путями:
1. Слить шифрованные разделы целиком со старого носителя (если он хоть как-то "дышит") и попробовать залить их на новый (образами).
2. Добраться до Diag протокола QMI (активировать Diag порт модема) и заливать QCN бакап данных NVRAM/EFS, слитый с такого же аппарата (после правки IMEI и иных ID на оригинальные), как это, наверняа, делает производитель, с помощью оригинального ОЕМного софта, либо универсальных инструментов Qualcomm - типа QPST (как эт делается для большинства других устройств на Qualcomm). Думается, никакой "Америки" я тут не открыл, как, собственно, и в части теории по работе с GPT.