element14 Community
element14 Community
    Register Log In
  • Site
  • Search
  • Log In Register
  • Community Hub
    Community Hub
    • What's New on element14
    • Feedback and Support
    • Benefits of Membership
    • Personal Blogs
    • Members Area
    • Achievement Levels
  • Learn
    Learn
    • Ask an Expert
    • eBooks
    • element14 presents
    • Learning Center
    • Tech Spotlight
    • STEM Academy
    • Webinars, Training and Events
    • Learning Groups
  • Technologies
    Technologies
    • 3D Printing
    • FPGA
    • Industrial Automation
    • Internet of Things
    • Power & Energy
    • Sensors
    • Technology Groups
  • Challenges & Projects
    Challenges & Projects
    • Design Challenges
    • element14 presents Projects
    • Project14
    • Arduino Projects
    • Raspberry Pi Projects
    • Project Groups
  • Products
    Products
    • Arduino
    • Avnet & Tria Boards Community
    • Dev Tools
    • Manufacturers
    • Multicomp Pro
    • Product Groups
    • Raspberry Pi
    • RoadTests & Reviews
  • About Us
    About the element14 Community
  • Store
    Store
    • Visit Your Store
    • Choose another store...
      • Europe
      •  Austria (German)
      •  Belgium (Dutch, French)
      •  Bulgaria (Bulgarian)
      •  Czech Republic (Czech)
      •  Denmark (Danish)
      •  Estonia (Estonian)
      •  Finland (Finnish)
      •  France (French)
      •  Germany (German)
      •  Hungary (Hungarian)
      •  Ireland
      •  Israel
      •  Italy (Italian)
      •  Latvia (Latvian)
      •  
      •  Lithuania (Lithuanian)
      •  Netherlands (Dutch)
      •  Norway (Norwegian)
      •  Poland (Polish)
      •  Portugal (Portuguese)
      •  Romania (Romanian)
      •  Russia (Russian)
      •  Slovakia (Slovak)
      •  Slovenia (Slovenian)
      •  Spain (Spanish)
      •  Sweden (Swedish)
      •  Switzerland(German, French)
      •  Turkey (Turkish)
      •  United Kingdom
      • Asia Pacific
      •  Australia
      •  China
      •  Hong Kong
      •  India
      •  Japan
      •  Korea (Korean)
      •  Malaysia
      •  New Zealand
      •  Philippines
      •  Singapore
      •  Taiwan
      •  Thailand (Thai)
      •  Vietnam
      • Americas
      •  Brazil (Portuguese)
      •  Canada
      •  Mexico (Spanish)
      •  United States
      Can't find the country/region you're looking for? Visit our export site or find a local distributor.
  • Translate
  • Profile
  • Settings
Avnet Boards Forums
  • Products
  • Dev Tools
  • Avnet & Tria Boards Community
  • Avnet Boards Forums
  • More
  • Cancel
Avnet Boards Forums
ZedBoard Hardware Design Optimizing Boot Time
  • Forum
  • Documents
  • Members
  • Mentions
  • Sub-Groups
  • Tags
  • More
  • Cancel
  • New
Join Avnet Boards Forums to participate - click to join for free!
Actions
  • Share
  • More
  • Cancel
Forum Thread Details
  • State Not Answered
  • Replies 5 replies
  • Subscribers 353 subscribers
  • Views 717 views
  • Users 0 members are here
Related

Optimizing Boot Time

Former Member
Former Member over 12 years ago

