Actions
Forum Thread Details
  • State Not Answered
  • Replies 2 replies
  • Subscribers 367 subscribers
  • Views 253 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.

Parents
  • 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

Reply
  • 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

Children
No Data