Re: [riot-devel] Call for OTA (Over the Air Update) Task Force
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
Re: [riot-devel] Call for OTA (Over the Air Update) Task Force
Hi Ludwig, Am 22.01.2015 um 11:08 schrieb Ludwig Ortmann: >>> To recover from this point i think it's sufficient implementing an >>> simple low level broadcast receiver without cryptographic checks or >>> an network stack. Alternatively there is space needed for an third >>> firmware image. > How would adding a second flashing mechanism help with this > problem? My fear so far is that throwing more code at this problem > will only deplete memory and introduce new errors. It helps do OTA when both images are broken, but i think this feature isn't really needed. > I'd rather have a thoroughly tested and well designed implementation > in the first place > Also, what would the third image change? > This is an alternative variant when somebody needs OTA functionality when both application images are crashing. I think it's easy to implement but not really needed. Regards, Frank ___ 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
Hi Jeff, On Thu, Jan 22, 2015 at 04:00:14PM +, Katz, Jeff wrote: > Currently: > 1) New image downloaded to spare storage (external SPI NOR flash) > 2) When new image verified, relocate important functions to RAM > 3) Wipe internal flash > 4) Copy new image to internal flash > 5) Reboot > > Obviously between 3 and 4 if there is an issue, the device is a brick. In > practice, 2-3-4-5 takes place in under a few milliseconds, which is shorter > than the amount of power provided by the bulk capacitors on the input, so > it's "OK". Are you checking for an "external" power failure before starting phase 3? Otherwise the period length is irrelevant ;) Cheers, Ludwig ___ 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
Hi All, Apologies for not replying directly when received. Here are my thoughts on the OTA topic: > - Who is interested in such feature, and what is your approach to OTA? KIWI.KI is definitely interested in such a feature. > - When can we meet virtually (or physically in case anyone is in Berlin)? I am not sure about when, but KIWI.KI can provide the where, for sure. > - 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? It depends very much on the available resources which options are viable. There are situations where FOTA can be done in an unreliable way acceptably (physical access, removable storage, recovery options) and there are situations where FOTA should never, ever fail. First, you need to determine which use cases you want to fulfil. In the case of KIWI, we are currently doing FOTA "unreliably", but as reliably as possible. Currently: 1) New image downloaded to spare storage (external SPI NOR flash) 2) When new image verified, relocate important functions to RAM 3) Wipe internal flash 4) Copy new image to internal flash 5) Reboot Obviously between 3 and 4 if there is an issue, the device is a brick. In practice, 2-3-4-5 takes place in under a few milliseconds, which is shorter than the amount of power provided by the bulk capacitors on the input, so it's "OK". Our ideal process would be as follows: 1) New image downloaded to spare storage (external SPI NOR flash) 2) When new image verified (public key signing optimal, minimally md5, sha1, or other hash), reboot 3) Minimal bootloader detects new image in external flash, removes existing OS and copies new over 4) execution continues in new OS If the bootloader ever needs to be updated, it can be then updated similarly to the "Current" procedure. Of course, this situation is a bit weird: * Can't execute from external SPI flash--there are situations where you can execute directly from your storage * Large external storage, small internal storage--our micro only has 32k of flash, which isn't really enough, but we have 256mbit of external flash to play with Any situation that involves SD cards or physical access is a non-starter for us, as our devices are built deep into buildings or high on infrastructure where putting hands on the device is unlikely to be fast and sure to be expensive. > 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 Definitely > - Simple hashing (crc?) I would expect more > - Cryptographically signed OTA updates Yes. It's nearly criminal not to support this. >- Dynamic loader to support updating only parts of the binary Nice-to-have >- A common boot-loader that can chain-boot riot from different memory regions Very nice to have Other neat features I could think of are: * Zero-information updates A device can be updated without revealing identifying information (for instance, what version it currently has, or which pieces it has downloaded already) * Fail-safe bootloader Giving the bootloader the ability to recover from a bad flash or bad image, and allow the device to get a new firmware * Peer-to-peer firmware updates Out of date devices coming on to the network are fed new firmwares by their peers instead of by central * Anycast firmware updates Many devices updatable at the same time Cheers, Jeff Katz KIWI.KI GmbH Lehrterstr. 17 10557 Berlin, DE M: +49 157 377 27 989 T: +49 30 609 8383 45 F: +49 30 609 8383 99 jeff.k...@kiwi.ki Registergericht: Amtsgericht Berlin Charlottenburg, HRB 140349 B Geschäftsführer: Dr.-Ing. Christian Bogatu, Peter Dietrich; Dr.-Ing. Claudia Nagel smime.p7s Description: S/MIME cryptographic signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Memory Management
On 22.01.2015 15:45, Martine Lenders wrote: Hi Raphael, Since I am interested in the stm32f4discovery, everything should be fine? Was that a question? I guess it was… As far as its documentation goes free is not possible by now on stm32f4: https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f4/syscalls.c#L122 I'm not sure what that documentation is based on though, running tests/malloc will allocate and free all available memory just fine. However, beware of memory fragmentation. Benjamin ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Memory Management
Hello Martine, > Was that a question? I guess it was… As far as its documentation goes free is > not possible by now on stm32f4: > https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f4/syscalls.c#L122 that was indeed a question and a bit of an assumption. The previously mentioned wiki entry does suggest that malloc and free are working indeed [1]. Are there plans to implement this? I couldn’t find anything in the open issues or PRs regarding this topic. Raphael [1] https://github.com/RIOT-OS/RIOT/wiki/Static-vs-Dynamic-Memory > On Jan 22, 2015, at 3:45 PM, Martine Lenders wrote: > > Hi Raphael, > > Since I am interested in the stm32f4discovery, everything should be fine? > > Was that a question? I guess it was… As far as its documentation goes free is > not possible by now on stm32f4: > https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f4/syscalls.c#L122 > > Martine > ___ > 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
Re: [riot-devel] Memory Management
Hi Raphael, Since I am interested in the stm32f4discovery, everything should be fine? > Was that a question? I guess it was… As far as its documentation goes free is not possible by now on stm32f4: https://github.com/RIOT-OS/RIOT/blob/master/cpu/stm32f4/syscalls.c#L122 Martine ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] absolute timpanist in vtimer
Le 22 janv. 2015 13:29, "Oleg Hahm" a écrit : > > Hi Raphael! > ... > All in all, I think it's quite urgent to establish a task force for the timer > system in a similar fashion like we do for the network stack or OTA, for > example. +1 Emmanuel ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] absolute timpanist in vtimer
Hi Raphael! > I think enabling vtimer to await an absolute point in time would be useful, > something like this [1]. Otherwise you end up subtracting the current time > and adding it again in vtimer_set. I think something like this could indeed be helpful. However, I think we should try to collect all the different requirements for the timer system somewhere and think about a redesign. Not only that certain features are hard or even impossible to achieve with the current hwtimer/vtimer/RTC concept, but also the API could be improved and simplified quite a bit - not speaking about all the bugs and races in the current implementation. All in all, I think it's quite urgent to establish a task force for the timer system in a similar fashion like we do for the network stack or OTA, for example. Would you be interested to participate in such a task force and maybe start already by setting up a wiki page or similar to collect the different requirements? Cheers, Oleg -- /* * We used to try various strange things. Let's not. */ linux-2.2.16/fs/buffer.c pgpluFHOj8Nss.pgp Description: PGP signature ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Memory Management
Hi, thanks for the answers! Since I am interested in the stm32f4discovery, everything should be fine? Raphael > On Jan 22, 2015, at 11:03 AM, Ludwig Ortmann > wrote: > > Hi, > > On Thu, Jan 22, 2015 at 10:56:22AM +0100, Martine Lenders wrote: >> for the native-stuff you have to ask Ludwig for the specifics as to of why, >> but most of the hosts system's implementation of standard functions are >> wrapped. I think this was because our POSIX interface would otherwise >> colide with the system's POSIX interface. > > That's mostly correct ;) > In this particular case it's wrapped to guard against side effects of > letting an application directly call the host implementation, though. > > Cheers, Ludwig > ___ > 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
Re: [riot-devel] Call for OTA (Over the Air Update) Task Force
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 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 devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Call for OTA (Over the Air Update) Task Force
Hi :-) >> I have trouble making sense of this - could you please elaborate a >> bit? (This is what I read: "If there is an error in the firmware update >> code it might not work.") > This is what i mean. I guess that is to be expected. If the firmware update contains an error it might not work. To add something to the discussion: I think the dual-image-approach seems safe and fair enough .. BUT devices that can only hold one image due to flash-size will not be supported - a minor drawback, imho. I'm very excited about this feature :-D kind regards, Leon > ___ > 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
Re: [riot-devel] Call for OTA (Over the Air Update) Task Force
Hi Frank, On Thu, Jan 22, 2015 at 10:52:36AM +0100, Frank wrote: > Am 22.01.2015 um 10:50 schrieb Ludwig Ortmann: > > On Thu, Jan 22, 2015 at 10:20:47AM +0100, Frank wrote: > >> it's possible to brick the device when flash code crashes every time > >> when it writes a new image. Then we have an corrupt image and an non > >> working image. > > I have trouble making sense of this - could you please elaborate a > > bit? (This is what I read: "If there is an error in the firmware update > > code it might not work.") > This is what i mean. OK, but (quoting more from the original mail): > > To recover from this point i think it's sufficient implementing an > > simple low level broadcast receiver without cryptographic checks or > > an network stack. Alternatively there is space needed for an third > > firmware image. How would adding a second flashing mechanism help with this problem? My fear so far is that throwing more code at this problem will only deplete memory and introduce new errors. I'd rather have a thoroughly tested and well designed implementation in the first place ;) Also, what would the third image change? Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Memory Management
Hi, On Thu, Jan 22, 2015 at 10:56:22AM +0100, Martine Lenders wrote: > for the native-stuff you have to ask Ludwig for the specifics as to of why, > but most of the hosts system's implementation of standard functions are > wrapped. I think this was because our POSIX interface would otherwise > colide with the system's POSIX interface. That's mostly correct ;) In this particular case it's wrapped to guard against side effects of letting an application directly call the host implementation, though. Cheers, Ludwig ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Memory Management
Hi Raphael,
for the native-stuff you have to ask Ludwig for the specifics as to of why,
but most of the hosts system's implementation of standard functions are
wrapped. I think this was because our POSIX interface would otherwise
colide with the system's POSIX interface. As for the other boards I'm
refrasing only what I've been told, so please correct me if I'm wrong,
anyone: newlib provides free() for most of our ARM boards (provided sbrk()
is implemented as a syscall). For msp430 there is currently only
oneway-malloc available and for AVR I'm not sure about the implementation.
Maybe Hinnerk can shed some light on this :-).
Cheers,
Martine
2015-01-22 10:41 GMT+01:00 Hiesgen, Raphael
:
>
> Hello,
>
> I am curious as to how memory management works. Searching the code for
> "void free(" returns two implementations. One implements the function in
> the native port as a wrapper of the systems implementations (?) and the
> other does nothing (found in malloc.h in the folder oneway-malloc and
> implemented in oneway-malloc.c).
>
> Is there another implementation I have overlooked or is there no way to
> free memory on boards?
>
> Thanks
> Raphael
>
>
>
> ___
> 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
Re: [riot-devel] Memory Management
Hi Raphael,
On Thu, Jan 22, 2015 at 09:41:31AM +, Hiesgen, Raphael wrote:
> I am curious as to how memory management works. Searching the code for "void
> free(" returns two implementations. One implements the function in the native
> port as a wrapper of the systems implementations (?) and the other does
> nothing (found in malloc.h in the folder oneway-malloc and implemented in
> oneway-malloc.c).
Yes, the native "implementation" just wraps the system implementation.
> Is there another implementation I have overlooked or is there no way to free
> memory on boards?
Please have a look at
https://github.com/RIOT-OS/RIOT/wiki/Static-vs-Dynamic-Memory
Cheers, Ludwig
___
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
Hello Ludwig, Am 22.01.2015 um 10:50 schrieb Ludwig Ortmann: > Hi, > > On Thu, Jan 22, 2015 at 10:20:47AM +0100, Frank wrote: >> it's possible to brick the device when flash code crashes every time >> when it writes a new image. Then we have an corrupt image and an non >> working image. > I have trouble making sense of this - could you please elaborate a > bit? (This is what I read: "If there is an error in the firmware update > code it might not work.") This is what i mean. Frank ___ 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
Hi, On Thu, Jan 22, 2015 at 10:20:47AM +0100, Frank wrote: > it's possible to brick the device when flash code crashes every time > when it writes a new image. Then we have an corrupt image and an non > working image. I have trouble making sense of this - could you please elaborate a bit? (This is what I read: "If there is an error in the firmware update code it might not work.") Cheers, Ludwig ___ 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
Hi, 2015-01-20 18:47 GMT+01:00 Arvid Picciani : > […] > - 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 > As one of the core developers behind the new network stack I'd like to ad, that I discussed networking for OTA with Oleg informally a while ago (we basically tossed some ideas around at lunch, so nothing special). Since our current approach aims more for a general-purpose network stack (though fine-granularly configurable, but never the less "big" in terms of IoT), we came to the conclusion that a special-purpose one-threaded OTA stack as part of some bootloader could be the best approach for this. Cheers, Martine ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
[riot-devel] Memory Management
Hello,
I am curious as to how memory management works. Searching the code for "void
free(" returns two implementations. One implements the function in the native
port as a wrapper of the systems implementations (?) and the other does nothing
(found in malloc.h in the folder oneway-malloc and implemented in
oneway-malloc.c).
Is there another implementation I have overlooked or is there no way to free
memory on boards?
Thanks
Raphael
___
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
Hello Arvid, Am 21.01.2015 um 21:52 schrieb Arvid Picciani: >>> - 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. If this an requirement an possible way is to link the firmware with any possible start address. The bootloader overwrites always the oldest version and jumps to latest version after checksum check. This means only an half of flash minus boot loader size is usable for application. If you implement this the bootloader needs only do checksum checks and a logic to detect if a new flash image fails. This can be done by setting an flag after flashing which is reset when the new application runs a while successfully. The flags and an space for checksum can be integrated into startup code by leaving some bytes empty. e.g. ASM code in main jumping over 0xff bytes. When its possbile to split the flash area in varable pieces an firmware image can be larger than an half of flash size. The smaller part is for an flashing only firmware. Currenty i working on an flash configuration store. This writes data from top of flash, so flexible positions of firmware addresses are needed. I plan an function to shrink the configuration store if space is needed. > > 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? This is my first idea. I think when you plan to work with two images there is no need to implement an network stack into boot loader code but it's possible to brick the device when flash code crashes every time when it writes a new image. Then we have an corrupt image and an non working image. To recover from this point i think it's sufficient implementing an simple low level broadcast receiver without cryptographic checks or an network stack. Alternatively there is space needed for an third firmware image. >> 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? If needed you can implement three commands. 1. erase an flash page 2. write an variable block at specified address 3. copy data from one flash area to another Sending 128kb with 200kbit/second takes approximately 7 seconds time. These are 128 1k pages on an nRF51. Each page needs ~22.3ms for an erase cycle -> 3 seconds. When flash code running from flash each word is written in 46.3us -> 3 seconds for 128kb. An image update should be possible in 15-20 seconds. With byte level diff, you can only reduce the transmission time, but i don't know at the moment if 200kbit/second are reachable values. When you work with an dual boot image the flash can updated in the background while your application is working. This is my idea to protect the application update when power fails. I'm also interested on other meanings. Regards, Frank ___ devel mailing list devel@riot-os.org http://lists.riot-os.org/mailman/listinfo/devel
