Frankenstein PHAT PS3: CECHA with 40nm RSX

Discussion in 'General PS3 Discussion' started by lcferrum, Feb 2, 2020.

  1. 6,910
    6,512
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    6,910
    Likes Received:
    6,512
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    I mean this one from the COK-001 top side (for the bottom side there is none at that size)
    https://www.psdevwiki.com/ps3/images/9/9d/COK-001_TOP.JPG
     
  2. 28
    43
    12
    lcferrum

    lcferrum Forum Noob

    Joined:
    Feb 2, 2020
    Messages:
    28
    Likes Received:
    43
    Trophy Points:
    12
    Gender:
    Male
    Well, yes, topside photo is ok actually. So I'm looking for the COK-001 backside photo of the same quality.
     
  3. 265
    164
    72
    ElGris

    ElGris Member

    Joined:
    Sep 19, 2019
    Messages:
    265
    Likes Received:
    164
    Trophy Points:
    72
    Squiglemouse likes this.
  4. 28
    43
    12
    lcferrum

    lcferrum Forum Noob

    Joined:
    Feb 2, 2020
    Messages:
    28
    Likes Received:
    43
    Trophy Points:
    12
    Gender:
    Male
    @ElGris, this will do, thanks!
     
  5. 63
    133
    57
    M4j0r

    M4j0r Member

    Joined:
    May 4, 2017
    Messages:
    63
    Likes Received:
    133
    Trophy Points:
    57
    Gender:
    Male
    Home Page:
    This is how Syscon sees the different hardware revisions (verified by Lv1 debug output and the Syscon eeprom) on Phats:
    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, ...
    
    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:
    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)
    
    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.
     
    Last edited: Feb 12, 2020
  6. 8,288
    9,410
    797
    DeViL303

    DeViL303 Developer PSX-Place Supporter

    Joined:
    Jan 23, 2016
    Messages:
    8,288
    Likes Received:
    9,410
    Trophy Points:
    797
    You could do with high resolution scans of the motherboard really to compare. At this kind of quality:

    upload_2020-2-10_18-12-9.png

    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: Feb 10, 2020
    sandungas and Cypher_CG89 like this.
  7. 3,389
    1,835
    297
    Cypher_CG89

    Cypher_CG89 Senior Member

    Joined:
    Jul 30, 2018
    Messages:
    3,389
    Likes Received:
    1,835
    Trophy Points:
    297
    Gender:
    Male
    Occupation:
    Lead Graphic Artist/Dev, VENOM ELITE GAMING
    Location:
    North East, England, UK
    Home Page:
    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.
     
  8. 1,226
    1,279
    272
    littlebalup

    littlebalup Developer PSX-Place Supporter

    Joined:
    Oct 16, 2014
    Messages:
    1,226
    Likes Received:
    1,279
    Trophy Points:
    272
    Location:
    43°36'16.0"N 1°26'36.1"E
    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:
    Code:
    "From Factory" system version, version build and date string from eeprom (at 0x02F00):
    04.110055445,20120302
    
    "Minimum Downgrade" version:
    1.00
    
    Plateform ID:
    Cok14
    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.
     
    sandungas, Cypher_CG89 and DeViL303 like this.
  9. 28
    43
    12
    lcferrum

    lcferrum Forum Noob

    Joined:
    Feb 2, 2020
    Messages:
    28
    Likes Received:
    43
    Trophy Points:
    12
    Gender:
    Male
    @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?
     
  10. 63
    133
    57
    M4j0r

    M4j0r Member

    Joined:
    May 4, 2017
    Messages:
    63
    Likes Received:
    133
    Trophy Points:
    57
    Gender:
    Male
    Home Page:
    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.
     
    sandungas likes this.
  11. 94
    103
    32
    squeept

    squeept Member

    Joined:
    Sep 20, 2019
    Messages:
    94
    Likes Received:
    103
    Trophy Points:
    32
    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.
     
    nCadeRegal likes this.
  12. 28
    43
    12
    lcferrum

    lcferrum Forum Noob

    Joined:
    Feb 2, 2020
    Messages:
    28
    Likes Received:
    43
    Trophy Points:
    12
    Gender:
    Male
    Is it possible to simply switch CXR SYSCON chips, do they have any per-console data? If it is possible, than at least we will be able to use 65nm RSX on BC Phats with DIA-001 and DIA-002 SYSCONs.
     
  13. 63
    133
    57
    M4j0r

    M4j0r Member

    Joined:
    May 4, 2017
    Messages:
    63
    Likes Received:
    133
    Trophy Points:
    57
    Gender:
    Male
    Home Page:
    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 ;) .
     
    sandungas likes this.
  14. 6
    1
    7
    techfury90

    techfury90 Forum Noob

    Joined:
    Aug 2, 2019
    Messages:
    6
    Likes Received:
    1
    Trophy Points:
    7
    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...
     
    sandungas likes this.
  15. 63
    133
    57
    M4j0r

    M4j0r Member

    Joined:
    May 4, 2017
    Messages:
    63
    Likes Received:
    133
    Trophy Points:
    57
    Gender:
    Male
    Home Page:
    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.
     
  16. 94
    103
    32
    squeept

    squeept Member

    Joined:
    Sep 20, 2019
    Messages:
    94
    Likes Received:
    103
    Trophy Points:
    32
    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.
     
  17. 6
    1
    7
    techfury90

    techfury90 Forum Noob

    Joined:
    Aug 2, 2019
    Messages:
    6
    Likes Received:
    1
    Trophy Points:
    7
    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...
     
  18. 6,910
    6,512
    622
    sandungas

    sandungas Moderator Developer

    Joined:
    Dec 31, 2014
    Messages:
    6,910
    Likes Received:
    6,512
    Trophy Points:
    622
    Location:
    Babylon 20xxE series
    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 :D (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: Feb 11, 2020
    techfury90 likes this.
  19. 6
    1
    7
    techfury90

    techfury90 Forum Noob

    Joined:
    Aug 2, 2019
    Messages:
    6
    Likes Received:
    1
    Trophy Points:
    7
    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.
     
  20. 63
    133
    57
    M4j0r

    M4j0r Member

    Joined:
    May 4, 2017
    Messages:
    63
    Likes Received:
    133
    Trophy Points:
    57
    Gender:
    Male
    Home Page:
    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)
    
    2.) and 3.) are obvious.
    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: Feb 11, 2020
Tags:

Share This Page