Editing Talk:Platform ID

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:
== Platform ID of COOKIE prototypes ==
== Lv2 Platform identifier ==
Can't be proven atm, <b>only for the COOKIE prototypes leading to the CECHAxx</b>.
can be found in old bootroms
 
<pre>
DEH-H100?-<b>B</b> -> 0xB = 11 -> {{unk|Cok11}} = {{unk|COOKIE-11}}<br>
Shr1.0
DEH-H100?-<b>C</b> -> 0xC = 12 -> {{unk|Cok12}} = {{unk|COOKIE-12}}<br>
Shr1.1
 
Shr1.2
DEH-H1001-<b>D</b> -> 0xD = 13 -> {{unk|Cok13}} = COOKIE-13<br>
Shr-1.3
DEH-H1000A-<b>E</b> -> 0xE = 14 -> Cok14 = COK-001 Prototype {{unk|(COOKIE-14)}}
Shr1.4
 
Shr1.5
== Other speculations ==
 
=== Theory 1 ===
* Shr = Shreck (CEB-10XX)
* Cyt = Cytology (CEB-20XX, DEH-R10XX, DECR-1000X)
* Cok = Cookie (DEH-H10XX, CBEH-10XX, DECHA, CECHA)
 
*Cyt2.2 = DEH-R100X / DEH-R101X / DEH-R102X
 
*Cyt3.1 = DEH-R103X
*Cyt3.2 = DEH-R104X / DECR-1000X
 
*Cok14 = DEH-H1000X / CECHA
 
