当前位置：首页>Linux>linux 项目dts定制开发---不侵入原厂sdk 的代码

linux 项目dts定制开发---不侵入原厂sdk 的代码

2026-10-11 07:03:04

背景：

项目开发时从soc厂商那里拿到一个版本的sdk，后续有极大可能需要进版（原厂又解决了一些公共问题）。如果我们的修改入侵到原厂的代码里，就会导致后续进版sdk有很多的冲突项。

一、整体思路与好处

现状

SDK 的设备树在 sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/，其中 rk3572.dtsi（SoC 级）、rk3572-evb1-v10.dtsi SDK 维护板级设备树。
我们板子的设备树是 customers/common/board/ID_BD_RK3572_01A/rk3572-customer-v10-linux.dts，属于 customers/ 这一层（customers -> sdk/device/cvt 是 symlink，是我们自己的目录）。

核心做法：board dts `#include` SDK dtsi，只做"增量覆盖"

板级 dts 顶部：

/dts-v1/;#include"rk3572-evb1-v10.dtsi"/* SDK 公板 dtsi */#include"rk3572-linux.dtsi".../ {    compatible = "rockchip,rk3572-evb1-v10", "rockchip,rk3572";    model = "Rockchip RK3572 customer V10 Board";    ...                                /* 板子自己的新增节点放这里 */};

然后所有对 SDK 的差异都用 &label { ... } 引用 + 覆盖实现：删节点、删属性、改属性、加属性、加子节点。不动 SDK dtsi 一个字。

这样做的好处

SDK 升级冲突最小：SDK 进新版本时，rk3572.dtsi/rk3572-evb1-v10.dtsi 会变，但我们没改过它们，merge 时几乎不冲突。我们的定制全集中在 board dts 一个文件里，rebase 这个文件即可。
意图清晰：board dts 里出现的 &xxx 块，全是"和公板的差异"，review 一眼能看出这块板子和公板不同在哪。
可回退：把某个 &xxx 块注释掉，就回到 SDK 默认行为，便于对比排查。
同样适用于 kernel config：customer_defconfig.config 是一个 config 片段，叠加在 rockchip_linux_defconfig 上（CONFIG_customer_* 等），同样不碰 SDK defconfig，升级零冲突。

反例（不要这样做）：直接去 sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/rk3572-evb1-v10.dtsi 里改属性/删节点。这会污染 SDK，升级时整片冲突，且改了什么无迹可循。

二、构建链路（知道 dtb 从哪来）

customers/common/board/ID_BD_RK3572_01A/rk3572-customer-v10-linux.dts   ← 源（我们维护）        │  构建时拷贝（inode 不同，是 copy 不是 symlink）        ▼sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/rk3572-customer-v10-linux.dts        │  dtc 编译        ▼sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/rk3572-customer-v10-linux.dtb  ← 最终产物        │  打包进 boot.img / resource.img        ▼设备 /sys/firmware/devicetree/base/...

关键点：改了 customers/.../rk3572-customer-v10-linux.dts 后，必须重新走一遍"拷贝+编译+打包+烧录"。如果只编了一半或烧了旧 dtb，设备上跑的还是老的——这次排查就栽在这上面过（改了源码但烧的是改之前的 dtb，白排查一轮）。

三、四种常用定制操作

1. 改属性 / 加属性（`&label { ... }` 覆盖）

引用 SDK 已有节点，直接写新值。同名属性后写覆盖先写；新属性就是新增。

&usb_drd0_dwc3 {    dr_mode = "peripheral";          /* 覆盖 SDK 的 "otg" */    maximum-speed = "high-speed";    /* 新增 */    phys = <&u2phy0_otg>;            /* 覆盖：去掉 combphy0_psu，只留 USB2 */    phy-names = "usb2-phy";    snps,dis_u2_susphy_quirk;        /* 新增布尔属性 */    status = "okay";                 /* 覆盖 SDK 的 "disabled" */};

2. 删属性（`/delete-property/`）

在 &label { } 块里删 SDK 设的某个属性：

&u2phy0_otg {    /delete-property/ rockchip,typec-vbus-det;   /* 删公板的 type-C VBUS 检测 */    status = "okay";};&vbus5v0_typec {    /delete-property/ gpio;    /delete-property/ pinctrl-names;    /delete-property/ pinctrl-0;};

