[参考译文] OMAP-L138：是否提供 RBL 源代码来了解引导闪存要求？

您好、Robert、

 我们通常不会提供 RBL 源代码、但 我需要在内部进行检查。 如果获得批准、可能需要通过销售代表。

雷克斯

您好 Robert

Rex 将此帖子转发给我。 遗憾的是、OMAPL138 RBL 不会公开发布。 您是对的，我们发布了 Keystone RBL，但代码结构不同，由于某些 IP 和实施问题，OMAPL138 RBL 无法完成相同的操作。

令人惊讶的是，这不是什么问题，大多数客户都能够根据文档和应用手册进行开发/调试。  

如果您对特定引导模式或闪存有任何特定问题，我们可以尝试了解我们可以如何最好地解决。  

此致

Mukul  

我们正在寻找帮助您从 NAND8芯片 MT29F4G08ABAFAH4 (类似于 NAND8 MT29F4G08ABADAH4)引导、唯一的区别是8位 ECC 与4位 ECC、页面大小加倍、OOB 大小为256而不是64。

问题在于从 NAND 中的初始启动、其中 RBL 无法跳转到 U-boot 映像。 在 NAND 启动时、不会从 UART/串行控制台进行打印。 U-Boot 映像已经过验证、并对 NAND 芯片进行了正确的读/写访问。 此外、从 SD 卡在 U-Boot 中引导后、从 NAND 中执行 Linux 内核/总线框没有问题。

已按时间顺序尝试的项目如下所示：

1) ECC
RBL 似乎无法执行 Micron 的内部 ECC 引擎使用的8位 ECC。

尝试了几次更改...
对于 U-Boot，我们不使用 NAND_ECC_HW_OOB_FIRST 的 ECC 模式，而是使用 NAND->ECC.MODE = NAND_ECC_NONE；
NAN->ECC.LO布局=&nand_Davinci_8bit_ondie_OOB_256；
对于 Linux、我们将 ti、davinci-ecce-mode ="hw"更改为 nand-ecc-mode ="片上"

根据 Micron 的建议、向 U-Boot 添加了新的 ECC 布局。 启用 CONFIG_SYS_NAND_ONFI_DETING 并将 CONFIG_SYS_NAND_PAGE_2K 更改为 CONFIG_SYS_NAND_PAGE_4K。 也可以使用 U-Boot 正确更新环境大小、页面大小和块大小。 使用的 U-Boot 版本是从 Yocto 构建的 ti-u-boot-2019.01。

在没有 ECC 更改的情况下、电路板也无法从 NAND 启动。 我们发现、这意味着我们的 SPL SRAM 空间已经用完。 我们需要尝试缩小 SPL、并找到可在不破坏 SPL 的情况下从 SPL 中去除的东西。 我们发现禁用 ECC 不是一个选项。

2) 2) TI ROM RBL 的问题
我们并不完全确定 TI 的 ROM RBL 将如何处理 MT29F4G08ABAFAH4。 TI 数据表 sprab41f 在附录 B 中将 MT29F4G08ABADA 列为受支持的器件。其器件 ID 为0xDC、这与我们已在使用的 MT29F4G08ABFAH4闪存的器件 ID 相同。 但是、附录 B 的器件 ID 表中未列出 MT29F4G08ABADA 器件 ID、因此 RBL 将默认使用第四个 ID 字节进行 NAND 配置。 这将暴露两个器件之间2KB 与4KB 的差异。

但是... OMAP-L138的 TI 闪存实用程序：

software-dl.ti.com/.../flash-utils-davinci.tar.gz

在文件 flash_utils/omap-L138/device_nand.c 中列出了以下内容：

//支持的 NAND 器件的 ROM 表
CONST NAND_CHIP_InfoObj DEVICE_NAND_CHIP_infoTable[]=

表中是器件 ID 0xDC。 因此、NAND 芯片可能可以工作、但必须使用默认的 NAND 大小设置对其进行设置。 这样、它将仅使用每个 NAND 页面的一半。 MT29F4G08ABAFAH4具有4KB 页大小和256KB 块大小。 默认为2KB 页大小和128KB 块大小。

在总结中、由于 OOB 设置有趣、人们似乎在将 SPL 和 u-boot 写入 NAND 时遇到问题。 人们在这方面取得了成功：

e2e.ti.com/.../2482361

github.com/.../flashtool

/flashtool -w -s 0 --DM365-RBL --ubi /dev/mtd1 uboot_and_ubl.bin

因此、不确定这是否起作用。 但是、如果 TI 闪存实用程序中的代码正确、则0xDC 的器件 ID 应该匹配、并且它们可以使用每页的一半。 很显然、这会将 NAND 闪存的大小减半。  将 Linux 分区加载到 DDR 存储器后、可以将 Linux NAND 驱动程序配置为正确使用 TI SPL、U-Boot 和 Linux 映像分区以上的所有闪存。

--

在进行了进一步的测试和上述所有测试之后、使用之前建议的参数尝试了闪存工具。 不幸的是，它不起作用；我们看到的错误是“oobsize 256 not supported (oobsize 256不支持)”。 显示此错误后、Flashtool 终止。

此外、我们尝试修改/重新编译闪存工具以旁路此错误(以及另一个与'writesize'相关的错误)。 它仍然不起作用。 也就是说、flashtool 完成了 u-boot 到 NAND 的写入、但电路板仍然无法从 NAND 中引导。 如果对闪存工具进行了正确的修改、它可能会起作用。 但我们认为这不是一种好方法。 如果我们可以使其正常工作、即使对 U-Boot 分区使用一半的内存大小、这仍然是一个很好的解决方案。

总之、要使用闪存工具将 SPL、u-boot 和 Linux 映像写入2k 页大小和128k 块大小、用户必须在 Linux 环境中使用闪存工具、其中的 nand 驱动程序配置为2k 页128k 块。 即使这样、也不能保证这将引导、因为我们无法知道 RBL 将执行什么操作、因为 TI 不会发布代码。

想法？

此致、
Robert

您好、Robert、  

请参阅此主题、该主题使用与您类似的器件、并有与您类似的问题。 希望这对您有所帮助。

https://e2e.ti.com/support/processors/f/791/p/882108/3277628#3277628

雷克斯

Rex、

您发送的此链接清楚地显示**否** 8位引导！！ 因此、这是一个禁止的做法。

那么、我们是否死在水中？

此致、

Robert

您好、Robert、

正如文章所述、不支持8位 ECC。

雷克斯