ElGris
Senior Member
This is my little help for the project. Let me know if you want another hot pic of that beauty ^^
https://imgur.com/a/vuHGprh
https://imgur.com/a/vuHGprh
M4j0r
Developer
This is how Syscon sees the different hardware revisions (verified by Lv1 debug output and the Syscon eeprom) on Phats:
CELL 90nm (0x31) and 65nm (0x40) models are not pin compatible, the same applies for the different South Bridge revisions.
Which means that the RSX is the only part which can be changed cross revision.
These are the minimal retail Syscon ROM versions for the revisions:
In short: 90nm RSX is supported by all, 65nm since 302GB (DIA-002) and 40nm since 303GB.
So you can use other RSX revisions, but you need a compatible Syscon.
If Sony did more changes to this system, I can hopefully analyse them after getting the full eeprom dump.
Code:
CELL: 0x31: TMU-510, TMU-520, COK-001, COK-002
0x40: SEM-001, DIA-001, DIA-002, VER-001, DEB-001
SB: 0x31: TMU-510, COK-001
0x32: TMU-520
0x40: COK-002
0x50: SEM-001, DIA-001, DIA-002, VER-001, DEB-001
RSX: 0x10: TMU-510
0x11: TMU-520, COK-001, COK-002, SEM-001, DIA-001
0x21: DIA-002, VER-001, DEB-001, DYN-001
0x30: SUR-001, ...Which means that the RSX is the only part which can be changed cross revision.
These are the minimal retail Syscon ROM versions for the revisions:
Code:
CELL: 0x31: 201GB (v1.0)
0x40: 203GB (v1.2)
SB: 0x31: 201GB (v1.0)
0x40: 202GB (v1.1)
0x50: 203GB (v1.2)
RSX: 0x11: 201GB (v1.0)
0x21: 302GB (v1.4)
0x30: 303GB/304GB (v1.5)So you can use other RSX revisions, but you need a compatible Syscon.
If Sony did more changes to this system, I can hopefully analyse them after getting the full eeprom dump.
Last edited:
You could do with high resolution scans of the motherboard really to compare. At this kind of quality:
Unfortunately I only have a COK002 here. Maybe someone with a decent scanner has a COK001 lying around. Linked a COK002 image anyway in case it might be useful to someone. It a 20MB composite made from 2 scans, over 14000x11000 pixels. I cant really get a good scan of the other side.
https://imgur.com/a/9meGXek
Edit: Imgur has scaled it down so I've attached a full res version here too:
http://xmbmods.com/temp/COK002_1.jpg
Unfortunately I only have a COK002 here. Maybe someone with a decent scanner has a COK001 lying around. Linked a COK002 image anyway in case it might be useful to someone. It a 20MB composite made from 2 scans, over 14000x11000 pixels. I cant really get a good scan of the other side.
https://imgur.com/a/9meGXek
Edit: Imgur has scaled it down so I've attached a full res version here too:
http://xmbmods.com/temp/COK002_1.jpg
Last edited:
Cypher_CG89
Senior Member
Someone with a COK-001 and smartphone that has a camera that's 13mp (13 mp res = 4160 x 3620, above 4K resolution) or above will do.
Ok, so based on the dump data @lcferrum sent me, I can confirm the console has been refurbished (chassis check 0xFxxx, customer ID starting with 0x0FFF00, 0x000300680100 instead of 0x000200600100 in cISD1, etc, etc...).
In add:
metldr rev key is 0x99873BC715F280809C302225
bootldr rev key is 0xCB9E152428B44FD2F93FBC43
Those keys are those we find on the regular 2K5 CEX consoles with minimum firmware version 3.40. And are those we find usually on most of the late refurbished consoles.
The trvk_prg0 content is from FW 3.40 "from factory" (because is not from the RL_FOR_PROGRAM.img of the publicly released CEX 3.40 PUP).
So my feeling is something like this :
The mainboard has been replaced with a late "special" spare serie of COK-001 mainboard with 3.40 preinstalled. Then, they updated to the latest available firmware (4.11, march 2012) before to send it back to the customer.
So it has been refurbished between march and july 2012.
That's all I can say.
In add:
Code:
"From Factory" system version, version build and date string from eeprom (at 0x02F00):
04.110055445,20120302
"Minimum Downgrade" version:
1.00
Plateform ID:
Cok14metldr rev key is 0x99873BC715F280809C302225
bootldr rev key is 0xCB9E152428B44FD2F93FBC43
Those keys are those we find on the regular 2K5 CEX consoles with minimum firmware version 3.40. And are those we find usually on most of the late refurbished consoles.
The trvk_prg0 content is from FW 3.40 "from factory" (because is not from the RL_FOR_PROGRAM.img of the publicly released CEX 3.40 PUP).
So my feeling is something like this :
The mainboard has been replaced with a late "special" spare serie of COK-001 mainboard with 3.40 preinstalled. Then, they updated to the latest available firmware (4.11, march 2012) before to send it back to the customer.
So it has been refurbished between march and july 2012.
That's all I can say.
lcferrum
Member
@M4j0r, assuming that there are no other changes from Sony, how can SYSCON version be upgraded on ordinary PS3? As I understand, now that we have SYSCON decryption keys, it is possible to make a homebrew SYSCON patch and install it with CFW. Is it possible to make a patch that will upgrade Phat SYSCONs to needed 1.5 version?
M4j0r
Developer
Yeah, that's weird, I don't think 1.00 supports a 40nm RSX. This is also a problem on DECR systems which allow you to easily brick one. Sony doesn't check the rsx version somehow.
This would match the copyright date on the Syscon (2010), fw 3.40 is also from 2010.
Sadly no, the patch is very limited in terms of how much it can patch and the newer RSX revisions need newer RRAC (FlexIO) training routines which simply don't fit into the patch. Like the new routines for the 40nm RSX need ~0x6000 bytes but the whole patch only has about 0x3C0 bytes of space.
Maybe you can somehow make it work but that needs a lot of testing.
Are the syscons locked to the console? I vaguely remember people doing chipset transplants, and they needed to swap the syscon with everything else?
In other words, if I pull the 65nm GPU and the 301GB syscon from a CECHJ or CECHK, you're saying it should work if I throw them on a CECHA?
Going further ....do the SW series syscon chips function exactly the same as the CXR chips and have all the same pins? An interposer for that would be trivial. I could whip one up in less than a case of beer so we could get down to 40nm.
In other words, if I pull the 65nm GPU and the 301GB syscon from a CECHJ or CECHK, you're saying it should work if I throw them on a CECHA?
Going further ....do the SW series syscon chips function exactly the same as the CXR chips and have all the same pins? An interposer for that would be trivial. I could whip one up in less than a case of beer so we could get down to 40nm.
M4j0r
Developer
Syscon is paired to the CELL. The easiest way to swap them would be to just copy the eeprom contents from one syscon to another, then you're done. You can also remarry them like the bd drive but that's more complex and only needed if you don't have the original data.
Sony also changed the eeprom layout between the 201GB/202G (Cookie old) and later (Cookie new) ROM versions: https://pbs.twimg.com/media/ENs1zGGXUAIwnZl?format=png&name=large but that's easily fixable.
Yes, but maybe the pcb needs some "patches" like on this console. You can already see some differences between the RSX pads on the COK-002 and SEM-001 if you look at the service manual. The software is compatible.
They serve the same function and the main components do have the same interface, but I don't know if Sony made them backwards compatible or if the misc io stays the same. They also run a completly different firmware. About the package: SW is QFP, CXR is VFBGA.
The SW2 is currently under attack
.techfury90
Forum Noob
I've been wondering about this: how does Sony actually install/update bootldr/metldr in refurbished consoles? We know they're encrypted using a key inside the Cell chip, one that we can't read. But yet, Sony seems able to reprogram them at service centers, but never in the field by updates.
It feels like a chicken and egg problem to me: how does Sony encrypt bootldr and metldr for a specific console? Master key database? Some sort of magical alternate key hidden in the on-chip bootloader that can be used to boot a special payload that encrypts bootldr/metldr for a specific console? Makes you wonder...
M4j0r
Developer
They use a database. CID and eCID are also stored inside CELL.
The firmware has functions to update the metldr/bootldr but they're never used in the field.
The perconsole loaders of CEB prototypes were updated with every firmware update.
I stared at them for both for awhile, and I think they're just "cosmetic" changes and some more NC or grounded pads due to different layouts and peripherals on each board. My gut tells me official Sony engineer approved procedures would not include any bodges underneath of a BGA package. If they did cut a trace, I would expect any cut to have a corresponding new connection elsewhere to avoid floating inputs. My money is on no funny business underneath the chip, and that the pinouts match. I'll try again when I get the right candidates.
techfury90
Forum Noob
Key database referenced by CID/eCID makes a lot of sense. I wonder why they quit updating it in the field with retail units. Perhaps it was judged as too risky? But on the other hand, Sony didn't seem particularly concerned about being able to recover from a brick, given that they provided no means with which to switch over to the alternate copy of CoreOS (or even try to do so automatically if the designated primary side failed verification) in the event of a brick.
That also reminds me, do you have a hypothesis as to how Sony programmed the NAND at the factory on COK-001 boards? It's strange that the test points for the SS2 are not usable for brick recovery, but yet no other obvious method seems to exist for programming the flash...
sandungas
Developer
Most probably what they does is at factory, when the motherboard is ready they connects it to a "jig-pin machine" that is like a frame with hundreds of pogo pins that connects with all the testpads of the motherboard, and is connected with a PC that have access to the internal database servers
This way they can collect all id's serials, keys, etc... from all the PS3 production in a massive unique database
And at the time a PS3 enters in a repair service they can either recover/update/delete that info from the database
And yeah, the "SoftWare Updaters" inside PS3UPDAT.PUP (named swu.self and swu2.self) doesnt allows to update the metldr/bootldr for safety reasons
(i remember years ago there was some underground theories about how to do it but never was posible to achieve it)The NAND's are connected with each other using an intermediate controller named "starfield2"... the testpads in the motherboard belongs to the starfield2 (so you are interacting with starfield2 when you connect to them, not with the NAND's)... but the starfield2 uses some kind of encryption/security... so we was never able to deal with it
The NAND flashers "bypasses" the starfield2
Last edited:
techfury90
Forum Noob
Yeah, that makes plenty of sense. Bed of nails tester would be par for the course for a PCB assembly line, easy to flash through one. It's also clearly how they did it for the NOR consoles, given their flash points. This makes more sense now, so it's not that the points are inherently unusable, we just don't know how to talk to it.
M4j0r
Developer
Yes, nothing underneath the BGA package, but somewhere else like the Clock gen reset we've seen here.
The interface between the South Bridge and StarShip2 is called EBUS. The prototype version of the StarShip is an off the shelf TDK part (SS1 = CXD9823, SS2 = CXD4302), both are based on the TDK GBDriver XR1 ("NAND to ATA" adapter), you can even find the drivers in some linux kernel versions. The NAND file system is proprietary.
The "EBUS" (External BUS) is just an "external SRAM" bus, Sony just uses different drivers for the SS2 and NOR version.
I had a look at the EEPROM of this console and the things which Sony changed are:
Code:
1.) Removed XDR config
2.) New fan table
3.) Changed RSX revision
4.) 6 bytes changed in an unreferenced area (0x3FA2)1.) is because Sony now uses the fallback in the firmware instead of writing the old values to the EEPROM, so nothing special.
4.) The "customer service area" isn't changed so maybe they use this offset instead? I haven't found any use of this offset in the sc firmware yet and the main firmware can't access it.
Last edited:
Similar threads
-
-
PS3 PS3 CECHA RSX Swap (40nm) – JP Limited – SYSCON Patch, VDDC Mod – Need Detailed Help- Started by jw0710
- Replies: 4
-
-
