RK3568平台BSP构建 on Potter的个人笔记

RK3568平台 I2S的接口调试与dts配置

Wed, 15 Oct 2025 00:00:00 +0000

1. 项目目标

本次任务的核心目标是在 RK3568 平台上，成功使能并调试多个I2S接口（I2S1, I2S2, I2S3），以实现与外部设备（如FPGA）的数字音频数据通信。具体包括：

配置I2S1和I2S3为音频输出 (Playback)。
配置I2S2为音频输入 (Capture)。

2. 调试主线与过程

整个调试过程遵循“硬件分析 -> DTS配置 -> 命令行测试 -> 问题定位与解决”的清晰脉络。

前期准备 - 硬件资源分析:
- 首先，对RK3568 SoC的I2S硬件资源进行梳理，明确了I2S0/1/2/3控制器的基本功能和用途（如I2S0用于HDMI，I2S1/2/3为通用）。
- 将DTS中的I2S控制器节点（i2s@fe4...）与产品原理图上的GPIO引脚进行了一一对应，为后续的pinctrl配置打下了坚实基础。
中期实施 - DTS配置与声卡注册:
- 使用 simple-audio-card 驱动模型来“链接”SoC的I2S控制器（CPU DAI）和一个虚拟的 dummy-codec（Codec DAI），从而在ALSA框架下注册了三张独立的声卡。
- 分别为card 1 (I2S1, output), card 2 (I2S2, input), card 3 (I2S3, output) 编写了DTS节点。
后期验证 - 系统性测试与问题发现:
- 使用 aplay -l 和 arecord -l 命令，成功验证了三张声卡均已在系统中注册。
- I2S1 (Output): 使用 speaker-test -D hw:1,0 ... 进行测试，设备工作正常，无报错。
- I2S2 (Input): 使用 arecord -D hw:2,0 ... 进行测试，命令按预期“挂起”等待外部时钟，符合I2S Slave模式的正确行为。
- I2S3 (Output): 使用 speaker-test -D hw:3,0 ... 进行测试，发现严重问题：设备虽能打开，但持续抛出 Write error: -32, Broken pipe 错误。

3. 核心知识学习与沉淀

在调试过程中，对Linux音频子系统和DTS进行了系统性的学习。

RK3568平台USB OTG端口功能调试

Wed, 15 Oct 2025 00:00:00 +0000

项目概述

背景: 在基于Rockchip RK3568的定制化项目中，基于公版SDK, 重新梳理板上的USB接口，并解决板载的USB 3.0 OTG (Type-A) 端口在默认BSP配置下，无法正常识别U盘等Host模式设备。

我的职责与贡献: 作为项目的BSP工程师，我独立负责诊断并解决此USB功能性问题。我的核心贡献在于：

执行了系统性的问题排查，覆盖了从硬件原理图核对，功能确认，故障分析，到内核设备树（dts）代码编写调试和sysfs运行时状态分析以及性能基线测试的详细排查。
主导并实施了解决方案：根据产品的硬件原理图，验证两个USB-A口和一个USB-C口的工作情况。并通过修改设备树(DTS)，定下解决方案：将usbdrd_dwc3控制器的dr_mode由"otg"强制修改为"host"。
精确定位了问题根源：OTG端口的ID引脚在当前硬件设计下并不存在，导致控制器无法自动检测plug-in，因此无法切换Host/Device模式。
完成了性能与功能的完整验证，确保修改后的端口不仅能稳定识别设备，其数据传输速率也达到了USB 3.0标准。
将整个调试过程和技术分析沉淀为详细的技术文档，为未来类似问题提供了清晰的解决范例。

我的方法论：嵌入式外设调试流程

本次调试遵循了一套由表及里、从软件到硬件的标准化诊断流程：

