第二类：嵌入式 BSP（板级支持包）

一句话

做嵌入式 BSP：从 datasheet 第一页读到最后一页，把每个 bug 写成 milestone，下次直接复用。

这是什么 / 不是什么

这是：我关于"嵌入式系统底层开发"的工作方法论 + 两个核心实战案例。 不是：某个具体芯片的入门教程、某个 SoC 的移植手册。

如果你正在招一个能做 BSP 的工程师，看完这一页 + 两个核心 case study 的链接，你应该能判断这个人是不是值得面。

方法论

1. TRM 阅读法（不是从头读到尾）

TRM 上千页，从头读到尾几乎不可能。我的做法：

1. 先看时钟表（Clock Overview）。每个模块有几根时钟、源头在哪里、有没有内部 PLL——这一张表决定 80% 的"为什么不通"。
2. 再看寄存器表（Register Description）。只读和当前 bug 相关的章节，但顺手把 chapter 里所有寄存器扫一遍名字。
3. 最后看电源域（Power Domain）。看哪些模块受哪个 PD 控制、reset 来源是什么。

好处：对一个 SoC 做 1-2 次 debug 之后，下次遇到同 SoC 其他子系统 bug，时钟表 + 寄存器表 + 电源域这三张图就能立刻定位 80% 的问题。

2. Debug 三角：代码 + log + 系统结构图

任何一个"为什么挂"的问题，我用三个证据来源交叉验证：

• 代码分析：grep kernel source，看 call stack 走的哪条路径
• 实测 log：printk / devmem / clk_summary / devtree 反证猜测
• 系统结构图：让 AI 帮我画硬件模块框图，反推"数据从哪来到哪去"

三个里至少两个对得上才下结论。单一证据的猜测不下结论。

3. 每个 bug 写成 milestone

参考 PKB 里的 milestones-pcie 格式：

MS-<ID>-<slug>
├─ Date
├─ Context（为什么做这一步）
├─ Method（具体动作 + 关键代码引用）
├─ Result（原始 log 摘录）
├─ Interpretation（排除了什么、锁定了什么）
└─ Next（下一步动作）

好处：下次遇到类似问题，milestone 是直接复用的，不从零开始。

实战案例

案例 1 · RK3568 平台 bringup

→ 查看完整 portfolio

RK3568 SoC 启动到用户态全流程：bootrom → ATF → u-boot → kernel → rootfs。涉及 pinctrl、clock、regulator、PMIC 各子系统初始化。

案例 2 · RK3588 PCIE PHY/PLL 时钟域调试

→ 配套长文：不靠猜：如何用 TRM 推导出 PCIe 模块的问题

7 天解谜 readl() 挂死。从"沉默"信号 + ARM64 ldr 语义出发，用 APB 通 + DBI 挂的对比实验 + TRM 三行原文 + 时钟表，把 hang 锁定到 PHY PLL 时钟域。

亮点：这一个 case 完整实践了"TRM 阅读法"+“Debug 三角”+“milestone 沉淀"三套方法论。如果你只读一个案例，读这个。

我用什么工具

• DTS：device tree 是"硬件的另一种说明书”
• printk：最朴素的 debug，但配合 tag 前缀能立刻 grep
• clk_summary (/sys/kernel/debug/clk/clk_summary)：CCF 输出，看时钟是否真的开起来
• devmem / devmem2：从 userspace 戳寄存器
• devtree (/proc/device-tree)：运行时 DTS
• 反汇编：当 source 跟 binary 不一致时（CONFIG_* 关闭、宏展开不同），直接 objdump

推荐阅读

• ARM AMBA AXI / APB Spec — 总线协议层
• PCI Express Base Spec — PCIe 协议层
• Rockchip RK3588 TRM（公开可查）
• Synopsys DesignWare PCIe Controller Databook（NDA，部分内容可从 kernel source 反推）
• Linux kernel source: drivers/pci/controller/dwc/