Как активировать тачпад в Recovery на MTK или патчим ядро Android.

Как вы заметили я редко пишу узкоспециализированные технические посты, в основном контент расчитан на более широкую аудиторию, но сегодня я не удержался. Предыстория очень простая. Во время сборки кастомного Recovery для одного из аппаратов на чипе от Mediatek я столкнулся с проблемой - тачпад в Recovery не работал, а любые упоминания о mtk-tpd напрочь отсутствовали в /sys/class/input. Надо сказать что mtk-tpd это как раз и есть тот самый MTK Android Linux Touch Panel Device Driver, который отвечает за работу тачпада. Напомню, что в нормальной ситуации, когда тачпад в recovery работает, сделав что-то вроде grep . /sys/class/input/input*/name в консоли мы должны увидеть примерно следующее:

/sys/class/input/input0/name:ACCDET
/sys/class/input/input1/name:mtk-kpd
/sys/class/input/input2/name:hwmdata
/sys/class/input/input3/name:m_alsps_input
/sys/class/input/input4/name:m_acc_input
/sys/class/input/input5/name:m_gyro_input
/sys/class/input/input6/name:mtk-tpd
/sys/class/input/input7/name:mtk-tpd-kpd

Однако в моей ситуации mtk-tpd отсутствовал. Зная что на одном из форумов есть человек, который уже занимался патчами ядра ARM64 для Mediatek, я обратился к нему с вопросом, а каким образом (честно говоря я рассчитывал на ответ в двух словах, такая-то функция, такая-то проверка) он заставил работать тачпад в recovery и что конкретно он патчил в ядре. Правда здесь я почему-то наткнулся на стену глухого непонимания и какой-то секретности. Ну "секрет" так секрет, настаивать, чтобы кто-то что-то рассказал, если человек сам не хочет бессмысленно. Поэтому я решил провести некий анализ, который занял от минут 30-40 ... теперь голые факты. В MTK существует несколько режимов загрузки, который описаны в заголовочных файлах ядра (mt_boot_common.h), вот они:

/* boot type definitions */
enum boot_mode_t {
 NORMAL_BOOT = 0,
 META_BOOT = 1,
 RECOVERY_BOOT = 2,
 SW_REBOOT = 3,
 FACTORY_BOOT = 4,
 ADVMETA_BOOT = 5,
 ATE_FACTORY_BOOT = 6,
 ALARM_BOOT = 7,
#if defined(CONFIG_MTK_KERNEL_POWER_OFF_CHARGING)
 KERNEL_POWER_OFF_CHARGING_BOOT = 8,
 LOW_POWER_OFF_CHARGING_BOOT = 9,
#endif
 DONGLE_BOOT = 10,
 UNKNOWN_BOOT
};

В драйвере дисплея в процедуре инициализации тача есть проверка:

static s32 tpd_i2c_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
 int err = 0;
 int count = 0;

 GTP_INFO("tpd_i2c_probe start.");
 if (RECOVERY_BOOT == get_boot_mode())
  return 0;
 probe_thread = kthread_run(tpd_registration, client, "tpd_probe");
 if (IS_ERR(probe_thread)) {
  err = PTR_ERR(probe_thread);
  GTP_INFO(TPD_DEVICE " failed to create probe thread: %d\n", err);
  return err;
 }

 do {
  msleep(20);
  count++;
  if (check_flag)
   break;
 } while (count < 50);
 GTP_INFO("tpd_i2c_probe done.count = %d, flag = %d", count, check_flag);
 return 0;
}

Как видно при вызове tpd_i2c_probe проверяется, если boot mode у нас равен RECOVERY_BOOT, то драйвер у нас не инициализируется ;) Т.е. со стороны MTK так и задумано что в recovery тач пользователю не нужен. Но ведь TWRP фактически использует только тач, скажете вы и будете правы. Но девайсы на платформе MTK никогда ведь не идут с TWRP в комплекте, а стоковому recovery тач естественно не нужен. Поэтому сейчас я вам расскажу как найти соответствующую проверку в бинарнике ядра, ну а непосредственно патч будет "домашним заданием" ) Должна же остаться какая-то "изюминка" ... Так вот. Для начала узнаем адрес tpd_i2c_probe, для этого от имени root выполняем:

sh -c "echo 0 > /proc/sys/kernel/kptr_restrict"
cat /proc/kallsyms | grep tpd_i2c_probe

В результате получаем нужный нам адрес 0xffffffc000760494. Далее загружаем в любом дизассемблер распакованное ядро (архитектура моего CPU - ARM64, поэтому offset нужной нам функции как видите 64-битный) с адреса 0xFFFFFFC000080000 (для 32-bit ядер - 0xC0008000) и переходим по найденному адресу:

На скриншоте выше наглядно видно и исходники и дизассемблированный код. На поиск нужной функции, как вы можете убедиться, и места проверки в ядре у нас ушло не более 5 минут. Теперь нам достаточно убрать условный переход по адресу 0xFFFFFFC0007604D0, заменив его NOP'ами или любой другой "пустой операцией" и собрать boot с модифицированным ядром назад. После чего при загрузке в recovery тачпад будет успешно инициализироваться.

Успехов вам!

p.s. Да, забыл сказать ... в данном примере мы разбирали инициализацию MediaTek gt91xx touch panel driver. Естественно, что в вашем устройстве может быть другой драйвер тача.

Билайн Про. Переразметка памяти.

Не так давно я писал о новом LTE смартфоне от Билайн - Билайн Про (он же ZTE Blade Q lux 4G, и он же, судя по всему скоро будет продаваться у МТС под пока неизвестным названием). В прошлой статье мы рассмотрели как установить CWM и получить root-права на Билайн Про, и по сути это было довольно просто. Сегодняшняя же наша статья рассчитана на продвинутых пользователей, которым не чужд SP Flash Tool и которые владеют навыками восстановления телефонов на платформе MediaTek (хотя все будет не так страшно, но если вы не уверены в своих силах - не делайте ничего из описанного здесь).

Основная проблема Билайн Про (ZTE Blade Q lux 4G) - недостаток внутренней памяти, а именно памяти для установки приложений. В телефоне установлена eMMC флеш на 8 Gb, которая разбита крайне бездарно. Память телефона делится на внутреннюю (память для установки приложений) - всего ~1.27 Gb и память телефона (фактически виртуальная SD-карта) - 4.44 Gb. Естественно что 1.27 Gb - это крайне мало, и установив пару-тройку приложений (Viber, ВКонтакте, еще что-нибудь) постоянно приходится сталкиваться с проблемой нехватки места. Даже, когда мы пытаемся скачать приложение из Google Play, зачастую мы получаем сообщение в стиле "упс, недостаточно памяти для распаковки приложения", недостаточно памяти для того, для сего ... что и обидно, т.к. мы знаем, что в нашем бюджетнике памяти-то целых 8 Gb. Для примера я решил задаться целью и увеличить внутреннюю память (т.е. память на которую устанавливаются приложения) в два раза.

Итак, что мы знаем про Билайн Про? Телефон этот на новой платформе - MT6572/MT6732M, поэтому про всякие там MTK Droid Tools и т.п. можно забыть. Они не умеют работать с разделами нашего телефона. Здесь нам поможет светлая голова, прямые руки и ADB. Первое что мы делаем это узнаем структуру разделов через cat /proc/partinfo :

Как мы видим, разметка диска в телефоне GPT, т.е. GUID Partition Table. Не лишним будет ознакомиться с ее описанием, хотя бы на Википедии. Как мы видим, в телефоне primary guid partition table - это раздел pgpt, а secondary guid partition table - это раздел sgpt. Я захотел увеличить память в два раза. Внутренняя память - это у нас раздел userdata, intsd - соответственно это виртуальная SD-карта. 

