• 状态 Resolved
  • 已锁定 已锁定
  • 回复 23 回复
  • 订户 0 订户
  • 视图 1447 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] DM385：无法使用 u-boot.min.nand 从 nand 引导

admin
Guru**** 2540720 points


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

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/603520/dm385-unable-to-boot-from-nand-with-u-boot-min-nand

器件型号：DM385

大家好、

我正在尝试从 nand 引导我的定制 DM385板。 我们使用的 Nand 是 MT29F2G08ABAGAH4-IT：G

目前、我可以通过两种方式成功引导系统：

1.从 SD 卡引导，从卡加载第一级和第二级 uboot，但从 nand 加载内核和 rootfs。

2.加载 u-boot.min.n 并在加电时使用 XMODEM (当我收到 CCCCCCC... 串行提示)。 加载后、u-boot.min 将运行、从 nand 加载 u-boot、然后再加载到内核中。

我已经尝试使用以下命令从第二阶段 u-boot 对 u-boot.min.nand 文件进行编程：

MMC 重新扫描0；fatload MMC 0 0x81000000 u-boot.min.nand；nand 擦除0x0 0x20000；nand write.i 0x81000000 0x0 0x20000

 

在使用以下命令对 u-boot.min.nx 进行编程之前、我还尝试将 nandecc 设置为 HW_ECC_BCH8：

 

纳瓦级硬件2.

MMC 重新扫描0；fatload MMC 0 0x81000000 u-boot.min.nand；nand 擦除0x0 0x20000；nand write.i 0x81000000 0x0 0x20000

 

这似乎也不起作用。 每当我重新引导系统时、我都会收到 CCCC 提示符。

 

是否有任何关于我需要做什么才能使其正常工作的想法？

 

谢谢

 

Mt.

