Hello Arvid, Am 20.01.2015 um 18:47 schrieb Arvid Picciani: > - Who is interested in such feature, and what is your approach to OTA? i'm interested having OTA update capability. At the moment i work on integrate micro-ecc library and flash api into RIOT. These are useful things for OTA updates.
> - When can we meet virtually (or physically in case anyone is in Berlin)? I'm available only in the evening for virtual or physical meeting. > 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. This needs to load flasher code into RAM. On battery powered/buffered devices i think this is an practicable way. There are MCU like ATMEGA which cannot execure code from RAM. > - Insert SD cards with a new image and reboot I think this is unpractical by limiting designs to have an SD card slot. > - Two copies of RIOT on the same flash, with a boot loader selecting > the active one Two copies are an good idea but this needs to link an firmware for both possible start addresses. An alternative is receive an firmware image into an free area and then flash it into correct region after checking if all received correctly. > - Re-flashing only the application part of RIOT over the air while > keeping the OS part forever. > - Any relevant concepts missing here? My Idea is to have an boot loader with limited functionality. This boot loader checks an checksum(CRC,Fletcher or cryptogaphic) of flash memory. Is the checksum is correct included code is executed. If not boot loader jumps into receive mode for an limited time. An flash update can initialized by RIOT function call or by reset/power on. The code needs to detect how reset is performed and jumps to flash code imminently when MCU is reset by an wake up interrupt. If not the boot loader waits one or two seconds if update packets are received. Update packages are send by another RIOT node at lowest possible network level to reduce code size of boot loader. The node acts as proxy by receiving updates from an update service. The node has to repeat packages until they are committed by node in boot loader mode. The firmware upgrade should by encrypted and signed. To reduce code size XTEA64 (encryption) and Fletcher checksums are candidates. This can implemented optional per Board/MCU when not enough ressources are available for an second instance of AES/CRC code. The firmware can provided by an update service which knows the key of every device. The firmware is signed by an predefined key. If an device requests an upgrade the firmware is encrypted with the device key. The boot loader checks the signature before and after flashing and calculates an check sum which is checked on every boot. The update service has to know every device so its possible to send only changed flash blocks. On nRF51 MCU there are two code regions available, so its possible to protect boot loader information from RIOT Application access. I think there are more MCU's with similar functionality. I think an fresh bootloader can accept any signing key, which is stored locally. The MCU can initially flashed with an application for key generation and key exchange. An reseted boot loader needs to accept unencrypted software to recreate an key or there is a need for an asymmetric key exchange in boot loader code. I think if public key signature checking is implemented the update service and can be insecure and the encyption key is only needed if the firmware content needs to be secured. The public signature of firmware needs to be checked with first packet to avoid corrupting firmware image by external ressources. My Questions: - Choose frequency/scan for update packages - Auto update functionality - Compression - How acceptable signing keys exchanged? (as part of application firmware?) - How to reset boot loader accept any signing key? (button? or press then times reset?) > Open discussion points are wether we need: > > - Cryptographically signed OTA updates I think this needed to avoid unwanted firmware updates. But if it implemented correctly its possible to create devices with RIOT without the possibility to replace the firmware with an own version. I love to hack things with MCU so the boot loader needs an reset procedure which is accepting any signing key. The reset procedure needs to erase all non boot loader pages. The accepted singing key must be erased after cleaning all flash pages to protect any information stored into flash. > - Are HW watchdogs necessary to check if the new image boots properly? In development this is needed. But there are MCU which can't disable an watchdog after it's enabled. On other MCU the watchdog must be disabled by boot loader to avoid an endless reset.
_______________________________________________ devel mailing list [email protected] http://lists.riot-os.org/mailman/listinfo/devel
