Actions
Forum Thread Details
  • State Not Answered
  • Replies 3 replies
  • Subscribers 342 subscribers
  • Views 322 views
  • Users 0 members are here
Related

Avoid bricking when updating firmware

hai.bi

If I boot from QSPI, and it contains FSBL, uBoot, and Linux Kernel, I may update the Linux Kernel later (say in 5 years).  I don't have to change FSBL, or uBoot, as I could change the FPGA fabric in software.  I assume the PCB determines what MIO I use and I update Linux only because I find a bug later. 

So, if I update Linux, there is chance I could brick the device.  What are the ways so that I can recover from this?  And I don't want to use the full Xilinx software with JTAG to do this since it's inconvenient for my customers.  Here is a list I can think of but I hope to get advices on whether these are valid or not:

1. Paritition QSPI so that Linux is on a JSSF2 and it could be easier to update Linux without actually writing to the QSPI explicitly.  If new Linux doesn't work, uBoot is still working, and I could use TFPT or other ways to get a working Linux and update Linux again.

2. Boot from SD card by changing the jumper.  The only problem is that the jumper is so small, it is kind of awkward to take it off.  But it is a solution.  The SD card contains a known good Linux which at least allows me to update the Linux on QSPI.  I hope to have a button on the carrier card to allow to boot from SD.  But it doesn't seem possible.

3.  others?

Parents
  • 0

    The Multibot option for Zynq allows you to save a "golden image" of whatever you like so that if an update caused the device to fail, you can revert to the golden image to prevent the device from failing in the field.   I'd take a look at that.

    As an aside, leaving a Linux kernel in place in the field on a device exposed to the Internet for extending periods without updates is not a recommended option.  As you are aware, Linux is constantly changing and the availability of devices on the Internet makes out-of-date kernels and user space vulnerable to incursions.  Not saying you can't do it, but having a plan to automate Linux updates might not be a bad idea...

    Ron

Reply
  • 0

    The Multibot option for Zynq allows you to save a "golden image" of whatever you like so that if an update caused the device to fail, you can revert to the golden image to prevent the device from failing in the field.   I'd take a look at that.

    As an aside, leaving a Linux kernel in place in the field on a device exposed to the Internet for extending periods without updates is not a recommended option.  As you are aware, Linux is constantly changing and the availability of devices on the Internet makes out-of-date kernels and user space vulnerable to incursions.  Not saying you can't do it, but having a plan to automate Linux updates might not be a bad idea...

    Ron

Children
  • 0 in reply to Former Member

    Ron, nice to have a discussion here.


    Our devices are on the intranet of customers.  They will not expose them to internet.  When they update the firmware, they will have a personnel next to the device, and use our software to update it through Ethernet.  so I wouldn't worry about a vulnerability, but instead, I care about the stability.  I want the device to work continuously for 10 years without stop.  If a bug is found to stop Linux after 9 months, then I need to fix it. Otherwise, I will leave it alone.  I will have one application on the Linux and run it as an embedded application.  My application even allocate all memory at the beginning of launch and not dynamically allocate memory at all (unless I troubleshoot, but in that case, I can still restart the device after that).  So it is a typical industrial embedded use, not a consumer use.

  • 0 in reply to hai.bi

    OK, I'm still left wondering how much work it would be to take a deployed Linux release that's out of date by a year or more and try to backpatch it to correct a problem that is only discovered in a current release - but still affects your version.   I guess you could depoly the new release, but there could be lots of problems porting applications in that case.  I suppose it depends on how closely tied the apps are to existing interfaces that may not be standardized.   I'll leave that up to you.   :-)

    But for updating a system, the multi-boot scenario seems workable to me.  You maintain a golden image that the system reverts to on boot failure, and only overwrite that once you are sure your new image is perfect.   You can maintain multiple software and hardware images as you desire.  Let me know if you decide to go that way, or if there is something I'm missing that makes it impractical for your product.

    Ron