嵌入式Linux共享库与U-Boot多阶段调试实战指南

1. 项目概述与核心挑战

在嵌入式Linux开发，尤其是针对Power Architecture这类高性能处理器的复杂系统开发中，调试工作往往是决定项目成败的关键环节。不同于在x86平台上开发桌面应用，嵌入式系统的调试环境构建充满了挑战：目标板资源有限、启动流程复杂、代码可能运行在Flash或RAM的不同阶段，并且常常涉及到底层硬件初始化、Bootloader以及动态加载的共享库。我过去在调试基于NXP（原Freescale）Power Architecture处理器的通信设备时，就曾花费大量时间与CodeWarrior IDE和U-Boot“搏斗”。今天，我想把这些实战中积累的经验，特别是关于共享库（Shared Library）调试和U-Boot多阶段调试的“硬骨头”啃下来，整理成一份可以直接上手操作的指南。

共享库调试的核心痛点在于，你的代码（可执行文件）和库文件（.so）是分离的。调试器需要知道两件事：第一，库的符号信息在哪里（用于设置断点、单步跟踪）；第二，在目标板运行时，系统去哪里加载这个库。这涉及到编译链接时的路径设置、调试会话的配置，以及目标板运行时环境变量（如 LD_LIBRARY_PATH ）的指定。任何一个环节出错，都会导致调试器无法进入库函数，或者程序在目标板运行时因找不到库而崩溃。

而U-Boot调试则更像一场“接力赛”。它的生命周期从芯片上电、从Flash中执行开始，经过内存初始化、代码自搬运（Relocation）到RAM，最后跳转到RAM中继续执行，直到交出控制权给Linux内核。每个阶段的内存映射、代码位置都完全不同。想象一下，运动员（U-Boot代码）在比赛（启动过程）中换了三次跑道（内存地址空间），而你的望远镜（调试器）必须能持续追踪到他。这就要求我们为不同的“赛段”准备不同的“观测点”（即调试配置）。很多开发者卡在这里，只能调试最开始的Flash部分，一旦U-Boot“跑”起来进入RAM，就失去了控制。

本文将基于CodeWarrior Development Studio for Power Architecture这个经典的开发环境，手把手带你打通这两个关键调试场景。我会假设你已经有基本的CodeWarrior和交叉编译工具链使用经验，并把重点放在那些官方文档可能一笔带过，但实际调试中却至关重要的细节和“坑”上。

2. 共享库调试：从构建到符号加载的全链路解析

在嵌入式Linux中，使用共享库是提升软件模块化和复用性的标准做法。但调试共享库比调试静态链接的程序要麻烦得多，因为调试器必须在运行时动态地关联库的调试符号。

2.1 理解动态链接与调试符号的分离

首先，我们必须厘清一个关键概念： 可执行文件（ELF）中记录的共享库信息，与调试器所需的符号信息，是两回事 。

当你编译一个依赖 libexample.so 的程序时，链接器只在可执行文件中记录：“我需要 libexample.so ，并且我期望在运行时从某个路径（或默认路径）找到它。”这个信息用于动态链接器（如 ld-linux.so ）在加载时解析函数地址。而调试符号（函数名、变量名、行号信息）通常存储在独立的 .debug 段，或者更常见的，直接保留在带有调试信息的库文件本身（ libexample.so ）中。在发布时，我们常使用 strip 命令移除这些符号以减小体积，但在调试时，我们必须确保调试器能访问到包含完整符号的库文件。

实操心得 ：在构建用于调试的共享库时，务必在编译命令中加上 -g 选项（如 -g -O0 ），以确保生成完整的调试信息。同时，避免使用 strip 命令处理你的调试版本库。

2.2 构建带调试信息的共享库与可执行文件

在CodeWarrior IDE中，这通常意味着为你的“SharedLibraryExample”项目选择合适的构建配置（Build Configuration）。项目模板或默认配置可能已经设置了优化级别。为了调试，你需要一个专门的调试配置。

