Forum Discussion
New ContributorAgilex 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.
1 Reply
JamesG_Altera1. Hardware/software paths
- U-Boot sf read: U-Boot SPI-NOR → Cadence QSPI controller at 0xff8d2000 → QSPI flash access window at 0xff900000 → flash. It is an HPS controller transaction, not an SDM mailbox data read.
- Linux /dev/mtd0: Linux Cadence QSPI → SPI-NOR → MTD. mtd0 is the first device-tree partition, not necessarily the entire flash - in the standard RSU setup for use with rsu_client, this begins at the start of SPT0.
- librsu / stratix10-rsu: librsu reads SPT/CPB data through /dev/mtdX; stratix10-rsu uses the ATF/SDM mailbox for RSU status, update, and control operations.
2. Can SDM handoff affect Linux reads?
Yes, indirectly. A failed QSPI ownership handoff, incorrect QSPI clock, disabled/mismatched device-tree node, or incompatible flash timing/configuration could make Linux SPI-NOR reads fail. Once ownership and timing are correctly established, Linux accesses the flash through its own Cadence/SPI-NOR driver rather than through the SDM mailbox.
3. Is a bridge, firewall, or special initialization required?
No FPGA bridge or special firewall step is normally required. The required setup is:
- successful early-boot QSPI ownership/open
- correct QSPI reference-clock information passed to Linux
- QSPI and flash nodes enabled and correctly described in the device tree
- for RSU, valid RSU partition metadata/DT handoff so the SPT location is correct
Linux then initializes the QSPI controller itself.
4. Known Agilex 7M cold-boot concerns
There is no indication of a generic Agilex 7M silicon defect that makes QSPI/RSU fail on cold boot.
Advice on Next Steps
I recommend first confirming the QSPI reference clock is correctly configured in Linux. This is an easy thing to miss as it requires a specific command to be run in U-Boot before booting Linux. For a reference of how to do this, please use the Baseline reference design:
https://altera-fpga.github.io/rel-26.1/embedded-designs/agilex-7/m-series/hbm2e/ug-gsrd-agx7m-hbm2e
In U-boot you will find a command "linux_qspi_enable", which edits the Linux device tree and sets the clock frequency of the QSPI clock source to a value determined by the U-boot device architecture code for Altera FPGAs (environment variable qspi_clock). This command (or an equivalent) must be run in U-boot before booting into Linux. You can confirm if this has been done correctly by first stopping in U-boot and running:
printenv qspi_clock
And then booting into Linux and inspecting the device tree location, which should be one of the following:
/proc/device-tree/soc/clocks/qspi-clk/clock-frequency
/proc/device-tree/soc/clkmgr/clocks/qspi_clk/clock-frequency
/proc/device-tree/clocks/qspi-clk/clock-frequencyConfirm the value in the booted Linux device tree is the same as the value of the qspi_clock variable in U-Boot.
