All times are UTC - 5 hours [ DST ]




Post new topic Reply to topic  [ 1 post ] 
Author Message
 Post subject: Sandisk 8GB UFD - suggestions?
PostPosted: August 26th, 2019, 7:43 
Offline

Joined: July 23rd, 2018, 2:19
Posts: 9
Location: north of the wall
Disclaimer: I also am in contact with support at Rusolut about this, but I just thought I'd see if anyone else have some input on the device that might help in the process as well.

Working with a Sandisk UFD 8GB device, no further marking that I'm having some issues with. Flash ID is 45 DE 98 A2 72 51, and decoding this info according to both Sandisk datasheets this should lead to the following (see attached pdf downloaded from some Chinese site):

0x45 - Sandisk
0xDE - 64GBit device, 3.3V
0x98 - 8LC/TLC
0xA2 - Block size 8MB(?) - (0x92 is 4MB, 0x82 is 2MB block size - so I assume 0xA2 thus is 8MB (erase) block size).
0x72 - Planes (physical): 1

Data sheet for the similar device states the structure of the device is the following
(logical) Page size: 8k+1k = 9216b
(physical) Page size: 2*(8k+1k) = 18432b
(logical) block size: (512+4) pages per block = 516*9216b = 4755456b
(physical) block size: (256+2) pages per block = 258*18432b = 4755456b
Plane size: 2084(?) blocks per plane: 2084*4755456b = 9739173888b

When trying to navigate through device while in reader it seems like the memory array layout is a bit different than stated in the datasheet (e.g. block size is a power of 2, and not 258 / 516). Ended up using:
Page size: 3*9216
Real block size: 3*9216*128
Nominal block size: 3*9216*256
Real plane size. 3*9216*128*1428
Nominal plane size: 3*9216*256*2048

Might be that other settings are the correct ones, but that's an easy fix. The bigger "problem" and what I hope maybe someone else who've been working with the same device could help with is the rest of the analysis.
For now I've found both ECC and XOR (Sandisk(9216b_8p_ecc230b_xoredSA)_c634c7_v2.xor) that is correct, so page is divided into [14b spare, 2048b data, 230b ecc]*4.

Rusolut support suggested I should set block size equal to page size and use three bytes (byte 5,4, and 7) for LBN in Marker's table (MT). If I do this I end up with a LBN list that contains two multiples for every LBN (all 14b spare area bytes except byte 6 is equal for the two duplicates - however, the data in the rest of the page is different between them). For this I did not use any pair-block in between XOR and MT.

I've tried to experiment a bit further; by analyzing the duplicate LBNs I see that byte 6 in the spare area changes between 0x00 / 0x80 and 0x40 / 0xC0 for the pairs. E.g. LBN 04C131 will have duplicates with byte 6 being 0x00 and 0x80, whereas LBN 04C132 can have duplicates with byte 6 being 0x40 and 0xC0. I've considered that maybe there could be some kind of bank-system in use, and that I maybe should use byte 6 as bank (giving me four banks due to the values being 0x00 / 0x40 / 0x80 and 0xC0). If I then apply a mask in the block filter for the bank (mask: 0xB0), I end up with two "banks", 0x00 and 0x80 (pairing LBNs with bytes (0x00 / 0x40) and (0x80 / 0xC0)) and a LBN table with a nice counter from 0x00 to 0x77e98 for both "banks".

However, this doesn't seem to be right either, so I'm curious if anyeone maybe have worked with a similar device (and Sandisk controller) and figured out a way to generate a logical image from the raw NAND dump?


Attachments:
24nm-64G-eX3-(8LC)-Data-Sheet-pkg-rev1-0.pdf [1.18 MiB]
Downloaded 22 times
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 1 post ] 

All times are UTC - 5 hours [ DST ]


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group