[Android][sensor]触发adsp的软dump和硬dump

原创已于 2023-03-06 13:55:15 修改 · 1.1k 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#android

于 2022-12-04 23:29:24 首次发布

android_sensor 专栏收录该内容

26 篇文章

订阅专栏

本文介绍如何通过禁用ADSP的SSR并使用adb命令来触发软dump，以及如何通过下拉PS_HOLD来模拟硬件重置以获取硬dump。此外还提供了使用qpst工具收集dump的方法，并推荐了用于解析ramdump的QCAP工具。

触发软dump

1.禁用ADSP的SSR

adb shell echo SYSTEM > adb shell cat /sys/bus/msm_subsys/devices/subsys[n]/restart_level
n是adsp对应的subsys

2.触发dump

adb shell c > /proc/sysrq-trigger

3.qpst工具收集dump.

触发硬dump

下拉PS_HOLD可以模拟突然硬件重置以获取dump。

解析dump

参考高通"80-NR964-54" 是解析ramdump的文档，用QCAP工具可以解析ramdump

确定要放弃本次机会？

福利倒计时

: :

立减 ¥

普通VIP年卡可用

立即使用

霁之鸢

关注关注

1
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
分享

复制链接

分享到 QQ

分享到新浪微博

扫一扫
打赏
打赏
打赏举报

举报

专栏目录

Android14音频进阶之ADSP调试(七十二)

Android系统攻城狮

05-16

1568

本篇目的：Android14音频进阶之开启内核dynamic debug动态调试内核的dynamic debug动态调试是一种强大的功能，它允许开发者和系统管理员在内核运行时对其进行调试和监测。这种调试技术可以在不重启系统的情况下，实时地修改内核的参数和行为，以便于分析和解决内核中的问题和性能瓶颈。dynamic debug技术基于内核的模块化设计。每个内核模块都可以独立地加载和卸载，因此，开发者可以针对特定的模块进行调试，而不会影响整个系统的稳定性和性能。

【系统稳定性】1.17 SSR

从0到1，突破自己

03-09

386

Subsystem Restart即子系统重启，这是一种回复策略或子系统兜底机制，旨在确保系统在某个子系统出现故障时能够自动恢复，而无需重启整个设备。SSR通过监控子系统的健康状态，并在检测到故障时触发重启，以恢复其功能。

参与评论您还未登录，请先登录后发表或查看评论

Qcom Sensor调试

ZKR_HN的博客

12-08

1210

Qcom Sensor

sensor调试总结

qq_45034380的博客

11-10

4270

sensor通常有两路供电1.8V和2.8V，1.8V给I2C总线供电，2.8V给器件供电。

[Android][sensor]高通SEE架构下adsp平台的sensor低功耗原理

csdn_liqian的博客

11-15

6927

高通SEE架构下adsp平台的sensor低功耗原理

Android Sensor详解（2）如何portingADSP中的sensor

热门推荐

The CnSkyline Blog

11-20

1万+

ADSP sensor overview在初略介绍sensor的时候，就有讲到sensor的架构，在此继续将其具体化，来看看高通的sensor架构。我们可以通过下图看具体sensor是如何进行运作的。该图我们可以非常明显地看到Sensor通过I2C或者是SPI将数据发到Sensor Driver中，drivers通过device driver framework将数据包装后发给Sensor Mana

[Android][sensor]物理sensor bring up流程

csdn_liqian的博客

11-26

3165

android Qcom SEE架构下的物理sensor bring up 流程

android开发工作笔记

小胡子_0214

06-21

542

config: (i,w,r,s,md),4,1,100,0x1,0x1,0 //100就是odr的值，从qxdm底层日志可以看到。（3）撤销commit，并撤销 git add，并撤销修改的代码：git reset --hard HEAD^（2）撤销commit，不撤销 git add 操作：git reset --soft HEAD^（1）撤销commit，并撤销 git add，不撤销修改的代码：git reset HEAD^（4） git add 后如何撤销：git reset HEAD。