Кстати, заметил что на форуме 4PDA появился некий пользователь KOTwasya, который судя по всему обладает доступом к исходникам прошивок под данный аппарат (и судя по всему к официальным), так вот он собирал официальную прошивку с флагом TESTE_PARTITION_RESIZE и добивался вообщем-то того же эффекта. Но, как я уже говорил - для того чтобы осуществить переразметку памяти на телефоне вовсе не обязательно собирать что-то исходников. Все что нужно - это сам телефон, а он у нас уже есть. Ну да не буду отвлекаться. 

Если мы хотим увеличить userdata в 2 раза, то у нас должно получиться примерно следующее:

Разметка памяти "ДО", т.е. оригинальная разметка.

И разметка пвмяти "ПОСЛЕ", т.е. то, что мы хотим получить.

Внимательно читаем про GUID Partition Table, и в частности про GUID partition entry format, т.к. мы будем изменять именно записи о разделах (!):

Тут мы довольно быстро понимаем, что запись о каждом разделе в PGPT представляет собой 128 байт и сам раздел задается с помощью First LBA и Last LBA, а вовсе не Offset и Size. Ну да ничего. Выкачиваем PGPT из телефона с помощью Readback в SP-Flash Tool и смотрим на него:

Красным обведены как раз FirstLBA и LastLBA. Как же сконвертировать LBA в Offset'ы и Size'ы? Да все очень просто. Смотрим к примеру на раздел userdata:

FirstLBA = 0x0000000000308000, Last LBA = 0x0000000000557FFF. 

Теперь смотрим на Start Offset, End Offset и Size в таблице выше для этого же раздела:

0x0000000061000000 - 0x00000000AAFFFE00 - 0x000000004A000000 (размер раздела)

Ну как, уже понятно? Нет? Ну тогда смотрите:

0x308000 * 0x200 = 0x61000000 , а 0x557FFF * 0x200 = 0xAAFFFE00 ... а 0xAAFFFE00 + 0x200 = 0xAB000000.

Все. Теперь нам понятно как рассчитать начала и концы разделов в LBA. Теперь удвоим размер раздела userdata и получим новый PGPT:

Здесь я обвел только то, что мы изменили. Пришло время залить новый PGPT в телефон. Изменяем scatter файл (он есть у нас из предыдущей статьи про установку CWM), так, чтобы раздел PGPT можно было залить в телефон. И, честно говоря, нас ждем "облом". Потому что в телефоне есть еще SGPT и он при загрузке не понимает такого издевательства над собой. Поэтому я выполнил последовательно две операции, залил новый, модифицированный PGPT с увеличенной памятью в телефон и отформатировал область память, в которой лежит SGPT (копия GPT):

После чего добился того чтобы телефон запускался (несколько раз у меня что-то переглючило при прошивке PGPT, поэтому я пробовал прошивать еще пустой userdata.img и пустой cache.img, вместе с PGPT и еще пару раз делал Readback PGPT чтобы убедиться что правильный раздел был записан в телефон). Наконец у меня все запустилось, я зашел в Philz Touch Recovery и еще раз для верности форматнул Cache и Userdata (можно сделать просто Wipe Data / Factory Reset). Запустил телефон (а вернее восстановил Backup который я делал перед началом экспериментов) и ... смотрите и радуйтесь:

Внутренней памяти стало 2.24 Gb, память телефона (виртуальная SD) - 3.44 Gb. Т.е. как мы и планировали, мы увеличили раздел userdata за счет intsd. Если 2.24 - недостаточно, тогда можно разбить userdata / intsd в другой пропорции, например 4.24 Gb / 1,44 Gb. Тут каждый как говорится, может творить что хочет.

Файлы которые я использовал: beeline_pro_repartition.7z , в архиве - оригинальный scatter, модифицированный scatter, а также оригинальный pgpt (pgpt_original.bin) и pgpt (pgpt.bin) c 2 Gb внутренней памяти.