文档与电路功能分析:
- 研读RK3568 TRM，理解其USB子系统架构（2个USB3控制器、OHCI/EHCI控制器、Combo PHY等）。
- 核对硬件原理图，确认OTG端口的物理连接，特别是ID和VBUS引脚。
- 梳理两A（USB-A）一C（USB-C）的数据流走向
设备树(DTS)与驱动映射:
- 深入分析rk3568.dtsi等芯片级设备树文件，梳理usbdrd30 (OTG)、usbhost30 (Host)、usb2phy等核心节点之间的配置和关系。
- 理清控制器与PHY之间的phys引用关系，并记录汇总成表格。
运行时状态诊断:
- 利用sysfs下的extcon接口 (/sys/class/extcon/extcon0)，实时查看内核感知的OTG端口状态（USB-HOST=0），印证了其未进入Host模式的猜想。
- 回到硬件原理图，研究USB-A/mini/micro/C四种接口的插拔原理，寻找解决方案。
方案实施与验证:
- 在板级DTS中，创建&usbdrd_dwc3的覆盖节点，将其dr_mode强制设为"host"。
- 重新编译并烧录固件，再次使用hdparm进行测试，验证问题已解决。
- SOC端USB作为主，则拒绝一切主设备的接入，由SOC端供电，因此，将固件升级（主设备典型应用）安排到外部按键方式触发进入Maskrom模式来进行
- 系统成功加载后，该USB-A口则作为普通host口使用。
技术总结和文档输出:
- 仔细梳理SoC 板级 Bring-up 工程手册里的硬件分层数据流模型，在项目结尾终于成稿。
- 更新 dts 调试的心得，一并沉淀进SoC 板级 Bring-up 工程手册的「从 dts 入手」一节

项目成果

功能修复: OTG端口现可稳定识别U盘及其他USB Host设备。
性能达标: 修复后，使用hdparm -t /dev/sda测试，端口读取速度恢复至 ~48MB/s，符合USB 3.0标准。
方案固化: 最终的DTS修改被合入产品代码库，成为该硬件的标准化配置。
文档沉淀: 完整的调试过程、代码分析和相关资料被整理归档。

技术栈与工具

硬件平台: Rockchip RK3568 SoC
软件环境: Linux Kernel 5.10, Buildroot
核心技术: Device Tree (DTS), USB 2.0/3.0 Subsystem, OTG, XHCI/EHCI/OHCI, Kernel extcon Framework
调试工具: hdparm, sysfs, dmesg, 串口调试

RK3568平台MIPI转eDP芯片LT8911EXB Bring-up与验证

Fri, 26 Sep 2025 00:00:00 +0000

项目总结：Rockchip RK3568 平台 MIPI-DSI 转 eDP 接口调试与验证

作者: Potter White
日期: 2025年9月
项目类型: Rockchip, Bring-Up, Linux Kernel Driver, Device Tree, I2C

1. 项目概述 (Project Overview)

背景 (Situation): 在一个基于 Rockchip RK3568 SoC 的定制化项目中，需要将 MIPI-DSI 视频信号通过 Lontium LT8911EXB 桥接芯片转换为 eDP 信号，以驱动一块 eDP 接口的显示屏。在初始的 BSP (Board Support Package) 集成后，显示屏未能正常点亮，内核日志（dmesg）中也未出现 LT8911EXB 相关驱动的加载信息。

我的职责与贡献 (My Role & Contributions): 作为项目的 BSP 工程师，我负责从硬件原理到内核驱动的全链路调试，以实现该显示通路的功能 Bring-up。我的核心贡献包括：

执行了系统性的硬件健康检查，验证了 LT8911EXB 芯片工作的基本条件，包括电源、时钟和复位电路。
深入分析了 Linux 设备驱动模型，厘清了设备树 (DTS)、内核驱动与硬件之间的交互与触发机制。
精确定位了驱动加载失败的根本原因：设备树中 I2C 地址与 GPIO 属性的配置与驱动代码及硬件规范不符。
主导并实施了设备树的修正方案，成功使内核驱动与硬件设备匹配，并正确加载。
沉淀了调试过程中的关键知识点，形成了包括 RC 电路、I2C 地址表示法、示波器探头使用等在内的技术笔记，为团队知识库做出了贡献。

2. 我的方法论：嵌入式外设 Bring-up 诊断流程

本次调试过程遵循了一套从硬件到软件、由表及里的系统性排查方法。这个流程旨在快速收敛问题范围，避免在不确定的方向上浪费时间。

RK3568平台显示子系统Bring-up与多接口调试

Mon, 18 Aug 2025 00:00:00 +0000

作者: Potter White
日期: 2025年8月

项目概述 (Project Overview)

背景 (Situation): 在一个基于Rockchip RK3568 SoC的定制化项目中，需要同时或独立地使能LVDS、MIPI-DSI和HDMI 2.0三大显示接口。其中，LVDS接口需向FPGA输出超越官方规格的1920x1080@30Hz视频流；HDMI与MIPI则需要绕过EDID检测，强制输出固定的1080p@60Hz信号。初始BSP中这些通路均未配置，需要从零开始进行Bring-up。

我的职责与贡献 (My Role & Contributions): 作为项目的BSP工程师，我独立负责整个显示子系统的Bring-up与对接任务。我的核心贡献在于通过对数据手册和内核源码的深度挖掘，完成了纯软件层面的配置与调试：

