QSPI boot / update

Hello Terok,

Yes, you can use the QSPI and the eMMC memory as storage after boot, with the limitation that you or your application/OS will need to be aware of the location of the boot files to avoid overwriting them.

You can use the eMMC as storage memory if you boot from QSPI.

The eMMC cannot be the 'primary' boot source for a Zynq based device but can be a 'secondary' boot device that is accessed once the boot is initiated from one of the available 'primary' boot devices such as QSPI or SD Card. In this case the QSPI can be used as storage memory after boot.

There is an application note "Application Note on Booting PicoZed Using QSPI and eMMC" should answer most of your questions. You can download the app note here: 

http://picozed.org/support/design/13076/106

-Gary

Hi Gary,

Thanks for the answer.

And obviously I could write a new boot image to QSPI (remote update) with application/OS as well, correct ?

Is there any particular reason why the eMMC couldn't be the primary boot source ?

-Terok

Hi Terok,

Yes, you could write a new boot image to the QSPI. Given the possibilty of an error during that operation that could render your design a 'brick' I would suggest studying the fall back or multiboot modes available.

The Zynq device primary boot is limited to QAPI, SD Card, NAND or NOR Flash or JTAG.

For a discussion of both the primary boot options and boot modes take a look at Chapter 6 of the Zynq Technical Reference Manual (UG585):

http://www.xilinx.com/support/documentation/user_guides/ug585-Zynq-7000-TRM.pdf

-Gary

Hi Gary,

Thanks for the answer.

One question though, if you may.

Does the multiboot / fallback work as described in

http://www.wiki.xilinx.com/Zynq-7000+AP+SoC+Boot+-+Multiboot+Tech+Tip

also when trying to download the bitstream from QSPI ?

Hello Terok,

If by "download the bitstream" you mean booting then the short answer is yes. The Tech Tip you reference does show the boot options using QSPI Flash.

There is one thing to consider if you do plan to use multiboot or fallback with a QSPI device that is larger than 128 MB. The Zynq device can only address the first 128 MB of the QSPI using 'linear addressing mode'. To address memory past 128 MB in larger devices by writing a fourth address byte into a vendor specific QSPI 'extended address register'. This operation is supported by the Xilinx tools and software drivers and is normally transparent to the user. However while this extended address register is cleared by a Power On Reset, it is NOT reset by a soft reset. So, if you plan to use one of the multiboot or fallback boot methods with a QSPI device larger than 128 MB you would need to take that into account.

There are several ways I can think of the handle this.

The first one is to add hardware to your design to detect soft resets and clear the QSPI register. This approach is detailed in this Xilinx Answer Record:

http://www.xilinx.com/support/answers/57744.html

The second approach would be to make sure you never use any QSPI memory above the 128 MB limit so that the extended address register is never written.

The third option would be to 'mirror' the boot image, or at least some code that would set the correct address and then jump to the image, at each 128 MB 'boundary' of the QSPI device to handle any extended address register setting.

-Gary

Hi Gary,

Thanks for this again.

Let's say that the system has QSPI and eMMC

Couple questions:

- Is it possible to use both fallback and multiboot ? How does it work ? Are parts in eMMC also 'fallback'
Or should one consider the whole boot(=fsbl+bitstream+uboot) as one although they are in multiple memories ?

-In production, does Xilinx tools (+Zynq) offer possibility to program the eMMC ? No extras needed ?

Hi Gary,

Thanks for this again.

Let's say that the system has QSPI and eMMC

Couple questions:

- Is it possible to use both fallback and multiboot ? How does it work ? Are parts in eMMC also 'fallback'
Or should one consider the whole boot(=fsbl+bitstream+uboot) as one although they are in multiple memories ?

-In production, does Xilinx tools (+Zynq) offer possibility to program the eMMC ? No extras needed ?

Gary, Let me be more specific with the terms:

Can one use fallback and partioning the boot to QSPI and eMMC ?
Are parts in eMMC also 'fallback' ?
Or should one consider the whole boot(=fsbl+bitstream+uboot) as one although they are in two memories ?

-In production, does Xilinx tools (+Zynq) offer possibility to program the eMMC when the board is blank? No extras needed ?

thanks already

Hello Terok,

You need to read the wiki page you referred to above as well as the app note on programming eMMC memory referenced earlier in the thread to under stand how this works.

As mentioned before, eMMC memory can only be a secondary boot device, not a primary boot, so fallback or multiboot do not have anything to do with the eMMC memory, just the primary boot device. The code in your primary boot device (QSPI in this case) can call or jump to code in the secondary boot device but mulitboot and fallback are not involved. One typical scenario would be for the FSBL to be in the primary boot device and jump to UBOOT in the secondary device. The bitstream could reside in either.

Again, please refer to the application note mentioned above for programming the eMMC memory.

-Gary

Hi Gary,

thanks for the patience.

I have looked the notes like,

Application Note on Booting PicoZed Using QSPI and eMMC  -> Booting PicoZed Using QSPI and eMMC v3.0 (2015.2.1)

And also the swdev-document Zynq-7000 AP SoC SWDG UG-821.

I just can't find  guidelines how to format/place partions  to eMMC without something extra.

Above application note uses microSD card and Linux, correct ?

Is there a way to format/place partions to eMMC with SDK or some application project ?

I am looking a way to get it done without the microSD card as done in application note.

am I missing something here totally ?