[参考译文] AM625：串行 NAND 引导流程问题

您好、James：

liang han 说：

ROM expert is out this week。  我猜是检查了 BUSY 位、13h 命令后跟3个地址字节。  [/报价]

客户可以等待最后的答案、直到下周。 因此请再次咨询 ROM 专家。

谢谢。此致、
田代浩一郎

您好、James：

感谢您的确认。
您是否意味着 ROM 代码会轮询状态寄存器中的繁忙位、即使在 计算出的超时之前该位未清零、也会转到下一步并正确启动？

根据以下常见问题解答、 "读取状态寄存器"的要求如下。
"闪存必须在1S-1S-1S 模式下支持此命令、操作码为0x05、0地址字节、0个虚拟周期。"  
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/946418/faq-tda4vm-is-there-a-guide-to-choosing-the-right-ospi-flash-parts-that-are-supported-on-jacinto-7

客户想知道 NAND 器件是否支持上述要求、该器件不能用作引导器件。

谢谢。此致、
田代浩一郎

Koichiro、是的、它将在清除 BUSY 位或满足超时后继续执行下一步。   

我不知道这一要求来自何处。   让我看看能否找到答案。  

此致、

James

您好、Lucas：

感谢您的详细回答！
客户希望确认以下几点。

user6021594 说：

客户想知道 NAND 器件是否支持上述要求、该器件不能用作引导器件。

根据您的回答、NAND 似乎可用作引导器件、即使它不支持带有 Opecode 0xF 的"读取状态寄存器"命令。
对吧？
或者在其他位置使用"读取状态寄存器命令"？

谢谢。此致、
田代浩一郎

尊敬的 Koichiro：

我想知道他们所考察的器件中哪些不支持带有操作码0xF 的 STATUS 寄存器命令？

我们已经使用 Winbond 和 Micron 进行了测试、每个都有用于 BUSY 位的相同位置。

如果器件不支持 STATUS 寄存器命令0xF、则2ms 的超时值将在每次读取页面时生效、但仍应完成。  但是、这可能对客户来说并不理想、因为这会导致启动时间长得多。

此致、

James

您好、James：

liang han 说：

我想了解他们关注的是哪个器件不支持带有操作码0xF 的状态寄存器命令？

我询问客户器件型号。

liang han 说：

但是、这可能不是客户的理想选择、因为这会导致更长的启动时间。

您能否仔细检查 ROM 代码的其他部分中未使用"读取状态寄存器"？

谢谢。此致、
田代浩一郎

嗨、Koichiro、ROM 将以相同的方式执行从 NAND 中读取数据。  不知道为什么您询问 ROM 代码的其他部分是否使用了该编译器。  每当 ROM 从串行 NAND>读取时、都会使用我

此致、

James

您好、James：

我刚刚向您发送了 NAND 器件型号以及客户计划使用的数据表。

谢谢。此致、
田代浩一郎

我收到了数据表、似乎都在地址0xC0处支持命令0xF、因此它们将支持"读取状态寄存器"。

不过、最后、为了确定器件是否可以引导、我建议客户将 EVM 上的器件更换为他们感兴趣的器件、并尝试从这些器件进行引导。 由于各种各样的器件具有不同的特性和规格、因此很难明确地说某个器件是否能够启动。

此致、

James

尊敬的 JJJD：

liang han 说：

似乎两者都在地址0xC0处支持命令0xF、因此它们将支持读取状态寄存器。

根据以下常见问题解答、命令需要为0x5、地址为0x0。 这是拼写错误吗？
https://e2e.ti.com/support/processors-group/processors/f/processors-forum/946418/faq-tda4vm-is-there-a-guide-to-choosing-the-right-ospi-flash-parts-that-are-supported-on-jacinto-7

BTW、上述常见问题解答是从下面的 AM62 SDK 文档链接过来的。
https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_00_09_04/exports/docs/linux/Foundational_Components /U-Boot/UG-QSPI.html#ospi-QSPI-NOR-NAND


谢谢。此致、
田代浩一郎

您好、

您发布的两个链接都适用于独立于 ROM 的 Linux/U-boot。 如果您对该软件有任何疑问、我会推荐 您专门针对这些软件详细信息的单独票证。

此致、

Lucas

您好、Lucas：

我有点困惑。 您是否表示 ROM 和 Linux/U-boot 支持的 NAND 器件有所不同？
- ROM 支持0xF 作为读取状态寄存器命令。
- Linux/U-boot 支持0x5作为读取状态寄存器命令。
这对我来说毫无意义。

谢谢。此致、
田代浩一郎

您好、

ROM 是器件上的非易失性代码、无法更改、用于加载引导映像、可称为主引导加载程序。 原始问题参考了有关 OSPI NAND 引导的 TRM 一章、该引导加载程序是从串行 NAND 闪存读取映像的主引导加载程序。 无法更改引导的这些要求。

主引导加载程序将映像加载到 SoC 中、之后全部取决于用户选择将映像放入闪存中的内容。 它通常是某种形式的次级引导加载程序、例如 MCU+SDK 甚至裸机代码中提供的内容；它不必是 U-boot。 这完全由用户决定次级引导加载程序的用途、甚至需要什么。一些客户从 OSPI 进行引导、然后再也不需要针对其用例再次触摸次级引导加载程序。

辅助引导加载程序完全由用户自定义。 通常用于引导 Linux 的 U-boot 是开源的、所有驱动程序/要求都取决于代码本身以及如何为用户自定义。 如果您询问 Linux/U-boot 要求及其相关详细信息、您将更幸运地提交有针对性的软件问题单 、以便能够理解该软件所需或不需要的内容。

此致、

Lucas

您好、Lucas：

感谢您的澄清。 我了解了主引导加载程序和次级引导加载程序之间的差异。
客户在这里询问的是主引导加载程序(ROM 引导加载程序)、无法更改用户。

Q1)我从前面的讨论中了解到、主引导加载程序支持 Opecode 0xF 作为读取状态寄存器。 对吧？

Q2)另一方面、Linux/U-boot 支持 Opecode 0x5作为读取状态寄存器、对吗？

Q3)如果 Q1/Q2的两个答案均 为"是"；
-对于串行 NAND 引导、必须使用 opecode 0xF。
-如果客户用例中需要串行 NAND 访问、则 Opecode 0x5是可选的。
对吧？

谢谢。此致、
田代浩一郎  

Koichiro

1)是的

2)不确定 MCU+SDK 驱动程序支持什么。  我将转发您的问题以获得答案。

3) 0xF 必须与 ROM 兼容。  我不知道次级引导加载程序的默认操作是什么。  但如果器件同时支持这两种操作码、则可以同时支持这两种操作码。

此致、

James

您好、

请允许我通读此主题并回答未决问题。

此致、

Vaibhav