NXP Layerscape平台TF-A启动流程下的DDR初始化与部署实战

最新推荐文章于 2026-06-16 14:14:45 发布

原创最新推荐文章于 2026-06-16 14:14:45 发布 · 442 阅读

6 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#TF-A #DDR内存初始化 #NXP Layerscape

AI助手已提取文章相关产品：

1. 项目概述

在嵌入式系统开发，尤其是基于NXP Layerscape系列高性能SoC（如LS1043A、LS1088A、LX2160A等）的项目中，系统启动流程的稳定性和效率是项目成败的基石。而在这个流程中， DDR内存的初始化 无疑是其中最复杂、也最关键的环节之一。它直接决定了处理器能否在脱离片上SRAM后，正确、稳定地访问外部大容量RAM，进而加载并运行U-Boot、Linux内核等后续组件。过去，这项工作通常由U-Boot的板级初始化代码负责，但随着系统对安全启动（Secure Boot）和可信执行环境（TEE）的要求日益提高，ARM的 TF-A（Trusted Firmware-A） 成为了更现代、更标准化的选择。

一个显著的变化是，在较新的Layerscape SDK（LSDK）中，DDR初始化的职责已经从U-Boot移交给了TF-A的BL2阶段。这种架构迁移不仅仅是代码位置的改变，它意味着更早的内存可用性、更清晰的信任链划分，以及对不同启动介质（如QSPI NOR、SD卡、eMMC）更统一的管理。然而，这也给开发者带来了新的挑战：如何在TF-A的框架下，为千差万别的硬件板卡（可能使用标准DIMM、Mock DIMM或分立式DDR颗粒）正确配置DDR参数？生成的 bl2.pbl 和 fip.bin 镜像又该如何部署到不同的存储介质上？

本文将从一个资深嵌入式系统工程师的视角，深入剖析NXP Layerscape平台在TF-A启动流程下的DDR初始化机制与完整部署实践。我会结合官方文档和实际项目中的踩坑经验，不仅告诉你“怎么做”，更会解释“为什么这么做”，并分享那些在标准手册里不会写的调试技巧和注意事项。无论你是正在将旧项目迁移到TF-A流程，还是为新板卡进行启动适配，这篇文章都将提供一份可直接参考的“实战地图”。

2. 核心思路与架构迁移解析

2.1 为何要将DDR初始化移至TF-A？

在传统的“BootROM -> U-Boot (含DDR Init) -> Linux”启动流程中，U-Boot在完成DDR初始化后，自身会重定位到DDR中运行，然后再加载内核。这个模式简单直接，但也存在一些局限性：

安全边界模糊 ：U-Boot通常被认为是“非安全世界”的软件，让非安全软件在最早阶段初始化关键硬件（如DDR），不利于构建从硬件信任根开始的完整信任链。
BL2阶段能力浪费 ：TF-A的BL2阶段运行在芯片的片上RAM（如OCRAM）中，其代码体积受限于SRAM大小。在BL2阶段初始化DDR，意味着BL2自身以及后续需要加载的BL31、BL32（如OP-TEE）、BL33（U-Boot）镜像，都可以被加载到容量大得多的DDR中，这极大地放宽了对每个阶段镜像大小的限制，为加入更复杂的固件功能（如更完备的硬件初始化、安全服务）提供了可能。
统一初始化入口 ：对于支持多种启动介质（NOR/NAND/SD/eMMC）的SoC，BootROM会根据引脚配置选择介质并加载PBL（Pre-Boot Loader，通常由RCW配置生成）和BL2。将DDR初始化放在BL2中，使得无论从哪种介质启动，内存初始化的逻辑都是同一份代码，提高了代码的复用性和可维护性。

因此，NXP在新的LSDK中，为LS1012A、LS1043A、LS1046A、LS1088A、LS2088A、LX2160A等平台引入了“TF-A boot flow”。其核心变化就在于： DDR初始化（DDR Init）的代码从U-Boot移到了TF-A的BL2中执行 。新的启动链条变为： Boot ROM -> BL2 (DDR Init) -> BL31 -> BL33 (U-Boot/UEFI) -> Linux 。

