As discussed during Hack’n’Ack, let’s organize a task force to address a currently hot feature in RIOT: Over the Air Updates. In Q1 2015 the company I work for is planning to contribute that feature, so i would like to call everyone who is planning or interested in the same feature to align goals.
- Who is interested in such feature, and what is your approach to OTA?
- When can we meet virtually (or physically in case anyone is in Berlin)?
While “when” and “from which buffer” is totally application specific, there are some common Ideas how to approach OTA in the core os itself that i have collected from people so far:
- 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?
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
- Simple hashing (crc?)
- Reducing rom size
- Optimizing stacks
- Converting some statically allocated stacks to dynamic
- Define a common OTA header with at least a magic and the checksum
Open discussion points are wether we need:
Cryptographically signed OTA updates
Dynamic loader to support updating only parts of the binary
A common boot-loader that can chain-boot riot from different memory regions
Are HW watchdogs necessary to check if the new image boots properly?
Feedback on these lists as well as other input on the requirements for OTA are appreciated at this point.
I will collect responses to this mail and summarize the discussion, and/or organize a meetup.