Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 357 subscribers
  • Views 234 views
  • Users 0 members are here
Related

Customer Zedboard firmware updates without Xilinx tools

Former Member

I'm currently running a Zedboard with bare-metal code in QSPI flash, programmed from the SDK. Once we ship systems to the customer, we'd like to be able to have them update in the field, as simply as possible.

The primary interface is Ethernet for the application (we use lwIP), but the J17 USB connector is theoretically also available to the customer.

It seems that any solution that involves reprogramming QSPI flash over J17 (USB-JTAG) will involve Xilinx tools -- the Lab Tools at a minimum. We consider this too much of a burden for technologically unsophisticated customers.

One option would be to program a fairly complicated update routine in our application that receives new firmware over Ethernet and then programs the QSPI. This seems doable, but may be a lot of work.

A second option would be to ship the customer an SD card containing Linux plus new firmware; the customer would change the boot jumpers to SD card mode, and from then on the SD card code would handle everything automatically, presumably using simple Linux commands to program the QSPI. Then the customer would reset the jumpers to QSPI boot mode. The downside of this approach is that the customer would have to open the box for access to the SD card and jumpers, but conceptually it seems quick to implement.

Have I missed another alternative? Is there a way to program QSPI over USB/JTAG that doesn't involve Xilinx tools? Thanks for any input.

  • 0

    Hi there,

    Unfortunately, I think you hit all the methods that I am aware.  Anything else is too invasive - if you do not really even want the customer opening the product up.

    I think that putting the effort in to create something to load the firmware over Ethernet is going to be the most hands-off for customers.  One issue to consider, those customers that already have a product might require the SDCard upgrade just to get to the point of being able to load over Ethernet.

    I will offer from my experience, since this is such a low level of hardware/firmware, it is unlikely that the effort put in will be in vein with future products, as the protocols used at that level do not typically change.  Meaning that routine/mechanism you come up with will likely be able to be re-used for a long time.

    Some other things to consider:
    -Check-sum to validate data received
    -TFTP to get the update
    -How do you trigger a client to update? Manual?  Time Based?
    -What happens if something does go wrong (be it with SD or downloaded)?
    -Ensure your customer is informed before gathering information, but as part of checking for updates consider status tracking / error reporting. 

    --Dan

  • 0

    If you don't want to go all the way to Linux, you could take advantage of the features of u-boot, which includes commands to program the serial flash.   Have you looked at the multi-boot setup for Zynq devices at all?  If you are upgrading firmware remotely, it's always nice to be able to drop back to a golden image if something goes wrong in the transfer.  Under Linux, you could possibly use USB/OTG as a secondary boot source as opposed to a new SD card.  Unfortunately, if your system has no way to enter a "firmware upgrade" mode, I don't really see any way around an intrusive update that will force your customers to open the box up and change the boot mode manually (or swap out an SD card).   However, as Dan points out going forward you can certainly improve on this scenario if you include a method for remote updates in your next distribution.

    Remote updates for products with a long lifecycle is something that needs to be built into products prior to release.  This is one reason that many designers rely on infrastructure provided by an underlying OS such as Linux to provide additional capabilities rather than building complex update mechanisms into each product.   We are currently working with Wind River to provide such an update mechanism as part of the basic package, which will hopefully address this problem for many products going forward.  Unfortunately, that doesn't help you at this point, but it is something you will be hearing about in the coming months.

    Ron