2.2 TF-A启动镜像组成解析

理解镜像组成是进行部署的前提。在新的流程下，我们主要和两个由TF-A构建的镜像文件打交道：

bl2_<boot_mode>.pbl ：这是系统的“第二级引导程序”。它不是一个单纯的BL2镜像，而是一个 复合镜像 。其生成过程是：将特定启动模式（如 qspi , sd , nor ）的RCW二进制文件（ rcw_<boot_mode>.bin ）与编译出的BL2二进制（ bl2.bin ）通过 pbl 工具拼接而成。BootROM会首先加载并运行这个 .pbl 文件。其中，BL2部分就包含了我们关注的DDR初始化代码。
fip.bin ：即Firmware Image Package。这是一个由 fiptool 工具创建的容器镜像，内部打包了后续所有阶段的固件：
- BL31 ：EL3运行时固件，提供电源管理、安全监控等基础服务。
- BL32 （可选）：可信操作系统（Trusted OS），例如OP-TEE，用于提供安全服务。
- BL33 ：非安全世界的引导程序，即我们熟悉的U-Boot或UEFI镜像。

这种分离的设计带来了部署上的灵活性： bl2_.pbl 包含了硬件相关的早期初始化（如时钟、DDR），通常烧写在存储介质的起始固定位置；而 fip.bin 包含了系统服务和应用引导程序，可以单独更新。

2.3 板级支持的关键： `_init_ddr` 函数

TF-A的BL2是一个通用框架，它并不知道你的板子上用的是哪种DDR芯片、如何配置。这部分硬件相关的知识，通过一个 板级特定的函数 _init_ddr 来注入。

这个函数是连接TF-A框架和NXP私有DDR驱动程序的桥梁。它的核心职责是：

收集并填充DDR配置信息（如控制器数量、时钟频率、DIMM信息或静态参数）。
调用NXP提供的通用DDR初始化函数 dram_init() 。
处理DDR初始化后的相关勘误（Errata）应用。
返回初始化成功的DDR总容量。

开发者需要根据自己板卡的硬件设计，在对应的板级目录（例如 plat/nxp/soc-ls1043/ls1043ardb/ ）下实现这个函数。接下来，我们就深入三种最常见的硬件场景，看看具体该如何实现。

3. 三种DDR硬件配置的实战详解

NXP的DDR驱动层为不同的硬件形态提供了三种适配模式：DIMM（带SPD）、Mock DIMM（静态时序）和Discrete DDR（静态寄存器）。选择哪种模式，完全取决于你的硬件设计。

3.1 DIMM模式：让SPD说话

如果你的板卡使用了标准的 DDR4 DIMM内存条 ，那么恭喜你，这是最“省心”的模式。DIMM上的SPD（Serial Presence Detect）EEPROM芯片已经存储了该内存条的所有时序参数、容量信息。驱动的工作就是通过I2C总线读取这些信息，并自动配置DDR控制器。

你需要做的配置工作：

定义关键宏 ：在板级的 platform_def.h 文件中，你需要告诉驱动有几个DDR控制器，每个控制器上插了几个DIMM。
```
// 示例：LS1088A有两个DDR控制器，每个控制器插了1条DIMM
#define NXP_DDRCLK_FREQ          100000000 // DDR参考时钟频率，单位Hz
#define NUM_OF_DDRC              2         // DDR控制器数量
#define DDRC_NUM_DIMM            1         // 每个控制器上的DIMM数量
```
注意： DDRC_NUM_DIMM 指的是每个控制器的DIMM数，不是总数。对于双通道板载内存（没有物理DIMM插槽），通常需要配置为 1 ，表示一个“虚拟”的DIMM。

实现 _init_ddr 函数 ：在 ddr_init.c 中，你需要提供一个基本的实现，将上述宏定义的信息传递给驱动数据结构。

