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 [email protected] http://lists.riot-os.org/mailman/listinfo/devel
