Boot Standalone application from SD on CORA

[Erickson]

I am trying to boot a standalone application from a micro SD card on the CORA Z7 board.  I'm working with a rather unconventional setup.  Due to IT policy at work, the only micro SD card interface I have available is the one on the CORA board.  Yesterday, I modified the example program that comes with the xilffs_v3_6 library to write and read back from an SD card.  Then, I generated a BOOT.BIN file via Xilinx SDK -> Create Boot Image, using an auto-generated FSBL application and an auto-generated helloworld application.  I wrote the BOOT.BIN to the SD card, but the CORA board did not seem to work with this configuration.

I found Xilinx AR# 59476 with some troubleshooting tips.  I've copied their steps (in italics) and provided answers covering what I've checked.

1) Please provide the board schematics and the name of the SD Memory Card used.

Schematic from Digilent

The micro SD card is an 8GB MMCTR08G3ACH-NJ (originally bundled with a Raspberry Pi).

2) Is Zynq Production Silicon?

The Zynq is an XC7Z010, with ID code 13722093.  Based on Xilinx AR# 37579, I interpret the first digit as the version code.  Based on Table 1 in Errata Notification EN247, I think this means I am working with production silicon.

3) In which phase of booting is Zynq is failing? BootROM or FSBL?

As far as I can tell, the device is not reaching the FSBL.  I'm not seeing any output via the UART when I try to boot in SD card mode.  When I configure via JTAG, my helloworld program happily sends characters back to my computer, so I am confident that the terminal is set up correctly.

This is as far through the troubleshooting check list as I've reached so far.  I'm going to investigate some of the following items in the Xilinx checklist, but am feeling kind of stuck being unable to read out any debug information from the FSBL.
 

[jpeyron]

Hi @Erickson,

Typically, i have seen the delay added to the application instead of the FSBL as shown in this forum thread . We will not have a Cora Z7-10 board in the office until Wednesday. On Wednesday I will do some testing to get the project running using the QSPI FLASH.

thank you,

Jon

[Wizard]

Hi, I managed to make the SD card works on Cora 7Z-07S on Vivado 2017.4. The following settings are needed prior to image generation.

Remember to check "Reset entire" and "Program FPGA". My SD card is formatted to FAT32 too.

[john_c_kennedy]

Apparently the SD card MUST be formatted FAT32 or it won't work.  There are some third party FAT32 formatting programs that you can use to format the bigger SD cards (>16GB) so they will work.  I found some fairly cheap 8 GB class 4 SD cards on Amazon which can be formatted FAT32 directly in Windows 10, so I bought a couple for using with the Cora Z7 boards.

[john_c_kennedy]

I couldn't get the FSBL with a FreeRtos Application working with either the Xilinx 2019.1 or 2019.2 tools using a 64GB SanDisk SD card formatted exFAT (the only option in Win10).  Switched to an old 1GB no name SD card formatted FAT32 and got it to work with the Xilinx 2019.2 Vivado/Vitis tools.  So I'm not sure if the FSBL doesn't work with large SD cards formatted exFAT or if it only works with smaller SD cards formatted FAT32?  It would be nice if Xilinx or Digilent would clarify this for everyone and save us a lot of time mucking around.

[aadgl]

Worked immediately with 2019.2 versions of Vivado and Vitis

[aadgl]

I am having the same problem with Cora Z7-07S (xc7z007sclg400-1) in Vivado 2019.1.

(a) Create and Test an application that loops through "Hello World"
(b) In same SDK project, Create FSBL Application
(c) Create Boot Image for the "Hello World" application
(d) Format 16GB SD Card Fat 32 with Default Allocation Size
(e) Copy BOOT.bin to SD Card, then eject Card
(f) Power down Cora
(g) Install JP2 to short both pins
(h) Insert SD Card and power-up Cora
(i) Connect Putty to Cora's COM port (same that worked in (a))
(j) Wait, watch, press SRST button, no traffic from Cora to Putty, no flicker to Cora Com LED, etc

I tried the BOOT.bin in the project for the other Cora FPGA, by jpeyron, above, 8/31/2018.  Same results.

I have tried several other SD Card, one works with another Zynq board.

Any clues, other settings, would be appreciated.

Thanks,
Dave

 

[Erickson]

I ran some experiments to figure out how much delay is needed.  It's somewhere in between 0 and the amount of time added as a result of FSBL_DEBUG_INFO being defined in fsbl_debug.h.

