Re-enable bad block table.
Here's what happened last time I was here:
- My actual problem was if a block was ever written with bad or incompatible
ECC (like from a misconfigured uboot or barebox, or using soft ECC on
one software version and mindspeed HW ECC on another software version),
there would be an unrecoverable HW ECC error. That problem put the
HW ECC engine into a bad state and caused spurious HW ECC errors until
the next reboot. I didn't know this.
- That led me to not trust the HW ECC engine, so the plan was to switch to
soft ECC while waiting for mindspeed to explain what was going on.
- Switching to soft ECC revealed that the OOB format is totally different
between hard and soft ECC engines. This included the BBT block, which
was invalidated by the switch, so the kernel rescanned for bad blocks.
This revealed, in turn, that the HW ECC engine moves the OOB around
in such a way that the manufacturer-provided bad block indicators are
suddenly in the middle of what is now the data section and vice
versa. All put together, this meant that the kernel generated a
new BBT that was filled with junk.
- To fix this I moved a few things around to not fail in this way.
Basically I removed several mindspeed hacks that tried to make the above
problem not happen in HW ECC mode. The changes made everything work right
with soft ECC but turned out to break the HW ECC.
- We eventually got all that straight and switched to HW ECC (and promised
to never write OOB in the wrong format so we didn't crash the ECC engine).
Then later, mindspeed provided a fix for the HW ECC engine crash also.
- But now we knew that in HW ECC mode, the kernel reads the badblock
indicator from a lying location in each eraseblock; it would fail to
create the BBT correctly (basically, manufacturer-provided badblocks would
be ignored), and you only get one chance to create the BBT (because the
kernel never re-scans the flash once it has a valid BBT). What you need
to do is create the BBT in manufacturing. But we didn't have that
going yet, so to try to be safe, we disabled the BBT altogether for now.
The plan was to populate it later and then re-enable it in the kernel.
- That plan didn't work out, because using the flash with HW ECC fills
all the non-bad blocks with data in the badblock indicator section (see
above), so that actual badblocks are indistinguishable. Data lost
forever, oops.
- Just to make it worse, the newer mindspeed SDK got merged in and forced
NAND_BBT_USE_FLASH, which causes it to write a fresh BBT on every boot,
despite the fact that it wasn't ever reading it back in. This causes
extra wear on exactly the blocks that you can't afford to go bad.
- Now the disaster: the kernel does a scan for badblock indicators with all
ECC (hard or soft) *disabled*. This is necessary because a bad block will
of course not have valid ECC. But the flip side is a *good* block, on MLC
NAND, might have some bits that randomly flip back and forth. ECC would
have fixed that up, but it's off. If you're extra unlucky, some blocks'
flakey bits will be the ones containing the badblock indicator (which is
not in the manufacturer's location, so it's not even useful). This means
that from one boot to the next, the badblock scan would give a slightly
different set of bad blocks. (This means that even with BBT enabled,
initial BBT creation has a pretty good chance of marking non-bad blocks as
bad, sigh.)
- ubiformat carefully avoids overwriting known bad blocks. So if you
ubiformat the flash one day, it might write sequence number A to all the
blocks. Then another day, a block is temporarily marked accidentally bad
(ECC disabled during badblock scan), and we ubiformat again, which skips
the flakey block. Then the next day, we decide the block isn't bad
anymore. UBI gets confused because there is a perfectly good block (UBI
header has valid CRC) but the old sequence number (since we didn't rewrite
it). UBI decides it's broken and aborts. With a BBT (unless the BBT
gets corrupted and lost) a block can never be un-marked bad, so this
never happens.
Conclusion
- The short version is let's turn the BBT back on.
- The longer version is that the badblock scan is still broken; even on a
fresh device I'm pretty sure it won't detect the real set of bad blocks.
We need to do it correctly in barebox by reading the correct bytes
from the correct place (ie. the non-rearranged OOB area that soft ECC
would use) and then write a BBT in the correct format (ie. the rearranged
block format that HW ECC would use).
- There's a slight risk that if a flash chip arrives from the factory with
any data on it other than badblock indicators, we will interpret that
as a very large number of badblocks and everything will go to heck.
I think we're okay because we probably erase all the flash during
manufacturing, and/or it comes pre-erased. This will be fixed entirely
when we start writing a proper BBT at the factory.
Now let us never speak of this again.
Change-Id: I131efefb593ad4bc99cc3622179937d924a6f81e
1 file changed
