Editing Talk:Flash

Jump to navigation Jump to search
Warning: You are not logged in. Your IP address will be publicly visible if you make any edits. If you log in or create an account, your edits will be attributed to your username, along with other benefits.

The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then publish the changes below to finish undoing the edit.

Latest revision Your text
Line 1: Line 1:
[[Category:Software]]
= List of files on NOR Flash (OLD/historic) =
= List of files on NOR Flash (OLD/historic) =
'''Note: <span style="color:red!important;">this is the old table that defyboy made<!--// and kept here for crossreference/backup/historic reasons - don't delete!//-->, a more current one with absolute values and for all firmware versions is on the [[Flash|Flash mainpage]]</span>'''
'''Note: <span style="background-color:white; color:red;">this is the old table that defyboy made<!--// and kept here for crossreference/backup/historic reasons - don't delete!//-->, a more current one with absolute values and for all firmware versions is on the [[Flash|Flash mainpage]]</span>'''


The following is a list of files stored in NOR Flash
The following is a list of files stored in NOR Flash
Line 224: Line 226:
'''remarks:'''
'''remarks:'''


* NAND dumps are 239MB because HV masks bootldr, see [[Hardware_flashing#Difference_between_hardware_dumps_and_software_dumps | Difference between hardware dumps and software dumps]]
* NAND dumps are 239MB because HV masks bootldr, see [http://www.ps3devwiki.com/index.php?title=Hardware_flashing#Difference_between_hardware_dumps_and_software_dumps Hardware flashing #Difference between hardware dumps and software dumps]
* trying to read beyond 0xEFC0000-0xFFFFFFF on NAND systems (a region filled with FF's on consoles without OtherOS) results in panic
* trying to read beyond 0xEFC0000-0xFFFFFFF on NAND systems (a region filled with FF's on consoles without OtherOS) results in panic


Line 1,159: Line 1,161:
== NAND reference (bluemimmo) ==
== NAND reference (bluemimmo) ==
CECHA-06/COK-001 with 3.60 OFW
CECHA-06/COK-001 with 3.60 OFW
=== VTRM ===
<pre>
  Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
 
  00D80000  53 43 45 49 56 54 52 4D 00 00 00 00 00 00 00 A8  SCEIVTRM.......¨
  00D80010  00 00 00 00 00 E8 02 00 00 00 00 00 00 00 00 28  .....è.........(
  00D80020  00 00 00 00 56 54 52 4D 00 00 00 00 00 00 00 04  ....VTRM........
  00D80030  DD 8F ED 9A 82 76 B5 2C 2A 99 A2 ED E3 AF B8 4E  Ý.íš‚vµ,*™¢í㯸N
  00D80040  F9 F6 0F CE 00 00 00 00 00 00 00 00 00 E8 27 20  ùö.Î.........è'
  00D80050  00 00 00 00 00 00 00 60 00 00 00 00 00 00 09 20  .......`.......
  00D80060  04 00 00 00 02 00 00 05 10 70 00 05 FF 00 00 01  .........p..ÿ...
  00D80070  9D 2B 1C B4 04 09 59 5C 7B 6A A6 F6 B4 BB A6 FF  .+.´..Y\{j¦ö´»¦ÿ
  00D80080  CA C2 B0 E9 34 3E 39 3C F4 1D 00 E8 B5 42 89 D7  Ê°é4>9<ô..èµB‰×
  00D80090  C5 12 67 F3 A2 DD 9B 5E AF A1 FE DB 19 27 C9 CB  Å.gó¢Ý›^¯¡þÛ.'ÉË
  00D800A0  4F DE D5 CF 7A B2 C2 7B 8C 44 BE 99 54 DB 99 93  OÞÕÏz²Â{ŒD¾™TÛ™“
  00D800B0  00 00 00 00 00 00 00 00 FF FF FF FF FF FF FF FF  ........ÿÿÿÿÿÿÿÿ
  00D800C0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  00D800D0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  00D800E0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
  00D800F0  FF FF FF FF FF FF FF FF 00 00 00 00 00 EB E4 8C  ÿÿÿÿÿÿÿÿ.....ëäŒ
  00D80100  00 00 00 00 00 00 00 14 86 1E A7 45 DB 22 16 01  ........†.§EÛ"..
  00D80110  EF 94 71 06 CD 91 7B 0F 95 D1 36 71 FF FF FF FF  ï”q.Í‘{.•Ñ6qÿÿÿÿ
  00D80120  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
</pre>


=== cell_ext_os_area ===
=== cell_ext_os_area ===
Line 1,194: Line 1,171:
   0FFFFFE0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
   0FFFFFE0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
   0FFFFFF0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ</pre>
   0FFFFFF0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ</pre>


== NAND reference CECHG04/SEM-001(sinsizer) ==
== NAND reference CECHG04/SEM-001(sinsizer) ==
Line 1,441: Line 1,419:
0E7807F0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
0E7807F0  FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
</pre>
</pre>
[https://www.kernel.org/pub/linux/kernel/people/geoff/cell/ps3-linux-docs/BootLinuxAndInstallation.html crosschecking]
=== OtherOS ===
=== OtherOS ===
[[Flash:OtherOS]]
[[Flash:OtherOS]]
Line 1,524: Line 1,499:


----
----
== Hidden value in VTRM (NOR Flash) ==
[[Flash:cvtrm]]
* from offset 0xEDD748 count 199 (0xC7) values of a 0x14 byte value (hash1) until you reach 0xEDE6D4, where you'll find another 0x14 byte value (hash2)
* from there, count 520 (321 + 199) values of the same repeated 0x14 byte value until you reach the second offset where you'll find the same hash of the first 199 step count (you can just search for the value to encounter it faster).
* in the area in the middle there's a third 0x14 value (hash3) at offset 0xEE4010 (repeated also twice in each vtrm)
maybe these are all sha1 hashes of something?
* 0xEE4010 should be an sha1 of root hsec, if syscon sends different hsec the sha1 wont match to VTRM it will lead to an [[RSOD]]. (root hash/ root hsec - srh)
* vtrm table is almost equally build up like PFD files.
===Experiments (with above hashes)===
* replacing both hash 2 with either hash3 or hash1 doesn't result in RSOD. why? (possibly hash1 and hash3 are fallback hashes?)
* filling hash2 with any other value besides hash1/2/3 in hash2 WILL result in RSOD
* no considerable changes found with experiment. most considerable changes would happen when the guilty is hardware and not software.
* hash_repeated:hmac_sha1(srk,empty data)
* hash_hidden:hmac_sha1(srk,0x58 bytes of empty sector)
* srh is the hash of the signature table (the giant table with the repeated hashes and the hidden one) hashed with srk key
* header hash is just a hmac sha1 of hmac sha1 of vtrm section without header (0x28 bytes) and signature table(again, with srk key, hashed twice)
= RAW NAND + bad blocks =
Each page of a block has 2048 bytes of data plus a 64 bytes oob (out of bounds) or spare area. This oob area contains 4*14 bytes ecc data for 4*512 bytes of actual data (of which 10 bytes are the actual ecc plus 4 unknown bytes). It totally unrelated to bad blocks. The remaining 8 bytes of oob contain eg. information of block status (good or bad) and the block mapping (physical block location in nand mapped to logical block location in merged dump).
The PS3 has many different ways of doing this depending on the location of bad blocks. That's [[:File:Nand-extract-error2.png|where flowrebuilder fails]], because it doesn't know all the different ways of doing it (if it [[:File:Nand-extract-noerror.png|doesn't fail]] it means it had bad blocks in a way that Flowrebuilder understands).
== As requoted from NORpatch ==
https://raw.githubusercontent.com/hjudges/NORway/824bab547698ebac8c69158d15e0c18d866c0a95/norpatch_README.txt
<div style="border-width: 1px; border-style:dashed; border-color:#000000; padding: 10px; background-color:#FFFFFF; color:#000000; ">Some additional information on how to use "norpatch" for checking ECC errors of raw NAND dumps...
<nowiki>***</nowiki> All credits go to "RPS" who developed/reversed the ECC algo (according to Flow Rebuilder title). <nowiki>***</nowiki>
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).
<br /><br />
-- judges</div>


= Flash Samples =
= Flash Samples =
Line 1,652: Line 1,569:
** https://github.com/anaria28/NOR-Dump-Tool
** https://github.com/anaria28/NOR-Dump-Tool
* https://github.com/Swizzy/PS3DumpChecker
* https://github.com/Swizzy/PS3DumpChecker
* flash_ident.c: http://pastie.org/private/vlrxgaawtbqwggyv4ggwg


== Generic Recommendations ==
== Generic Recommendations ==
* The information in this wiki was given [[http://www.gnu.org/licenses/old-licenses/fdl-1.2.txt freely by many volunteers]] ; it would be most fair to release any program based on it, as opensource with the community accordingly (tip: [http://git.ps3dev.net/ public git-repo]).
* The information in this wiki was given [[http://www.gnu.org/licenses/old-licenses/fdl-1.2.txt freely by many volunteers]] ; it would be most fair to release any program based on it, as opensource with the community accordingly (tip: [http://git.ps3dev.net/ public git-repo]).
* Please link to wiki so that others might improve the code and also know on what information it is based as well as other informative pages.
* Please link to ps3devwiki so that others might improve the code and also know on what information it is based as well as other informative pages.
* Feel free to ask questions on the talkpages when having trouble understanding mainpage or when not knowing what to check for.
* Feel free to ask questions on the talkpages when having trouble understanding mainpage or when not knowing what to check for.
* Make checkers/extractors bytedirection aware and byteswap when needed
* Make checkers/extractors bytedirection aware and byteswap when needed
Line 1,676: Line 1,592:
* Check for downgradeability
* Check for downgradeability
* Check statistics in range with known FW versions (3.55 is considered base on wiki unless documented)
* Check statistics in range with known FW versions (3.55 is considered base on wiki unless documented)
= With / Without =
* Flash Without EID5 : Boots Fine
* Flash Without EID0 Sections 1 2 3 4 5 7 8 9 and With Sections 0 6 A : Boots Fine
* Flash With only MAC Address on cISD and Header: Boots Fine
=Experimental tables=
{| class="wikitable"
|+NOR flash
! rowspan="2" | type !! rowspan="2" colspan="4" | Regions !! colspan="3" | Start Offset !! colspan="3" | Length !! Notes
|-
! Hex !! Blocks !! Bytes !! Hex !! Blocks !! Bytes
|-
| {{generic}} || rowspan="8" | [[Flash:Second_Region|Second<br>Region]] || rowspan="2" | Partition table || colspan="2" | [[Flash:0FACE0FF_DEADFACE|0FACE0FF DEADFACE]] ||  ||  ||  ||  ||  ||  ||
|-
| {{generic}} || colspan="2" | erased bytes ||  ||  ||  ||  ||  ||  ||
|-
| {{generic}} || region 0 || colspan="2" | missing ||  ||  ||  ||  ||  ||  ||
|-
| {{generic}} || region 1 || colspan="2" | [[Flash:CELL_EXTNOR_AREA|CELL_EXTNOR_AREA]] ||  ||  ||  ||  ||  ||  ||
|-
| {{generic}} || rowspan="4" | region 2 || colspan="2" | [[Flash:CELL_EXTNOR_AREA#F40000|CRL1]] ||  ||  ||  ||  ||  ||  ||
|-
| {{generic}} || colspan="2" | [[Flash:CELL_EXTNOR_AREA#F60000|DRL1]] ||  ||  ||  ||  ||  ||  ||
|-
| {{generic}} || colspan="2" | [[Flash:CELL_EXTNOR_AREA#F80000|CRL2]] ||  ||  ||  ||  ||  ||  ||
|-
| {{generic}} || colspan="2" | [[Flash:CELL_EXTNOR_AREA#FA0000|DRL2]] ||  ||  ||  ||  ||  ||  ||
|-
| {{perconsole}} || colspan="4" | [[Flash:bootldr|bootldr]] ||  ||  ||  ||  ||  ||  ||
|-
|}
<!-- old tests, hidden
{| class="wikitable"
|+NOR flash
! rowspan="2" | type !! rowspan="2" | Region !! rowspan="2" colspan="3" | Name !! colspan="2" | Hexadecimal !! colspan="2" | Blocks !! colspan="2" | Decimal !! rowspan="2" | Notes
|-
! Start Offset !! Length !! Start Offset !! Length !! Start Offset !! Length
|-
| {{generic}} || rowspan="6" style="text-align:center" | [[Flash:Second_Region|2]] || colspan="3" | [[Flash:0FACE0FF_DEADFACE|0FACE0FF DEADFACE]] || 0xF00000 || 0x1000 || 0x7800 ||  ||  || 4096 bytes ||
|-
| {{generic}} || colspan="3" | [[Flash:CELL_EXTNOR_AREA|CELL_EXTNOR_AREA]] || 0xF20000 || 0x20000 || 0x7900 ||  ||  || 131072 bytes ||
|-
| {{generic}} || colspan="3" | [[Flash:CELL_EXTNOR_AREA#F40000|CRL1]] || 0xF40000 || 0x20000 || 0x7A00 ||  ||  || 131072 bytes ||
|-
| {{generic}} || colspan="3" | [[Flash:CELL_EXTNOR_AREA#F60000|DRL1]] || 0xF60000 || 0x20000 || 0x7B00 ||  ||  || 131072 bytes ||
|-
| {{generic}} || colspan="3" | [[Flash:CELL_EXTNOR_AREA#F80000|CRL2]] || 0xF80000 || 0x20000 || 0x7C00 ||  ||  || 131072 bytes || same as CRL1
|-
| {{generic}} || colspan="3" | [[Flash:CELL_EXTNOR_AREA#FA0000|DRL2]] || 0xFA0000 || 0x20000 || 0x7D00 ||  ||  || 131072 bytes || same as DRL1
|-
| {{perconsole}} || rowspan="1" style="text-align:center" | <small>[[Flash:Lv0ldr_Region|lv0ldr]]</small> || colspan="3" | [[Flash:bootldr|bootldr]] || 0xFC0000 || 0x40000 || 0x7E00 ||  ||  || 262144 bytes ||
|-
|}
-->
= Erasing blocks =
The PS3 erases blocks in chunks of 0x40000 bytes, this is a sample of how the blocks are erased in a ros area (with offsets relatives to the start of the ros area):
Erase block 0 begins 0x0
Erase block 1 begins 0x40000
Erase block 2 begins 0x80000
Erase block 3 begins 0xC0000
Erase block 4 begins 0x100000
Erase block 5 begins 0x140000
Erase block 6 begins 0x180000
Erase block 7 begins 0x1C0000
Erase block 8 begins 0x200000
Erase block 9 begins 0x240000
Erase block 10 begins 0x280000
Erase block 11 begins 0x2C0000
Erase block 12 begins 0x300000
Erase block 13 begins 0x340000
Erase block 14 begins 0x380000
Erase block 15 begins 0x3C0000
Erase block 16 begins 0x400000
Erase block 17 begins 0x440000
Erase block 18 begins 0x480000
Erase block 19 begins 0x4C0000
Erase block 20 begins 0x500000
Erase block 21 begins 0x540000
Erase block 22 begins 0x580000
Erase block 23 begins 0x5C0000
Erase block 24 begins 0x600000
Erase block 25 begins 0x640000
Erase block 26 begins 0x680000
Erase block 27 begins 0x6C0000
Please note that all contributions to PS3 Developer wiki are considered to be released under the GNU Free Documentation License 1.2 (see PS3 Developer wiki:Copyrights for details). If you do not want your writing to be edited mercilessly and redistributed at will, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource. Do not submit copyrighted work without permission!

To protect the wiki against automated edit spam, we kindly ask you to solve the following hCaptcha:

Cancel Editing help (opens in new window)

Templates used on this page:

Retrieved from "http://www.psdevwiki.com/ps3/Talk:Flash"