long long _init_ddr(void)
{
    struct ddr_info info;
    struct sysinfo sys;
    long long dram_size;

    zeromem(&sys, sizeof(sys));
    get_clocks(&sys); // 获取系统时钟，驱动会从中计算DDR时钟
    debug("platform clock %lu\n", sys.freq_platform);
    debug("DDR PLL1 %lu\n", sys.freq_ddr_pll0);
    debug("DDR PLL2 %lu\n", sys.freq_ddr_pll1);

    zeromem(&info, sizeof(struct ddr_info));
    info.num_ctlrs = NUM_OF_DDRC;        // 传递控制器数量
    info.dimm_on_ctlr = DDRC_NUM_DIMM;   // 传递每个控制器的DIMM数
    info.clk = get_ddr_freq(&sys, 0);    // 计算最终的DDR数据率时钟
    info.ddr[0] = (void *)NXP_DDR_ADDR;  // DDR控制器的基地址

    dram_size = dram_init(&info);        // 调用核心初始化函数

    if (dram_size < 0)
        ERROR("DDR init failed\n");

    // 可选：应用DDR控制器勘误，例如A-008850
    erratum_a008850_post();

    return dram_size; // 返回初始化成功的总容量
}

关键点解析 ：

get_clocks(&sys) ：这个函数会从SoC的时钟控制器读取PLL配置，计算出平台时钟和DDR PLL的频率。 get_ddr_freq() 会基于这些值计算出DDR的数据速率（如1600MT/s）。
NXP_DDR_ADDR ：这是一个SoC相关的内存映射地址，指向第一个DDR控制器的寄存器空间。对于多控制器SoC，驱动内部会通过偏移量计算其他控制器的地址。
dram_init(&info) ：这是NXP DDR驱动的入口。它会根据 info 中的配置，发起I2C通信读取SPD，解析数据，并完成所有DDR控制器和PHY的寄存器编程。
返回值 ：如果成功，返回总字节容量；失败则返回负数。BL2会检查这个返回值。

实操心得与避坑指南：

I2C总线确认 ：确保在BL2更早的初始化阶段（可能在平台特定的 plat_ 开头的函数中），连接DIMM SPD的I2C总线控制器已经正确初始化（时钟、引脚复用等）。否则驱动会读不到SPD数据。
SPD地址 ：驱动通常使用标准的SPD I2C地址（如0x50, 0x51）。如果你的设计使用了地址选择电阻改变了地址，需要检查驱动代码是否支持，或是否需要修改I2C扫描逻辑。
调试信息 ：在早期调试阶段，可以临时增加 INFO() 级别的打印，输出读取到的SPD关键字段（如速度、容量、时序），便于验证硬件连接和SPD内容是否正确。

3.2 Mock DIMM模式：固定时序参数

很多嵌入式设备为了降低成本、减少面积，会直接使用 贴片式的DDR颗粒 ，而不是DIMM插槽。这种情况下，没有SPD芯片。我们需要将DDR颗粒的时序参数“硬编码”到代码中，这就是Mock DIMM模式。

配置步骤：

定义宏并启用Mock DIMM ：在 platform_def.h 中，除了定义控制器和DIMM数量，必须定义 CONFIG_DDR_NODIMM 来告知驱动不使用SPD。

#define NXP_DDRCLK_FREQ         100000000
#define NUM_OF_DDRC             1
#define DDRC_NUM_DIMM           1
#define CONFIG_DDR_NODIMM       // 关键：启用Mock DIMM模式

实现 ddr_get_ddr_params 函数 ：这是Mock DIMM模式的核心。你需要在 ddr_init.c 中提供一个全局的 dimm_params 结构体变量，并实现一个函数来填充它。

