MTK log #

介绍#

mtklog是由log生成工具MTKLogger生成的一系列问题追踪文件，其主要作用就是对系统或者应用产生的异常进行快速定位，从而解决问题。

log文件名称为：
crash_log ：崩溃日志，主要输出程序崩溃造成的crash log
events_log：事件日志，主要输出记录各个activity周期及事件
kernel_log：底层驱动，按键，低内存相关log
sys_log：系统日志，Exception定位点
radio_log：输出通话，网络状态变化
main_log：详尽输出每一步的log

开启和关闭#

（1）在拨号盘界面输入*#9646633# ：
（2）进入EngineerMode的第一个Telephony界面：
（3）向左滑动进入Log and Debugging界面：
（4）点击MTKLogger 菜单：点击log设置图标可进入log设置界面，如果我只要打印MobileLog可将ModemLog，NetworkLog，GPSlog关闭，点击蓝底色1 即可：
（5）点击开始（红色播放按键）按键：
（6）log 开启：
（7）当我们已经发现异常时，当关闭log，并截图记录时间点，下拉进入下拉栏界面，点击MTKLogger is running：
（8）点击停止按键

Log总览**#

Android Log

Android java层和native层 log
main log、system log、radio log、event log

Kernel Log

Linux Kernel内核和驱动log
UART Log

Exception Datebase(db)

系统死机/重启等问题发生时候的原始RAW data

Log Tools#

mtklogger
PC tool

mark

手机端mtklogger#

mark

个人优化#

mtklog抓取完整kernel log#

默认抓不全原因

由于Mobilelog service运行要在android system init阶段，而从kernel启动到这个阶段，kernel log已经在不断地送入log ring buffer，log量大的情况下ring buffer就会被覆盖

默认抓取到的kernel_log.boot不是从0s开始，对于研发debug阶段,只能靠抓取uart log来获取0s开始的log，非常影响debug效率

解决方法

alps/kernel-3.18/init/Kconfig
config LOG_BUF_SHIFT
       default 17  --- > 21   2^21=2MB buffer

alps/system/core/liblog/include/private/android_logger.h
#define LOG_BUFFER_SIZE (2048 * 1024)    #log和logd一致
123456

电脑端PC tool#

adb#

logcat#

介绍

logcat是android中的一个命令行工具，可以用于得到程序的log信息

常见的日志纪录方法包括：

方法	描述
v(String,String) (vervbose)	显示全部信息
d(String,String)(debug)	显示调试信息
i(String,String)(information)	显示一般信息
w(String,String)(waning)	显示警告信息
e(String,String)(error)	显示错误信息

例如：

//开发过程中获取log
Log.i("MyActivity","MyClass.getView() - get item number"+position);
//adb获取log
adb logcat
1234

adb logcat输出的日志格式如下：

I/ActivityManager( 1754): Waited long enough for: ServiceRecord{2b24178c u0 com.google.android.gms/.checkin.CheckinService}

实例

adb logcat –b radio
adb logcat –b system
adb logcat –b events
adb logcat –b main
1234

优势

缓冲区强大，不会因为数据量过大而丢失log
过滤性能好
语法简洁，使用方便

提取db#

位置

/data/aee_exp
/data/vendor/mtklog/aee_exp
12

GAT#

mark

BugReport

mark

DB puller

mark

Mediatek LogView

mark

各种mode抓mobile log#

Normal mode#

