📚 课程目录第2章开发环境搭建

2. 开发环境搭建

NVIDIA Jetson Orin平台的BSP与底层驱动开发，本质上是在一个资源受限的嵌入式目标系统上，通过主机端进行高效的交叉编译与镜像部署。开发环境搭建的合理性直接决定了后续驱动调试、内核裁剪和系统集成的效率。本章将围绕“主机-目标板”双机协同模型，系统讲解JetPack SDK的安装策略、交叉编译工具链的配置方法，以及主机与目标板之间的连接与文件传输机制。我们将以Ubuntu 20.04/22.04主机配合Jetson Orin AGX/Orin NX模组为典型场景，给出可复现的完整操作路径。

上图展示了开发环境的整体架构：主机端负责工具链、镜像构建与调试服务，目标板运行L4T系统并通过USB、以太网和串口三条物理链路与主机交互。在实际BSP开发中，这三条链路各有分工——USB用于初始刷机与Recovery模式，以太网用于SSH远程登录、NFS挂载根文件系统以及内核镜像传输，串口则作为最底层的调试通道，即使内核崩溃或网络异常时仍可输出日志。理解这三条链路的角色差异，是后续所有开发工作的基础。

2.1 JetPack SDK安装：从SDK Manager到手动部署

JetPack SDK是NVIDIA官方发布的集成开发套件，它包含了Linux4Tegra（L4T）内核源码、U-Boot引导程序、根文件系统、CUDA库、TensorRT以及多媒体API等组件。对于BSP与底层驱动开发者而言，JetPack的核心价值在于提供了一套完整且经过验证的板级支持包，使得开发者可以专注于驱动逻辑本身，而不必从零搭建系统。

核心原理：JetPack的组件分层

JetPack的安装本质上是将主机端的交叉编译工具链与目标板的系统镜像进行绑定。其内部结构可分为三层：引导层（U-Boot与TegraBoot）、内核层（Linux内核与设备树）、用户空间层（根文件系统与CUDA等库）。SDK Manager通过读取目标板的硬件ID（如Orin AGX的芯片型号）自动匹配对应的BSP版本，并将这三层打包为可烧写的镜像。

组件名称	版本示例	安装位置	驱动开发用途
L4T (Linux4Tegra)	35.4.1	目标板 /boot	内核镜像、设备树、内核模块
U-Boot	2022.10	目标板 SPI Flash	引导参数、启动流程定制
RootFS	Ubuntu 22.04	目标板 eMMC/NVMe	驱动依赖库、运行时环境
Toolchain	GCC 11.3	主机 /opt	交叉编译内核与驱动
CUDA/多媒体	12.2	目标板 /usr/local	GPU驱动、多媒体框架依赖

操作流程：SDK Manager图形化安装

在主机下载并安装NVIDIA SDK Manager，运行后登录NVIDIA开发者账号。
选择目标硬件平台（Jetson Orin AGX 或 Orin NX）与JetPack版本（推荐最新LTS版本）。
勾选“Host Machine”中的“Jetson SDK Components”与“Target Machine”中的“Jetson Linux”组件。
将Orin开发套件通过USB Type-C线连接主机，按住Recovery按键并上电，进入Recovery模式。
SDK Manager自动识别设备后，点击“Flash”开始烧写。烧写过程约需15-30分钟，期间会写入U-Boot、内核与根文件系统。

风险提示：SDK Manager在烧写过程中会格式化目标板存储介质。如果目标板已有重要数据，务必提前备份。此外，烧写过程中不要断开USB连接或断电，否则可能导致目标板变砖，需要重新进入Recovery模式恢复。

案例拆解：手动安装JetPack组件

在某些离线或定制化场景下，SDK Manager无法使用。此时需要手动下载L4T驱动包（如Jetson_Linux_R35.4.1_aarch64.tbz2）与根文件系统包（如Tegra_Linux_Sample-Root-Filesystem_R35.4.1_aarch64.tbz2）。解压驱动包后，将根文件系统解压到rootfs/目录，然后执行./apply_binaries.sh脚本完成系统集成。最后通过./flash.sh脚本配合目标板的Recovery模式进行烧写。手动方式虽然繁琐，但能精确控制每个组件的版本，适合需要定制内核或修改U-Boot的BSP开发场景。

经验提醒：对于驱动开发者，建议在安装JetPack时同时勾选“Host SDK”中的“Cross-Compile Toolchain”选项。SDK Manager会自动将交叉编译工具链安装到/opt/nvidia目录，并配置好环境变量，省去手动配置的麻烦。

2.2 配置交叉编译工具链：从环境变量到内核编译

交叉编译是指在x86主机上编译生成ARM架构（aarch64）可执行代码的过程。Jetson Orin使用ARMv8.2-A架构，因此需要aarch64-linux-gnu工具链。正确配置工具链是驱动模块编译、内核裁剪和U-Boot定制的前提。

核心原理：工具链的组成与作用

交叉编译工具链由三部分组成：编译器（gcc）、汇编器（as）、链接器（ld）以及配套的C库（glibc）。对于内核模块编译，还需要内核源码树中的Makefile与Kconfig系统配合。NVIDIA官方提供的工具链基于GCC 11.3，支持C++17标准，并针对Tegra处理器进行了优化。

操作流程：手动配置工具链

# 1. 下载并解压L4T工具链
wget https://developer.nvidia.com/downloads/embedded/l4t/r35.4.1/toolchain/aarch64-glibc-11.3.tar.gz
sudo tar -xvf aarch64-glibc-11.3.tar.gz -C /opt

