LittleFS: correct CRC calculation #11896
Conversation
|
@kjbracey-arm, thank you for your changes. |
|
@kjbracey-arm Should this fix and your previous commit be upstreamed? littlefs |
The code I'm touching isn't actually in that upstream version - the "use Mbed CRC" code is in our version only. |
|
There's nothing actually wrong with LFS's own software CRC code - it's a tight and pretty-optimal reflected CRC32. I'd not have bothered trying to hook it up to MbedCRC in the first place, but I guess hooking it up allows code+table reuse in theory. It doesn't allow hardware acceleration though, because LFS doesn't have "start/stop" as part of its API, and often does it 1 byte at a time, which doesn't mesh well with HW acceleration. |
When using MbedCRC, init value must be non-reversed, regardless of `reflect_data` or `reflect_out` settings. This means we need to reflect the intermediate output before passing using it as the next init value. (In GCC this ends up putting in two `RBIT` instructions back-to-back, because it's implemented as assembler, so it doesn't know how to optimise. In ARMC6, `__RBIT` is implemented as an intrinsic, so adding this reflection cancels the existing reflection and makes the code smaller).
|
CI started meanwhile |
Test run: FAILEDSummary: 1 of 4 test jobs failed Failed test jobs:
|
|
CI restarted (internal error) |
Test run: SUCCESSSummary: 11 of 11 test jobs passed |
|
Preceding PR (5.15rc1 needs to be created first - soon). Otherwise this is ready. |
|
Looks good to me 👍
I agree, in practice I doubt we really get much benefit from HW acceleration here. It's theoretically possible to refactor LFS to better batch together CRC of operations (lfs_cache_crc?), but I don't think there's much interest in this as most CRC operations are heavily overshadowed by waiting for storage transactions. |
And indeed there's a danger - we've just got a giant mutex on the singleton CRC hardware, so if the storage or some other bulk thing were to start using it, anything low-latency like a radio would find itself shut out. We already have the equivalent problem with storage vs radio and SPI mutex locks, but that's been pushed aside simply by using one mutex per SPI bus. We've no solution for thread-switching singleton hardware like crypto. I can see various solutions to address that problem, but none are straightforward. Not inclined to tackle it at this time. |
|
Why 6 and not 5.15? |
Cos this is fixing a bug in #11559, which is filed for 6 because there are breaking changes (change to way 7-bit CRCs are handled, removal of special |
Description (required)
When using MbedCRC, init value must be non-reversed, regardless of
reflect_dataorreflect_outsettings. This means we need to reflect the intermediate output before using it as the next init value.(In GCC this ends up putting in two
RBITinstructions back-to-back, because it's implemented as assembler, so it doesn't know how to optimise. In ARMC6,__RBITis implemented as an intrinsic, so adding this reflection cancels the existing reflection and makes the code smaller).Summary of change (What the change is for and why)
Fixes #11879
Documentation (Details of any document updates required)
n/a
Pull request type (required)
Fixes issue caused by #11559, so depends on that.
Test results (required)
Is covered by existing tests, but they're not being run?