// 定义一个全局结构体，存放你的DDR颗粒的所有时序参数（单位：皮秒ps）
struct dimm_params ddr_raw_timing = {
    .n_ranks = 1,                     // 1个Rank（片选）
    .rank_density = 2147483648u,      // 单个Rank密度，单位字节？这里通常是位？需确认。示例值可能不对。
    .capacity = 2147483648u,          // 总容量，单位字节？示例为2GB？需根据颗粒手册计算。
    .primary_sdram_width = 16,        // 数据总线位宽，如16位
    .ec_sdram_width = 0,              // ECC位宽，无ECC则为0
    .device_width = 16,               // 单个DDR颗粒的数据位宽
    .die_density = 0x4,               // 芯片密度编码，参考JEDEC标准
    .rdimm = 0,                       // 0表示UDIMM（非寄存式）
    .mirrored_dimm = 0,               // 是否镜像，通常为0
    .n_row_addr = 15,                 // 行地址位数
    .n_col_addr = 10,                 // 列地址位数
    .bank_addr_bits = 0,              // Bank地址位数，通常为0（由bank_group_bits替代）
    .bank_group_bits = 2,             // Bank Group位数，DDR4重要参数
    .edc_config = 0,                  // ECC配置，无ECC为0
    .burst_lengths_bitmask = 0x0c,    // 支持的突发长度，如BL8
    .tckmin_x_ps = 938,               // 最小时钟周期（对应最大频率），例如DDR4-2133的tCK=938ps
    .tckmax_ps = 1600,                // 最大时钟周期
    .caslat_x = 0x000FFC00,           // 支持的CAS延迟，位掩码格式
    .taa_ps = 13750,                  // CL * tCK 的时间
    .trcd_ps = 13750,                 // RAS to CAS Delay
    .trp_ps = 13750,                  // Row Precharge Time
    .tras_ps = 32000,                 // Row Active Time
    .trc_ps = 45750,                  // Row Cycle Time (tras + trp)
    .twr_ps = 15000,                  // Write Recovery Time
    .trfc1_ps = 350000,               // Refresh Cycle Time 1 (标准)
    .trfc2_ps = 260000,               // Refresh Cycle Time 2 (降频)
    .trfc4_ps = 160000,               // Refresh Cycle Time 4 (自刷新)
    .tfaw_ps = 21000,                 // Four Activate Window
    .trrds_ps = 3000,                 // Read to Read Delay (不同Bank Group)
    .trrdl_ps = 4900,                 // Read to Read Delay (相同Bank Group)
    .tccdl_ps = 5000,                 // Read to Read Delay (相同Bank Group，带CCD）
    .refresh_rate_ps = 7800000,       // 刷新间隔
};

int ddr_get_ddr_params(struct dimm_params *pdimm, struct ddr_conf *conf)
{
    static const char dimm_model[] = "Fixed DDR on board";

    // 告诉驱动哪个DIMM插槽是有效的。例如，单控制器单DIMM，则 conf->dimm_in_use[0] = 1;
    conf->dimm_in_use[0] = 1;

    // 将我们定义好的时序参数拷贝到驱动提供的结构体中
    memcpy(pdimm, &ddr_raw_timing, sizeof(struct dimm_params));
    memcpy(pdimm->mpart, dimm_model, sizeof(dimm_model) - 1);

    // 返回有效的DIMM掩码。例如，单DIMM返回0x1。
    return 0x1;
}

参数来源与计算 ：所有这些时序参数（ taa , trcd , trp , tras , trc , trfc1/2/4 , tfaw , trrds/l , tccdl ）都必须严格遵循你使用的 DDR颗粒数据手册（Datasheet） 。不要从其他板卡示例中盲目拷贝。 tckmin_x_ps 决定了DDR的运行频率（频率 = 1e12 / tckmin_x_ps）。 caslat_x 是一个位掩码，表示支持的CL值，需要根据频率和颗粒规格设置。

注意事项：

精度至关重要 ：时序参数的单位是皮秒(ps)，1纳秒=1000皮秒。一个错误的参数就可能导致内存不稳定，表现为系统随机死机、数据错误。务必反复核对数据手册。
容量计算 ： rank_density 和 capacity 字段的单位需要仔细确认驱动代码的期望值（是字节还是位）。通常， capacity 应该是总字节数。计算方式： 容量 = 2^(行地址+列地址) * 数据位宽 / 8 * Rank数 。
调试方法 ：当DDR初始化失败时，Mock DIMM模式比DIMM模式更难调试，因为无法通过SPD验证硬件。此时，应首先用示波器或逻辑分析仪确认DDR时钟和电源稳定，然后检查驱动打印的配置信息是否与预期一致。可以尝试降低频率（增大 tckmin_x_ps ）或放宽时序来测试。