Для тех кто хочет поэкспериментировать - берем SP_Flash_Tool_exe_Windows_v5.1452.00.000, модифицированный scatter, модифицированный PGPT и заливаем все это в телефон. При этом не забываем отформатировать sgpt со следующими параметрами:

linear_start_addr: 0x1d1f80000
partition_size: 0x80000

После чего сделать wipe'ы в recovery и/или формат разделов data и cache. Вот вообщем-то и все. Как мы убедились - переразметить память собственного телефона так как нашей душе угодно не так уж и сложно.

Готовая прошивка с 2Gb памяти телефона для Билайн Про

Т.к. материал сложен для понимания, решил также выложить готовый "боекомплект". Внутри архива стоковая прошивка от Билайн Про с интегрированным Root и 2Gb памяти телефона (userdata). Также в прошивке уже присутствует универсальный Philz Touch Recovery, который "видит" и внешнюю SD и внутреннюю память.

Шить через SP Flash Tool не ниже 5.1452.00.000, при прошивке выбрать Firmware Upgrade и Scatter - !Mod_MT6752_Android_scatter.txt, т.е. все так, как показано на картинке:

Скачать прошивку Билайн Про 2Gb

(пароль на архив - decker.su)

Набор Scatter'ов и PGPT для предыдущей прошивки

Как я и говорил, для тех кому мало 2Gb, вполне могут сделать себе 4Gb. Пример:

В архиве beeline_pro_1gb_2gb_4gb_userdata_decker_su.7z есть все необходимое. На всякий случай поясню. Скачиваете предыдущий архив с прошивкой, распаковываете в папку, например D:\firmware ... Скачиваете этот архив и распаковываете его в ту же папку. Т.е. в D:\firmware помимо файлов из архива с основной прошивкой у вас должны быть:

• pgpt_original.bin
• pgpt_2gb.bin
• pgpt_4gb.bin
• !Mod_MT6752_Android_scatter_1Gb.txt
• !Mod_MT6752_Android_scatter_2Gb.txt
• !Mod_MT6752_Android_scatter_4Gb.txt

Далее, если мы хотим прошиться на 1Gb - выбираем scatter - ...1Gb.txt, 2Gb - ...2Gb.txt и, наконец, 4Gb - ..4Gb.txt.

p.s. Так как прошивка сделана для заливки с помощью Firmware Upgrade - ее вполне можно использовать для восстановления кирпичей. Что, естественно, дополнительный плюс.

p.p.s. По просьбам пользователей zzzepr отснял небольшую видеоинструкцию по этому посту, которую я и размещаю здесь:

Внимание! Материалы приведенные в данной статье размещены в ознакомительных целях. Все действия описанные в данной статье вы осуществляете на свой страх и риск! Автор(ы) статьи не несут ответственности за вышедшее из строя оборудование, в результате ошибочных действий или неверного понимания вами смысла изложенного в ней материала, а также в силу любых прямых и косвенных причин, которые потенциально могут привести к неработоспособности вашего устройства или любым другим проблемам с ним. Если вы не уверены в своих силах, сомневаетесь и т.п. - не выполняйте ничего из вышеописанного. Используя материалы из этой статьи вы соглашаетесь с тем, что ответственность за ваши действия несете вы и только вы.

Как сделать Backup прошивки с помощью SP Flash Tool (MediaTek)?

В этом посте я расскажу о том как снять backup прошивки с практически любого аппарата на базе MediaTek с помощью SP Flash Tool и MTK Droid Tools. Также, отдельно, я рассмотрю случаей, когда MTK Droid Tools по каким-либо причинам не видит аппарат, но есть доступ по ADB. Итак, приступим. Для начала скачаем все необходимое:

• Драйвера ADB (поддерживаются x86 и x64) системы - AdbDriverInstaller.7z, также рекомендуется ознакомиться со статьей - Как установить драйвера ADB на Android?
• Platform Tools для Windows - т.е. adb.exe и все остальное, если у вас еще нет этих утилит (взято из статьи Как бороться с ADB "device offline" на Android 4.4?)
• SP Flash Tool для Windows (рекомендуется взять две версии -  SP Flash Tool v 5.1504.00 и SP Flash Tool v 3.1352.01 (5.1352.00), если с одной не получится, обязательно получится с другой).
• Драйвера MediaTek - mtk_xp_vista_7_8_x32_x64.zip
• MTK Droid Tools 2.5.3

После того как мы скачали все необходимое, можно, например, создать в корне какого-нибудь папку Android и разложить распакованное содержимое архивов по папкам, т.е. драйвера в папку Drivers, Platform Tools в отдельную папку, SP Flash Tool в отдельную, MTK Droid Tools тоже в отдельную.

Далее включаем на своем устройстве Режим разработчика и активируем отладку по USB. Т.е. сначала заходим в Настройки -> О телефоне (Об устройстве) и кликаем несколько раз (5-7) по надписи "Номер сборки", до появления сообщения о том что Режим разработчика активирован. Далее переходим в меню Настройки -> Для разработчиков и ставим галочку на "Отладка по USB":

После этого подключаем устройство к ПК и устанавливаем драйвера ADB (т.е. либо запустив AdbDriverInstaller.exe из архива, либо открыв диспетчер устройств и указав вручную путь к драйверам в папке Android ADB driver x64 для неизвестного устройства). В результате должно получиться так (Диспетчер устройств):

Устройство Android ADB Interface в диспетчере устройств подтверждает что у нас все готово к следующему шагу.

Запускаем MTK Droid Tools:

Ждем пока устройство определится в нем и нажимаем кнопку "Карта блоков":

После чего нажимаем кнопку "Создать scatter файл" и сохраняем получившийся файл (у меня он назывался MT6582_Android_scatter.txt) на диск. На этом этап подготовки закончен и можно приступать непосредственно к чтению данных.

Открываем получившийся файл в Notepad++ или Word (обратите внимание, обычный блокнот не подойдет) и находим в нем строчку partition_name: CACHE:

И запоминаем то, что у вас написано в графе linear_start_addr, в данном случае это - 0x3E900000.

Отключаем телефон от ПК и выключаем его, т.е. держим кнопку выключения питания и выбираем в меню "Отключение питания", также можно отсоединить и вставить батарею. Далее запускаем SP Flash Tool и переходим в нем на закладку Readback. Далее нажимаем кнопку Add. В результате в таблице появится одна строка:

Кликаем по ней, у нас появляется запрос выбора места сохранения файла ROM_0, выбираем папку, в которую мы его хотим сохранить и на следующем экране в поле Length вводим запомненное нами ранее число (linear_start_addr):

В итоге должно получиться что-то вроде этого:

После чего подключаем выключенный телефон (!) к ПК. В этот момент желательно открыть диспетчер устройств. Пока никакие кнопки в SP Flash Tool на этом экране не нажимаем!

В момент подключения у вас определится неизвестное устройство MT65xx PreLoader и ОС предложит вам установить драйвера на него. На картинке ниже это наглядно показано. Лучше сразу перед подключением телефона открыть диспетчер устройств, чтобы "отловить" момент появления MT65xx PreLoader. Если устройство появится, а ОС не предложит автоматически установить драйвера, то это надо сделать вручную, кликнув правой кнопкой мыши на устройстве MT65xx PreLoader. 

Выбираем "Выполнить поиск драйверов на этом компьютере" и указываем папку в которой находится распакованное содержимое архива mtk_xp_vista_7_8_x32_x64.zip (т.е. к этому моменту вы должны распаковать архив куда-нибудь). После того как драйвера успешно установятся, картинка в диспетчере устройств должна поменяться на такую: 

