[参考译文] AM3354：预刷写 NAND 时块管理不良

admin

Other Parts Discussed in Thread: AM3354

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/581863/am3354-bad-block-management-when-pre-flashing-nand

器件型号：AM3354

您好！

我正在使用基于 Sitara AM3354处理器的 ODM 板。要在每个分区上加载的映像文件包括：

DEV：   size       erasesize        名称
mtd0：00020000          00020000      "xload"            === MLO
mtd1：00020000          00020000      "xload_Backup1"       <= MLO
mtd2：00020000          00020000      "xload_Backup2"       <= MLO
mtd3：00020000          00020000      "xload_backup3"       <= MLO
mtd4：00080000          00020000      "光箱"          <== barebox.bin
mtd5：00020000          00020000      "bareboxenv"             <= barebox.env
mtd6：00400000          00020000      "内核"            <=uImage-pcm051
mtd7：1fae0000           00020000      "根"             === rootfs.ubi

闪存 NAND 的当前方法是将电路板连接到以太网、并按照文档中的规定从服务器加载 U-boot 映像、我们没有遇到任何问题。

此时、我们将改用大规模生产方法、因此我们将使用 NAND 编程器、我有关于管理坏块的问题。简而言之、我知道当处理器在前四个区域块(绝对地址)中搜索有效的引导映像时、必须加载 MLO 四次。但是、如果在"barebox.bin"或"bareboxenv"映像中找到坏块、会发生什么情况？如果在预期位置发现坏块、则处理器或 MLO 是否具有任何坏块管理功能来写入/读取"barebox.img"或"bareboxenv"？那么、NAND 编程器是否应该有一个简单的算法来管理这一点？

感谢您的帮助和支持

此致

豪尔赫

8 年多前

0 admin 8 年多前

TI__Guru**** 2614265 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好！

请参阅 processors.wiki.ti.com/.../Linux_Core_NAND_User's_Guide NAND 应使用 U-boot、RESP 中使用的 ECC 进行预闪存。内核。

0 admin 8 年多前

TI__Guru**** 2614265 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Biser、

感谢您提供有关使用与 U-Boot 相同的 ECC 的信息。

此外、我对将不同的图像处理到 NAND 中有一些疑问。我的问题与下表有关、请参阅"AM335x U-Boot 用户指南"：

---------------- !-->0x00000000--> SPL 启动 (第一个块上的 SPL 副本)
| |
| |->0x0001FFFF->SPL 结束
| |->0x00020000 -> SPL.Backup1开始(SPL 副本在第二个块上)
| |
| |->0x0003FFFF->SPL.Backup1结束
| |->0x00040000-> SPL.Backup2 start (SPL 副本在第3个块上)
| |
| |->0x0005FFFF->SPL.Backup2结束
| |->0x00060000-> SPL.backup3开始(SPL 副本在第4个块上)
| |
| |->0x0007FFFF->SPL.backup3结束
| |->0x00080000-> U-Boot 开始
| |
| |->0x002BFFFF->U-Boot End
| |->0x00260000-> ENV 开始
| |
| |
| |->0x0027FFFF->ENV 结束
| |->0x00280000-> Linux 内核开始
| |
| |
| |
| |
| |->0x0077FFFF->Linux 内核末
尾| |->0x00780000->文件系统启动
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |+---
+->0x10000000-> NAND 结束(自由结束)

那么，这些地址是绝对值(物理擦除块(PEB)地址)还是相对值(逻辑擦除块(LEB)地址)？

我是说、例如、在这个表后面、我应该开始在地址0x00080000上写入 U-Boot (在我的例子中是裸框)、但是这个地址是绝对地址还是相对地址？如果在0x00080000发现坏块，并且在下一个正常块中写入光框图像，SPL (之前写入 NAND)是否知道如何管理到 U-Boot (在我的情况下是 Barebox)？

在跳转到内核映像时也是如此：表中的地址是绝对地址还是相对地址？

感谢您的支持、Biser

此致

豪尔赫

0 admin 8 年多前

TI__Guru**** 2614265 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

您好、Jorge、

一般而言、u-boot 可用于物理地址、而 Linux 内核可用于虚拟(相对)地址。

此致、
Yordan

0 admin 8 年多前

TI__Guru**** 2614265 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Yordan、您好！
因此、由于 u-boot 使用物理地址、假设 xloader 映像在写入 u-boot 映像之前写入 NAND 中、我不确定应该写入 u-boot 的位置是否存在错误块。请让我举一个案例示例：

0x00000000 -> SPL 启动
+跳转至0x00080000处的 U-boot
0x0001FFFF -> SPL 结束
0x00020000 -> SPL.Backup1开始
+跳转至0x00080000处的 U-boot
0x0003FFFF -> SPL.Backup1结束
0x00040000 -> SPL.Backup2开始
+跳转至0x00080000处的 U-boot
0x0005FFFF -> SPL.Backup2结束
0x00060000 -> SPL.backup3开始
+跳转至0x00080000处的 U-boot
0x0007FFFF -> SPL.backup3结束
0x00080000 ->错误块启动

0x0009FFFF ->错误块结束
0x000A0000 -> U-boot 启动
+跳转至0x00080000处的 U-BOOT_ENV
0x0010FFFF -> U-boot 结束
--
--
--

是这样吗？假设所有 Xloader 分区都指向0x00080000，系统将如何重新定向到0x000A0000的新 U-Boot 地址？我的 NAND 闪存器是否应该在每个 xloader 映像中重新写入跳转地址？

感谢您的支持
此致
豪尔赫

0 admin 8 年多前

TI__Guru**** 2614265 points

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

Yordan Kovachev 关于物理和虚拟寻址的说法是错误的。

NAND 地址未映射到 CPU 的地址空间。 NAND 未进行存储器映射。

CPU ROM 代码正在将 SPL 代码加载到内部存储器中。

如果您想了解 U-Boot 代码的加载方式、可以查看 SPL 源代码。

从我的(受限)大脑内存中、U-Boot 代码在跳过 NAND 中的坏块时加载。

处理器（参考译文帖）

处理器（参考译文帖）(Read Only)

[参考译文] AM3354：预刷写 NAND 时块管理不良