3.3 Discrete DDR模式：直接寄存器配置

这是最底层、最灵活的配置方式，主要用于 非常规或需要极致性能调优 的场景。在这种模式下，开发者需要直接提供一个完整的DDR控制器和PHY寄��器配置数组（ ddr_cfg_regs ），驱动会将这些值直接写入硬件寄存器，完全绕过内部的时序参数计算逻辑。

配置步骤：

定义宏并启用静态DDR ：在 platform_def.h 中定义 CONFIG_STATIC_DDR 。
```
#define CONFIG_STATIC_DDR
```

实现 board_static_ddr 函数并提供寄存器配置 ：

#ifdef CONFIG_STATIC_DDR
// 这是一个针对特定频率（如1600MT/s）和硬件的完整寄存器配置示例
const struct ddr_cfg_regs static_1600 = {
    .cs[0].config = 0x80040322,   // CS0配置：使能、类型等
    .cs[0].bnds = 0x7F,           // CS0边界地址
    .sdram_cfg[0] = 0xC50C0000,   // SDRAM配置寄存器0
    .sdram_cfg[1] = 0x401100,     // SDRAM配置寄存器1
    .timing_cfg[0] = 0x91550018,  // 时序配置0 (RAS, CAS, WR, etc.)
    .timing_cfg[1] = 0xBBB48C42,  // 时序配置1 (RFC, FAW, etc.)
    .timing_cfg[2] = 0x48C111,    // 时序配置2
    .timing_cfg[3] = 0x10C1000,   // 时序配置3
    // ... 更多时序、模式寄存器、ZQ校准、写均衡等配置
    .wrlvl_cntl[0] = 0x8675F607,  // 写均衡控制0
    .wrlvl_cntl[1] = 0x7090807,   // 写均衡控制1
    .wrlvl_cntl[2] = 0x7070707,   // 写均衡控制2
    .debug[28] = 0x00700046,      // 调试寄存器
};

long long board_static_ddr(struct ddr_info *priv)
{
    // 将静态配置拷贝到驱动信息结构体中
    memcpy(&priv->ddr_reg, &static_1600, sizeof(static_1600));
    // 必须返回一个硬编码的DDR大小（字节）
    return 0x80000000; // 例如，返回2GB
}
#endif

寄存器值来源 ：这些神秘的十六进制数值从哪里来？通常有两个途径：

参考设计 ：从NXP提供的官方评估板（如LS1043ARDB、LS1088ARDB）的代码中，找到与你使用的DDR颗粒和设计频率最接近的配置，作为起点。
工具生成 ：使用NXP提供的 DDR配置工具 （如DDR Stress Test Tool或寄存器计算工具）。这些工具可以根据你输入的DDR颗粒型号、PCB拓扑结构、目标频率，自动计算出一套优化的寄存器配置。 这是最推荐的方式 ，可以避免手动计算带来的错误。

特别说明：对于LX2160A等高级平台 LX2160A使用了更复杂的DDR4 PHY，除了静态寄存器配置，还需要提供PHY训练固件（微代码）。这就是为什么在LX2160A的部署流程中，有一个额外的步骤“编译DDR FIP镜像”。这个镜像（ fip_ddr_all.bin ）包含了针对UDIMM和RDIMM的1D/2D训练IMEM/DMEM镜像，在DDR初始化时会被加载到PHY的微控制器中执行，以完成更精细的时序校准。

模式选择建议：

