[参考译文] AM3358：双源 NAND（不同 OOB 大小）、在 oldversion 的 uboot 中使用单源

Hi Ki-hwan Ahn,

支持较旧的 TI SDK (U-Boot 2014.07、Linux 内核 3.14) 将是一项挑战。
这里有一些一般性意见。
1/。 nand-A 和 nand-B 的页面大小是多少 BCH 方案依赖于页面大小和 OOB 大小。
2/。 我建议使用相同的 nand 配置 (BCH、ONFI 参数...) SPL/u-boot 和 Linux 内核中用于刷写和引导。
３。 GPMC_CONFIGx 寄存器值在 u-boot 中通过硬编码或器件树进行配置、具体取决于 u-boot 版本。 您可能需要检查设置中的 u-boot 版本。
４。 在检测到 nand-A 与 nand-B 的电路板型号后、我们是否使用 DTB 对特定于电路板的配置进行了检查？

此致、
- Hong

​Hong Hong：

​感谢您的跟进和建议。 我有一些关于我们的环境的最新信息。

​1.更新了内核版本与 NAND 规范：

我们的 Linux 内核版本实际上为 4.1.18、我们使用的是 U-Boot 2014.07。

对于硬件、NAND A (Micron) 和 NAND B (Macronix) 具有完全相同的物理规格、但 OOB 总大小除外：

• ​页面大小： 4096 字节
• ​BCH 方案： BCH16（每个 512 字节扇区有 26 字节 ECC）
• ​ECC 布局： 两个芯片使用相同的 CONFIG_SYS_NAND_ECCPOS 映射（从索引 2 到 209）。 ECC 字节和位置完全相同。
• ​唯一的区别是 OOB 总大小（224 字节与 256 字节）。

​2.为什么不能用 dtb 交换方法:

我们理解您关于加载不同 DTB 的建议。 然而、在我们特定的大规模生产设置中、 我们不使用单独的 DTB 文件 （我们依赖于单个附加的 DTB /硬编码设置）。 因此、我们不能根据 ADC 结果在 U-Boot 中动态交换 DTB 文件。

​3.内核 4.1.18（C-驱动程序覆盖）的核心问题:

由于我们不能交换 DTB、因此我们必须继续使用原始架构：通过引导参数传递自定义参数并覆盖 Linux MTD C 驱动程序 (OMAP2.c) 内的设置。

​我们对内核 4.1.18 的严重关切是 ONFI 检测优先级。

如果启用了 CONFIG_SYS_NAND_ONFI_Detection、MTD 驱动程序将自动读取物理 OOB 大小。

为了使用我们的单个映像来支持两个 NAND,我们计划在 MTD 驱动程序中截取它:在 nand_scan_ident() 完成后（并读取 ONFI）,但在 nand_scan_tail() 运行之前,我们将根据我们的 bootargs 强制 MTD->oobsize =224（或 256）。

​由于 ECC 字节和位置完全相同、 在内核 4.1.18 中手动覆盖 C 代码中的 MTD->oobsize 是否安全？ 我们是否应该了解任何隐藏的副作用或 MTD 子系统限制？

​此致、

安基焕

Hi Ki-hwan Ahn,

n 和器件均使用相同的 OOB 利用率：
-字节 0–1：保留用于坏块标记 (BBM)
-字节 2–209：BCH16 数据（26*8=208 字节）
--字节 210–223：空闲/未使用（14 字节）(OOB = 224)
--字节 210–255：空闲/未使用（36 字节）(OOB = 256)

我认为从 ONFI 参数读取 nand 几何体后更新 mtd->oobsize 不会有问题。

2/。 我建议使用相同的 nand 配置 (BCH、ONFI 参数...) SPL/u-boot 和 Linux 内核中用于刷写和引导。
３。 GPMC_CONFIGx 寄存器值在 u-boot 中通过硬编码或器件树进行配置、具体取决于 u-boot 版本。 您可能需要检查设置中的 u-boot 版本。

我建议根据 nand-A 或 nand-B 按需配置 GPMC_CONFIGx 寄存器值

此致、
- Hong

Hong Hong：

感谢您确认 mtd->oobsize 覆盖方法。 这为我们提供了一个清晰的 Linux MTD 端路径。

但是、我们还有一个关于 U-Boot SPL 中的硬件识别阶段的关键问题。 由于电路板受到严格的限制、我们目前没有任何备用的数字 GPIO 引脚可用于识别 NAND 供应商 (Micron 与 Macronix) 的硬件搭接。

为了避免添加新的 GPIO 引脚（需要 PCB 修订版）、我们的管理层询问是否可以使用具有不同电阻分压器的可用模拟引脚 (ADC 通道、例如 AIN4)、以便在早期 U-Boot SPL 阶段区分电路板。

在我们对 PCB 版本做出最终决定之前、我们需要您提供官方的技术建议：

