📚 课程目录第2章 Green Hills项目集成环境搭建

2. Green Hills项目集成环境搭建

Green Hills INTEGRITY/MULTI 的集成环境搭建，本质上是把“工具链—授权—目标硬件—工程结构—版本控制”五件事一次性对齐。任何一环错位，都会在后续编译、下载或调试阶段以难以定位的方式暴露出来。本节按实际工程落地顺序展开，重点说明每一步的关键输入、操作要点与判断依据。

2.1 MULTI IDE 安装与授权配置

MULTI IDE 的安装包通常以平台为单位分发，例如 Windows 主机上的 multi__win.exe，或 Linux 主机上的 multi__linux.bin。安装前先确认三件事：主机操作系统版本、目标架构（ARM、PowerPC、RH850、TriCore 等）、以及是否需要配套的 comp_ 编译器组件。安装路径建议统一为 C:\ghs\ 或 /opt/ghs/，避免空格与中文路径，否则部分 Makefile 与脚本在引用路径时会出现转义问题。

授权配置是安装后最容易出错的环节。Green Hills 常见授权形式包括节点锁定（node-locked）、浮动授权（floating license）以及基于 USB dongle 的授权。以浮动授权为例，需要在主机上设置环境变量指向 license 服务：

# Windows
set GHS_LMD_LICENSE_FILE=27000@license-server
set LM_LICENSE_FILE=27000@license-server

# Linux
export GHS_LMD_LICENSE_FILE=27000@license-server
export LM_LICENSE_FILE=27000@license-server

配置完成后，用 lmutil lmstat -a -c 27000@license-server 查看授权是否可见，重点确认 comp_、multi、debugger 三类 feature 是否处于 Users of ... 列表中。若显示 Cannot connect to license server，优先排查防火墙 27000 端口与主机名解析，而不是反复重装。

2.2 目标硬件连接：JTAG、TRACE32 与以太网

目标硬件连接方式取决于芯片与调试探针。常见组合有三类：

JTAG 直连：使用 Green Hills 支持的探针（如 iSYSTEM、Lauterbach、Segger）通过 JTAG 接口连接目标板，适合裸机或早期 bring-up。
TRACE32 连接：Lauterbach TRACE32 通过其 config.t32 与 *.cmm 脚本加载目标初始化，MULTI 通过 TRACE32 Remote API 或 t32rem 与 TRACE32 通信。
以太网连接：目标运行 INTEGRITY 后，通过以太网使用 gdbserver 或 Green Hills 的 rtserv 进行远程调试与下载。

以 TRACE32 为例，典型连接流程是：先启动 TRACE32 并加载对应 CPU 的 config.t32，确认 SYStem.Up 成功；再在 MULTI 中新建连接，选择 TRACE32 作为 debugger backend，填写 Node、Port（默认 20000）与 PackLen。判断连接是否成功的依据是 MULTI 的 Command 窗口出现 Connected to TRACE32，且 Register 窗口能读出 PC、SP 等寄存器值。若 SYStem.Up 失败，通常是复位电路、时钟或 JTAG 电平不匹配，应先示波器确认 TCK/TMS 波形，而不是直接改 MULTI 配置。

2.3 编译器与调试器版本匹配

Green Hills 的编译器、调试器与 INTEGRITY 内核版本之间存在明确的兼容矩阵。工程中必须记录三组版本号：cc 编译器版本、multi IDE 版本、以及 INTEGRITY OS 版本。例如编译器 ccarm 2021.1.5 通常要求 MULTI 不低于 7.1.4，且 INTEGRITY 不低于 5.2。版本不匹配的典型症状是：编译通过但链接报 undefined reference to __ghs_...，或调试时符号表加载失败。

建议在工程根目录放置 toolchain.lock 文件，显式记录版本，并在 CI 中校验：

# toolchain.lock 示例
GHS_MULTI=7.1.4
GHS_COMPILER=ccarm 2021.1.5
INTEGRITY_OS=5.2.1
TRACE32=2023.02

校验命令可用 ccarm --version 与 multi --version，将输出与 lock 文件比对，不一致则阻断构建。这一步在安全关键项目中属于可追溯性要求，不能省略。

2.4 工程目录结构规划与版本控制接入

推荐采用“按职责分层”的目录结构，而不是把所有源文件平铺。一个可直接参考的示例如下：

project/
├── src/                # 应用与驱动源码
│   ├── app/
│   ├── bsp/
│   └── os_cfg/         # INTEGRITY 配置
├── include/            # 对外头文件
├── lib/                # 第三方与预编译库
├── build/              # 构建脚本与 Makefile
├── tools/              # 烧录、校验、脚本
├── test/               # 单元与集成测试
├── docs/               # 需求、设计、接口文档
├── toolchain.lock      # 工具链版本锁定
└── .gitignore

版本控制接入时，.gitignore 必须排除 build/ 下的中间产物、*.o、*.elf、*.map 以及 MULTI 的 .ws 工作区文件，但应保留 toolchain.lock、Makefile、*.gpj 工程文件与 INTEGRITY 的 *.int 配置。若使用 Git，建议对 *.gpj 启用 text 属性并统一换行符，避免跨平台协作时出现整文件 diff。

最后，用一次“最小闭环”验证环境是否真正可用：新建一个仅含 main.c 的 INTEGRITY 工程，编译生成 .elf，通过 TRACE32 下载并运行到 main 断点，确认 Register 与 Memory 窗口可正常读取。若这一步通过，说明工具链、授权、硬件连接与工程结构已基本对齐，可以进入后续的集成与交付阶段。