高通平台Sensor调试

Evejer的博客

11-30

2840

高通平台sensor驱动调试，分为ap侧和slpi侧驱动，以icm42670型号为例

adb shell setprop persist.vendor.ssr.restart_level adsp

07-08

- 触发ADSP SSR测试（可选）：参考引用[^3]，可发送诊断命令模拟故障，但生产环境中不建议频繁测试。 - 重启设备：`adb reboot`，检查重启后属性是否保持（持久性）。 #### 注意事项 - **风险提示**：错误的值...

Line 20149: 10-14 22:01:48.314995 11611 11611 I [269501.770848]CAM_INFO: CAM-SENSOR: cam_sensor_driver_cmd: 1042 CAM_RELEASE_DEV Success, sensor_id:0x5044,sensor_slave_addr:0x20 Line 20716: 10-14 22:02:16.930389 175 175 E [269530.386242]qcom_smp2p soc: qcom,smp2p-adsp: 2:sleepstate_see: status:ffffffff sensor_type:0 ap_stat:0 Line 20814: 10-14 22:02:17.391599 175 175 E [269530.847452]qcom_smp2p soc: qcom,smp2p-adsp: 2:sleepstate_see: status:ffffffff sensor_type:65535 ap_stat:255 Line 20836: 10-14 22:02:17.503628 862 862 W [269530.959481]: wcd_core_dlkm(OE) stub_dlkm(OE) cnss_utils(OE) bolero_cdc_dlkm(OE) oplus_audio_pa_manager(OE) audio_pkt_dlkm(OE) oplus_dns_hook(OE) audpkt_ion_dlkm(OE) wcd937x_slave_dlkm(OE) spf_core_dlkm(OE) coresight_tgu(E) gpr_dlkm(OE) oplus_network_linkpower_module(OE) oplus_freeze_process(OE) stm_p_basic(E) hdcp_qseecom_dlkm(OE) oplus_hans(OE) oplus_security_guard(OE) snd_usb_audio_qmi(E) cfg80211(E) qti_qmi_sensor(E) snd_event_dlkm(OE) qti_devfreq_cdev(E) swr_dlkm(OE) oplus_data_module(OE) coresight_dummy(E) cx_ipeak_cdev(E) oplus_chg_v2(E) oplus_networks_tuning(OE) coresight_hwevent(E) oplus_app_monitor(OE) oplus_stats_calc(OE) stm_p_ost(E) coresight_tpda(E) oplus_bsp_memleak_detect(OE) q6_notifier_dlkm(OE) lmh_cpu_vdd_cdev(E) coresight_cti(E) msm_tsens_driver(E) q6_pdr_dlkm(OE) msm_lmh_dcvs(E) oplus_sched(OE) coresight_tpdm(E) oplus_qr_scan(OE) oplus_game_first(OE) leds_qti_flash(E) oplus_chg(E) coresight_remote_etm(E) leds_qti_tri_led(E) stm_console(E) qrtr_smd(E) Line 20840: 10-14 22:02:17.503886 862 862 W [269530.959739]: oplus_bsp_tp_syna_comnon(E) sg(E) rtc_pm8xxx(E) phy_msm_qusb(E) oplus_bsp_tp_ilitek_common(E) ipa_fmwk(E) usb_f_cdev(E) oplus_bsp_tp_ft3518(E) usb_f_ccid(E) ucsi_glink(E) oplus_io_monitor(E) oplus_bsp_tp_ft3419u(E) oplus_bsp_tp_focal_common(E) oplus_bsp_tp_comon(E) msm_performance(E) oplus_bsp_fw_update(E) oplus_bsp_tp_custom(E) qpnp_pdphy(E) oplus_bsp_tp_notify(E) qcom_va_minidump(E) olc(E) cx_ipeak(E) guestvm_loader(E) rdbg(E) rpm_smd_debug(E) usb_bam(E) oplus_sensor(E) hung_task_enh(E) phy_qcom_emu(E) gpucc_sm6115(E) sps_drv(E) oplus_bsp_dfr_ubt(E) iolimit(E) rq_stats(E) dwc3_msm(E) ehset(E) phy_msm_ssusb_qmp(E) phy_msm_snps_hs(E) phy_generic(E) oplus_resctrl(E) cdsp_loader(E) ssc_interact(E) oplus_bsp_sensor_feedback(E) bwmon(E) dispcc_sm6115(E) qcom_ramdump(E) qfprom_sys(E) eud(E) charger_ulog_glink(E) altmode_glink(E) rpm_master_stat(E) dispcc_khaje(E) memlat(E) boot_stats(E) pmic_glink_debug(E) core_hang_detect(E) qti_battery_debug(E) pmic_glink(E) Line 20840: 10-14 22:02:17.503886 862 862 W [269530.959739]: oplus_bsp_tp_syna_comnon(E) sg(E) rtc_pm8xxx(E) phy_msm_qusb(E) oplus_bsp_tp_ilitek_common(E) ipa_fmwk(E) usb_f_cdev(E) oplus_bsp_tp_ft3518(E) usb_f_ccid(E) ucsi_glink(E) oplus_io_monitor(E) oplus_bsp_tp_ft3419u(E) oplus_bsp_tp_focal_common(E) oplus_bsp_tp_comon(E) msm_performance(E) oplus_bsp_fw_update(E) oplus_bsp_tp_custom(E) qpnp_pdphy(E) oplus_bsp_tp_notify(E) qcom_va_minidump(E) olc(E) cx_ipeak(E) guestvm_loader(E) rdbg(E) rpm_smd_debug(E) usb_bam(E) oplus_sensor(E) hung_task_enh(E) phy_qcom_emu(E) gpucc_sm6115(E) sps_drv(E) oplus_bsp_dfr_ubt(E) iolimit(E) rq_stats(E) dwc3_msm(E) ehset(E) phy_msm_ssusb_qmp(E) phy_msm_snps_hs(E) phy_generic(E) oplus_resctrl(E) cdsp_loader(E) ssc_interact(E) oplus_bsp_sensor_feedback(E) bwmon(E) dispcc_sm6115(E) qcom_ramdump(E) qfprom_sys(E) eud(E) charger_ulog_glink(E) altmode_glink(E) rpm_master_stat(E) dispcc_khaje(E) memlat(E) boot_stats(E) pmic_glink_debug(E) core_hang_detect(E) qti_battery_debug(E) pmic_glink(E) Line 20971: 10-14 22:02:18.064941 175 175 E [269531.520794]qcom_smp2p soc: qcom,smp2p-adsp: 2:sleepstate_see: status:ffffffff sensor_type:0 ap_stat:0 Line 22637: 10-14 22:03:57.621884 175 175 E [269631.077737]qcom_smp2p soc: qcom,smp2p-adsp: 2:sleepstate_see: status:ffffffff sensor_type:65535 ap_stat:255 Line 22774: 10-14 22:03:58.351254 862 862 W [269631.807107]: wcd_core_dlkm(OE) stub_dlkm(OE) cnss_utils(OE) bolero_cdc_dlkm(OE) oplus_audio_pa_manager(OE) audio_pkt_dlkm(OE) oplus_dns_hook(OE) audpkt_ion_dlkm(OE) wcd937x_slave_dlkm(OE) spf_core_dlkm(OE) coresight_tgu(E) gpr_dlkm(OE) oplus_network_linkpower_module(OE) oplus_freeze_process(OE) stm_p_basic(E) hdcp_qseecom_dlkm(OE) oplus_hans(OE) oplus_security_guard(OE) snd_usb_audio_qmi(E) cfg80211(E) qti_qmi_sensor(E) snd_event_dlkm(OE) qti_devfreq_cdev(E) swr_dlkm(OE) oplus_data_module(OE) coresight_dummy(E) cx_ipeak_cdev(E) oplus_chg_v2(E) oplus_networks_tuning(OE) coresight_hwevent(E) oplus_app_monitor(OE) oplus_stats_calc(OE) stm_p_ost(E) coresight_tpda(E) oplus_bsp_memleak_detect(OE) q6_notifier_dlkm(OE) lmh_cpu_vdd_cdev(E) coresight_cti(E) msm_tsens_driver(E) q6_pdr_dlkm(OE) msm_lmh_dcvs(E) oplus_sched(OE) coresight_tpdm(E) oplus_qr_scan(OE) oplus_game_first(OE) leds_qti_flash(E) oplus_chg(E) coresight_remote_etm(E) leds_qti_tri_led(E) stm_console(E) qrtr_smd(E) Line 22777: 10-14 22:03:58.351528 862 862 W [269631.807381]: ucsi_glink(E) oplus_io_monitor(E) oplus_bsp_tp_ft3419u(E) oplus_bsp_tp_focal_common(E) oplus_bsp_tp_comon(E) msm_performance(E) oplus_bsp_fw_update(E) oplus_bsp_tp_custom(E) qpnp_pdphy(E) oplus_bsp_tp_notify(E) qcom_va_minidump(E) olc(E) cx_ipeak(E) guestvm_loader(E) rdbg(E) rpm_smd_debug(E) usb_bam(E) oplus_sensor(E) hung_task_enh(E) phy_qcom_emu(E) gpucc_sm6115(E) sps_drv(E) oplus_bsp_dfr_ubt(E) iolimit(E) rq_stats(E) dwc3_msm(E) ehset(E) phy_msm_ssusb_qmp(E) phy_msm_snps_hs(E) phy_generic(E) oplus_resctrl(E) cdsp_loader(E) ssc_interact(E) oplus_bsp_sensor_feedback(E) bwmon(E) dispcc_sm6115(E) qcom_ramdump(E) qfprom_sys(E) eud(E) charger_ulog_glink(E) altmode_glink(E) rpm_master_stat(E) dispcc_khaje(E) memlat(E) boot_stats(E) pmic_glink_debug(E) core_hang_detect(E) qti_battery_debug(E) pmic_glink(E) msm_memshare(E) debugcc_khaje(E) glink_pkt(E) heap_mem_ext_v01(E) smp2p_sleepstate(E) cdsprm(E) msm_gpi(E) gpucc_khaje(E) oplus_bsp_proactive_compact(E) Line 22777: 10-14 22:03:58.351528 862 862 W [269631.807381]: ucsi_glink(E) oplus_io_monitor(E) oplus_bsp_tp_ft3419u(E) oplus_bsp_tp_focal_common(E) oplus_bsp_tp_comon(E) msm_performance(E) oplus_bsp_fw_update(E) oplus_bsp_tp_custom(E) qpnp_pdphy(E) oplus_bsp_tp_notify(E) qcom_va_minidump(E) olc(E) cx_ipeak(E) guestvm_loader(E) rdbg(E) rpm_smd_debug(E) usb_bam(E) oplus_sensor(E) hung_task_enh(E) phy_qcom_emu(E) gpucc_sm6115(E) sps_drv(E) oplus_bsp_dfr_ubt(E) iolimit(E) rq_stats(E) dwc3_msm(E) ehset(E) phy_msm_ssusb_qmp(E) phy_msm_snps_hs(E) phy_generic(E) oplus_resctrl(E) cdsp_loader(E) ssc_interact(E) oplus_bsp_sensor_feedback(E) bwmon(E) dispcc_sm6115(E) qcom_ramdump(E) qfprom_sys(E) eud(E) charger_ulog_glink(E) altmode_glink(E) rpm_master_stat(E) dispcc_khaje(E) memlat(E) boot_stats(E) pmic_glink_debug(E) core_hang_detect(E) qti_battery_debug(E) pmic_glink(E) msm_memshare(E) debugcc_khaje(E) glink_pkt(E) heap_mem_ext_v01(E) smp2p_sleepstate(E) cdsprm(E) msm_gpi(E) gpucc_khaje(E) oplus_bsp_proactive_compact(E) Line 22842: 10-14 22:03:58.475684 175 175 E [269631.931537]qcom_smp2p soc: qcom,smp2p-adsp: 2:sleepstate_see: status:ffffffff sensor_type:0 ap_stat:0

