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:
= 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 224:
'''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,441: Line 1,441:
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,525: Line 1,522:
----
----


== Hidden value in VTRM (NOR Flash) ==
=== 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)
<br>from offset 0xEDD748 count 199 (0xC7) values of a 0x14 byte value until you reach 0xEDE6D4, where you'll find another 0x14 byte value
* 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).
<br>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)
<br>in the area in the middle there's a third 0x14 value at offset 0xEE4010 (repeated also twice in each vtrm)


maybe these are all sha1 hashes of something?
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,599:
** 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,622:
* 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"