=== Theory 2 (the shreck conspiracy) ===
There is an interesting coincidence in some of the platform_id version numbers and the numbers used in prototypes PS3 models, crosscheck with: [[SKU_Models_Nonretail#Prototype_models|Prototype models]]


*'''SHRECK V1 series''' ? (Motherboard '''MPU-500''' ?)
Shr2.0
**Shr1.0 -> [[CEB-1000]] ?
Shr2.1
**Shr1.1 -> undocumented / never found (theorethically a '''CEB-1010''')
Shr2.2
**Shr1.2 -> [[CEB-1020]] ?
Shr2.3
**Shr-4D -> ?
Shr2.4
**Shr1.3 -> undocumented / never found (theorethically a '''CEB-1030''')
Shr2.5
**Shr-LC -> ?
Shr2.6
**Shr1.4 -> undocumented / never found (theorethically a '''CEB-1040''')
**Shr1.5 -> undocumented / never found (theorethically a '''CEB-1050''')
*'''SHRECK V2 series''' ? (Motherboard [[MPU-501]] ?)
**Shr2.0 -> [[CEB-200x]] ?
**Shr2.1 -> [[CEB-201x]] ?
**Shr2.2 -> [[CEB-202x]] ?
**Shr2.3 -> [[CEB-2030]] ?
**Shr2.4 -> [[CEB-2040]] ?
**Shr2.5 -> [[CEB-2050]] ?
**Shr2.6 -> [[CEB-206x|CEB-2060]] ?
*'''SHRECK V3 series''' ? (Motherboard '''MPU-502''' ?)
**Shr3.0 -> ?
**Shr3.1 -> ?
**Shr3.2-4 -> ?
**Shr3.2 -> ?
**Shr3.3 -> ?
*'''SHRECK V4 series''' ? (Motherboard '''MPU-503''' ?)
**Shr4.0 -> ?


== Super Slims NOR vs eMMC ==
Shr3.0
As explained [[MN66840|here]] the circuit design of all superslim motherboards (7 motherboard models documented so far) allows to install either a NOR or a eMMC flash. If we assume the [[Platform ID]] of a specific motherboard changes based in his flash type (NOR or eMMC) we have a theoretical amount of 14 posible platform ID's for superslims<br>
Shr3.1
But... the fact that all the superslims allows to install a eMMC doesnt means that sony did in retail production in all them (the existence of a MSX-001 motherboard with a eMMC flash is doubtful). Anyway... in the meantime im going to make a list with all the posible combinations to keep a record of which ones has been found to be real<br>
Shr3.2
Is relativelly easy to do if we find photos of them, even if the photo is blurry or have s small size, we just need to check the motherboard name and the presence of the NOR chip located next to the HDD connector (rectangled chip=NOR, squared chip=eMMC), if some of you find a photo or any other proof of the existence of them just post the link in this list
Shr3.3
*1
**MSX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:MSX-001-top.jpg
**MSX-001(eMMC) - <span style="background:#ff4444;">? (never found)</span>
*2
**MPX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:MPX-001-top.jpg
**MPX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:MPX-001_Front_%2812GB%29.jpg
*3
**NPX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:NPX-001_NOR_top_side.jpg
**NPX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:NPX-001_%28top_view%29.jpg
*4
**PPX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:PPX-001_1-888-615-12_main_componentside.png
**PPX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:PPX-001_eMMC_top_side.jpg
*5
**PQX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:PQX-001_NOR_top_side.jpg
**PQX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:PQX-001_Board.jpeg
*6
**RTX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:RTX-001_top.jpg
**RTX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:RTX-001_eMMC_top_side.jpg
*7
**REX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:REX-001_NOR_top_side.jpg
**REX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:REX-001-top.jpg


=== Some thoughts ===
Shr4.0
Sony doesn't have all the platform ids inside the syscon firmware, sometimes they just overwrite the platform id using the "eeprom".<br>
Shr-4D
That's denoted as "hardcoded" [[Talk:Platform_ID#Lv2_Platform_identifier_in_Syscon_firmware|here]], which means that e.g. Syscon makes no difference between the CokE10 and Deb01 or CokJ13 and Cok20.<br>
ShrLC
Also the last platform id which can be found in the latest syscon SW3-304, ends at CokN30 which means all later boards are handled the same by Syscon and the platform id is just overwritten.<br>


<pre>
Cyt1.0
CokM10    Dumped unknown motherboard
Cyt1.1
CokM20    Inside Syscon firmware
Cyt1.2
CokM30    Dumped MPX-001 eMMC
CokM40    Inside Syscon firmware
CokN10    Inside Syscon firmware
CokN30    Inside Syscon firmware
CokP10    Dumped PQX-001 NOR
CokP40    Dumped PPX-001 eMMC
CokR30    Dumped unknown motherboard
CokR40    Dumped REX-001 eMMC


so CokX10, CokX20, CokX30, CokX40 ?
Cok01
Cok02
</pre>
</pre>
You can also see that there're 8 different Product Sub Codes for the Superslim: 0x0D, 0x0E, 0x0F, 0x10, 0x11, 0x12, 0x13, 0x14 - but only 7 boards?<br>
The minimum support firmware (excluding the metldr enforced one) can be seen [[Motherboard_Revisions#Product_Sub_Code|here]] and also the mapping to the Chassis ID.<br>
There seem to be only 4 groups (4.15, 4.20, 4.40 and 4.50).
== SW "EEPROM" ([[Special:Diff/63500/63501|diff]]) ==
The platform ID (hex and/or string) doesn't have to be at 0x60000 (SW) or 0xA0000 (SW2/3). That's where the eeprom emulation space starts.<br>
At least from what I know now, the eeprom emulation can mark blocks as invalid.<br>
That means if the block size is set to 16 bit, every 16 bit can be replaced by a different block and the old one just gets marked "invalid" (the data stays there).<br>
It also does wear leveling so if you change some data multiple times, the location will change but the old data won't (and maybe only some words will be remapped).<br>
I would rather not list that else someone could think they can read the values directly from the flash image, but that might lead to problems.<br>
Or maybe add a disclaimer that under normal circumstances you can read some things from there but you can't trust it 100%. (you can trust r 0 8 though)
*I tryed to improve the descriptions in [[Special:Diff/63503/63511|this edit]], there are still many details i dont understand fully, btw if we dont count the block remapping and wear leveling features the emulated EEPROm should be always located in that offsets, right ?, in other words... in the worst scenario posible the only relocated data we are going to find are just some blocks "here and there" (in other words, a couple of bytes here and there) but finding a big chunks of relocated data (lets say 20 consecutive blocks relocated) is not much probable, right ?. In the practise... if we take a look at 0x60000 (SW) or 0xA0000 (SW2/3) there is a huge probability to find some of the original data, right ?, im just asking for the purpose of identifying where the regions starts and ends. Im also asking because [[Special:Diff/63501/63503|this sample]] surprised me a bit, how is posible to be completly empty after the first 0x40 bytes ?, in all the other samples i have this area of 0x250 bytes seems to have at least 4 or 5 different "chunks" of data, maybe is because the dumper tools are not "rebuilding" it properlly ?. Last btw... i been using the concept of "overriding" data chunks because i was thking there was 2 copies of the data chunks (one of them "read only" and the other "read/write" in the emulated EEPROM), but right now i have doubts, it makes sense to keep only 1 copy, but the first 0x250 bytes in the emulated EEPROM of the SW3-302 full dump sample we have that is almost filled completly with FF's doesnt makes sense
**The emulated EEPROM has no real offset. The data at 0x60000 or 0xA0000 (length 0x20000) is used to emulate the EEPROM, it's not the emulated EEPROM. The only way to access that is to use the dedicated read/write functions. Or reverse them and then you can extract the data from the flash image.
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)

Template used on this page:

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