Sorry, you need to enable JavaScript to visit this website.

QSPI boot / update

Unsolved
16 posts / 0 new
Terok's picture
Terok
Junior(0)
QSPI boot / update

Hi,
I would like to confirm few things.
I am planning a design with Zynq + QSPI+eMMC and have few questions related to that.
 
1) If I choose to use qsPI as boot; the QSPI can be updated (=write/read) with Linux on the fly easily using same SPI pins that they are originally assigned ?

Meaning that these QSPI pins can be accessed by Linux also in user mode ? The qSPI are NOT dedicated to the boot only ?
2) If using QSPI as a boot, eMMC can be used as a storage memory ?
 
3) If using eMMC as a boot source, the same eMMC can be used as a storage memory at the same time ?
 
Thanks!
 

TroutChaser's picture
TroutChaser
Moderator(18)
Hello Terok,

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

Terok's picture
Terok
Junior(0)
Hi 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

TroutChaser's picture
TroutChaser
Moderator(18)
Hi 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-...

 

-Gary

Terok's picture
Terok
Junior(0)
Hi 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 ?
 
 
 

TroutChaser's picture
TroutChaser
Moderator(18)
Hello Terok,

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

 

Terok's picture
Terok
Junior(0)
Hi 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 ?
 
 
 
 

Terok's picture
Terok
Junior(0)
Gary, Let me be more specific

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

TroutChaser's picture
TroutChaser
Moderator(18)
Hello Terok,

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

Terok's picture
Terok
Junior(0)
Hi 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 ?
 
 
 
 

Terok's picture
Terok
Junior(0)
Partly answeroing to myself..

Partly answeroing to myself..
Should this be done via U-boot in two stages?
 
First load u-boot to QSPI  (=fsbl+u-boot) and boot from and there:
1)make eMMC format and place eMMC boot parts to there (bitstream+uboot+OS)
2) and then update the QSPI with FSBL with emmc_support
 
Or how ?

Terok's picture
Terok
Junior(0)
Hi Gary,

Hi Gary,
Could you confirm:
Is the u-boot a solution for this (or some own uploader sw application) or something else ?

TroutChaser's picture
TroutChaser
Moderator(18)
Hello Terok,

Hello Terok,

One of my colleagues suggested that this method would be more complicated than needed. His suggestions was to:

 

The QSPI image can be programmed directly from SDK.

Using that image, they can boot the system into Linux and use that to format the eMMC and copy files over to the eMMC file system.

They could then copy new Linux components over to the QSPI if needed, then reboot the system to boot Linux from QSPI and mount the RFS from eMMC.

U-boot could be used to replace SDK above but there is the issue of getting U-boot loaded onto the device to begin with (without using an SD card).

 

-Gary

 

 

Terok's picture
Terok
Junior(0)
Hi Gary,

Hi Gary,
Couple question:
1) Is there a difference if the eMMC is located in SD0 or SD1 ?
2) With the system you described above, from where they boot the linux ? qSPI/NFS or from where ?

Terok's picture
Terok
Junior(0)
Hi Gary,

Hi Gary,
Could you see these through:
Couple question:
1) Is there a difference if the eMMC is located in SD0 or SD1 ?
2) With the system you described above, from where they boot the linux ? qSPI/NFS or from where ?
    Does the used Linux fully fit to the QSPI ?

jan.budroweit's picture
jan.budroweit
Junior(0)
Hi Gary,

Hi Gary,
Hi Terok,
 
we are working on a similar object. We would like to support muli-boot and fallback options (golden image search) if the bootable image is damaged. We thought about NAND Flash devices, which support lager sizes and are supported by the Zynq Controller as a boot medium. But NAND flashes requieres Bad Block Management and i'm aware that this would be an issue by booting multiple images and support fallback. QSPI and eMMC sounds like a good alternative, but unfortunalty without multiboot and fallback. Could you explain what will happen if the image (lets say the kernel) in the second boot device is damaged? Will the system freeze?
Cheers
Jan