#1489 BLOC BTest-4: nandflash 'wipe' kills bad block table

[Zarro Boogs per Child]

#1489: nandflash 'wipe' kills bad block table
----------------------------------+-----------------------------------------
  Reporter:  dwmw2                |       Owner:  wmb at firmworks.com
      Type:  defect               |      Status:  new              
  Priority:  blocker              |   Milestone:  BTest-4          
 Component:  ofw - open firmware  |     Version:                   
Resolution:                       |    Keywords:                   
  Verified:  0                    |  
----------------------------------+-----------------------------------------
Changes (by wmb at firmworks.com):

  * verified:  => 0

Comment:

 I tried this on my preB3 with the following command sequence:

 select /nandflash
 wipe
 copy-nand u:\boot\nand406.img

 It worked perfectly.  Linux booted in the usual way with no error reports.

 I think we have this backwards - It is not that the bad block table got
 eaten, but rather that the preexisting bad block table listed a lot of
 non-bad blocks as being bad.  Here is a scenario where that can happen
 (and I have observed this scenario myself in the past):

 a) Start with 2-chip B3 and firmware that does not support the 2-chip
 parts.

 b) Use copy-nand to put an OS image on it.  That will create a BBT at the
 end of the first chip and copy the OS image into blocks on the first chip.

 c) Upgrade the firmware to a version that supports 2 chips.

 d) Open the nandflash driver with that firmware.  The firmware nandflash
 driver, which now knows about the second chip, will look for a BBT at the
 end of the second chip, and won't find it because the BBT is in the first
 chip.

 e) The firmware nandflash driver will then create a new BBT at the end of
 the second chip.  It will determine which blocks are bad by looking for
 non-ff bytes at the beginning of the OOB area of the first two pages of
 each erase block, which is the approved method for determining the factory
 bad-block information.

 f) But that will generate huge numbers of false positives, because all of
 those JFFS2 blocks that copy-nand wrote in step (b) are seen as bad, since
 their OOB area has valid ECC info, not FF bytes.  So the new BBT at the
 end of the second chip lists most of the first-chip blocks as bad.

 The solution is to use "scrub" instead of "wipe" on NAND FLASHs that have
 been "polluted" by copy-nand'ing with an old driver.

-- 
Ticket URL: <http://dev.laptop.org/ticket/1489#comment:2>
One Laptop Per Child <http://laptop.org/>