您好！
我们正在尝试获取基于从 nand 引导的 DM385的定制板。 我们使用以下 NAND： MT29F2G08ABAEAH4-IT
我们的引导模式如下：01000010011b、我还通过读取 CONTRAL_STATUS 寄存器并验证我们的引导模式位来验证这一点。 我们从引导模式开始的引导顺序应为 NAND -> NANDI2C->MMC->UART。
我能够从 MMC 和 UART 引导、但不能从 NAND 引导。
之前、我们的设计使用具有128位 OOB 数据的不同 NAND、由于 TI ROM 代码选择了 BCH16、因此无法启动。 有关该问题的主题如下：
我们使用的新芯片具有64字节的 OOB 数据、导致 TI ROM 代码使用 BCH8进行 ECC。 我们实际上可以生成 BCH8 ECC、因此我们怀疑我们的引导过程应该起作用、但实际上不能起作用。
我们现在使用的芯片 与我们的 nSketch 开发板完全相同、它能够从 NAND 中顺利启动。
我想验证我在两个器件上都有相同的代码、因此我决定从工作开发板启动 u-boot.min 并将其放在定制板上。 这些是我采取的步骤
在正确引导的开发板上、我输入了命令"Cat /dev/mtd0 >/mnt/mmc/working-uboot.bin "、这会将第一个0x80000字节的数据复制到 SD 卡上的文件中。
2.我使用 SD 卡启动了定制板、然后使用以下命令将 working-uboot.bin 刷写到定制板中：
mw.b 0x81000000 0xFF 0x00080000
MMC 重新扫描0；fatload MMC 0 0x81000000 working-uboot.bin
纳瓦级硬件2.
NAND 擦除0x00000000 0x80000；nand write.I 0x81000000 0x0 0x80000
3.为了验证所有匹配项(包括 OOB 数据)是否都匹配，我使用以下命令再次转储两个 nandump -f /mnt/mmc/nanddump.bin -o /dev/mtd0
通过比较每个器件的 nanddump.bin 文件、我能够验证每个 NAND 的前0x80000字节是否完全相同、包括 OOB 数据。
遗憾的是、定制板仍然无法启动。 由于代码应该完全相同、因此我认为这可能是硬件问题。 硬件工程师和我探测了几个引脚、以查看我们是否可以发现任何问题。
我们能够在重启时看到 NAND CE_引脚变为低电平。 我相信 DM385正试图访问 NAND。 D0引脚最初看起来短暂为低电平、然后变为高电平、然后进入中间电压、然后再次短暂地升高、直到它返回到接地并保持在那里。 在探测更多线路之前、我们已经没有时间了、但明天会尝试更多线路。
我对等待信号感到好奇。 我们的引导模式配置为忽略等待信号、我们的开发套件配置方式相同。 NAND 的数据表显示、主机必须等待 R/B#(等待)信号变为高电平、然后才能向目标发出复位(0xFF)。 我想知道 DM385是否在 NAND 准备就绪之前尝试通信。 开发板上的 NAND 可能在 DM385之前加电、并且有足够的时间准备就绪、并且我们的也很快就会启动。
我有以下问题：
1. ROM 引导代码是否在进行任何其它访问之前先向 NAND 发出复位命令(0xFF)？ 如果是、我将在明天的数据线上查找0xFF。
2.等待线是否导致了我们的问题？
3.我的 Nand 转储过程是否看起来应该正常工作？ 或者我是否错过了任何步骤。 在引导 NAND 之前、我是否需要对其执行任何其他操作？
4.我们是否应该寻找任何其他东西来诊断 NAND 为什么不是从引导的？
谢谢！
