[参考译文] SK-AM62：尝试从定制 AM62 板上的 SPI NOR 闪存引导

您好、

请稍后回复。

此致、

Vaibhav

=> SF probe
JEDEC_SPI_NOR 闪存@0：无法识别的 JEDEC ID 字节：FF、ff、ff
在 0：0 处初始化 SPI 闪存失败（错误 0）
 [/报价]

您是否可以使用逻辑分析仪探测 SPI 时钟/数据信号、并查看是否有任何活动？ `sf probe`期间是否存在时钟信号、频率是否符合预期？ AM62x 的时钟输出命令是否符合预期？ QSPI 闪存是否做出响应？ 这将有助于验证 pinmux 等设置。

要从 SPI 闪存引导、需要进行硬件/软件更改？

TRM 中有一个小节、介绍了如何配置/使用 SPI 引导模式。

此外、如果我们直接刷写到 SPI 或使用 SPI NOR 闪存编程器、您能建议我们可以使用哪个图像吗？

如果使用我们的 Linux SW 堆栈、您只需将不同的引导映像 (tiboot3.bin、tispl.bin、u-boot.img) 刷写到预期的适当偏移量、除此之外不需要任何“特殊“。 SDK 用户指南提供了有关这方面的一些信息、请参阅： https://software-dl.ti.com/processor-sdk-linux/esd/AM62X/11_00_09_04/exports/docs/linux/Foundational_Components SDK-U-Boot/UG-QSPI.html#ospi-QSPI-NOR-NAND （您需要向下滚动一点点）。 在使用 Linux 执行相同操作时、也有类似的指令。

此致、Andreas

[/quote]

我们能够通过更改闪存 IC 来解决先前的问题。 我们尝试从在 3.3V 下运行的 IC 引导、但我们的电路板设置为 1.8V。 我们在软件中增加了对新 IC (Macronix MX25U51245GMI00) 的支持。 在探测时、我们现在能够检测 IC 并获得以下输出
=> SF 探针
SF：检测到 mx25u51245g、页面大小为 256 字节、擦除大小为 4 KiB、总计 64 MiB

我们在 UBoot 控制台中执行了以下步骤来从 SD 卡刷写 QSPI NOR 闪存：

=>加载 MMC 1：1 $｛loadaddr｝tiboot3.bin
在 46 毫秒内读取 294113 字节 (6.1 MiB/s)
=> SF 更新$loadaddr 0x0 $filesize
器件 0 偏移 0x0、大小为 0x47ce1
写入 294113 个字节、在 0.91s 中跳过 0 个字节、速度为 3203954 B/s
=>加载 MMC 1：1 $｛loadaddr｝tispl.bin
1159931 字节读取时间为 117 ms (9.5 MiB/s)
=> SF 更新$loadaddr 0x80000 $filesize
器件 0 偏移量 0x80000、大小为 0x11b2fb
1159931 字节写入、0 字节在 0.364 秒内跳过、速度 3236428 B/s
=>加载 MMC 1：1 $｛loadaddr｝u-boot.img
1014083 字节读取时间为 106 毫秒 (9.1 MiB/s)
=> SF 更新$loadaddr 0x280000 $filesize
器件 0 偏移 0x280000、大小 0xf7943
1014083 字节写入、0 字节在 0.319 中跳过、速度 3224909 B/s

此后、我们尝试通过将引导模式更改为 xSPI（引导模式切换为 B0 至 B15 - 1100111000100100） 和 QSPI（引导模式切换为 B0 至 B15 - 11001000000100100）来更改为从闪存引导、但我们没有在控制台上获得任何输出。

我们是否缺少任何步骤或者引导模式不正确。

=> SF probe
SF：检测到 mx25u51245g、页面大小为 256 字节、擦除大小为 4 KiB、总共 64 MiB

看起来您的系统启动后可以进行基本操作、这非常好。 您的闪存编程步骤看起来不错。 有了这个至少`tiboot3.bin`应该在启动期间出现,无论什么和做一些控制台打印,但看起来你甚至没有得到.

`s您使用的是` f update `s、但要确保在编程步骤之前也尝试添加` f erase` step（在本例中使用`sf write<eps>）、看看它是否会有任何区别（对于正确实现和配置的闪存驱动程序，它不应该--但我们应该仔细检查这一方面）。

