Forum Discussion
FakhrulA_altera
Regular Contributor
1 year agoHi,
Based on your description, the issue with accessing the second QSPI flash may be due to:
- FPGA Retaining Control: Ensure the FPGA design releases the second QSPI after configuration in PS mode.
- Software Initialization: Verify that SPL/U-Boot initializes the second QSPI correctly for data storage and that the device tree or address mapping reflects the changes.
- Pin and Clock Conflicts: Check for conflicts or misconfigurations in the QSPI pin assignments and clock settings.
You can debug by testing low-level access to the second QSPI and enabling logs in SPL/U-Boot or Linux. Let me know if further assistance is needed!
Best regards,
Fakhrul
- Rainwang1 year ago
Contributor
thanks for the reply.
please see my answer below.
- FPGA Retaining Control: Ensure the FPGA design releases the second QSPI after configuration in PS mode.(we can access the QSPI device successfully after FPGA AS configuration. for PS mode, the device doesn't work as a config device, so i don't think FPGA will still occupy this device. Or, can you tell me how to verify this?)
- Software Initialization: Verify that SPL/U-Boot initializes the second QSPI correctly for data storage and that the device tree or address mapping reflects the changes.(as i mentioned above, we can access the QSPI device successfully after FPGA AS configuration, we use the same SPL/U-boot when we try to access the device after PS configuration.)
- Pin and Clock Conflicts: Check for conflicts or misconfigurations in the QSPI pin assignments and clock settings.(since we can access the device after AS configuration, it can be verified that no pin or clock related error.)
thanks.