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!

Showing results for 
Search instead for 
Did you mean: 
Visitor ganeshk
Registered: ‎10-20-2015

Field upgrade strategy for Zynq - using SDCARD and QSPI

Hello All,

I am in process of doing some evaluation with Zynq devices. My setup is


Environment - Avnet Zedboard with s25fl256s1 (32768 Kbytes) QSPI flash

Petalinux 2014.4

Vivado 2014.4


Please pardon me for my lack of understanding about Zynq's, uboot and linux, as I am(was) a primarily bare metal microcontroller firmware developer. I have started with a base project based on xapp1078 and 2014.4 tools are the lastest version supported, so persisted with them. I have been able to boot up Linux on CPU0. Next stage for me is to work out a suitable field upgrade strategy. Using flascp commands I have been able to copy BOOT.bin, image.ub to mtd0 and mtd2 on QSPU and successfully boot up from it. Field devices will always boot up using QSPI. Our upgrade strategy is to provide with a upgrade file which users will copy to sdcard and insert into device. An app running on cpu0 would be able to identify it, decrypt and untar it and use flashcp to copy new BOOT.bin and image.ub files and reboot. Now I a few questions regarding this -

1. Is it possible to replace BOOT.bin and image.ub(uboot, kernel, dev tree and rootfs) in a running system using kernel userspace? If XIP is used, I don't think this is possible. What is the ideal solution? I understand that not always bit file, kernel, and uboot will change but for simplicity sake I am assuming firmware upgrade means replacing both BOOT.bin and image.ub file.

2. Power loss during upgrade is a real issue, so currently our other linux devices use a dual firmware image solution(ping-pong). In other TI based devices, on a successful update the UBL(first stage BootL) is modified to pick the new address of UBoot. Also uboot env is changed to point to new kernel and rootfs. This change happens at the end of successful upgrade, so any issue during upgrade, the firmware will boot from the previous image.

I can use unpacking and decrypting solution from those projects. But what I have not been able to work out is a ping-pong solution using bootROM and fsbl. Currently my project uses mtd0-BOOT.bin, mtd1- env, mtd2- image.ub. Is it possible to create 3 more partitions(there is enough space on zedboard) to have the other image and instruct rom bootloader to pick say mtd3 with BOOT2.bin? As far as I have read, I don't think that's possible, but I did see a fallback golden image solution, in case of corrupted BL header. But it would fail to detect corrupted kernel or rootfs.

How could I implement a similar ping pong solution using ROM bootL and FSBL?

What I have been able to come up till now is that I may have to keep fsbl permanent not allow to be field upgradeable. Say I make a .bin file with only fsbl. If then I could modify fsbl code, to read some location and pick appropriate version of UBoot and bit file. That is acceptable.

Can experts please point out if I am thinking sane and any pitfalls in this issue?

Is there any better/easier way of doing a ping-pong firmware field upgrade?

I have found source code for fsbl, but would be great if someone could give some pointers about changes to be done and gotchas to be taken care of.

Apologise for a long post.



0 Kudos
1 Reply
Scholar milosoftware
Registered: ‎10-26-2012

Re: Field upgrade strategy for Zynq - using SDCARD and QSPI

You can update a linux system from within itself. You probably have a PC on your desk that demonstrated this ability to you already.


This means you can rewrite the flash contents from within Linux, even if the root filesystem is in there. In that case, the upgrade routine should copy the executables and libraries it needs into a RAM disk, unmount the rootfs, upgrade it, and then probably reboot. (Though it could just remount and continue...)


If you use a filesystem in flash like UBI of jffs2, you can update files in the field. These filesystems are very resilient to power out, they won't corrupt data if you pull the plug in the middle of a flash write operation. Combined with a bootloader that fetches kernel etc from that filesystem directly, you can upgrade whatever you want whenever you want.

0 Kudos