Thank you very much for all your advice, especially for Nico, Felix, Peter


Melissa Yi

BIOS Lead Engineer
Celestica(Shanghai) R&D Center, China

Solid Partners, Flexible Solutions

2017-10-02 4:22 GMT+08:00 Felix Held <>:
Hi Nico!

The question I have here is what to do if there is more than one valid
entry. Just using the first one introduces a bit of undetermined
behavior (block order in the flash might be different after
No, always choosing the first would be determined behavior. In case we
keep things in order it's also the better choice when it comes to sear-
ching the current, valid entry (we'd have to always search the whole
used space for a newer version otherwise). I'd treat it like this: If
the old version wasn't invalidated, the update didn't finish. So we can
ignore the new version.
I was assuming the ring buffer case here where the first entry in the raw flash address space doesn't have to be the oldest one.

So either use some counter (beware of overflows!) on
either the flash erase block (small overhead and rather efficient) or
the entry (full region has to be either cached or read every time and
needs more bytes than the counter per erase block) or accept the
possibility of undetermined behavior (IMHO not a good idea).
I'm not sure how to use a per erase-block counter? When would it update?
we could only do that on every erase. A per variable counter might be
useful, but I still hope it will work without.
I was thinking of putting a number in the first word of a block. Every time a new block is allocated, this value is written once. The value is the highest number already used plus 1. Also beware of wraparounds there.

Might be done in a sanitation phase before each write. But if we define
the first entry to be the valid one, we probably don't need it. Update:
I didn't come around in my scheme below... maybe we should make the
update in three steps: tag for update, insert new value, invalidate.
This way we would only have to search for duplicates for valid entries
tagged for update.
Good idea.

Haven't really looked at and thought about your defragmentation phase idea; maybe I'll comment on that next week.