1.可行性和已知风险: 在早期 SPL 引导阶段初始化和读取 ADC 以确定引导路径是否可靠? 考虑到 AM335x 特性、我们应该知道是否将 ADC 读数用作临界启动条件？

2、参考/示例代码： 如果此 ADC 权变措施在技术上可行并推荐使用、您能否提供任何示例代码或参考实现、以便在 AM335x U-Boot SPL 环境中初始化和读取特定的 ADC 通道？

您的客观评估将非常感激、因为这将帮助我们的管理部门最终决定是继续使用此 ADC 权变措施还是为数字 GPIO 执行正确的硬件版本。

此致、安基焕

Hi Ki-hwan Ahn,

下面是一个替代选项

-读取 Nand 设备 ONFI 参数或 SPL/u-boot 中的设备 ID

-根据在 SPL/u-boot 中检测到的 nand 设备 ID (Nand-A vs nand-B ),绑定电路板配置（即包括 nand 设备配置）

此致、

- Hong

Hong Hong：

感谢您的答复。 这是非常有帮助的。

根据您关于在所有阶段保持配置一致的建议、我已 在 SPL/U-Boot 和内核中实现了基于 ID 的分支逻辑来处理不同的 NAND 器件 (128B 与 224B OOB)。

我有两个具体的后续问题：

1. ECCPOS 行为： 正如我提到的、我们的 2018 配置 (OOB 128B、ECCPOS 高达 209) 已使用 8 年。 TI NAND 驱动器是在内部“自动切割“还是根据检测到的 OOB 大小忽略额外的 ECCPOS 条目？ 我想了解为什么这种不一致不会导致问题。

2. 验证方法： 现在我已经实现了基于 ID 的分支以匹配 SPL、U-Boot 和内核的设置、 如何严格验证所有阶段是否都使用完全相同的 ECC 布局？

   • 您是否建议使用特定的命令或寄存器转储来确认 U-Boot 和内核之间的 ECC 布局一致性？

我想确保这是大规模生产的防弹。

此致、

Hi Ki-hwan Ah,

[报价 userid=“4832002“ url=“~/support/processors-group/processors/f/processors-forum/1638118/am3358-dual-sourcing-nand-different-oob-sizes-with-a-single-source-in-uboot-of-oldversion/6316237

对于硬件、NAND A (Micron) 和 NAND B (Macronix) 具有完全相同的物理规格、但 OOB 总大小除外：

• ​页面大小： 4096 字节
• ​BCH 方案： BCH16（每个 512 字节扇区有 26 字节 ECC）
• ​ECC 布局： 两个芯片使用相同的 CONFIG_SYS_NAND_ECCPOS 映射（从索引 2 到 209）。 ECC 字节和位置完全相同。
• ​唯一的区别是 OOB 总大小（224 字节与 256 字节）。

[/报价]

根据您的建议、 为了在所有阶段保持配置一致、我已在 SPL/U-Boot 和内核中实现了基于 ID 的分支逻辑来处理不同的 NAND 器件 (128B 与 224B OOB)。[/报价]

什么是 NAND 器件 OOB 大小？ 256B 还是 128B？
此致、
- Hong

Hong Hong：

很抱歉混淆。 总而言之、 128B OOB 器件是我们的 传统产品 、它使用 单独的固件。 它不是当前的集成固件工程的一部分。

对于我的 当前工程、我将 使用基于 ID 的分支将 NAND A (Micron、224B OOB) 和 NAND B (Macronix、256B OOB) 集成到单个固件中、以确保 SPL、U-Boot 和内核之间的一致性。

关于这一点,我有两个具体的问题:

1.关于传统 128B OOB 设置： 如前所述、 ECCPOS 128B OOB 设备 8 年来、我们使用了高达 209 个、没有出现任何问题。 为什么这样做没有错误？ 此外、您是否建议我们现在纠正此设置（即使它是稳定的）？

2.在 Linux 内核启动之前验证 U-Boot 设置: 我现在根据 NAND ID 更改 U-Boot 中的 OOB 值, Linux 也会通过 ONFI 重新检查它。 在控制权传递给 Linux 之前、如何验证在 U-Boot 中正确应用了 OOB/ECC 设置？ 是否有特定的存储器地址、寄存器或命令来检查最终应用的值？

3、其他测试? 我们已经通过了两种 NAND 类型的物理环境测试（温度/湿度）。 在大规模生产之前是否需要进一步的应力测试、或者这种验证是否足够？

1、Macronix : OOB 256

1) U-Boot (SPL) 消息检查

2) 内核识别检查

1.微米：OOB 224

1) U-Boot (SPL) 消息检查

2) 内核识别检查

此致、

Hi Ki-hwan Ahn,

最好是知道您根据 nand 器件 ID 检测添加了 nand 配置逻辑。

1/。 NAND_ECC_POS[]在 SPL/u-boot 中用于定义 NAND 器件 OOB（存储 ECC 数据）内的确切字节偏移量。 我建议将其设置为匹配 OOB 中的特定 NAND 器件 ECC 布局。
2/。 请执行一些额外的 ECC 布局@u-boot 检查
NAND 信息
NAND 转储#addr