329f2g u-boot.min.nand

  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我忘了说、我们的引导模式是10011、它对应于以下引导顺序：

    与非
    NANDI2C
    MMC
    UART
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Mikael、

    是否确定以上粘贴的 nand write 命令？ 因为您尚未在 NAND 命令中指定 START 和 SIZE

    它应该是什么样的
    # nand write.i 0x81000000 0x0 0x20000
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好 Dwarakesh、

    我认为我的第一个帖子由于某种原因切断了完整命令、下面是我使用的确切命令：

    MMC 重新扫描0；fatload MMC 0 0x81000000 u-boot.min.nand；

    NAND 擦除0x0 0x20000；nand write.I 0x81000000 0x0 0x20000

    我认为这与您建议的命令相同。

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

    希望引脚顺序从引脚4 (1)引脚3 (0) PIN2 (0)引脚1 (1)引脚0 (1)开始。 请务必确保与 TRM 中 NAND 引导的4.7.3.5 Sysboot 引脚要求相匹配
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Dwarakesh、

    我想您可能已经发现了第4.7.3.5节的问题。 我们板上的其中一个 CS0MUX 引脚上似乎有一个未组装的电阻器。 我将让硬件工程师对此进行验证、如果是问题、我会将您的答案标记为正确。

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

    我们对电路板进行了更改、以确保电路板上的 CS0MUX 引脚被拉至低电平、并在示波器上验证它们是否为低电平。 遗憾的是、我们仍然得到"CCCC..." 提供了一个示例。

    为了验证、我重新刷写了 u-boot.min.nand 文件。 首先、我使用以下命令对其进行了刷写：

    MMC 重新扫描0；fatload MMC 0 0x81000000 u-boot.min.nand；

    NAND 擦除0x0 0x20000；nand write.I 0x81000000 0x0 0x20000

    在这不起作用后、我在启用"nnandecc HW 2"后尝试了它、但仍然不幸运。

    我们还应该尝试什么？
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    您使用的是哪种软件包？ 您可以尝试预构建的映像吗？
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    我们的评估板(nSketch)的制造商为我们提供了 SDK、因此我不确定它的确切版本。 ti_tools 中的 CBB_PSP 版本为 CBB_PSP_04_04_00_02。 是否有合适的位置来查找我们的软件所基于的版本？

    我已经尝试编写了 SDK 附带的预构建 u-boot.min.nand、但它仍然没有启动。 我知道这款预构建版本可在其评估板上工作。
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Mikael、

    这看起来是 PSP 版本_04_04_00_02。 您能否确保使用第一级和第二级作为预编译。 预构建的第二级引导加载程序中的闪存。 希望您已确保所有其他 sysboot 引脚符合预期。 NAND 器件型号是否因评估板和定制板而异？
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Dwarakesh、

    现在我想、我不确定预构建的映像是否可以在该系统上工作。 我们必须修改 RAM 时序才能使 uboot 在此系统上工作。 预构建的 uboot 不会进行此修改、也不会起作用。

    为了测试这一点、我尝试通过 XMODEM 加载预构建的 u-boot.min.nand 文件。 加载映像后、CCC 打印退出、但未发生任何情况。 当我使用 u-boot.min.n并且 我使用我们的系统的 RAM 时序构建的 u-boot.min.nt 执行此操作时、它将正确加载。 这让我认为问题与引导模式或映像如何写入 NAND 有关。

    该项目的硬件工程师已经仔细检查了所有的 btmode 引脚、他认为它们是正确的。 我将在这里与大家分享、如果您看到任何奇怪的东西、请告诉我。

    btmode]= 1
    btmode]= 1
    btmode]= 0
    btmode]= 0
    btmode]= 1
    btmode]= 0
    btmode]= 0
    btmode]= 0
    btmode]= 0
    btmode]= 1
    btmode]= 0
    btmode]= 0
    btmode]= 0
    btmode]= 0
    btmode]= 0
    btmode]= 0

    至于 NAND 器件、评估板使用的 NAND 与我们使用的 NAND 或多或少相同。 它们的芯片是我们的几个修订版本、并且采用了不同的封装。
    我们的定制板使用：MT29F2G08ABAGAH4-IT：G
    评估板正在使用：MT29F2G08ABAEAWP-IT

    我们注意到的一件事是、我们的 btmode 引脚的设置完全相同、btm模式[9]除外。 它们的值为0、我们的值为1。 我知道这与以太网引导相关、并告诉您连接了哪种 phy、但奇怪的是、评估板和我们的板都使用 RGMII phy。 根据其器件的数据表(使用 RGMII)、他们使用的 PHY 甚至不支持 MII (GMII)。
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好！

    我不确定它是否有效，因为它可以在类似的 NAND 芯片上工作，但从 processors.wiki.ti.com/.../TI81XX_PSP_04.04.00.02_Release_Notes 可以看到 一个已知问题：

    "NAND：ROM 代码和 uBoot/Kernel 驱动程序之间在 OOB 中存储 ECC 的格式未对准、导致 BCH8 ECC 方案出现 NAND 读取问题。"

    我建议您从 IPNC RDK 等最新软件包中获取 uboot 并尝试。
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    嗨、Dwarakesh、

    您能给我指一下最新的 IPNC RDK 吗？ 我不确定从哪里下载它。

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

    这是链接： www.ti.com/.../ipnc-rdk-csk

    这具有最新的 u-boot 2016。 它可能不同、但请尝试此封装。 对于具有 u-boot 2011 (类似于您的封装)的 IPNC 封装3.8、请联系您当地的 TI FAE。 3.8封装将是更好的选择。

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

    我已继续并从 TI 联系人处申请了 IPNC 3.8封装、因为希望这将更容易集成到我们的现有代码中。

    您提到了我的 uboot 版本的已知问题：
    "NAND：ROM 代码和 uBoot/Kernel 驱动程序之间在 OOB 中存储 ECC 的格式未对准、导致 BCH8 ECC 方案出现 NAND 读取问题。"

    您是否知道此问题的位置以及解决方法？ 是否有修补程序？ 在搜索代码时、问题似乎出在 ti81xx_nand.c 文件中。

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

    我可能无意中发现了某件事。 我在网上搜索其他版本的 ti81xx_nand.c、并偶然发现了 Arago 项目版本。 我搜索了项目中的 ECC 并找到了以下更改日志：

    arago-project.org/.../

    将其中的一些更改与我的 ti81xx_nand.c 版本进行比较、可以看出、某些 BCH8 ECC 修复程序似乎在我的 uboot 中实现、但随后通过 代码中的"#if 0"从编译中删除。

    我将仔细检查 并从代码中删除#if 0、以便它更类似于 Arago 版本、并查看这是否使我到达任何位置。

    您是否认为只克隆 Arago 版本的 uboot 并使用它会有任何问题？
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好 Mikael、

    请尝试使用 Blow u-boot 版本、它基于 IPNC RDK 3.8和 PSP 4.04.00.02：

    arago-project.org/.../

    另请参阅以下 wiki 页面是否将处于"帮助"中：

    processors.wiki.ti.com/.../Debug_Tips_for_DM81xx_Boot_Fail
    processors.wiki.ti.com/.../AM335x_board_bringup_tips

    processors.wiki.ti.com/.../TI81XX_PSP_UBOOT_User_Guide
    processors.wiki.ti.com/.../TI81XX_PSP_04.04.00.02_Release_Notes
    processors.wiki.ti.com/.../TI81XX_PSP_NAND_Driver_User_Guide

    此致、
    帕维尔
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    大家好、Pavel 和 Dwarakesh、

    我将在 TRM 的 ROM 代码部分(第4节)稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍稍 我们开发板上的 NAND 是 MT29F2G08ABAEAWP_IT。 对于它、一个页是2048字节+ 64字节 obb。 我们的器件是 MT29F2G08ABAGAH4-IT、页面为2048+128。

    我在 TRM 第4.7.3.1节中注意到、对于 NANDD、它特别指出了2048 + 64的页面大小。 我还注意到、nandwrite 程序无法写入 nand、输出文本"未知闪存(非正常 NAND)"。 我搜索了这个文本、我相信它来自 libmtd.a. "更新"或"filesys_update"应用程序中对该文本的其他引用专门防止具有2048字节页的闪存在没有64字节的 obb 时工作。

    这是否是我们的系统无法引导的原因？ ROM 代码检查以确保它是2048+64、还是这意味着我们需要在写入 u-boot.min 映像时执行任何不同的操作？

    谢谢！

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

    1) TRM 建议 ROM 代码在第四个字节(4K 页)中查找10b 以使用 BCH16方案。 这可能意味着如果看到01b、它可以继续使用 BCH8。 如果它使用了 BCH8、我认为即使错误地假定64字节的 OOB 大小也足以从 NAND 中引导电路板。

    2)但是、在 e2e 中、对于 TI81xx (与 DM38x 类似)也有类似的讨论、其中讨论了 ROM 代码根据备用区域选择 BCH 算法。 如果有128字节的备用区域、则可以使用 BCH16。 在这种情况下、看起来 Uboot 中还不支持 BCH16。 您可以移植它、但这是一项努力。

    所以，有两个正方，我不确定是哪一个。 帕维尔可以更好地评论。 等待他的意见。
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    嗨、Dwarakesh、

    1) 1)我刚刚检查、第4个字节中没有10b、但是我们的页面大小是2K、因此我不确定这是否会发生任何变化。
    2) 2)我认为最有可能发生这种情况。 从我所能说的情况来看，证据表明这是原因。 我还一直在阅读有关 ti81xx 的其他文章、在 NAND 中看到的大于64字节额外空间的问题似乎与我看到的非常相似。

    希望 Pavel 能够帮助确认这是问题所在。

    再次感谢！
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    Mikael、

    根据我的计算、BCH8应该足以支持2k + 128 OOB、请参阅以下 e2e 线程：

    e2e.ti.com/.../1792717

    下面的 e2e 线程讨论了如何将2K + 112 OOB 与 BCH8搭配使用：

    e2e.ti.com/.../231420

    此致、
    帕维尔
  • 0
    TI__Guru**** 2540720 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    嗨、Pavel、

    如果我错了、请更正我的错误、但根据我将链接到下面的文章、ROM 引导加载程序将使用它可以使用的最大 ECC 方法。 在 ti81xx 中 ROM 引导加载程序可能不同、因此链接可能不适用。 根据 BCH 闪存 OOB 布局的 wiki、NAND 的计算如下：

    页面大小：2048

    每页512字节扇区：2048/ 512 = 4

    对于 BCH8、我们需要14 * 4 = 56字节。

    对于 BCH16、我们需要26 * 4 = 104字节。

    那么、如果 ROM 引导加载程序选择它可以容纳的最大 ECC 方法、并且我们总共有128个 OOB 字节、它是否会选择 BCH16？

    我目前正在安装 JTAG、因此可以尝试访问 ROM 引导加载程序状态向量。 当我获得这些信息时、我会报告。  

    https://e2e.ti.com/support/arm/sitara_arm/f/791/p/382272/1346910?tisearch=e2e-sitesearch&keymatch=bch16%20rom%20code#1346910

    e2e.ti.com/.../842118

    http://processors.wiki.ti.com/index.php/TI81XX_PSP_UBOOT_User_Guide#BCH_Flash_OOB_Layout

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

    Mikael、

    是的、TI81xx ROM 代码的作用相同、ROM 将使用其可以放入备用区域的最大 BCH、请参阅以下指针：

    以下是我在电子邮件通信中提供的一些信息：

    问题说明：

    ----------------

    现在、uBoot 和 Linux 内核驱动程序都具有编译时选项、可选择各种 ECC 模式(ECC-SW、ECC_HAM1、ECC_BCH8)、但它们不支持 ECC_BCH16模式。 因此、当客户必须使用特定模式时、它会使用他选择的选项重新构建 uBoot 和内核。

    但是、ROM 代码是用于多器件平台的通用代码、不是使用这些用户选项设计的。 ROM 根据它在电路板上检测到的器件的 OOB 面积(物理参数)，自动选择‘最高可能’ECC 模式。

    因此、在当前情况下、客户电路板的器件 OOB 区域为224位、因此 ROM 代码自动选择 ECC_MODE = ECC_BCH16。 由于从 uBoot 或内核刷新的 uBoot 映像无法在 ECC_BCH16中刷新、因为代码不支持 ECC_BCH16、因此 ROM 代码无法识别 uBoot 刷新的映像、并且会发生故障。

    可能的解决方案：

    (1)  使用某些支持 BCH-16代码且与 ROM 代码 ECC 布局相匹配的第三方闪存工具将 U-Boot 映像刷写到 NAND 中。 通过这种方式、ROM 可以了解刷写的 U-Boot 映像、U-Boot 加载后客户可以使用他选择的 ECC_MODE。

    (2)  从 NAND 之外的任何其他源(例如 SPI 闪存、SD 卡)引导 U-Boot 映像、然后可以从 NAND 中加载更多的 Linux 映像。

     

    您还可以检查最新的 DM38x IPNC RDK 3.9.1 u-boot 代码库、bq16应该已经在那里可用。 您可以向后移植到您的 u-boot 代码库。

    此致、
    帕维尔

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

    感谢 Pavel、

    我们已决定切换回 NAND、以便为时间考虑允许 BCH8 ECC。 感谢您在这方面的帮助。