将引导模式更改为 xSPI (

您的闪存似乎支持 SFDP、因此 xSPI 引导模式在理论上应该起作用。

您是否尝试过从下电上电（而不是重置）引导？ 也许闪存在 U-Boot 中刷写后处于 ROM 无法通信的状态。 如果闪存复位信号未连接到系统复位（是您的？）、则可能会发生这种情况。 如需了解更多信息、请参阅此处： https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1436064/am2431-spi-and-qspi-boot-modes-using-an-external-flash-w-o-a-dedicated-reset-pin/5506328#5506328   在上电时尝试引导可能是一个很好的测试、可以在此处查看是否存在此问题。

然后、如果您在 CLK、数据输入和数据输出信号上看到任何通信、是否可以使用逻辑分析仪探测信号？

我们是否遗漏了任何步骤或者引导模式不正确。

您可以尝试的另一件事是使用常规 SPI 引导模式、然后循环使用所有不同的引导模式配置设置、必须查看这些设置中是否有任何一个正常工作。 此外、还要确保从冷启动（开机）执行所有操作。

此致、Andreas

我们尝试了不同的引导模式、但仍然无法在控制台上获得任何输出。在 SF 读取/写入命令期间、我们在数据线路和时钟上获得了活动。

我们使用 SF 擦除遵循以下命令：

sf probe

sf erase 0x0 0x680000

load mmc 1:1 ${loadaddr} tiboot3.bin

sf write $loadaddr 0x0 $filesize

load mmc 1:1 ${loadaddr} tispl.bin

sf write $loadaddr 0x80000 $filesize

load mmc 1:1 ${loadaddr} u-boot.img

sf write $loadaddr 0x280000 $filesize

我们在电路板开启时更改了引导模式、然后提供复位信号以检查电路板是否引导或在 SPI 数据线或时钟线上是否有任何活动、但我们没有任何活动。

我们在电路板开启时更改了引导模式、然后发出复位信号、以检查电路板是否会引导或者在 SPI 数据线或时钟线上获取任何活动、但我们没有获得任何活动。

尝试按照我之前介绍的方法对电路板进行下电上电。 BOOTMODE 引脚仅在非常特定的低电平 复位时才会被读取/锁存、至少在我们的 EVM 上按下板载复位按钮几乎不足以重新捕获 BOOTMODE 引脚状态。 100%的最佳选择是进行下电上电。

如果您很好奇、TRM 提供了有关此方面的详细信息...

此致、Andreas

我们尝试了不同的引导模式、每次对电路板进行下电上电、同时在闪存上提供复位信号（我们直接从 IC 复位引脚连接到“RESETSTATz"信号“信号）信号）、但仍然没有任何活动。

设备树中是否有任何地方或者我们可以指定闪存工作电压的任何其他地方（SD 卡可以这么做）？

本周我将在 PTO 上工作、但下周将再次查看。

此致、Andreas

是否有关于此问题的任何更新

我们直接在 IC 复位引脚与“RESETSTATz"信号“信号

该信号是“主域热复位状态输出“、是器件 POV 的输出。

您需要断言的是  MCU_PORz 即“MCU 域冷复位“。 这是一个器件输入、是进行器件复位的有效方法、还可确保读取和锁存引导模式引脚。

此致、Andreas

我们使用了 RESETSTATz 与在参考设计中一样 OSPI0_CSN1 （用作 GPIO_OSPI_RSTn）用于闪存复位。 我们将尝试使用 MCU_PORz 信号来查看它是否发生了任何变化。

TRM 提到：“当使用大于 128MB 的 OSPI\xSPI\QSPI\SPI 闪存设备时、具有复位功能的闪存设备包
信号“。那么、如果我们使用 128MB 的闪存 IC、我们是否能够在没有任何复位信号的情况下引导闪存？

因此、如果我们使用 128 MB 的闪存 IC、我们是否能够在没有任何复位信号的情况下引导闪存？

是的。 复位信号的连接主要能够通过复位更好地从某些运行和故障场景中恢复、因此引导 ROM 固件有一个“干净“（未配置）器件可供通信。 但是、这方面不应影响您在上电后进行初始引导的能力、这正是您遇到的问题。

此致、Andreas