首选DIMM模式 ：如果硬件允许，使用带SPD的DIMM是最简单、最不易出错的方式。
次选Mock DIMM ：对于固定贴片DDR颗粒的设计，Mock DIMM模式是平衡复杂度和灵活性的最佳选择。你需要仔细填写时序参数。
慎用Discrete DDR ：除非你有充分的理由（如性能极限调优、非标准硬件），或者有可靠的寄存器配置来源（如官方工具生成），否则不建议直接使用此模式，因为调试难度最大。

4. TF-A镜像编译与部署全流程

理解了DDR配置，下一步就是将包含这些代码的TF-A镜像编译出来，并烧写到目标板。这个过程涉及多个仓库的协同工作。

4.1 环境准备与代码获取

假设你的开发环境是Ubuntu 18.04或20.04，并已安装好ARM64的交叉编译工具链（如 aarch64-linux-gnu- ）。

# 创建工作目录
mkdir -p ~/lsdk/tfa-build
cd ~/lsdk/tfa-build

# 1. 克隆并编译RCW (Reset Configuration Word)
git clone https://source.codeaurora.org/external/qoriq/qoriq-components/rcw
cd rcw
git checkout -b LSDK-19.09 LSDK-19.09 # 切换到与你的SDK对应的标签
cd ls1088ardb # 进入你的平台目录
# 如果需要修改RCW配置（如SerDes协议、时钟分频），在此编辑 .rcw 源文件
make
# 编译后，在类似 rcw/ls1088ardb/FCQQQQQQQQ_PPP_H_0x1d_0x0d/ 的目录下生成 rcw_xxxx.bin

RCW是芯片上电后BootROM读取的第一段配置代码，它决定了启动设备、SerDes Lane配置、时钟等最基础的硬件状态。务必选择与你的板卡启动模式匹配的RCW二进制文件。

4.2 编译U-Boot (BL33)

# 2. 克隆并编译U-Boot
cd ~/lsdk/tfa-build
git clone https://source.codeaurora.org/external/qoriq/qoriq-components/u-boot.git
cd u-boot
git checkout -b LSDK-19.09 LSDK-19.09
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-
make distclean
# 注意：必须使用 _tfa_defconfig
make ls1088ardb_tfa_defconfig
make -j$(nproc)
# 生成 u-boot.bin

关键点 ：必须使用 <platform>_tfa_defconfig 配置。这个配置与普通的 _defconfig 不同，它确保U-Boot知道它将被TF-A（BL31）以BL33的身份加载，并做出相应的行为调整（如不重复初始化DDR）。

4.3 编译TF-A (BL2, BL31, FIP)

这是核心步骤，我们将生成 bl2_.pbl 和 fip.bin 。

# 3. 克隆并编译TF-A
cd ~/lsdk/tfa-build
git clone https://source.codeaurora.org/external/qoriq/qoriq-components/atf
cd atf
git checkout -b LSDK-19.09 LSDK-19.09
export ARCH=arm64
export CROSS_COMPILE=aarch64-linux-gnu-

# 假设我们编译QSPI NOR启动的镜像，且不使用OP-TEE (BL32)
# 首先编译BL2镜像，并打包成 .pbl
# RCW_PATH 替换为你编译出的rcw二进制文件路径
RCW_PATH=~/lsdk/tfa-build/rcw/ls1088ardb/FCQQQQQQQQ_PPP_H_0x1d_0x0d/rcw_1600_qspi.bin
make PLAT=ls1088ardb bl2 BOOT_MODE=qspi pbl RCW=$RCW_PATH

# 编译FIP镜像，包含BL31和BL33 (U-Boot)
UBOOT_PATH=~/lsdk/tfa-build/u-boot/u-boot.bin
make PLAT=ls1088ardb fip BL33=$UBOOT_PATH

编译完成后，在 build/ls1088ardb/release/ 目录下可以找到：

bl2.bin : 纯BL2二进制。
bl2_qspi.pbl : 与RCW合并后的PBL镜像，用于烧写。
bl31.bin : EL3运行时固件。
fip.bin : 包含BL31和BL33的最终镜像包。

如果需要OP-TEE (BL32) ，则编译命令稍作修改：