注意：/delete-property/ 删一个本来就不存在的属性，dtc 静默忽略不报错（不会编译失败）。

3. 删节点（`/delete-node/`）

两种写法，别搞混（这是高频坑）：

(a) 顶层按 label 引用删（label 前要加 &）：

/delete-node/ &wireless_bluetooth;/delete-node/ &rk730_es7210_sound;

放在 dts 顶层（不在任何 &node {} 块内）。&label 引用的是节点的 label。

(b) 父节点内按"子节点名"删（用节点的 unit name，不是 label，且不加 &）：

&mdio1 {    /delete-node/ phy@1;          /* ✓ 删名为 phy@1 的子节点 */    yt8522c_phy: phy@0 {        compatible = "ethernet-phy-ieee802.3-c22";        reg = <0x0>;    };};

反面教训：在 &mdio1 { /delete-node/ rgmii_phy; } 里用裸 label rgmii_phy（既不是 &label 也不是节点名 phy@1），dtc 找不到名为 rgmii_phy 的子节点，静默不删，结果 rgmii_phy: phy@1 (reg=<1>) 还在 mdio1 里，注册时报 MDIO device at address 1 is missing。判断依据：报哪个 address，就是哪个 reg 的子节点没删干净。

4. 加节点

在已有父节点下加子节点，或顶层 / 下加新节点：

&mdio0 {    yt8522c_phy: phy@3 {        compatible = "ethernet-phy-ieee802.3-c22";        reg = <0x3>;             /* PHY 的 MDIO 地址，必须有 */                           };};

顶层加节点（board 自己的功能，SDK 没有的）：

/ {    net_detect {        compatible = "customer,net-detect";        detect-gpios = <&gpio0 RK_PD1 GPIO_ACTIVE_LOW>,                       <&gpio0 RK_PD2 GPIO_ACTIVE_LOW>;    };};

四、验证最终 dtb 是否符合需求（三处对照）

改完源码 → 编译 → 烧录 → 设备运行，这四个环节的 dtb 必须一致。排查时三个地方都要看，任何一个不对都白搭。

1. 反编译构建产物 dtb（编译后、烧录前必查）

# 确认改动真的进了 dtbdtc -I dtb -O dts \  sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/rk3572-customer-v10-linux.dtb \  > /tmp/out.dts 2>/dev/null# 看具体节点sed -n '/usb@24000000 {/,/};/p' /tmp/out.dts | grep -E "phys|phy-names|dr_mode|maximum-speed"# 看某属性是否还在（删了应查不到）grep -n "rockchip,typec-vbus-det" /tmp/out.dts# 看某节点是否还在grep -n "rgmii_phy\|phy@1" /tmp/out.dts

2. 设备运行中 dtb（烧录后、在板子上查）

# 属性是否存在（删了的应该 No such file）ls /sys/firmware/devicetree/base/soc/syscon@26054000/usb2-phy@0/otg-port/rockchip,typec-vbus-det# 期望: No such file or directory# 列某节点下所有属性ls -l /sys/firmware/devicetree/base/soc/usb@24000000/# 读字符串型属性值（status、compatible、dr_mode、phy-names）strings /sys/firmware/devicetree/base/soc/usb@24000000/dr_modestrings /sys/firmware/devicetree/base/soc/usb@24000000/status# 读数值型属性（reg、phys 等是二进制，用 hexdump）hexdump -C /sys/firmware/devicetree/base/soc/usb@24000000/phys

属性文件大小为 0 是正常的（布尔属性如 snps,dis_u2_susphy_quirk 就是 0 字节空文件，存在即生效）。

3. 对照源码 dts（确认源就是对的）

grep -n "typec-vbus-det\|orientation-switch\|combphy0_psu\|/delete-" \  customers/common/board/ID_BD_RK3572_01A/rk3572-customer-v10-linux.dts

三处一致才算数：源码 dts 有改 ✓ → 构建产物 dtb 反编译出改了 ✓ → 设备 /sys/firmware/devicetree 反映出改了 ✓。任何一处断层（最常见是"编了没烧""烧了旧 dtb"），现象就会和源码对不上，别急着怀疑驱动，先查这三处。

4. tmp 文件排查

