摘要：本文从 Zephyr 的目录结构出发，系统梳理Architecture（CPU 架构）→ SoC（芯片）→ Board（开发板）三个层次的职责划分与协作关系。你将理解：arch/回答「CPU 怎么运行」，soc/回答「这颗芯片有什么」，boards/回答「这块板子怎么把芯片用起来」，而dts/则用 Devicetree 把三者串成完整的硬件描述。文章以 STM32F303RE / NUCLEO-F303RE 为例，逐步拆解 SoC 与 Board 的区别、Devicetree 与 Kconfig 的分工，并给出公司 SoC 接入 Zephyr 时「SoC 只实现一次、Board 可多个」的 BSP 设计原则，为后续学习 SoC / Board Porting 打下基础。这一篇非常关键。如果你的最终目标是把公司的 SoC 芯片加入 Zephyr 开发生态，那么你现在不能只把 boards/ 当成"开发板目录"来看。你需要建立一个非常清晰的概念：Architecture 决定 CPU 怎么跑 → SoC 决定这颗芯片有什么 → Board 决定这块板子怎么把芯片用起来。Zephyr 官方的 SoC Porting Guide 和 Board Porting Guide 也是按照这个层次组织的。Zephyr：Architecture → SoC → Board 到底怎么组织先记住这一张图：但是这里有一个非常重要的细节：这不是简单的"目录包含关系"。例如：ARCH │ └── SoC │ └── Board更准确地说是：而Devicetree 又把它们串起来了。1. 先看 Zephyr 的三个目录在你的 ~/zephyrproject/zephyr：zephyr/ ├── arch/ ├── soc/ ├── boards/ ├── dts/ ├── drivers/ ├── kernel/ ├── subsys/ ├── include/ └──...其中今天最重要的是：arch/ soc/ boards/ dts/可以把它们理解成：目录回答的问题arch/CPU 怎么运行？soc/这颗芯片是什么？boards/这块开发板是什么？dts/硬件实际上怎么连接？这四个东西共同构成 Zephyr 的硬件适配层。2. Architecture：CPU 架构例如你的 STM32F303RE。它使用：ARM Cortex-M4所以它首先属于：ARM └── ARM Cortex-MZephyr 的 arch/ 负责的是：CPU architecture │ ├── reset ├── interrupt ├── exception ├── context switch ├── CPU register ├── stack └── thread switching也就是说：arch/ 不关心你的 STM32F303RE 板子上 LED 接在哪个 GPIO。它甚至不应该关心：UART1 SPI2 I2C1 GPIOA这些属于更下面的 SoC / DeviceTree / Driver 层。3. 为什么 Architecture 要独立出来？这是 Zephyr 能够支持大量芯片的关键。假设：STM32F303 STM32F407 STM32H743都是：ARM Cortex-M那么它们不应该分别实现：thread switching interrupt entry exception handling stack initialization否则会产生大量重复代码。所以：这些 SoC 可以共享 Architecture 层。这就是：Architecture 是 CPU 共性。4. SoC：真正开始进入"芯片世界"然后到了：soc/这里才真正开始描述：我的这颗 SoC 到底是什么。官方 SoC Porting Guide 给出的基本结构类似：soc/VENDOR/soc-name/ ├── soc.yml ├── soc.h ├── CMakeLists.txt ├── Kconfig ├── Kconfig.soc └── Kconfig.defconfig比如可以抽象成：soc/ └── st/ └── stm32/ ├── common/ ├── stm32f0/ ├── stm32f1/ ├── stm32f3/ ├── stm32f4/ └──...这里开始出现：STM32而不是：Cortex-M45. SoC 层到底负责什么？例如你的 STM32F303。SoC 层可能涉及：STM32F303 │ ├── CPU ├── NVIC ├── Clock ├── RCC ├── Flash ├── SRAM ├── UART ├── SPI ├── I2C ├── GPIO ├── Timer ├── ADC └──...所以：ARCH回答：Cortex-M4 怎么运行？而：SoC回答：STM32F303 这颗芯片有哪些硬件资源，以及这些资源如何初始化？这就是两个非常不同的层次。6. Board：开发板又是什么？假设芯片是：STM32F303RE但是你有：NUCLEO-F303RE那么：STM32F303RE ≠ NUCLEO-F303RE因为：STM32F303RE是芯片。而：NUCLEO-F303RE是：一块使用 STM32F303RE 的具体 PCB。因此：boards/ └── st/ └── nucleo_f303re/描述的是板子。7. Board 层负责什么？例如：NUCLEO-F303RE板子上可能有：这些东西：不是 STM32F303RE 芯片本身决定的。而是：NUCLEO-F303RE 这块板子怎么把芯片的资源连接出来。所以 Board 层描述：- 这个 LED 接哪里？ - 这个 Button 接哪里？ - 这个 UART 用哪组 Pin？ - 这个板子的默认 console 是哪个 UART？这就是 Board。8. 一个非常重要的区别你以后做公司 SoC 时，一定要区分：SoC和：Board例如公司有一颗：ABC123然后公司有：ABC123-EVK ABC123-DK ABC123-Reference那么应该是：SoC 只实现一次。Board 可以有很多个。这就是你以后做 BSP 最重要的设计原则之一。9. Devicetree 是怎么把三者串起来的？这里才是整个 Zephyr 硬件模型最关键的地方。例如：boards/.../nucleo_f303re/nucleo_f303re.dts可能会包含：STM32F303 SoC .dtsi最终形成：nucleo_f303re.dts │ ├── stm32f303xx.dtsi │ ├── ARM/common DTSI │ └── Board-specific hardware官方文档明确说明，Board 的 .dts 通常会 include SoC 的 .dtsi，SoC .dtsi 描述 CPU/SoC 的硬件资源，而 Board .dts 再描述板级硬件。所以最终可以画成：Board DTS │ │ include ▼ SoC DTSI │ │ include ▼ ARCH DTSI这非常重要。10. 举一个 UART 的完整例子假设：STM32F303里面有：USART1那么 SoC 层可以描述：usart1:serial@40013800{compatible="st,stm32-usart";reg=lt;0x400138000x400gt;;interrupts=lt;37gt;;...};这表达的是：芯片里面存在 USART1。但是：NUCLEO-F303RE可能把它连接到了某些板级接口。所以 Board DTS 再决定：chosen{zephyr,console=usart1;};于是：Application │ │printk()▼ Zephyr Console │ ▼ USART1 Driver │ ▼ STM32 USART1 │ ▼ NUCLEO-F303RE │ ▼ ST-LINK/UART │ ▼ macOS Terminal这就是你之前做的：NUCLEO-F303RE → ST-LINK → macOS → UART terminal背后的 Zephyr 硬件模型。11. 所以不要把 DTS 当成"配置文件"这是我建议你现在重点改变的一个认识。很多初学者认为：DTS=配置文件不够准确。更准确的是：**Devicetree 是 Zephyr 对硬件结构的描述语言。**它描述：CPU Memory Bus Peripheral Interrupt GPIO Clock Pin Device然后 Zephyr 根据这些硬件描述生成对应的配置和代码连接。