title: How to correctly nandwrite a nanddump'ed dump with oob?
body: <p>I am struggling on flashing a previous ROM dump of an embedded device in Linux. My previous dump contains oob data. I wrote it with <code>nandwrite -n -N -o /dev/mtd0 backup.bin</code>, and then take a ROM dump again.</p>
  
  <p>By comparing the old and new ROM dump, I see some un-explainable situation: the last 24 bytes of the oob (ecc bytes) of any empty blocks (filled with 0xFF) is ought to be 0xFF also, but those in the new ROM dump is filled with 0x00, causing later write failures.</p>
  
  <p>oob ought to be:</p>
  
  <pre><code>FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
  </code></pre>
  
  <p>but for <code>nandwrite</code>:</p>
  
  <pre><code>FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
  FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF
  FFFFFFFF FFFFFFFF 00000000 00000000
  00000000 00000000 00000000 00000000
  </code></pre>
  
  <p>Anyone has any idea why?</p>
  
  <hr>
  
  <p>I added a hack in the <code>nandwrite</code> code, to skip writing to NAND if the content to be written is <code>0xFF</code>, and it worked. So the problem exists when trying to write an empty page to the NAND?</p>
  
  <hr>
  
  <p><strong>ADDED:</strong></p>
  
  <p>Now I am having this problem also when writing a bootloader image. The image isn't page-aligned so <code>nandwrite</code> padded it with <code>0xFF</code>. But for pages with only <code>0xFF</code> the ecc bytes are still polluted by <code>0x00</code> just like above. Seems that my hack doesn't totally solve my problem. Anyone can help? Perhaps it could be a bug in kernel 2.6.35?</p>
  
  <p>This is my hack:</p>
  
  <pre><code>int i;
  int needwrite=0;
  for (i = 0 ; i &lt; len ; ++i){
      if(((uint8_t*)data)[i]!=0xff){
          needwrite=1;
          break;
      }
  }
  if(!needwrite)
      return 0;
  </code></pre>