1. 8155车机系统硬件平台识别实战搞车机开发的朋友们应该都深有体会每次拿到一个新硬件平台最头疼的就是确认这到底是个什么配置。我当年第一次接触8155平台时光是为了确认硬件版本就折腾了大半天。今天我就把实战中总结的三板斧分享给大家保证你5分钟内就能搞定平台识别。先说说为什么要这么麻烦地确认硬件平台。8155作为高通的主力车规级芯片其实细分了多个硬件版本。比如Auto Star和Auto Air虽然都用8155但外设配置、电源管理方案都有差异。你要是拿着Auto Star的配置去调Auto Air的设备那真是要踩坑踩到怀疑人生。第一招看QNX启动日志车机开机时盯着点QNX的启动界面关键信息都在这里。比如你会看到这样的内容CDT Version:3,Platform ID:25,Major ID:1,Minor ID:0,Subtype:0这几个数字就是硬件平台的身份证号。Platform ID25对应8155系列后面的Major和Minor ID决定了具体型号。我建议直接用手机拍个照免得手忙脚乱记错数字。第二招查XML配置文件到代码仓库里找到这个文件路径qupv3/config/855/QUPAC_Private.xml。用文本编辑器打开后搜索PLATFORMS_LIST你会看到这样的配置段var_seq namePLATFORMS_LIST typeDALPROP_DATA_TYPE_UINT32_SEQ 25, 0, // Auto Star Platform 25, 1, // Auto Air Platform 25, 2, // Auto Alcor Platform end /var_seq这里25对应Platform ID后面的数字就是Subtype。对照之前QNX看到的Subtype:0就能确定这是Auto Star平台。有个小技巧用Notepad的XML插件格式化代码查看起来会更清晰。第三招确认设备树路径根据前面得到的信息去查apps/qnx_ap/target/filesets/dtsi/sdm8155.dtsi文件。我建议直接用VS Code全局搜索ADP_Star很快就能定位到类似这样的配置board_name ADP_Star_v1.0.0;这个board_name就是最终要确认的硬件平台名称。记得检查版本号v1.0.0和v1.1.0可能在GPIO定义上有差异。2. 设备树配置全流程解析确认完硬件平台接下来就是重头戏——设备树配置了。说实话我第一次搞8155设备树时被那一堆dtsi文件绕得头晕。后来发现只要掌握几个关键点其实也没那么可怕。2.1 进入设备树目录先用adb shell进入车机Android系统切换到/proc/device-tree目录。这个目录下的结构看起来是这样的. ├── aliases ├── chosen ├── compatible ├── model ├── name └── soc别被这么多文件吓到我们主要关注model和compatible这两个。直接cat model就能看到芯片型号cat model # 输出Qualcomm Technologies, Inc. SA8155 Single LA Virtual Machine2.2 提取设备树信息这里我推荐用grep命令快速定位关键信息grep -nr Qualcomm Technologies, Inc. SA8155 Single LA Virtual Machine这个命令会在整个文件系统搜索包含芯片型号的文件通常能找到设备树源文件.dts的路径。找到后记得复制出来备份我吃过没备份直接改配置的亏...2.3 解析设备树映射用Python脚本解析设备树是最稳妥的方法。准备好deviceTreeMap.py脚本高通代码库里有执行python3 deviceTreeMap.py -f sa8155-vm-la.dts这个脚本会生成设备树映射关系表特别要注意I2C、SPI这些总线的配置。比如常见的I2C设备树会指向sm8150-qupv3.dtsi文件这个文件里定义了所有I2C控制器的寄存器地址和中断号。2.4 验证设备树改完配置后千万别直接刷机先用dtc工具验证语法dtc -I dts -O dtb -o test.dtb sa8155-vm-la.dts没有报错再刷入设备。建议准备个USB转串口工具万一设备树错了还能通过串口救砖。这个坑我踩过三次都是血泪教训啊3. QNX系统日志分析技巧QNX的日志系统就像个宝藏但需要正确的打开方式。很多开发者抱怨QNX日志难懂其实只是没找对方法。这里分享几个我总结的日志分析秘籍。3.1 关键日志抓取QNX启动时按CtrlAltShiftL可以调出完整日志。重点看这几类信息CDT信息前面提到的硬件平台标识设备树加载日志搜索devicetree关键词外设初始化状态特别是I2C、SPI总线的枚举情况3.2 日志过滤技巧用slay命令杀掉系统logger后用以下命令重新启动并过滤日志slay slogger slogger -b 2M -f /tmp/log.txt tail -f /tmp/log.txt | grep -E CDT|devicetree|i2c这个组合拳可以大幅提升日志分析效率。2M的缓冲区足够存几分钟的日志grep的正则表达式可以根据需要调整。3.3 常见错误解析看到这些日志要特别注意[WARNING] i2c_qup: probe failed这通常表示设备树里的I2C配置与硬件不符。我的经验是先去查sm8150-qupv3.dtsi里对应控制器的clock-frequency参数8155平台常见的是400kHz和1MHz两种速率。再比如这种错误[ERROR] gpiochip_add_data: failed to add gpio chip大概率是GPIO编号冲突了。打开sdm8155.dtsi检查gpio-ranges属性确认GPIO bank划分是否正确。有个取巧的方法直接搜索出问题的GPIO编号比如gpio120。4. 设备树调试实战案例去年给某车企调试8155车机时遇到个典型问题触摸屏时灵时不灵。最后发现是设备树里I2C配置有问题这个案例特别有代表性分享给大家避坑。4.1 现象分析触摸屏在冷启动时工作正常但系统休眠唤醒后经常失效。用示波器抓I2C波形发现唤醒后没有SCL时钟。4.2 设备树排查检查sm8150-qupv3.dtsi中触摸屏控制器的配置i2ca94000 { status okay; clock-frequency 400000; pinctrl-0 qup_i2c9_default; touchscreen38 { compatible focaltech,ft5436; reg 0x38; interrupt-parent tlmm; interrupts 125 0x2008; }; };发现问题出在pinctrl配置上qup_i2c9_default这个引脚组在休眠唤醒后没有重新初始化。4.3 解决方案在设备树中添加pinctrl-1配置pinctrl-0 qup_i2c9_default; pinctrl-1 qup_i2c9_sleep; pinctrl-names default, sleep;同时要确保在板级dts里正确定义了qup_i2c9_sleep这个引脚组。改完后记得用dtc验证语法然后分步测试先测试冷启动功能再测试短时间休眠唤醒10秒内最后测试长时间休眠30分钟以上4.4 经验总结8155平台的I2C设备树有这几个坑要注意clock-frequency要根据外设实际支持速率设置中断触发方式要用0x2008边沿触发高电平有效必须配置sleep状态的pinctrlreg地址要用16进制表示类似的SPI、UART等外设也要检查休眠唤醒相关的配置。建议修改设备树前先备份原文件我习惯用日期命名备份文件比如sa8155-vm-la.dts.20230801。