On 01/20/2015 06:47 PM, Arvid Picciani wrote: > 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?
We (Eistec) are interested in this feature as well. > - When can we meet virtually (or physically in case anyone is in Berlin)? Initially I would prefer to have a virtual meeting, but I think it would be beneficial to have a physical meeting once a task force/working group has been formed. > > 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? Another method related to the SD card solution if there is external memory available would be to download the new firmware image to external memory (NOR flash or similar) and then tell the device to reboot into a flasher/bootloader which checks the external memory for a new image and perform the device flashing before jumping into the main entry point. This way the bootloader could be kept small and placed in a reserved area of the internal flash, at least if partial erases of the internal memory are supported by the hardware. > > 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. > Have you looked at the LWM2M initiative? They have a firmware update service specified in their registry. I have not yet had time to look closer at it, though. See http://technical.openmobilealliance.org/Technical/technical-information/omna/lightweight-m2m-lwm2m-object-registry and http://technical.openmobilealliance.org/tech/profiles/LWM2M_Firmware_Update-v1_0.xml Best regards, Joakim Gebart Eistec AB www.eistec.se _______________________________________________ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
