Forum Discussion
New ContributorArria 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.
New ContributorHi,
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
tehjingy_AlteraRegular Contributor
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.
