3 ms·

Using ECC is very strange in this context. eMMC storage already provides for data correctness (and wear leveling of flash). If flash is corrupted to a point whe

Using ECC is very strange in this context. eMMC storage already provides for data correctness (and wear leveling of flash). If flash is corrupted to a point where internal error correction cannot compensate for it, eMMC will return no data, simply returning an error. This means that the additional level of error correction that they added will never ever be used. Perhaps earlier revisions of this used raw NAND? Either that, or somebody got overzealous without thinking through.

mkj 5y ago
Is the internal error correction done on the eMMC module? Perhaps they don't trust that, or are being wary of bit errors on the data lines. It seems like a fair bit of effort for a device like this - I wonder if the same u-boot codebase is used on devices in space which have higher reliability requirements.
- dmitrygr 5y ago
  The spec is quite clear. Read shall either produce the same data as was written or return an error. I haven't ever seen an eMMC device that didn't comply with this part of the spec given how obviously bad that would end.
  - ec109685 5y ago
    Couldn’t a glitch happen between the rMMC and the SoC?
    - dmitrygr 5y ago
      It is equally likely to happen during other parts of the process. The colonel is only a few megabytes. The file system is much larger and read many times. And then what?
sgtnoodle 5y ago
Maybe they're worried about bit flips before the data gets to emmc? They probably aren't doing it, but you could always interleave the data across the emmc blocks. A lost emmc block would therefore corrupt single-digit bytes across many ECC'ed blocks, rather than many bytes within a couple ECC'd blocks. 32 bytes of Reed Solomon should be able to correct up to 16 bytes of corruption. CDs do the same trick to be robust to scratches.
- dmitrygr 5y ago
  Except they are not doing that
mlindner 5y ago
If I had to guess, it's likely shared code from SpaceX's other projects like Falcon 9, Dragon, and the Starlink satellites themselves, where bit flips can be much more common.

mkj 5y ago

Is the internal error correction done on the eMMC module? Perhaps they don't trust that, or are being wary of bit errors on the data lines. It seems like a fair bit of effort for a device like this - I wonder if the same u-boot codebase is used on devices in space which have higher reliability requirements.

dmitrygr 5y ago
The spec is quite clear. Read shall either produce the same data as was written or return an error. I haven't ever seen an eMMC device that didn't comply with this part of the spec given how obviously bad that would end.
- ec109685 5y ago
  Couldn’t a glitch happen between the rMMC and the SoC?
  - dmitrygr 5y ago
    It is equally likely to happen during other parts of the process. The colonel is only a few megabytes. The file system is much larger and read many times. And then what?

sgtnoodle 5y ago

Maybe they're worried about bit flips before the data gets to emmc? They probably aren't doing it, but you could always interleave the data across the emmc blocks. A lost emmc block would therefore corrupt single-digit bytes across many ECC'ed blocks, rather than many bytes within a couple ECC'd blocks. 32 bytes of Reed Solomon should be able to correct up to 16 bytes of corruption. CDs do the same trick to be robust to scratches.

dmitrygr 5y ago
Except they are not doing that

mlindner 5y ago

If I had to guess, it's likely shared code from SpaceX's other projects like Falcon 9, Dragon, and the Starlink satellites themselves, where bit flips can be much more common.