[参考译文] AM4378：基于 AM4378x 的系统上存在 NAND 引导故障和 ECC 错误

您好、

这是迫切需要的,所以如果你能在今天结束时回答,这将是非常有帮助的。
我还想从硬件的角度检查 AM4378和 NAND 闪存的连接方式是否存在问题。 我将与您分享电路图、您能查看一下吗？

e2e.ti.com/.../3482.Circuit-Diagram.pdf

谢谢、

Conor

您好、

一位客户联系我们、表示他们希望对此问题做出快速响应。 很抱歉、您能在今天结束时告诉我们吗？ 我们还想确认以下几点。
1.出现问题的 AM4378的批号是"631B ZDN"。 是否有此批次的任何报告缺陷信息？
2.是否有任何关于 TI Linux SDK 中 NAND 的缺陷信息报告？

谢谢、

Conor

听起来这个系统已经投入生产了一段时间吗？ 误差只是最近在某些器件上才会出现？ 还有其他单位(有多少个？) 运行而不会出现问题？ 这种理解是否正确？

此外、当您重新刷新故障装置时、它们是否可以正常工作？

此致、Andreas

尊敬的 Andreas：

我们目前正在调查批次编号为"631B ZDN"的3块电路板上发生的 NAND 读取故障。 在其他大约5个电路板上、到目前为止没有发现问题。

*本产品在大规模生产前处于原型阶段。

虽然重新编程可以解决问题、但我们尚未尝试过、因为我们希望先了解根本原因。

在分析过程中、我们发现、当执行 nand 读取命令时、ECC 校正可能无法在 U-Boot 中正常工作。 为了验证这一点、我们使用 U-Boot 将原始 zImage 与从 NAND 中检索到的数据进行比较。

尊敬的 Andreas：

我们在 zImage 区域观察到位错误。 U-Boot 中使用了以下命令：

ーーー μ s
Ruby
=> mw.b 0x82000000 0x55 0x700000
=> n 并读取0x82000000 NAND.kernel 0x700000
OMAP-elm：不可纠正的 ECC 错误
NAND：错误：位翻转位置无效
...(重复)
从偏移300000读取 NAND 失败-74
=>保存 USB 0：1 0x82000000 /zImage_TD2 0x4c4200
将检索到的 zImage_TD2与原始图像进行比较后、我们确认发生了位损坏。
ーーー μ s

我们还尝试使用 nand read.raw 命令来包含 OOB (ECC)数据、并期望检索未校正的数据以供进一步分析。 但是、结果与常规 nand 读取命令中的数据完全相同、并且仍然只显示一个 single-bit 错误、这些错误应该是可纠正的。 尽管如此、还是报告了"不可纠正的 ECC 错误"。

根据这些结果、我们怀疑 ECC 校正可能无法按 U-Boot 读取操作中的预期正常工作。

问题1： 您是否有关于这种行为的任何已知问题或见解、即即使位错误可纠正、U-Boot 中的 ECC 校正也会失败？

问题2： 您还能查看我们之前分享的原理图、确认硬件设计是否存在任何潜在问题吗？

我们感谢您为帮助解决此问题而提供的任何支持。

谢谢、

Conor

尊敬的 Conor：

我注意到在你之前的日志下面的评论..

It will freeze at this point. Sometimes it will start without any errors.

...听起来可能这不是闪存数据损坏问题、而可能是与 AM437x 和 NAND 闪存之间的通信/连接有关的硬件问题。

对此进行的快速测试是通过设置中的位0来减慢 GPMC 控制器的速度  GPMC_CONFIG1 寄存器。 这可以通过三种方法来实现...

1. 按如下方式更改 U-Boot 代码(但这将需要重新编程、这看起来是您不想要的)
   
   

   diff --git a/arch/arm/include/asm/arch-am33xx/mem.h b/arch/arm/include/asm/arch-am33xx/mem.h
   index 0fd52f82f59..f9d7581ceee 100644
   --- a/arch/arm/include/asm/arch-am33xx/mem.h
   +++ b/arch/arm/include/asm/arch-am33xx/mem.h
   @@ -37,7 +37,7 @@
    #define GPMC_SIZE_32M          0xE
    #define GPMC_SIZE_16M          0xF
   
   -#define M_NAND_GPMC_CONFIG1    0x00000800
   +#define M_NAND_GPMC_CONFIG1    0x00000801      /* GPMC_CLK frequency = GPMC_FCLK frequency/2 */
    #define M_NAND_GPMC_CONFIG2    0x001e1e00
    #define M_NAND_GPMC_CONFIG3    0x001e1e00
    #define M_NAND_GPMC_CONFIG4    0x16051807\

   
   
   
   
