Talk:Platform ID: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
 
(24 intermediate revisions by 2 users not shown)
Line 1: Line 1:
== Lv2 Platform identifier in Syscon firmware ==
== Platform ID of COOKIE prototypes ==
This is a collection of the platform ids with their internal id which can be found in the syscon firmware
Can't be proven atm, <b>only for the COOKIE prototypes leading to the CECHAxx</b>.
 
I would like to suggest to keep this list clean, avoiding adding any association with motherboards or PS3 models, to help keeping open mind, and trying to not bringing here posible "mistakes" from other wiki pages or any internet source to avoid taking things as "facts". Also, consider sony itself could have made some "mistake" or breking his own naming convention, as example labeling a prototype with a sticker telling "cytology" but returning "shreck" in the syscall that shows the platform_id. If someone wants to add some speculation crete a section at bottom of this page and post it there --[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 16:52, 22 August 2018 (UTC)
 
<pre>
Mullion
0x10            Shr1.0
0x11            Shr1.1
0x12            Shr1.2
0x13            Shr-4D
0x14            Shr1.3
0x15            Shr-LC
0x16            Shr1.4
0x17            Shr1.5
0x20            Shr2.0
0x21            Shr2.1
0x22            Shr2.2
0x23            Shr2.3
0x24            Shr2.4
0x25            Shr2.5
0x26            Shr2.6
0x30            Shr3.0
0x31            Shr3.1
0x32            Shr3.2-4
0x33            Shr3.2
0x34            Shr3.3
0x40            Shr4.0
 
0x10000010      Cok01
0x10000020      Cok02
0x10000030      Cok03
0x10000050      Cok05
0x10000080      Cok08
0x100000B0      Cok11
0x100000C0      Cok12
0x100000D0      Cok13
0x100000E0      Cok14
0x10000100      CokB10
0x10000200      CokC10
0x10000201      CokC11
0x10000202      CokC12
0x10000300      CokD10
0x10000301      CokE10
0x10000301      Deb01        hardcoded
 
0x20000010      Cyt1.0
0x20000011      Cyt1.1
0x20000012      Cyt1.2
0x20000020      Cyt2.0
0x20000021      Cyt2.1
0x20000022      Cyt2.2
0x20000030      Cyt3.0
0x20000031      Cyt3.1
0x20000032      Cyt3.2
0x20000033      Cyt3.3
0x20000034      Cyt3.4


 
DEH-H100?-<b>B</b> -> 0xB = 11 -> {{unk|Cok11}} = {{unk|COOKIE-11}}<br>
Sherwood
DEH-H100?-<b>C</b> -> 0xC = 12 -> {{unk|Cok12}} = {{unk|COOKIE-12}}<br>
0x01            Cok11
0x02            Cok12
0x03            Cok13
0x04            Cok14
0x10            CokB10
0x20            CokC10
0x21            CokC11
0x22            CokC12
0x30            CokD10
0x40            CokE10
0x40            Deb01        hardcoded
0x50            CokF10
0x60            CokG10
0x61            CokG11
0x70            CokH10
0x71            CokH11
0x80            CokJ13
0x80            CokJ20      hardcoded
0x90            CokK10
0xB0            CokM20
0xB8            CokM40
0xA0            CokN10
0xA8            CokN30
...
</pre>
<!-- are you sure sherwood 0xB8 is M40 ?. It looks like it could be M30 -->
 
== Speculation ==
Can't be proven atm, <b>only for the COOKIE prototypes leading to the CECHAxx</b>.


DEH-H1001-<b>D</b> -> 0xD = 13 -> {{unk|Cok13}} = COOKIE-13<br>
DEH-H1001-<b>D</b> -> 0xD = 13 -> {{unk|Cok13}} = COOKIE-13<br>
DEH-H1000A-<b>E</b> -> 0xE = 14 -> Cok14 = COK-001 Prototype {{unk|(COOKIE-14)}}
DEH-H1000A-<b>E</b> -> 0xE = 14 -> Cok14 = COK-001 Prototype {{unk|(COOKIE-14)}}


==Theory 1==
== Other speculations ==
 
=== Theory 1 ===
* Shr = Shreck (CEB-10XX)
* Shr = Shreck (CEB-10XX)
* Cyt = Cytology (CEB-20XX, DEH-R10XX, DECR-1000X)
* Cyt = Cytology (CEB-20XX, DEH-R10XX, DECR-1000X)
* Cok = Cookie (DEH-H10XX, CBEH-10XX, DECHA, CECHA)
* Cok = Cookie (DEH-H10XX, CBEH-10XX, DECHA, CECHA)


*Cyt2.2 = DEH-R100X / DEH-R101X / DEH-R102X
*Cyt2.2 = DEH-R100X / DEH-R101X / DEH-R102X
Line 105: Line 22:
*Cok14 = DEH-H1000X / CECHA
*Cok14 = DEH-H1000X / CECHA


==Theory 2==
=== Theory 2 (the shreck conspiracy) ===
Trying to assing the codenames above with prototypes models...
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 V2 series''' ? - There is an interesting coincidence in some of the platform_id version numbers and the numbers used in prototypes PS3 models, crosscheck with the info in: [[SKU_Models_Nonretail#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]] ?)
**Shr2.0 -> [[CEB-200x]] ?
**Shr2.0 -> [[CEB-200x]] ?
**Shr2.1 -> [[CEB-201x]] ?
**Shr2.1 -> [[CEB-201x]] ?
Line 115: Line 41:
**Shr2.4 -> [[CEB-2040]] ?
**Shr2.4 -> [[CEB-2040]] ?
**Shr2.5 -> [[CEB-2050]] ?
**Shr2.5 -> [[CEB-2050]] ?
**Shr2.6 -> [[CEB-206x]] ?
**Shr2.6 -> [[CEB-206x|CEB-2060]] ?
*'''SHRECK V1 series''' ? - Following this same numbering theory... then the prototype models preceding are:
*'''SHRECK V3 series''' ? (Motherboard '''MPU-502''' ?)
**Shr1.0 -> [[CEB-1000]] ?
**Shr3.0 -> ?
**Shr1.1 -> undocumented / never found (theorethically a CEB-1010)
**Shr3.1 -> ?
**Shr1.2 -> [[CEB-1020]] ?
**Shr3.2-4 -> ?
**Shr-1.3 -> undocumented / never found (theorethically a CEB-1030)
**Shr3.2 -> ?
**Shr1.4 -> undocumented / never found (theorethically a CEB-1040)
**Shr3.3 -> ?
**Shr1.5 -> undocumented / never found (theorethically a CEB-1050)
*'''SHRECK V4 series''' ? (Motherboard '''MPU-503''' ?)
*'''CYTOLOGY V1 series''' ? - Also, this method matches with some prototypes for reference tool:
**Shr4.0 -> ?
**Cyt1.0 -> [[DEH-R1000]] ?
**Cyt1.1 -> [[DEH-R1010]] ?
**Cyt1.2 -> [[DEH-R1020]] ?
<strike>
*'''CYTOLOGY V2 series''' ? - The numbers doesnt matches in this ones, but just because in the sequence are located inmediatly after the previous prototypes for reference tool (and for completionism):
**Cok01 -> [[DEH-R1030]] ?
**Cok02 -> [[DEH-R1040]] ?</strike>please someone check if there is some bootrom listing a "Cyt1.3" and "Cyt1.4" (for [[DEH-R1030]] and [[DEH-R1040]])
 
 
With this theory all the groups are assigned, but the question that emerges is... what happens with the platform_id for shreck v3 series (Shr3.0 Shr3.1 Shr3.2 Shr3.3), and shreck v4 series (Shr4.0 Shr-4D ShrLC) ?


== Super Slims NOR vs eMMC ==
== Super Slims NOR vs eMMC ==
As explained [[MN66840|here]] the circuit design of all superslim motherboards (7 motherboard models) 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>
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>
But... the fact that all the superslims allows to install a eMMC doesnt means that sony did in retail production in all them. As far i can see there are some superslim motherboards that was released only with a NOR (the eMMC variant of that specific motherboard model never was released)<br>
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>
This is very confusing actually, i guess at some point we will have a better understanding after some more reports, and if someone dumps and shares the syscon contents of the last PS3 model with M4j0r (because contains a list with the platform ID names from all the previous superslim PS3 models). 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>
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
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
*1
Line 147: Line 62:
**MPX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:MPX-001_Front_%2812GB%29.jpg
**MPX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:MPX-001_Front_%2812GB%29.jpg
*3
*3
**NPX-001(NOR) - '''YES''' [https://picclick.fr/Working-Sony-PS3-Super-Slim-Motherboard-NPX-001-162528967351.html 1] (to wikify)
**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
**NPX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:NPX-001_%28top_view%29.jpg
*4
*4
**PPX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:PPX-001_1-888-615-12_main_componentside.png
**PPX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:PPX-001_1-888-615-12_main_componentside.png
**PPX-001(eMMC) - '''YES''' [https://konsolowo.pl/gb/ps3-super-slim/2048-motherboard-ppx-001-for-playstation-3-super-slim-5903981903306.html 1] (to wikify)
**PPX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:PPX-001_eMMC_top_side.jpg
*5
*5
**PQX-001(NOR) - <span style="background:#ff4444;">? (never found)</span>
**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
**PQX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:PQX-001_Board.jpeg
*6
*6
**RTX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:RTX-001_top.jpg
**RTX-001(NOR) - '''YES''' https://www.psdevwiki.com/ps3/File:RTX-001_top.jpg
**RTX-001(eMMC) - <span style="background:#ff4444;">? (never found)</span>
**RTX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:RTX-001_eMMC_top_side.jpg
*7
*7
**REX-001(NOR) - <span style="background:#ff4444;">? (never found)</span>
**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
**REX-001(eMMC) - '''YES''' https://www.psdevwiki.com/ps3/File:REX-001-top.jpg


Line 165: Line 80:
Sony doesn't have all the platform ids inside the syscon firmware, sometimes they just overwrite the platform id using the "eeprom".<br>
Sony doesn't have all the platform ids inside the syscon firmware, sometimes they just overwrite the platform id using the "eeprom".<br>
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>
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>
Also the last platform id which can be found in the latest syscon firware (304), ends at CokN30 which means all later boards are handled the same by Syscon and the platform id is just overwritten.<br>
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>
<pre>
CokM10    Dumped unknown motherboard
CokM20    Inside Syscon firmware
CokM20    Inside Syscon firmware
CokM30    Dumped MPX-001 eMMC
CokM30    Dumped MPX-001 eMMC
Line 173: Line 89:
CokN10    Inside Syscon firmware
CokN10    Inside Syscon firmware
CokN30    Inside Syscon firmware
CokN30    Inside Syscon firmware
CokP10    Dumped unknown
CokP10    Dumped PQX-001 NOR
CokP40    Dumped PPX-001 eMMC
CokP40    Dumped PPX-001 eMMC
CokR30    Dumped unknown
CokR30    Dumped unknown motherboard
CokR40    Dumped REX-001 eMMC


so CokX10, CokX20, CokX30, CokX40 ?
so CokX10, CokX20, CokX30, CokX40 ?
</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.<br>
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>
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)
*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.

Latest revision as of 12:11, 1 December 2021

Platform ID of COOKIE prototypes[edit source]

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[edit source]

Theory 1[edit source]

  • 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)[edit source]

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[edit source]

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

Some thoughts[edit source]

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)[edit source]

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)

  • I tryed to improve the descriptions in 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 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.
Retrieved from "http://www.psdevwiki.com/ps3/index.php?title=Talk:Platform_ID&oldid=63534"