最新发布

10-18

- `sensor_type: 65535`（0xFFFF）和 `ap_stat: 255`（0xFF）均为异常值，表明 ADSP 无法进入睡眠状态。 - **可能原因**： - 传感器驱动未释放资源（如 Line 20149 的摄像头传感器 `sensor_id:0x5044` 虽释放...

如何portingADSP中的sensor

sunnywalden

04-10

1308

ADSP sensor overview 在初略介绍sensor的时候，就有讲到sensor的架构，在此继续将其具体化，来看看高通的sensor架构。我们可以通过下图看具体sensor是如何进行运作的。该图我们可以非常明显地看到Sensor通过I2C或者是SPI将数据发到Sensor Driver中，drivers通过device driver framework将数

高通ADSP抓取sensor init log

weixin_32104133的博客

08-23

4965

高通平台支持两种获取adsp侧sensor init log的方式。第一种方式是：通过adb名利重启sensors a. adb shell stop sensors b. adb shell “echo ‘related’ > /sys/bus/msm_subsys/devices/subsys1/restart_level” c. adb shell “echo ‘restart’ &...

Sensor系列之aDSP端Sensor Driver流程

接私活，免费帮家长照顾20-25岁的好看的女孩子。

07-06

7131

--所有的存在都是为了走向毁灭而设计的。--我们被囚禁在这....--生与死的无尽螺旋里。--这是诅咒?--还是惩罚?--面对着将无解谜题交予我们的神明，我们会有反抗的一天吗? 本系列导航： Android简单的计步器应用实现 Android Native到HAL源码剖析，以sensor为例 Android Sensor HAL层初始化流程(基于Qualcomm平台) Sensor系...