常见问题解答的日志中列出了一个示例
【常见问题解答】GPMC-NAND 引导时 AM64x ROM 中的错误块管理 

此致、
- Hong

尊敬的 TI Hong：

我们正在最终确定 SPL 实现、以使用单个二进制文件支持多个 1GB NAND 供应商 (Micron 224B OOB 与 Macronix/ISSI 256B OOB)。 请在以下几点提供您的最终技术确认：

问题 1： 统一 OOB 缓冲区大小的适用性

鉴于 BCH16 读取流程主要根据编译时参数 (ECCTOTALL、ECCPOS) 访问 ECC 数据、在 AM335x SPL NAND BCH 架构中将 SPL OOB 缓冲区大小统一到最大 256B 的技术上可以接受的实现吗？

问题 2： TI Uniflash 编程一致性

通过 TI Uniflash 刷写映像时、ECC 布局/编程是否由检测到的器件 ID 自动确定？ 还是依赖于所提供的 U-Boot/SPL 二进制文件中定义的 CONFIG_SYS_NAND_OOBSIZE 值？

如果是后者、即使在对 224B OOB NAND (Micron) 进行编程时、使用 256B 设置是否安全？ （我们的测试显示使用此配置成功引导。）

问题 3 对运行时元数据的依赖 (MTD->oobsize)

在最小 SPL BCH 路径中、是否有任何直接依赖于 mtd->oobsize (nand_info[0].oobsize) 而不是编译时常量的关键操作？

我们实现了运行时供应商检测来为此变量分配 224 或 256、但它在实际 BCH 读取路径中似乎未使用。

最终确认请求：

假设除 OOB 大小之外所有 NAND 规范都相同、将最大 OOB 大小设置为低于使用单个 SPL/U-Boot 二进制文件来支持两种 NAND 类型是否足够？

#define CONFIG_SYS_NAND_OOBSIZE 256

此致、

Hi Ki-hwan Ahn,

在 U-Boot 引导过程中、通用原始 NAND 框架查询物理闪存：
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/tree/drivers/mtd/nand/raw/nand_base.c?h=12.00.00.07
-它发送 ONFI 参数查询命令或读取嵌入在芯片内的 JEDEC 闪存 ID。
-它直接从硬件矩阵中提取确切的物理页面布局,并将其直接分配给 MTD->oobsize

我认为您需要自己调整/测试双 NAND 用例。

此致、
- Hong

尊敬的 TI Hong：

感谢您以前的支持和指导。 感谢您在本次调查期间提供的帮助。

我们跟踪了 AM335x 最小 SPL BCH 路径 (AM335x_spl_bch.c)、并使用两个 1GIB NAND 器件执行引导测试。 两个器件使用相同的 SPL 二进制文件成功引导。

我们目前的理解如下：

• 两个 NAND 器件共享相同的参数：

  • 页面大小= 4096B

  • ECC 大小= 512B

  • ECC 字节= 26B

  • BCH16 ECC 方案

• 因此、ECCTOTAL 在这两种情况下都相同：

ECCTOTAL = 26 × 8 = 208 字节

• 两款器件之间的唯一区别是物理 OOB 大小：

  • 微米：224B

  • MXIC/ISSI：256B

从我们的代码跟踪来看、最小 SPL BCH 路径似乎主要依赖于编译时 ECC 配置值 (ECCSIZE、ECCBYTES、ECCPOS、ECCTOTAL)、而不是运行时 OOB 元数据 (MTD->oobsize)。

此外、我们还观察到 CONFIG_SYS_NAND_OOBSIZE 似乎用于静态缓冲区分配：

u_char oob_data[CONFIG_SYS_NAND_OOBSIZE];

而实际的 ECC 提取路径使用：

for (i = 0; i < ECCTOTAL; i++)
    ecc_code[i] = oob_data[nand_ecc_pos[i]];

根据这一实现、我们的理解是有效访问范围由 ECCTOTALL 和 ECCPOS 决定、而不是由完整的 OOB 缓冲区大小本身决定。

在当前配置中：

• ECCTOTAL = 208

• 最大 ECCPOS 索引= 209

由于此访问范围同时处于物理 OOB 边界内：

• 微米：209 < 224

• MXIC/ISSI：209 < 256

使用似乎是：

#define CONFIG_SYS_NAND_OOBSIZE 256

即使对两种 NAND 类型使用单个 SPL 二进制文件、也不应产生功能问题。

您能否确认这一理解是否正确、以及最小 SPL BCH 路径中是否存在任何隐藏的依赖关系、这些依赖关系仍可能依赖于物理 OOB 大小或运行时 MTD -> oobsize 信息？

再次感谢您的参与和支持。 我们希望您进行最终确认。

此致、

Hong Hong：

感谢您的明确确认。

我们非常感谢您在整个调查过程中提供的支持。

此致、