# 假设已编译好 tee.bin
OPTEE_PATH=~/lsdk/tfa-build/optee_os/out/arm-plat-ls/core/tee.bin
make PLAT=ls1088ardb bl2 SPD=opteed BOOT_MODE=qspi BL32=$OPTEE_PATH pbl RCW=$RCW_PATH
make PLAT=ls1088ardb fip BL33=$UBOOT_PATH SPD=opteed BL32=$OPTEE_PATH

4.4 镜像烧写指南

烧写方式取决于你当前板卡所处的状态和可用的工具。最常见的方式是通过 已运行的U-Boot，使用TFTP网络加载新镜像进行更新 。

场景：从旧版（PPA流程）U-Boot更新到TF-A流程

假设板卡当前可以从QSPI NOR Flash0启动旧的U-Boot，我们打算将新的TF-A镜像烧写到Flash1，并从Flash1启动测试。

准备TFTP服务器 ：将编译好的 bl2_qspi.pbl 和 fip.bin 放到开发主机的TFTP目录下。
启动旧版U-Boot ，进入命令行。

烧写 BL2 到 Flash1 ：

=> sf probe 0:1  # 探测并切换到QSPI Flash1
=> tftp 0xa0000000 bl2_qspi.pbl  # 通过TFTP加载镜像到内存
=> sf erase 0x0 +$filesize       # 擦除Flash1从0地址开始，大小为文件长度的区域
=> sf write 0xa0000000 0x0 $filesize # 从内存写入Flash

注意：


   $filesize

是U-Boot环境变量，在执行


   tftp

命令后会自动设置为刚加载文件的大小。

烧写 FIP 到 Flash1 ：

=> tftp 0xa0000000 fip.bin
=> sf erase 0x100000 +$filesize  # 通常FIP从1MB偏移开始存放
=> sf write 0xa0000000 0x100000 $filesize

切换启动Bank ：NXP板卡通常有拨码开关或寄存器可以配置从Flash0或Flash1启动。将开关拨到从Flash1启动的位置，然后复位板卡。

其他启动介质命令摘要：

启动介质	烧写 BL2 命令示例	烧写 FIP 命令示例	说明
SD卡	`mmc write 82000000 8 <blk_cnt>`	`mmc write 82000000 800 <blk_cnt>`	`8` 和 `800` 是SD卡上的LBA起始块号，需根据分区布局确定。 `blk_cnt = 文件字节数 / 512` 。
NOR Flash	`erase 64000000 +$filesize; cp.b 82000000 64000000 $filesize`	`erase 64100000 +$filesize; cp.b 82000000 64100000 $filesize`	假设交替Bank起始地址为 `0x64000000` 和 `0x64100000` 。
NAND Flash	`nand erase 0x0 $filesize; nand write 82000000 0x0 $filesize`	`nand erase 0x100000 $filesize; nand write 82000000 0x100000 $filesize`	NAND需要先擦除再写入。

部署后的启动流程验证： 成功启动后，在串口日志中你应该能看到类似以下的输出序列，这表明TF-A流程已成功运行：

[BL2]： ... DDR初始化日志 ...
[BL31]： ... 
[BL33]：U-Boot 2020.04 ...

如果卡在BL2阶段，特别是DDR初始化失败，那么就需要回到前面的章节，仔细检查你的DDR配置代码。

5. 常见问题排查与调试技巧

在实际移植过程中，你几乎一定会遇到DDR初始化失败的问题。以下是一些常见的故障现象和排查思路。

5.1 DDR初始化失败典型现象

