How can I determine if NAND blocks are good blocks?

Question

I'm trying to rescue some data from our hardware. On the board I have a pair of Samsung k9f4g08u0d NAND chips. Each chip has been dumped to include every block, including the spare areas. If I invert every byte on the dumps and interleave both chips (such that the output is chipA[0],chipB[0],chipA[1],chipB[1] ... etc) I can see that there is ascii text throughout the dump. Based on the data sheets for 1 chip I know the following:

• Blocks: 4096 per device
• Pages: 64 per block
• Page Size: (2K data + 64 spare) = 2112 bytes

But because the chips are interleaved together there are actually (4K data + 128 spare) = 4224 bytes of data per page.

The spare area is Adjacent, rather than separate, so each section of 512 bytes of data in a page is immediately followed by 16 bytes of spare data (or out-of-band: OOB).

Adjacent layout:
+-----+----+-----+----+-----+----+-----+----+-----+----+-----+----+-----+----+-----+----+
| 512 | 16 | 512 | 16 | 512 | 16 | 512 | 16 | 512 | 16 | 512 | 16 | 512 | 16 | 512 | 16 |
+--^--+-+--+--^--+-+--+--^--+-+--+--^--+-+--+--^--+-+--+--^--+-+--+--^--+-+--+--^--+-+--+
   |    |     |    |     |    |     |    |     |    |     |    |     |    |     |    |
   +----+     +----+     +----+     +----+     +----+     +----+     +----+     +----+

Separate layout:
+-----+-----+-----+-----+-----+-----+-----+-----+----+----+----+----+----+----+----+----+
| 512 | 512 | 512 | 512 | 512 | 512 | 512 | 512 | 16 | 16 | 16 | 16 | 16 | 16 | 16 | 16 |
+--^--+--^--+--^--+--^--+--^--+--^--+--^--+--^--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+-+--+
   |     |     |     |     |     |     |     |    |    |    |    |    |    |    |    |
   +----------------------------------------------+    |    |    |    |    |    |    |
         |     |     |     |     |     |     |         |    |    |    |    |    |    |
         +---------------------------------------------+    |    |    |    |    |    |
               |     |     |     |     |     |              |    |    |    |    |    |
               +--------------------------------------------+    |    |    |    |    |
                     |     |     |     |     |                   |    |    |    |    |
                     +-------------------------------------------+    |    |    |    |
                           |     |     |     |                        |    |    |    |
                           +------------------------------------------+    |    |    |
                                 |     |     |                             |    |    |
                                 +-----------------------------------------+    |    |
                                       |     |                                  |    |
                                       +----------------------------------------+    |
                                             |                                       |
                                             +---------------------------------------+

When only analyzing the spare area, I can see the first 3 bytes seem to increment. I think the first two bytes are the block number and I believe the 3rd byte is the page number. After the "page number" value is 0x3F it resets to 0x00 and the "block number" increments. I know nothing about what the remaining 13 bytes are but I assume some, if not all, are ECC bytes.

The problem is there are some blocks that appear multiple times in the dump. For example, there are three sections with "block number" of 0x2C47 and I know this is probably because of wear leveling with NAND; however, I don't know how to read the pages/blocks that are good so I can mount/extract it. It seems to follow no standard, and believe me - I have searched a lot haha. The system was running QNX6.

Answer 1

I don't know if it applies exactly but the following document from QNX suggests that:

• spare is made up of "sequence #", "file ID", "offset", "CRC" and "ECC"
• there are special blocks that contains wear-levelling information such as bad blocks, erase count and file system hierarchy

Thus it is possible the information you are looking for is not in the spare area but there is a dedicated block. This page suggests that could be the ETFS filesystem which is transaction based.