1. 创建或选择调试构建配置 ：在“Project Properties” -> “C/C++ Build” -> “Settings”中，找到“Tool Settings”标签页。确保在“GCC C Compiler” -> “Debugging”级别中选择了 -g3 （提供最多调试信息）。在“Optimization”级别中，选择 -O0 （关闭优化）。优化会使代码执行顺序重排、变量被优化掉，给单步调试带来巨大困扰。
2. 构建库与可执行文件 ：如文档所述，你需要分别针对库项目和可执行项目进行构建。一个常见的项目结构是，将共享库作为一个独立的子项目（Project），而可执行文件主工程依赖它。在构建顺序上，需要先构建库，再构建依赖它的可执行文件。CodeWarrior的“Build Project”功能会自动处理依赖关系。

2.3 配置调试启动参数：连接主机与目标板的桥梁

这是共享库调试中最核心、也最容易出错的步骤。你的目标是告诉CodeWarrior调试器三件事：可执行文件下载到哪里、共享库文件在哪里、以及目标板运行时去哪里找这个库。

1. 指定远程下载路径（Remote Download Path） ：

   • 作用 ：这个路径是目标板（嵌入式设备）上的一个目录。调试器会将你的可执行文件（如 SharedLib_IM.elf ）通过调试代理（如CodeWarrior TRK）下载到这个目录，然后从那里启动它。
   • 设置 ：在“Debug Configurations” -> “Debugger” -> “Remote”标签页中，填写“Remote Download Path”。例如 /tmp 。 关键点 ：确保目标板上的 /tmp 目录存在且对调试代理进程有写权限。 /tmp 是一个通用选择，因为它通常在嵌入式Linux的根文件系统中存在且可写。

2. 添加并配置其他可执行文件（Other Executables） ：

   • 作用 ：这是让调试器认识你的共享库的关键一步。通过这里添加 libexample.so ，调试器会加载该文件的符号表，这样你才能在库的源代码中设置断点。
   • 设置 ：在“Debugger” -> “Other Executables”标签页，点击“Add”。
     • Location ：浏览选择你主机上编译生成的、 带调试信息的 libexample.so 文件。
     • Load Symbols ： 必须勾选 。这是加载符号信息的开关。
     • Download to Device ： 必须勾选 。这会将库文件也下载到目标板。
     • Remote download path ：同样设置为 /tmp 。这意味着库文件会被下载到目标板的 /tmp 目录下。

3. 设置运行时库搜索路径（LD_LIBRARY_PATH） ：

   • 原理 ：当你的程序在目标板上启动时，系统的动态链接器（loader）负责加载它依赖的共享库。链接器会按照一定顺序搜索库文件，其中 LD_LIBRARY_PATH 环境变量指定的路径是优先级最高的搜索位置之一（通常在默认系统库路径如 /usr/lib 之前）。
   • 设置 ：在“Debug Configurations” -> “Environment”标签页，点击“New”。
     • Name : LD_LIBRARY_PATH
     • Value : /tmp
   • 为什么是 /tmp ？ 因为我们在上一步把 libexample.so 下载到了 /tmp 。这样，程序启动时，动态链接器就会在 /tmp 目录下找到它。
   • 设置 AVOID_SYSTEM_PATH ：这是一个CodeWarrior/TRK相关的环境变量。将其值设为 YES ，可以确保调试会话严格使用你指定的 LD_LIBRARY_PATH ，避免意外链接到目标板系统自带的、可能版本不匹配的同名库。

注意事项 ： LD_LIBRARY_PATH 和库的远程下载路径 必须保持一致 。如果你把库下载到 /home/root/libs ，那么 LD_LIBRARY_PATH 也应该包含这个路径。不一致会导致程序启动失败，报“找不到共享库”的错误。

2.4 启动调试与会话控制

