Why does Arria® 10 HPS IP generation fail with missing mgc_common_axi.sv in Quartus® Prime Pro 24.1/24.2?
Description Due to a problem in the Quartus® Prime Pro Edition Software versions 24.1 and 24.2, Arria® 10 HPS IP generation may fail with an error similar to: Error: add_fileset_file: no such file .../ip/altera/mentor_vip_ae/axi3/bfm/mgc_common_axi.sv This occurs because AXI3 Mentor Graphics BFM collateral was removed starting in Quartus Prime Pro 24.1, while the Arria 10 HPS generation flow still referenced the removed AXI3 BFM file. Associated Quartus Suite bug: QS-569165. Resolution To resolve this issue, upgrade to Quartus Prime Pro Edition Software version 24.3, regenerate the Platform Designer system/IP output files, and rerun compilation.Why the Error Injection using Linux* debugfs interface does not work for SDMMC ECC Port B?
Description Due to a problem in the EDAC (Error Detection and Correction) driver, the Error Injection using Linux* debugfs interface on SDMMC ECC Port B is not functioning. The error injection command below does not write to INIT test register as intended. echo C > /sys/kernel/debug/edac/sdmmca-ecc/altr_trigger As comparison, when writing directly to the INITTEST register, single bit error interrupt is shown to be working. root@agilex7dksiagf014eb:~# devmem2 0xFF8C8C26 h 0x1 ----- /dev/mem opened.[ 1785.685802] EDAC DEVICE6: CE: Altera ECC Manager instance: sdmmcb-ecc0 block: sdmmcb-ecc0 count: 1 'sdmmcb-ecc' This issue is impacting Agilex® 7 SoC FPGA devices and Quartus® Prime software of version 25.3.1 and older. Resolution To workaround this issue, apply the patch by following the instructions below: git clone the repo https://github.com/altera-fpga/linux-socfpga/commits/socfpga-6.18.2-lts/ run: git format-patch-1 Make sure the commit is included in the patch: https://github.com/altera-fpga/linux-socfpga/commit/be94a41dfaf7e124a5547ac8948b36f097a73c90 Use “git am” to apply the patch onto your source code. Additional Information This issue is fixed in Quartus Prime software version 26.1 onwards.Why is the HPS booting process on Agilex® 5 and Agilex® 3 SoC FPGA devices stuck at the U-boot stage?
Description Due to a problem in the Agilex® 5 and Agilex® 3 SoC FPGA devices' HPS RAM Repair mechanism sequencing in Quartus® Prime Pro Edition Software version 25.3.1 and earlier, the HPS may fail to boot up normally after a RAM Repair happens. The failure signature is shown in the image below: Resolution To solve the issue, please consider the following options: Upgrade to Quartus® Prime Pro Edition Software 26.1 and newer. Which the fix is included. For Quartus version 25.3.1, apply the Quartus firmware patch attached in this KDB. For older Quartus version, contact Altera to check for the availability of patch. Additional Information Add these notes for the patches for Quartus® Prime Pro Edition Software version 25.3.1: Patches must be applied to the Quartus® Prime Pro Edition Software and the Quartus® Prime Pro Edition Software Programmer and Tools. Recompilation is not required. All programming files should be recreated. Re-run the programming file generation or conversion using the Quartus® Prime Software programming file generator.Why is the FPGA To HPS bridge not functional in a non-HPS EMIF hardware design in Agilex® 5 FPGA device in 25.3.1 release and earlier?
Description Due to an incorrect configuration in the mpfe_config register in the System Manager, performed by the SDM FW, the FPGA-to-HPS transactions will fail to complete on the Agilex® 5 FPGA device in a hardware design that does not instantiate the HPS EMIF IP created with Quartus® Prime 25.3.1 and before. The problem resides in the incorrect value that the SDM FW assigns to the mpfe_config[f2soc_intfcsel] bit when the HPS EMIF is not instantiated. Under this scenario, it is expected that the f2soc_intfcsel field has a value of ‘1', but this is set to '0’ instead. Resolution To workaround this problem, you can set the mpfe_config[f2soc_intfcsel] bit to '1' in the FSBL. The following snippet shows an example of how to do it in U-Boot SPL: #define MPFE_CONFIG_F2SOC_INTFCSEL_BIT 0 void board_init_f(ulong dummy) { : setbits_le32(socfpga_get_sysmgr_addr() + SYSMGR_SOC64_MPFE_CONFIG, BIT(MPFE_CONFIG_F2SOC_INTFCSEL_BIT)); do_bridge_reset(1, RSTMGR_BRGMODRST_FPGA2SOC_MASK ); : } This needs to be done before the FPGA-to-HPS (F2H) bridge is released from reset. This problem will be fixed in a future release. Note: If your non-HPS EMIF design instantiates the Altera ACE5-Lite Cache Coherency Translator (CCT) and, after applying the above workaround, you observe that read transactions in the FPGA-to-HPS (F2H) bridge succeed, but after a write transaction, the system hangs, you may require an additional fix in the ACCT IP that will be released together with the mpfe_config[f2soc_intfcsel] configuration fix. Please refer to Why does the Agilex® 5 FPGA Hard Processor System hang during ACCT IP operations when translating AXI4 to ACE5‑LITE?Why does the Agilex® 5 FPGA Hard Processor System hang during ACCT IP operations when translating AXI4 to ACE5‑LITE?
Description Due to an issue in Quartus® Prime Pro Edition Software version 25.1, the readdatareordering_depth property of the ACCT IP AXI4 interface is not configured correctly. As a result, the interconnect is not set up to handle out‑of‑order responses. In this scenario, the Agilex® 5 FPGA Hard Processor System (HPS) may issue out‑of‑order responses during ACCT IP operations when translating AXI4 transactions to ACE5‑LITE. Because the interconnect is not configured to accommodate this behavior, the system may hang. Resolution This issue is scheduled to be fixed in Quartus® Prime Pro Edition Software version 26.1.Why is the FPGA fabric unable to access the QSPI device through the SDM mailbox when ATF is used as the HPS bootloader in release 26.1 and earlier?
Description Due to the current implementation of Arm Trusted Firmware (ATF), BL31 retains ownership of the QSPI device after HPS boot in flows where ATF is used as the HPS bootloader (for example, ATF-to-Linux direct boot flow or bare‑metal boot flow). As a result, the FPGA fabric is unable to access the QSPI device through the SDM mailbox. This issue is observed in ATF releases 26.1 and earlier and affects Agilex® 7 FPGA, Agilex® 5 FPGA, and Agilex® 3 FPGA devices. Resolution There is no workaround for this issue. For Agilex® 5 FPGA and Agilex® 3 FPGA devices, this problem will be addressed in a future release by introducing an ATF build‑time switch that allows control over whether QSPI ownership is retained by or released from the HPS.Why does Agilex® 5 FPGA fail to boot Linux* from NAND when using the ATF-to-Linux direct boot flow in the 26.1 release?
Description Due to an issue with the SDRAM memory configuration in the Linux* device tree, the Agilex® 5 FPGA HPS fails to boot Linux from NAND when using the ATF-to-Linux direct boot flow in the 26.1 release (Linux branch socfpga-6.18.2-lts). This issue does not occur in the U-Boot–to-Linux boot flow, as U-Boot patches the Linux device tree with the correct memory configuration. In the ATF-to-Linux direct boot flow, ATF does not perform this patching; therefore, the memory configuration must be correctly defined in the device tree. Resolution To work around this issue, the Linux device tree used for booting from NAND in the ATF-to-Linux direct boot flow must be updated with the correct memory configuration. For the Premium Development Kit Production (065B and 065A), apply the following fix to arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_nand_atfboot.dts: memory { device_type = "memory"; reg = <0 0x80000000 0 0x80000000>; }; Refer to the following build instructions for the workaround implementation: PDK 065B PDK 065A This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition Software.Why does Agilex® 5 FPGA fail to boot Linux* from eMMC when using the ATF-to-Linux direct boot flow in the 26.1 release?
Description Due to an issue with the SDRAM memory configuration in the Linux device tree, the Agilex® 5 FPGA HPS fails to boot Linux* from eMMC when using the ATF-to-Linux direct boot flow in the 26.1 release (Linux branch socfpga-6.18.2-lts). This issue is not observed in the U-Boot–to-Linux boot flow, as U-Boot patches the Linux device tree with the correct memory configuration. In the ATF-to-Linux direct boot flow, ATF does not perform this patching; therefore, the memory configuration must be correctly defined in the device tree. Resolution To work around this issue, the Linux device tree used for booting from eMMC in the ATF-to-Linux direct boot flow must be updated with the correct memory configuration. For the Premium Development Kit (ES and production), this requires updating the file arch/arm64/boot/dts/intel/socfpga_agilex5_socdk_emmc_atfboot.dts with the following fix: memory { device_type = "memory"; reg = <0 0x80000000 0 0x80000000>; }; Refer to the following build instructions for the workaround implementation: PDK 065B ES PDK 065B PDK 065A This problem is scheduled to be fixed in a future release of the Quartus® Prime Pro Edition Software.Why does the typical web server page is not displayed when using binaries created from the HPS Baseline and Legacy System Example Design in Agilex® 5/Agilex® 3 FPGA device in release 25.3.1 and 26.1?
Description Due to a problem in the HPS Baseline and Legacy System Example Design for Agilex® 5 FPGA and Agilex® 3 FPGA devices, the web server application just shows the “It works!” message instead of the typical view, in which it briefly describes the development kit, shows the state of some LEDs, and allows them to be controlled. This problem is observed in Quartus® Prime Pro Edition software version 25.3.1 and 26.1 releases. Resolution There is no workaround for this problem. This problem will be fixed in a future release.Why does FPGA core configuration fail in HPS early IO release mode of Arria® 10 SoC device?
Description In Arria® 10 SoC device HPS early IO release mode, you may see FPGA core configuration failure when you use the following command to generate core rbf. quartus_cpf --convert --hps -o bitstream_compression=off <sof_file> <rbf_file> This problem occurs because uncompressed core rbf file may be too large to cause configuration failure. Resolution To work around this problem, please use the following command to generate rbf files. quartus_cpf --convert --hps -o bitstream_compression=on <sof_file> <rbf_file>
