QSPI Flash Programming

[Altera_Forum]

Hello All, 

 I am trying to follow the GSRD for booting from flash here: https://rocketboards.org/foswiki/documentation/a10gsrd161qspiboot  I am using the precompiled binaries as there were many issues trying to build them myself. I have the full qspi image I want to put on the flash. I am trying to use the quartus_hps programmer to load the image but it craps out since it can't read the flash silicon ID. Below is the event log.  Info: Command: quartus_hps -c 1 -o s Current hardware is: USB-BlasterII [3-3]  Successfully change hardware frequency to 16Mhz Found HPS at device 2  Double check JTAG chain Warning: Overwrite HIR => 11, HDR => 2 HPS Device IDCODE: 0x4BA00477 AHB Port is located at port 0 APB Port is located at port 1  Double check device identification ... Warning: Device is Arria 10 SoC Setup non-secure transaction ... Boot Info: 1.8V QSPI Flash Clock Select: 0 Start HPS Quad SPI flash programming ... Initialize QSPI peripheral and flash controller ...  Assuming QSPI controller system clock is 50Mhz  QSPI controller baudrate setting: 32 (15) Read Silicon ID of Quad SPI flash ...  Quad SPI Flash silicon ID is 0xFFFFFFFF Error: Not able to map flash ID from flash database Error: Quartus Prime Programmer was unsuccessful. 0 errors, 0 warnings  Here's an instance where someone programs the flash successfully: https://www.alteraforum.com/forum/showthread.php?t=54519 . I'm not sure what I'm doing wrong/differently.  I've set the BSEL pins to 1.8V QSPI, and all the jumpers and switches are in the default position. I have the Micron QSPI Daughtercard that comes with the A10 SoCDevKit loaded in the file flash memory slot.   Does anyone have any ideas on how I can fix this issue?  Thanks, Bogg

[Altera_Forum]

I had your same problem when I tried to read from qspi memory but this memory was not soldered on the development board

[Altera_Forum]

Hi,  

 I had the same deadlock. I programmed a wrong QSPI image then the U-Boot gets stuck and HPS flash programmer could not access it anymore.   What I did is: Remove the QSPI card and power on the system. While the system is running plug on the QSPI card (ensure not to make any short circuits!!). This will ensure that u-boot is not running and the card has power. Then erase the card with quartus_hps.  Regards MillerTheRipper   EDIT: I found a much better smooth way to do prevent the HPS from booting. Try:  quartus_hps --boot=18 --cable=1 --operation=pv uboot_w_dtb-mkpimage.bin

[Altera_Forum]

One possibility is your QSPI flash chip has the information in its non-volatile configuration register to make it operate in the dual or the quad mode at power-up. 

This would make the chip only respond to 2 lane or 4 lane commands instead of the default 1 lane command, therefore it would explain the ID of 0xFFFFFFFF. If that's the case, it means Quartus cannot deal with it. You'll have to use some app to set these bit back to non dual - non-quad mode.  Regards

[Altera_Forum]

Thanks for the replies everyone. The problem was actually really simple, the daughtercard needed to be in the boot flash slot instead of the file flash. No issues afterwards.