完成上述配置后，点击“Debug”启动调试会话。调试器会依次将可执行文件和共享库上传到目标板的 /tmp 目录，然后启动程序。当执行到调用共享库函数的代码行（例如 ret = add_example(a, b) ）时，你可以使用“Step Into”（F5）命令进入 libexample.so 中的函数实现进行单步调试。

在调试过程中，你可以通过“Variables”视图查看和修改变量值，在“Breakpoints”视图中管理断点。如果无法进入库函数，请按以下顺序排查：

1. 检查“Other Executables”中 libexample.so 的“Load Symbols”是否勾选。
2. 检查库文件是否成功下载到目标板（可以查看调试控制台日志）。
3. 在目标板shell（如果有）中，使用 ls -la /tmp 确认文件存在，并使用 ldd ./SharedLib_IM.elf （需在目标板编译该命令）检查程序依赖的库路径解析是否正确。

3. U-Boot调试：应对多阶段启动的复杂调试策略

U-Boot的调试是嵌入式底层开发的必修课。其复杂性源于它的启动过程是分阶段的，代码在内存中的位置会发生改变。

3.1 U-Boot启动阶段深度剖析

理解阶段划分是配置调试器的基础。从内存视角看，U-Boot的典型启动流程可分为四个关键阶段：

1. 阶段一：Flash中的初始代码（Stage 1 - Flash） ：

   • 状态 ：CPU从复位向量（Reset Vector）开始执行，此时MMU（内存管理单元）未开启，缓存可能被禁用或处于非一致状态。代码在Flash的物理地址上运行（例如 0xFFF40000 ）。
   • 调试挑战 ：调试器需要知道代码的确切加载地址（即Flash中的地址），并且需要初始化一个最基本的硬件环境（如时钟、内存控制器）以便能进行下载和调试。

2. 阶段二：内存初始化与代码搬运准备（Stage 2 - Memory Translation） ：

   • 状态 ：U-Boot的早期汇编代码已经运行，它初始化了最基本的内存控制器（DDR），为将自身代码从Flash复制到RAM做准备。此时，代码仍在Flash中执行，但目标RAM区域已准备好。
   • 调试挑战 ：需要为调试器配置正确的内存映射（Memory Map），让它知道RAM的物理地址和大小，以便它能正确访问即将被拷贝的代码和数据。

3. 阶段三：RAM中的重定位后代码（Stage 3 - Relocated in RAM） ：

   • 状态 ：U-Boot将自身代码段和数据段从Flash复制到RAM的某个地址（例如 0x01000000 ），然后跳转到RAM中继续执行。此时，代码执行地址发生了根本性改变。
   • 调试挑战 ：这是最易丢失调试连接的点。调试器必须知道代码新的运行地址（即重定位地址），并在这个地址上重新加载符号。否则，单步执行会看到程序计数器（PC）乱飞，源代码无法对应。

4. 阶段四：MMU启用后（Stage 4 - With MMU Enabled） ：

   • 状态 ：U-Boot启用MMU，开启虚拟地址到物理地址的转换。此后，所有代码访问的地址都是虚拟地址。
   • 调试挑战 ：调试器需要支持MMU地址转换，或者知道转换规则，才能将虚拟地址映射回正确的物理地址和源代码行。

3.2 准备工作：BSP安装与U-Boot镜像构建

在开始调试前，必须准备好正确的软件环境。

1. 安装板级支持包（BSP） ：

   • 目的 ：BSP包含了针对特定硬件板（如P4080DS）的Linux内核、设备树、驱动以及 U-Boot源代码和交叉编译工具链 。这是构建U-Boot的基础。
   • 操作 ：从NXP官网下载对应你硬件平台的BSP ISO镜像。在Linux主机上挂载并安装。安装路径不要有空格或中文，并且 务必以非root用户身份运行安装脚本 ，否则可能会因权限问题导致后续编译失败。
   • 注意 ：不同版本的BSP，其构建系统可能不同（如旧版的LTIB，新版的Yocto）。本文示例基于较老的BSP，你需要根据自己BSP的文档，使用对应的命令（如 source 环境设置脚本）来激活交叉编译环境。

