FE xx_dump.bb Files question

[HaQue]

Hi, To people that use SC FE regarding bb files..

I have a 32GB MicroSD Im working on, MicroSD v10 with 4x CE

4 banks, 4 dumps + 4 bb files.

01_01.dump.bb & 01_04.dump.bb are exactly the same, same MD5 even. Is this normal?

01_02.dump.bb & 01_03.dump.bb after scrolling through in a hex editor, seem all 00 00's.

I checked all soldering under microscope, and re-read the second and third banks with same result. It looks like the layout isnt being found because of still bad blocks that cant be cut on 2nd and 3rd banks.

on wire adapter there is 4x RB signals, wheras on the Monolith there is a single RB, the pinout labelled it as RB0,3 so I assume all RB signals on the chip are tied. I soldered the wire adapter RB0 to Chip RB0,3 and read the first bank, then soldered the wire adapter RB1 to Chip RB0,3 and read the second bank. Is this the correct method? I was hesitant to tie all 4 RB together on the wire adapter and do the whole device at once.

So questions are:
should .bb files be different to my result, 4 different files, and should I tie all RB on wire adapter at once to hook to Chip RB0,3?

cheers

[networkpc3000]

It no work for all chip.

[HaQue]

I know, WL chips I am talking about.
This example was 4 dumps of 4 banks on the same chip.

banks 0 & 3 bb files look normal, banks 1 & 2 are all 00's.

[fzabkar]

What are the pinouts for the adapter and the monolith?

[HaQue]

here tis

[fzabkar]

ISTM that there must be something wrong with your CE pins. I can't see any way for two banks to read exactly the same unless they share the same select pins.

Have you checked whether any of the CE pins are tied together? What happens if you connect CE0 on the adapter to each of the chip CE pins in turn, and leave the other CEs disconnected?

[HaQue]

The way I read it was to connect RB0-RB0,3 on the Microsd, read the first bank, swap to RB1-RB0,3, read second bank and so on for all four banks.

I don't know if you have used SC tools, or are familiar with reading NAND chips of this type so I will add some background info. This chip is a "WL" chip, and this means that when it reads a bank, it reads the Data into a file, say 01_01.dump, then after that reads the Bad Block table into a paired file 01_01.dump.bb.
Where nn_kk, nn=chip number, kk = bank number

4 banks, produces 8 files. There is no way for a user to read(with my tools at least) the data and bb file separately, the software reads them both one after the other with each bank. You can however read a bank separately or choose which bank in the software.

In my case, the data files are different, between the 2 banks, but the bb files are all 00's. So it could be that they have actually read out all 00's from each bank, or that it is not reading correctly and writes 00's to the file, or other.

I don't know how to verify the resulting bb file against the bb table on each bank of the chip.

[fzabkar]

I confess that I haven't used any flash tools, so thanks very much for your explanation.

I found the following tech note very useful:

NAND Flash 101: An Introduction to NAND Flash and How to Design It Into Your Next Product:
http://www.ece.umd.edu/~blj/CS-590.26/micron-tn2919.pdf

AIUI, the bad block flag is stored in the first byte of the spare area of the first page of each block. The spare area also contains the ECC bytes plus other firmware specific information. The same command (READ PAGE or RANDOM DATA READ) is used to read the data area and spare area. Therefore ISTM that, if you can correctly read the data and ECC bytes, then this means that your wiring and methodology are correct, and that you should be able read the bad block bytes in the same way.

BTW, AIUI it is electrically OK to tie the RB pins together on the adapter side, as these are inputs to the chip reader and open drain outputs from the NAND banks. However, it remains to be seen whether the software would be OK with seeing a BUSY signal on each of the 3 banks that aren't being addressed.

[HaQue]

I tied the pins together and read the chip again with the same results.

I believe the bad block file is additional to the bad block flag a block may get in general use. Reading standard NANDs does not produce a bad block file, and I believe the reader ignores them, or the layout software knows how to account for them. I think in WL Chips it is the list of bad blocks from the factory, and used to downgrade a chip from say 16Gb to 8Gb to increase yield using chips with a lot of bad blocks initially. I need to research it more but there isn't a lot of documentation aside from chip data sheets... and the software normally handles it so I haven't had to worry about it.

