Forum Discussion
Agilex 7M RSU: Incorrect SPT Magic Number During Cold Boot on the Agilex 7M HBM2e board
We are investigating an intermittent RSU SPT detection issue on the Agilex 7M HBM2e board.
The main observation is:
Cold boot → automatic U-Boot boot → Linux
- rsu_client reports an invalid SPT magic number:
Bad SPT1 magic number 0x577134E7 Bad SPT0 magic number 0x577134E7 No valid SPT0 or SPT1 found
Cold boot → stop at U-Boot → wait → boot Linux
- The issue does not occur.
Warm reboot
- The issue does not occur.
We verified the SPT directly from U-Boot:
sf probe SF: Detected mt25qu02g with page size 256 Bytes, erase size 64 KiB, total 256 MiB sf read 0x02000000 0x00f10000 0x40 SF: 64 bytes @ 0xf10000 Read: OK md.b 0x02000000 0x40 02000000: 27 34 71 57 01 00 00 00 07 00 00 00 e3 56 ee e0 ...
The expected SPT magic is 0x57713427, stored as bytes 27 34 71 57.
Linux identifies the same flash as:
/sys/bus/spi/devices/spi0.0 modalias: spi:mt25qu02g driver: spi-nor
and the device path confirms:
/sys/devices/platform/soc/ff8d2000.spi/spi_master/spi0/spi0.0
U-Boot dm tree also shows:
spi cadence_spi spi@ff8d2000 spi_flash jedec_spi_nor flash@0
Therefore, both U-Boot and Linux are using the Cadence QSPI controller at 0xFF8D2000.
For Linux access, we tested /dev/mtd0 corresponding to the QSPI region starting at 0x00F10000. We tested reads using bs=4 as well as byte-wise reads. The results showed that the behavior depends on the read method, and byte-wise reads have shown inconsistent data, while other MTD read methods can return the expected SPT bytes.
The Linux RSU driver/librsu nevertheless reports:
Bad SPT0 magic number 0x577134E7 Bad SPT1 magic number 0x577134E7
We would like your guidance on the following:
- Since the QSPI flash is physically connected to the SDM on this board, what is the exact hardware/software path used by:
- U-Boot sf read
- Linux /dev/mtd0
- librsu / stratix10-rsu
- Can the SDM/QSPI initialization or HPS-to-SDM handoff affect the Linux SPI-NOR read path during cold boot?
- Is any bridge, firewall, or QSPI initialization required before Linux accesses the QSPI flash/RSU SPT?
- Is there any known Agilex 7M issue involving QSPI/SDM initialization, Linux SPI-NOR, or RSU SPT access during cold boot?
Our objective is to determine whether the SPT is actually being corrupted in flash or whether the incorrect magic number is caused by the Linux/RSU QSPI access path.
To resolve this issue and ensure a reliable automated boot sequence, please provide:
- U-Boot Configuration: The recommended bootcommand settings or environment variables needed to initialize the RSU subsystem properly.
- Patches or Updates: Any official driver or SDM firmware patches available to fix this intermittent initialization error.
We need a stable, automated boot workflow to proceed with our deployment validation. Thank you for your support and guidance on this issue.
Thanks and Regards,
M.Charan.