Riotboot, configuration/IDevID and native

Development
1

{can we have riotboot, and native tags?}

Hi, my goal is to have a configuration area which is preserved across flash updates (OTA). I’d like to keep an IDevID certificate there, and no platforms without any secure element, the private key there too.

I have a notion for keeping the configuration store as a CBOR indefinite map RFC 8949: Concise Binary Object Representation (CBOR) . CBOR “stop” codes are 0xFF, which is the same as unwritten flash. So one can append new/updated key values the end. This means that the cbor map reader has to read to the end of the map and return the last value. I have to check what nanocbor does here.

riotboot would maintain two pages of flash for the key/value pairs. It would maintain them with slot numbers the same way that it does for slot0/1, and would leave a pointer to the active page somewhere in ram. That’s all riotboot would do, although it would be good if it could erase the page and re-write it via DFU as an option. The actual appending/updating (and rewriting to other page when full) would all be in the main code, not in riotboot. Using CBOR for this means that we are immune to changes to structures, and gives a wide variety of types… for “free”

I’d prefer to try to make this all work in native (because I think it would be easier to debug, and to build test cases for), and native does have MTD, but it doesn’t have riotboot … yet.

@chrysn and I had a thread that started when the forum was down, but I wanted to move things here.

2

Unless riotboot is fully involved in the format of the data there, it can probably not say anything about which of the pages is active.

I think that what riotboot can and should do is allow the board (or something between the board and the application, probably it’d be the board for now) to say that an area of this or that size (usually two pages of erasable flash) are “for configuration”. We may provide tools to work with those inside RIOT, but from the bootloader separation this should suffice. (Exposing the partition via DFU etc would certainly be neat, and ease bootstrapping).

I don’t think that having this usable depends on riotboot for native; if we introduce a module for “config MTD space”, then it can have an implementation from riotboot (that allows the data to persist through upgrades), a native implementation (that just configures ./config.img as the config space) and possibly one for other bootloaders (however they arrange for that space) or for directly flashed devices (so this can be used even when no firmware updates are possible, just as an easy way to set aside two pages).