Re: [riot-devel] OTA meetup 11.2.2015
Hi, please join us on appear.in online. Make sure to use chrome or opera in order to receive the slide sharing. https://appear.in/riot <https://appear.in/riot> Arvid > On Feb 13, 2015, at 4:27 PM, Joël Chotard wrote: > > Hi, which is the Google hangouts address ? > Regards > Joel > > Le 11 févr. 2015 22:41, Arvid Picciani a écrit : >> >> Hi, >> >> by popular demand, we will be meeting this Friday at 19:00 at the kiwi.ki >> office >> >> KIWI.KI GmbH >> Lehrter str. 17 >> 10557 Berlin, DE >> >> as well as online over appear.in or google hangouts (whatever i can get >> working). >> >> Attached are the slides i will be presenting for about 15minutes. >> Feel free to bring your own slides or notes. Especially for topics not >> covered by me. >> >> see ya there! >> >> best, >> Arvid >> >> >> >> >> ___ >> devel mailing list >> devel@riot-os.org >> http://lists.riot-os.org/mailman/listinfo/devel > ___ > devel mailing list > devel@riot-os.org > http://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] OTA meetup 11.2.2015
Hi, by popular demand, we will be meeting this Friday at 19:00 at the kiwi.ki office KIWI.KI GmbH Lehrter str. 17 10557 Berlin, DE as well as online over appear.in or google hangouts (whatever i can get working). Attached are the slides i will be presenting for about 15minutes. Feel free to bring your own slides or notes. Especially for topics not covered by me. see ya there! best, Arvid RIOT OTA (1).pdf Description: Adobe PDF document ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Call for OTA (Over the Air Update) Task Force
Thanks everyone for the input so far, it looks like there is a decent agreement on some core concepts, and there is a strong interest to contribute them. I would like to propose to continue with a virtual meeting, to: - present a summary(!) of the use cases and requirements posted on the ML - break them down into layers (such as bootloader, flash, etc) - for each of those layers, get a rough idea about what exists already today, or what we can do to help create them. Since this is a fairly industry-heavy crowd, i would suggest having the meeting during central european work hours for 2 hours. http://doodle.com/mtzr2s9fbdx72sun I will read all the comments on this doodle and try to adjust accordingly, so please also post your preferred time of the day. best, Arvid ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Call for OTA (Over the Air Update) Task Force
Thanks for your input Frank, > 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. This is great! Indeed i expect that these are the parts everyone will want. Keep me updated on both MRs. > I'm available only in the evening for virtual or physical meeting. noted. I’m guessing many will have that preference. >> - Simply over-writing RIOT in flash with a new copy, by keeping the flasher >> code external. > This needs to load flasher code into RAM. As far as i understood the idea, it would be that the flasher also is on the flash itself. It sounds very similar to what you’re proposing later. >> - 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. The requirement here was to not have a critical moment where removing power will corrupt the main image. > My Idea is [..] > boot loader checks an checksum of flash memory. Is the checksum is correct > included code is executed. If not boot loader jumps into receive mode for an > limited time. [..] Sounds compatible to all other approaches so far, if you scratch “receive mode” and “flash from [insert preferred method of obtaining a buffer]”. Is it correct that in your case you would implement a network stack in the boot loader? > The update service has to know every device so its possible to send only > changed flash blocks. We are talking about byte-level diff here right, so you don’t need a way to flash RIOT and app individually? > 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?) These sound very much like application specific settings. > >> Open discussion points are wether we need: >> >> - Cryptographically signed OTA updates > I think this needed to avoid unwanted firmware updates. ok, so what i’m thinking here, assuming the bootloader method is agreed on, are these steps: 1. bootreason=upgrade make the bootloader stop due to either “bootreason upgrade” or optionally from a failed main code checksum 2. download some app specific method to obtain a buffer with the new image, for example: - in your case over network into ram - a second scratch flash region that isnt meant to be booted, just downloaded to - external storage, some other offline ways - any de-compression method goes here as well 3. integrity check the new image with - some RIOT specific header with magic - some checksum - signature, which i see as a separate framework here, that can be linked into the bootloader if needed 4. flashing burn the new image to main location, - possibly relocate addresses? is the two-system approach still needed if the new image can just be written to flash then copied over in the bootloader? - note that the bootloader cannot be overwritten ever. I don’t know if anyone will need that? In Franks case how do you update a broken cipher? 5. bootreason=normal reboot and set boot reason back to normal would this as a rough framework address your use case? It would also work for some of the other proposals, while not for all of them. At this point i’d really like more people to jump in here and see if their use case is represented. best, Arvid ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Call for OTA (Over the Air Update) Task Force
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 devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