# 2. 设置环境变量（建议写入 ~/.bashrc）
export CROSS_COMPILE=/opt/aarch64-glibc-11.3/bin/aarch64-linux-gnu-
export ARCH=arm64
export PATH=$PATH:/opt/aarch64-glibc-11.3/bin

# 3. 验证工具链
aarch64-linux-gnu-gcc --version
# 输出应包含 "gcc version 11.3.0"

案例拆解：编译第一个内核模块

假设需要为Orin平台编写一个简单的字符设备驱动。首先需要获取与目标板内核版本完全一致的内核源码树。在JetPack安装后，内核源码位于目标板的/usr/src/linux-headers-$(uname -r)目录。将该目录拷贝到主机，或通过NFS挂载后，在主机上执行以下编译命令：

# 进入驱动源码目录
cd ~/driver_dev/hello_driver
# 编写Makefile
obj-m := hello.o
KDIR := /path/to/linux-headers-5.10.104-tegra
all:
    make -C $(KDIR) M=$(PWD) ARCH=arm64 CROSS_COMPILE=/opt/aarch64-glibc-11.3/bin/aarch64-linux-gnu- modules
clean:
    make -C $(KDIR) M=$(PWD) ARCH=arm64 CROSS_COMPILE=/opt/aarch64-glibc-11.3/bin/aarch64-linux-gnu- clean

编译成功后生成hello.ko文件。将该文件通过scp传输到目标板，执行insmod hello.ko加载模块，通过dmesg查看内核日志确认加载成功。这个流程验证了工具链配置的正确性，也是后续所有驱动开发的基础。

关键点：交叉编译时，ARCH=arm64和CROSS_COMPILE必须同时设置。如果只设置其中一个，内核构建系统会使用主机自带的x86工具链，导致编译出的模块无法在ARM平台上加载，报错Invalid module format。

2.3 连接目标板与主机：三条链路的配置与验证

目标板与主机的连接质量直接影响开发效率。USB链路用于刷机与Recovery模式，以太网链路用于日常开发中的文件传输与远程调试，串口链路则作为最后的调试保障。三条链路需要协同配置，才能构建一个高效的开发闭环。

核心原理：链路分工与优先级

在BSP开发中，串口是优先级最高的调试通道，因为它不依赖操作系统网络栈，即使内核panic或网络驱动异常，串口仍能输出日志。以太网是日常开发的主力通道，通过SSH执行命令、通过SCP传输文件、通过NFS挂载根文件系统，都能显著提升迭代速度。USB则用于系统烧写和Recovery模式，是系统级故障恢复的最后手段。

操作流程：串口与网络配置

# 串口配置（使用minicom）
sudo apt install minicom
# 查看USB转串口设备
ls /dev/ttyUSB*
# 配置minicom
sudo minicom -s
# 串口设置：/dev/ttyUSB0, 115200, 8N1, 无流控

# 网络配置（静态IP）
# 目标板侧执行
sudo ifconfig eth0 192.168.1.100 netmask 255.255.255.0 up
# 主机侧执行
sudo ifconfig eth0 192.168.1.101 netmask 255.255.255.0 up
# 测试连通性
ping 192.168.1.100

案例拆解：NFS挂载根文件系统

在驱动开发中，频繁烧写整个系统镜像非常耗时。更高效的做法是使用NFS将主机的根文件系统目录挂载到目标板。这样，主机上修改的文件系统内容会实时反映到目标板，无需重新烧写。具体步骤如下：

在主机上安装NFS服务器：sudo apt install nfs-kernel-server。
编辑/etc/exports，添加/home/user/orin_rootfs *(rw,sync,no_subtree_check,no_root_squash)。
重启NFS服务：sudo systemctl restart nfs-kernel-server。
在目标板U-Boot启动参数中设置root=/dev/nfs nfsroot=192.168.1.101:/home/user/orin_rootfs ip=192.168.1.100。
启动目标板，验证挂载成功：mount | grep nfs。

风险说明：NFS挂载依赖网络稳定性。如果网络中断，目标板可能会出现IO错误甚至系统崩溃。建议在驱动调试阶段使用NFS，在稳定性测试阶段切换回本地存储。此外，no_root_squash选项会允许目标板以root权限访问主机文件，存在安全风险，仅限开发环境使用。

常见误区与总结复盘

误区一：认为SDK Manager安装完成后工具链就自动配置好了。实际上，SDK Manager只安装了工具链文件，环境变量仍需手动配置。
误区二：使用主机自带的gcc编译内核模块。这会导致模块架构不匹配，加载时报Exec format error。
误区三：忽略串口调试的重要性。在驱动开发中，串口日志往往能提供比dmesg更早、更详细的启动信息，尤其是在内核早期初始化阶段。
误区四：在NFS挂载时使用soft挂载选项。虽然soft模式在网络故障时不会挂起，但可能导致文件系统损坏，建议使用hard模式并配合intr选项。

总结而言，开发环境搭建的核心目标是建立一条从主机到目标板的可靠、高效的开发链路。JetPack SDK提供了标准化的系统镜像，交叉编译工具链使得在x86主机上编译ARM代码成为可能，而三条物理链路的合理配置则保证了开发过程的顺畅。在实际项目中，建议将工具链配置脚本化、链路验证自动化，以减少重复劳动并降低人为配置错误的风险。