Zephyr Native_Sim仿真环境搭建指南：WSL下免硬件开发与测试实战

在嵌入式软件开发过程中，硬件未到位就想验证应用逻辑、执行单元测试的情况并不少见。与其干等开发板资源，不如借助软件仿真平台把验证工作提前做起来，效率提升会非常明显。

此前我们介绍过用 QEMU 搭建 Zephyr 软件仿真环境。今天换一条更轻量化的路线：Zephyr Native_Sim 平台。

Native_Sim 是 Zephyr 官方提供的软件仿真方案。它基于 Linux 主机的 POSIX 支持，把 Zephyr 应用直接编译为本机可执行程序，不需要任何目标硬件就能运行和调试，特别适合功能验证、自动化测试以及持续集成（CI）场景。

本文基于 WSL（Windows Subsystem for Linux） 环境，从零开始完成 Native_Sim 环境搭建，重点涵盖以下内容：

• 安装 Native_Sim 所需依赖
• 配置 Python 开发环境和 West 工具
• 使用系统 GCC 工具链进行编译
• 构建默认 32 位 Native_Sim
• 构建 64 位 Native_Sim
• 解析 BOARD_NATIVE_SIM_NATIVE_64 的来源与作用
• 常见错误排查与解决方案

一、安装 Native_Sim 运行环境

首先更新系统软件源：

sudo apt update

安装 Native_Sim 所需的基础开发工具和依赖库：

sudo apt install -y build-essential libc6-dev ninja-build cmake device-tree-compiler gcc-multilib

各组件作用如下：

• build-essential：提供 GCC、G++、Make 等基础开发工具
• ninja-build：Zephyr 默认使用 Ninja 作为构建后端
• cmake：Zephyr 构建系统核心组件
• device-tree-compiler（dtc）：用于设备树编译
• gcc-multilib：提供 32 位编译与运行支持

需要留意的是，Native_Sim 默认生成 32 位程序。如果系统缺少对应运行库，执行生成的程序时可能报错，因此建议提前安装多架构支持，避免后续编译运行踩坑。

二、创建 Python 虚拟环境并安装 West

Native_Sim 虽然不依赖 Zephyr SDK，但 West 作为 Zephyr 官方的项目管理工具仍然必不可少。

创建 Python 虚拟环境：

python3 -m venv ~/zephyr-venv
source ~/zephyr-venv/bin/activate

随后通过 pip 安装和管理 West 及相关工具链组件。采用虚拟环境的好处是避免系统 Python 环境被污染，同时便于维护不同版本的开发环境。

三、使用系统 GCC 工具链

对于 Native_Sim 平台来说，并不强制要求安装 Zephyr SDK。

因为目标程序最终运行在当前 Linux 主机上，直接使用系统 GCC 就能完成编译，这种方式更为轻量，也更适合快速验证和测试。

只需设置一个环境变量，即可让 Zephyr 使用主机工具链：

export ZEPHYR_TOOLCHAIN_VARIANT=host

如果需要显式指定编译器，还可以额外设置：

export CC=gcc
export CXX=g++

四、构建默认 32 位 Native_Sim

Zephyr 的 Native_Sim 默认工作在 32 位模式。

执行构建：

west build -b native_sim -p

生成的程序位于：

build/zephyr/zephyr.exe

可以直接运行：

./build/zephyr/zephyr.exe

特别要注意，如果使用 WSL 环境且未安装 32 位兼容库，程序可能无法正常启动。所以前面提到的多架构支持包建议提前装好。

五、构建 64 位 Native_Sim（推荐）

实际开发中，很多工程师更倾向于使用 64 位程序，原因在于：

• 减少对 i386 运行库的依赖
• 提供更加现代的运行环境
• 与当前主流 Linux 发行版保持一致
• 更方便后续集成调试工具

这里有一个常见误区需要强调：仅仅给 CFLAGS 添加 -m64 是无效的，因为 Zephyr 的 native_sim 内部会自动插入 -m32。

正确的方法有两种：

方法一：通过 Kconfig 开启 64 位支持（推荐）

在工程的 prj.conf 文件中加入：

CONFIG_BOARD_NATIVE_SIM_NATIVE_64=y

然后重建：

west build -t pristine --pristine -d build
west build -b native_sim -d build

检查是否成功：

file build/zephyr/zephyr

输出应为：

ELF 64-bit LSB executable, x86-64

这是官方推荐的配置方式，也是兼容性最好的方案。

方法二：直接指定 64 位 Board

一些 Zephyr 版本支持指定：

west build -b native_sim/native/64 -p

这种方法依赖于具体版本的 Board 目录结构。从长期维护和兼容性角度考虑，仍建议优先使用 Kconfig 配置方案。

六、深入理解 BOARD_NATIVE_SIM_NATIVE_64

在查看构建日志或源码时，经常能够看到：

BOARD_NATIVE_SIM_NATIVE_64

这个宏不是 CMake 定义的，也不是编译器生成的，而是来自 native_sim 的 Kconfig。

路径位置：

boards/native/native_sim/Kconfig

其中包含以下配置项：

config BOARD_NATIVE_SIM_NATIVE_64
bool "Build native_sim as 64-bit"

当 Kconfig 选择此项后：

• Zephyr 会自动生成 #define CONFIG_BOARD_NATIVE_SIM_NATIVE_64 1
• CMake 根据此宏，将 ARCH_FLAG 设置为 -m64
• 编译器生成 64-bit ELF 程序

因此，该宏的本质：它是一个 Kconfig 选项控制的编译特性，而不是工具链或 CMake 自主决定的。

七、常见问题排查

1. Exec format error

原因：系统缺少 32 位运行环境。

解决方案：

sudo dpkg --add-architecture i386
sudo apt update
sudo apt install libc6:i386 libstdc++6:i386 libgcc-s1:i386

2. Could NOT find Dtc

安装 dtc：

sudo apt install device-tree-compiler

3. CMake was unable to find Ninja

安装 ninja：

sudo apt install ninja-build

4. 添加 -m64 后仍然生成 32 位程序

原因：Zephyr 内部强制加了 -m32。必须使用 Kconfig：

CONFIG_BOARD_NATIVE_SIM_NATIVE_64=y

八、结语

Native_Sim 是 Zephyr 生态中非常实用的软件仿真平台。与 QEMU 相比，它无需模拟完整硬件系统，而是直接将 Zephyr 应用编译为 Linux 本机程序，因此编译速度更快、运行效率更高、调试流程也更简洁。

通过本文的方法，我们不仅完成了 WSL 环境下 Native_Sim 的搭建，还深入分析了默认 32 位构建机制、64 位切换方案以及 BOARD_NATIVE_SIM_NATIVE_64 的实现原理。

掌握 Native_Sim 之后，即使没有任何目标硬件，也能快速验证应用逻辑、执行自动化测试，大幅提升 Zephyr 项目的开发效率。对于日常开发、单元测试以及 CI/CD 场景而言，这无疑是一把不可多得的效率利器。如果你正在使用 Zephyr 进行嵌入式开发，不妨把 Native_Sim 纳入日常开发流程，让软件验证不再受硬件资源限制。

对于嵌入式开发者来说，类似这样的环境搭建经验和工具链配置心得，在云栈社区的技术讨论中经常能碰撞出新的思路，感兴趣的可以多逛逛。