4 ms·
In addition to the other great projects mentioned, I'll throw out fwup [1] (A/B partition update, used by nerves.io) and snapcraft [2] (containerized packages,
by thom_nic 10y ago
In addition to the other great projects mentioned, I'll throw out fwup [1] (A/B partition update, used by nerves.io) and snapcraft [2] (containerized packages, not whole-OS.)
For myself, I'm comfortable with some form of A/B partition update (assuming the problem of distribution and verification is solved elsewhere) however at the very least you still have to patch or script u-boot (or your bootloader of choice) to make it smart enough to try booting the primary partition and also have some sort of canary file it can check on the next boot to validate that the partition booted successfully and e.g. made it all the way to the target runlevel. And if that check fails fall back to the secondary partition or some recovery image.
Embedded firmware updates - especially for M2M devices that are not necessarily user-facing - are sort of like changing the engine of your car while driving down the highway. It's a very tricky thing to get right. Plus if something goes wrong, it's not like you can just SSH into your server or kill that cloud instance and start a new one :)
[1] https://github.com/fhunleth/fwup https://github.com/fhunleth/fwup
[2] https://snapcraft.io/ https://snapcraft.io/
- abhirag 10y ago"Embedded firmware updates - especially for M2M devices that are not necessarily user-facing - are sort of like changing the engine of your car while driving down the highway. It's a very tricky thing to get right. Plus if something goes wrong, it's not like you can just SSH into your server or kill that cloud instance and start a new one :)" -- I worked on marking 'embedded firmware installation' process better in a previous job of mine and you described the problems involved perfectly. There was a part of the process in which communicating with the device and attaching debuggers was a major pain and I had to rely on extensive tracing to keep an eye on the process. I personally believe that the better way would be to emulate what NixOS does(https://nixos.org/~eelco/pubs/nixos-jfp-final.pdf https://nixos.org/~eelco/pubs/nixos-jfp-final.pdf). Painless rollbacks and reliable updates would help embedded development a lot and treating the state of the device as immutable is a great way of doing that.
- thom_nic 10y agoYup I did not mention nix but from what I understand it is very similar in spirit to snapcraft. Unfortunately creating an embedded linux distro leaves one with few package manager/ updater options - Debian (apt/deb, although Sid has a package for snap), debootstrap (none) or Yocto (ipk). Seems NixOS for embedded [1] has not seen much love. [1] https://nixos.org/wiki/Embedded_NixOS https://nixos.org/wiki/Embedded_NixOS