Iu2019m trying to minimize bare metal boot time using QSPI flash on a Zedboard, Rev C.  Using a scope, Iu2019ve verified the QSPI SCLK is running at 100 MHz.  At that speed, the boot time should be less than 100 msec (Boot ROM + FSBL + PL + PS) but Iu2019m measuring close to 600 msec.  Monitoring the CS signal on the flash device I see what appears to be many 8 clock cycles of data transfer then a pause of 100 nsec after each one.  In addition to these pauses is a periodic delay of around 6 usec and a several pauses in the 50 msec range.  What are these delays?  Is there something in the FSBL that can be adjusted to remove them?
tt
Thanks for your help!
Clay

  • Sign in to reply
  • Cancel
  • Former Member
    0 Former Member over 12 years ago

    Give this a try. Edit the fsbl/src/qspi.c file and in the InitQspi(void) function change the XQSPIPS_CLK_PRESCALE_8 (this is the FSBL default setting) to XQSPIPS_CLK_PRESCALE_2. Theoretically, this should improve the access time by a factor of 4.

     

    -Gary

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Former Member
    0 Former Member over 12 years ago

    Gary, thanks for the quick response.  I had actually changed that value in the FSBL already--prior to changing it from the default (8), I measured the QSPI SCLK at 25 MHz and the overall boot time at around 600 msec.  After changing the PRESCALE value to 2, I measured the QSPI SCLK at 100 MHz but the overall boot time remained the same. I think this tells me the boot time is being driven by something in the FSBL code and not the QSPI bus speed.  Iu2019m digging through the FSBL code now but havenu2019t found anything obvious yet.
    Does that make sense or is there somewhere else you think I should look?
    Thanks, Clay

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Former Member
    0 Former Member over 12 years ago

    Hi,
    could u share how did u measure 600msec whole boot time?

    According to avnet doc it should be...

    As 100MHz QSPI Flash device throughput of up to 50MB/s)


    Parameter Time (ms)
    Power Ramp 50
    PLL Lock 0.05
    PS Image Load (5MB) 100
    PL Image Load (5MB) 100
    Total Boot Time 250.05

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Former Member
    0 Former Member over 12 years ago

    Using a scope, we initially measured the time between the Power Good LED (green) and the FPGA Config Done LED (blue).  To get a better understanding, we also measured QSPI bus activity with a scope by monitoring the Chip Select and SCLK pins on the flash device itself.  Monitoring the QSPI bus shows the initial Boot ROM speed to be around 5.4 MHz, it goes up to about 70 MHz while loading the FSBL and then it finally runs at 100 MHz while loading the PL and PS.  There are lots of unexplained pauses in the transfer as well.  As I understand it, the Avnet engineers were able to duplicate this and are looking into it.  Iu2019ll post more once the issue is resolved.

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
  • Former Member
    0 Former Member over 12 years ago

    Worked with Xilinx support to resolve this. It turns out that it is related to the QSPI device size. There is a workaround if you can live with only 16 MB of QSPI space. Here is the response from Xilinx support:

     

    I've dug deeper into this issue and the performance is related to the larger QSPI device.  Once a part goes beyond the 16MB boundary, we have to access it in IO mode, not linear due to the 24 bit address limit in our QSPI controller.

     

    If the customer image is below 16MB, there is a code change in qspi.c that can be done to trick the driver.   After line 419, you can add:

    QspiFlashSize = FLASH_SIZE_128M;

     

    That will keep the driver in linear mode and drop boot time.   I've verified this in my mcs.  I'll be writing up an AR on this next week detailing what all is going on.

     

    -Gary

    • Cancel
    • Vote Up 0 Vote Down
    • Sign in to reply
    • Verify Answer
    • Cancel
element14 Community

element14 is the first online community specifically for engineers. Connect with your peers and get expert answers to your questions.

  • Members
  • Learn
  • Technologies
  • Challenges & Projects
  • Products
  • Store
  • About Us
  • Feedback & Support
  • FAQs
  • Terms of Use
  • Privacy Policy
  • Legal and Copyright Notices
  • Sitemap
  • Cookies

An Avnet Company © 2026 Premier Farnell Limited. All Rights Reserved.

Premier Farnell Ltd, registered in England and Wales (no 00876412), registered office: Farnell House, Forge Lane, Leeds LS12 2NE.

ICP 备案号 10220084.

Follow element14

  • X
  • Facebook
  • linkedin
  • YouTube