Hi Peter,
On 01.10.2017 00:48, Peter Stuge wrote:> Nico Huber wrote:
wear leveling ring buffer sanitation phase optimizing every update Defragmentation
..
Might work?
Please don't invent a new format
Can you give an example of an existing format that might do? I have to admit, I didn't took the time yet to look at related work.
don't reinvent JFFS2 and/or UBI..
These implement wear leveling for NAND flashes, AIUI. We are talking about NOR flashes. I'm pretty sure you know the difference better than I do.
Let's make CBFS work for this, please. Reusing the existing data structure is incredibly valuable, even if it means some overhead.
There are a few obstacles to overcome and decisions to make if we want to use CBFS. First, what level of compatibility should we target? Some ideas, only some are mutually exclusive:
1. Just reuse the CBFS data structures for a new kind of entry (without implied compatibility to other entry types).
2. Handle any kind of CBFS entry in the variable storage implemen- tation that fits an erase block and can easily be moved around.
3. Handle any kind of CBFS entry in the variable storage implemen- tation. (even "complex" entries, e.g. bigger than erase block size, entries with fixed alignment or positions).
4. Always keep the variable storage in a state such that current CBFS readers succeed to read it.
5. Bloat current CBFS readers until they can handle the variable storage in any state (including fail states due to interrupted updates).
6. Always keep the variable storage in a state such that current `cbfstool` can alter a dump safely.
7. Bloat `cbfstool` until it can alter a dump safely.
I hope we can agree that 1. alone would only result in confusion and is to be avoided.
2. seems to be easily accomplished, but I don't see any benefit.
3. together with 4. or 5. would allow us to put mutable variables into the same CBFS space that we use for the coreboot stages. It implies that we could never have a per erase block header but I've tried to avoid that in my drafts anyway, so far.
I don't see how 4. and 6. could be accomplished without always keeping things in order and, thus, not having a backup in case an update fails. Maybe I miss something, could it be done?
I don't like 5. and 7. (that's why I used the word bloat). But so far the only combination where I see a win by reusing CBFS structures with- out a loss in reliability is 3. + 5. (+ optionally 7.).
Peter, please choose your preferred combination of compatibility targets (add new ones that you miss).
Nico