深入研究并梳理了RK3568显示子系统的数据流，清晰地描绘了从内存(Memory) -> VOP -> 各接口控制器 -> Combo PHY的完整硬件链路。
主导并完成了设备树(DTS)的精确配置，为LVDS、MIPI-DSI、HDMI三大接口正确设置了VOP路由、时序参数(Timings)以及PHY复用关系。
通过精密的DTS配置，成功驱动SoC物理层(PHY)输出正确的数字视频信号，为后续与FPGA的信号握手及HDMI显示器的点亮奠定了坚实基础。
成功实现了超越官方规格的视频流输出，在满足时钟频率限制的前提下，稳定实现了LVDS接口1920x1080@30Hz的信号输出，并获得FPGA端的成功接收。
将整个调试过程提炼并撰写成一套标准作业程序(SOP)与技术文档，为团队未来所有显示接口的调试工作提供了清晰、高效的指导框架。

我的方法论：显示接口调试标准作业程序 (SOP)

为了系统性地解决此类“点屏”或“信号对接”问题，我沉淀了一套分为四个阶段的SOP。该流程将模糊的调试任务分解为清晰、可验证的步骤，能够快速定位问题是在SoC软件配置侧，还是在对端设备(FPGA/屏幕)侧。

SoC 板级 Bring-up 工程手册: 其中「底层验证」一节，详细阐述了从信息收集到底层验证的四个关键阶段。
How-to: RK3568下强制HDMI的配置: 记录了如何通过修改驱动代码和DTS来强制HDMI连接状态与分辨率。
Rockchip显示子系统关键概念解析: 总结了VOP、DRM端口路由等核心概念。
LCDs(lvds) Bring-Up 数据流研究: 深入分析了LVDS从内存到物理引脚的完整数据链路。

项目成果与验证 (Results & Verification)

遵循SOP，我成功使能了RK3568的所有目标显示接口。所有配置均通过软件工具和对端设备的反馈得到验证。

内核模式验证 (modetest)

modetest工具的输出确认内核已为各个接口成功创建并应用了我们强制指定的模式，绕过了EDID检测。以下是LVDS接口的示例：

Connectors:
id encoder status name size (mm) modes encoders
172 171 connected LVDS-1 0x0 1 171
 modes:
 index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
 #0 1920x1080 29.41 1920 1968 2000 2040 1080 1083 1088 1111 66660 flags: nhsync, nvsync; type: preferred, driver
 ...

174 173 connected HDMI-A-1 0x0 1 173
 modes:
 index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
 #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: preferred
 ...

190 189 connected DSI-1 68x121 1 189
 modes:
 index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot
 #0 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: nhsync, nvsync; type: preferred, driver
 ...

结论: 内核DRM框架已按DTS预期工作，clock-frequency与时序参数均正确加载。HDMI与MIPI接口也通过类似方式得到验证。

RK3568平台千兆以太网控制器Bring-up与验证

Fri, 25 Jul 2025 00:00:00 +0000

作者: Potter White
日期: 2025年7月

项目概述 (Project Overview)

背景 (Situation): 在一个基于Rockchip RK3568 SoC的定制化产品开发项目中，我负责对板载的千兆以太网接口（GMAC1, ethernet@fe010000）进行初次的功能Bring-up。在初始BSP配置下，该网络接口未能被内核正确初始化，日志显示Cannot attach to PHY和Failed to reset the dma等错误。

我的职责与贡献 (My Role & Contributions): 作为项目的BSP工程师，我负责诊断并解决此底层软硬件集成问题。我的主要工作包括：

执行了端到端的系统性排查，覆盖了从物理电路到内核驱动的全链路。
精确定位了问题根源，将其归因于设备树（DTS）中关于GMAC1的时钟树、引脚功能（pinctrl）配置与硬件设计不匹配。
主导并实施了设备树的修正方案，成功使能网络接口并确保其稳定运行。
通过iperf进行了性能验证，确认网络吞-吐量达到千兆以太网的设计标准。
将调试过程沉淀为一套标准作业程序 (SOP)，用于指导未来类似外设的Bring-up工作。

我的方法论：嵌入式外设Bring-up标准作业程序 (SOP)

我总结了一套系统性的硬件Bring-up工作流。该流程将问题排查结构化，通过分阶段、多层次的验证，能够定位并解决从物理层到驱动层的部分复杂问题,并大量缩短调试时间。

第一部分：标准化移植流程 (Standard Porting Workflow)

此流程用于在硬件设计已知且大概率正确, 且串口功能稳定可用的情况下，进行设备树（DTS）和phy驱动调试。

