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 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 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 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>How to set current strength for Agilex® 7 FPGA HPS dedicated IO?
Description Due to a problem in Quartus® Prime Edition Software version 25.3.1 and prior, you may see the following error when you set current strength for HPS dedicated IO in qsf file or in assignment editor. Current strength logic option is set to 2/4/6/8mA for pin intel_agilex_hps_0_<IO_name>~pad， but setting is not supported by I/O standard 1.2-V. This problem occurs because HPS dedicated IOs in Agilex™ 7 device are configured to I/O standard 1.2-V by default in Quartus, instead of I/O standard 1.8-V. Resolution To work around this problem, please set the HPS IO to I/O standard 1.8-V in qsf file or in assignment editor, and then set current strength for the pins to make it work.