cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
ewong3
Adventurer
Adventurer
11,265 Views
Registered: ‎11-05-2014

Updating flash out in the field

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.

0 Kudos
12 Replies
drjohnsmith
Teacher
Teacher
11,241 Views
Registered: ‎07-09-2009

is this any help

 

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

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
smarell
Community Manager
Community Manager
11,229 Views
Registered: ‎07-23-2012

Multiboot/Fallback is not supported with ES devices. Please make sure that the FPGA is production silicon and you can follow the steps from the link given by drjohnsmith.
-----------------------------------------------------------------------------------------------
Please mark the post as "Accept as solution" if the information provided answers your query/resolves your issue.

Give Kudos to a post which you think is helpful.
0 Kudos
milosoftware
Scholar
Scholar
11,228 Views
Registered: ‎10-26-2012

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?

0 Kudos
ewong3
Adventurer
Adventurer
11,205 Views
Registered: ‎11-05-2014

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

0 Kudos
milosoftware
Scholar
Scholar
11,193 Views
Registered: ‎10-26-2012

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.

0 Kudos
ewong3
Adventurer
Adventurer
11,180 Views
Registered: ‎11-05-2014

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?

 

1) FSBL

2) u-boot

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!

0 Kudos
milosoftware
Scholar
Scholar
11,170 Views
Registered: ‎10-26-2012

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)

64k Devicetree

4MB Kernel

(rest) Rootfs

 

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

0 Kudos
ewong3
Adventurer
Adventurer
11,128 Views
Registered: ‎11-05-2014

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

0 Kudos
ewong3
Adventurer
Adventurer
11,123 Views
Registered: ‎11-05-2014

Arg, just realized the bitstream partition needs to be way bigger. I'll probably make it 8MB. And just FYI, the erase block size for my flash device is 256K, so that's why the rather large partitions.
0 Kudos
milosoftware
Scholar
Scholar
9,207 Views
Registered: ‎10-26-2012

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.

0 Kudos
ewong3
Adventurer
Adventurer
9,198 Views
Registered: ‎11-05-2014

Thanks @milosoftware,

 

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?

0 Kudos
ewong3
Adventurer
Adventurer
9,167 Views
Registered: ‎11-05-2014

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.

0 Kudos