感兴趣可以看我的日志: GMAC Bring Up Work Flow

第二部分：异常诊断清单 (Troubleshooting Checklist)

当标准化流程不成功，或怀疑硬件存在未知问题时，此清单提供了一个从物理层到控制层的系统性排查路径。

感兴趣可以看我沉淀的方法论: SoC 板级 Bring-up 工程手册

SOP流程图

graph TD
 %% === 定义与样式 ===
 classDef dark_main fill:#2c3e50,color:white,stroke:#8e9eab;
 classDef dark_debug fill:#4b3e58,color:white,stroke:#b8a3d3;
 classDef dark_decision fill:#27ae60,color:white,stroke:#88d1a1;
 classDef dark_result_ok fill:#16a085,color:white,stroke:#72d6c1;
 classDef dark_result_fail fill:#c0392b,color:white,stroke:#e69a93;

 %% === 主流程 (左侧) ===
 subgraph "标准化移植流程 (Standard Porting Workflow)"
 direction TB
 S[<b>开始</b>]:::dark_main
 A[<b>1. 硬件接口确认</b><br>GMAC0或GMAC1]:::dark_main
 B[<b>2. 时钟模式分析</b><br>25MHz与125MHz两种时钟的流向]:::dark_main
 C[<b>3. 设备树DTS适配</b><br>从瑞芯微的ModeConfig手册里节选正确dts配置]:::dark_main
 D[<b>4. 编译与验证</b>]:::dark_main

 S --> A --> B --> C --> D
 end

 %% === 决策点 (中央) ===
 F{"<div style='text-align:center'><i class='fa fa-question-circle'></i> <b>验证</b><br>网络是否正常工作?</div>"}:::dark_decision
 D --> F

 %% === 诊断流程 (右侧) ===
 subgraph "异常诊断锦囊 (Troubleshooting Checklist)"
 direction TB
 G["<div style='text-align:left; padding:10px;'><i class='fa fa-bolt'></i> <b>物理层健康检查 (L1)</b><br>- 电源 (Power Rails)<br>- 复位信号 (Reset Signal)<br>- 参考时钟 (Reference Clock)</div>"]:::dark_debug
 H["<div style='text-align:left; padding:10px;'><i class='fa fa-bullseye'></i> <b>控制通路验证 (L2)</b><br>- U-Boot 'mii read'<br>- Kernel 'sysfs' </div>"]:::dark_debug
 I["<div style='text-align:left; padding:10px;'><i class='fa fa-cogs'></i> <b>关键逻辑审查 (Logic Review)</b><br>- 硬件模式 (Strapping Pins)<br>- 时钟流向 (Clock Direction)</div>"]:::dark_debug

 G --> H --> I
 end

 %% === 成功/失败出口 ===
 SUCCESS[<b><i class='fa fa-check-circle'></i> 成功</b>]:::dark_result_ok
 FAILURE["<div style='text-align:left; padding:10px;'><i class='fa fa-undo'></i> <b>修正并迭代</b><br>根据诊断结果<br>返回<b>阶段3或4</b><br>重新适配DTS</div>"]:::dark_result_fail

 %% === 流程连接 ===
 F -- "是 (Yes)" --> SUCCESS
 F -- "否 (No)" --> G
 I --> FAILURE
 FAILURE -.-> C & D

项目成果与验证 (Results & Verification)

RK3568平台BSP构建 on Potter的个人笔记

RK3568平台 I2S的接口调试与dts配置

1. 项目目标

2. 调试主线与过程

3. 核心知识学习与沉淀

RK3568平台USB OTG端口功能调试

项目概述

我的方法论：嵌入式外设调试流程

项目成果

技术栈与工具

RK3568平台MIPI转eDP芯片LT8911EXB Bring-up与验证

项目总结：Rockchip RK3568 平台 MIPI-DSI 转 eDP 接口调试与验证

1. 项目概述 (Project Overview)

2. 我的方法论：嵌入式外设 Bring-up 诊断流程

RK3568平台显示子系统Bring-up与多接口调试

项目概述 (Project Overview)

我的方法论：显示接口调试标准作业程序 (SOP)

项目相关技术文档 (Project-Related Technical Documents)

项目成果与验证 (Results & Verification)

内核模式验证 (modetest)

RK3568平台千兆以太网控制器Bring-up与验证

项目概述 (Project Overview)

我的方法论：嵌入式外设Bring-up标准作业程序 (SOP)

第一部分：标准化移植流程 (Standard Porting Workflow)

第二部分：异常诊断清单 (Troubleshooting Checklist)

SOP流程图

项目成果与验证 (Results & Verification)