tree dc14244277b56cab6e64ec6c1b2cb439e5715c7a
parent 80807183802cecd94b05999ffeac376516a25b7b
author Avery Pennarun <apenwarr@gmail.com> 1394787520 -0400
committer Avery Pennarun <apenwarr@gmail.com> 1394787520 -0400

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