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

2、开发环境搭建：安装交叉编译工具链、配置TFTP/NFS服务、创建Ubuntu虚拟机或Docker环境

嵌入式Linux系统移植是一项对开发环境依赖极强的工作。对于全志F1C100s（ARM926EJ-S内核）和V3s（ARM Cortex-A7内核）这两款芯片而言，无论是U-Boot编译、Linux内核裁剪，还是根文件系统构建（通常使用Buildroot或BusyBox），都必须在特定的交叉编译环境中完成。若环境搭建不当，轻则编译报错、浪费大量时间排查路径问题，重则生成错误架构的二进制文件导致目标板无法启动。本章将围绕“交叉编译工具链安装”、“TFTP/NFS服务配置”以及“Ubuntu虚拟机或Docker环境创建”三个核心任务展开，帮助读者构建一套高效、可复现的开发环境。

上图展示了开发环境的核心架构：开发主机通过虚拟机或Docker容器提供统一的编译环境，生成的可执行文件经由TFTP/NFS网络服务传输至目标板，同时串口作为调试和控制的辅助通道。理解这一数据流是后续所有移植工作的基础。

2.1 交叉编译工具链的安装与验证

核心原理：为什么需要交叉编译

F1C100s基于ARM926EJ-S架构（32位ARMv5TE指令集），V3s基于Cortex-A7架构（32位ARMv7-A指令集），而我们的开发主机通常是x86_64架构。x86_64的机器无法直接运行ARM指令集的可执行文件，因此必须在x86主机上使用“交叉编译器”生成目标平台（ARM）的机器码。交叉编译工具链由binutils（汇编器、链接器）、gcc（编译器）、glibc（C库）以及内核头文件组成，其命名通常带有目标三元组前缀，例如arm-linux-gnueabihf-（用于V3s，支持硬件浮点）和arm-linux-gnueabi-（用于F1C100s，无硬件浮点单元）。

操作流程：安装与配置

推荐使用Linaro提供的稳定工具链，或使用Buildroot自动下载并编译工具链。以下为手动安装的通用步骤：

下载工具链：访问Linaro官网或使用apt安装（仅限Ubuntu仓库中的旧版本）。建议下载gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz。

解压至指定目录：

sudo mkdir -p /opt/toolchains
sudo tar -xJf gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz -C /opt/toolchains/

配置环境变量：编辑~/.bashrc，添加以下内容：

export PATH=/opt/toolchains/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin:$PATH
export ARCH=arm
export CROSS_COMPILE=arm-linux-gnueabihf-

验证安装：
```
source ~/.bashrc
arm-linux-gnueabihf-gcc -v
```
若显示gcc version 7.5.0，则安装成功。

注意：F1C100s（ARM926EJ-S）不支持硬件浮点，必须使用arm-linux-gnueabi-工具链（软浮点），否则内核或应用在运行时会产生“Illegal instruction”错误。V3s则必须使用arm-linux-gnueabihf-（硬浮点），以发挥其VFPv4硬件浮点单元的性能。

案例拆解：编译一个最小可执行程序

编写一个简单的Hello World程序，并分别用x86原生gcc和交叉编译器编译，观察文件类型差异：

#include <stdio.h>
int main() { printf("Hello F1C100s!\n"); return 0; }

gcc hello.c -o hello_x86
arm-linux-gnueabi-gcc hello.c -o hello_arm
file hello_x86 hello_arm

输出结果中，hello_x86显示为“ELF 64-bit LSB executable, x86-64”，而hello_arm显示为“ELF 32-bit LSB executable, ARM, EABI5”。将hello_arm拷贝至目标板，通过串口执行，即可看到输出。此案例验证了工具链的正确性。

常见误区与复盘

误区1：使用apt安装的gcc-arm-linux-gnueabihf版本过旧（如4.8），可能导致内核编译时出现未知错误。建议使用Linaro 7.5或更高版本。
误区2：忘记设置CROSS_COMPILE环境变量，导致内核编译时调用x86原生gcc，产生大量“未定义的引用”错误。
误区3：工具链路径包含空格或中文，导致Makefile解析失败。务必确保路径纯英文且无空格。

2.2 配置TFTP与NFS服务

核心原理：网络引导的基石

在嵌入式开发初期，频繁烧写Flash既耗时又容易损坏存储介质。TFTP（Trivial File Transfer Protocol）和NFS（Network File System）提供了“网络加载”的解决方案。TFTP基于UDP协议，用于U-Boot阶段从主机下载内核镜像（uImage）和设备树（.dtb）文件。NFS则允许目标板将主机上的某个目录直接挂载为根文件系统，内核启动后无需将rootfs烧入Flash，即可直接运行主机上的应用程序，极大缩短了调试迭代周期。

操作流程：服务端配置（以Ubuntu 22.04为例）

1. 安装并配置TFTP服务：

sudo apt update
sudo apt install tftpd-hpa
sudo mkdir -p /srv/tftp
sudo chown -R tftp:tftp /srv/tftp
sudo vim /etc/default/tftpd-hpa

配置文件内容如下：

TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
TFTP_ADDRESS="0.0.0.0:69"
TFTP_OPTIONS="--secure"

