If I may throw up a ball.
I think we should only define and specify a secure OTA protocol and
leave it up to the implementation if an external flash memory is used
for saving the image or an internal. For the OTA protocol this is not
relevant and we should not limit the implementation by defining this
in the first place.
I think we should in time make two bootloaders, one that is
minimalistic and uses internal memory and one that uses external.
External could be anything from SD card to flash chip.
The OTA protocol should be able to verify the image and check its
signature. I think we need to look at the type of file supported (ELF
for example) and if partial update or modifications are supported. If
this is supported I would advice to check the Z-modem protocol since
they designed a very clever partial update mechanism that we maybe can
use too.
Paul.
Arvid Picciani <[email protected]> schreef:
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.
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
