Недавно решил объединить свой старый способ дампа логов с модулем LLCON, т.к. их функционал пересекается. Да и старая реализация дампа логов написана на скорую руку внутри файла printk.c , что является очень плохим тоном.
Напомню, что ранее в этом блоге я уже описывал саму возможность дампа ядерных логов через запись и последующее чтение так называемой persistent ram.
Дублирование ядерных логов в специальную область оперативной памяти позволяет даже при экстренном рестарте SoC андройд девайса получить эти самые логи.
Так же напомню, что после экстренного рестарта девайса должно загрузиться что то полностью рабочее. Я рекомендую использовать для этого TWRP. Но данное TWRP должно тоже обладать способностью резервировать в оперативной памяти область по заданному адресу (напомню, что в моем случае этот адрес равен 0x7f200000). Для Qualcomm устройств это можно сделать через редактирование dtb.img, которое находится внутри TWRP. Полность описывать тут подробности сей процедуры я не стану, т.к. тематика редактирования DTB в этом блоге уже рассматривалась неоднократно. Вкратце напомню, что нужно дописать в dts-файл:
После подготовки средства для дампа участка оперативной памяти следует заняться доработкой ядра, которое отказывается запускаться. Для этого нужно просто напросто добавить в ядро модуль LLCON и пропатчить некоторые участки кода ядра:
После внесения изменений в исходники ядра следует не забыть включить сам функционал LLCON. Для этого в defconfig устройства нужно добавить следующие параметры:
Полученный boot.img закидываем в Android устройство. При помощи заранее подготовленного TWRP (см. выше инструкцию) заливаем boot.img в раздел boot и выполняем "System Reboot". Дожидаемся пока отработает тестируемое ядро. Если ядро тупо виснет, то при помощи длительного удержания кнопки Power и VolumeUp заставьте устройство перезагрузиться в TWRP (при этом должен быть подключён USB-кабель, что бы не обесточились чипы оперативной памяти). Если тестируемое ядро заставляет SoC грубо рестартиться, то просто вовремя зажмите кнопки Power и VolumeUp, что бы бутлоадер загрузил TWRP.
Теперь в TWRP выполните следующее (через ADB-интерфейс):
Напомню, что ранее в этом блоге я уже описывал саму возможность дампа ядерных логов через запись и последующее чтение так называемой persistent ram.
Дублирование ядерных логов в специальную область оперативной памяти позволяет даже при экстренном рестарте SoC андройд девайса получить эти самые логи.
Так же напомню, что после экстренного рестарта девайса должно загрузиться что то полностью рабочее. Я рекомендую использовать для этого TWRP. Но данное TWRP должно тоже обладать способностью резервировать в оперативной памяти область по заданному адресу (напомню, что в моем случае этот адрес равен 0x7f200000). Для Qualcomm устройств это можно сделать через редактирование dtb.img, которое находится внутри TWRP. Полность описывать тут подробности сей процедуры я не стану, т.к. тематика редактирования DTB в этом блоге уже рассматривалась неоднократно. Вкратце напомню, что нужно дописать в dts-файл:
/dts-v1/; /memreserve/ 0x7f200000 0x100000; /include/ "msm8226-v2.dtsi /include/ "msm8226-qrd.dtsiЗарезервировать область в памяти можно и другим способом. Нужно в dts-файл добавить фальшивое устройство, которое требует резервирование физической памяти:
/ { qcom,llcon-dmp-driver { compatible = "qcom,llcon-dmp-driver"; qcom,memblock-reserve = <0x7f200000 0x100000>; }; };Так же в этот TWRP следует добавить утилиту viewmem, которая позволяет дампить на диск участки оперативной памяти Android устройства. Исходники утилиты viewmem можно взять тут: github.com
После подготовки средства для дампа участка оперативной памяти следует заняться доработкой ядра, которое отказывается запускаться. Для этого нужно просто напросто добавить в ядро модуль LLCON и пропатчить некоторые участки кода ядра:
- патчи для ядер версии 3.4: github.com
- патчи для ядер версии 3.10: github.com
После внесения изменений в исходники ядра следует не забыть включить сам функционал LLCON. Для этого в defconfig устройства нужно добавить следующие параметры:
CONFIG_VT=y CONFIG_LLCON=y CONFIG_FONTS=y CONFIG_FONT_6x11=y CONFIG_FONT_8x16=y CONFIG_FONT_SUN12x22=yПеред стартом сборки ядра нужно так же внести изменения в BoardConfig.mk , в который следует добавить физический адрес памяти, в который будут дампиться ядерные логи:
BOARD_KERNEL_CMDLINE := console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 BOARD_KERNEL_CMDLINE += androidboot.hardware=d10f androidboot.selinux=permissive BOARD_KERNEL_CMDLINE += msm_rtb.filter=0x37 BOARD_KERNEL_CMDLINE += user_debug=31 debug ignore_loglevel BOARD_KERNEL_CMDLINE += llcondmp=0x7f200000,0x100000 BOARD_KERNEL_CMDLINE += coherent_pool=8M vmalloc=400MВот теперь можно запускать сборку тестируемого ядра.
Полученный boot.img закидываем в Android устройство. При помощи заранее подготовленного TWRP (см. выше инструкцию) заливаем boot.img в раздел boot и выполняем "System Reboot". Дожидаемся пока отработает тестируемое ядро. Если ядро тупо виснет, то при помощи длительного удержания кнопки Power и VolumeUp заставьте устройство перезагрузиться в TWRP (при этом должен быть подключён USB-кабель, что бы не обесточились чипы оперативной памяти). Если тестируемое ядро заставляет SoC грубо рестартиться, то просто вовремя зажмите кнопки Power и VolumeUp, что бы бутлоадер загрузил TWRP.
Теперь в TWRP выполните следующее (через ADB-интерфейс):
viewmem 0x7f200000 0x100000 > dmesg_llcon.txtПосле выполнения этой команды в корне диска появится файлик dmesg_llcon.txt , который содержит ядерные логи с предыдущего запуска тестируемого boot.img.
Комментариев нет:
Отправить комментарий