UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Reply

FSBL without DDR

Visitor
Posts: 7
Registered: ‎06-12-2015

FSBL without DDR

Hello,

 

I have a dedicated board that does not integrate any external memory. The application is small enough to fit in the OCM memory.

 

The default FSBL is designed to work with DDR. I found 2 ways to modify the FSBL for my specific need :

1/ https://www.xilinx.com/support/answers/56044.html
2/ http://www.wiki.xilinx.com/Zynq-7000+AP+SoC+Boot+-+Booting+and+Running+Without+External+Memory+Tech+Tip

Both solutions are documented for old versions of Vivado.

 

The solution 1/ is not suitable for me as the application memory footprint is limited to 64K.

 

I tried to implement the 2nd solution without success by merging differences between sources files provided in tech tip and the default FSBL provided by Vivado 2016.4 . There are now a lot of differences due to the updates to Vivado 2016.4 and I guess I miss something.

 

Has anybody a newer version of this kind of implementation (FSBL in XIP_MODE and application in OCM) ?

Is there another way to make the FSBL working without DDR?

 

Thanks in advance

 

Regards

 

Samuel

Scholar
Posts: 1,682
Registered: ‎07-09-2009

Re: FSBL without DDR

Sorry I dont know

 

But I'm very interested if you get an answer on how to not use external memory, 

 

( the fact its ddr is not relevant as such ) 

Highlighted
Explorer
Posts: 188
Registered: ‎01-15-2008

Re: FSBL without DDR

Yes, you can do this, though it's not obvious.  I got it working on a custom board with QSPI and no external RAM.  Note that you cannot do it with NAND flash (my first cut at the PCB design used this, and I discovered it wasn't possible to boot from NAND without external RAM, due to the need for complicated bad-block tables.  I had to respin the board).

 

Here are the notes I made on the topic.  Hope this helps.

 

Rick

 

The boot ROM

The QSPI flash holds both the bitstream for programming the Programmable Logic (PL) portion of the Zynq and the executable software that runs on the Zynq processor.  This is a complicated issue.

A typical Zynq system with a lot of DDR RAM will include a First Stage Boot Loader (FSBL) executable, and also a much larger application program, which might be an entire Linux operating system, for instance.  In our no-DDR case, the executable must fit in the 192kB On Chip Memory (OCM), so I’ve combined the boot-loader with the application into a single executable (“FSBL_plus_app”).

I created the bootloader in SDK- they supply an FSBL model.  But this model assumes the presence of DDR RAM and so needs a lot of editing to work right in our system.

 

When the Zynq processor powers on, or is given a hard reset (via the PS_PORb input), it first executes the on-chip Boot Rom (which is unalterable).  This code reads the boot mode jumpers, does a little bit of Processor System (PS) setup, then loads the executable from the flash device into the OCM and vectors to it.  In a system with DDR, the FSBL would then initialize DDR, load a much larger application from flash into DDR, load the configuration bitstream into the PL, and then vector to the application in DDR.  In our system, the Boot Rom reads the jumpers, sets up the PS, then loads the executable (FSBL_plus_app) into OCM, programs the PL and vectors to OCM.  The processor continues to execute the service loop from OCM.

 

The 32MB (256Mb) QSPI can be addressed two different modes,  “linear” or “IO”.  In linear mode some hardware is used to read the contents with less processor intervention; in IO mode the processor has to get more involved.  But only the lower half of the 32MB is accessible in linear mode due to the 24-bit addressing limitation.

 

The FSBL generated in SDK sets the mode to IO, because the QSPI is >16MB.  But the FSBL then wants to move the PL partition into DDR prior to transferring it, via DMA, to the PL.  Since there’s no DDR, this won’t work (one could perhaps rework the FSBL PartitionMove to transfer data in smaller chunks, but that seems like a can of worms).  In linear mode, the partition goes directly via DMA to the PL, no DDR required.  To get around this I hard-coded the access mode to “Linear” (in qspi.c):

 

if (1){//QspiFlashSize <= FLASH_SIZE_16MB) {  RJR Added

 

Now the transfer will be done in linear mode, despite the flash being 32MB.

This works fine with the zedboard (XC7Z020), whose bitstream is about 4MB.  But our system has an XC7Z100, whose bitstream is 16.7MB.  This won’t fit in half the flash, unless it’s compressed (and the flash needs to contain the executable, too).  Therefore, the XC7Z100 bitstream needs to be compressed.  My hw_platform_06 design compressed from 16.7MB to 2.5MB.  Compression is not guaranteed to save any space at all (it simply sets a flag whenever a configuration frame is exactly equal to the previous one).  If our ultimate hardware design is extremely full we might get into trouble here, in which case we’d have to rework the FSBLcode to access the full 32MB space without the use of DDR. (An alternative which would also save some power would be to use an XC7Z050on the flight board, if the design would fit).

Scholar
Posts: 1,682
Registered: ‎07-09-2009

Re: FSBL without DDR

Fantastic reply

 

thank you

 

Xilinx , if your listening, how about paying this person to write up an app note for you.

 

Visitor
Posts: 7
Registered: ‎06-12-2015

Re: FSBL without DDR

Thanks a lot for sharing and for the quality of your notes.

 

I will try to include my software into the FSBL code and will post the result.

 

Regards,

 

Samuel