09-04-2015 10:14 AM
I am using a Zynq 7020 on custom board. What are the some approaches to updating its firmware out in the field? I surmise that a resident bootloader must exist to read a new BOOT.BIN image (e.g., from an SD card or USB stick or over serial port) and reprogram the flash. Can the FSBL be modified to serve this function? Or is another bootloader needed since FSBL is in the BOOT.BIN image itself? Is there an example of such a bootloader available?
Also, can I have two BOOT.BIN images reside in flash and have a flag determine which one to boot? How does the Zynq determine where in flash to start booting from?
Thanks for your help.
09-05-2015 10:50 AM
09-06-2015 09:53 PM
09-06-2015 10:51 PM
Safest choice would be to use a second-stage loader, and arrange the boot choice yourself in the first stage loader.
Are you booting an OS or using bare metal?
09-08-2015 08:56 AM
Your link does help. Thanks @drjohnsmith.
@milosoftware, I am booting Linux which then loads CPU1 with a FreeRTOS binary, running in AMP configuration. The update methods described so far would replace the entire image (Linux & FreeRTOS binary) in one fell swoop. But I am also looking into how to re-flash just the CPU1 binary. I think I'd have to put the CPU1 binary in its own partition in flash (right now, it is embedded into the Linux root file system.).
09-08-2015 10:51 PM - edited 09-08-2015 10:55 PM
You could make the rootfs partition in flash writable, e.g. using UBI. That allows you to upgrade very specific packages. If you're paranoid, you could mount it "ro" at boot, and re-mount it "rw" while upgrading. u-boot also supports reading from UBI partitions, so you could everything (but the bootloader) into a single large (compressed) filesystem. Storing the FPGA bitstream in a compressed rootfs will save megabytes of flash space.
There are dozens of options for setting up your filesystem in flash. Xilinx IDEs tend to lean into "ramdisk" boots, which is my least favorite way to do it. My favorite by far is to have OpenEmbedded (or Yocto) build everything and put a package manager (opkg) on the board. That way you can quickly upgrade packages and install new ones after a build without even having to reboot it. Works in flash or SD alike. During development I often boot the boards from RAM only, by sending the kernel and rootfs via USB, and even then I put in the packager so I can install things at will.
09-09-2015 01:58 PM
Thanks @milosoftware, I'm using Yocto, so your suggestions sound very appealling. When I create the boot image for flash, this is what I'd put in it?
3) Linux Kernel
4) UBI RFS (contains FPGA bitstream and CPU1 app ELF)
Then either u-boot or Linux can program the FPGA with the bitstream? Do you create a ramdisk partition to store log files temporarily, or do you let log files just write and persist to flash?
How do you supply parameters for u-boot from flash? I've only used u-boot from SD Card so far, where a uEnv.txt file provides the parameters for u-boot.
This sounds like the answer to most of my concerns. Thank you!
09-09-2015 10:49 PM
You can use u-boot SPL as alternative for the FSBL, it's a bit smaller and faster, and doesn't raise any licensing questions.
With a normal Yocto setup, it will mount a tmpfs (ram filesystem) at boot for storing runtime data like logs and process IDs.
You can patch u-boot to use a different boot setup, or you can store the environment in a flash sector. You'll probably have to modify the u-boot defaults anyway, because the default ones are useless. If you change the location of the flash partitions, also change them in the kernel DTS. I tend to use something like the following:
64k - u-boot SPL (boot.bin, usually ~45k)
512k u-boot.img (usually ~350k)
64k u-boot environment (optional)
In Yocto, you can just add "ubi" to IMAGE_FSTYPES to create an ubi image for flash. You'll have to fill in the UBI parameters then in the machine config (or local.conf).
09-18-2015 03:33 PM
@milosoftware, wondering if I could impose on you and pick your brain a bit more.
I've decided to use this flash partition layout:
mtd0: 00040000 00040000 "qspi-fsbl" (256k)
mtd1: 00040000 00040000 "qspi-bitstream" (256k)
mtd2: 00080000 00040000 "qspi-uboot" (512k)
mtd3: 00040000 00040000 "qspi-uboot-env" (256k)
mtd4: 00040000 00040000 "qspi-device-tree" (256k)
mtd5: 00400000 00040000 "qspi-linux" (4MB)
mtd6: 06000000 00040000 "qspi-rootfs" (96MB)
I have total of 128MB flash, so I still have some flash space leftover that I'll decide what to do with later.
But in this initial attempt to get UBIFS working on Linux, I'd like to try to use the FSBL that Xilinx SDK provides (instead of uboot-spl) and allow it to load the FPGA bistream as it does now.
And I'd also like to avoid having to rebuild uboot.elf. I gather this means I'd have to write the uboot-env partition with information where the DTB, kernel and UBIFS RFS is. Do you know how to generate an image for the uboot-env partition? And would I need to rebuild uboot anyway to tell it at least about the uboot-env partition location?
Thanks for any help.
09-18-2015 03:50 PM
09-21-2015 12:54 AM
If you want to use the FSBL, you can create a boot.bin with the bitstream included in it. This will result in a ~5MB BOOT.BIN file. Write that to the first flash sectors, and that's enough. You'll need a partition big enough to contain it of course. The size of the bitstream is constant, only depends on the FPGA type, so the partition can be made to the smallest possible that still fits.
So you'd have a 5MB mtd0, then uboot and the rest.
09-21-2015 08:48 AM
How would you generate the flash image for the u-boot environment? On a SD card, I just create a uEnv.txt file. How do you create the flash equivalent?
And then would I have to modify/patch u-boot to tell it where in flash the environment is located? In Yocto, would this go in a uboot.bbappend file? Or is there a way to point u-boot to the flash partition without rebuilding it?
09-21-2015 11:40 PM
I got my answers from a meta-xilinx mailing list thread. There are #defines in u-boot configuration to specify a flash partition to grab environment from, and u-boot must be recompiled.