[参考译文] AM4378：关于使用 AM4378进行 NAND 引导的 ECC 方案的阐述

我本周在 PTO 上、但下周我将再次获得 E2E 支持。 谢谢。

尊敬的 Andreas：

我们已经查看了 Micron NAND 数据表、并确认使用的与非器件具有以下特性：

• 页面大小：4096字节

• 备用(OOB)区域：224字节

根据 AM437x TRM 和图5-15"NAND ECC 方案选择过程"、ROM 代码会根据备用区域大小自动在 BCH8和 BCH16之间进行选择。

假设：

1. 每页的扇区数= 4096÷512 = 8个扇区

2. 所需的 ECC 字节= 8 × 26 = 208字节

3. 可用备用区域= 224字节

4. 由于224≥208、因此预计 ROM 代码会选择 BCH16
   
   

我们还检查了相关的 U-Boot 补丁、发现 SPL NAND 驱动程序am335x_spl_bch.c()仅支持具有1扇区粒度的 BCH8 ECC。 它不支持 BCH16或多扇区 ECC 操作。
https://git.ti.com/cgit/ti-u-boot/ti-u-boot/commit/?h=ti-u-boot-2023.04-next&id=c0176ab8dd53f86e193c578ec4781400e9fb18e3

因此、在此配置中、当 ROM 代码选择 BCH16、但 SPL (通过 ROM 加载)使用仅 BCH8的驱动程序时、SPL 无法正确读取和解码其后续阶段(即 U-Boot 正常)。 这可能会由于 SPL 阶段的 ECC 错误而导致引导失败。

为了解决这个问题、U-Boot 补丁在构建 SPL 时似乎会强制 ECC 模式进入 BCH8并进行1扇区操作。 这确保 SPL 将始终使用与 BCH8兼容的格式读取 U-Boot 映像、即使 ROM 最初选择了 BCH16、引导过程也能够成功。 应用补丁后、器件正常工作。

我们希望这一理解是正确的、并希望您对此行为的确认或任何其他见解得到证实。

谢谢、

Conor

尊敬的 Andreas：

关于 AM437x NAND 引导的操作、请确认以下理解是否正确。

1. SPL NAND 驱动程序(AM335x_spl_bch.c)仅支持具有单扇区 ECC 的 BCH8。 它不支持 BCH16或多扇区 ECC 模式。

2. 该定义CONFIG_NAND_OMAP_ECCSCHEME = OMAP_ECC_BCH16_CODE_HW适用于主 U-Boot 和 Linux 内核、但不适用于 SPL。

3. 在构建期间、不会将 ECC 添加到预编译的二进制文件(例如、MLO、u-boot.img)。 相反、在 NAND 刷写时、ECC 由 U-Boot 或 SoC 的 ECC 引擎生成并应用。

4. 因此、必须使用 BCH8 ECC 写入 MLO (SPL 映像)才能被 ROM 和 SPL 正确读取、而 U-Boot 和内核可以使用 BCH16 ECC 写入。

您能否确认上述理解是否正确？

[背景]

• 在u-boot.img写入了没有补丁的器件上、SPL 和 U-Boot 成功加载、但内核由于 ECC 错误而无法引导(如前面连接的引导日志中所示)。

• 仅u-boot.img在使用补丁版本的同一器件上重写、会导致 SPL、U-Boot 和内核成功引导。

• 该u-boot.config文件包含定义#define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH16_CODE_HW,因此我们假设 BCH16正在使用中。

谢谢、

Conor

尊敬的 Conor：

虽然我本周不在办公室、但让我回想起一位可能有一些过去关于 AM43x ECC 主题的经验的同事、看看我们是否能够以某种方式向前推进。

此致、Andreas

尊敬的 Andreas：

由于我们处于预量产阶段、因此我们需要尽快解决此问题、如果您能指派另一位同事处理该问题、直至您返岗、我将不胜感激。

谢谢、

Conor

