SoC 板级 Bring-up 工程手册

Thu, 30 Jul 2026 00:00:00 +0000

从硬件三要素，到用证据逼出根因。

这份手册是我在 RK3568、RK3588 上做过 GMAC、显示（LVDS/MIPI/HDMI）、USB、PCIe 等多个模块的 bring-up 之后，回头总结出来的一套东西。它已经脱离了任何单一模块，是我下次面对一颗陌生 SoC、一个陌生外设时，脑子里第一时间会浮现的操作主线。

我把以前拆散写过的几篇笔记（电源/时钟/复位、硬件分层架构、dts 三级节点、显示 SOP）全部融进了这条主线——因为它们本来就是同一条脉络上被拆下来的零件。

一、先讲两条底层认知（心法）

在讲具体怎么做之前，得先说清楚我对 bring-up 这件事本身的两个判断。这两条决定了后面所有操作的取舍。

1. bring-up 的精华不是「调通」，是「找到整条事情的脉络」

即便你把硬件调通了，若只是碰巧，或者不改 dts、不动驱动代码、甚至是不敢改，那也没意义。调通只是结果，能说清楚它为什么通、为什么之前不通，才是本事。

尤其是失败的时候——成功了大家都默认自己做得对；但失败了，多数时候也是猜测：猜测应该是哪里、感觉是哪里，基本上找到一个不合理的地方，所有人就都拥上去说是这个导致的。

但 kernel 已经做得极其复杂，一层一层封装包裹，控制器一般是厂商外面买的 IP，所以又在原厂基础上做一层自己的 wrapper，一层一层调用，就得一层一层去解包。这个层层解包的过程，本身就足以劝退一个刚接触这个硬件模块的人。所以单拿一个显眼的错误就说自己找到了根源，是不牢靠的。

2. bring-up 的根本矛盾：有限的时间 vs 近乎无限的打击面

bring-up 总是很赶。不是因为没有时间预算，而是因为你面对的可能是浩瀚 kernel 里的任何一个问题（Linus 说过，如今 3500 万行以上的 kernel，已经没人能完全精通了）。而你不可能现场把内核学精通了再回来调。

所以这是一个矛盾体：

有限的时间 vs 近乎无限的打击面（内核）。

因此，bring-up 最重要的能力，不是「懂很多」，而是定位问题、缩小打击面的能力。靠什么做到？靠脉络。下面这 7 步，就是我缩小打击面的主线。

二、脉络：7 步操作主线

这 7 步是有严格先后的。核心原则：假设越靠前的层越可能出问题，就越先排除它；每一步都尽量用最便宜的手段（读一个文件、测一个脚、加一条 printk）得到一个「通 / 挂」的二元结论，一层层往下逼。

第 1 步 · 以 SDK 为起跳点

SDK 本身是最佳起点。原厂给的 SDK 至少保证「能跑起来、不出 bug」，这是你唯一确定的地面。所有改动都从这个已知可用的基线出发，改坏了随时能退回来对比。先让原始 SDK 跑通，再谈改。

不靠猜：如何用 TRM 推导出 PCIe 模块的问题

Wed, 29 Jul 2026 00:00:00 +0000

这是我在 RK3588 上做 PCIe 3.0 bring-up 时的一段真实调试经过。调试的结果是硬件出问题，对我来说，这比把模块调通更有意义，因此出错时自己被倒逼反复的死抠每一个路径上遇到的技术细节，直到完成，比起轻松的调通，其实我对rk3588的pcie模块理解得更深。重要的是：整个过程里，我每一步都拿得出证据，说清楚"卡在哪、为什么卡、下一条路该往哪走"。

这篇文章的前 70% 是第一人称的时间线复盘（我怎么一步步逼近根因、走过哪些弯路），后 30% 是我从这次经历里提炼出的反思。文末链到我沉淀的 SoC 板级 Bring-up 工程手册——这篇 PCIe 案例，就是那套方法在最深一层的实战。

0. 引子：CPU7 上的沉默

最初的sdk里，pcie30phy的mode就是NANBNB，即不聚合，port0和port1的2Lane不单独分开，乃是合并为一个独立的2Lanes通道使用。且pcie3x4是打开的。但是，一旦我修改了dts里的配置，板端起 PCIe 驱动之后，CPU7 的 rk-pcie kthread 触发 RCU stall，在此状态下，内核其实并未直接Panic卡死，每几十秒就会大段的打印cpu的信息, 这着实吓到我了，心想怎么样也不应该连bash都进不去吧。

rcu: INFO: rcu_preempt detected stalls on CPUs/tasks:
 7-....: (1 GPs behind) idle: 1c0
rcu: blocking rk-pcie thread on readl(dbi_base + 0x8bc)

[ 63.970433] CPU7 online:1
[ 63.970443] EL2(NS) PC: <0xffffffc00874c2c4> dw_pcie_read+0x44/0xc0

起初看到这样的东西，一头雾水，但求助AI,很快就直到核心的信息是告诉我们cpu7上的任务卡住了：也就是 “ dw_pcie_read+0x44/0xc0”

1. 第一步：找出dw_pcie_read()是被谁调用？

我的第一个任务就是去搞清楚，是谁调用了dw_pcie_read()函数，透过全篇kernel的搜索，写下了它的调用栈：

rk3588-linux_20250321/kernel/drivers/pci/controller/dwc/pcie-designware.c
int dw_pcie_read(void __iomem *addr, int size, u32 *val)
 ↓
rk3588-linux_20250321/kernel/drivers/pci/controller/dwc/pcie-dw-rockchip.c
static u32 rk_pcie_readl_atu(struct dw_pcie *pci, u32 reg)
↓

enter branch A:

static u32 rk_pcie_readl_ob_unroll(struct dw_pcie *pci, u32 index, u32 reg)
↓
rk_pcie_prog_outbound_atu_unroll()
↓
static void rk_pcie_prog_outbound_atu(struct dw_pcie *pci, int index,int type, u64 cpu_addr, u64 pci_addr, u32 size)
↓
static int rk_pcie_ep_outbound_atu(struct rk_pcie *rk_pcie,phys_addr_t phys_addr, u64 pci_addr,size_t size)
↓
static int rk_pcie_ep_atu_init(struct rk_pcie *rk_pcie)

enter branch B:

static u32 rk_pcie_readl_ib_unroll(struct dw_pcie *pci, u32 index, u32 reg)
↓
rk_pcie_prog_inbound_atu_unroll()
↓
rk_pcie_prog_inbound_atu()
↓
rk_pcie_ep_inbound_atu()
↓
rk_pcie_ep_atu_init()

branch A merged with Branch B

↓
(rockchip_dw_pcie_resume) 或
static int rk_pcie_add_ep(struct rk_pcie *rk_pcie)
↓
static int rk_pcie_really_probe(void *p)
↓
static int rk_pcie_probe(struct platform_device *pdev)
↓
static struct platform_driver rk_plat_pcie_driver = {
	.driver = {
		.name = "rk-pcie",
		.of_match_table = rk_pcie_of_match,
		.suppress_bind_attrs = true,
		.pm = &rockchip_dw_pcie_pm_ops,
	},
	.probe = rk_pcie_probe,
};

追到最后的rk_plat_pcie_driver我已经完全清楚了。就是在pcie设备进行probe的阶段，发生的问题。虽然对内核并不算很熟悉，但是内核里的驱动正是靠这种塞满函数指针的结构体变量来进行注册的。

Debug on Potter的个人笔记