HPS SDRAM Calibration Failed
To whom it may concern, The HPS of a Cyclone V SoC based board that I designed is failing the booting process. In which the following error message is outputted to the console: U-Boot SPL date and time SDRAM Calibration Failed. ERROR ### Please Reset the board ### I’m trying to determine the cause of the SDRAM calibration failure by enabling calibration reporting as indicated in: https://www.intel.com/content/www/us/en/docs/programmable/683841/17-0/enabling-the-debug-report-for-arria.html https://www.intel.com/content/www/us/en/docs/programmable/683841/17-0/determining-the-failing-calibration.html but I’m only getting the above mentioned message without an indication of the failing SDRAM stage and cause. please advise on how to get the preloader to output debug insights to the console. Please note that the approach described in the link below was used to create the Preloader: https://www.rocketboards.org/foswiki/Documentation/BuildingBootloaderCycloneVAndArria10 Also, please advise on the sequence of failure messages that are outputted by the Preloader. Regards,
SDRAM calibration failed.
Hello, after Enpirion stopped selling some of the parts we used on our board, we had to redesign it. We assembled ten boards, and on two of them, I’m now getting an SDRAM calibration error in U-Boot. I’d like to enable the SDRAM calibration report to understand the cause of the error. However, the described method of adding. #define RUNTIME_CAL_REPORT 1 in the sequencer_defines.h file didn’t work. I generated the files using the QTS filter script, but there was no change. Could you please tell me how to properly enable the SDRAM calibration report so I can debug the issue?
25.3 PRO Release
Version: Release 25.3 PRO Quartus Build/TAG: B109/QPDS25.3_REL_GSRD_PR Release Date: October 10, 2025 Device Affected: Agilex™ 3, Agilex™ 5, Agilex™ 7, Startix® 10, Arria® 10 Release Type: Major release/Binary release Binary Release Path: http://releases.rocketboards.org/2025.10/ Major Features Released Support of GHRD 2.0 in Agilex™ 5 which includes foundational boot to Linux, ability to create compatible phase 2 bitstreams, parameterized HPS for maximum performance and best practices. Support of GSRD 2.0 Yocto layers for the Agilex 5 E-Series Premium DevKit with OOBE daughtercard for the GHRD 2.0 baseline design. Agilex 5 GSRD Development User Experience Improvement through KAS using a graphical/text interface to configure a limited number of high-level options on top of simplified Yocto recipes. - GSRD 2.0 with Kas Build System Support for running Agilex 5 Simics Simulation under the GSRD 2.0 framework. Booting from SD Card and QSPI is supported. - Exercising Simics Simulation from GSRD 2.0 Support GHRD and GSRD for Agilex™ M-Series PRQ HBM2e for DK-Sl-AGM039EA development kit. The GSRD is capable of booting to Linux. - Build the GSRD for DK-DEV-AGM039EA Hypervisor Multi-OS Support Example, demonstrating Linux and Zephyr running side-by-side in the HPS cluster. - HPS Xen Hypervisor GSRD System Example Design: Agilex™ 3 FPGA and SoC C-Series Development Kit Support for monitoring of SEU errors from the SDM in the HPS in Agilex™ 7. Add capability to measure the latency of Linux SMC calls. Support Nios V Lockstep application with a fail-safe mechanism
ERROR: Config PwrMgr handoff failed. error -1
Hi, After switching my Agilex 5 work from Quartus 24.3.1 to Quartus 25.3.0, I encountered the following issue. When I try to start my SoC platform, instead of the normal boot process (and UART output), I get the following error: ERROR: Config PwrMgr handoff failed. error -1 ASSERT: plat/intel/soc/agilex5/soc/agilex5_power_manager.c:80 BACKTRACE: START: assert 0: EL3: 0xc98 1: EL3: 0xa428 2: EL3: 0x78cc 3: EL3: 0x54f8 4: EL3: 0xb40 5: EL3: 0xe0 BACKTRACE: END: assert Additional information: - Booting from QSPI (FPGA-first mode) - Zephyr OS - Device: A5ED065BB32AE4SR0 - Board: Atum A5 Evaluation Board - Normal operating conditionsCyclone V: how to boot Linux from QSPI?
I am building a system with Buildroot and Barebox as the bootloader. I can generate a working SD card image. Now, I want to transpose this to a 64MiB NOR QSPI flash on the SoM. I read the HPS boot guide, that describes the required SD card partition layout, but it is not very verbose about the QSPI... I read that UBI + UBIFS is very common for NOR flash. I understand that it is well suited for the rootfs. But where should I place the pre-loader? Could someone give more details to install Linux on a QSPI and boot from it?
Arria10 Secure Boot : unable to boot SPL FUSE
On the Arria10, a signed SPL using the FUSE method does not boot at all, but it does boot when using the USER method. The behavior is the same as if we had not programmed the fuses. Details : Using the alt_authtool.py utility found in the repository, the SPL is signed. The tool accepts the following options: - fuse: embed root pubkey in image. BootROM verifies its hash against device fuses. - fpga: fetch trusted root pubkey from location in FPGA memory. - user: embed root pubkey in image. BootROM does not verify. read EC key Private-Key: (256 bit) priv: 9e:e1:55:ec:b6:be:bd:15:22:80:73:3a:66:ee:07: fa:58:26:1f:d0:13:c8:e5:6a:b0:05:bc:23:f7:dc: 58:46 pub: 04:0d:b3:cf:29:e9:54:60:7a:1c:d2:99:ca:5e:dd: d0:72:98:0c:5f:89:33:2c:16:35:24:4f:65:ad:ba: 23:45:9d:ec:5e:22:06:9f:b6:b2:bd:d0:19:8c:53: aa:af:20:1c:df:72:0f:02:e9:44:b0:86:1a:d5:b5: 7a:2c:81:65:dd ASN1 OID: prime256v1 NIST CURVE: P-256 First, we generate the SPL using the user option, then follow the Application Note, and the Arria10 board boots correctly. python3 -B -E $(which alt_authtool.py) sign -t user -k ${ROOT_KEY_PEM} -i ${DEPLOYDIR}/u-boot-spl-public-key.sfp -o ${DEPLOYDIR}/u-boot-spl-public-key-signed.sfp --fuseout ${DEPLOYDIR}/u-boot-spl-public-key-signed.fuse The following text is displayed: SHA256 digest of root public key: 3dfe63cab8b3657db2ebdeaca234f0d6ec3744a3905d7e04dfa63a5a6721dfe7 ==> The SPL with USER option boots correctly. Next, we generate the SPL using the fuse option. With this, the FPGA should only be able to boot if the fuses are programmed (volatile or non-volatile). When alt_authtool.py is executed, it displays the SHA256 hash of the public key. We use this public key to construct a file containing: key1 3DFE63CAB8B3657DB2EBDEACA234F0D6EC3744A3905D7E04DFA63A5A6721DFE7 Using this key file, we generate an EKP file with Quartus (compressed into a zip and attached to the present message). In the end, using the Quartus Prime Programmer, we program the Arria10 board with EKP file (this takes less than one second). Immediately after programming the volatile fuses, the board resets (the power supply current drops from 1A to 0.8A, and then returns to 1A), and the fan stops and restarts. ==> However, on the serial console, the SPL signed with the FUSE method does not display any messages, and neither U-Boot nor the kernel is loaded. On the other hand, the SPL signed with the USER method is still able to boot, even with the volatile fuses programmed (boot messages appear, and both U-Boot and the kernel are loaded). Question: Can you help us to solve this boot issue with the FUSE method ? The behavior is like volatile fuses are not programmed ! If you need more information and details, please tell us. Thanks in advance. Christian & Baptiste
Agilex 5 GTS to HPS CDC/STA issue: help request!
I am trying to bring-up the GTS component on the A5. The general idea is: Oscillator -> GTS -> FIFO -> DMA -> HPS -> Application. The Qsys diagram looks as followed (HPS section omitted for brevity): It's also worth noting that the Osc -> FIFO -> DMA-> HPS design has been tested and works ok. Furthermore, the only changes I have made to the GTS and FIFO IP are as followed: GTS FEC/PMA PHY settings changed from factory: ------------------------------ Datapath clocking mode : PMA TX/RX PMA interface FIFO mode : Register TX/RX clock options : Word Clock Avalon DC FIFO settings changed from factory: ------------------------------ Symbols per beat : 4 Bits per symbol : 8 FIFO depth : 32 Channel width : 0 Error width : 0 I have compiled two different designs: ----------------- 1: Reduced test ----------------- Clock domain A: Oscillator -> GTS -x Clock domain B: 32'b1 -> FIFO -> DMA -> HPS The linking HDL in the top level (HPS section omitted for brevity): module top(...); ... // GTS signals wire gts_i_rx_cdr_refclk; wire gts_i_tx_pll_refclk; reg gts_i_tx_reset, gts_i_rx_reset; wire gts_o_tx_reset_ack, gts_o_rx_reset_ack; wire gts_i_tx_coreclkin, gts_i_rx_coreclkin; wire gts_o_tx_clkout, gts_o_rx_clkout; wire gts_o_tx_serial_data, gts_o_tx_serial_data_n; wire gts_i_rx_serial_data, gts_i_rx_serial_data_n; wire [79:0] gts_i_tx_parallel_data; wire [79:0] gts_o_rx_parallel_data; wire osc_clk, raw2s_clk, fifo_clkin; wire osc_rst, raw2s_rst, fifo_reset; wire [31:0] osc_pattern_o; wire [31:0] raw2s_data_i; // reset always @(posedge system_clk_100) begin if (system_reset) begin gts_i_tx_reset <= 1'b1; gts_i_rx_reset <= 1'b1; end else begin if((gts_o_tx_reset_ack==1'b1) && (gts_o_rx_reset_ack==1'b1)) begin gts_i_tx_reset <= 1'b0; gts_i_rx_reset <= 1'b0; end end end // GTS internal clocks assign gts_i_tx_coreclkin = gts_o_tx_clkout; assign gts_i_rx_coreclkin = gts_o_rx_clkout; // serial data assign gts_i_rx_serial_data = gts_o_tx_serial_data; assign gts_i_rx_serial_data_n = gts_o_tx_serial_data_n; // GTS to DMA assign fifo_clkin = system_clk_100; assign fifo_reset = ~system_reset; assign raw2s_clk = system_clk_100; assign raw2s_rst = ~system_reset; assign raw2s_data_i = 32'b1; // Oscillator to GTS assign osc_clk = gts_o_tx_clkout; assign osc_rst = gts_i_tx_reset; assign gts_i_tx_parallel_data[31:0] = osc_pattern_o; // Qsys Top module qsys_top soc_inst ( .clk_100_clk (system_clk_100), .ninit_done_ninit_done (ninit_done), .intel_directphy_gts_0_i_rx_cdr_refclk_p_clk (REFCLK), .intel_directphy_gts_0_i_tx_pll_refclk_p_clk (REFCLK), .intel_directphy_gts_0_i_tx_reset_tx_reset (gts_i_tx_reset), .intel_directphy_gts_0_i_rx_reset_rx_reset (gts_i_rx_reset), .intel_directphy_gts_0_o_tx_reset_ack_tx_reset_ack (gts_o_tx_reset_ack), .intel_directphy_gts_0_o_rx_reset_ack_rx_reset_ack (gts_o_rx_reset_ack), .intel_directphy_gts_0_i_tx_coreclkin_clk (gts_i_tx_coreclkin), .intel_directphy_gts_0_i_rx_coreclkin_clk (gts_i_rx_coreclkin), .intel_directphy_gts_0_o_tx_clkout_clk (gts_o_tx_clkout), .intel_directphy_gts_0_o_rx_clkout_clk (gts_o_rx_clkout), .intel_directphy_gts_0_o_tx_serial_data_o_tx_serial_data (gts_o_tx_serial_data), .intel_directphy_gts_0_o_tx_serial_data_n_o_tx_serial_data_n (gts_o_tx_serial_data_n), .intel_directphy_gts_0_i_rx_serial_data_i_rx_serial_data (gts_i_rx_serial_data), .intel_directphy_gts_0_i_rx_serial_data_n_i_rx_serial_data_n (gts_i_rx_serial_data_n), .intel_directphy_gts_0_i_tx_parallel_data_i_tx_parallel_data (gts_i_tx_parallel_data), .intel_directphy_gts_0_o_rx_parallel_data_o_rx_parallel_data (gts_o_rx_parallel_data), .intel_srcss_gts_0_i_src_rs_priority_src_rs_priority (1'b1), .oscillator_0_clk_clk (osc_clk), .oscillator_0_rst_reset (osc_rst), .oscillator_0_oscillator_pattern_o_new_signal (osc_pattern_o), .raw_to_stream_0_conduit_end_1_new_signal (raw2s_data_i), .raw_to_stream_0_rst_reset (raw2s_rst), .raw_to_stream_0_clk_clk (raw2s_clk), .st_dc_fifo_0_in_clk_clk (fifo_clkin), .st_dc_fifo_0_in_clk_reset_reset_n (fifo_reset), ... ); ... endmodule The STA output: And the system boot (SUCCESS): Downloading FPGA bitstream... Using ethernet@10830000 device TFTP from server **bleep**.**bleep**.**bleep**.**bleep**; our IP address is **bleep**.**bleep**.**bleep**.**bleep** Filename 'fpga/soc_system_base.rbf'. Load address: 0x90000000 Loading: ################################################################# ################################################################# ###### 2 MiB/s done Bytes transferred = 1994752 (1e7000 hex) ..FPGA reconfiguration OK! ------------ 2: Full test ------------ Clock Domain A+B: Oscillator -> GTS -> FIFO -> DMA -> HPS The changes made to the linking HDL: module top(); ... // GTS to DMA assign fifo_clkin = gts_o_rx_clkout; assign fifo_reset = gts_i_rx_reset; assign raw2s_clk = gts_o_rx_clkout; assign raw2s_rst = gts_i_rx_reset; assign raw2s_data_i = gts_o_rx_parallel_data[31:0]; ... endmodule; Note that the reason for connecting the tx_out and rx_out can be seen in this comment The STA output: The system boot (HANG): Downloading FPGA bitstream... Using ethernet@10830000 device TFTP from server **bleep**.**bleep**.xx.x; our IP address is **bleep**.**bleep**.xx.x Filename 'fpga/soc_system_base.rbf'. Load address: 0x90000000 Loading: ################################################################# ################################################################# ####### 2 MiB/s done Bytes transferred = 2011136 (1eb000 hex) ........ FPGA reconfiguration failed!Command 'load' failed: Error -110 FPGA not ready. Bridge reset aborted! Conclusion: ========= The above has led me to believe that the issue with the design occurs at the CDC between the GTS and the HPS. I am not experienced with these sort of issues where the STA files seem to hold the key to debugging, and so would appreciate some help navigating how to approach this kind of problem! Many thanksGTS PMA/FEC Direct set-up
I am looking through the GTS docs, and have noticed that there is a setup sequence: In the generated /hwtest directory, this is all controlled via a set of .tcl scripts through Quartus system console. My questions are 1: Where are the hex addresses defined from in the /src folder? 2: It seems this example is a standalone - excuse my ignorance, but is there a standard way to go about integrating this example into a larger project? Thanks!
