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.