2. 配置与编译带调试信息的U-Boot ：

   • 进入U-Boot源码目录（通常在BSP安装目录下的 u-boot-* 文件夹）。
   • 使用BSP提供的交叉编译工具链进行配置和编译。关键是在编译时加入调试信息。

   # 1. 清理旧配置
   make distclean
   # 2. 选择板级配置，例如 P4080DS
   make P4080DS_defconfig
   # 3. 手动调整配置，确保开启调试信息
   make menuconfig
   

   • 在 make menuconfig 的图形界面中（或直接修改 .config 文件），确保以下选项被设置：
     • CONFIG_DEBUG_INFO=y (编译时加入-g标志)
     • CONFIG_OPTIMIZE_INLINING=n (或 CONFIG_CC_OPTIMIZE_FOR_DEBUG=y ) 尽可能关闭优化
   • 执行编译： make CROSS_COMPILE=powerpc-fsl-linux- 。这将生成最终的U-Boot镜像 u-boot.bin 和包含调试符号的ELF文件 u-boot （无后缀）。

3.3 创建CodeWarrior U-Boot调试工程

这一步是将编译好的U-Boot ELF文件导入CodeWarrior，创建一个可以对其进行调试的工程。

1. 导入可执行文件 ：在CodeWarrior IDE中，选择 File -> Import -> CodeWarrior -> CodeWarrior Executable Importer 。
2. 关键参数选择 ：
   • Project name ：给你的调试工程起个名字，如 U-Boot_P4080_Debug 。
   • Executable ：选择你上一步编译生成的 u-boot （ELF格式）文件。
   • Processor ：务必选择与你目标板完全一致的处理器型号，例如 P4080 。
   • Toolchain ：选择 Bareboard Application 。这是关键！U-Boot在引导内核前是一个裸机程序，没有操作系统支持，必须选择裸板调试工具链。
   • Target OS ：选择 None 。
   • Debugger Connection Type ：根据你的硬件连接选择，如通过网线连接的 Ethernet TAP 或 Gigabit TAP ，并填写TAP设备的IP地址。

3.4 配置多阶段启动的调试会话

这是U-Boot调试的核心技巧：为不同的启动阶段创建独立的启动配置（Launch Configuration）。

第一阶段配置（Stage 1 - Flash） ： 这个配置在创建工程时通常会自动生成一个（例如 U-Boot_P4080_Debug Attach ）。我们需要对其进行精细调整。

1. 打开 Run -> Debug Configurations ，找到对应的配置。
2. Main 标签 ：检查并创建正确的硬件连接（Connection）和系统（System）。
3. Debugger 标签 -> PIC 页面 ：
   • 勾选 Alternate Load Address 。
   • 填入地址 0xFFF40000 。这个地址是U-Boot在Flash中的起始地址。 这个地址因板而异 ，你必须查阅你的硬件手册或U-Boot板级配置头文件（如 include/configs/P4080DS.h ）中的 CONFIG_SYS_TEXT_BASE 宏定义来确认。
4. Initialization 标签 ：这里需要加载一个目标板初始化脚本（TCL文件）。这个脚本由BSP或CodeWarrior提供，用于在调试器连接后，对处理器进行最基本的初始化（例如设置时钟、初始化内存控制器）。找到 <CW_Install_Dir>/PA/PA_Support/Initialization_Files/ 目录下对应你板子的文件，例如 p4080_uboot_32.tcl 。 务必取消执行系统复位（ Execute system reset ） ，因为硬件可能已经由上电或之前的操作处于某种状态���盲目复位可能导致初始化失败。

创建后续阶段配置（Stage 2, 3, 4） ： 我们通过复制和修改第一阶段配置来快速创建。