I am thinking this chip is faulty and the 2 middle bad block tables are inaccessible.

[fzabkar]

FWIW, I found the following document useful also:

AN1819 Bad Block Management in NAND Flash Memory:
http://beilenet.com/download/AN1819.pdf

I confess I don't know what you mean by "WL chip". Do you have an example with a datasheet?

Could we see an example of a typical dump.bb file? What are the sizes, in bytes, of the dump and dump.bb files?

[HaQue]

I actually haven't seen anywhere that says what "WL" means. I thought I had a datasheet from one of the chips but I cannot locate it. I think it may be to do with the Word Line. This document:
https://www.google.com.au/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CEkQFjAF&url=https%3A%2F%2Fwww.techinsights.com%2FuploadedFiles%2FPublic_Website%2FWebsite_Pages%2FNews_and_Events%2FNews_Room%2FNews_Room%2FNAND%2520Flash%2520Design%2520Trends.pdf&ei=foGmU92MOY6ZkAXP_4GwDg&usg=AFQjCNFd0BsdnID2FMbicPCO_FUUNj1iDw&sig2=-hT5lm3NE1MPP5OkOuw6wQ

and others use it as an abbreviation, but I am not really sure.

some chip ID's:
98 4a a9 92
98 d7 98 92 *
98 3C 98 92
98 de 98 92 *

45 de 98 92 *
45 d7 98 92 *

* denotes ones I see in flash drives a LOT


An example of a bb file is here, and it is not from the 4 bank device, but a smaller one due to size constraints.

01_01.dump.rar

example bb file

(365.3 KiB) Downloaded 455 times

this is a view of the file sizes involved (32GB Device)

[fzabkar]

ISTM that a NAND dump would consist of sequential pages (raw data + spare area), cycling through each block in turn. This would seem to be borne out by the 1GB example in one of your other threads:

viewtopic.php?t=28896&p=199344#p199344
download/file.php?id=8367&mode=view

However, the size of the main dump file in this thread seems a little strange, ie ...

9739173888 bytes = 0x244800000

If the capacity of each bank is 0x200000000 bytes, ie 8GiB, then that leaves 0x044800000 bytes for the spare area.

AISI, this allows for the following possible relationships between page size and spare area:

1KB / 137B
2KB / 274B
4KB / 548B
8KB / 1096B
16KB / 2192B

However, the ONFI spec and the following URL both suggest that such a spare area would be unusually large:

http://www.linux-mtd.infradead.org/nand ... ddata.html
http://www.onfi.org/-/media/onfi/specs/ ... 20gold.pdf
http://www.onfi.org/specifications

For example, an 8KB page size is typically associated with a spare area of 436, 448, 576, or 640 bytes.

Have I misunderstood the structure of the dump files, or is there something different about your NANDs? Do you have any page size, block size, spare area, ONFI/JEDEC parameter/ID information?

[HaQue]

The actual capacity of the Bank, chip, drive etc. is only an approximation. Even a new drive is not guaranteed to be exactly the GB it says on the tin, to the byte level.

As you mentioned, this chip has a size of 0x24480000 (9,739,173,888 - the file size).

made up of 0x1000 blocks each with a size of 0x244800 Bytes. Each block has pages of size 9216(0x2400).

The trick is finding out how the controller uses these blocks, XOR, ECC, Mix

The ONFI spec comes into it reading the chip, but that's about as far as it goes. The chips has been read successfully aside from weather or not the 2 bb files are ok or not.

Not cutting the bad blocks from the image has detrimental effect on getting a god image to recover files.

BTW, It has been a long day and I have 4 difficult cases for different reasons. I have probably botched a number of the terminologies, descriptions and such, as I rarely have to verbalise this stuff. I am not good at explaining something that is done on a follow your nose basis.

regards

[networkpc3000]

I know, WL chips I am talking about.
This example was 4 dumps of 4 banks on the same chip.

banks 0 & 3 bb files look normal, banks 1 & 2 are all 00's.

No work for all WL. Some no work. You can find answer for confirm on tools forum. It has post for mention this problem.