I'm a bit of a novice with C, and didn't realize that if I defined FSBL_DEBUG_INFO in fsbl.h, that it would be ignored by the compiler.  Had I enabled it correctly to begin with, I probably would have never noticed the sensitivity to delay and would have had a painful time in a few months when we go to do customer demos and I (hypothetically) un-define the FSBL_DEBUG_INFO flag.

On a related note, I found that the BOOT.bin file @jpeyron kindly provided had been built with the FSBL.elf, HW.bit, and APPLICATION.elf files.  The resulting BOOT.bin file was a little over 2-MB, while the BOOT.bin file resulting from just an FSBL.elf and APPLICATION.elf is about 120-kB without FSBL_DEBUG_INFO and about 135-kB with FSBL_DEBUG_INFO included.  Based on my hardware setup where the BOOT.bin has to be transferred to the micro SD card by way of the UART interface on the Zynq (IT still won't let me put an SD card into a company computer), the factor of 16 difference in file size made for a meaningful difference in the time I had to wait for Tera Term to push the file to the Zynq.  Needless to say, for my delay-length experiments, I cut down the cycle time considerably by leaving out the HW.bit file.

[jpeyron]

Hi @Erickson,

I'm glad the delay has fixed the issue. Let us know what you find with how long and where you end up using the delay. I do not know of a way to have tera term maintain the connection with serial ports while resetting the device.

thank you,

Jon

 

 

 

[Erickson]

Hi @jpeyron,

Before I saw your reply, I went ahead and added a for loop to the start of the FSBL main function, and re-generated my programming files.  Now, from the time I reset the board until the done bit LED comes on is several seconds.  I was pleased to see that my helloworld program now executes correctly.

It appears I stumbled upon an additional issue that may have been confusing things for a while.  When I power cycle the CORA board, Tera Term seems to disconnect from the COM port, even though it continues to read "COM4:115200baud - Tera Term VT" at the top of the window.  Do you know if there is a setting in Tera Term to keep a hold on the port and keep listening even if the device at the other end disappeared? EDIT: This seems to be more of a Windows issue than a terminal program issue.  When the CORA board power cycles, the COM4 device disappears momentarily from Windows device manager.  Tera Term allows this to happen silently.  Putty, on the other hand, throws a warning.

The sequence of steps I'm needing to take in order to see the helloworld output looks like:

1. Power cycle CORA board
2. File -> Disconnect in Tera Term
3. File -> New Connection in Tera Term
4. Select COM4 and press OK
5. Press the SRST button on the CORA board
6. Wait for my for-loop to finish looping
7. Then the helloworld output appears on the terminal

I'm going to go have lunch, but I'll do some experimenting this afternoon to see how much delay I actually need in order for the system to work, and whether it matters if it's at the start of the FSBL or the start of my application.

Thanks for the suggestion to add delay.

[Erickson]

Hi @jpeyron,

Both SD cards that I tried were formatted to FAT32.  Unfortunately, I can't provide a screen shot of the contents.  I can't connect an SD card into a work computer system, due to an IT policy that I mentioned in my original post.  I've checked both cards on a non-work system and verified that BOOT.bin was the only file, and that the file size matched what had been generated by the Xilinx tools.

With respect to adding a delay, would that be at the start of the main function in the FSBL?

Thank you for the help.

[jpeyron]

Hi @Erickson,

Is the sd card formatted to FAT32? Please attach a screen shoot of contents of the SD card. Add a delay in the beginning of the  SDK Code to ensure that all of the power up sequences are done. 

thank you,

Jon

[Erickson]

Good morning @jpeyron,

Thank you for the follow-up.  I'm seeing the exact same result with your project as I did with mine.  I've put together a more detailed description of my setup and the steps I've been following:

PC running SDK and Tera Term <------ USB/UART ------> CORA <------ SDIO -------> micro SD card

1. Launch SDK
2. Power CORA board
3. Connect Tera Term to COM4 @ 115200baud
4. Launch SDIO_write_file application (modified from xilffs_polled_example in xilffs_v3_6 library) from the SDK
5. When prompted in Tera Term, send BOOT.bin file
6. Power down CORA board
7. Set jumper on JP2 to select SD boot
8. Power CORA board

The output I am seeing on Tera Term is as follows.  It is all generated by the SDIO write application.  There is no indication of output from either the FSBL or the user application.

<font=courier>
Write File Test
Entering FfsSdPolledExample()
Filling SourceAddress[] buffer.
Send file to be written:
2204424 bytes received
Attempting to mount the device
Attempting to make a filesystem
Entered f_mkfs()
Volume read from path: 0
Attempting to open file
Attempting to seek to start of file
Attempting to write data to file
Attempting to seek to start of file
Attempting to read data from file
Checking file contents for match
Attempting to close the file
Successfully ran SD Polled File System Example Test
</font>

I tried a different micro SD card without any luck.  I've already installed the Digilent board files, and have been using those for all of the projects I've started in Vivado.

 

[jpeyron]

Hi @Erickson,

Here is a completed but not verified Vivado 2017.2 Cora-Z7-10 sd bootloader project with the basic hello world template used.  Add the boot.bin to a FAT32 SD card and make sure the Cora Z7-10 is set to micro sd mode on the Mode jumper (JP2). Use a serial terminal like tera term and have the baud rate set to 115200. Are you able to see the hello world in tera term?  I believe Step 3 of the Xilinx Programming/Booting troubleshooting checklist is information they would like you to provide if you are going to make a ticket with xilinx. I am not sure where to get that specific information.  Instead of using the target fpga  XC7Z010-1CLG400 I would suggest to use the board files provided by Digilent. The board files correctly configure the zynq processor. Here is a tutorial on installing the board files. If you are trying to boot an hdl(Verilog/VHDL) project then you do not need to include the APPLICATION.elf since there would not be any. In this case you would need to include the HW.bit file otherwise how would it boot the correct hw platform?

[Erickson]

After some more digging, I'm still not there, but have an update that may help narrow down what's happening.  The Xilinx AR# 59476 suggests:

Please provide the status of INIT_B (high or low or blinking), REBOOT_STATUS and BOOT_MODE registers after the boot failure.

REBOOT_STATUS is reading a value of 0x0040_0000 after POR, and reads 0x0060_0000 after I press the SRST button.

The BOOT_MODE register reads 0x0000_0000 following a POR with the JP2 jumper removed.  After a POR with JP2 installed, BOOT_MODE reads 0x0000_0005.  These match my expectations based on studying the UG585 Zynq 7000 TRM.

Looking at the schematic, I see INIT_B is tied to a resistor rather than an LED as assumed by the Xilinx troubleshooting checklist.  I suppose that means I will have to find a magnifying glass and oscilloscope in order to find out what it is doing. UPDATE: INIT_B is sitting happy at 3.3-V.

[Erickson]

Hi Jon,

It appears I do not have a successful boot from the SD card, even for just a UART helloworld.  When I go through Run As -> Run Configurations from the SDK, the applications work as I expect.  I'm trying to run on a CORA Z7 10 version with the XC7Z010-1CLG400, developing with Vivado  and SDK 17.2.

Looking at the Zedboard programming guide, I noticed a difference between what it describes in Appendix A and what I had been doing.  It calls out including the HW.bit file in addition to the FSBL.elf and APPLICATION.elf files.  Because my application only uses the Processor Subsystem (employing the UART and SDIO peripherals), I assumed the HW.bit file did not need to be included in the BOOT.bin file.  I'm still not very confident whether that is needed or not, given the nature of my application and intended HW configuration.  Do you know if this is a meaningful difference?

I tried creating a new BOOT.bin incorporating the HW.bit file from the Vivado project.  That made the .bin file a lot bigger, but behaved the same when I attempted to boot from the SD card.

Something else I noticed is that my original BOOT.bin file was only about 120-kB.  That seemed small, given that the FSBL.elf and APPLICATION.elf files were 310-kB and 162-kB respectively.  I'm not confident that this is the root of my problem, but seems a little suspicious.

Step 3 of the Xilinx Programming/Booting troubleshooting checklist suggested:

Please provide the status of INIT_B (high or low or blinking), REBOOT_STATUS and BOOT_MODE registers after the boot failure.

I'm trying to figure out how to read those.  Are they something I would access through the XSCT console in the SDK?

[jpeyron]

Hi @Erickson,

Are you able to get the basic un-altered uart hello world booting from the SD card on the Cora Z7? Which Cora Z7 board do you have the 10 or the 07s? What version of Vivado are you using?  Here is the Zedboard Programming Guide in SDK tutorial which is a good reference for how to boot from the SD card with the Zynq processor as well as how to make the BOOT.bin.

thank you,

Jon