rk平台在编译完设备树后，会在 sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/ 目录下有中间文件保留

注意：默认是隐藏文件，需要在文件管理器里面打开隐藏文件

五、典型场景对照表

需求	写法	位置
改某节点属性	`&label { prop = <val>; }`	任意位置
删某属性	`&label { /delete-property/ prop; }`	`&label` 块内
删某节点（按 label）	`/delete-node/ &label;`	顶层
删某子节点（按节点名）	`&parent { /delete-node/ child@addr; }`	父节点块内
加子节点	`&parent { newnode: child@x { ... }; }`	父节点块内
加顶层节点	`/ { newnode { ... }; };`	顶层

六、一页速查（排查 dtb 没生效）

# A. 源码改对没？grep -n "<关键字>" customers/common/board/ID_BD_RK3572_01A/rk3572-customer-v10-linux.dts# B. dtb 编进去没？（mtime 应晚于源码 dts）stat -c '%y %n' customers/common/board/ID_BD_RK3572_01A/rk3572-customer-v10-linux.dts \  sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/rk3572-customer-v10-linux.dtbdtc -I dtb -O dts \  sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/rk3572-customer-v10-linux.dtb 2>/dev/null \  | grep "<关键字>"# C. 设备上生效没？（adb connect 后）ls /sys/firmware/devicetree/base/soc/<node>/<property>   # 删了的应 No such filestrings /sys/firmware/devicetree/base/soc/<node>/<str-prop>

A→B→C 任意一环断了，现象就和源码对不上。先修通这条链，再去看驱动/硬件。

附：涉及路径速记

板级 dts 源：customers/common/board/ID_BD_RK3572_01A/rk3572-customer-v10-linux.dts
SDK dtsi（不改）：sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/rk3572.dtsi、rk3572-evb1-v10.dtsi
构建产物 dtb：sdk/kernel-6.12/arch/arm64/boot/dts/rockchip/rk3572-customer-v10-linux.dtb
板级 kernel config 片段（同理不改 SDK defconfig）：customers/common/board/ID_BD_RK3572_01A/customer_defconfig.config
设备运行 dtb 查看：/sys/firmware/devicetree/base/soc/...

本文来自网友投稿或网络内容，如有侵犯您的权益请联系我们删除，联系邮箱：596563534@qq.com 。

核心做法：board dts `#include` SDK dtsi，只做"增量覆盖"

这样做的好处

二、构建链路（知道 dtb 从哪来）

三、四种常用定制操作

1. 改属性 / 加属性（`&label { ... }` 覆盖）

2. 删属性（`/delete-property/`）

3. 删节点（`/delete-node/`）

4. 加节点

四、验证最终 dtb 是否符合需求（三处对照）

1. 反编译构建产物 dtb（编译后、烧录前必查）

2. 设备运行中 dtb（烧录后、在板子上查）

3. 对照源码 dts（确认源就是对的）

五、典型场景对照表

六、一页速查（排查 dtb 没生效）

附：涉及路径速记

linux 项目dts定制开发---不侵入原厂sdk 的代码

一、整体思路与好处

现状

最新文章

热门文章

随机文章

linux 项目dts定制开发---不侵入原厂sdk 的代码

一、整体思路与好处

现状

核心做法：board dts #include SDK dtsi，只做"增量覆盖"

这样做的好处

二、构建链路（知道 dtb 从哪来）

三、四种常用定制操作

1. 改属性 / 加属性（&label { ... } 覆盖）

2. 删属性（/delete-property/）

3. 删节点（/delete-node/）

4. 加节点

四、验证最终 dtb 是否符合需求（三处对照）

1. 反编译构建产物 dtb（编译后、烧录前必查）

2. 设备运行中 dtb（烧录后、在板子上查）

3. 对照源码 dts（确认源就是对的）

五、典型场景对照表

六、一页速查（排查 dtb 没生效）

附：涉及路径速记

红黑树-Linux内核和Java HashMap为什么都选了它?

嵌入式Linux--LinuxIIO驱动调试技巧

最新文章

热门文章

随机文章

核心做法：board dts `#include` SDK dtsi，只做"增量覆盖"

1. 改属性 / 加属性（`&label { ... }` 覆盖）

2. 删属性（`/delete-property/`）

3. 删节点（`/delete-node/`）