📚 课程目录第2章 INTEGRITY系统构建工程环境搭建

2. INTEGRITY系统构建工程环境搭建

INTEGRITY 是 Green Hills Software 面向高安全实时系统的分离内核操作系统，其构建过程与常规 Linux 发行版差异很大：应用与内核镜像通常需要在 Linux 构建主机上，通过 Green Hills 提供的交叉工具链编译，再结合 BSP 包中的板级配置生成可烧录镜像。本节围绕交叉编译工具链、BSP 包结构、构建主机配置与版本管理策略四件事展开，目标是让读者能独立搭出一套可复现的构建环境。

一、交叉编译工具链的组成与选择

INTEGRITY 的编译工具链由 Green Hills 的 MULTI 集成开发环境及其底层编译器组成。典型安装目录下会看到 comp_<target>、cc_<target>、as_<target>、ld_<target> 等可执行文件，其中 <target> 是目标架构标识，例如 arm、arm64、ppc、x86。以 ARMv8 为例，常用前缀为 aarch64-gcc 或 ccarm64，具体名称取决于安装的 MULTI 版本与授权模块。

选择工具链时需关注三点：一是目标架构与 BSP 中声明的 CPU 核是否一致，例如 Cortex-A53 与 Cortex-A72 虽同属 ARMv8，但编译选项中的 -mcpu 不同；二是工具链版本必须与 INTEGRITY 内核版本匹配，Green Hills 通常要求 MULTI 版本不低于内核发布说明中标注的最低版本；三是浮点 ABI 要与 BSP 的启动代码一致，硬浮点与软浮点混用会在链接阶段报出符号不匹配。

安装完成后，建议在构建主机上验证工具链可用性：

$ export GHS_ROOT=/opt/ghs/multi_<version>
$ export PATH=$GHS_ROOT/comp_arm64:$PATH
$ ccarm64 --version
Green Hills C/C++ Compiler, Version <version>
Target: ARMv8-A, ABI: hard-float

若 --version 能正确输出目标架构与 ABI，说明工具链路径与授权均正常。授权通常通过 License 服务器或本地 License 文件提供，构建主机需能访问 GHS_LMD 指定的授权服务。

二、BSP 包结构解析

BSP（Board Support Package）是 INTEGRITY 构建中与硬件绑定最紧密的部分。一个典型的 BSP 包目录结构如下：

bsp_<board>/
├── config/
│   ├── board.cfg          # 板级内存映射、时钟、串口配置
│   └── kernel.cfg         # 内核裁剪与地址空间划分
├── include/
│   ├── board.h            # 寄存器基址、中断号定义
│   └── memory_map.h       # DDR、SRAM、外设地址段
├── src/
│   ├── init_board.c       # 早期硬件初始化
│   ├── timer.c            # 系统节拍与定时器驱动
│   └── uart.c             # 调试串口驱动
├── ld/
│   └── link.ld            # 链接脚本，定义段布局
└── Makefile               # BSP 编译入口

其中 board.cfg 与 link.ld 是构建时最容易被忽略却最关键的两个文件。board.cfg 中的内存映射必须与硬件实际地址一致，否则内核启动后访问外设会触发异常；link.ld 决定代码段、数据段、BSS 段在 DDR 中的落点，若与 BootROM 加载地址冲突，镜像将无法启动。BSP 包通常由芯片厂商或板卡厂商提供，版本号与板卡修订号对应，更换板卡修订时需同步更换 BSP。

三、构建主机配置要点

构建主机推荐使用 64 位 Linux，Ubuntu 20.04 LTS 或 CentOS 7 以上均可。需要安装的基础软件包包括 make、gcc（用于构建主机侧辅助工具）、python3、git、device-tree-compiler（若 BSP 使用设备树）、minicom 或 picocom（串口调试）。磁盘建议预留 20 GB 以上，因为 MULTI 工具链本身约 3～5 GB，加上内核源码、BSP 与编译中间文件，空间消耗较快。

环境变量是构建主机配置的核心。除 GHS_ROOT 与 PATH 外，还需设置 GHS_LMD 指向 License 服务地址，INTEGRITY_ROOT 指向内核源码根目录。建议将这些变量写入 ~/.bashrc 或独立的 env.sh，并在构建脚本开头 source 该文件，避免不同终端会话环境不一致。

调试通道方面，若目标板通过 JTAG 连接，需安装 Green Hills 的 MULTI 调试器与对应探针驱动；若通过串口，需确认 /dev/ttyUSB0 权限，通常将当前用户加入 dialout 组即可。构建主机与目标板的网络连接（TFTP/NFS）也应在环境搭建阶段一并验证，便于后续快速部署镜像。

四、版本管理策略

INTEGRITY 构建涉及三类版本：工具链版本、BSP 版本、内核与应用源码版本。三者任意一个变化都可能导致构建结果不同，因此必须纳入统一版本管理。推荐做法是使用 Git 仓库管理应用与内核源码，BSP 与工具链以子模块或外部依赖清单的形式锁定版本号。

一个可参考的版本锁定文件 build_manifest.yaml 如下：

toolchain:
  vendor: Green Hills
  multi_version: "<version>"
  target: arm64
  abi: hard-float
bsp:
  board: <board_name>
  revision: "A2"
  package_version: "<bsp_version>"
kernel:
  integrity_version: "<kernel_version>"
  patch_level: "<patch>"
application:
  git_commit: "<commit_hash>"
  branch: "release/<version>"

每次构建前，构建脚本读取该清单，校验工具链版本、BSP 版本与内核版本是否匹配，不匹配则终止构建并给出明确提示。这样做的价值在于：当现场出现问题时，可以凭清单精确复现当时的构建环境，而不是靠记忆猜测用了哪个版本。

建议为每个正式发布版本打 Git tag，并将对应的 build_manifest.yaml 与构建日志一并归档。构建日志中应包含工具链版本输出、BSP 校验和、内核 commit hash，便于追溯。

五、构建环境验证

环境搭建完成后，建议执行一次最小构建验证：选择一个官方示例工程或 BSP 自带的 hello 示例，执行 make，观察是否生成 .elf 与 .bin。若编译通过但链接报错，优先检查 link.ld 中的内存地址与 board.cfg 是否一致；若编译阶段报找不到头文件，检查 INTEGRITY_ROOT 与 BSP 的 include 路径是否加入编译选项。验证通过后，再将镜像通过 TFTP 或调试器加载到目标板，确认串口有启动输出，即说明构建环境基本可用。