• 状态
  • 已锁定 已锁定
  • 个回复 7 个回复
  • 名订阅用户 0 名订阅用户
  • 次查看 75 次查看
  • 用户 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.

[参考译文] AM3517：在目标系统中使用"nandwrite"写入 NAND 块0失败

admin
Guru**** 652440 points
Other Parts Discussed in Thread: AM3517, AM3505
请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/949466/am3517-failure-using-nandwrite-in-the-target-system-to-write-to-nand-block-0

器件型号：AM3517
主题中讨论的其他器件： AM3505

尊敬的先生或女士：

我们使用 的是 Compulab 的 CM-T3517模块化计算机("COM")。 它包含主题微控制器和 一个 Hnix H27U1G8F2BTR-BC NAND 芯片。 我们的目标系统软件(Yocto 嵌入式 Linux)需要能够更新 nand 块0中的 x 加载程序("x-load.bin.Shift"、也称为"MLO")。 擦除块0并使用新版本的 x 加载程序对其进行编程(在目标系统中)后、系统不会引导。 我知道块0在纠错方面应该被不同的对待。 我已经使用"nanddump"从块0中读取 x 加载程序、并且这些文件没有区别。 以下是我使用的示例命令：

FLASH_eraseall /dev/mtd0或

FLASH_ERASE /dev/mtd0 0 0

nandwrite -p --noecc /dev/mtd0 x-load.bin.ift

nanddump --noecc -l 34614 -f x-load.bin.Shift.dump /dev/mtd0

diff x-load.bin.ift x-load.bin.ift.dump

我猜1位 ECC 方案不是由"Nandwrite"或 NAND 的内核驱动程序正确完成的。 我知道块0是特殊的、因为它的纠错必须与 ROM 加载程序的预期相匹配。

感谢您的帮助、

Kirby Cartwright