GAT (user版本只能抓main log，eng版本还能抓到kernel log)
mtklogger(user版本通过*##3646633##*进入工模选择)，会暂时录制到/data/log_temp下，等SD卡ready后再copy到mtklog/mobilelog/APLog路径下

Meta mode(PC meta tool)#

会先录制到/data/log_temp/meta/下，等外卡ready后再copy到sdcard1/mtklog/mobilelog/APLog路径下，然后删除源文件(data/log_temp)。

Factory mode(power + down key)#

同Meta mode

Recovery mode(power + up key)#

先存在tmp/recovery.log，Reboot进入normal后存在cache/recovery
user 版本需要下载eng的recovery.img和boot.img才能抓log

IPO mode#

设置IPO关机后，关机期间的log会录制到/data/log_temp/ipo/下，等再次开机后再copy到/mtklog/mobilelog/APLog路径下，然后删除源文件。
GAT

各种场景抓log#

Preloader & LK阶段（没有logo或卡在logo界面）开机log#

抓取uart log

Kernel阶段（有logo或开机动画)开机log#

如果是User版本，先用对应ENG 版本的lk 替换掉user 版本的lk
或者在user load的alps/bootable/bootloader/lk/app/mt_boot/mt_boot.c中，将所有printk.disable_uart=1改成printk.disable_uart=0，然后重新编译lk, download lk 即可。

Android阶段（有开机动画）开机log#

Adbd进程起来后，可以使用GAT抓取开机log（录制前先关机）。

若mtklogger可用，可以通过设置mobile log开机自启动录制开机log。

停止录制状态下mtklogger->settings->mobile log->start automticaly

若TP无法使用，可以参考FAQ06939使用adb命令控制mtklogger录制。

user build 抓开机向导或者不开机log#

编译一版eng版本对应软件，做如下修改：

alps/system/core/rootdir/init.rc

on property:ro.debuggable=1
    # Give writes to anyone for the trace folder on debug builds.
    # The folder is used to store method traces.
    chmod 0773 /data/misc/trace
    start console
//add begin
on property:ro.debuggable=0
    # Give writes to anyone for the trace folder on debug builds.
    # The folder is used to store method traces.
    chmod 0773 /data/misc/trace
    start console
setprop persist.sys.usb.config mass_storage,adb //add end
123456789101112

alps/kernel-3.18/drivers/misc/mediatek/mtprof/bootprof.c

#ifdef CONFIG_MT_PRINTK_UART_CONSOLE
    //mt_disable_uart();
#endif
123

alps/build/make/core/main.mk

ifeq (true,$(strip $(enable_target_debugging)))  # Target is more debuggable and adbd is on by default
  ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=1  # Enable Dalvik lock contention logging.
  ADDITIONAL_BUILD_PROPERTIES += dalvik.vm.lockprof.threshold=500   # Include the debugging/testing OTA keys in this build.
  INCLUDE_TEST_OTA_KEYS := true
else # !enable_target_debugging
  # Target is less debuggable and adbd is off by default
  ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=1
endif # !enable_target_debugging
12345678

编译好后，user版本刷入eng版本的lk+boot，抓取uart 或者上层log

如需抓取开机向导前的log，由于系统还未正式起来，请焊uart线，uart log中输入adb logcat &将上层log输出到uart log中

AEE异常机制#

AEE介绍#

AEE (Android Exception Engine)是安卓的一个异常捕获和调试信息生成机制。

手机发生错误（异常重启/卡死）时生成db文件（一种被加密过的二进制文件）

why do we need AEE#

用来保存和记录异常发生时候的所有内存信息，通过调试和仿真这些信息，可以追踪到异常的原因

DB文件介绍#

File	Description
__exp_main.txt	异常类型，调用栈等关键信息
_exp_detail.txt	详细异常信息
SYS_ANDROID_LOG	android buffer log(logcat -d -v time *:v)
SYS_KERNEL_LOG	kernel log
SYS_LAST_KMSG	上次重启前的kernel log
SYS_MINI_RDUMP	类似coredump，可以用gdb/trace32调试
SYS_WDT_LOG	看门狗复位信息
SYS_REBOOT_REASON	重启时的硬件记录的信息
SYS_VERSION_INFO	kernel版本，用于和vmlinux对比，只有匹配的vmlinux才能用于分析这个异常
SYS_ANDROID_EVENT_LOG	android event log(logcat -b events -v time -d *:v)
SYS_ANDROID_RADIO_LOG	android buffer log(logcat -b radio -v time -d *:v)
PROCESS_COREDUMP	native program core dump
SYS_PROPERTIES	system properties
SWT_JBT_TRACES	/data/anr/.
ZZ_INTERNAL	基本异常信息
SYS_CPU_INFO	cpu 信息(top -n 1 -d 1 -m 30 -t)
SYS_MEMORY_INFO	memory information (/proc/meminfo)

