Hi All,
Apologies for not replying directly when received. Here are my thoughts on the OTA topic:
- Who is interested in such feature, and what is your approach to OTA?
KIWI.KI is definitely interested in such a feature.
- When can we meet virtually (or physically in case anyone is in Berlin)?
I am not sure about when, but KIWI.KI can provide the where, for sure.
- Simply over-writing RIOT in flash with a new copy, by keeping the
flasher code external.
- Insert SD cards with a new image and reboot - Two copies of RIOT on the same flash, with a boot loader selecting the
active one
- Re-flashing only the application part of RIOT over the air while keeping
the OS part forever.
- Any relevant concepts missing here?
It depends very much on the available resources which options are viable. There are situations where FOTA can be done in an unreliable way acceptably (physical access, removable storage, recovery options) and there are situations where FOTA should never, ever fail. First, you need to determine which use cases you want to fulfil. In the case of KIWI, we are currently doing FOTA "unreliably", but as reliably as possible.
Currently: 1) New image downloaded to spare storage (external SPI NOR flash) 2) When new image verified, relocate important functions to RAM 3) Wipe internal flash 4) Copy new image to internal flash 5) Reboot
Obviously between 3 and 4 if there is an issue, the device is a brick. In practice, 2-3-4-5 takes place in under a few milliseconds, which is shorter than the amount of power provided by the bulk capacitors on the input, so it's "OK".
Our ideal process would be as follows: 1) New image downloaded to spare storage (external SPI NOR flash) 2) When new image verified (public key signing optimal, minimally md5, sha1, or other hash), reboot 3) Minimal bootloader detects new image in external flash, removes existing OS and copies new over 4) execution continues in new OS
If the bootloader ever needs to be updated, it can be then updated similarly to the "Current" procedure.
Of course, this situation is a bit weird: * Can't execute from external SPI flash--there are situations where you can execute directly from your storage * Large external storage, small internal storage--our micro only has 32k of flash, which isn't really enough, but we have 256mbit of external flash to play with
Any situation that involves SD cards or physical access is a non-starter for us, as our devices are built deep into buildings or high on infrastructure where putting hands on the device is unlikely to be fast and sure to be expensive.
While I do have a favorite approach, the goal of a first virtual or
physical meeting would be to figure out a common ground here, so we can focus on implementing one set of standard features into the base OS. Independent from the actual OTA approach, these are the core features that we appear to need from RIOT so far.
- The ability to flash memory regions from a buffer
Definitely
- Simple hashing (crc?)
I would expect more
- Cryptographically signed OTA updates
Yes. It's nearly criminal not to support this.
- Dynamic loader to support updating only parts of the binary
Nice-to-have
- A common boot-loader that can chain-boot riot from different memory
regions Very nice to have
Other neat features I could think of are: * Zero-information updates A device can be updated without revealing identifying information (for instance, what version it currently has, or which pieces it has downloaded already)
* Fail-safe bootloader Giving the bootloader the ability to recover from a bad flash or bad image, and allow the device to get a new firmware
* Peer-to-peer firmware updates Out of date devices coming on to the network are fed new firmwares by their peers instead of by central
* Anycast firmware updates Many devices updatable at the same time
Cheers, Jeff Katz
KIWI.KI GmbH Lehrterstr. 17 10557 Berlin, DE
M: +49 157 377 27 989 T: +49 30 609 8383 45 F: +49 30 609 8383 99
jeff.katz@kiwi.ki
Registergericht: Amtsgericht Berlin Charlottenburg, HRB 140349 B Geschäftsführer: Dr.-Ing. Christian Bogatu, Peter Dietrich; Dr.-Ing. Claudia Nagel