1. 复制远程系统（Remote System） ：在 Window -> Show View -> Other -> Remote Systems 打开远程系统视图。右键复制第一���段的系统（如 P4080 U-Boot Stage 1 ），重命名为 P4080 U-Boot Stage 2 (Mem Trans) 。
2. 修改复制的系统属性 ：右键新系统 -> Properties 。在 System 标签页，为其指定一个新的 内存配置文件（Memory Configuration File） 。这个文件定义了该阶段下可访问的内存区域。对于阶段二（内存初始化后），你需要一个包含了DDR内存区域定义的文件，例如 p4080_uboot_32_stage2.mem 。
3. 复制并修改启动配置 ：回到 Debug Configurations ，右键复制 P4080 U-Boot Stage 1 配置，重命名为 P4080 U-Boot Stage 2 。
   • 在 Main 标签页，将 Remote system 改为你刚创建的 P4080 U-Boot Stage 2 (Mem Trans) 。
   • 在 Debugger -> PIC 页面， 取消勾选 Alternate Load Address 。因为阶段二代码仍在Flash中运行，但调试器需要感知到已初始化的RAM。
4. 创建阶段三配置 ：再次复制阶段一的配置，重命名为 P4080 U-Boot Stage 3 。
   • Remote system 可以继续使用阶段二的系统（因为内存映射相同）。
   • Debugger -> PIC 页面，同样 取消勾选 Alternate Load Address 。 但是，最关键的一步来了 ：你需要知道U-Boot重定位后的地址。这个地址通常在U-Boot启动时，在串口输出中显示为“ Now running in RAM - Address: 0x01000000 ”之类的信息。 将这个地址记录下来 。
5. 创建阶段四配置 ：复制阶段三的配置，重命名为 P4080 U-Boot Stage 4 。
   • 在 Debugger -> PIC 页面， 重新勾选 Alternate Load Address ，并填入U-Boot重定位后在RAM中的地址（例如 0x01000000 ）。这个地址就是阶段三记录的那个地址。启用MMU后，代码的逻辑地址（我们调试时看到的）可能还是从这个地址开始。

3.5 分阶段调试执行流程

现在你有了四个启动配置，对应U-Boot的四个生命周期。

1. 从Stage 1开始 ：使用 P4080 U-Boot Stage 1 配置启动调试。调试器会停止在复位向量处。你可以单步执行最初的汇编代码，观察Flash中的启动流程。
2. 切换到Stage 2 ：当代码执行完内存控制器初始化后（通常是一个名为 init_ram 或 setup_ddr 的函数返回后）， 暂停调试 。然后，在CodeWarrior的 Debug 视图中， 终止（Terminate）当前的调试会话 。注意，不是断开连接，是终止整个会话。
3. 重新附着到Stage 2 ：使用 P4080 U-Boot Stage 2 配置启动一个新的调试会话。此时调试器会以新的内存映射重新附着到目标板。你可以继续单步，观察代码准备搬运自身的过程。
4. 切换到Stage 3 ：当U-Boot完成代码自搬运并跳转到RAM后（通常会有一个长跳转指令 bl _main 或跳转到 relocate_code 的返回地址），再次 终止当前会话 。使用 P4080 U-Boot Stage 3 配置启动调试。这时，由于代码地址已变，如果你直接让程序运行，PC会飞掉。你需要 在反汇编窗口中找到当前PC对应的指令，然后通过 Run -> Add Function Breakpoint 在 board_init_r 等C语言入口函数设置断点 ，再继续运行，程序会在RAM中的C代码入口处停下。
5. 切换到Stage 4 ：在U-Boot启用MMU（调用 enable_mmu ）之后，终止会话，用 P4080 U-Boot Stage 4 配置重新附着。此后，你就可以像调试普通程序一样调试完整的U-Boot了，包括设备初始化、环境变量处理、命令解析等。

核心避坑指南 ：