重启服务：sudo systemctl restart tftpd-hpa。将编译好的uImage和suniv-f1c100s.dtb拷贝至/srv/tftp目录。

2. 安装并配置NFS服务：

sudo apt install nfs-kernel-server
sudo mkdir -p /srv/nfs/rootfs
sudo vim /etc/exports

在/etc/exports末尾添加：

/srv/nfs/rootfs *(rw,sync,no_root_squash,no_subtree_check)

重启服务：sudo systemctl restart nfs-kernel-server。将Buildroot生成的根文件系统内容解压至/srv/nfs/rootfs。

经验提示：在U-Boot中设置环境变量时，需确保主机IP、目标板IP、服务器IP在同一网段。例如：setenv serverip 192.168.1.100（主机IP），setenv ipaddr 192.168.1.50（目标板IP）。

案例拆解：U-Boot通过TFTP加载内核并NFS挂载根文件系统

在U-Boot命令行中依次执行以下命令：

setenv bootargs 'console=ttyS0,115200 root=/dev/nfs nfsroot=192.168.1.100:/srv/nfs/rootfs,v3 tcp rw ip=dhcp'
tftp 0x80000000 uImage
tftp 0x81000000 suniv-f1c100s.dtb
bootz 0x80000000 - 0x81000000

此过程的关键参数说明：root=/dev/nfs告诉内核使用NFS作为根文件系统；nfsroot指定主机IP和共享目录；ip=dhcp让目标板自动获取IP。若网络通畅，内核启动后应能看到NFS目录下的文件系统内容。

常见误区与排障

现象	可能原因	解决方案
TFTP下载超时	防火墙未开放69端口	`sudo ufw allow 69/udp`
NFS挂载失败：`Network is unreachable`	内核未启用NFS客户端支持	内核配置中开启`CONFIG_NFS_FS=y`和`CONFIG_ROOT_NFS=y`
NFS挂载后出现`VFS: Unable to mount root fs`	NFS服务端导出目录权限错误	检查`/etc/exports`是否包含`no_root_squash`，并重启服务

2.3 创建Ubuntu虚拟机或Docker环境

核心原理：环境隔离与可复现性

嵌入式开发中，主机系统升级、库版本冲突是导致编译失败的主要诱因。使用虚拟机（如VirtualBox/VMware）或Docker容器，可以将开发环境与主机隔离，确保所有依赖（如ncurses、zlib、python3等）版本固定。Docker相比虚拟机更轻量，启动秒级，资源占用小，且通过Dockerfile可以精确复现环境，非常适合团队协作和CI/CD集成。

操作流程：Docker环境搭建

1. 编写Dockerfile：

FROM ubuntu:22.04
RUN apt update && apt install -y \
    build-essential \
    git \
    vim \
    wget \
    xz-utils \
    u-boot-tools \
    device-tree-compiler \
    python3 \
    python3-pip \
    libncurses5-dev \
    libssl-dev \
    bc \
    bison \
    flex \
    tftpd-hpa \
    nfs-kernel-server \
    && rm -rf /var/lib/apt/lists/*
# 添加交叉编译工具链
COPY gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf.tar.xz /opt/
RUN tar -xJf /opt/gcc-linaro-*.tar.xz -C /opt/ \
    && rm /opt/*.tar.xz
ENV PATH=/opt/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin:$PATH
ENV ARCH=arm
ENV CROSS_COMPILE=arm-linux-gnueabihf-
WORKDIR /workspace
CMD ["/bin/bash"]

2. 构建镜像并启动容器：

docker build -t f1c100s-dev:1.0 .
docker run -it --name dev-env -v /srv/tftp:/srv/tftp -v /srv/nfs:/srv/nfs --network host f1c100s-dev:1.0

使用-v参数将主机的TFTP和NFS目录挂载进容器，实现编译产物即时共享。

案例拆解：使用Docker编译内核并自动部署

假设内核源码位于/workspace/linux，在容器内执行：

cd /workspace/linux
make suniv_defconfig
make -j$(nproc) uImage
cp arch/arm/boot/uImage /srv/tftp/

由于容器与主机共享网络和目录，编译完成后目标板即可通过TFTP获取新内核。此流程将“编译-部署”压缩至分钟级，且环境完全可复现。

常见误区与复盘

误区1：在Windows主机上直接使用WSL编译，但未启用systemd导致NFS服务无法启动。建议在WSL2中使用sudo service nfs-kernel-server start手动启动。
误区2：Docker容器内使用--network host时，若主机防火墙拦截TFTP端口，容器内服务同样不可用。需在主机上开放端口。
误区3：虚拟机中共享文件夹（如VirtualBox的vboxsf）性能较差，编译内核时I/O成为瓶颈。建议将源码放在虚拟机磁盘内，通过NFS或SSH同步。

总结复盘：开发环境搭建的核心目标是“快速迭代、稳定复现”。交叉编译工具链决定了生成的二进制是否能在目标板上运行；TFTP/NFS服务决定了调试效率；而虚拟机/Docker则保证了环境的可移植性。建议读者将本章所有操作记录为脚本或Dockerfile，纳入版本管理，以便在更换主机或新同事加入时，能够一键重建环境。