sensorservice相关dump

许浑的博客

01-17

4287

高通adsp sensor core adb 命令

不喜欢指指点点，欢迎指点指点

11-03

2784

adb root adb wait-for-device adb shell mount -o remount,rw /firmware adb remount adb shell rm /system/etc/firmware/adsp* adb shell rm /system/etc/adsp* adb push ./adsp.b00 /system/etc/firmware

Android Sensor详解（5）搭建adsp firmware的环境

The CnSkyline Blog

03-06

5785

获取与安装hexagon tools首先你得要有高通的账号，通过高通官网下载相关的tool。通过搜索tool，就可以找到祥光的hexagon tool，然后直接安装即可。具体安装方法可以参考高通的80-VB419-25。这里仅仅是简单介绍 cd Linux/72-NN231-6.4.03 chmod a+x Install_HEXAGON_Tools_6.4.03.bin sud

Java 7之基础 - 强引用、弱引用、软引用、虚引用

rongwenbin的专栏

03-28

397

1、强引用（StrongReference）强引用是使用最普遍的引用。如果一个对象具有强引用，那垃圾回收器绝不会回收它。如下： 1 Object o=new Object(); // 强引用当内存空间不足，Java虚拟机宁愿抛出OutOfMemoryError错误，使程序异常

高通工具 - 解析APPS dump 工具linux ramdump parser

