6

I am considering developing on the Yocto project for an embedded Linux project (an industrial application) and I have a few questions for those with experience with embedded Linux in general -- Yocto experience a bonus. Just need to get an idea of what is being commonly done in firmware updates.

I have a few requirements, that being authentication, a secure communications protocol, some type of rollback if the update failed. Also, if there is a way to gradually release the patch across the fleet of devices then that would also be interesting as I want to avoid bricked devices in the field.

How do you deploy updates/patches to field devices today – and how long did it take to develop it? Are there any other considerations I am missing?

uptime000001
  • 61
  • 3
  • In a nutshell, for _common_ devices, firmware is shipped with the Linux kernel, and the device driver validates it by whatever means it wishes before uploading it to the device. There's no reason you can't do something similar. – Michael Hampton Jul 24 '15 at 18:11
  • Thank you, Michael. Just to clarify -- I am talking about remote updates of devices that have been field-deployed. – uptime000001 Jul 24 '15 at 19:22

2 Answers2

2

You can look at Yocto's Wiki, there is a section regarding updating:

https://wiki.yoctoproject.org/wiki/System_Update

sbabic
  • 29
  • 2
  • Can you make your answer stand on its own? http://meta.stackexchange.com/questions/8231/are-answers-that-just-contain-links-elsewhere-really-good-answers – chicks Mar 01 '17 at 13:07
  • Please add the solution here and not to an external link – Orphans Mar 12 '17 at 09:30
1

Before thinking about secure communications channels and rollback mechanisms, I think you should invest some time into the following subjects, which will be much more important in the longer term:

  • Versioning: Over time you will end up with different revisions of your embedded platform, not all with the same capabilities. Your device needs to be able to check if an upgrade it has received is compatible and can be applied.

  • Plan upgrade paths: You don't know how your system looks in 5 years time, but you want your system of today to be able to accomodate a firmware you are yet going to develop. Such an upgrade may require multiple steps, which should be documented.

  • Don't forget downgrades: At some time you will introduce changes which make it impossible to downgrade. How do you want to handle them?

Here some ideas for the technical details:

  • Authentication and secure communications channel: As long as your device has a mechanism to validate an upgrade it has received, the exact properties of the communications channel get less important. That validation needs to check if the data is consistent and compatible.

  • Rollback: A straightforward mechanism can be implemented using two equal-length partitions for holding the entire OS. It is a good idea to arrange for the OS to work read-only and place and data which can change on a separate partition.

    The bootloader needs a boot-flag telling it which partition to boot. It will always try to boot from that partition first, and fall-back to the other partition if it somehow fails. That boot-flag can be stored anywhere the bootloader has access to.

    For upgrading your device, you copy the new sytem (once it has been validated) into the currently inactive partition, change the boot-flag and reboot. In the init scripts of your system you check if it booted from the expected partition. If it didn't, something went wrong and you can take appropriate measures.

Oliver
  • 5,883
  • 23
  • 32