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