Actions
Forum Thread Details
  • State Not Answered
  • Replies 4 replies
  • Subscribers 329 subscribers
  • Views 1454 views
  • Users 0 members are here
Related

Field upgrade strategy for Zynq - using SDCARD and QSPI

Former Member

<<Cross posted on Xilinx forums for exposure>>

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 QSPI 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.



Thanks

  • 0

    Hi GK,

    I'll take a shot at answering what I can:

    1. Once PetaLinux is running from ramdisk, it no longer requires access to the primary boot area.  You can mount an SD card, and copy files from the mounted FAT32 partition to QSPI, replacing whatever is already there.  You can do this from userspace using the root login.

    2. Zynq has a feature called multi-boot, which can be enabled to allow a golden image stored in a separate non-volatile memory location away from your field upgrade image.  If the field upgrade image is corrupt, as would be the case if the system lost power during the copy, the Zynq ROM code will locate the golden image and boot from that.  This allows the system to be restored to a working state, even after a failed upgrade, at which point the upgrade can be tried again. 

    Ron

  • 0 in reply to Former Member

    Hi Ron,
    Thank you for your kind response.
    I am looking at the following strategy.

    Userspace application will untar, decrypt Upgrade file, replace BOOT.bin and image.ub using flashcp commands. Boot image header will be updated in the end after successful upgrade, so in case of any interruptions,  on a subsequent boot, ROM bootL will be forced to find the backup image and the process can be repeated.

    In this case my query is, is it enough create a new image (BOOT.bin+image.ub) and flash it as backup. I mean yes, I will change redundant UBoot env to pick up redundant kernel. But how do I instruct my redundant fsbl to pick the redundant uboot?

    Regards

  • 0

    The BOOT.BIN file contains the FSBL, bitstream and the u-boot.elf file by default, so the FSBL and u-boot are tied together in the binary.  There is no problem loading a backup boot image and not having the FSBL and u-boot associate properly.  And as you say, the u-boot environment variables should point to the correct kernel at it's MTD partition in QSPI, so no problem there either.  The only problem I see here is that you may want to have a two step procedure to validate that the new image.ub is flashed and verified first, before updating the boot.bin.  

    The reason is that if the boot.bin image fails to load properly, it will trigger the multi-boot and look for the backup.  But if it loads correctly and starts the new u-boot, which in turn retrieves a new image.ub and that image is corrupt, then the kernel boot will likely panic and multi-boot won't help you there.  As far as multi-boot is concerned, everything worked because you were able to get the processor to a bare metal program (u-boot), and everything after that is implementation-specific.

    Ron

  • 0

    Hi to all,

    altought this post is very old, I have the same issue with Petaliunx 2018.2.

    In this version there is no firmware-upgrade app to be included in rootfs.

    I re-build the solution providing an image.ub file to updated in the microzed and I transfer the image in a running petalinux.

    after flash the mtd partition with flashcp reboot the system and nothing appears: linux doesn't boot and I don't know any reason.

    Any suggestion please?

    Thank you to all