重启原因记录

struct last_reboot_reason
{
    uint32_t fiq_step;
    uint32_t exp_type; /* 0xaeedeadX: X=1 (HWT), X=2 (KE), X=3 (nested panic) */
    uint32_t reboot_mode;

    uint32_t last_irq_enter[NR_CPUS];
    uint64_t jiffies_last_irq_enter[NR_CPUS];

    uint32_t last_irq_exit[NR_CPUS];
    uint64_t jiffies_last_irq_exit[NR_CPUS];

    uint64_t jiffies_last_sched[NR_CPUS];
    char last_sched_comm[NR_CPUS][TASK_COMM_LEN];

    uint8_t hotplug_data1[NR_CPUS], uint8_t hotplug_data2;
    uint64_t hotplug_data3;

    uint32_t mcdi_wfi, mcdi_r15, deepidle_data, sodi_data, spm_suspend_data;
    uint64_t cpu_dormant[NR_CPUS];
    uint32_t clk_data[8], suspend_debug_flag;

    uint8_t cpu_dvfs_vproc_big, cpu_dvfs_vproc_little, cpu_dvfs_oppidx, cpu_dvfs_status;

    uint8_t gpu_dvfs_vgpu, gpu_dvfs_oppidx, gpu_dvfs_status;

    uint64_t ptp_cpu_big_volt, ptp_cpu_little_volt, ptp_gpu_volt, ptp_temp;
    uint8_t ptp_status;

    uint8_t thermal_temp1, thermal_temp2, thermal_temp3, thermal_temp4, thermal_temp5;
    uint8_t thermal_status;

    void *kparams;
};
12345678910111213141516171819202122232425262728293031323334

实际应用总结#

usr状态，不同现象手机如何抓取有效log#

可正常开机

A：MTKlogger基本足矣

卡logo，不开机

A：

刷入eng的lk和boot，再跳线抓取uart log，并开启logcat抓取从开机到异常出现时的所有底层和上层log
如果偶尔可以开机，第一时间进入系统提取db信息
如上述方式无法提取到关键db，则需要通过flashtool来回读db的原始raw分区，再通过自制expdb解压工具展开

debug阶段，手机如何抓取有效log#

无ctp情况下如何调试手机

A：连接adb，通过adb发送ctp报点与手势，来操作手机

无lcd情况下如何调试手机

A：使用GAT工具，实时抓取手机内部frame buffer，投影到电脑上，并用adb命令操作手机

UART Log量太大，无法找出重要log怎么办

A：采用adb logcat方式实时过滤带关键字关键level的log （包括kernel log）

Log分析与调试技巧#

Android开机流程图#

mark

bootprof#

adb shell cat /proc/bootprof or mktlog bootprof file

mark

实际案例（不开机类）#

文件系统损坏导致挂载失败#

System mount fail 导致 service 起不来，readback system分区对比看是否文件破坏。

[138:kworker/u16:2]device-mapper: verity: 179:30: metadata block 716579 is corrupted
[246:init]JBD2: IO error reading journal superblock
[246:init]EXT4-fs (dm-0): error loading journal
[246:init]fs_mgr: __mount(source=/dev/block/dm-0,target=/system,type=ext4)=-1  <<===文件系统挂载失败
[246:init]EXT4-fs (mmcblk0p31): VFS: Can't find ext4 filesystem
12345

经常遇到无法开机的问题，低概率、难复现，而且软、硬体跨度大，不易掌握与追踪；

事后分析:

部分有硬件实际损坏、系统映像档被破坏，或用户拔电池导致系统核心文件损坏…等几种原因。其中一部分导致无法开机的问题是由于不当操作使得文件损坏导致的。

PS:产线也会报小概率不开机的问题。

Donwload完整性检查和开机检查客制化

检查kernel log是否有emmc i/o error相关log

如果是单机问题检查emmc相关供电或作替换物料交叉实验

[ 5.030802] <0>.(0)[165:mmcqd/0]mmcblk0: error -110 transferring data, sector 5448262, nr 442, cmd
response 0x900, card status 0x0
[ 5.032358] <0>.(0)[165:mmcqd/0]blk_update_request: I/O error, dev mmcblk0, sector 5448262
[ 5.130190] <0>.(0)[179:init]EXT4-fs (dm-0): unable to read superblock
[ 5.131325] <0>.(0)[179:init]fs_mgr: __mount(source=/dev/block/dm-0,target=/system,type=ext4)=-1  <<===文件系统挂载失败
12345

preloader hang by mem test fail#

[50:31:154] [MEM] complex R/W mem test fail :FFFFFFFF
[50:31:155] <ASSERT> memory.c:line 105 0
[50:31:155] PL fatal error
[50:31:155] PL delay for Long Press Reboot
[50:31:159] power key is pressed
[50:36:117] [PLF]Emergency Dwld mode(timeout: 5s)
[50:36:119] mtk_arch_reset at pre-loader!
1234567

场景追溯

此问题发生的背景，是产线样机？研发样机？还是客退机？
问题发生概率如何？有固定的复现路径吗？目前遇到的问题是在什么测试下发生的？
问题发生是在一台机器，还是多台机器都有遇到？—- 如果是单机问题该memory硬件问题可能性大
用料是否为MTK QVL上已经验证OK的？其他项目上是否已经使用过？

汇贤雅叙

mtk-log

MTK log #

介绍#

开启和关闭#

Log总览**#

Log Tools#

手机端mtklogger#

个人优化#

mtklog抓取完整kernel log#

电脑端PC tool#

adb#

logcat#

提取db#

GAT#

各种mode抓mobile log#

Normal mode#

Meta mode(PC meta tool)#

Factory mode(power + down key)#

Recovery mode(power + up key)#

IPO mode#

各种场景抓log#

Preloader & LK阶段（没有logo或卡在logo界面）开机log#

Kernel阶段（有logo或开机动画)开机log#

Android阶段（有开机动画）开机log#

user build 抓开机向导或者不开机log#

AEE异常机制#

AEE介绍#

why do we need AEE#

DB文件介绍#

实际应用总结#

usr状态，不同现象手机如何抓取有效log#

debug阶段，手机如何抓取有效log#

Log分析与调试技巧#

Android开机流程图#

bootprof#

实际案例（不开机类）#

文件系统损坏导致挂载失败#

preloader hang by mem test fail#

MTK log#

介绍#

开启和关闭#

Log总览**#

Log Tools#

手机端mtklogger#

个人优化#

mtklog抓取完整kernel log#

电脑端PC tool#

adb#

logcat#

提取db#

GAT#

各种mode抓mobile log#

Normal mode#

Meta mode(PC meta tool)#

Factory mode(power + down key)#

Recovery mode(power + up key)#

IPO mode#

各种场景抓log#

Preloader & LK阶段（没有logo或卡在logo界面）开机log#

Kernel阶段（有logo或开机动画)开机log#

Android阶段（有开机动画）开机log#

user build 抓开机向导或者不开机log#

AEE异常机制#

AEE介绍#

why do we need AEE#

DB文件介绍#

实际应用总结#

usr状态，不同现象手机如何抓取有效log#

debug阶段，手机如何抓取有效log#

Log分析与调试技巧#

Android开机流程图#

bootprof#

实际案例（不开机类）#

文件系统损坏导致挂载失败#

preloader hang by mem test fail#

MTK log #