Если драйвера установились - можно переходить к следующему шагу. Обратите внимание, что при подключении телефона Preloader USB VCOM Port может появляться всего на несколько секунд - это нормально, наша задача на этом этапе установить драйвера телефона, чтобы он определялся именно как Preloader USB VCOM Port, а не неизвестное устройство MT65xx PreLoader. Если вы вдруг не успели установить драйвера, а телефон включился - вытаскиваем батарею, отсоединяем телефон, вставляем батарею, подключаем телефон и повторяем процедуру.

Как только мы убедились что драйвера у нас установлены - отсоединяем телефон от ПК. Выключаем его, в открытом у нас SP Flash Tool нажимаем кнопку Readback и подключаем выключенный телефон к ПК. После этого у нас пойдет процесс считывания прошивки из телефона:

Многие пишут о затруднениях возникающих именно на этом шаге. Попробую объяснить чуть подробнее. После того как вы нажимаете кнопку Readback - SP Flash Tool переходит в режим ожидания подключения телефона, т.е. подразумевается что до этого вы успели отловить момент когда выключенный телефон у вас определяется как MT65xx PreLoader и установить на него драйвера, чтобы в COM-портах у вас появился Preloader USB VCOM Port. Если вдруг по каким-то причинам SP Flash Tool написал об ошибке, или телефон не успел подключиться - может помочь следующая методика (все описанное справедливо только если вы корректно установили драйвера и при подключении телефона у вас появляется именно Preloader USB VCOM Port): отключаем телефон от ПК, вынимаем батарею, нажимаем кнопку Readback, подключаем телефон с вытащенной батареей. В SP Flash Tool пойдет красная полоска (Download), за это время быстро вставляем батарею назад, если мы успели, то пойдет синяя полоска Readback с процентами, как на картинке:

Ждем пока процесс завершится. Создание backup'а может занимать 10-15 минут. Просто смотрим на бегущие проценты и ничего не трогаем ;) По окончании процедуры чтения у вас появится надпись Readback Ok:

Пока у нас делается Backup самое время пояснить что же такое scatter файл и что представляет собой файл ROM_0, который мы получим на выходе. Память телефона - это обычная EMMC Flash, которая разбита на определенные разделы. Scatter файл это и есть файл описания разделов (так, например в Scatter'е есть разделы PRELOADER, RECOVERY, LOGO, ANDROID и т.п.). Назначение разделов различно, так, например в Recovery - содержится образ recovery, в logo - логотип, использующийся при загрузке системы, в Android - образ system и т.п. Файл ROM_0, который мы получаем на выходе по сути представляет собой сплошной дамп EMMC Flash в одном файле. Но чтобы воспользоваться полученным backup'ом прошивки, например, для восстановления другого аналогичного аппарата - нам еще будет необходимо разбить его на разделы. Здесь я опишу несколько способов как это сделать. Первый и самый распространенный - через MTK Droid Tools. Допустим у нас уже есть файл ROM_0 сделанный с помощью SP Flash Tool.

Включаем питание устройства (телефона) и даем ему загрузиться, после чего вновь запускаем MTK Droid Tools (режим отладки по USB на телефоне при этом, естественно, должен быть включен, а драйвера ADB установлены на ПК), переходим на закладку root, backup, recovery и нажимаем кнопку "Создать бэкап из ROM_ флэштула":

Выбираем получившийся у нас на предыдущем шаге ROM_0 и в окне лога видим примерно следующее:

--- Папка сохранения на компьютере: E:\Android\MtkDroidTools\backups\KINGSING_S1_141117_ForFlashtoolFromReadBack_150512-005322\

 --- scatter сохранен в файле:  

E:\Work\Мегафон Login Plus\MtkDroidTools\backups\KINGSING_S1_141117_ForFlashtoolFromReadBack_150512-005322\MT6582_Android_scatter.txtкопирование завершено 

    -- preloader.bin ...скопировано  ... cut OK

    -- MBR ...скопировано 

    -- EBR1 ...скопировано 

    -- pro_info ...скопировано 

    -- nvram.bin ...скопировано 

    -- protect_f ...скопировано 

    -- protect_s ...скопировано 

    -- seccfg ...скопировано 

    -- uboot.bin ...скопировано 

    -- boot.img ...скопировано 

...

Ну и т.д. Теперь в папке сохранения, у меня это E:\Android\MtkDroidTools\backups\ у нас появляется папка с полным backup'ом нашей прошивки, разбитым на разделы (т.е. каждый раздел в отдельном файле):

На этом процесс создания Backup'а прошивки завершен. Если вы только хотели узнать как сделать backup прошивки с помощью SP Flash Tool и у вас все получилось, дальше можно не читать.

Для продвинутых

А что делать если MTK Droid Tools "не видит" телефон? Или же не получается создать scatter файл или разбить получившийся файл ROM_0 на разделы? Как получить карту разделов и есть ли возможность "разрезать" файл ROM_0 вручную? Такая возможность есть. Чтобы получить карту разделов на MTK 65xx нужно в консоли ADB дать команду cat /proc/dumchar_info - т.е. запустить в консоли adb shell и уже там набрать эту команду:

Если вдруг телефон по каким-то причинам не видится и через ADB (в этом случае я советую ознакомиться с мануалом по ADB, может быть проблема в VEN_ID устройства и его нужно просто прописать в %USERPROFILE%\.android\adb_usb.ini), то ту же самую команду можно дать и в самом телефоне, установив Terminal Emulator for Android из Google Play:

Как видите - результат точно такой же и linear_start_address раздела cache можно взять и отсюда. Да, к слову, в новых устройствах, например на базе MTK 6752, таких как Билайн Про, ZTE Q Lux и т.п. карту разделов можно получить с помощью cat /proc/partinfo. MTK Droid Tools с этими устройствами вообще не работает.

Методика получения адреса старта раздела cache, который нужен для получения ROM_0 с помощью SP Flash Tool у нас теперь есть. Также мы знаем адреса (смещения) и размеры каждого из разделов. Т.е. чтобы "порезать" ROM_0 на разделы - использовать MTK Droid Tools нам вовсе не обязательно. Это можно сделать "руками" в любом Hex-редакторе, поддерживающим функцию выделения и сохранения блока в файл (я пользуюсь консольным HIEW). Ну и в качестве примера давайте "вырежем" раздел с Recovery из получившегося ROM_0 файла.

Мы знаем (из scatter'а или из dumchar_info) его linear_start_addr: 0x4180000 и partition_size: 0x1000000. Открываем ROM_0 в HIEW и переходим на 0x4180000. Т.е. в консоли делаем hiew32 ROM_0, затем нажимаем F5 и вбиваем адрес начала раздела - 4180000:

Как вижно по 4180000 у нас находится сигнатура ANDROID!, что говорит нам о том, что мы на верном пути ;) Адрес конца раздела вычисляется как linear_start_addr+partition_size-1 = 0x517FFFF в нашем случае. Нажимаем в HIEW * (звездочку на доп. клавиатуре) для начала выделения блока (если подвигать стрелками вверх / вниз / вправо / влево, то мы видим как блок начинает выделяться цветом) и либо спускаемся до 0x517FFFF, либо делаем это через F5:

И заканчиваем выделение блока, опять же через "серую" * (на доп. клавиатуре). После этого нажимаем F2 - Put block (сохранение блока в файл):

И раздел recovery у нас записан. Точно также можно вырезать из ROM_0 любой другой раздел. Как вы понимаете MTK Droid Tool при этом нам вообще не нужен. 

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

p.s. На этом пока все ... пост получился как "черновой вариант", т.к. писался на скорую руку, возможно позже я его дополню, если будут какие-то непонятные моменты. И конечно же, как всегда, буду раз вашим комментариям и вопросам ...

p.p.s. Как меня успели немного поправить, в /proc/dumchar_info содержатся не linear_start_addr из scatter'а, а physical_start_addr. Т.е. в приведенном примере для раздела с recovery мы имеем:

  linear_start_addr: 0x4180000
  physical_start_addr: 0x2D80000
  partition_size: 0x1000000

И в /proc/dumchar_info мы в графе StartAddr мы видим именно physical_start_addr. Но если мы взглянем на размер первого раздела (preloader), то становится понятно как перевести physical_start_addr в linear_start_addr, если к 0x2D80000 добавить 0x1400000 (это как раз размер preloader'а), то как раз получается 0x4180000.

MTK Nvram Tool (Backup & Restore). Резервное копирование NVRAM на MTK.

В последнее время довольно часто задают вопрос о Backup'е nvram на аппаратах, построенных на базе SoC MediaTek (MTK), вернее о восстановлении случайно затертого nvram, например, в результате неудачной перепрошивки, форматирования раздела и т.п. Многие кастомные recovery уже имеют подобную функцию штатно, но, например Clockwork Mod Recovery (CWM) или построенный на его базе PhilZ Touch Recovery подобной фукции не имеют. Как же быть в этом случае?

Для этих целей предусмотрена утилита MTK Nvram Tool, построенная на базе Aroma Installer 2.56. Для тех кто не знаком с тем что это такое или слышит это термин впервые, вкратце расскажу. Любая Android система использует для обновления бинарный файл update-binary и сценарий обновления updater-script. В сценарии прописан набор действий, которые совершаются с системой при обновлении, например, распаковка определенных файлов, форматирование разделов и т.п., ну а реализация этих действий фактически прописана в update-binary, который представляет из себя скомпилированную программу на С. Однако, несмотря на удобство подобного подхода и успешность его в плане применения обновлений - у него есть один недостаток. Он лишен интерактивности, т.е. не обеспечивает никакого взаимодействия с пользователем.

Фактически Aroma Installer это "улучшенный" во много раз update-binary, который содержит aroma ui (интерфейс взаимодействия с пользователем), поддерживает тач (сенсор), темы оформления, расширенные возможности в скриптовой части и много чего еще. Благодаря подобному функционалу на базе Aroma Installer можно создать "интерактивное обновление прошивки", где весь процесс установки будет сопровождаться диалогом с пользователем. Например, при прошивке update.zip через CWM откроется красивое окошко и у пользователя спросят, а желаете вы к примеру, установить дополнительные приложения от оператора или нет. И т.п. Думаю смысл в общих чертах понятен.

Ну а теперь к главному. Некто AnoopKumar с форума XDA-Developers (см. тему) создал на базе Aroma Installer полноценную утилиту для Backup'а NVRAM - MTK Nvram Tool. Смысл очень простой, вы загружаетесь в CWM или любой другой кастомный Recovery, выбираете пункт Install Zip и запускаете MTK_Nvram_Tool.zip. После чего у вас открывается интерфейс утилиты MTK Nvram Tool в котором есть всего два пункта меню - Nvram Backup и Nvram Restore:

Nvram Backup - сохраняет Nvram на SD-карту (обратите внимание, поддерживается только работа с внешней SD-картой), а Nvram Restore - восстанавливает их с SD-карты. При этом, на одной SD можно хранить только один единственный backup (что вообщем-то логично, т.к. SD карта как правило постоянно используется в одном аппарате).

Итого, всего лишь установив CWM и записав на SD-карту архив с MTK Nvram Tool мы получаем мощнейшее средство для резервного копирования и восстановления настроек nvram, которое защитит наш аппарат от неудачных экспериментов, "слёта" MAC адреса WiFi, IMEI и т.п. 

Надеюсь что статья оказалась вам полезной ...