PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

[RIP-Felix]

So you are suddenly interested. I thought you all were against the idea lol

I don't think it's necessary, no. I'm not against the project. From an academic standpoint, it's an interesting challenge. And it's a good 1-up on SONY's repair technicians who only figured out how to replace RSX' with pin-compatible versions. If we can take it that next step, it's bragging rights.

But yeah, it doesn't excite me now that the major "defective" component can be replaced. At this point it's going above and beyond repair, to the point of enthusiast gains for no real need. Like liquid nitrogen overclocking. Neat, but unnecessary.

 

[_XBrD4shDOE_808_]

wow, CECHA's with 40nm RSX and 65nm CELL BE, that's pretty crazy!
But along with that, several questions come to mind.
assuming that the physical work of reconnecting non-compatible pads is overcome and that it really has a good chance of working, how will the issue of backward compatibility be?
In MB COK 001 we have the EE + GS soldered directly to the board. Maybe the 65nm CELL doesn't recognize it and needs a patch or something. But on COK 002 models we only have the GS, with the EE being emulated by the CELL, and I think you know where I'm going.
I don't know how to formulate the question, so I'll cut to the chase.
The 65nm CPU has a chance to emulate the PS2's EE and there are glitches in that emulation, game incompatibility and maybe not even do this emulation.
Most likely, this issue has already been put on the table and studied, but if it did, it would be a big problem.
I'm also considering that there may be compatibility and recognition errors of the memory chips with the new CPU, with the South Bridge and even with the audio and HDMI chips, but I believe that such problems should not occur.

 

[RIP-Felix]

Yes, it's part of the fuses. The CID/eCID are (read-only) accessable through the spi registers in the pervasive logic (page 103 in the 90nm 1.5 HIG, x'0004' through x'000B').

 

[RIP-Felix]

wow, CECHA's with 40nm RSX and 65nm CELL BE, that's pretty crazy!
But along with that, several questions come to mind.
assuming that the physical work of reconnecting non-compatible pads is overcome and that it really has a good chance of working, how will the issue of backward compatibility be?
In MB COK 001 we have the EE + GS soldered directly to the board. Maybe the 65nm CELL doesn't recognize it and needs a patch or something. But on COK 002 models we only have the GS, with the EE being emulated by the CELL, and I think you know where I'm going.
I don't know how to formulate the question, so I'll cut to the chase.
The 65nm CPU has a chance to emulate the PS2's EE and there are glitches in that emulation, game incompatibility and maybe not even do this emulation.
Most likely, this issue has already been put on the table and studied, but if it did, it would be a big problem.
I'm also considering that there may be compatibility and recognition errors of the memory chips with the new CPU, with the South Bridge and even with the audio and HDMI chips, but I believe that such problems should not occur.

I have the same concerns.

Like I said, it would be an accomplishment worth the bragging rights.

 

[RIP-Felix]

Okay, So if the CELL ID is physically written in read-only registers, then there is no way to replace it (on chip) with the ID the SYSCON and NAND are expecting. But what about off chip? Could we not use a modchip that does basically what the exploit did with the teensy? Silently sniff the SPI bus waiting for the header that signify it's time to read the Cell_ID register, then disconnect the Cell SPI bus and Jedi the response, "Yeah, I'm the 90nm CELL you're looking for! There's definitely nothing suspicious going on here. Move along."

