解析dump的几种方式

在开发调试过程中,经常会遇到手机/设备crash或者dump了,memory dump是分析系统crash/dump的重要办法

在qualcomm的流程中,设备如果发生dump,会将dump的log缓存到某一个区域,用户可以利用个别工具将log取出来分析,以下就是基本qcom的基础上介绍几种获取dump log的方法:

1.T32方法

trace32 onlie软件,链接到主板/设备上,然后利用JTAG方法能获取到log,T32的方法适用于qcom和MTK各种平台,具体方法可以google T32查询,这里不重点不在T32的方法

2.利用QPST获取

手机在dump后,会进入一个特殊的端口模式(diag.9006 Port),手机此时并不是处于关机/待机状态,这时候打开QPST Configuration,手机会自动抓取dump log并导出。同时,可以在phone状态栏发现,手机处于sahara memory dump的状态下。如下:


然后对应的文件夹会存放到指定的QPST目录下,默认目录在:

C:\Program Files\Qualcomm\QPST\....

在QPST中有设置输出路径的地方,DUMP LOG. 存储路径为 :

点击 Help 菜单 第二项 Open Log File Directory ,在弹出的窗口中打开Sahara 文件夹中 ,其中Port_COMX文件夹内存放的就是DUMP LOG, 注意此处 Port_COM号跟之前在QPST Configuration软件中显示COM 号要一致。以确保是本次导出

注意的是

1.在链接QPST导出时,请关系其他占用端口的软件,例如QDST等等,否则可能会导致QPST无法连接串口

2.QPST软件最好在window下运行,在虚拟机的window中运行有时候也会发生未知的错误链接不到

××××××××

获取到dump的log后,此时的log是无法直接review的,还需要经过处理,拿到ramdump+vmulinux,放在同一个路径下

脚本请下载:linux-ramdump-parser-v2/ramparse.py

git clone git://codeaurora.org/quic/la/platform/vendor/qcom-opensource/tools

以上工具是需要区分32位和64位的,请注意环境

同时在android环境中找到ndk提供的交叉编译环境:arm-linux-androideabi-gdb和arm-linux-androideabi-nm(也可以在网上下载)

执行以下cmd:

python /data/doc/linux-ramdump-parser-v2/ramparse.py --force-hardware=8916 -v/data/Port_COM49/vmlinux -g /data/p445tf/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-gdb -n /data/p445tf/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8/bin/arm-linux-androideabi-nm -a /data/Port_COM49 -o /data/dump8 –x

以上, 红色部分:ramparse.py脚本路径

    绿色部分:平台信息

    浅紫色部分:vmlinux路径

    深紫色部分:交叉编译环境路径,目前的路径就是gcc环境编译后存放在位置

    深黑色部分:dump文件名

以上是为了举例解释脚本用法,最好是添加到~/brasch中,方便快捷

其中-v指定dump文件对应的带调试信息的内核vmlinux文件
       -g指定对应的gdb工具文件
       -o指定解析文件的输出目录
       -x表示所有的debug信息均输出

命令执行后会出现如下解析info

!!! Out directory does not exist. Creating...


    [1/32] --clock-dump ... 0.873911s
    [2/32] --cpr3-info ... 0.135361s
    [3/32] --cpr-info ... 1.103903s
    [4/32] --cpu-state ... 0.098867s
    [5/32] --ddr-compare ... 3.923111s
    [6/32] --check-for-watchdog ... 0.011697s
    [7/32] --parse-debug-image ...
    ...

等待大约8分钟后,会提示解析完成,然后可以打开分析,dump log全部解析完成

3.利用高通QCAP网站解析

首先,你得有高通账号!你得有高通账号!你得有高通账号!(同时qcom那边有贵司项目信息入库)重要的事情说三遍

QCAP网站:

https://cap.qti.qualcomm.com/default.aspx

进入后是如下界面,界面中保存着你所有解析过的dump文件的记录,甚至可以下载xml下来给高通帮忙分析

那么要使用这个网页工具,点击new start analysas,会进入下面的页面:


按照图上的信息填完,carsh log就是dump log的路径

而build location这选择contents.xml路径,该文件存放在nonhlos/或者amss/下,用于区分modem侧各个分区的信息,会依照此文件分别解析对应log

解析完成后会显示如下界面:

首页会有网页自动帮忙分析的root case,当然解决问题的办法还需要深入的去查看其中的详细log(左侧可以分别查看tz,modem,ap侧等各类log和存储堆栈信息)

奇怪的是,个别log本地解析会有异常,没有log吐出,如果有case在qcom帮忙分析的话,qcom会重新要一份这样的vmlinux,dump file等拿去自己解析(据说他们解析出来文件是完整的)

阅读更多
个人分类: usb
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

加入CSDN,享受更精准的内容推荐,与500万程序员共同成长!
关闭
关闭