Agilex 5 Multiboot SPL Fails to Probe QSPI - Agilex 5 Multiboot SPL Fails to Probe QSPI Dear all, I'm trying to activate the RSU Multiboot feature. Unfortunately it seems like the SPL can not probe the QSPI flash. So far I've been able to access QSPI from U-Boot and Linux. My set up: - Quartus 25.1.1 - Based on QPDS25.1_REL_GSRD_PR - HPS First - QSPI Ownership is HPS - U-Boot proper is stored on FAT partitions. Here is the console output: U-Boot SPL 2025.01-gcd3a9044d661-dirty (Jan 29 2026 - 16:45:35 +0000) Reset state: Cold MPU 1250000 kHz L4 Main 400000 kHz L4 sys free 100000 kHz L4 MP 200000 kHz L4 SP 100000 kHz SDMMC 50000 kHz is_ddr_csr_clkgen_locked: ddr csr io96b_0 clkgenA is successfully locked io96b_cal_status: Calibration for IO96B instance 0x18400400 done at 0 msec! init_mem_cal: Initial DDR calibration IO96B_0 succeed DDR: Calibration success io96b_mb_init: num_instance 1 io96b_mb_init: get memory interface IO96B 0 io96b_mb_init: IO96B 0 mem_interface 0: ip_type_ret: 0x1 io96b_mb_init: IO96B 0 mem_interface 0: instance_id_ret: 0x0 io96b_mb_init: IO96B 0: num_mem_interface: 0x1 DDR4: 2048 MiB ecc_enable_status: ECC enable status: 0 DDR: size check success DDR: firewall init success DDR: init success QSPI: Reference clock at 500000 kHz WDT: Started watchdog@10d00200 with servicing every 1000ms (11s timeout) Trying to boot from MMC1 RSU: Error - spi_flash_probe failed! ERROR: could not find u-boot proper(SSBL): SSBL.@xx! And here is the relevant dts section: &qspi { status = "okay"; flash0: flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "micron,mt25qu256a", "jedec,spi-nor"; reg = <0>; spi-max-frequency = <6250000>; m25p,fast-read; cdns,page-size = <256>; cdns,block-size = <16>; cdns,read-delay = <2>; cdns,tshsl-ns = <50>; cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>; partitions { compatible = "fixed-partitions"; #address-cells = <1>; #size-cells = <1>; partition@0 { label = "Boot and fpga data"; reg = <0x00a10000 0x015f0000>; phandle = <0x53>; }; }; }; }; Kind Regards, Eric Opitz Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI Thanks for posting the solution. Is there anyway you can think of this error could be avoided or how we could prevent people from seeing this problem? Thanks, Sue Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI Dear all, I was able to find a solution to this issue. Apparently my defconfig was the culprit as it was based on an older QPDS version. Adding the defconfig entries from the QPDS25.1 solved the problem. The Active Serial Clock speed was not the issue and I left it at the QPDS25.1 default (125 MHz). Here are the changes to my defconfig. I don't know which change solved the issue: Removed: CONFIG_SYS_MALLOC_F_LEN=0x2000 CONFIG_NR_DRAM_BANKS=1 CONFIG_ENV_OFFSET=0x04100000 CONFIG_TARGET_SOCFPGA_AGILEX5_SIMICS=y CONFIG_CMD_SF=y CONFIG_DOS_PARTITION=y CONFIG_SPL_DOS_PARTITION=y CONFIG_CMD_NAND=n CONFIG_CMD_NAND_TRIMFFS=n CONFIG_CMD_NAND_LOCK_UNLOCK=n CONFIG_SPL_MTD_SUPPORT=y CONFIG_CMD_UBIFS=n CONFIG_MTD_UBI=n CONFIG_MTD_UBI_WL_THRESHOLD=4096 CONFIG_MTD_UBI_BEB_LIMIT=20 CONFIG_ENV_IS_IN_UBI=n CONFIG_FPGA_INTEL_PR=y CONFIG_MTD=y CONFIG_SYS_NAND_U_BOOT_LOCATIONS=n CONFIG_UBI_SILENCE_MSG=n CONFIG_DM_ETH=y CONFIG_UBIFS_SILENCE_MSG=y CONFIG_SPL_STACK=0x73000 CONFIG_MTD_RAW_NAND=n CONFIG_SPL_NAND_SUPPORT=n CONFIG_SPL_NAND_FRAMEWORK=n CONFIG_NAND_BOOT=n CONFIG_NAND_DENALI_DT=n CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT_HUSH_PS2="> " CONFIG_CMD_FS_GENERIC=y CONFIG_CMD_PART=y CONFIG_LZO=y CONFIG_CMD_DHCP=y CONFIG_SPI_FLASH_MACRONIX=y CONFIG_SPI_FLASH_GIGADEVICE=y CONFIG_SPI_FLASH_WINBOND=y CONFIG_SPI_FLASH_ISSI=y Added: CONFIG_NR_DRAM_BANKS=3 CONFIG_CMD_NAND_TRIMFFS=y CONFIG_CMD_NAND_LOCK_UNLOCK=y CONFIG_ENV_IS_IN_UBI=n CONFIG_USE_BOOTFILE=y CONFIG_BOOTFILE="kernel.itb" CONFIG_SYS_NAND_U_BOOT_LOCATIONS=y CONFIG_SPL_MTD=y CONFIG_USB_HUB_DEBOUNCE_TIMEOUT=3000 CONFIG_SPL_STACK=0x71000 CONFIG_MTD_RAW_NAND=y CONFIG_SPL_NAND_SUPPORT=y CONFIG_SPL_NAND_FRAMEWORK=y CONFIG_BLOBLIST=y CONFIG_BLOBLIST_SIZE=0x1000 CONFIG_BLOBLIST_ADDR=0x72000 CONFIG_HANDOFF=y I took your advice and added some log messages to u-boot: - I tested this on the arrow dev kit - I used version QPDS25.1 - I activated multiboot and set QSPI Ownership to HPS - I added some debug messages From the log you can see that the speed is retrieved from the SDM and this value is used in cadence_spi_probe(). But afterwards there are two more calls to cadence_spi_set_speed() with 100 MHz (probably from dts) and 1 MHz (probably from CONFIG_SF_DEFAULT_SPEED) respectively. Therefore I think the actual speed is 1 MHz. Perhaps you can verify this and adapt the log message "QSPI: Reference clock at 500000 kHz". is_ddr_csr_clkgen_locked: ddr csr io96b_0 clkgenA is successfully locked io96b_cal_status: Calibration for IO96B instance 0x18400400 done at 0 msec! init_mem_cal: Initial DDR calibration IO96B_0 succeed DDR: Calibration success io96b_mb_init: num_instance 1 io96b_mb_init: get memory interface IO96B 0 io96b_mb_init: IO96B 0 mem_interface 0: ip_type_ret: 0x1 io96b_mb_init: IO96B 0 mem_interface 0: instance_id_ret: 0x0 io96b_mb_init: IO96B 0: num_mem_interface: 0x1 LPDDR4: 1024 MiB ecc_enable_status: ECC enable status: 0 DDR: size check success DDR: firewall init success DDR: init success QSPI: Reference clock at 500000 kHz Bloblist at 72000 not found (err=-2) WDT: Not starting watchdog@10d00200 Trying to boot from MMC1 get_spl_slot spi_flash_probe CONFIG_SF_DEFAULT_BUS. 0 CONFIG_SF_DEFAULT_CS. 0 CONFIG_SF_DEFAULT_SPEED. 1000000 CONFIG_SF_DEFAULT_MODE. 8195 cadence_spi_probe priv->ref_clk_hz = 500000000 cadence_spi_probe - return cadence_spi_set_speed hz = 100000000 cadence_spi_set_speed - return cadence_spi_set_speed hz = 1000000 cadence_spi_set_speed - return RSU current image: 0x01000000 RSU state: 0x00000000 RSU error location: 0x00000000 RSU error details: 0x00000000 RSU: Partition 'BOOT_INFO' start=0x00000000 length=0x00210000 RSU: Partition 'FACTORY_IMAGE' start=0x00210000 length=0x00800000 RSU: Partition 'image1' start=0x01000000 length=0x00800000 RSU: Partition 'image2' start=0x01800000 length=0x00800000 RSU: Partition 'SPT0' start=0x00a10000 length=0x00008000 RSU: Partition 'SPT1' start=0x00a18000 length=0x00008000 RSU: Partition 'CPB0' start=0x00a20000 length=0x00008000 RSU: Partition 'CPB1' start=0x00a28000 length=0x00008000 get_spl_slot - return rsu_spl_mmc_filename, filename: u-boot_image1.itb spl_mmc_load_image: Boot from filename: u-boot_image1.itb spl_load_image_fat: error reading image u-boot_image1.itb, err - -5 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ### Kind Regards, Eric Opitz Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI Hi EricOpitz Do you have an update for the previous comment? Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI A bit more information, i am not sure why UBOOT Proper and linux works for you. If the Frequency is wrong, it would have failed from the start. Can you dump your device tree for Linux here? The design is as follow so that you can debug this on your own. The SDM gets the AS_CLK from your QHIP platform designer setting The SDM calculates the QSPI REF clock , here 500MHz based on your 125MHz The FSBL UBOOT gets the QSPI REF Clock via mailbox as you saw. The FSBL writes the QSPI REF clock to scratch boot register which is later shared to the UBOOT Proper The UBOOT proper should still use 500MHz as the ref clock. The Kernel gets the 500MHz by running a script in UBOOT Proper CLI, which updates the Linux kernel's freq. SOCFPGA_AGILEX # fdt addr 0x8000000 Working FDT set to 8000000 SOCFPGA_AGILEX # run linux_qspi_enable SF: Detected mt25qu02g with page size 256 Bytes, erase size 64 KiB, total 256 MiB Enabling QSPI at Linux DTB... Working fdt: 08000000 QSPI clock frequency updated SOCFPGA_AGILEX # Can you place printf to determine why the spi flash probe fails? Can you print out the ref_clk_hz? I would like to see whether the UBOOT Proper uses a different ref clock than the UBOOT SPL. And, also to double confirm the ref freq used. Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI hi, You need to set the AS_CLK to a frequency less than 80MHz which is your NOR flash's max frequency. The 500MHz is the QSPI REF clock which is 4 times the AS_CLK. This is an internal design where the SDM chooses the REF clock based on your AS_CLK input. Try to pick another AS_CLK less than 80MHz in the Quartus GUI below. Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI Thanks for the reply. Let us try to confirm a couple of things. I am not 100% sure why UBOOT Proper SPI probe works, and Linux works for you. Are you using the default GSRD/GHRD uboot.itb and kernel.itb from us without modification? The only change you did is the change of the NOR flash as compared to our GSRD? Did you then change the NOR flash type in the Uboot.itb Device tree and Linux device tree? What is your Linux kernel device tree? The GSRD linux kernel DT is as shown below and the UBOOT proper as well as the SPL UBOOT should use the same. Did you modify all of them to use the 32MB Nor flash? You can modify the AS_CLK here. More details below. The design is like this (This will help you to debug on your own): The SDM determines the QSPI CLOCK based on the requested AS_CLOCK. So, if your flash AS_CLOCK is a max of 80MHz, you can use anything up to that frequency. Let us say, we use 50MHz or anything less than the max of 80MHz from the dropdown menu of Quartus. The displayed QSPI reference clock seems to 500MHz on your end. Based on 500MHz, it is likely your AS_CLK is 125MHz which is higher than 80MHz. I am not 100% sure. The Quartus should tell you the highest possible AS_CLK frequency and only allow you to change to specific list of frequencies only. There is basically a 4:1 clock relation between the QSPI CLOCK and the AS_CLK. What AS_CLK did you use in the Quartus platform designer? Given the fact that Linux also works with the default spi max frequency of 400MHz based on your DTB info, i think 400MHz is the right frequency. QSPI ref clock is then, determined by SDM based on an internal clock table. It should be QSPI_CLOCK >= 4x AS_CLOCK. The SPL will then, get the QSPI_CLOCK from the SDM via mailbox. (in your case, this is 500MHz) The SPL writes the QSPI_CLOCK value into a scratch boot register COLD 0. The SSBL should read the contents of the scratch boot register COLD0 during spi probe to configure the QSPI controller The SSBL will also write into the environment variables. The env variable is for example, " qspi_clock=<0x17d78400>" The user can run a script at the UBOOT proper CLI to overwrite the Linux Device tree for QSPI clock frequency so, the Kernel gets the right clock frequency. Did you run this in your test? Example, SOCFPGA_AGILEX # fdt addr 0x8000000 Working FDT set to 8000000 SOCFPGA_AGILEX # run linux_qspi_enable SF: Detected mt25qu02g with page size 256 Bytes, erase size 64 KiB, total 256 MiB Enabling QSPI at Linux DTB... Working fdt: 08000000 QSPI clock frequency updated SOCFPGA_AGILEX # One thing I am not sure, is that, if the Frequency received by SDM is wrong, the UBOOT proper should also fail. Well even the SDM should fail to read the QSPI NOR flash and hence failing the HPS boot. But in your case it didn't. This is because during UBOOT proper spi probe, the frequency is fetched from the Scratch boot register cold0 using the cm_get_qspi_controller_clk_hz(). Could you add a printf here to find out what ref_clk_hz values you are using in UBOOT Proper versus UBOOT SPL for us to double confirm? In general, the root-cause is not very clear to me. Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI Dear all, To clarify: - I am using a custom board. - I am able to access QSPI from U-Boot proper using the dts from the previous post. - I am able to access QSPI from Linux. - I am not able to access QSPI from U-Boot SPL. - The QSPI Flash only contains U-Boot SPL and SDM Firmware. - The U-Boot Proper, FPGA image, and Linux kernel image are stored on the SD Card. U-Boot Proper is stored on FAT partition and is loaded by U-Boot SPL. - The QSPI Flash from the DTS (MT25QU256) is correct and you are correct in saying that it is only 32MB. We have 3 partitions (factory + 2 others) of 8MB each. During updates the .rpd file is around 800kB so (assuming .rpd doesn't contain compressed images?) the size should be sufficient. Yes, the message "QSPI: Reference clock at 500000 kHz" could be the culprit. The flash only supports up to 80 MHz. I tried lowering this setting but I couldn't figure out which setting to change. Can you help here? From the u-boot source code I see that the SPL gets this frequency via mailbox request to SDM (arch/arm/mach-socfpga/mailbox_s10.c:mbox_qspi_open()). So it could be a setting in Quartus/Qsys or in the u-boot dts. I've checked both but I don't find anything that sets the clock to 500MHz. - In my dts I set the speed to 6,25 MHz (see previous post). - In the decompiled u-boot dtb I see soc/clocks/qspi-clk { clock-frequency = <0xbebc200>; } (200MHz) - In Qsys I see "Peripheral PLL C3" and "PSI Ref" at 500MHz. As there are a number of other clocks derived from those I can't easily test changing this value. - In Quartus the "Active serial clock source" is set to 125MHz. Kind Regards, Eric Opitz Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI Hi EricOpitz Do you have any update for the question in the previous comment? Replies: Re: Agilex 5 Multiboot SPL Fails to Probe QSPI hi, I think your Device tree could be the culprit. It does not seem right. Let us go through the questions below. Can i seek clarification on your statement "So far I've been able to access QSPI from U-Boot and Linux."? Are you able to access QSPSI in UBOOT-proper (SSBL) and Linux ? The QSPI only failed during SPL RSU? I am a bit confuse here. Let me assume you did not actually see QSPI working on your target board. What board are you using? My assumption is a custom board. The NOR Flash you are using is only 32MB. " compatible = "micron,mt25qu256a", "jedec,spi-nor";" Your flash is a bit too small to support both RSU and QSPI boot for HPS. Is this the correct Flash device? Is your Device tree correct? Typically, the RSU takes up to 64MB (we could go lower if there is no need to support multiple RSU slots), and the remaining partitions cater to the HPS secondary boot images like SSBL UBOOT, Linux kernel and the Linux ROOTFS in UBIFS format. The SSBL UBOOT is of course a fixed address in the NOR flash so, the SPL could locate it during boot-up. The SSBL UBOOT address is CONFIG_SYS_SPI_U_BOOT_OFFS=0x04000000 (from UBOOT source, configs/socfpga_agilex5_defconfig) The partitions that we used for the Altera premium devkit is shown below. Of course this is just an example. You are free to change the partition but you may have to modify the Device tree and UBOOT config especially the U_BOOT offset address. Are you booting everything from QSPI NOR flash? Also the spi-max-frequency is different. Also, the Flash partition seems different too. Also, "QSPI: Reference clock at 500000 kHz" <- The QSPI clock is 500MHz which is different than the one in your DT. Is this correct? Is this your custom board? The official GSRD NOR flash is https://github.com/altera-fpga/u-boot-socfpga/blob/socfpga_v2025.10/arch/arm/dts/socfpga_agilex5_socdk.dts flash0: flash@0 { #address-cells = <1>; #size-cells = <1>; compatible = "mt25qu02g"; reg = <0>; spi-max-frequency = <100000000>; m25p,fast-read; cdns,page-size = <256>; cdns,block-size = <16>; cdns,read-delay = <1>; cdns,tshsl-ns = <50>; cdns,tsd2d-ns = <50>; cdns,tchsh-ns = <4>; cdns,tslch-ns = <4>; - 2026-01-29