Talk:Platform ID: Difference between revisions
m (Moved to frontpage) |
mNo edit summary |
||
| Line 100: | Line 100: | ||
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> | 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). | 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) | |||
Revision as of 12:39, 29 November 2021
Platform ID of COOKIE prototypes
Can't be proven atm, only for the COOKIE prototypes leading to the CECHAxx.
DEH-H100?-B -> 0xB = 11 -> ?Cok11? = ?COOKIE-11?
DEH-H100?-C -> 0xC = 12 -> ?Cok12? = ?COOKIE-12?
DEH-H1001-D -> 0xD = 13 -> ?Cok13? = COOKIE-13
DEH-H1000A-E -> 0xE = 14 -> Cok14 = COK-001 Prototype ?(COOKIE-14)?
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: Prototype models
- SHRECK V1 series ? (Motherboard MPU-500 ?)
- Shr1.0 -> CEB-1000 ?
- Shr1.1 -> undocumented / never found (theorethically a CEB-1010)
- Shr1.2 -> CEB-1020 ?
- Shr-4D -> ?
- Shr1.3 -> undocumented / never found (theorethically a CEB-1030)
- Shr-LC -> ?
- Shr1.4 -> undocumented / never found (theorethically a CEB-1040)
- Shr1.5 -> undocumented / never found (theorethically a CEB-1050)
- SHRECK V2 series ? (Motherboard MPU-501 ?)
- 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
As explained 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
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
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
- 1
- MSX-001(NOR) - YES https://www.psdevwiki.com/ps3/File:MSX-001-top.jpg
- MSX-001(eMMC) - ? (never found)
- 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
Sony doesn't have all the platform ids inside the syscon firmware, sometimes they just overwrite the platform id using the "eeprom".
That's denoted as "hardcoded" here, which means that e.g. Syscon makes no difference between the CokE10 and Deb01 or CokJ13 and Cok20.
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.
CokM10 Dumped unknown motherboard CokM20 Inside Syscon firmware 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 ?
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?
The minimum support firmware (excluding the metldr enforced one) can be seen here and also the mapping to the Chassis ID.
There seem to be only 4 groups (4.15, 4.20, 4.40 and 4.50).
SW "EEPROM" (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.
At least from what I know now, the eeprom emulation can mark blocks as invalid.
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).
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).
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.
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)