[参考译文] 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

如前所述、我们购买了一个 128 MB 闪存 (W25Q12PWSFIM)、并尝试从该闪存引导。 如果我们在不添加特定驱动程序的情况下尝试探测闪存、则会出现以下问题：

sf probe
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: df, 00, 30
Failed to initialize SPI flash at 0:0 (error 0)

在包含 JEDEC ID 并在 drivers/MTD/SPI/SPI-NOR-IDs.c 中添加以下行之后：

{ INFO("w25q12pwsfim", 0xdf0030, 0, 64 * 1024, 256, SECT_4K | SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ ) }

并在菜单 conf 中启用以下功能：

->设备驱动程序-> MTD 支持-> SPI 闪存支持-> Winbond SPI 闪存支持

我们在探测闪存（SF 探针）后收到以下错误：

Failed to initialize SPI flash at 0:0 (error 0)

对此案例有何更新？

因此、该主题现在讨论 3（！）  闪存器件不同；我有点困惑、这里实际上发生了什么。

1. W25Q01JVSFIQ  
2. MX25U51245GMI00
3. W25Q12PWSFIM

假设你现在想要的是#3,一些非常基本的东西是关闭的。

搜索数据表时自动搜索 W25Q12PW 我在这里找到的部分： https://www.winbond.com/hq/support/documentation/downloadV2022.jsp?__locale=en&xmlPath=/support/resources/.content/item/DA00-W25Q12PW.html&level=1

这个数据表是否正确？

它是一个 Winbond 部件、并且具有一个 EFH 的制造商 ID。 但您所读的是 DFH 吗？ 如果是这种情况、您可能需要进一步分析一些基本的电气/连接问题。 您可能还希望降低 SPI 时钟速度、看看这样是否有任何帮助。

此致、Andreas

很抱歉在最后一个问题中没有说明自己、但您得到了正确的闪光灯。 我们尝试从基于 SK-AM62 的定制板上的 QSPI 闪存引导。 我们第一次尝试使用 MX25U51245GMI00、但由于它大于 128 MB、因此需要重置闪存、我们的主板上没有该闪存。 所以我们切换到了 W25Q12PWSFIM、它是 128 MB、但在最后一个问题中提到了问题。 我们在板上有一个闪存插槽、因此我们只需更换了同一板上的闪存、该闪存可在探测 MX25U51245GMI00 上提供正确的 ID、并成功写入闪存。 因此、我怀疑这是一个连接问题、但我将再次检查以防万一。 可能会有任何其他原因导致这个问题。 （为了消除混淆，我们在 W25Q12PWSFIM 上遇到问题，并要求获得同样的帮助）

感谢您的澄清。 本周我在动力输出轴上工作。 下周将再次提供 E2E 支持。

任何更新

我们能得到关于这种情况的更新吗

所以我们切换到了 W25Q12PWSFIM、它是 128 MB、但在最后一个问题中提到了问题。

因此、您应该读取的 JTAG 制造商 ID 为 0xEF。 但您正在读取 0xDF、这是不正确的。 看起来序列中的两个位被翻转了。 我知道您之前提到过、您可以成功探测不同的闪存芯片、这意味着基本接线应该可以、但是使用 W25Q12 芯片可能会使其对您的设置中的噪声/信号更加敏感。

由于您使用的是套接字（可能永远不会用于生产）、因此您应尝试降低传输速度/参数、以确定您是否可以正确读取芯片 ID、即使它仅用于测试目的。

尝试在此处更改以下内容（示例）：

&ospi0 {
     pinctrl-names = "default";
     pinctrl-0 = <&ospi0_pins_default>;
     status = "okay";

     serial_flash: flash@0 {
             compatible = "jedec,spi-nor";
             reg = <0x0>;
             spi-tx-bus-width = <8>;            /* <-- Use <1> here */
             spi-rx-bus-width = <8>;            /* <-- Use <1> here */
             spi-max-frequency = <25000000>;    /* <-- Use <1000000> here */
             cdns,tshsl-ns = <60>;
             cdns,tsd2d-ns = <60>;
             cdns,tchsh-ns = <60>;
             cdns,tslch-ns = <60>;
             cdns,read-delay = <0>;
     };
};

此致、Andreas

我们应用了您建议的修补程序并能够使其正常工作、因此它似乎与您建议的一样。

探测闪存后、我们将 U-Boot 文件刷写到闪存中：

 sf probe
SF: Detected w25q128jw with page size 256 Bytes, erase size 4 KiB, total 16 MiB
load mmc 1:1 ${loadaddr} tiboot3.bin
293089 bytes read in 41 ms (6.8 MiB/s)
sf update $loadaddr 0x0 $filesize
device 0 offset 0x0, size 0x478e1
293089 bytes written, 0 bytes skipped in 1.236s, speed 242230 B/s
load mmc 1:1 ${loadaddr} tispl.bin
1243171 bytes read in 121 ms (9.8 MiB/s)
sf update $loadaddr 0x80000 $filesize
device 0 offset 0x80000, size 0x12f823
1243171 bytes written, 0 bytes skipped in 5.209s, speed 244245 B/s
load mmc 1:1 ${loadaddr} u-boot.img
988099 bytes read in 98 ms (9.6 MiB/s)
sf update $loadaddr 0x280000 $filesize
device 0 offset 0x280000, size 0xf13c3
988099 bytes written, 0 bytes skipped in 4.157s, speed 243165 B/s

之后、我们将引导模式切换更改为 xSPI 模式 (1100111000000000) 并获得以下结果：

U-Boot SPL 2023.04-ti-g2bedcd265ca6 (May 13 2025 - 07:07:38 +0000)
SYSFW ABI: 4.0 (firmware rev 0x000a '10.1.8--v10.01.08 (Fiery Fox)')
SPL initial stack usage: 13408 bytes
Trying to boot from SPI
jedec_spi_nor flash@0: unrecognized JEDEC id bytes: ef, 80, 18
SPI probe failed.
SPL: failed to boot from all boot devices
ERROR ### Please RESET the board ###

我们假设此错误可能是由于次级引导加载程序中“tispl.bin"文件“文件中的问题而发生的、但我们使用了相同的文件从 SDcard 引导、没有收到任何错误。 或由于闪存频率与引导模式中设置的频率不匹配而导致的问题。 您能找出问题所在吗？ 与此同时,我们也会尝试从我们这边。  

我们发现问题出在引导映像检查闪存 JEDEC ID 的方式上。 由于某种原因、在 U-Boot 中、电路板加载“tiboot3.bin"，“，仅、仅检查周期闪存的 ID、因此我们会生成错误。 我们在“spi-nor-ids.c"文件“文件中添加了闪存的 JEDEC ID 以及 Cypress ID、并成功解决了该问题。 为什么这可能是导致的、我们使用的方法感觉像是一个解决方法、而不是解决它、因此有一种正确的方法可以做到这一点。

我们应用了您建议的修补程序、并且能够使其正常工作、因此它似乎与您建议的一样。

好的、感谢您的反馈。

我们在“spi-nor-ids.c"文件“文件中添加了 FLASH 的 JEDEC ID 以及 cypress 1、并能够解析它。

如果您的 Flash 是 Winbond Flash、则应将 ID 添加到相应的 #ifdef CONFIG_SPI_FLASH_WINBOND ... #endif部分。 您需要确保 CONFIG_SPI_FLASH_WINBOND 为 U-Boot SPL R5 启用该功能。 那么它应该可以正常工作。 如果不能像这样工作、请随时提供完整的补丁、其中添加了 ID 和更新的 defconfig、然后我可以更深入地了解。

此致、Andreas