09-24-2019 11:36 AM
I'm using the ZCU102 dev board and attempting to follow the instructions in https://www.xilinx.com/support/answers/67475.html to reduce the boot time as much as possible. It defines some REG_INIT commands for optimizing the quad SPI for PRE-FSBL BOOT ROM reading, but there is one command that prevents the first stage boot loader from loading:
.set. 0xFF0F0000 = 0x00000030; // This is the QSPI offset.
.set. 0xFF0F0FFC = 0x00000000; // This is the QSPI offset.(I'm not sure what register this references, this write prevents the FSBL from loading)
.set. 0xFF5E0020 = 0x00014800; // CRF_APB QSPI REF CLOCK offset
.set. 0xFF5E0068 = 0x01040100; // CRF_APB QSPI REF CLOCK offset
Are those the only 4 commands that I need to include or am I missing something else?
After power on there is a period of about 366ms before the QSPI clock becomes active.
09-24-2019 01:34 PM
After doing some more poking around I found that the PS_POR_B pin is deasserted right before the initial quad SPI clock activity. Do the measured boot times use that as the starting point? Rather than when power is first applied to the dev board?
09-25-2019 10:01 AM
I determined that the time between switching on the power and the QSPI becomming active is due to the POR_B being released ~366 ms after the power is turned on due to the voltage sequencer. My bitstream is 9.1MB and my first stage boot loader .elf is 1.5 MB. The time between POR_B being released to DONE led (DS32) illumination is 190ms. I made the changes required in the "notes and disclaimers" section of the boot time excel sheet. The estimated boot time from the excel sheet is 117.79ms.
I have the POR_OVERRIDE pin connected to VCCINT but it doesn't appear to make a difference in the boot time. According to the spread sheet, having this enabled should cut out approximately 50ms.
It seems more time is spent running the PMU and CSU than is indicated in the spreadsheet. I do see the QSPI clock increasing from 13MHz to 50MHz and eventually to 150MHz.
09-25-2019 05:28 PM
It appears the CSU is reading the FSBL out of flash twice when power is applied to the board but only once when the power on reset push button is asserted. The CSU takes about 60ms to load the FSBL rather than the estimated 44ms from the spreadsheet.