Booting Snickerdoodle in different boot modes

[Akshay Vaidya]

Hi all,

         Has anyone tried to boot Snickerdoodle in JTAG or QSPI Mode? All that user manual suggests to do is use the krtkl app on pg 12 of user manual. Can anyone help me find a way to change the bootmode? 

[Akshay Vaidya]

Russell from krtkl Answered via email:

The Zynq boot pins can be configured at boot time by pressing and holding the select/reset buttons on the snickerdoodle while powering on the board. If no buttons are pressed, the board immediately configures the pins to boot from the SD card and starts the boot process. If the select button is pressed and held while the board is powered on, the board will boot from QSPI flash. (must be held for 2 seconds during power-up, LEDs will turn on during bring-up and turn off when it is safe to release the button). If the reset button is pressed and held, the board will be configured for JTAG boot (recommended for writing to QSPI flash using flash utility. Holding and pressing both buttons during power on will put the STM32 into device firmware upgrade mode where firmware can be loaded over the USB port. 

[pat...@gmail.com]

The snickerdoodle being on its way, I took a closer look at the doc. Basically everything looks clear so far but I too have a concern regarding boot mode.

Is there a way to always boot directly from QSPI ?

Do Krtkl provide the source code for the platform controller ?

Many thanks in advance.

[pat...@gmail.com]

Not using linux here and I want to always boot by default from qspi flash, here are the solutions I can think of:

1- shortcircuit the select button
   pro: easy
   con: possible loss of warranty
        lousy way to solve the issue
        having to turn the power off/on for each system reset not acceptable

2- desolder r63 and connect it to ground
   pro: easy
   con: loss of warranty

3- get the platform controller source code from krtkl and make the change myself
   pro: easy if everything builds up (i.e. no missing files)
   con: dunno if krtkl want to make it open source

4- krtkl make a 2nd .dfu with qspi boot as default
   pro: easy
   con: 2 versions of .dfu to distribute

5- krtkl make the platform controller software to save boot default in non-volatile mem and setting can be done from PS
   pro: the way to go in the long run
   con: requires a bit more work

6- write my own platform controller software. I don't need wireless, at least for now, and from the schematics it seems straightforward to figure out how to drive the stm gpio's to get the board running
   pro: self-reliant
   con: am here to work on zynq not stm


AFAIK I like (4) best followed by (3) because it doesn't take much effort thus can be done right away

Anyway this was an opportunity to have a glimpse under the hood. The board is still on its way but looks really nice indeed!

[Bush]

The current configuration of booting from the SD card by default and allowing the QSPI and JTAG boot options through button control was designed to be the most useful during development. Obviously, once you've designed your system and you want it to boot primarily (or only) from a source other than the SD card, you should have to hack the hardware to get the behavior you want. I think the most reasonable solution is to provide firmware updates for systems like this. A couple of important things I would get yelled at for not pointing out:

1. Yes, if you modify the hardware, you risk destroying your board and do so at your own risk. In reality, however, I would not discourage anyone from modifying hardware to fit their needs.
2. Modifying the firmware on the board can cause major headaches and issues as the firmware is responsible for bringing up the board interfaces necessary for basic functionality.

This is what I see as the most straight-forward way to loading and running a QSPI based system:

1. Load the system onto an SD card (factory firmware loaded at this point)
2. Boot from SD card
3. Write the QSPI images from the SD card onto the QSPI from either U-Boot or Linux
4. Shutdown
5. Boot in DFU mode
6. Load QSPI boot firmware (I will produce this)
7. Reboot (should boot into QSPI)

This procedure would not require any external tools, however, once the QSPI is loaded, I'm not sure what the best mechanism is for updating the image (unless the image contains U-Boot or Linux). If you have any ideas about this proposal please let me know. I want to make sure the use-cases are well accounted for and as easy to use as possible.

[pat...@gmail.com]

Thanks so lot for your detailed reply Russ, much appreciated.

"...6. Load QSPI boot firmware (I will produce this)..."

Yes this is what I was asking for "4- krtkl make a 2nd .dfu with qspi boot as default"

I too think this is the quickest and easiest way to address this limitation.

"This procedure would not require any external tools, however, once the QSPI is loaded, I'm not sure what the best mechanism is for updating the image (unless the image contains U-Boot or Linux). If you have any ideas about this proposal please let me know. I want to make sure the use-cases are well accounted for and as easy to use as possible."

I assume we can write boot.bin to the Snickerdoodle QSPI with Xilinx SDK, right ?

Sorry to bother you with that guys, I know you must be incredibly busy.

[Bush]

Yes, you can write to the QSPI from Xilinx SDK using JTAG but the best solution (in my opinion) should not require a JTAG adapter to update the system. We can still use the functionality of the buttons to switch between a primary and secondary boot source. In this case, the QSPI would be used and the primary source and the SD card can be used as a secondary boot source for the purpose of updating the QSPI image. A simple SD card image with U-Boot and a QSPI load script can be used to load QSPI flash images. Let me know what you think.

[pat...@gmail.com]

Sounds pretty good. Although I think a good JTAG adapter is a must to get the most out of Zynq, it's certainly great to provide the user with multiple choices.

From this side of the pond, I flash the QSPI whenever I change the bitstream which can be up to 10 times a day and boot from QSPI up to say 100 times a day. I use one JTAG adapter to write QSPI with SDK and another JTAG adapter to test and debug with a UK-made toolchain.

I'll be a happy camper if you can produce the firmware to boot from QSPI as default.

Thanks in advance.

[pat...@gmail.com]

A quick update.

Not knowing when the mod will be available, I decided to take the plunge.

Desoldering R63 and connecting it to ground. While the Digilent HS2 JTAG adapter worked fine, there was an ID conflict when using a RedProbe+ JTAG adapter and I removed RN9. I also removed RN12 & RN13 to disconnect the platform controller from respectively SD and QSPI. Finally since the Zynq Bank0 is powered with 1.8V, I inserted a 3.3V to 1.8V regulator to feed the JTAG probe VDD.

While I can easily revert to the original setup if needed, for now I basically don't need the STM and this is the setup I find to best suit my needs.

DDR/SD/QSPI tested with PS and everything is behaving as expected, so problem solved and ready to move on (Oh, and I got that pesky white led which keeps blinking when a bitstream is loaded!!)

Nice board and I'm pleased with the connectors as well:
- 1.27mm pitch is not too wide, not too narrow. Combined with through-hole means it'll be piece of cake to temporary solder some cables for quick testing like checking signals with a scope
- GND between each LVDS pair
- SRCC/MRCC (external clock inputs) are spread to the 4 (5) FPGA connectors

[pat...@gmail.com]

One more mod and I figured it's probably best to group them together in the same thread if someone has the same needs, although for obvious reasons I don't recommend to do any of those.

I don't know what's the idea behind the reset push-button, pin17 or pin19 of J2 but the bottom line is that I often need to reset the PS and none of those 3 guys seem to do it.

I'm sick of having to turn the power off and on again every time I need to reset the system, so I de-soldered the select push-button, and soldered instead a smaller one to GND and a wire going to 5 of RN6 (PS_SRST B10).

[Cousins]

Ha - nice! Although this would seem to fall into the "I've hardware hacked my way to voiding my Warranty" category... :)

For reference, the button functionality is actually software driven (by the STM32).

Shane asked a question about the STM32 source code in another thread. We're discussing on our end the best way to handle that and will get back to you/everyone shortly.

-Ryan

[pat...@gmail.com]

Thanks Ryan.

I'm not getting along with the STM controller sitting in the middle and I've basically taken it out of the equation. If one day I decide to put it back, the source code will definitely be most welcome.

Anyway the board is working like a charm and I'm very happy with it. Here's a short video of the current setup while integrating a cdrom drive https://youtu.be/3WGMJvbun_Y