DeadEnd
Senior Member
He was talking about "motherboard revision" though... But I can't find datasheets for BD35287 either...
He was talking about "motherboard revision" though... But I can't find datasheets for BD35287 either...
vyktormvmpay25
Senior Member
D35282 from my previous photos is on left side of rsx bottom mobo.
DeadEnd
Senior Member
Well, clearly I misunderstood you about the Offsets. It was for the firmware... So that's all that's needed then? I just overwrite values with the ones you provided at those offsets?
I found them by looking at HEX of the CWF, yet there is a spanish text at those offsets. Did you use OWF then? Does it have to be specific version?
I appreciate the explanations on how the patch is built, etc. I had no idea there are actually several other tools needed to decrypt/unpack it. But since you understand this topic much better, perhaps you could then possibly share the offsets and patch for COK-002, and we can just move on to the next steps? I couldn't even find a working link for that unpkg tool.
Ok, as I was writing this, I started realizing a little bit of what you mean... You probably can't know the right offsets for every CWF or OWF, since you only see them after patching, encrypting and packaging the PUP. So in my case, it's probably just better to understand how to make them for my particular system and firmware... And now that you've explained what tools are needed, it helps to see the logic.
Last edited:
nCadeRegal
Senior Member
Nice community effort here guys. This is amazing to follow. I have been reading this thread since day one and it looks like you guys are beginning to get a really good understanding of how this all works. Good luck, I am eager to see the finished results.
M4j0r
Developer
I won't go over how to work with the main ps3 firmware. You need to know how to deal with that else you brick your PS3.
And remember, the syscon patch is inside the corresponding SYS_CON_.....pkg. I linked an example output from my decoding tool earlier, you can use that to match what you've decrypted.
The COK-002 firmware hasn't been dumped yet, so nobody can find the needed offsets.
It's not that I have some secret notes here, everything including the theory and tools have been released on the psdevwiki and on this forum (and other ones too). It's just that I work on reversing/documenting this information, if I would be providing noob friendly solutions, I wouldn't have time to work on the actually hard part.
M4j0r
Developer
No, you need the syscon firmware, which is not part of the PUP.
vyktormvmpay25
Senior Member
Would flashcat jtag be good to do dump cok002. I may need some scrip for atmega 32u2 if so.
Syscon out of board.
Syscon out of board.
DeadEnd
Senior Member
One last question before I give up on the syscon endevour.
You still refer to 'patches' and firmwares in a way that is easy to mix up. There is the patch inside PUP - a pkg file. Then there is a Firmware, as in CWF or OFW, then there is also a Syscon firmware that is separate and cannot be dumped with a pup. Correct?
So I got a CWF from evilnat now installed on COK002. At this point, can I now dump the syscon FW over UART ? Do I need any special script for it? You wrote here while ago, but not sure which script you were referring to:
M4j0r
Developer
The main PS3 FW is a PUP file, and it contains a patch for the syscon firmware. The syscon firmware is only stored on syscon itself as well as the currently applied patch.
No, you need to overwrite the syscon patch which is saved on the syscon with a blank syscon patch contained in a modified PS3 FW, then you use the syscon UART interface to install a special dump patch.
DeadEnd
Senior Member
Alright, got it now. Thank you.
RIP-Felix
Senior Member
I wasn't sure if there were schematics for those model PS3s. I only work on A models and am looking for the equivalent VRM for the RSX_VDDR.
It appears these "D35_ _ _" IC's are all pretty similar. Same function different features. The only difference I see are resistors that set the voltages properly are either inside (fixed) or set by the user with the pads provided on the board.
They all are set to the same voltages, so I don't think it really matters unless that chip is bad or allows too much noise through.
That may have been what happened in the second console swap. However, we should measure the voltages and noise characteristics on all the donor and recipient consoles, just to be sure the electrical environment is verified to be the same. Then if it doesn't work, we know the hardware is not why. Will make things easier for the software guys.
Of course, we're just speculating on the changes seen in the few pictures and 2 consoles we have to go off of. And I'm not an EE! I just watch videos and read the datasheets I can find. That should be disconcerting. If there's a real EE out there, you should be double checking our work and chiming in (unless you're having too much fun laughing - I'm sure SONY is).
It appears these "D35_ _ _" IC's are all pretty similar. Same function different features. The only difference I see are resistors that set the voltages properly are either inside (fixed) or set by the user with the pads provided on the board.
They all are set to the same voltages, so I don't think it really matters unless that chip is bad or allows too much noise through.
That may have been what happened in the second console swap. However, we should measure the voltages and noise characteristics on all the donor and recipient consoles, just to be sure the electrical environment is verified to be the same. Then if it doesn't work, we know the hardware is not why. Will make things easier for the software guys.
Of course, we're just speculating on the changes seen in the few pictures and 2 consoles we have to go off of. And I'm not an EE! I just watch videos and read the datasheets I can find. That should be disconcerting. If there's a real EE out there, you should be double checking our work and chiming in (unless you're having too much fun laughing - I'm sure SONY is).
DeadEnd
Senior Member
I may have missed a few things here, but if 1.5v on this pic is not VDDR, then the whole voltage clarification is indeed irrelevant . (though the reset resistors might still hold some ground.)
It's better to focus on the syscon manipulations... However that is not as simple as one would hope. Seems like Bus Pirate is the easiest route after all...
Last edited:
sandungas
Developer
Btw, there is a very clarifying image posted by @M4j0r some weeks ago in this post
Correct me if im wrong in something of what im going to say...
This is the eeprom map of a syscon CXR series (doesnt applyes to syscon SW1/2/3 series because it seems they uses some kind of "virtual map")
The syscon firmware is everything that appears in that table, except the areas named "Patch part 1" and "Patch part 2" (it seems the name "patch" is an official codename btw), the whole syscon firmware is written at factory (so the only way to make a copy of it is by reading it from inside syscon)
Think in the "Patch part 1" and "Patch part 2" as "slots" that are empty from factory, and are ready to install a patch in them
As you can see in this info screens there are some PS3 models where the patch areas are empty. In the image im posting is indicated by the third info line most at top where it tells 098F @ 0000000000000 @ SC
The 098F is an identifyer of the syscon ID (im not going to enter in more details, but indicates which patches from inside the PUP are applicable to the syscon hardware)
And all the 0000000000000 means that the patches "slots" from inside the syscon eeprom are empty
https://www.psdevwiki.com/ps3/More_System_Information
And the reason why are empty in this screenshot, is because well... im playing dirty because thats an screenshot of a PS3 superslim, and as you can see in this table doesnt exists any official syscon patch applicable to superslims (with syscon ID 098F)
https://www.psdevwiki.com/ps3/System_Controller_Firmware#Known_Retail_syscon_update_packages
I can tell you @M4j0r is not hiding much info, is just there are hundreds of things that needs to be explained before getting your hands dirty with this, also, as far i seen, everytime he writes something technical (thats most of his posts, lol) he is trying to cover all scenarios posibles:
-With a CFW installed (and considering the posible gameOS tools/apps that could be published in the future)
-With a PS3 that doesnt boots (where is needed to do everything by hardware)
-Without syscon patches installed (so is a bit easyer because we have the patch "slot" available to write our custom stuff)
-With syscon patch installed (so first step is to delete the installed patch to make room for our stuff)
-Etc...
As far i see there are many ways to do this, and im not so sure what we will be using in the future
Another btw... i think (but im not sure) the way how syscon loads the data is by using some kind of "overlay" where the patch is "pasted" on top of the base firmware... but this happens on runtime, the original data is still there is just syscon loads the data in the patch instead the original
The original data areas that can be patched is a bit doubful for me, in the other thread about the syscon keys we was talking about it, i was wondering if it could be posible to patch the "thermal config" area just by running an app in a CFW (that app doesnt exists though)
Correct me if im wrong in something of what im going to say...
This is the eeprom map of a syscon CXR series (doesnt applyes to syscon SW1/2/3 series because it seems they uses some kind of "virtual map")
The syscon firmware is everything that appears in that table, except the areas named "Patch part 1" and "Patch part 2" (it seems the name "patch" is an official codename btw), the whole syscon firmware is written at factory (so the only way to make a copy of it is by reading it from inside syscon)
Think in the "Patch part 1" and "Patch part 2" as "slots" that are empty from factory, and are ready to install a patch in them
As you can see in this info screens there are some PS3 models where the patch areas are empty. In the image im posting is indicated by the third info line most at top where it tells 098F @ 0000000000000 @ SC
The 098F is an identifyer of the syscon ID (im not going to enter in more details, but indicates which patches from inside the PUP are applicable to the syscon hardware)
And all the 0000000000000 means that the patches "slots" from inside the syscon eeprom are empty
https://www.psdevwiki.com/ps3/More_System_Information
And the reason why are empty in this screenshot, is because well... im playing dirty because thats an screenshot of a PS3 superslim, and as you can see in this table doesnt exists any official syscon patch applicable to superslims (with syscon ID 098F)
https://www.psdevwiki.com/ps3/System_Controller_Firmware#Known_Retail_syscon_update_packages
I can tell you @M4j0r is not hiding much info, is just there are hundreds of things that needs to be explained before getting your hands dirty with this, also, as far i seen, everytime he writes something technical (thats most of his posts, lol) he is trying to cover all scenarios posibles:
-With a CFW installed (and considering the posible gameOS tools/apps that could be published in the future)
-With a PS3 that doesnt boots (where is needed to do everything by hardware)
-Without syscon patches installed (so is a bit easyer because we have the patch "slot" available to write our custom stuff)
-With syscon patch installed (so first step is to delete the installed patch to make room for our stuff)
-Etc...
As far i see there are many ways to do this, and im not so sure what we will be using in the future
Another btw... i think (but im not sure) the way how syscon loads the data is by using some kind of "overlay" where the patch is "pasted" on top of the base firmware... but this happens on runtime, the original data is still there is just syscon loads the data in the patch instead the original
The original data areas that can be patched is a bit doubful for me, in the other thread about the syscon keys we was talking about it, i was wondering if it could be posible to patch the "thermal config" area just by running an app in a CFW (that app doesnt exists though)
Last edited:
M4j0r
Developer
Yes, the Sherwood (SW) uses a virtual mapping to create the nvs for you if you read it, it's not stored continuously on the flash eeprom like on the Mullion (CXR). But since we can't simply read it via hardware, it doesn't matter.
The fimware is actually already applied at the chip factory, it's a mask rom, not a PROM (same goes for the Sherwood, Sony orders them already programmed from NEC but it's flash technology so you can change it (but it's disabled for security reasons)).
Patch Part 1 and Patch Part 2 are actually only one patch, Sony splits them into the main patch and the hdmi patch section. The Sherwood patch is also splitted but saved in one place.
The "soft id" is actually just the build id of the syscon firmware.
The fastest way for a repair shop is just to use the hardware eeprom interface (SPI) on the CXR. The SW always needs a working PS3 since you can't program the patch over the UART interface, the only way to do it via hardware is to glitch it. But if you want to put a newer RSX on these units you need to glitch it in order to update the firmware either way.
If you want a user friendly solution (for changing the fan settings etc.) you need to pack the patches into the PS3 firmware. I provided the example patches, which fully unlock the syscon eeprom to the CELL side (usable by lv1) and the UART. This enables you to do anything with the eeprom. Then you just need to use the syscon device access service through the lv1/lv2 interface in a user program - that already exists.
Yes, Sony is using a special device for that on the CXR (since you can't overwrite ROM), on the SW it all happens in RAM.
The patch is only really meant to patch the (not rewritable) firmware ROM, using it for the eeprom would be wasteful, since you can just rewrite it. As explained above you just use the existing lv1 interfaces through lv2 to overwrite/read any eeprom region.
sandungas
Developer
Im shy to ask about it because probably is mentioned somewhere in psdevwiki but i cant find it
There is some image or table where we could see the eeprom map after that "virtualization" has been removed ?
For me that image you posted with the map of CXR has been very useful since some weeks ago (to try to digest the technical info published about all this stuff), but now since the virtualization used in sherwood i feel a bit lost
Ok, so is a single patch divided in half.. and it allows to patch 4 addressess
The patch to "unlock" the gameOS access to eeprom requires to patch 3 addressess... and the fourth is better to reserve it by now for all other posibles hacks/eastereggs that could be found in the future
The fact some of that patch data is related to HDMI represents a restriction for us... or we can repurpose that hdmi stuff to patch other data ?
Well, after thinking in all this i guess is better to include inside the PUP the (common) patch to unlock syscon, after that use a program to change the thermal config with the "set" command (that doesnt makes permanent changes to the eeprom) to try some configurations, and when we are satisfyed with it write the custom thermal config permanently into eeprom
And after that keep the syscon "unlocked" forever, just incase we need to acces it for other magic tricks in the future
M4j0r
Developer
I'll maybe reverse the virtual to physical mapping, but the lv1 accessible nvs regions are already documented here: https://www.psdevwiki.com/ps3/SC_EE..._Block_Offset_Mapping_Table_.28NVS_Service.29 . The physical offsets on the SW can even differ between some chips, but since both the UART and lv1 interface work with virtual addresses, we don't really need the physical ones.
You can patch HDMI functions (which is used to dump the firmware but not useful in other cases) or increase the space for the optional patch code, but you won't get more than 4 universal patch offsets.
Yes, that's probably the best solution.
ElGris
Senior Member
I have the readings, both mobos have 1.5v exactly on that point. In the PPX one, IC 323504Q has a different name but it looks like it's doing the same thing than D35287, pin nº 5 and 6 are feeding RSX with 1.5v, while pin 8 is GND, on both ICs. In the schematic of the BD3520 IC we have a different configuration, where GND is pin nº 2, Am I right? Well, it seems these two ICs (BD3520 and D35287) are electronically different but are doing the same task, but with a difference of 0.3V. What do you think?
Also, I found another D35287 in the back of a RTX's RSX, and everything looks the same.
What happens with that resistor change on that modified CECHA?
Attachments
Similar threads
-
-
PS3 PS3 CECHA RSX Swap (40nm) – JP Limited – SYSCON Patch, VDDC Mod – Need Detailed Help- Started by jw0710
- Replies: 4
-
-