完全死寂 ：上电后串口无任何输出。这可能是因为BL2镜像本身损坏、烧写位置不对、或者DDR初始化失败导致BL2无法将自身复制到DDR运行（如果BL2代码超过SRAM容量）。 排查顺序 ：确认RCW配置与硬件匹配 -> 确认 .pbl 文件烧写到正确偏移地址 -> 使用JTAG调试器单步跟踪BL2代码，看死在何处。
打印部分信息后停止 ：串口输出了BL2的早期日志（如平台初始化、时钟设置），但在“DDR Init”相关日志后停止。这强烈指向DDR配置问题。 排查重点 ：检查 _init_ddr 函数是否被正确调用和链接；检查传递给 dram_init() 的参数（控制器数、时钟频率）是否正确；对于Mock DIMM/Discrete DDR，逐一核对时序参数或寄存器值。
数据访问错误 ：系统能启动到U-Boot甚至Linux，但运行大型程序或进行内存测试时出现随机崩溃、数据错误。这通常是 内存不稳定 的表现。 排查重点 ：时序参数过于紧张（特别是 tRFC , tFAW , tRRD 等）；PCB布线质量问题导致信号完整性差；电源纹波过大。可以尝试放宽时序参数（增加ps值），或降低DDR运行频率进行测试。

5.2 调试手段与工具

利用TF-A调试打印 ：在TF-A的Makefile或编译命令中，可以指定不同的日志级别。在 atf 目录下编译时，尝试：
```
make PLAT=ls1088ardb bl2 BOOT_MODE=qspi pbl RCW=... LOG_LEVEL=50
```
更高的 LOG_LEVEL （如50）会输出更多DEBUG和INFO信息，有助于看到DDR驱动内部的详细步骤和读取到的SPD值。
JTAG调试器 ：这是最强大的手段。通过JTAG（如Lauterbach、DS-5、OpenOCD）连接板卡，可以在BL2代码中设置断点，单步执行，查看/修改寄存器，观察DDR控制器和PHY的状态寄存器（如 DDR_SDRAM_CFG , TIMING_CFG_0 等），以及检查AHB总线上的访问是否成功。
示波器/逻辑分析仪 ：测量DDR时钟（DDR_CLK_P/N）是否稳定，频率是否正确。测量DDR电源电压（VDD、VTT、VREF）的纹波是否在规范内。对于高级调试，可以使用带DDR协议解码功能的逻辑分析仪，捕捉初始化过程中的命令总线（CKE, CS, RAS, CAS, WE）和数据总线活动，看是否与JEDEC标准序列相符。
寄存器对比法 ：如果你有一块工作正常的参考板（如官方开发板），可以在其U-Boot或Linux下使用 md 命令导出DDR控制器所有关键寄存器的值。然后在你自己的板卡上，在Discrete DDR模式的配置数组中，填入这些寄存器值进行测试。如果这样能工作，说明问题出在参数计算或PCB上；如果仍不能工作，则可能是电源、时钟或PCB硬件的根本性差异。

5.3 针对LX2160A等平台的特别注意事项

LX2160A的DDR子系统更为复杂，引入了DDR4 PHY和独立的训练固件。除了前述的 fip_ddr_all.bin 需要正确生成和包含外，还需注意：

PHY固件版本匹配 ：确保从NXP官方仓库（ ddr-phy-binary ）下载的PHY训练固件二进制与你的LSDK版本和硅片版本（Rev）匹配。不匹配的固件可能导致训练失败。
static_dimm 结构体 ：在Discrete DDR模式下，除了提供寄存器配置，还必须正确填充一个 struct dimm_params static_dimm 结构体，用于告知PHY驱动一些基本的DDR属性（如位宽、Rank数、是否RDIMM等）。这个结构体的信息必须与你实际的硬件和寄存器配置严格一致。
2D训练 ：对于高密度或多Rank的内存配置，可能需要启用2D训练（眼图扫描）以获得最佳信号质量。这需要在RCW或后续配置中启用相关选项，并确保 fip_ddr_all.bin 中包含了2D训练的IMEM/DMEM镜像。

移植DDR初始化是一项细致且需要耐心的工作，它横跨硬件、固件和软件。最有效的策略是 循序渐进 ：先从最低频率、最宽松的时序开始，确保内存能进行最基本的读写；然后再逐步调整到目标频率和优化时序。充分利用官方工具和参考设计，能帮你避开很多深坑。当你看到“DDR Init Success”的日志，并且系统稳定地跳入U-Boot时，那份成就感无疑是巨大的。

您可能感兴趣的与本文相关内容