ContributionsMost RecentMost LikesSolutionsRe: ERROR: Config PwrMgr handoff failed. error -1 Hello, I just tried to build a simple Zephyr Hello World application using the Toolchain setup, GHRD, ATF instructions from https://altera-fpga.github.io/rel-25.3/embedded-designs/agilex-5/e-series/premium/boot-examples/ug-linux-boot-agx5e-premium/#boot-from-qspi_1 together with the Zephyr instructions in the https://altera-fpga.github.io/rel-24.3/embedded-designs/agilex-5/e-series/premium/gsrd_zephyr/ug-zgsrd-agx5e-premium/ and this is working correctly as you can see below: NOTICE: DDR: Reset type is 'Power-On' NOTICE: IOSSM: Calibration success status check... NOTICE: IOSSM: All EMIF instances within the IO96 have calibrated successfully! NOTICE: DDR: Calibration success NOTICE: DDR: ECC is enabled NOTICE: IOSSM: Memory initialized successfully on IO96B NOTICE: ###DDR:init success### NOTICE: DFI interface selected successfully to SDEMMC NOTICE: SOCFPGA: QSPI boot NOTICE: BL2: v2.13.0(release):QPDS25.3_REL_GSRD_PR NOTICE: BL2: Built : 15:51:35, Oct 22 2025 NOTICE: BL2: Booting BL31 NOTICE: SOCFPGA: Boot Core = 0 NOTICE: SOCFPGA: CPU ID = 0 NOTICE: SOCFPGA: Setting CLUSTERECTRL_EL1 NOTICE: BL31: v2.13.0(release):QPDS25.3_REL_GSRD_PR NOTICE: BL31: Built : 15:51:35, Oct 22 2025 *** Booting Zephyr OS build b755e7bab5f8 *** Secondary CPU core 1 (MPID:0x100) is up Secondary CPU core 2 (MPID:0x200) is up Secondary CPU core 3 (MPID:0x300) is up Hello World! intel_socfpga_agilex5_socdk Thanks Rolando Re: ERROR: Config PwrMgr handoff failed. error -1 Hello The error that you are seeing is observed in the First Stage Boot Loader(FSBL), which corresponds to ATF in this flow. This is related to the SDRAM bring-up. From the hardware configuration, some settings (stored in the bitrstream in QSPI) are read by the FSBL and this configures some HPS/EMIF registers to bring some peripherals or the SDRAM. In this case, seems that the problem is related to any incorrect configuration in the hardware design in the pss_sram_power_off() function (https://github.com/altera-fpga/arm-trusted-firmware/blob/socfpga_v2.13.0/plat/intel/soc/agilex5/soc/agilex5_power_manager.c#L42), which is reporting a failure. Unfortunately, we have not updated the Zephyr GSRD after 24.3, so the instructions in https://altera-fpga.github.io/rel-24.3/embedded-designs/agilex-5/e-series/premium/gsrd_zephyr/ug-zgsrd-agx5e-premium/ have not been tested with Quartus 25.3. Now, the failure that you see is observed at ATF stage before Zephyr is launched, and we support some flows that also use ATF as bootloader. The flow described in Direct ATF to Linux Boot (https://altera-fpga.github.io/rel-25.3/embedded-designs/agilex-5/e-series/premium/boot-examples/ug-linux-boot-agx5e-premium/#boot-from-qspi_1) can be used as a reference to build your hardware desgin and your ATF for 25.3 release. You can build these and then use it with your original Zephyr build instructions and see if your error is not longer seen. You can also compare the HPS configuration in Quartus between your current hardware build and the one that you create using the Direct ATF to Linux Boot and identify any difference that could be creating the error that you are seeing. Please let me know if this information helps you to move forward. Thanks Rolando 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 Re: SD Card Boot Hi Brian So you are saying that if you use Altera U-Boot from 2025.01 and 2025.04 branches in Cyclone V, there is no output from the serial console similarly to what is being reported in the Agilex 5 Modular dev kit when using latest branch in Das U-Boot repo? If this is the case, I think that for Cyclone V this shouldn't be a surprise, since the latest code validated for Cyclone V uses the QPDS24.1STD_REL_GSRD_PR tag in Altera Repos as it can be seen in https://altera-fpga.github.io/rel-25.1/embedded-designs/cyclone-v/sx/soc/gsrd/ug-gsrd-cve-soc/#source-code Cyclone V is aligned with Quartus STD releases, which occur only once a year, so it is not expected to work with U-Boot branches 2025.01 or 2025.04. In the case of Modular Dev Kit, this should work with Altera U-Boot branches from 2025.01 and 2025.04, but since not all the updates in the Altera repos have been pushed to the Das U-Boot repo, it possible to observe this issue, so that's why we recommend to use the Altera repo content. Thanks Rolando Re: Questions regarding the HPS GSRD User Guide for the Agilex™ 5 Hello In U-Boot and Linux there are some files that allow you to indicate if you need to build a driver or not. These are the configs. For example for agilex 5 we have these: U-Boot: https://github.com/altera-fpga/u-boot-socfpga/blob/socfpga_v2025.04/configs/socfpga_agilex5_defconfig Linux: https://github.com/altera-fpga/linux-socfpga/blob/socfpga-6.12.19-lts/arch/arm64/configs/defconfig If a CONFIG is set to 'y' it means that the corresponding driver will be built and integrated into the Linux kernel. If it's set to 'm', the driver will be build but be created as an independent module that you need to load using the insmod command. If it's set to 'n', then the driver is not built and won't be available to the Linux kernel. In the GSRD page, Yocto is the one that updates the device tree along to CONFIGS and other things. Yocto is very powerful but difficult to use. What I understand about the Yocto flow is that it gets the content of the Linux/ATF/U-Boot repo with a specific branch indicated in a recipe, and then executes recipes that update device trees and CONFIGS and also apply patches (to fix an issue or support any specific functionality). You need to create or modify these recipes to do what you want. Once that the repo is updated this is built and generates the Linux/ATF/U-Boot binaries. Then also Yocto has recipes to build Linux file system, libraries and applications that are copied into the file system. When it gets all components already built, Yocto also integrates these in you final binaries that could be a SD card image, a .rpd or .jic image to boot from QSPI, etc. But to update the recipes is it needed to have certain level of knowledge about Yocto. The good thing is that this is popular and there are many resources in the web. Again, if you are starting with our devices and you don't have much experience with Linux, I suggest you to start with https://altera-fpga.github.io/rel-25.1/embedded-designs/agilex-5/e-series/premium/boot-examples/ug-linux-boot-agx5e-premium/. Also we have a very nice simulator for our Agilex 5 device that could help you to ramp up on this, in case you don't have a dev kit: https://www.altera.com/products/development-tools/simics-virtual-platform Re: Questions regarding the HPS GSRD User Guide for the Agilex™ 5 Hello PJW, I will try to respond your questions. 1. The GSRD (Golden System Reference Design) includes the hardware component (referred as hardware design or GHRD - Golden Hardware reference design) and the HPS SW components. If you want to use the HPS in your project, then you need to instantiate this one in Platform design and if this is the case you need to indicate what controllers in the HPS you need to use (for example the UART, the SD Controller, the ethernet controller, etc). Besides of the HPS, you also may want to create any design in the FPGA fabric (like a timer or GPIO controller, an On-Chip RAM, NIOS V, etc). If you want that HPS makes use of the controllers in the HPS that you enabled in the hardware design or if you want that the HPS interacts with the hardware in the FPGA fabric, then you need to enable in the HPS software (could be U-Boot or Linux) the corresponding driver that allows the HPS to interact with that controller or piece of hardware in the fabric. To enable these drivers, you need to build the driver (this is done through CONFIGS) and also need to enable and configure the driver(through decive tree). In the same way if the HPS controller needs to interact with an external device like a SD card memory, serial RTC, ethernet phy device, you also need to enable the corresponding driver (also through device tree and CONFIGS). The GSRD that we provide already includes the CONFIGS and device tree settings that allow the HPS to interact with the reference design. If you enable something more in the hardware design, you will likely need to enable the corresponding driver in the HPS software. The GSRD in this page, relies on Yocto, which is a framework that allow to build the HPS software. This framework relies on some device trees that are already public in the external repositories (for example for Linux at https://github.com/altera-fpga/linux-socfpga/tree/socfpga-6.12.19-lts/arch/arm64/boot/dts/intel/socfpga_agilex5*) and also from additional layers included in other repositories (https://github.com/altera-fpga/meta-intel-fpga-refdes/tree/master/recipes-bsp/device-tree/files). The framework integrates all the recipes/components and build the binaries needed. So to respond to your first question, if you add more components in your hardware design and if you need the HPS to interact with them, then you do need to update the device tree. In the user guide we show customers how they integrate a custom hardware design into the Yocto recipes that includes this is the binaries (but don't directly show how you can to update the HPS software if any new component is added to the hardware design, the assumption is that the customer is familiar with the Yocto framework). Now, why do we need to include the hardware design in the HPS binaries created by Yocto? Well, there is an boot mode name HPS boot first, that is the one that the GSRD exercise, in which the hardware design is divided in 2 pieces, called phase1 and phase 2. The phase 1 includes the HPS and its peripherals, while the phase 2 includes the rest of the fabric and the idea is that the HPS first boots and then from U-Boot or Linux the HPS configures the phase 2 section (referred as core.rbf) . So in this mode, the phase 1 (hps.rbf) is the QSPI device while the phase2 is included in the SD-Card (in the case of the GSRD this is included as part of the kernel.itb file). In order to get familiar with the boot flow, I sugest you to start with this page that shows you how to build most of the components (ATF, U-Boot, Linux individually): https://altera-fpga.github.io/rel-25.1/embedded-designs/agilex-5/e-series/premium/boot-examples/ug-linux-boot-agx5e-premium/ 2. The legacy_baseline_hps_debug.sof is a binary that includes the hardware design (phase 1) and a dummy HPS software as FSBL (first stage boot loader). This dummy HPS doesn't do anything, but just enter into an infinity loop. This acts as our FSBL. We used this with the debugger. First load this image and the HPS enters into this loop, and then we connect the debugger to load the real HPS software. You can refer to https://altera-fpga.github.io/rel-25.1/demos/agilex-5/e-series/premium/riscfree-debug-u-boot/ug-riscfree-debug-uboot-agx5e-premium/ in which it shows how this is used. 3. The hps_wipe.s is the actual dummy HPS software that does some initial configuration and then enters into an infinite loop. I don't think that there is any need to modify this file. In our GSRD or the boot example that I showed above we use the u-boot-spl-dtb.hex instead as our FSBL, so this one is in charge of setup the DDR memory and some other hardware components in the HPS and then load second stage bootloader(SSBL which is u-boot.itb). Re: SD Card Boot Hi Malcom I confirmed that the links in the Agilex 5 GSRD pages pointing to the binaries is incorrect, the correct paths are the following: Agilex 5 Modular Dev Kit: SD Card: https://releases.rocketboards.org/2025.08/gsrd/agilex5_mk_a5e065bb32aes1_gsrd/ QSPI: https://releases.rocketboards.org/2025.08/qspi/agilex5_mk_a5e065bb32aes1_qspi/ Agilex 5 Premium Dev Kit: SD Card: https://releases.rocketboards.org/2025.08/gsrd/agilex5_dk_a5e065bb32aes1_gsrd/ QSPI: https://releases.rocketboards.org/2025.08/qspi/agilex5_dk_a5e065bb32aes1_qspi/ I will fix this in our GSRD pages. Related to the need of wipe the SDCard, this is only needed when building the binaries using the GSRD flow. This happens because the U-Boot SPL tries to find the u-boot.itb from the different boot devices starting with the SDCard. If you look at the HPS GHRD Linux Boot Examples page (https://altera-fpga.github.io/rel-25.1.1/embedded-designs/agilex-5/e-series/modular/boot-examples/ug-linux-boot-agx5e-modular/#boot-from-sd-card), this line changes the list of devices in which it will try to boot from, keeping only mmc, which corresponds to the SD Card. sed -i 's/u-boot,spl-boot-order.*/u-boot\,spl-boot-order = \&mmc;/g' arch/arm/dts/socfpga_agilex5_socdk-u-boot.dtsi Related to the errors that you are seeing when building the binaries, it's possible that a package could be missing in the WSL2 environment when building the RootFS, but what is weird is that in this page https://altera-fpga.github.io/rel-25.1.1/embedded-designs/agilex-5/e-series/modular/boot-examples/ug-linux-boot-agx5e-modular, you just use the rootfs in the Linux boot stage and shouldn't affect that you see something on the serial console. The U-Boot SPL is the first binary that HPS executes and this is included as part of the bitstream provided to the system. This bitstream includes the hardware design(.sof) and the SPL(.hex): In the case of booting from SD Card: In the case of Booting from QSPI: If the hardware design(.sof) and the SPL(.hex) were created correctly, you should be able to see an output from the serial console. here you also need to double-check that in your devkit, the msel is set to QSPI so it can read the bitstream from the QSPI. If you have problems generating the RootFS, you can get this directly from the Pre-Built binaries included in the correct paths provided above. Thanks Rolando Re: SD Card Boot Hello Brian Our documentation and HPS releases are based on the Altera repositories (https://github.com/altera-fpga). Please look at our Release Notes page that shows what versions of each component we released: https://github.com/altera-fpga/gsrd-socfpga/releases/tag/QPDS25.1.1_REL_GSRD_PR In the case of U-Boot, the latest release is based on 2025.04. The next release will be based in 2025.07. We are working to push all the updates that we have in our repositories to the repositories that the community supports (i.e. https://github.com/u-boot/u-boot) but it's possible that the latest code in the Altera repos are not yet propagated to the community repos, so this is the reason why we direct our customers to use the Altera repos. If you have any further questions about Cyclone V, it would be better to open a new case, so we can focus in this case to solve the issues related to Agilex 5. Thanks Rolando Re: SD Card Boot Hi Brian I don't think we had drop the support of these devices, but the embedded software (including U-Boot) evolves from release to release. Sometimes, there are dependencies on using the correct component versions to boot successfully ( SDM FW included on Quartus, ATF. U-Boot SPL, U-Boot, Linux). So in our releases pages (https://github.com/altera-fpga/gsrd-socfpga/releases) we include the combinations of components that we validate. For GSRD page or any other page with instructions to build binaries, we have a version of the page for each one of the releases with the component version combinations that we know they work. For this pages, we switched from Rocketboards to https://altera-fpga.github.io/ some time ago. For Agilex 5, I think most of the versions are already in the new site. Thanks Rolando Re: SD Card Boot Hello Brian, I am in charge of updating the build instructions related to Agilex 5 and we want to improve these as much as we can. Could you please provide more details of the configuration that you needed to do to boot successfully? Were you using the instructions provided in https://altera-fpga.github.io/rel-25.1.1/embedded-designs/agilex-5/e-series/premium/boot-examples/ug-linux-boot-agx5e-premium/ to build your SPL for the modular dev-kit? You mentioned that you needed to change socfpga_cyclone5_defconfig, may I know why you started with this defconfing instead of the one specific for Agilex 5 ( socfpga_agilex5_defconfig )? Thanks in advance Rolando