Arria 10 QSPI controller hangs after U-Boot shell while SPL boots successfully - Arria 10 QSPI controller hangs after U-Boot shell while SPL boots successfully Hello, I am debugging a QSPI issue on two custom Arria 10 SoC boards. The boards are not the same FPGA package, but they are based on the same project. The only difference between the builds is the generated HPS handoff. On both boards: SPL boots successfully from QSPI flash. U-Boot FIT image is loaded successfully. U-Boot reaches the shell. During boot, U-Boot tries to read the environment from QSPI. On the working board: sf probe works. saveenv works. I can access the QSPI controller registers after U-Boot shell. Reading the QSPI module ID register works. On the failing board: SPL still boots correctly from the same QSPI flash flow. U-Boot also reaches the shell. The environment area is empty because saveenv cannot be executed successfully. Any command that accesses the flash, such as sf probe, hangs. Eventually the watchdog resets the board. After the U-Boot shell is up, I also cannot read the QSPI module ID register. The QSPI register base address from the address map is: i_qspi_qspiregs base: 0xFF809000 end: 0xFF8C07FF The module ID register is: offset: 0xFC expected value: 0x1001 So I am trying to read: 0xFF809000 + 0xFC = 0xFF8090FC On the working board this read succeeds. On the failing board this read hangs / causes the system to stop, and then the watchdog resets the board. I also checked the reset manager from U-Boot: md.l 0xFFD05014 4 The first value was: 0x00000000 So it does not look like the QSPI controller is held in reset. Additional observations from logic analyzer: JEDEC ID command 0x9F is sent correctly. The flash responds with a valid ID, for example: 0x20 0xBB 0x22 Later U-Boot sends a 4-byte read command: 0x13 0x00 0x20 0x00 0x00 The flash returns only 0xFF. I also tried compiling SPL and U-Boot separately for the failing board, instead of using the full project build, but the result was exactly the same. My questions are: What can cause the Cadence QSPI controller to work correctly during SPL and early U-Boot boot, but stop responding after reaching the U-Boot shell? Can a wrong HPS handoff, clock configuration, pinmux, bridge/firewall setting, or reset configuration cause this behavior only after U-Boot relocation/shell? Which Arria 10 registers should I check to verify that the QSPI controller clock, reset, and access permissions are still valid after U-Boot shell? Why would reading the QSPI controller module ID register hang on one board but work on another, while both can still boot SPL and U-Boot from QSPI? Any suggestions on what to check next would be appreciated. Thanks. Replies: Re: Arria 10 QSPI controller hangs after U-Boot shell while SPL boots successfully Hi LironAvrhmov Good to hear that! Thanks for sharing your findings. Replies: Re: Arria 10 QSPI controller hangs after U-Boot shell while SPL boots successfully Hi, Thank you for your suggestion. I added several debug prints throughout the U-Boot initialization process in order to determine exactly where the issue occurs. Here is what I found: The QSPI controller is initialized successfully. setup_flash_device() completes successfully. The SPI NOR device is detected correctly. The environment is read successfully from flash (spi_flash_read() returns 0). The only result is a Bad CRC, so U-Boot falls back to the default environment, but the flash controller continues to operate normally. I also added register reads after the environment loading and confirmed that the QSPI module is still accessible and responding correctly. The crash actually happened later during the network initialization (initr_net()), not during the QSPI or environment handling. After further investigation, I found that the Device Tree still had the Ethernet PHY node enabled (status = "okay"), while this specific board (Combiner Master) does not have a PHY populated. As a result, U-Boot attempted to initialize a non-existent PHY and eventually crashed. After changing the PHY node to: status = "disabled"; the issue was completely resolved and U-Boot now boots normally. Regarding the handoff files, we are already using different handoff (hps.xml) files for each board, generated separately for their respective hardware configurations. Thank you for your help. Replies: Re: Arria 10 QSPI controller hangs after U-Boot shell while SPL boots successfully Hi LironAvrhmov Is it possible if you could share your hps.xml in the handoff folder? Try comparing the non-working handoff file with the working. Check if the pinmux generate matches with the peripherals selected under the HPS IP. Replies: Re: Arria 10 QSPI controller hangs after U-Boot shell while SPL boots successfully Hi, Thank you for your response and for your suggestions. I would like to clarify that we are not sharing binaries between the two boards. Each board has its own HPS handoff generated from its own project, and we compile the SPL and U-Boot separately using the corresponding handoff file. I also rebuilt the failing board from scratch using its own handoff, but the behavior remained exactly the same. I also checked the registers you suggested: QSPI Clock Enable Register (0xFFD040D0) = 0x00000F7F qspiclken (bit 11) is set, so the QSPI clock is enabled. PER0MODRST Register (0xFFD05024) = 0xFF7FBEBE The QSPI reset bit (bit 6) is cleared, so the QSPI controller is not held in reset. Despite this, on the failing board any access to the QSPI controller register space after reaching the U-Boot shell hangs the CPU. For example, reading the Module ID register at address 0xFF8090FC causes the system to hang until the watchdog resets the board. On the working board, the same register returns the expected Module ID (0x1001). Since the QSPI clock is enabled and the controller is not in reset, do you have any suggestions on what else could cause the QSPI controller to stop responding after U-Boot reaches the shell? Thank you for your help. Best regards, Liron Replies: Re: Arria 10 QSPI controller hangs after U-Boot shell while SPL boots successfully Hi LironAvrhmov In practice the handoff file should be unique to each boards and be compile together with the uboot for each boards. If you are sharing the binaries, please avoid that and use the handoff file from each project to compile separate SPL and uboot for the boards. One thing to try is to check the QSPI Clock enable register and the QSPI Reset register below: https://www.intel.com/content/www/us/en/programmable/hps/arria-10/hps.html#topic/sfo1429890551172.html https://www.intel.com/content/www/us/en/programmable/hps/arria-10/hps.html#topic/sfo1429890575955.html On the failing board try reading the register value and see if the QSPI Clock is enabled and not in reset.