Understanding ONFI NAND Parameters Page

[Jared]

OK, so I'm working on a 32Gb single NAND case here which I'm thinking is a bit non-standard (as most are I realize).

The chip has no markings, but ID's as "8988244BA9"

In the VNR DB I find two different page sizes listed with this NAND: 8640 (all but one show this), and 8592 (only one shows this). However, all the ones in the DB are one or two crystal chips. The one I'm working on happens to be 4 crystals.

Looking in the ONFI Parameters it shows this:


Just doing a bit of quick math:

Data Bytes / Page 0x2000 = 8192
+
Spare Bytes / Page 0x1C0 = 256

And I arrive at 8448 bytes / page.

So is that the correct number to use, or do I also need to consider the number of ECC bits in this number?

 

[jol]

[post]5913[/post] Spare Bytes / Page 0x1C0 = 256

=448

 

[HaQue]

I have 6 chips listed for that ID when I put the number in the identifier filter on the right. I would choose one of those chips and look at the dump in the bitmap viewer. The pages should "line up" and you should clearly see the SA's all lining up as you scroll down.

I wouldn't muck about with individual config options just yet, as quite tricky.

for that chip it should be fairly standard. I would use an 8640 config with that ID. actual part number matters less. just read it and look in the bitmap, the more you get familiar with the bitmap feature, the easier you can spot things that loog right or wrong.

 

[Jared]

[post]5913[/post] Spare Bytes / Page 0x1C0 = 256

=448

Good catch! I must have typed it wrong into the calculator. So that confirms it is size 8640, and my math method was right at least. This isn't even a really case exactly, I'm just trying to learn and understand as much as I can.

Oddly I'm not seeing any spare areas in the middle of the data like in the videos. Only seeing that on the far right side. Is that just because the program is defaulted to displaying a single page size? Or does it likely have to do with the xor?

Sent from my SM-N900V using Tapatalk

 

[HaQue]

data/ spare areas can be made up in a variety of ways. can have pages like :

data|sa||data|sa||data|ecc||data|ecc||
data|ecc|data|ecc|data|ecc|data|ecc| sa |
data|data|sa||data|data|sa||

you probably have data areas joined together and all sa for the page at the end.

data areas are usually only XORed, but can have sa xor as well in less cases. datas that are xored usually looks like very uniform snow, and hex view shows no ascii strings at all. if no xor you will see ascii strings such as file headers, pdf files contents etc

 

[Jared]

I think this here is actually the solution for this chip: http://www.pc-3000flash.com/solbase/sol ... 1&lang=eng

But I'm guessing that Ace has their own naming structure for these XOR patterns. I don't see anything resembling "ID_XOR 91" in Rusolut's XOR's.

Anyone have an idea which one this is?



Looks a bit like IS916 to me, but that doesn't seem to unscramble it.

 

[HaQue]

what is the controller number? pics of both sides of pcb is helpful as well. sometimes there is bad columns that are done in controller firmware and not using chip bad column file, are you sure there is no bad columns? if you want to upload dump to drobpox, I can have a look and see if I can help understand the parts that are blocking you.

 

[Jared]

This is the controller: SM3255EN Q AA



I can PM you later with links to the dumps if you want to have a quick look. Not that I want you to waste any time on it, it's just a favor job anyway that I'm using as a test case to learn this program. There's no $$$ on this one.

There's nothing in the bitmap that looks like a bad column to me, but then again my eyes aren't very well trained to this yet I suppose.

 

[HaQue]

No Problem, send the link. Bad columns will be obvious, there will be staggered vertical lines, each the same size as a block.

 

[Jared]

No Problem, send the link. Bad columns will be obvious, there will be staggered vertical lines, each the same size as a block.

Yeah, definitely none of those. I did look for that (been reading/watching all the Rusolut documentation). I'm thinking it's just an XOR that RuSolut doesn't have yet.

I see there's a method to "extract" the key, but the documentation doesn't seem to really spell out that process well. I think I'll eventually have to hire someone to remote in and show me that trick. But, I'll probably wait till it's a paying job for that.