> On Jul 26, 2018, at 3:10 PM, marko kiiskila <[email protected]> wrote:
>
> Hi,
>
> there’s few issues with FCB which I need to fix.
>
> 1) Compressing flash sector in the middle of write.
> Currently the cycle of operation is expected to be the following:
> fcb_append() -> get offset to write data to
> flash_area_write() -> write data
> fcb_append_finish() -> writes CRC etc
>
> This is not too great if the location returned by fcb_append() gets rotated
> to be
> scratch area before fcb_append_finish() is called. Which is quite possible
> if you’re using FCB to store logs, and data comes from different tasks.
Note that this is not an issue when storing config in FCB; locking within
config module ascertains that this will not happen. But for log_fcb this
race condition exists. Which makes me lean towards not having the
write tracking inside FCB, but rather at a user of FCB. I.e. with logs it
would cancel writes where target is an area in the flash which was
erased from underneath.
>
> 2) CRC is 1 byte only. It’s ok for short config entries, but for longer things
> (log entries) is not good enough.
>
> To fix 1 I was going to add linkage to fcb_entry such that FCB can track
> of incomplete writes, and add a write routine which should be used when
> doing the write.
>
> Issue 2 is a little bit more cumbersome. I want to be able to at least
> allow backwards compatibility, where code figures out from data in
> the flash which CRC format is there. But then be able to switch to
> 16 bit CRC format as new flash areas are written. Or keep using
> the old format, because you want to do downgrade to old SW version
> if necessary.
>
> So that’s what I’m currently thinking of trying to achieve. Let me know
> if you guys have other things to take into consideration here.