2. 使用 U-Boot 命令行工具更改该寄存器(使用`md`和`mw`命令)
   
   
3. JTAG 访问

Unknown 说：

Q1. 您是否有关于这种行为的任何已知问题或见解、即即使位错误可纠正、U-Boot 中的 ECC 校正也会失败？

我没有任何关于 AM335x/AM437x 类设备上 NAND/ECC 的实践经验、这个领域的专家将在下周前离开办公室。 但与此同时、我们可以通过搜索 E2E 数据库来尝试查找相关信息。

Unknown 说：

Q2. 您还能查看我们之前分享的原理图以确认硬件设计是否存在任何潜在问题吗？

我将看到是否可以从硬件团队中找到某人来帮助审阅原理图。

Unknown 说：

1. 发生问题的 AM4378的批号是"631B ZDN"。 是否有此批次的任何报告缺陷信息？
2.在 TI 的 Linux SDK 中是否有任何关于 NAND 的报告缺陷信息？

在 NAND 运行方面、我不知道有任何与批次或 SDK 版本相关的问题。

最后、我注意到您使用的是 U-Boot 2021.01、这意味着 AM437x SDK v8.x 我们已经发布 SDK v9.x、它使用较新的 U-Boot 版本2023.04。 您应该尝试查看迁移到最新的 U-Boot 是否会对 NAND 行为产生任何影响。 但即使不是、我也强烈建议使用我们最新/当前的 U-Boot。  请参阅 https://www.ti.com/tool/PROCESSOR-SDK-AM437X

此致、Andreas

大家好！  

我查看了原理图并在内部进行了检查、并具有以下建议：

将数据信号的串联电阻值降至0r。

为数据信号添加外部上拉电阻

禁用数据信号的内部拉电阻

此致、

Sreenivasa.

尊敬的 Andreas 和 Sreenivasa：

根据您最近的反馈、我们有几个后续问题：

问题1：
关于修改 GPMC_CONFIG1寄存器的过程：
以下方法是否正确？

在 U-Boot 提示符处、我们执行：

MD.l 0x50000060
然后、我们获取读取值并仅将低两位(位[1：0])修改为11b、从而使所有其他位保持不变、然后使用以下命令写回：

mw.l 0x50000060 0xXXXXXXX 1
(其中 XXXXXXX 是位[1：0]设置为11b 的值)

之后、我们运行 nand Read 以评估数据损坏频率是否有任何改善。 您能否确认此程序是否合适？

问题2：
我们知道、将数据线上的串联电阻更改为0Ω 是可行的。 但是、在我们的电流板上添加外部上拉电阻器在物理上是很困难的。

您能否阐明为 NAND 数据线推荐外部上拉电阻器的原因？
此外、如果确实需要外部上拉电阻器、您能否就建议的电阻器阻值提供指导？

我们感谢您对上述几点的建议。

此致、

Conor

尊敬的 Andreas 和 Sreenivasa：

即使 GPMC 的运行速度暂时降低、这种现象的频率也没有改变。 我附上了测试结果的日志信息、如果您能查看、我将不胜感激。
e2e.ti.com/.../NAND_5F00_read-test-log.txt

Xiange Tian 说：

我没有在 AM335x/AM437x 类器件上使用 NAND/ECC 的任何实践经验、这方面的专家将在下周前离开办公室。 但与此同时、我们可以通过搜索 E2E 数据库来尝试查找相关信息。

此外、截至上周、AM437x 器件的 NAND/ECC 相关事务方面没有专家、因此目前正在等待响应。 您已经评论过、您计划在本周内重返工作岗位、那么请您再看看这一点吗？

谢谢、

Conor

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

尊敬的 Andreas 和支持成员：

我明白。 由于这是大规模生产之前的问题、如果您能尽快做出响应、会非常有帮助。 我还有以下其他问题。

我们查看了 TI 提供的 U-Boot 文档(doc/README.nand)、并找到了一个围绕第260行的声明、表明这一点
"BCH16对于页面大小为2KB 的 NAND 器件不受支持。"

在我们的当前设计中、我们使用 Micron MT29F8G08ABACAWP、其页面大小为2KB、
并且想确认 BCH8是否是在这种情况下要使用的正确 ECC 模式。

此外、我们的理解是、AM4378中的 ROM 引导加载程序在引导期间从 NAND 读取 SPL (MLO)时、默认使用 BCH8 ECC。
能否请您确认是否正确？

如果我们应该了解有关此行为的任何限制或实施说明、我们将非常感谢您的指导。

谢谢、

Conor