Talk:Syscon Hardware: Difference between revisions

From PS3 Developer wiki
Jump to navigation Jump to search
m (I been hesitant of cleaning up this talk because there are some interesting comments from m4j0r. Im going to clean it up now keeping only that notes... we will see what to do with them later)
m (deleted talk about the new table format)
Line 4: Line 4:
The actual platform configuration which defines the board on the which Syscon resides is stored in the EEPROM (CXR) or Flash data section (SW), it can be mapped to the platform id.
The actual platform configuration which defines the board on the which Syscon resides is stored in the EEPROM (CXR) or Flash data section (SW), it can be mapped to the platform id.
----
----
For the sherwoods i been thinking in creating another 2 more tables with the same style, based in the package we have 3 groups: all the "mullions BGA 200 balls" (this is confirmed in many ways, all the mullions shares the same pinout, we have the COK-001 and COK-002 refurbishements with the latest mullion versions CXR714120-303GB and CXR714120-304GB, a metal gear solid special edition COK-002 with a CXR714120-301GB, and the COOKIE-13 and other prototypes with a CXR713F120A), "Sherwoods SW & SW2 QFP 128 pins", and "Sherwoods SW3 QFP 100 pins". The point of grouping them this way is because indicates which ones can be replaced by each others, also im guessing the members of each group are "pinout compatibles" with each others<br>
In theory even the SW(1) chips work on Mullion boards if you adapt them. The "F" syscon problem is interesting, since that model is only used on prototypes and the marking XXXGB doesn't map to a particular firmware (especially since they reuse the chips). We would have to somehow get the TMU-510, TMU-520 and all the prototype boards into the table or just say that the "F" model does support both the retail firmware and then list the known prototype firmwares, this would mean that we only need to add the TMU-520.<br>
The other reason is because in the actual table style im keeping the names of the "syscon model", "motherboard model" and "PS3 model" to leverage a bit the skills required to read the wiki pages. With the actual table style the group for the "mullions BGA 200 balls" requires to display the names of 5 retail motherboards in the same table row (one more for the "F"), "Sherwoods SW & SW2 QFP 128 pins" is composed by 5 motherboards, and "Sherwoods SW3 QFP 100 pins" by 8 motherboards. That numbers are fine for splitting the table in 3 groups, otherway if we joing together all the sherwoods it would be needed to have 13  columns 5+8) for the motherboard names and the width of the table would be excesive--[[User:Sandungas|Sandungas]] ([[User talk:Sandungas|talk]]) 11:58, 23 April 2021 (UTC)
----
I like the new table. I don't know if it makes sense to include the ports into the table since Sony never changed them. In theory even the SW(1) chips work on Mullion boards if you adapt them. The "F" syscon problem is interesting, since that model is only used on prototypes and the marking XXXGB doesn't map to a particular firmware (especially since they reuse the chips). We would have to somehow get the TMU-510, TMU-520 and all the prototype boards into the table or just say that the "F" model does support both the retail firmware and then list the known prototype firmwares, this would mean that we only need to add the TMU-520.<br>
Sherwood would need 3 tables since the SW and the SW2 are not interchangable (because of the CEC handling which uses hardcoded HDMI stuff), but I like that idea.<br>
Sherwood would need 3 tables since the SW and the SW2 are not interchangable (because of the CEC handling which uses hardcoded HDMI stuff), but I like that idea.<br>
So about the "SoftID" and the platform id: Sony never uses the CECHXxx code internally, the same for the motherboard label (e.g. COK-001), the only thing which they use to identify the hardware is '''the platform id, which contains the chassis id''' [[SKU_Models_Nonretail#Prototype_model_names]]. On prototype units it's not only stored in syscon, but also on a label on the board and part of the board_id inside cISD1.<br>
So about the "SoftID" and the platform id: Sony never uses the CECHXxx code internally, the same for the motherboard label (e.g. COK-001), the only thing which they use to identify the hardware is '''the platform id, which contains the chassis id''' [[SKU_Models_Nonretail#Prototype_model_names]]. On prototype units it's not only stored in syscon, but also on a label on the board and part of the board_id inside cISD1.<br>

Revision as of 16:43, 4 November 2021

Main table problem

Syscon_Hardware#Retail assumes that each PS3 model does have an unique Syscon associated with it, but that's not true. Every syscon within a series (CXR, SW, SW2, SW3) is backwards compatible, e.g. every CXR Syscon works on the COK-001, but only -202GB and newer on a COK-002.
The SoftID (Syscon firmware build id) is a 1:1 mapping to the suffix -XXXGB. So each -XXXGB does have a unique SoftID (in case of retail chips).
The actual platform configuration which defines the board on the which Syscon resides is stored in the EEPROM (CXR) or Flash data section (SW), it can be mapped to the platform id.


In theory even the SW(1) chips work on Mullion boards if you adapt them. The "F" syscon problem is interesting, since that model is only used on prototypes and the marking XXXGB doesn't map to a particular firmware (especially since they reuse the chips). We would have to somehow get the TMU-510, TMU-520 and all the prototype boards into the table or just say that the "F" model does support both the retail firmware and then list the known prototype firmwares, this would mean that we only need to add the TMU-520.
Sherwood would need 3 tables since the SW and the SW2 are not interchangable (because of the CEC handling which uses hardcoded HDMI stuff), but I like that idea.
So about the "SoftID" and the platform id: Sony never uses the CECHXxx code internally, the same for the motherboard label (e.g. COK-001), the only thing which they use to identify the hardware is the platform id, which contains the chassis id SKU_Models_Nonretail#Prototype_model_names. On prototype units it's not only stored in syscon, but also on a label on the board and part of the board_id inside cISD1.
So how they do it is start with the platform id, then get the chassis id which then maps to the numeric model code (1000, 1200, 1300...) and the model type byte inside the IDPS. The actual SKU name then gets assigned based on what they want it to be marketed as. That's why I think the SKU name and board name are maybe misleading if you don't know how Sony works with them. The platform id is mapped 1:1 to your actual hardware, the SKU codes (especially for the early models) are all over the place. For example there're CECHA/DECHA with COK-001, COK-001 (with COK-002 syscon) and COK-002, also models certified as CECHE are sold as CECHA in some regions. The CECHM either had a VER-001 or DIA-001, completely different architecture and I wonder how many of these cases we haven't identified yet...
M4j0r (talk) 13:49, 23 April 2021 (UTC)