高通Thermal debug

包括两个部分kernel thermal monitor(KTM)和thermal engine。

  • Thermal 管理包括的内容如下:
  1. 硅片结温
  2. 内存温度限制
  3. 外表面温度限制
  • 当thermal engine完全初始化后,KTM确保所有环境条件下的结温处于限定的范围之内。
  • Thermal engine monitor监控系统的温度限制范围。
  • 机械结构设计模拟是获得最佳性能的必要步骤
  • Thermal management软件控制thermal响应。

DCVS:Dynamic Cloclk Frequency and Voltage Scaling.

下图包括了thermal 管理框架的四个部分:thermal engine, sensor driver以及其它温度管理设备。

在安卓用户空间thermal engine作为一个超级用户运行,thermal engine是温度管理的核心。启动时thermal engine初始化系统。threshold,set point以及管理的设备配置缺省情况从代码读取。参数用于设置温度传感器的中断门限。

为了在温度规范内获得最佳性能,这些参数在每一个设计中都要调优。温度传感器有:

  • 嵌入芯片硅结的温度传感器,这些是被称之为TSENS
  • thermal management 设备是软件抽象的设备,用于控制硬件,如GPU,CPU等

除了上述thermal架构,还有两个温度管理算法用于thermal engine完全启动前的设备启动和linux内核初始化阶段的温度管理。

Android温度限制和特点

  • KTM

内核启动时保护系统

设置110°为CPU热插拔的门限

将控制移交给thermal engine

  • Thermal engine

完整的温度保护策略

对特定对象必须调节

  • Thermal reset

异常情况

TM移交时间线

KTM

KTM函数和相关的调试

循环查询指定TSENS的温度,并根据得到的温度有如下的行为:

  • check_temp()--位于drivers/thermal/msm_thermal.c;每一个采样周期(msm_thermal_info.poll_ms)将被调用
  • do_therm_reset()---如果任意一个温度传感器的温度超过critical门限,这将导致看门狗(其参数由设备树的qcom,therm-reset-temp指定)喂狗,

msm_thermal:msm_thermal_bite: TSENS:α reached temperature:β. System reset

  • therm_get_temp()--获得设备树<qcom, sensor_id>字段指定sensor的温度,在调试时需要将该温度打印出来。
  • do_core_control()--到CPU温度超过门限时将cpu unplug,其打印的信息如下:
    msm_thermal:do_core_control: Set Offline: CPU$ Temp: β
    msm_thermal:do_core_control: Allow Online CPU$ Temp: β
  • do_vdd_mx()--对linux设备,KTM管理所有的温度传感器,如果温度掉于某个门限,其提升内存供电电压,在收到内存门限后KTM打印如下信息:

msm_thermal: vdd_mx_notify: Sensorα trigger received for type <threshold_type>

  • do_psm()--对于PMIC,温度超过一个门限后,其将被自动disable,KTM将发送一个命令让PMIC工作在PWM(pulse width modulation)模式,发送该命令时打印的信息如下:

msm_thermal:do_psm: Requested PMIC PWM Mode tsens:α. Temp:β
msm_thermal:do_psm: Requested PMIC AUTO Mode

  • do_gfx_phase_cond() and do_cx_phase_cond()---DIGITAL/GFX的多阶段电压轨。

msm_thermal:send_temperature_band: Sending <rail> temperature band<band_number> where, <rail>: DIGITAL or GFX with multiple BAND definition
depending on chipset

  • do_ocr()--对于一些设备,KTM监控温度,如果发现任意一个传感器温度超过门限,其向regulator发送最优电流请求。
  • do_vdd_restriction()--用于限制温度低门限(5°)时,KTM打印的信息如下:

msm_thermal:vdd_restriction_notify: sensor:α reached high thresh for Vddrestriction
msm_thermal:vdd_restriction_notify: sensor:α reached low thresh for Vddrestriction

  • do_freq_control()---当一个温度超过门限时CPU调频控制,其打印的信息如下:

msm_thermal:do_freq_control: Limiting CPU$ max frequency to 1958400. Temp:β

KTM设置

一个例子是:/arch/arm64/boot/dts/qcom/msm8916.dtsi

qcom,msm-thermal {
qcom,msm-thermal {
compatible = "qcom,msm-thermal";
qcom,sensor-id = <5>;
qcom,poll-ms = <250>;
qcom,limit-temp = <60>;
qcom,temp-hysteresis = <10>;
qcom,freq-step = <2>;
qcom,freq-control-mask = <0xf>;
qcom,core-limit-temp = <80>;
qcom,core-temp-hysteresis = <10>;
qcom,core-control-mask = <0xe>;
qcom,hotplug-temp = <94>;
qcom,hotplug-temp-hysteresis = <15>;
qcom,cpu-sensors = "tsens_tz_sensor5", "tsens_tz_sensor5",
"tsens_tz_sensor4", "tsens_tz_sensor4";
qcom,freq-mitigation-temp = <94>;
qcom,freq-mitigation-temp-hysteresis = <10>;
qcom,freq-mitigation-value = <400000>;
qcom,freq-mitigation-control-mask = <0x01>;
qcom,online-hotplug-core;
qcom,vdd-restriction-temp = <5>;
qcom,vdd-restriction-temp-hysteresis = <10>;
vdd-dig-supply = <&pm8916_s1_floor_corner>;
qcom,vdd-dig-rstr{
qcom,vdd-rstr-reg = "vdd-dig";
qcom,levels = <5 7 7>; /* Nominal, Super Turbo, Super
Turbo */
qcom,min-level = <1>; /* No Request */
};
qcom,vdd-apps-rstr{
qcom,vdd-rstr-reg = "vdd-apps";
qcom,levels = <533330 800000 998400>;
qcom,freq-req;
};
};
CPU0传感器用于控制算法,如果温度超过limit-temp给定的值,CPU的最高主频将被限制,如果后续轮询温度继续升高,则频率会被进一步降低,轮询的时间间隔是poll-ms定义的值。如果温度调到limit-temp和temp-hysteresis之和以下,那么可以达到的最高主频将被增加。CPU频率的高低在DCVS表中仅一步。

除了CPU调频,第二个温度门限core-limit-temp定义了CPU热插拔的门限。当温度超过该门限时CPU将被unplug。

设备树中的freq-control-mask和core-control-mask定义了那个cpu核按上述定义的规则工作,bit 0对应CPU0,默认core-control-mask 不包括CPU0,因为其不可以热插拔。

该算法位于/drivers/thermal/msm_thermal.c,对应的温度参数定义于arch/arm64/boot/dts/qcom/msm8916.dtsi。

Thermal Engine

这属于安卓侧的温度管理策略,其根据一个configure文件(default is /etc/thermal-engine.conf),但是一般会有一个平台对应文件,如/system/etc/thermal-engine-8974.conf

Thermal 管理策略--嵌入式和配置方式

三种算法

  • SS(single step),PID(Proportional-Integral-Derivative)和monitor。
  • 所有的规则要么定义于config文件,要么硬编码到thermal engine 数据文件里。

对于嵌入式规则,要求必须提供电压限制和PSM控制,可选的是所有CPU启动SS/PID控制算法

对于配置文件定义的算法,管理结温的算法通常采用SS算法,管理Pop 内存的采用SS或者monitor算法。

SS/PID/MONITOR算法实例

SS algorithm

本例中label是surface_control_dtm,该名称必须是唯一的,SS算法(algo_type = ss)通过每隔一秒(sampling = 1000)采样ID是3(sensor = tsens_tz_sensor3)的传感器来进行温度控制,DTM控制所有CPU的最大允许的主频(device = cpu),Sensor ID 3的温度设置根据系统表面温度是25°时设定的,所以控制表面温度在45°时,ID 3的温度传感器的温度应该在70°,安全门限温度设置在了55°,这一温度将不会限制CPU主频。

[surface_control_dtm]
algo_type ss
sensor tsens_tz_sensor3
device cpu
sampling 1000
set_point 70000
set_point_clr 55000

PID algorithm

标号是urface_control_pid,算法类型是(algo_type = pid),其65ms(sampling = 65)间隔采样ID 5温度传感器(sensor = tsens_tz_sensor5),PID调节最大允许的cpu主频(device = cpu0),ID 5是CPU0,所以控制温度设置成了95°,安全门限温度是55°,所谓的安全门限就是在这一温度以下,主频可以放开跑。

[CPU0_control_pid]
algo_type pid
sensor tsens_tz_sensor5
device cpu0
sampling 65
set_point 95000
set_point_clr 55000

Monitor algorithm

[modem]
algo_type monitor
sensor pa_therm0
sampling 1000
thresholds 70000 80000
thresholds_clr 65000 75000
actions modem mode

Thermal engine 调试

1.找到当前的thermal engine配置

adb shell thermal-engine –o > thermal-engine.conf

2.修改该文件后推送到设备上

3.将”debug“放到thermal-engine.conf的首行,然后重新启动thermal-engine服务

adb shell stop thermal-engine
adb root
adb remount
adb push thermal-engine.conf /system/etc/thermal-engine.conf
adb shell sync .
adb shell strat thermal-engine --debug &
4.logcat查看系统温度log

adb logcat –v time –s ThermalEngine

Temperature日志

内部传感器log

1.绝大多数信息已经导入到了sysfs node节点里。

2.log脚本周期性记录温度并保存到文件里

3.当前主频和最高主频也要记录到文件里

// checking for temp zone 0 value if sensor available
if (tz_flags[0]) {
tz_temp= 0;
tzs=
fopen("/sys/devices/virtual/thermal/thermal_zone0/temp","r");
if(tzs) {
fscanf(tzs,"%d",&tz_temp);
if (debug) {
printf("\nReadTEMPZONE0
file %d\n",tz_temp);
}
fclose(tzs);
}
fprintf(out_fd,"%d,",tz_temp);
}
4.POP内存/表面温度记录

可以使用热电偶或者红外摄像机

5,读取当前的温度

adb shell cat /sys/devices/virtual/thermal/thermal_*/temp


<think>好的,我现在需要帮助用户解析Android高通平台的未知重启问题,特别是关于POWERUP_REASON、POWERUP_REASON_DETAIL和POWEROFF_REASON 0x80040的日志。首先,用户之前的问题是关于如何搜索异常重启的关键字,现在他进一步询问具体日志的解析方法,并提到了这些特定的电源相关原因代码。 我需要回顾之前的对话,确保回答的连贯性。上一次我提供了需要搜索的关键字和日志抓取方法,现在用户需要更深入的分析这些特定字段的含义。首先,我应该确认高通平台中这些电源原因代码的具体定义,因为不同的芯片组可能有不同的编码。 用户提到的POWERUP_REASON、POWERUP_REASON_DETAIL和POWEROFF_REASON 0x80040,这些都是高通芯片中用于记录启动和关机原因的寄存器或日志字段。0x80040这样的十六进制值需要转换为二进制来分析每一位的含义,可能对应不同的硬件模块或事件触发,比如看门狗、过热、电源键长按等。 接下来,我需要结合用户提供的引用内容,特别是引用[1]到[4]中提到的关机流程和系统调用,说明这些原因代码如何与系统行为关联。例如,如果重启是由看门狗触发的,日志中可能会有相关的subsys-restart或Watchdog bark条目,同时POWERUP_REASON可能对应某个特定位被置位。 还要考虑如何解析这些日志,用户可能需要使用高通的工具如QPST或QXDM来获取更详细的诊断信息,或者通过adb命令提取last_kmsg和tombstones日志。此外,需要指导用户如何将十六进制代码转换为具体的原因,可能需要参考高通的文档或头文件,比如在PMIC(电源管理集成电路)相关的文档中查找定义。 另外,用户的问题涉及到unknown reboot,这意味着标准日志中没有明确的原因,这时候需要结合多个日志源,如内核日志、系统事件日志、Modem日志等,综合分析。例如,POWEROFF_REASON 0x80040可能对应某个特定的硬件错误,需要查看硬件错误日志或传感器数据。 最后,需要确保回答结构清晰,分步骤说明如何解析这些字段,并提供相关工具和命令示例,帮助用户实际操作。同时,生成的相关问题要引导用户进一步排查可能的原因,比如硬件故障或特定子系统崩溃。</think>针对Android高通平台的未知重启问题分析,需重点关注电源状态寄存器(POWERUP_REASON/POWERUP_REASON_DETAIL)和关机原因代码(POWEROFF_REASON 0x80040),结合以下关键点进行日志解析: --- ### 一、电源状态寄存器解析 #### 1. **POWERUP_REASON**(启动原因寄存器) - **硬件级触发标志**:记录芯片组PMIC(Power Management IC)检测到的开机触发源 - **典型值分析**: - `0x1`:电源键长按(硬件触发) - `0x2`:USB充电唤醒 - `0x4`:RTC闹钟唤醒 - `0x8`:看门狗复位(需结合`subsys-restart`日志)[^1] #### 2. **POWERUP_REASON_DETAIL**(启动细节寄存器) - **二级触发分析**:补充说明具体触发模块 - `0x10000`:APSS(应用处理器子系统)触发 - `0x20000`:Modem子系统触发 - `0x40000`:WLAN/BT子系统触发 - **示例**:`POWERUP_REASON_DETAIL=0x20100`表示Modem异常导致APSS复位[^2] #### 3. **POWEROFF_REASON 0x80040** - **十六进制解析**:展开为二进制`1000 0000 0000 0100 0000`,按位分析: - **Bit19(0x80000)**:硬件看门狗超时 - **Bit6(0x40)**:PMIC过温保护触发 - **典型场景**:芯片温度超过阈值导致强制关机[^3] --- ### 二、日志关联分析方法 #### 1. **内核日志交叉验证** ```bash adb shell dmesg | grep -E "PMIC|WDG|THERMAL" ``` - 匹配`THERMAL: Critical temperature reached`确认过温保护 - 匹配`qcom,wdog`查看看门狗喂狗记录 #### 2. **高通子系统日志** - **SSR(SubSystem Restart)事件**: ```bash adb logcat | grep "subsys_name=modem" # 基带异常重启 ``` - **SMEM日志**:通过高通工具QXDM抓取`SMEM Dump`,定位PMIC错误码[^4] #### 3. **电源管理服务日志** - **Init进程日志**: ```bash adb logcat -b events | grep "boot_reason" ``` 匹配`last_poweroff_reason=0x80040`确认关机原因 - **PowerManagerService**: 检查`ShutdownThread`调用栈: ```java // 代码片段对应引用[2] PowerManagerService.lowLevelReboot(reason); ``` --- ### 三、异常场景对照表 | 现象 | 关键日志组合 | 根本原因 | |---------|--------------|----------| | 过热重启 | `POWEROFF_REASON 0x80040` + `THERMAL: shutdown` | 散热异常或CPU负载过高 | | 看门狗复位 | `POWERUP_REASON 0x8` + `KERNEL: Watchdog bark` | 子系统未及时喂狗 | | Modem崩溃 | `POWERUP_REASON_DETAIL 0x20000` + `SSR: modem` | 基带固件/信号问题 | --- ### 四、深度排查工具 1. **QPST Configuration** 使用`QCAT`分析QXDM抓取的`PMIC Log`,查看电压/温度曲线 2. **APSS Ramdump** 通过`adb pull /sys/fs/pstore/console-ramoops`获取崩溃瞬间内存快照 3. **寄存器直接读取** ```bash adb shell "echo 0x80040 > /sys/kernel/debug/pmic_dbg/reg && cat /sys/kernel/debug/pmic_dbg/reg" ``` ---
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

shichaog

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值