• 地址是灵魂 ： Alternate Load Address 和重定位地址绝对不能错。错误的地址会导致调试器符号表与执行代码完全错位，单步调试如同梦游。务必从U-Boot源码或串口打印中确认这些地址。
• 会话切换要果断 ：阶段切换时，必须终止旧会话，用新配置启动新会话。试图在同一个会话中通过修改配置来适应新阶段，几乎百分之百会失败。
• 初始化脚本是关键 ：第一阶段使用的TCL初始化脚本必须与你的硬件匹配。错误的初始化可能导致内存无法访问，调试器无法工作。如果遇到连接问题，首先检查初始化脚本是否执行成功。

4. 针对不同Flash设备的U-Boot调试要点

U-Boot可以存储在NOR Flash、NAND Flash、SPI Flash或SD卡中。存储介质不同，其启动代码（SPL, Secondary Program Loader）和调试方法也有细微差别。

4.1 NOR Flash 调试

NOR Flash支持芯片内执行（XIP），因此U-Boot可以直接在NOR中运行。调试方法最为直接，即前面描述的 阶段一（Stage 1）配置 。你只需要将U-Boot的ELF文件（ u-boot ）导入工程，并将 Alternate Load Address 设置为NOR Flash在处理器内存映射中的起始地址（如 0xFFF40000 ）即可。

4.2 NAND Flash 调试

NAND Flash不支持XIP，因此需要一小段代码（SPL）先被芯片内部的BootROM加载到SRAM中运行，再由这段SPL将主U-Boot从NAND加载到RAM中。因此，调试NAND启动涉及 两个可执行文件 。

1. 导入SPL ：在创建CodeWarrior工程时， Executable 应选择SPL文件，通常位于U-Boot源码的 nand_spl 目录下，名为 u-boot-spl 。
2. 添加主U-Boot ：在 Debug Configurations 的 Debugger -> Other Executables 页面，点击 Add ，将主U-Boot的ELF文件（ u-boot ）添加进来，并勾选 Load Symbols 。这样调试器就能同时加载两套符号。
3. 调试流程 ：从SPL开始调试，当SPL将主U-Boot加载到RAM并跳转后，调试器会自动切换到主U-Boot的符号。你需要像 阶段三（Stage 3） 那样，知道主U-Boot被加载到的RAM地址，并确保调试配置能正确访问该内存区域。

4.3 SPI Flash / SD Card 调试

对于SPI Flash和SD卡，启动过程与NAND类似，也需要SPL。但此外，镜像的头部需要添加特定的数据结构（如文档中描述的eSPI/SD EEPROM Data Structure），其中包含引导签名、代码长度、源地址、目标地址和启动地址等信息。BootROM会读取这个头部，将用户代码（U-Boot）拷贝到指定内存并执行。

1. 镜像处理 ：你不能直接使用编译生成的 u-boot.bin 。需要使用BSP提供的 boot_format 工具，将其与一个DDR初始化配置文件打包，生成最终的引导镜像。

   # 对于SPI Flash
   ./boot_format config_p4080_ddr.dat u-boot.bin -spi spi-boot.bin
   # 对于SD卡，需要先格式化SD卡分区为vfat，再写入
   sudo ./boot_format config_p4080_ddr.dat u-boot.bin -sd /dev/sdc1
   

2. 调试配置 ：调试时，你仍然导入原始的、带调试信息的 u-boot （ELF）文件。调试的 入口地址（Alternate Load Address） 不再是Flash地址，而是 boot_format 工具配置文件中指定的 目标地址（Target Address） ，也就是U-Boot被SPL加载到RAM中的地址。后续的调试流程与从RAM启动的U-Boot（即 阶段三及以后 ）完全相同。

5. 实战问题排查与调试技巧实录

即使按照指南一步步操作，在实际调试中仍会遇到各种问题。这里记录几个我踩过的“坑”及其解决方案。

5.1 共享库调试常见问题

问题1：调试器可以停在 main 函数，但无法“Step Into”共享库函数。