(合同)软件工程师-持续

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

    您好、Kirby、

    您使用的是目标系统软件的哪个版本？

    您是否已确认问题出在刷写过程、而不是新的 x 加载程序？ (即、当您将原始的 x 加载程序编程回 Nand 块0时、它是否会再次开始工作？)

    此致、

    Nick

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

    Nick、

    以下是将回答您的问题的引导消息的有用摘录：

    U-Boot SPL 2020.01-rc3-ts-g4fa6070cdd (2020年8月5日- 19：49：53 +0000)
    尝试从 NAND 引导

    U-Boot 2020.01-rc3-ts-g4fa6070cdd (2020年8月5日- 19：49：53 +0000)

    AM35XX-GP ES2.0、CPU-OPP2、L3-165MHz、最大 CPU 时钟为600MHz
    型号：TI AM3517 EVM (AM3517/05 TMDSEVM3517)
    AM3517EVM 板+ LPDDR/NAND

    NAND 读取：器件0偏移量0x2a0000、大小0x40000
    262144字节读取：正常
    正在运行引导脚本...
    ##正在执行80000000的脚本
    已成功加载脚本...

    NAND 读取：器件0偏移量0x2a0000、大小0x40000
    262144字节读取：正常
    正在运行引导脚本...
    ##正在执行80000000的脚本
    已成功加载脚本...
    正在从 K1R1D1引导系统...

    NAND 读取：器件0偏移量0x2e0000、大小0x300000
    读取3145728字节：好的

    NAND 读取：器件0偏移量0x6e0000、大小0xa00000
    读取10485760字节：好的

    正在从 K1R1D1引导系统...

    NAND 读取：器件0偏移量0x78e0000、大小0x10000
    65536字节读取：正常
    ##从传统映像启动内核，地址为81000000...
    图像名称：Linux-4.14.148-Yocto-Tina-ts-CMM
    映像类型：ARM Linux 内核映像(未压缩)
    数据大小：2807968字节= 2.7 MIB
    加载地址：80008000
    入口点：80008000
    正在验证校验和... 好的
    ##正在从传统映像加载 init Ramdisk，地址为82000000...
    图像名称：CMM-IMAGE-TEST-CMM-2020102018562
    映像类型：ARM Linux ramdisk 映像(未压缩)
    数据大小：8304609字节= 7.9 MIB
    载入地址：00000000
    入口点：00000000
    正在验证校验和... 好的
    ###展开的器件树团在80c00000处
    使用0x80c00000处的 FDT blob 进行引导
    正在加载内核映像
    正在将 Ramdisk 加载到8577a000，结束85f657e1... 好的
    正在将设备树加载到85768000，结束85779cf0... 好的

    正在启动内核...

    正在解压缩 Linux... 已完成、正在引导内核。
    [0.000000]在物理 CPU 0x0上引导 Linux
    [0.000000] Linux 版本4.14.148-Yocto-Tina-CMM (OE-USER@OE-host)(gcc 版本8.2.0 (GCC))#1 UTC 2020年10月14日16：33：42日
    [0.000000] CPU：ARMv7处理器[411fc087]修订版7 (ARMv7)、CR=10c5387d
    [0.000000] CPU：PIPT/VIPT 非混叠数据高速缓存、VIPT 非混叠指令高速缓存
    [0.000000]、共个：FDT：机器模型：physio Control CMM
    [0.000000]内存策略：数据高速缓存写回
    [0.000000] CPU：所有 CPU 均在 SVC 模式下启动。
    [0.000000] AM3505 ES1.1 (二级高速缓存 NEON)

    操作系统是 Linux 4.14.148、基于 TI 用于 AM3517EVM 板的 Linux。 它使用更现代的内核和器件树二进制文件来定义 I/O

    谢谢、

    Kirby Cartwright

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

    您好、Kirby、

    请注意、AM35x 软件被视为"成熟"- 我们自2013年以来未更新 AM35x Linux EZSDK。 我不能支持有关在 AM35x 上使用最新软件的问题。

    您是否已确认问题出在刷写过程、而不是新的 x 加载程序？ (即、当您将原始的 x 加载程序编程回 Nand 块0时、它是否会再次开始工作？)

    此致、

    Nick

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

    Nick、

    我将忽略微控制器已过时这一事实、希望您仍能提供帮助。

    我找到了使用 CAN 成功刷写 MTD 块0的 U-Boot 版本。 以下是我根据 TI 应用手册(URL 如下)使用的命令：

    纳德特硬件汉明

    NAND 读取0x80000000 0x00000000 0x8736

    NAND 擦除0x0 0x50000

    NAND 写入0x80000000 0x0 0x8736

    0x8736是"x-load.bin.ift"文件的大小、0x00000000是 NAND 闪存中的位置。

    您是否知道 TI 在2013年修改的过时 Linux 内核是否可以写入 mtd0？

    Kirby W. Cartwright

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

    您好、Kirby、

    为了确保我正确理解您的意思：您最初尝试从 AM35x Linux 命令行刷写 NAND、但遇到了问题。 但是、您是否能够根据上面 wiki 链接中的说明从 AM35x uboot 闪存 NAND？ 自 uboot 闪光是否是您用例的可接受替代方案？

    请在单独的注释中保存您在 AM35x 上找到的任何 wiki 页面、供您将来参考。 Wiki 将在年底脱机、AM35x 页面目前尚未计划迁移到其他网站。

    我正在进行一些挖掘。 BeagleBoardNAND 页面 指示 Linux 将 NAND xloader 和 uboot 视为只读、而 AM335x 等后续器件的大多数 TI 闪存指令仅提供从 uboot 执行此操作的指令。

    此致、

    Nick

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

    Nick、

    感谢您的回复。 我们的所有 MTD 模块都设置为读取/写入。 是的、问题出在命令行上。 您的建议对我们不起作用、因为 U-boot 对用户不可用。

    我将尝试使用旧版本的内核(2.26.32)、flashwrite 等、并查看它们是否在命令行中工作。

    此致、

    Kirby Cartwright

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

    您好、Kirby、

    请告诉我您在测试中发现的内容。 我仍在寻找是否支持从 Linux 刷写 xloader 和 uboot。

    此致、

    Nick