Booting from QSPI

[Derek Mulcahy]

Hi,

I have been trying to boot from QSPI and I have been failing!

I have installed a BOOT.bin on the /dev/mtd0 partition of the QSPI using flashcp and it verifies and reads back correctly but when it boots I get no output on the console. I am sure that I am holding the select button down correctly and waiting the required time for the leds to turn off. It is problematic that I have to unplug the snickerdoodle to get the select button to be handled at power-on as this disconnects me from the USB console and makes viewing the output tricky.

I have tried various BOOT.bin files and they work when running from the SD card but not from the QSPI. I found information about enabling FSBL debug and that works fine for the SD boot but produces nothing for the QSPI boot.

I have run out of ideas!

Thanks,

Derek

[Derek Mulcahy]

I had an idea...

I have attached a logic analyzer to the QSPI chip and I am going to monitor the startup sequence. I see that MIO4 and MIO5, the zynq pins that control zynq boot mode, share the DQ2 and DQ3 pins on the QSPI flash. These are busy pins as the platform controller has a second connection over the QSPI_SPI net group.

I noticed that u-boot reads 128K of environment variables from 0x0E0000 in the flash during an sdcard boot. This doesn't do u-boot much good as the "data" is in no way valid but it does confirm that my QSPI flash is connected to the analyzer and still working.

[Derek Mulcahy]

Hmm, monitoring the QSPI is not proving fruitful.

I place the Snickerdoodle in QSPI boot mode by holding down the select button for 2 seconds at power-on until the leds go out. I then start the logic analyzer and trigger on CS going low. I hold down the reset button for a couple of seconds and I get a (very noisy!) transition of CS from high to low indicating that the QSPI has been selected. CS stays low for about a second then it goes high. No clock appears on SCK and nothing is transferred on the DQ lines.

[Derek Mulcahy]

Here is a snapshot of a normal sdcard boot, the blip from uboot on DQ0 to probe the QSPI and then fast read of 128K of environment variables and then finally a probe when the linux kernel has started. 

[Derek Mulcahy]

Here is a snapshot of a QSPI boot captured from before power-on, during button select and for a few seconds after. CS goes high after the select button is released then nothing happens!

[Derek Mulcahy]

OK, the end of this stream of consciousness, and the solution is  hold down the RESET key at power-on for QSPI mode. The previous screenshots show the MIO4 and MIO5 selecting JTAG. Here is a snapshot of the Snickerdoodle booting from QSPI. Booting from QSPI is working as expected. It uses all of the pins DQ0-DQ3 for data, QSPI mode.

Thanks for listening.

[Bush]

I'm glad you were able to determine the correct button config to boot from the QSPI. We've had a lot of questions on how to store the QSPI boot configuration to avoid needing to hold the RESET button every time you boot. This will be addressed in firmware but as you've demonstrated, a boot environment can be written to the QSPI to determine the boot source. With a firmware change, the board can be minimally booted from the QSPI before optionally loading components from a secondary source such as the SD card. This would allow a small system to be loaded by default when the SD card is not present and to have the system persistently configured to boot from either source based on user preference.

There is another configuration option that we are working on that will allow the QSPI to be read/written from the USB interface via a mass storage device enumeration. This would allow the QSPI to look like a 16MiB mass storage device that can be written to for the purpose of updating the boot images and updating the boot environment. Let me know if you have any ideas on usability and if any of this is helpful or not. Thanks.