3. DRIVE OS与DriveWorks基础环境搭建

DRIVE OS 是运行在 NVIDIA DRIVE 平台上的底层操作系统与固件集合，DriveWorks 则是构建在其之上的自动驾驶中间件与算法库。量产项目的第一步，是把这两层环境在目标硬件上稳定复现，并让版本可追溯、可回滚。本节围绕“烧录—驱动—开发环境—版本管理”这条主线，给出可执行的操作路径与判断依据。

一、系统镜像烧录：从 BSP 到目标板

DRIVE OS 的发布形态通常是一个 BSP 包，内部包含 bootloader、hypervisor、guest OS 镜像、根文件系统以及刷写脚本。以 DRIVE AGX Orin 为例，典型目录结构如下：

DRIVE_OS_6.0.8_Linux_with_DRIVE_AV_SDK/
├── bootloader/          # 引导与固件
├── kernel/              # 内核与设备树
├── rootfs/              # 根文件系统
├── tools/flashtools/    # flash.sh 等刷写脚本
└── drive-foundation/    # DriveWorks 与 SDK 组件

烧录前需确认三件事：目标板型号与 BSP 版本匹配、主机 USB/网络连接正常、板端已进入恢复模式（Recovery Mode）。恢复模式通常通过按住 Force Recovery 按钮再上电进入，主机执行 lsusb 应能看到 NVIDIA 的 USB 设备（如 0955:7045）。确认后执行刷写：

cd tools/flashtools
sudo ./flash.sh -b ./bootloader/ -r ./rootfs/ \
  -k ./kernel/ -t aurix -B qspi p3710-10-a01

刷写过程会依次写入 QSPI、Aurix MCU 固件与 eMMC/NVMe 根文件系统。判断成功的依据不是“脚本无报错”，而是串口日志中出现 bootloader 版本号、内核启动到 login: 提示，且板端 cat /etc/nv_tegra_release 输出的版本与 BSP 一致。若卡在 Waiting for device，优先检查 USB 线缆与恢复模式是否真正进入。

二、驱动安装与板端基础配置

系统启动后，需要补齐与传感器、网络、时间同步相关的驱动与配置。DRIVE OS 已内置多数相机与以太网驱动，但量产项目常需按实际传感器型号加载对应模块。例如启用 GMSL 相机时，确认设备树中已包含对应 serdes 节点，并通过 dmesg | grep -i max 观察探测日志。网络方面，量产车端通常使用静态 IP 与 PTP 时间同步，示例配置如下：

# /etc/systemd/network/10-eth0.network
[Match]
Name=eth0
[Network]
Address=192.168.1.10/24
Gateway=192.168.1.1
DNS=8.8.8.8

时间同步对多传感器融合至关重要。若使用 PTP，需确认网卡支持硬件时间戳，并通过 ptp4l -i eth0 -m 观察 offset 是否收敛到微秒级。驱动与配置完成后，建议执行一次板端自检：nvidia-smi 查看 GPU 状态、cat /proc/driver/camera/* 查看相机节点、ip addr 确认网络，三者均正常才进入开发环境配置。

三、开发环境配置：交叉编译与 DriveWorks 集成

DriveWorks 开发通常在 Ubuntu 主机上进行交叉编译，再部署到目标板。主机侧需安装与 BSP 匹配的交叉编译工具链、CMake 以及 DriveWorks SDK。关键环境变量包括：

export DRIVE_SDK_ROOT=/opt/nvidia/drive/drive-foundation
export CROSS_COMPILE=aarch64-linux-gnu-
export TARGET_ROOTFS=/path/to/targetfs
export LD_LIBRARY_PATH=$DRIVE_SDK_ROOT/lib:$LD_LIBRARY_PATH

一个最小 DriveWorks 程序需初始化 dwInitialize、创建 context、加载传感器模型。编译时通过 CMake 的 find_package(DriveWorks REQUIRED) 链接库。部署到板端后，运行 ./sample_sensor_info 应能枚举出已连接的相机与 LiDAR。若报 DW_INVALID_HANDLE，多为 context 未正确初始化或库路径缺失，需检查 LD_LIBRARY_PATH 与 dwGetVersion 输出。

四、量产版本管理策略

量产环境最忌讳“开发机上的版本”与“产线烧录的版本”不一致。建议采用三层版本锁定：BSP 版本、DriveWorks 版本、配置与标定版本，三者共同构成一次发布的唯一标识。每次发布生成一份 Manifest 文件，记录各组件哈希值与构建时间。产线烧录时只允许使用已签核的 Manifest，禁止现场混用不同 BSP 与 DriveWorks 组合。

回滚策略同样重要。若新版本在整车测试中出现相机丢帧或 PTP 失步，应能快速切回上一版 Manifest。实践中可将根文件系统做成 A/B 双分区，升级写入备用分区，验证通过后再切换启动标志。这样即使升级失败，也能通过 bootloader 回退到已知可用版本。