• 排查 ：
  1. 首先确认在“Other Executables”中，共享库的 Load Symbols 已勾选，且路径正确。
  2. 在调试暂停时，打开“Disassembly”视图，查看调用库函数的那条指令（如 bl 指令）。如果地址是一个明显的非法地址（如 0x0 或 0xdeadbeef ），说明动态链接失败，库根本没加载。
  3. 检查调试控制台输出，看是否有“ error while loading shared libraries: libexample.so: cannot open shared object file ”之类的错误。
• 解决 ：
  • 确保 LD_LIBRARY_PATH 环境变量在调试配置中已正确设置，且值与库的远程下载路径一致。
  • 在目标板（通过串口终端）上，手动执行 export LD_LIBRARY_PATH=/tmp ，然后尝试运行程序，看是否报错。
  • 检查库文件的权限，确保目标板上的用户有执行权限。

问题2：单步调试共享库时，变量显示 <optimized out> 。

• 原因 ：库在编译时开启了编译器优化（如 -O2 ）。
• 解决 ： 务必 使用 -O0 -g3 选项重新编译共享库。在CodeWarrior项目属性中，确保Debug配置的优化级别为 None (-O0) 。

5.2 U-Boot调试常见问题

问题1：使用Stage 1配置连接时，调试器无法暂停在复位向量，或连接后立即跑飞。

• 排查 ：
  1. 检查硬件连接（网线、TAP电源、IP地址）是否正常。
  2. 检查 Alternate Load Address 是否与你的板子Flash地址完全一致。
  3. 最重要 ：检查初始化脚本（TCL文件）是否正确。尝试在初始化脚本中增加一些简单的内存写入-读取测试，确认内存控制器是否已正确初始化。
• 解决 ：尝试在初始化脚本中，将复杂的初始化过程注释掉，只保留最核心的时钟和内存控制器初始化部分。有时BSP提供的脚本包含了不必要的操作，在特定板卡上可能导致问题。逐步放开注释，找到问题点。

问题2：从Stage 1切换到Stage 3后，设置断点无效，程序无法暂停。

• 原因 ：符号地址与代码实际运行地址不匹配。Stage 3配置中 Alternate Load Address 未设置或设置错误。
• 解决 ：
  1. 百分百确认U-Boot重定位后的地址。最可靠的方法是在U-Boot源码 arch/powerpc/lib/board.c 的 relocate_code 函数附近添加打印，或者仔细查看串口启动日志。
  2. 在Stage 3配置中， Alternate Load Address 必须填入这个重定位后的RAM地址。
  3. 切换配置后，如果程序仍在运行，先暂停，然后使用 Run -> Add Function Breakpoint 尝试对 board_init_r 等函数下断点。如果能成功下断并命中，说明配置正确。

问题3：调试过程中，变量查看窗口显示的值全是乱码或无法访问。

• 原因 ：可能处于MMU未开启或地址转换不匹配的阶段。在MMU开启前，访问的是物理地址；开启后，访问的是虚拟地址。调试器可能使用了错误的地址映射。
• 解决 ：
  • 在MMU开启前（Stage 1-3），尝试在“Memory”视图中直接输入物理地址查看内存内容。
  • 在MMU开启后（Stage 4），如果调试器支持MMU感知，它会自动转换。如果不支持，你需要知道U-Boot设置的页表映射关系，手动计算物理地址。一个更简单的方法是：在U-Boot命令行中，使用 md （memory display）命令查看内存，与调试器中的值进行对比验证。

调试U-Boot和共享库是一个需要耐心和细致观察的过程。最关键的是理解每一层抽象背后的实际硬件行为：地址、内存、链接、加载。当你把CodeWarrior IDE的每一个配置项都与这些底层概念对应起来时，问题就变得有迹可循了。这份指南提供的步骤是一个坚实的起点，但真正的精通来自于在具体项目中的反复实践和问题解决。