<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(34, 34, 34); font-family: arial, sans-serif; font-size: 13px; background-color: rgb(255, 255, 255);" class="">As discussed during Hack'n'Ack, let’s organize a task force to address a currently hot feature in RIOT: Over the Air Updates.</div><div class="">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.</div><div class=""><br class=""></div><div class="">- Who is interested in such feature, and what is your approach to OTA?</div><div class="">- When can we meet virtually (or physically in case anyone is in Berlin)?</div><div class=""><br class=""></div><div class="">While “when” and “from which buffer” is totally application specific, there are some</div><div class="">common Ideas how to approach OTA in the core os itself that i have collected from people so far:</div><div class=""><br class=""></div><div class="">- Simply over-writing RIOT in flash with a new copy, by keeping the flasher code external.</div><div class="">- Insert SD cards with a new image and reboot</div><div class="">- Two copies of RIOT on the same flash, with a boot loader selecting the active one</div><div class="">- Re-flashing only the application part of RIOT over the air while keeping the OS part forever.</div><div class="">- Any relevant concepts missing here?</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">- The ability to flash memory regions from a buffer</div><div class="">- Simple hashing (crc?)</div><div class="">- Reducing rom size</div><div class="">    - Optimizing stacks</div><div class="">    - Converting some statically allocated stacks to dynamic</div><div class="">- Define a common OTA header with at least a magic and the checksum</div><div class=""><br class=""></div><div class="">Open discussion points are wether we need:</div><div class=""><br class=""></div><div class="">- Cryptographically signed OTA updates</div><div class="">- Dynamic loader to support updating only parts of the binary</div><div class="">- A common boot-loader that can chain-boot riot from different memory regions</div><div class=""><div class="">- Are HW watchdogs necessary to check if the new image boots properly?</div></div><div class=""><br class=""></div><div class="">Feedback on these lists as well as other input on the requirements for OTA are appreciated at this point.</div><div class=""><br class=""></div><div class="">I will collect responses to this mail and summarize the discussion, and/or organize a meetup.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>