SoC Family Architecture：一个 Zephyr BSP 如何支撑一整个 SoC 家族现在必须解决一个更现实的问题：如果公司不是只有一个 SoC，而是有 SoC-A、SoC-B、SoC-C……怎么办？真正成熟的 BSP 不应该：SoC-A → 一套代码 SoC-B → 复制一份 SoC-C → 再复制一份而应该形成：Company SoC Family │ ┌─────────────┼─────────────┐ │ │ │ SoC-A SoC-B SoC-C │ │ │ Board-A Board-B Board-C更重要的是：Common Architecture │ ┌───────────────┼────────────────┐ │ │ │ Common HAL Common Drivers Common SoC │ │ │ ┌────┴────┐ ┌───┴────┐ ┌───┴────┐ A B A B A B这就是今天这一篇的核心：如何设计一个"可扩展的 SoC Family BSP Architecture"。1. 先看一个真实世界的问题假设公司有三个 MCU：Company-X1 Company-X2 Company-X3它们关系如下：特性X1X2X3CPUCortex-M4Cortex-M4Cortex-M7UART相同相同相同GPIO相同相同新版SPI相同相同相同I2C相同相同相同Clock不同不同不同IRQ基本相同扩展不同SRAM128 KB256 KB512 KBFlash512 KB1 MB2 MBPinmux相同相同新版如果没有 Family Architecture，很容易变成：soc_x1/ uart.c gpio.c spi.c clock.c soc_x2/ uart.c gpio.c spi.c clock.c soc_x3/ uart.c gpio.c spi.c clock.c结果：80% 的代码重复。几年以后：X1 UART 修 bug ↓ 忘记 X2 ↓ X3 又有自己的版本这就是 BSP 最容易发生的code fork。2. 正确的第一原则：Family ≠ SoC这是今天最重要的概念之一。不要把：SoC Family理解成：一个 SoC 名字下面有几个型号更准确的理解是：Family 是一组共享硬件架构的软件抽象边界。例如：Company SoC Family │ ├── CPU architecture ├── interrupt model ├── clock model ├── peripheral register model ├── pinmux model └── memory model只要这些东西高度共享，就应该尽量共用代码。3. SoC Family 最常见的三级结构一个比较合理的 Zephyr BSP：arch/ arm/ soc/ company/ family_a/ soc_a1/ soc_a2/ soc_a3/ boards/ company/ board_a1/ board_a2/ board_a3/但这只是目录。真正重要的是：Family │ ├── Common │ ├── Variant │ └── SoC可以画成：Company Family │ ┌───────────┴───────────┐ │ │ Family Common Variant-specific │ │ ┌────┼────┐ ┌────┼────┐ │ │ │ │ │ │ Clock IRQ UART X1 X2 X34. 什么应该放 Family Common？假设：X1 X2 X3UART register layout 完全一样：struct company_uart{volatile uint32_t DR;volatile uint32_t SR;volatile uint32_t CR;volatile uint32_t BAUD;};那么：UART Driver不应该复制三份。应该：drivers/ serial/ uart_company.c然后：X1 ─┐ X2 ─┼──→ uart_company.c X3 ─┘这就是：Driver Commonality5. SoC Common 和 Driver Common 不是一回事这是很多 BSP 新手容易混淆的地方。例如：drivers/serial/uart_company.c属于：Zephyr Driver而：soc/company/family_a/common/属于：SoC Architecture例如 Family Common 里面可能有：clock_control.c soc_irq.c system_init.c pinmux.c power.c这些代码负责：SoC architecture而不是直接实现：Zephyr device API所以：Zephyr │ ┌───────┴────────┐ │ │ SoC Layer Driver Layer │ │ Family Common UART/GPIO/SPI │ │ Variant这是非常重要的边界。6. 三层 SoC Family 模型推荐把 SoC 分成：Family Variant Part例如：CompanyX Family │ ├── CX3 Family │ │ │ ├── CX301 │ ├── CX302 │ └── CX305 │ └── CX5 Family │ ├── CX501 └── CX502或者：CompanyX Family │ ├── CX3 Family │ │ │ ├── CX301 │ ├── CX302 │ └── CX305 │ └── CX5 Family │ ├── CX501 └── CX502这里：Family代表共享的软件架构。Variant代表一个硬件架构分支。Part代表最终芯片型号。7. Devicetree 应该承担什么？这是 SoC Family Architecture 的关键。不要把所有差异塞进 C：# ifdef CONFIG_SOC_X1...# elif CONFIG_SOC_X2...# elif CONFIG_SOC_X3...# endif如果差异属于：硬件描述应该优先进入 Devicetree。例如 X1：soc{uart0: uart@40000000{compatible="company,uart";reg=0x40000000 0x1000;interrupts=5;status="okay";};};X2：soc{uart0: uart@40010000{compatible="company,uart";reg=0x40010000 0x1000;interrupts=7;status="okay";};};Driver 不需要知道：X1 X2Driver 只知道：company,uart然后：DEVICE_DT_DEFINE(...)从 Devicetree 获取：base address IRQ clock pinmux status8. Kconfig 又负责什么？可以用一个非常简单的判断方法：Devicetree回答：我的硬件是什么？例如：UART0 在哪里？ GPIO 有几个？ IRQ 是多少？ SPI 接哪个 clock？Kconfig回答：软件功能是否启用？例如：CONFIG_SERIAL=yCONFIG_GPIO=yCONFIG_SPI=y