#1905 BLOC Trial-2: Field Return: flash corruption - OpenFirmware complaining of 'unknown node type 2006'.

Zarro Boogs per Child bugtracker at laptop.org
Tue Jul 10 22:46:29 EDT 2007


#1905: Field Return: flash corruption - OpenFirmware complaining of 'unknown node
type 2006'.
-----------------------+----------------------------------------------------
  Reporter:  dwmw2     |       Owner:  wad     
      Type:  defect    |      Status:  assigned
  Priority:  blocker   |   Milestone:  Trial-2 
 Component:  hardware  |     Version:          
Resolution:            |    Keywords:          
  Verified:  0         |  
-----------------------+----------------------------------------------------
Comment (by wmb at firmworks.com):

 We need to find a synthetic test case that will recreate the problem

 The problem is not in JFFS2 per se, but rather seems to occur in the
 memory buffer that is used to write blocks of data into NAND FLASH.
 Therefore, it should be possible to construct a test case that does not
 involve JFFS2 itself, thus opening up the list of people who could work on
 it.

 Suggestions for making a test case:

 1) Boot from USB and unmount the NAND FLASH so that JFFS2 is not accessing
 NAND.

 2) Using raw access to mtd0, locate an erase block that does not currently
 contain any JFFS2 data (i.e. an erased block containing all 0xff's).

 3) Fill a 2K (the NAND FLASH page size) memory buffer with pseudo-random
 data using a simple random number generator that can be reseeded to
 recreate the last sequence.  For example,

 {{{
    /* Linear congruence PRNG */
    seed = (seed * 1103515245 + 12345) & 0x7fffffff;
 }}}
 or
 {{{
    /* 32-bit maximal period Galois Linear Feedback Shift Register */
    usigned int seed;
    seed = (seed >> 1) ^ (-(signed int)(seed & 1) & 0xd0000001u); // taps
 32 31 29 1
 }}}

 4) Write the buffer to a page within the selected NAND FLASH erase block
 via the mtd0 driver.

 5) Read back the data and check it against the pseudo-random sequence
 (regenerate the sequence from the same starting seed value in case
 corruption occurs in the top-level memory buffer).  Do whatever is
 necessary to make sure that the data goes all the way out to NAND FLASH
 and is read back from there, lest internal caching affect the test
 results.

 6) Repeat with different pages in the same 128K erase block until the
 erase block is filled up.  Use different seed values for each page test.
 When the erase block is filled up, erase it and start over.

 7) Do this under different system loads, different environmental
 conditions, etc, in hopes of provoking a failure.

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



More information about the Bugs mailing list