/
norpatch_README.txt
28 lines (20 loc) · 3.17 KB
/
norpatch_README.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
Some additional information on how to use "norpatch" for checking ECC errors of raw NAND dumps...
*** All credits go to "RPS" who developed/reversed the ECC algo (according to Flow Rebuilder title). ***
The algo was like forever available in Flow Rebuilder, but it was only used to create new ECCs for patched dumps. I actually don't know why there's no "checking" function. I've been using it for over a year now to validate nand dumps, cause it's a handy *additional* verification step. I've been asked many times to release this, but I didn't develop the algo, so I never did. Since the Flow Rebuilder source code is floating around anyway, I figured what the heck. Feel free to complain.. :P
It's important to understand what ECC (Error Correcting Code) is and what it does (and more importantly - what it doesn't do!):
- A PS3 NAND has a 10 byte ECC for each 512 byte sector.
- The PS3 uses the ECC to detect and correct errors (as everything with Sony it's a propriatary algo, but commonly a 10 byte ECC can correct up to 4 invalid bytes).
- RPS' implementation can only be used to detect errors, not to correct them!
Where ECC fails:
- Your flasher returned all 0xFF for a sector/page/block instead of correct data. This won't be detected by ECC, as the ECC for 512 * 0xFF = 10 * 0xFF.
- Your flasher swapped pages while dumping, e.g. page 0 is located at the offset of page 1 and vice versa. The ECC will be correct, but the dump is still invalid.
What do you do when there are ECC errors?
- ECC errors are normal and it does happen that a NAND cell loses its content. Usually the PS3 will correct the error.
- As a rule of thumb you can say that up to 10 errors per dump are a valid range. If you get significantly more than that, you should worry (in case of a bad dump, you'll usually get hundreds of errors - or no errors at all if your dump is just 0xFF's :) ).
- When there're 10 or less errors, check the location of the errors - this requires some calculation: you'll get a block number for the error, which is the physical block in your raw dump. You have to convert this physical block number to a logical offset in your merged dump generated by Flow Rebuilder. When unscrambling dumps, Flow Rebuilder will create a text file called "nand0_phy_mapping.txt" and "nand1_phy_mapping.txt". Open the file that corresponds to the dump you've checked for ECC errors (0=top, 1=bottom). First column is the physical block, second column is the logical block. Locate the physical block number reported by the ECC check, take the corresponding (decimal) logical block number and multiply it with 0x40000 (hex). The result is the offset in your merged dump. Anything from 0x00C0000 to 0x0EBFFFF (ROS 0/1) and from 0x0F00000 to 0xEFFFFFF (VFlash) can usually be ignored. For everything else you should worry.
In general:
- Always make multiple dumps and file compare them!
- ECC checks don't eliminate the need for additional validation!
- Additionally use one or all of the awesome dump validators out there! "norpatch" is not a full-fletched validator!
- I personally use BwE, especially because it will catch the 0xFF ECC issue mentioned before with its repetition check (I guess Swizzy's tool does this as well now).
-- judges