尊敬的 Conor：
我们将以下 e2e 合并到这一个中、因为两个 e2e 看起来与此问题相同。
https://e2e.ti.com/support/processors-group/processors/f/791/t/1515021
根据其他 e2e 的日志、测试中使用 Linux SDK 8.2。 我的理解是否正确？
去年我在 AM335x 上为另一个客户提供了 GPMC-nand 问题支持、事实证明 Linux SDK 8.2和 SDK 9.1上存在 GPMC-nand 问题。 这是有关如何修复 AM335x 上 SDK 9.1中的 GPMC-nand 问题的常见问题解答、请参考。
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1407372/faq-how-to-flash-and-boot-linux-from-nand-with-am335x-linux-sdk-9-1
此致、
- Hong

Hong Hong：

您使用 Linux SDK 8.2的理解是正确的。

我们知道 SPL 不支持多扇区 ECC。 但是、我们想澄清一下、无论 U-Boot 中的 ECC 配置如何、SPL 是否强制将 ECC 方案切换到 BCH8。

【问题的背景】

• 在具有未打补丁的电路板上u-boot.img、SPL 成功启动并加载 U-Boot、但内核由于 ECC 错误而无法引导。

• 当我们仅u-boot.img将替换为补丁版本时、SPL→U-Boot→Kernel 已成功引导。

• 在中定义了以下配置include/configs/am335x_xxx.h、我们认为使用了 BCH16：

  #define CONFIG_NAND_OMAP_ECCSCHEME OMAP_ECC_BCH16_CODE_HW
  

基于此行为、我们假设 BCH16 ECC 校正正常工作、但我们想确认这一理解是否正确。

此外、我们还想确认以下几点：

• 我们知道、编译的二进制映像(SPL、U-Boot、内核)默认不包含 ECC 数据。 相反、在 NAND 写入操作期间、U-Boot 驱动程序和 CPU 的硬件 ECC 引擎会计算并应用 ECC。

• 我们使用 U-Boot 将每个映像写入其各自的偏移量(例如 SPL 为0x0、U-Boot 为0x20000、内核为0x200000)、并且我们期望根据有效 ECC 设置在写时添加 ECC (OMAP_ECC_BCH16_CODE_HW)。

鉴于上述情况、我们可以假设：

1. 如果在写入时在 U-Boot 中启用了 BCH16、则将 BCH16 ECC 正确写入 NAND？

2. 或者、无论 NAND 内容如何、SPL 是否会在自身运行期间强制切换到 BCH8？

此致、
Conor

尊敬的 Conor：
1/。 ROM 使用基于 NAND 器件 OOB 大小等的 BCH 方案加载第一级 BL (即 SPL)。 这就要求必须使用 RAW+BCH 将 SPL 二进制文件刷写到 NAND 中、并使用由 ROM 确定的匹配 BCH 方案。
2/。 考虑 SPL/u-boot/kernel... 在您的设置中通过 u-boot 全部刷写到 Nand、实际上有必要选择与 ROM 使用的相同 BCH 方案来刷写所有二进制文件(SPL/u-boot/kernel...) n 和。
３。 为了使用 SDK 8.2从 nand 引导、我建议参阅我上次回复中的常见问题解答、并应用 u-boot 补丁(至少前两个补丁)。
此致、
- Hong

 Hong Hong：

感谢您的答复。

我们目前正在调查 AM437x 平台上的 NAND 引导问题。 我们已经通过可用的常见问题解答和论坛审查了已知的与 GPMC-NAND 相关的问题、现在我们正在评估其他职能领域是否存在任何类似的潜在问题。

具体来说、我们担心的是、在某些潜在的情况下、系统似乎正常工作、但可能会因细微或时序相关问题而突然无法启动或运行。

目前、我们已经审查了下列官方资源：

Processor SDK Linux 08.02.00.24版本说明（AM437x）

AM437x 器件勘误表

如果存在与 TI 提供的软件环境(SPL、U-Boot、Processor SDK、ti-u-boot 等)相关的任何其他已知问题(上述来源中记录的问题除外)、 如果您能与我们分享、我们将不胜感激。

谢谢、

Conor

 Hong Hong：

我还有一个问题。
了解本主题中的查询与发行说明中的 LCPD-25271相关、我是否正确？

谢谢、

Conor