You'd have to match timings and maybe do this to both the SYSCON and NAND, whenever they send a request to read that resister, but why couldn't that work? Isn't that basically how the ORBIS Modchip works? Or is the marrying process a lot more complicated? There is a serial number at register 0x9C80 in the HIG too, which might be part of the pairing. That I'm guessing would need to match the SYSCON as well. So perhaps some prep-work would need to be done before this could be performed. We would need to have the info off the old cell before replacing it. Which perhaps could be a feature of the modchip. (Install modchip first, power it on, it reads those registers and programs itself. Then you replace the cell and it spoofs the OG 90nm's unique info.) This is assuming we cannot just change what the SYSCON/NAND is expecting. AKA remarry them to the new cell.

 

[DeadEnd]

wow, CECHA's with 40nm RSX and 65nm CELL BE, that's pretty crazy!
But along with that, several questions come to mind.
assuming that the physical work of reconnecting non-compatible pads is overcome and that it really has a good chance of working, how will the issue of backward compatibility be?
In MB COK 001 we have the EE + GS soldered directly to the board. Maybe the 65nm CELL doesn't recognize it and needs a patch or something. But on COK 002 models we only have the GS, with the EE being emulated by the CELL, and I think you know where I'm going.
I don't know how to formulate the question, so I'll cut to the chase.
The 65nm CPU has a chance to emulate the PS2's EE and there are glitches in that emulation, game incompatibility and maybe not even do this emulation.
Most likely, this issue has already been put on the table and studied, but if it did, it would be a big problem.
I'm also considering that there may be compatibility and recognition errors of the memory chips with the new CPU, with the South Bridge and even with the audio and HDMI chips, but I believe that such problems should not occur.

They are all the same chip just on a smaller die. I don't see why shouldn't they work the same way provided they are installed correctly and remarried.

 

[RIP-Felix]

They are all the same chip just on a smaller die. I don't see why shouldn't they work the same way provided they are installed correctly and remarried.

You could be right that there is not a HW difference that matters. That the emulation is done completely in software and whatever cell can run it.

 

[M4j0r]

Okay, So if the CELL ID is physically written in read-only registers, then there is no way to replace it (on chip) with the ID the SYSCON and NAND are expecting. But what about off chip? Could we not use a modchip that does basically what the exploit did with the teensy? Silently sniff the SPI bus waiting for the header that signify it's time to read the Cell_ID register, then disconnect the Cell SPI bus and Jedi the response, "Yeah, I'm the 90nm CELL you're looking for! There's definitely nothing suspicious going on here. Move along."

You'd have to match timings and maybe do this to both the SYSCON and NAND, whenever they send a request to read that resister, but why couldn't that work? Isn't that basically how the ORBIS Modchip works? Or is the marrying process a lot more complicated? There is a serial number at register 0x9C80 in the HIG too, which might be part of the pairing. That I'm guessing would need to match the SYSCON as well. So perhaps some prep-work would need to be done before this could be performed. We would need to have the info off the old cell before replacing it. Which perhaps could be a feature of the modchip. (Install modchip first, power it on, it reads those registers and programs itself. Then you replace the cell and it spoofs the OG 90nm's unique info.) This is assuming we cannot just change what the SYSCON/NAND is expecting. AKA remarry them to the new cell.

The CELL FlexIO ID can be manipulated using a modchip or you just patch it in the syscon eeprom like the RSX ID.
The CELL ID can't be altered as CELL internally doesn't use the SPI channel to communicate with the pervasive logic, you also can't change the key which is used to decrypt lv0ldr/metldr.

 

[bguerville]

.. you also can't change the key which is used to decrypt lv0ldr/metldr.

Taking the opportunity to ask you to clarify something that few people are likely to know.
During decryption operations, how does that kind of data actually go from CELL to SPU LS exactly?

 

[DeadEnd]

Also @sandungas, @Pacorretaco @RIP-Felix you might find these files interesting with regards to package design of Cell (first two are downloadable, third one isn't in free access, 4th is visible by scrolling down the page).

https://www.researchgate.net/public..._Trade-offs_in_the_65nm_Cell_Broadband_Engine

https://www.researchgate.net/public...microprocessor_for_supercomputer_applications

https://www.researchgate.net/public...Characterization_of_the_Cell_Broadband_Engine

https://www.academia.edu/24210728/Cell_Broadband_Engine_processor_Design_and_implementation

 

[M4j0r]

Taking the opportunity to ask you to clarify something that few people are likely to know.
During decryption operations, how does that kind of data actually go from CELL to SPU LS exactly?

That's unknown, it could be a channel or register or some sort of dma. It's also unknown how the code works which gets the encrypted lv0ldr/metldr from flash and then decrypts them.

 

[marciolsf]

Also @sandungas, @Pacorretaco @RIP-Felix you might find these files interesting with regards to package design of Cell (first two are downloadable, third one isn't in free access, 4th is visible by scrolling down the page).

https://www.researchgate.net/public..._Trade-offs_in_the_65nm_Cell_Broadband_Engine

https://www.researchgate.net/public...microprocessor_for_supercomputer_applications

https://www.researchgate.net/public...Characterization_of_the_Cell_Broadband_Engine

https://www.academia.edu/24210728/Cell_Broadband_Engine_processor_Design_and_implementation

I have a penchant for reading overly complicated technical papers... I'm done with the first one you linked (thank you!), and found this particular nugget. I don't know that it necessarily brings anything we can act on, but it's interesting all the same.

One of the major changes from the 90nm to 65nm was the reduction in pitch of the vias across the 65nm package (page 3). The paper goes to great lengths to explain the reasoning and consequences of this change, but the one I wanted to point out is this one (Mechanical analysis, page 8 - bold mine):

Incorporating a smaller C4 pitch as part of the technology
migration also raised concerns regarding the mechanical
robustness of the package interconnects. The smaller C4 pitch
required a significantly smaller interfacial contact area and
height of the C4 ball, both of which increase the strain on the
interconnect. Fortunately, the technology migration (aka,
moving from 90nm to 65nm) also
resulted in a significant die shrink. This, coupled with the
implementation of lower CTE dielectrics in the package
laminate, resulted in a lower overall strain on the interconnect
after the technology migration.

[....]

Implementing staggered vias in the
stacks and employing lower CTE dielectric in the construction
significantly reduced the strain on the vias

[...]

This via construction (the 90nm process) was removed from the 65nm
design ground-rules and replaced with a staggered via construction
that added robustness and reduced the cost of the laminate

The TL;DR is that the multi-layered construction of the cell (and possibly the RSX as well? The paper is only about Cell, but I imagine the concerns are similar) required vias across all the layers in the package -- those vias cause stress on the layers, so one of the goals with the redesign is to reduce via-induced strain. Earlier (on page 3), the paper said that the 65nm design was started before the 90nm was successfully introduced. That sounds like to me they likely knew that stacked vias (the original design) was not "ideal" and started working on a redesign right away. They were designed pretty much in parallel, which sorta explains why the chips are mostly pin-compatible.

It also seems to me that the "Power Distribution Analysis" portion is significant in understanding the Cell power supply design changes (and maybe the move away from tokins?), particularly the final paragraph. I don't think I'm fully grasping the implications, though:

One significant concern with the integration of the array
supply into the package is that it would degrade the current
distribution of the core supply, which carries most of the
current in the package. In most Cell system applications, the
core power is brought into the package ostensibly from
regulators located on the south side. Thus large core currents
are carried laterally on the package power planes. Voltage
drops in the package per se are not a problem because voltage
sense lines on the chip compensate for the general voltage
drops in the package; however, voltage drops across the chip
face are more problematic since the regulation of the supply is
typically done with voltage sensing from one location on the
chip.

 

[RIP-Felix]

Hmm... this bit doesn't sound promising...

for the memory cell size reduction in the 65 nm, an additional power supply (VddCS) was used for SRAM arrays

That could mean that it needs a different voltage than is available on 90nm boards. Meaning we don't have it available.

The issues to overcome are mounting.

• Remarry new cell (big one!)
  
• Create an adapter to mount pin-incompatible package.
• Design voltage regulation to supply unique voltages required.

It might be easier to start with the 28nm RSX. But it has a big issue of it's own. The fact we don't have a pinout and would need to create a breakout adapter to analyse logic and try to match pins for an adapter to then be made. Would be a huge undertaking!

 

[DeadEnd]

Hmm... this bit doesn't sound promising...

That could mean that it needs a different voltage than is available on 90nm boards. Meaning we don't have it available.

The issues to overcome are mounting.

• Remarry new cell (big one!)
  
• Create an adapter to mount pin-incompatible package.
• Design voltage regulation to supply unique voltages required.

It might be easier to start with the 28nm RSX. But it has a big issue of it's own. The fact we don't have a pinout and would need to create a breakout adapter to analyse logic and try to match pins for an adapter to then be made. Would be a huge undertaking!

You are right about the voltage . Designing one won't be easy for sure.

I quickly looked over the SEM-001 schematic and this is what I found.

First of all, IC6302 responsible for creating +1.2_BE_VCS in a SEM board is SN105233DBTR along with all his mosfet friends. There is also a voltage sensing line BE_VCS_FB coming from Cell and two other lines - BE_VCS_1.20_ON and BE_VCS_1.30_ON coming from Syscon. Page 27 and 22 ( in the pdf browser).






While in COK boards... You guessed it. it's not needed so the component at IC6302 is TPS5117PWRG4 (page 26 in the pdf browser)







There are also bypass caps present on SEM (page 9 in the browser)



Here's where +1.2_BE_VCS and BE_VCS_FB connect to Cell BE (page 8 in the browser)

 

[RIP-Felix]

You are right about the voltage . Designing one won't be easy for sure.

I quickly looked over the SEM-001 schematic and this is what I found.

First of all, IC6302 responsible for creating +1.2_BE_VCS in a SEM board is SN105233DBTR along with all his mosfet friends. There is also a voltage sensing line BE_VCS_FB coming from Cell and two other lines - BE_VCS_1.20_ON and BE_VCS_1.30_ON coming from Syscon. Page 27 and 22 ( in the pdf browser).

View attachment 37828

View attachment 37834
View attachment 37835

While in COK boards... You guessed it. it's not needed so the component at IC6302 is TPS5117PWRG4 (page 26 in the pdf browser)

View attachment 37831


View attachment 37833


There are also bypass caps present on SEM (page 9 in the browser)

View attachment 37829

Here's where +1.2_BE_VCS and BE_VCS_FB connect to Cell BE (page 8 in the browser)

View attachment 37830

So yeah, we could create a VRM module to create the new voltage, complete with bypassing. It's the bit about SYSCON connection that worries me. That means more analysing SYSCON changes and mimicking it's specific instructions to enable or monitor the new voltage IC.

Ugg... this is aproaching masochistic levels of challenge.

 

[DeadEnd]

It's the bit about SYSCON connection that worries me. That means more analysing SYSCON changes and mimicking it's specific instructions to enable or monitor the new voltage IC.

@M4j0r may be able to solve that... But one step at a time I guess. Not that the whole thing is necessary in the first place... But just for curiosity sake.

 

[sandungas]

You are right about the voltage . Designing one won't be easy for sure.

I quickly looked over the SEM-001 schematic and this is what I found.

First of all, IC6302 responsible for creating +1.2_BE_VCS in a SEM board is SN105233DBTR along with all his mosfet friends. There is also a voltage sensing line BE_VCS_FB coming from Cell and two other lines - BE_VCS_1.20_ON and BE_VCS_1.30_ON coming from Syscon. Page 27 and 22 ( in the pdf browser).

View attachment 37828

View attachment 37834
View attachment 37835

While in COK boards... You guessed it. it's not needed so the component at IC6302 is TPS5117PWRG4 (page 26 in the pdf browser)

View attachment 37831


View attachment 37833


There are also bypass caps present on SEM (page 9 in the browser)

View attachment 37829

Here's where +1.2_BE_VCS and BE_VCS_FB connect to Cell BE (page 8 in the browser)

View attachment 37830

The pads BE_VCS_1.20_ON and BE_VCS_1.30_ON exists in all mullion syscons, i see in your images where are connected in SEM-001 but i cant find where are conneted in COK-001 or COK-002... did you found them ?

Btw, the references such "IC6302" are not respected in between motherboards, thats the name for SEM-001, but in COK-001/2 was named "IC6301"
Different name, but is the same component... in COK-001/2 doesnt uses the BE_VCS_1.20_ON and BE_VCS_1.30_ON


EDIT:
Because an image worths hundred words... compare the first image (from COK-001/2) with your image (from SEM-001)

It seems to be one of the few cases where they added components for a new motherboard revision, but im still wondering how was used the signals BE_VCS_1.20_ON and BE_VCS_1.30_ON in COK-001/2, someone knows ?

 

[DeadEnd]

Btw, the references such "IC6302" are not respected in between motherboards, thats the name for SEM-001, but in COK-001/2 was named "IC6301"
Different name, but is the same component...

No, look closer. IC 6302 is used for producing +1,8v_VDD_MEM in both cases, while IC 6301 is used to make +1.8v_RSX_FBVDDQ in both cases.

IC6301 is the same, but IC6302 is not , because on COKs they didn't need to produce additional voltages so there is a simpler controller in place.

The pads BE_VCS_1.20_ON and BE_VCS_1.30_ON exists in all mullion syscons, i see in your images where are connected in SEM-001 but i cant find where are conneted in COK-001 or COK-002... did you found them ?

On COK boards these Syscon contacts are marked as PF1 and PF2. I don't know what that means. And they're not connected, but there are test points that can be used to tap into.

 

[sandungas]

No, look closer. IC 6302 is used for producing +1,8v_VDD_MEM in both cases, while IC 6301 is used to make +1.8v_RSX_FBVDDQ in both cases.

IC6301 is the same, but IC6302 is not , because on COKs they didn't need to produce additional voltages so there is a simpler controller in place.

Ok, i see what you mean, btw another way to identify which one is each is to look at the "SW_xx" signals, thats syscon outputs to enable the chips, and that names are respected in all the manuals we have (and probably some of them exists with the same names even in PS3 superslim models)
What i meant is the component in this image is also a SN105233DBTR (labeled as IC6301)
But i didnt realized in SEM-001 there are two SN105233DBTR

On COK boards these Syscon contacts are marked as PF1 and PF2. I don't know what that means. And they're not connected, but there are test points that can be used to tap into.

View attachment 37845

I just realized, this service manuals are a pain to navigate, btw, someone thought in editing them to improve that shitty bookmarks/index ?, everytime i need to search something i have to scroll all the pages just trying luck

Awesome, so that pads named PF1 and PF2 in the COK-001/2 manuals seems to be something that was ready to be used since day one but was not used in COK-001/2, i wonder if there is some mention about them in the BCU-100 manual or if is inherited from pre-retail prototypes... never minds, right now i dont have the courage to dig so deep

 

[truemaster]

so guys you actually gona try cell swap will smaller factor nm? its getting crazy but i like it