Forum Discussion

New Contributor

13 days ago

Solved

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...

Configuration

Core Logic

Generic Io

LironAvrhmov
12 days ago

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.

LironAvrhmov

New Contributor

13 days ago

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