How-to: 显示接口调试标准工作流程 (SOP)

Categories:

  少于1分钟  

How-to: 显示接口调试标准工作流程 (SOP)

阶段一：准备与信息收集 (Preparation & Info Gathering)

目标： 在写任何代码或DTS之前，确保你拥有所有必需的“图纸”和“说明书”。

  1. 获取硬件原理图 (Schematic): 这是你的依据。你需要知道：

    • 显示接口（MIPI/LVDS）连接到了主控SoC的哪个物理接口？(DSI0 还是 DSI1？)
    • 相关的控制引脚（RESET, POWER_ENABLE, BACKLIGHT_PWM）连接到了哪个GPIO或PWM控制器？
    • 接口的I2C总线连接到了主控的哪个I2C控制器？（用于触摸或配置桥接芯片）

  2. 获取目标设备“说明书” (Datasheet): 你的“屏幕”可能是物理屏，也可能是FPGA。

    • 如果是物理屏：获取屏幕模组的Datasheet。你需要从中找到：
      • display-timings (时序参数)：分辨率、刷新率、h/v porch、sync len等。
      • panel-init-sequence (初始化序列)：上电后需要发送的一长串DCS命令。
      • 接口参数：MIPI是几条lane？数据格式是RGB888还是RGB666？
      • 供电和复位时序要求：先上电还是先复位？延时多少毫秒？
    • 如果是FPGA：把FPGA工程师当作你的Datasheet。向他索要上述所有参数。FPGA的设计文档就是你的“说明书”。

  3. 获取平台参考资料 (Platform Reference):

    • SoC的TRM (技术参考手册)：理解VOP、DSI/LVDS控制器、Pinctrl等模块的工作原理。
    • SoC的SDK中的官方DTS示例：这是你最好的抄袭和参考对象，特别是对于VOP路由和Pinctrl配置。

阶段一产出：一个信息清单，包含了所有需要填入DTS的参数，以及明确的硬件连接关系。你同事的DTS在这里就属于“目标设备说明书”的一部分。

阶段二：DTS配置与编译 (DTS Configuration)

目标： 将阶段一收集到的信息，用DTS语言“翻译”出来，让内核知道如何驱动硬件。

  1. 配置Pin Control (pinctrl):

    • 在pinctrl节点中，为显示接口所需的所有引脚（数据线、时钟线、控制线）配置正确的功能复用。参考官方DTS示例的语法。

  2. 配置核心控制器 (&dsi0, &vop等):

    • 使能（status = "okay";）VOP、DSI/LVDS控制器、MIPI PHY等。

  3. 配置显示路由 (Routing):

    • 这是平台相关的关键一步。根据官方DTS示例，正确地connect VOP的输出和显示接口的输入。

  4. 创建Panel节点:

    • 在对应的接口节点下（如&dsi0），创建一个panel子节点。
    • 填入从Datasheet/FPGA工程师那里拿到的所有参数：compatible, reg, display-timings, dsi,lanes, dsi,format等。
    • 关键原则：如果是直连物理屏，把所有参数（包括初始化代码）都填上。如果是送给FPGA，只填FPGA需要的核心时序参数，删除所有物理相关的（背光、初始化代码、供电等）。

  5. 编译内核: 确保没有DTS语法错误。

阶段二产出：一个编译通过的、包含新显示配置的内核镜像（如boot.img）。

阶段三：底层验证 (Low-level Validation)

目标： 不依赖上层应用（Android/Linux桌面），验证内核驱动是否已经正确加载，并且物理信号是否已经发出。这是最关键的一步！

  1. 检查内核日志 (dmesg):

    • 烧录新内核，开机进入串口终端。
    • 输入 dmesg | grep -i panel：看你的panel驱动（如simple-panel）是否被成功probe（加载）。如果报错，日志会告诉你原因（如pinctrl没找到、时钟获取失败等）。
    • 输入 dmesg | grep -i dsi 或 dmesg | grep -i drm：查看DRM（Direct Rendering Manager）子系统和DSI控制器有没有报错。

  2. 检查Sysfs接口 (/sys):

    • ls /sys/class/drm/: 你应该能看到代表你屏幕的节点，比如card0-DSI-1。
    • cat /sys/class/drm/card0-DSI-1/modes: 查看内核识别到的分辨率和时序。这必须和你DTS里配置的一致！
    • cat /sys/class/backlight/.../brightness: 如果有背光，尝试写入亮度值，看屏幕背光是否有反应。

  3. 物理信号测量 (The Moment of Truth):

    • 使用示波器！ 这是你的眼睛。
    • 测量MIPI/LVDS的时钟线：
      • 是否有波形？有波形说明PHY和控制器至少在工作。
      • 波形频率是否正确？这能验证你的clock-frequency配置是否生效。
    • 测量MIPI/LVDS的数据线：
      • 是否有数据信号？（MIPI通常是突发的burst数据）
    • 如果此时屏幕/FPGA还没正常工作，但你已经在示波器上看到了正确的时钟和数据信号，那么恭喜你，RK侧的驱动配置大概率是正确的！问题已经转移到了屏幕/FPGA那一侧。

阶段三产出：确认内核驱动已加载，且SoC物理引脚上已有信号输出。如果这一步没完成，不要进入下一阶段。

阶段四：上层联调与调试 (High-level Integration & Debugging)

目标： 在底层信号OK的基础上，解决显示内容、颜色、偏移等问题。

  1. 验证显示内容:

    • 如果系统能进入桌面，看显示是否正常。
    • 如果黑屏，但底层信号已有，问题可能在：
      • panel-init-sequence错误或不完整（针对物理屏）。
      • 时序参数有细微偏差（比如某个porch值差了一两个像素）。
      • 数据格式不匹配（data-mapping for LVDS, dsi,format for MIPI）。
      • FPGA侧没有被正确配置（你的情况）。
      • 物理连接问题（线缆接触不良，差分线接反等）。

  2. 使用调试工具:

    • Rockchip的modetest工具：可以强制在某个显示器上显示彩条测试图，绕过上层复杂的UI系统，是验证DRM驱动和硬件通路的神器。
    • cat /dev/urandom > /dev/fb0: 向framebuffer设备灌入随机数据，看屏幕上是否有“雪花点”变化。有变化说明从内存到屏幕的通路是通的。
    • 调整DTS参数: 根据显示异常（如花屏、偏色、显示不全），微调display-timings、data-mapping等参数，重新编译，快速迭代。

阶段四产出：一个正常显示的屏幕或一个被FPGA正确接收和处理的视频流。

通过这套流程，你可以把一个“点亮屏幕”的模糊任务，分解成一个个清晰、可验证的小目标。每一步都有明确的入口条件和产出，从而系统性地定位问题，而不是凭感觉乱试。