Help needed - Serious challange with this one

[jermy]

WOW, finally we getting something

can you upload the dump with ECC ?
what configs has been done ?

[joanorsky]

i really hope your chip is been supported
because i don't know how 1024 blocks (c the pic. attached with original configurations) end up with the size of 16MB, if page size supposed to be 528
& i can't find where it (page size) can be changed

It seems to be correct... please check :


Source : http://www.datasheetlib.com/datasheet/2 ... #datasheet

WOW, finally we getting something

can you upload the dump with ECC ?
what configs has been done ?

Well... i must underline that i am a "newbie" on this stuff.. so most of these things are new to me and i might be saying things that are just stupid (so please have some patience with me ). As i can tell the ECC code is present on the initial dump (1st post)... and the code without ECC was done by fzabkar on 12th post (http://www.users.on.net/~fzabkar/temp/NOECC.rar)

[pcimage]

The ECC is not the concern right now, it's the block number info in the +16 bytes after the 512 byte data area in each 528 byte page we are after, which I can't see.

Let's see if I can find one of these chips...

[joanorsky]

The ECC is not the concern right now, it's the block number info in the +16 bytes after the 512 byte data area in each 528 byte page we are after, which I can't see.

Let's see if I can find one of these chips...

These chips are usually found on the sony's memory sticks .. i have found a few on my scavenge rampage..

[pcimage]

Can't find one of those, but found a dump from another 528 page device.

Hex dump attached starting from FAT

As you'll see, the SA data is present in the last 16 bytes, with bytes 516/517 being the block number. The FAT block has block number "00 01" as we'd expect.

Attachments

300k.rar

(250.23 KiB) Downloaded 780 times

Last edited by pcimage on May 13th, 2015, 11:31, edited 1 time in total.

[pcimage]

The next block (0x4200 on) is block "00 06" (from bytes 516/517) and we can see FAT entries for files there...

So, the blocks are out of sequence due to wear levelling.

Attachments

[fzabkar]

@pcimage, many thanks for your enlightening data. It appears that the OP's job would probably already be done if he had started it with a good dump. (I like to start my days the same way.)

I notice that the FAT16 boot sector (in your example) is located at sector 33. There are then two FATs, each spanning 31 sectors. This means that the root directory would be located at sector 96. That's on a 16KB block boundary. The boot sector's BPB is reporting a cluster size of 32 sectors, so it appears that each cluster corresponds to, and is aligned to, a single NAND block. This leads me to wonder how many formatting tools are able to align FAT (or NTFS) volumes in the same way.

As for the FTL, does this mean that the flash controller scans the block numbers on power-up and then assembles a map in RAM?

[joanorsky]

I'm gonna do the new dump on a beeprog+. Any special configuration i need to know for the dump?

Page size : 512b
Spare size : 16b
Block size : 32 pages
Number of blocks : 1024
Tension : 3.3v

... Right?

[jermy]

it seems that the programmer has these configuration already

[HaQue]

I'm gonna do the new dump on a beeprog+. Any special configuration i need to know for the dump?

Page size : 512b
Spare size : 16b
Block size : 32 pages
Number of blocks : 1024
Tension : 3.3v

... Right?

yes, but as jermy said, config exists, always use the preset if possible.

I am glad this is finally to this stage. I don't think I conveyed as good as Sean showing the idea in pictures, but in my second post on page 1:

Usually you would have bytes called spare area that holds the FTL information. The actual FTL can be tricky or impossible to see as a whole because it is mad up of both hardware (ecc engines, xor engines) and the bytes in the spare area (block numbers, page numbers, page rotations, block conditions, ecc , and more) there is a huge amount of schemes used, and DATA Recovery is performed using only a subset of these attributes of the FTL.

sometimes it can be as simple as looking at each page sequentially, or each page will have a block number and you just piece it together. Other times some info is actually stored by the OS or another special area of the chip such as in TLC chips, and putting it together is a whole lot harder.

Normally there will be some relationship of the Spare area bytes. So if you cut out each spare area bytes and put each spare area 1 after the other, you can see easily the patterns. ever SA might have the 4th and 5th byte FF FF followed by a number that you can tell increments. you can then guess that the incremented number is a page number or block number. I don't see any relationship with the bytes of this dumps SA. Franc could be right and this could be ECC. ECC looks like random data. So this means we should be looking for a translation table that maps the physical pages/blocks to the data image/images. as the TT holds the information instead of the spare area.

If you look in a hex editor, and set the bytes displayed across as the page size (normally a hex editor is 16 bytes across) then these patterns show up quite well. VNR has a bitmap view that is excellent for this work.

Putting the User Data back together should be fairly easy after dumping properly.

if you look at the last 16 bytes in seans pictures, you can easily see how a pattern would emerge after you line up all the SA's in a row

[HaQue]

after a good dump, may need to find out about the ECC if any. Possibly 3 bytes per sector.

here is some general ECC info, and I haven't looked but info specific to the system may be in the docs already previously presented in the thread.

http://www.spansion.com/support/application%20notes/types_of_ecc_used_on_flash_an.pdf
http://www.xeltek.com/nand-flash-programming

or more hardcore:
[url]tn2905_ecc_module.pdf[/url]

[joanorsky]

I have some new dumps from BeeProgPlus programmer but i believe that they are bad. I will post them in a while as soon as i get home.. but as we in Portugal usually say "my tail is down".. :'(

[joanorsky]

New dumps here:

http://www.joaocesarsilva.com/echo/new_ ... ogplus.rar

Sadly... it seems to me that these are of no help. Give it a check...

[fzabkar]

The latest dumps have the same problem. Worse still, the firmware sections are missing.

On the plus side, your latest dumps are identical, so there is some hope that there are no bit errors in the user data area.

I notice that your chip has an /SE pin that more recent flash chips do not need. I suspect that you need to ground this pin in order to be able to read the spare bytes.

Spare Area Enable (SE)

The SE input controls the access of the spare area. When SE is high, the spare area is not accessible for reading or programming. SE is recommended to be coupled to GND or Vcc and should not be toggled during reading or programming.

Furthermore, the way that the spare area is accessed in this early chip differs from later ones. ISTM that the reason that the programmer is reading the first 16 bytes of the data area instead of the spare area may be that the pointer is being incorrectly set and/or the wrong command is being used.

Attachments

[joanorsky]

I am still wondering what i am going to do next...but most probably is to find another high end programmer and make sure that these commands are in and that the SE pin is low. Ohh... what a headache...

Thank you all for helping on this..

[fzabkar]

Just isolate pin #6 from the programmer and run a wire from the IC socket or adapter to ground. If that doesn't work, then worry about the commands.

I suspect that those special commands are only required if you need to explicitly reposition the pointer. If you read the page starting from location 0, then I suspect that the pointer will automatically advance to the spare area. At the moment, because the spare area is disabled, the pointer appears to be skipping over this area and advancing to the next page.

[fzabkar]

I should add that IMHO it would be best to plug your chip adapter (a DIP type?) into a machine socket (aka turned-pin IC socket), then cut pin #6 from the IC socket so that it no longer connects to the programmer, but leave just enough of a stub so that you can solder a ground wire.

[HaQue]

This is why Sean and I have offered to read the chip. Early chips require different reading methods. I have NAND reader software from early versions that has been successful on my dedicated NAND Reader hardware. We have found that regular chip programmers don't seem to properly support most NAND chips.. Even if they say they do. Some of the pin configurations, such as needing to add VCC to other chips also isn't contained in the data sheets, but discovered by looking at the PCB. Failure to do exta sometimes makes the dump empty or very poor.

What franc has suggested could work as well, I haven't looked at the datasheet closely in this case.

[fzabkar]

@HaQue, maybe you could add a 16MB DOC to your toy collection. I see them on eBay for $20.

As for chip readers, ISTM that if you pay several $K for one of these tools, then you shouldn't have to make excuses for it. It should just work. There is a current thread where a SalvationData tool is unable to retrieve intelligible output from an ordinary SPI flash. In the past I corresponded with an MRT Lab user whose tool sent 10% of all dwords from an ordinary SPI flash to the bit bucket. Now we have what seems to be a jelly bean NAND chip that the big daddy of all DR tools can't handle. I think I'll just buy my tools from eBay.

[fzabkar]

Is NAND pin #6 grounded on the DOC PCB? If so, then that's your answer.