I am using a Snickerdoodle Black and Breaky Breaky to prototype a product that will eventually transition to custom PCB. I have my FPGA code running and I want to program it into the Snickerdoodle flash. This is a bare metal application. The Snickerdoodle Hardware Configuration Guide explains the process for generating the .bin file, then suddenly veers off into loading the FPGA from Linux. There is one discussion in the forum that seems to be related:
I am using the SDK command Xilinx -> Program Flash to program over the Xilinx Platform Cable.
So, exactly how do I take the .bin file that I created from bootgen and program it into something on the Snickerdoodle (either Flash or SD, I don’t even know which) so that my baremetal application is running on power up?
In terms of booting snickerdoodle in QSPI mode, the original version of the firmware requires the on-board buttons be used to select a boot media other than the SD card (default). From the topic you linked:
You can change the boot source by holding down the SELECT button while powering on the snickerdoodle. You will see all of the LEDs on the board turn on for 3 seconds and turn off when the boot sequence has ended. You can release the SELECT button after the LEDs turn off. The platform controller will "remember" the boot selection until the power has been cycled. If you need to reset the Zynq to clear your programming and bitstream, you can press and hold the RESET button for 3 seconds. The APP LED will flash at 1Hz when the reset has been asserted and can then be released. The boot source that was selected during the initial power up will be used when the reset is released.
Right now, the problem isn’t booting, it’s how do I write to whatever device I’m booting from. On all my other evaluation boards, I choose Xilinx -> Program Flash Memory put in my Image File and FSBL File locations and click the Program button.
When I do that with my Snickerdoodle, the SDK console eventually says:
WARNING: [Xicom 50-100] The current boot mode is SD.
If flash programming fails, configure device for JTAG boot mode and try again.
and then later:
Problem in running uboot
Flash programming initialization failed.
ERROR: Flash Operation Failed
So then I powered up while holding down the Select button and tried programming the flash again. I don’t get errors, but it just hangs preparing for programming flash.
Holding down both buttons acts the same as not holding down any buttons.
I gave up on the flash becasue holding down buttons on the snickerdoodle won’t be acceptable when I make up a demo in an enclosure.
I got an SD card and figured out how to program it and boot the board. This uncovered my next problem, and maybe a fatal flaw in using a Zynq. In my project, the ARM runs a small supervisory program that manages multiple image sensors writing to DRAM. The ARM code is small enough to execute out of OCM, which works fine when running from SDK. But when I boot from flash or SD, the FSBL is written to OCM and when the main program is also written to OCM it causes problems. I changed the linker to put the ARM program in DRAM and now I can boot everything from SD. I will have to evaluate my project to see how this affects the memory bandwidth, but for now I’m all set.
Thanks for your quick reply and suggestions.
—
Joe
We are working on an updated version of the firmware that we will be releasing shortly; with this, we can provide a version that will allow you to boot from QSPI immediately/by default.
Re: the OCM, can you describe what kind of problems you’re having and what you’re ultimately trying to accomplish? Is executing out of OCM a requirement for the application or is that still TBD?
I’m guessing you already went through these links:
The issue is that for some of my applications I’d need about 2GB/s of bandwidth to DRAM. With 32-bit wide memory and a 400MHz clock (800Gb/s) that’s 3.2GB/s. Let’s say I get 70% of that, or 2.2GB/s. If I don’t have to share that with the ARM then I’m better off. I’ve looked at lots of forum posts, but I’ll make sure that I check out the ones you’ve listed. There’s a great one about running a Zynq with no DRAM at all. That involved paring down the FSBL and merging it with the main code. That’s when I knew I was in over my head!
Booting from QSPI has the advantage of a quicker turnaround in debugging if I can write the QSPI directly from SDK. I use a tcl script to quickly create all my bitstreams, but it takes time to pull out the SD card, put it in the adaptor, write it and put it back on the board. My final design will boot from QSPI, so that will be one more thing proven to work before committing to PCB.
Yeah I thought about including that link too…XIP was going to be the next suggestion actually (if you’re trying to avoid using the DRAM for anything but the image sensors). That’s odd that you can’t program the flash or get the board to enter the appropriate boot mode though… I’ll have to check that out on another board in the office tomorrow.
I installed and have running r2p0. I was hoping that it would have the option to boot from QSPI by default, but I don’t see that. Is this possible with r2p0, or would I need a custom version? I am using the snickerdoodle to prototype a product that boots from QSPI. I need to make sure that it can fall back to the ‘golden’ boot file on flash error, that it will reboot if the watchdog timer expires and that I can write the flash from my Zynq supervisory program. I plan on putting the snickerdoodle into an enclosure, so the users will not have access to the switches to change boot modes.
Have you tried holding the select button during power on and setting the default boot mode that way? Or are you able to now boot from flash reliably but looking to implement the additional features you described? If you’re looking for more advanced functionality (e.g. booting from different partitions based on certain criteria), that will require additional firmware modifications. Although it shouldn’t be that bad.
I see what I did wrong: I mis-read “Board will use selected boot mode until changed” to mean that it would use the selected boot mode until it was power cycled. I followed the instructions and it does work.
I do have another problem, though. I can’t get Vivado or SDK to program the flash. Both hang shortly after starting.
I like the SDK because it has more status messages. This is what I see when I try to program the flash via SDK (flash type is qspi-x4-single, offset 0):
Connected to hw_server @ TCP:127.0.0.1:3121
Available targets and devices:
Target 0 : jsn-DLC10-0000153a9a4f01
Device 0: jsn-DLC10-0000153a9a4f01-4ba00477-0
So it’s hanging while executing the UBoot serial flash probe command. I have the boot mode set to JTAG. Could there be interference from the STM32? Should I be able to program the flash through Vivado and SDK?
Apologies for the delay… Not sure if you figured this out already, but it appears the hardware might be configured incorrectly (either that, or the error messages are misleading).
Do you know what this is?
Zynq CSE QSPI Board
Or this?
DRAM: 256 KiB
It almost seems like U-Boot is using the SRAM but things it's DDR, is that possible?
Typically if you specify a flash memory device Vivado’s Hardware Manager doesn’t like (i.e. see), you’ll immediately see an error message indicating as much and you won’t be able to proceed.
One thing that wasn’t totally clear from your previous post: Were you able to successfully program your Zedboard’s flash but not your snickerdoodle’s? The messages appear to be identical, but I couldn’t tell if one was successful and the other was hanging or if you’re having the same issue with both.