bsp_linux_dev的博客

08-26

465

高通开源的工具，用于分析Linux 死机dump log。

adsp crash 和 adsp ramdump的区别

08-05

<think>嗯，用户现在想理解ADSP crash和ADSP ramdump的区别，而且是在车载音频开发的背景下。之前已经用大白话解释过ramdump的概念，现在需要更聚焦在ADSP这个特定场景。用户提供的站内引用都是关于高通平台的双系统开发，特别是QNX+Android架构下的ADSP问题。用户可能是个车载系统工程师，正在调试音频相关的崩溃问题。从ta追问的精确度来看，应该是有实际调试经验的技术人员，不是完全的小白。ta需要明确区分两个易混淆的概念：crash是故障事件本身，ramdump是事后分析手段。这个区分对实际排障流程很重要——工程师得先确认crash发生了，才能去获取ramdump。引用[1]提到ADSP crash时用两种方式dump内存，正好佐证这个关系。引用[3]展示的crash工具命令行则说明ramdump需要特定解析工具。有趣的是引用[2]特别强调QNX的ramdump和LA方案不同，暗示用户要注意平台差异——不过当前问题不需要展开这点。需要避免把问题复杂化。核心逻辑应该是：crash是“系统猝死”，ramdump是“尸检报告”。ADSP作为专用处理器，它的crash会影响整个音频子系统，而dump出来的内存镜像包含ADSP专属的寄存器状态、音频流水线数据等，这点要区别于普通应用崩溃。用户可能隐含的深层需求是如何获取和分析这些dump。虽然ta没直接问，但最后生成的相关问题里应该包含这类实操方向，比如“如何触发ADSP ramdump”或“分析ADSP dump的特殊工具”。不过当前回复保持概念区分即可，补充的实际案例用高通平台的crash命令示例足够有说服力。对了，数学公式部分虽然用户没提，但保持LaTeX规范总是好的。不过这个回答里应该用不到复杂公式，顶多用$ADSP$表示芯片名称时加个格式？</think>理解ADSP Crash和ADSP Ramdump的区别，可以用一个简单的比喻： 1. **ADSP Crash（崩溃）** ➤ **相当于ADSP芯片“突然晕倒”或“停止工作”**。 - 当ADSP（音频数字信号处理器）运行时遇到严重错误（如软件缺陷、硬件冲突、内存溢出），它会立即停止所有工作。 - 表现：**音频功能失效**（如车载音响无声、通话中断）、系统日志报错（如`ADSP Fault Detected`）[^1][^2]。 - **本质：故障事件本身**。 2. **ADSP Ramdump（内存转储）** ➤ **相当于给“晕倒的ADSP”拍一张大脑快照**。 - 在ADSP崩溃瞬间，**自动将其内存中的全部数据（代码、变量、堆栈等）保存成文件**（如`DDRCS0_0.BIN`）[^1][^3]。 - 作用：工程师事后用工具（如`crash`命令）分析该文件，**定位崩溃原因**[^3][^4]。 - **本质：故障的“法医证据”**。 --- ### 关键区别总结 | **概念** | **ADSP Crash** | **ADSP Ramdump** | |----------------|---------------------------------|---------------------------------| | **是什么** | 故障事件（处理器停止工作） | 故障现场的数据快照（内存文件） | | **发生时机** | 错误触发时立即发生 | Crash后自动/手动触发保存 | | **内容** | 无实体（表现为功能中断） | 内存二进制文件（如`DDRCSx_x.BIN`） | | **用途** | 需通过日志/现象感知问题存在 | 用于分析崩溃根本原因[^3][^4] | --- ### 实际案例（高通平台）当QNX+Android车载系统的ADSP崩溃时： 1. **Crash发生**：音频服务停止，系统记录`ADSP subsystem failure`[^1][^2]。 2. **Ramdump生成**：自动保存内存文件（如`DDRCS0_0.BIN@0x80000000`）到存储区[^1][^3]。 3. **分析工具**：用`crash`工具加载文件，结合内核符号（`vmlinux`）分析崩溃点： ```bash crash vmlinux --kaslr=0x5d8800000 DDRCS0_0.BIN@0x80000000... ``` 输出可能定位到具体代码行（如`fast_smmu_map_page drivers/iommu/dma-mapping-fast.c:355`）[^4]。 --- ### 附：Ramdump分析流程 ```mermaid graph LR A[ADSP Crash发生] --> B{触发Ramdump} B -->|自动保存| C[内存文件 DDRCSx_x.BIN] C --> D[工程师用crash工具解析] D --> E[定位崩溃代码/数据] E --> F[修复Bug] ``` ---