PS3 Frankenstein PHAT PS3: CECHA with 40nm RSX

DeadEnd said:
@M4j0r was my source for this information. But you can hear it from him too if it helps...
Click to expand...
Yes it would be very helpful for all to understand because I can't see how the chips would even be able to do that by themselves. How would a fault in the FlexIO data lines (common fault) be possibly detected and reported then if there is no communication between it and the CPU?
Why does a bittraining error pop up if I cut one of those data traces with a knife?
How could something like that be detected if they are doing it "on their own" individually in isolation?
What is BitTraining even about then?
 
M4j0r said:
Syscon is the calibration master and CELL, RSX, SB all take part in the calibration process, of course in conjunction with the connected chip, but not coherently. Just from the name "interface calibration" it's easy to tell that not the link but the interface gets calibrated. So each chip can do it on it's own, but I guess that's not what the starting question is about.
Syscon first handles the CELL <-> SB link and then the CELL <-> RSX link - it'll ask SB and RSX if everything went fine. If yes it'll ask CELL if the links are good.
Click to expand...
Ok the answer came while I was asking.
Thank you and sorry if this was a bit distracting. It is a complex thing after all
Syscon first handles the CELL <-> SB link and then the CELL <-> RSX link - it'll ask SB and RSX if everything went fine. If yes it'll ask CELL if the links are good
Click to expand...
So of course CELL CPU is always involved in the bittraining. I hadn't gone crazy...
And that's why 3034 it is accordingly listed in the manual as a broad CPU error
 
Last edited:
M4j0r said:
Yes, if you look at the list of FlexIO IDs that's not the first time (the SX SB has a lower ID than the PX SB).

I don't know which chip corresponds to which ID, but the SUR-001 came only with the 21 EC. All later boards support 21 EC or 21 EB, Syscon detects which chip is used and selects the right data.
Click to expand...
I resumed the problem in this edit (and i reverted my changes later because im not completly sure about it)
https://www.psdevwiki.com/ps3/index.php?title=Talk:Rambus_Registers&diff=65634&oldid=65596

Most people (me included) is going to read the list you published "from top to bottom" thinking the most at top is the oldest and most at bottom is the newest

But it seems sony was so weird with the 40nm RSX that they inverted the hardware models "etched" in the IHS of the 40nm RSX's

In plain words... the first 40nm RSX models that entered in retail production was given the name CXD5300xxx and CXD5301xxx... that ones are the "v1" (if we think about hardware identifyers)
But if we think in software identifyers is the other way around, actualy you assigned the unnofficial name "v1" to the lower software ID because you was thinking in software identifyers only

I dont know either which RSX hardware models are each RSX software ID, but i think we should stop using that concept of "v1" and "v2" in the 40nm RSX models. The only accurate way i see is to mention the hardware model "by series"
Thats what i was trying to do when i modifyed my previous post with your syscon patches... sadly we are at a point where we need to make some assumptions and wait for the feedback of other people to see if our speculations are right

The dilemma we have right now can be summarized into this:
-We have 3 series of 40nm RSX hardware models (CXD5300xxx, CXD5301xxx, CXD5302xxx)
-But we have only 2 software ID's for them, so we ned to make 2 groups with them
-One of the groups "should" be composed by 2 series... and the other group "should" be the other serie
-You suggested to start trying with 21EC because thats what did work for you... and vyktor said the RSX had his own IHS (so is either a CXD5300xxx or a CXD5301xxx)
-David/felix said they did a successful frankentein with a CXD5301xxx using 21EC

By now we have
CXD5300xxx = posible 21EC (from your PS3)
CXD5301xxx = 21EC (from david)
CXD5302xxx = no reports

Deadend made a frankenstein but it was a 65nm RSX (so the RSX model doesnt matters because all the 65nm RSX shares the same software ID). Vyktor made another frankenstein but as far i remember he didnt mentioned the exact RSX hardware model and the software ID of the RSX he used, so please @DeadEnd @vyktormvmpay25 @RIP-Felix keep attention to this and report back the results, im not telling only about your own tests, but also if you see someone in forums or chats doing this frankensteins with a 40nm RSX ask them about the hardware model and the software ID they used

I guess this is not going to take us much time, we just need a few successful reports, if we are lucky it will be simple, my hope is we are going to be able to identify them by the presence of the IHS (the CXD5302xxx without IHS should be the 21EB) but is just a theory
 
Last edited:
Btw, the other day i was doing some "hexeditor views" of the thermal config formats in wiki in the most intuitive way i found, the page is still a work in progress but it allows to show you a couple of related things
https://www.psdevwiki.com/ps3/Syscon_Thermal_Configs

Is better explained in that page, but i made an screenshot to show you the bytes we are changing with the frankenstein syscon patches
Untitled-1-copy.png

As you can see there are 3 thermal config formats, but the byte/s we need to modify are exactly in the same position in the first 2 formats (in other words, is the same offset for all mullion syscons)
In sherwood syscons we need to modify only 1 byte because is not repeated (the mullions are repeating it twice)

The samples i used are not random, as you can see i choose to show 3 different thermal config formats... but in the last 2 samples was used a 40nm RSX ;)
The original thermal config of COK-001 motherboard is the sample at left... compare the values in it with the sample at center (COK-001 with the official 40nm RSX refurbished and the last mullion syscon CXR714120-304GB)

The "problem" they had is the CXR714120-304GB requries to use second thermal config format (the structure shown in the sample at the center) so they "ported" all the values from the old format to the new format WITHOUT MODIFYING ANY TEMPERATURE OR SPEED !
The only value they modifyed is this bytes im talking about related with the RSX revision... we dont know what is it but for sure is important because is the only worthy thing they did of that porting in between thermal config formats
I dont use to subestimate sony engineers, but this was lame... i mean... they was taking all the temperaures and speeds from the original 90nm RSX to use them in the 40nm RSX, it cant be right, is pretty much like not doing anything

Moral of the story... if you change the RSX you are supposed to change the thermal settings for it... not only that misterious byte that seems to be related with the RSX revision... but also the temperatures or the speeds, the thermal shutdowns, etc...
I know, is not so easy, and sony didnt made any better but configuring the thermal config settings is going to be a nice improvement to keep everything under control in this frankensteins
 
Last edited:
mugininja said:
Hi guys...glad to hear we dont need the orbis mod.. thank you guys for all the efforts!

Could you guys have the ps3 bc console with 40nm rsx test the L.A Noire games.
I think this game put a lot of stress on the system.

https://blog.playstation.com/2011/05/19/rockstar-games-and-sony-joint-statement-on-l-a-noire/

hope can see the youtube video for this results. hopefully it stays cool too.
Click to expand...

I have the game on disc, but no finished 40nm system at the moment. I'll try to remember if i get time to make another.
 
sandungas said:
Btw, the other day i was doing some "hexeditor views" of the thermal config formats in wiki in the most intuitive way i found, the page is still a work in progress but it allows to show you a couple of related things
https://www.psdevwiki.com/ps3/Syscon_Thermal_Configs

Is better explained in that page, but i made an screenshot to show you the bytes we are changing with the frankenstein syscon patches
Untitled-1-copy.png

As you can see there are 3 thermal config formats, but the byte/s we need to modify are exactly in the same position in the first 2 formats (in other words, is the same offset for all mullion syscons)
In sherwood syscons we need to modify only 1 byte because is not repeated (the mullions are repeating it twice)

The samples i used are not random, as you can see i choose to show 3 different thermal config formats... but in the last 2 samples was used a 40nm RSX ;)
The original thermal config of COK-001 motherboard is the sample at left... compare the values in it with the sample at center (COK-001 with the official 40nm RSX refurbished and the last mullion syscon CXR714120-304GB)

The "problem" they had is the CXR714120-304GB requries to use second thermal config format (the structure shown in the sample at the center) so they "ported" all the values from the old format to the new format WITHOUT MODIFYING ANY TEMPERATURE OR SPEED !
The only value they modifyed is this bytes im talking about related with the RSX revision... we dont know what is it but for sure is important because is the only worthy thing they did of that porting in between thermal config formats
I dont use to subestimate sony engineers, but this was lame... i mean... they was taking all the temperaures and speeds from the original 90nm RSX to use them in the 40nm RSX, it cant be right, is pretty much like not doing anything

Moral of the story... if you change the RSX you are supposed to change the thermal settings for it... not only that misterious byte that seems to be related with the RSX revision... but also the temperatures or the speeds, the thermal shutdowns, etc...
I know, is not so easy, and sony didnt made any better but configuring the thermal config settings is going to be a nice improvement to keep everything under control in this frankensteins
Click to expand...
So we write a custom fan curve for the 40nm? One that better matchs the curve used on a slim? Or do you mean other thermal data?
 
Pacorretaco said:
I wouldn't know but it is just too easy to follow the stream and always blame the RSX too quick. Yes RSX can be swapped now for different model but that doesnt mean RSX always need to be swapped.

These machines are incredibly complex. Hoping that different RSX will solve all present and future problems is just not sensible. (I am talking in general, not anybody specifically. You seem to have lots of experience)

Sometimes even RSX related errors are not "because" of the RSX chip itself. Even 3034 can have root in the CPU side for example etc... It is a data error, failed communication "between" the two.

And especially 3013/21xx errors I have only seen in cases where it has nothing to do with RSX. Sometimes a random component, or yes totally destroyed CPU I have seen with those errors.
Click to expand...
Here is an updateon my dilemma!
I carried out another Frankenstein mod today on a COK-002 with a 65nm RSX and all has gone well and still running.
This confirms for me that the previous unit that seemed to fry RSX after RSX that the board has an issue because i used one of the supposedly fried RSX's off of the first unit on this second unit and it works fine.
I did notice that wit the first unit after it yellow lighted after the 3rd or 4th attempt to boot after the mod that it showed the RSX FlexIO error in the syscon log on bringup. This seems to be where the problem is,even though if i read 3242 and 3254 they both have the correct data that initially allowed the console to run with the 65nm RSX. It is though the syscon is forgetting the settings even though they are there and correct. got me beat so I'll use it for parts. It did the same when converting back to a 90nm RSX - 3rd boot and ylod -RSX FlexIO error
 
RIP-Felix said:
So we write a custom fan curve for the 40nm? One that better matchs the curve used on a slim? Or do you mean other thermal data?
Click to expand...
Well, i was talking about several things, the byte/s i marked with yellow arrows in the screenshot is the most important change sony was doing inside the thermal config in the official refurbs, im just copying what sony did with this byte/s

What is not fine is to keep the original thermal settings (the values for RSX temperaures mostly) that was calculated by the engineers for the 90nm RSX in the 40nm RSX
 
sandungas said:
Well, i was talking about several things, the byte/s i marked with yellow arrows in the screenshot is the most important change sony was doing inside the thermal config in the official refurbs, im just copying what sony did with this byte/s

What is not fine is to keep the original thermal settings (the values for RSX temperaures mostly) that was calculated by the engineers for the 90nm RSX in the 40nm RSX
Click to expand...
So that's the fan curves, thermal shutdown temperature, hysteresis, etc?
 
RIP-Felix said:
So that's the fan curves, thermal shutdown temperature, hysteresis, etc?
Click to expand...
Using the screenshot as reference... as a minimal i would change all the values of RSX "tempU" and "tempD", because this values was calculated for the 90nm RSX (hotter), but after a 40nm RSX replacement you should reduce them

The value named "hyst" doesnt needs to be changed because is the same in all PS3 models, we dont know well how it works also so no improvement posible here, and no need to worry becuse the original value is fine

"tshutdown" for RSX needs to be reduced too but probably you would like to reduce it for CELL too because usually is very high (over 90ºC, some PS3 models are more permisive up to 100ºC)
"trp" is always 1ºC lower than "tshutdown" (and it should match with the highest value of "tempU")... so if you change "tshutdown" you should change "trp" too to keep it 1ºC lower than "tshutdown"
 
PS3#12 Update - Frankie's Got a 40!
(...continued from NEC/TOKIN thread Here.)​

I installed a "NOS" 40nm RSX on this CECHE01 (COK-002) this morning. I just cleaned the board and it's currently drying. I'll update with test results later. I intend to use the Frankenstein Phat method. I have not installed the Voltage mod to VDDR yet. If the console works, I will probably attempt to replicate SONY's method by replacing the Controller, instead of hacking a slim MOSFET. Besides, I'm fresh out of slims to harvest from (I only ever had the one).

I wonder if I can get a BD3504 online? Or maybe I can find one on that KTE-001 Donor I took the MOSFET off of...IDK.

Anyway, I decided to install that 40nm RSX I balled with lead spheres (my first successfully balled RSX). It had great readings off the board. I just ohm tested all the relevant voltages on the motherboard after cleaning and It looks great! 3.1 ohms VDDC and all the rest within margin. I'll post actual numbers later.

Fun fact, after I removed the 90nm RSX I cleaned it and measured it. VDDC was 0.3 ohms, VDDR was short and FBVDDQ was having a hard time getting a reading. So that 90nm was definitely dead. Weird thing is that before none of them looked bad! 2.3 ohms VDDC, 428 ohms VDDR, 112 ohms FBVDDQ, etc. All good. So maybe I killed it in the removal or ohm testing on the MB doesn't always show a dead RSX! Kinda a mystery.

***EDIT: Mystery solved! I accidentally placed the measurments from PS3 #13 into the folder for PS3 #12. If you look closely at he picture I attached to the OP you'll see that the MB is a COK-001, not the COK-002 this E01 has...Whoops! I aparently didn't didn't record the measurments for this Motherboard...Dang it! So now I'm thinking it would have shown there was a low VDDC and short on FBVDDQ or VDDR, like what I'm seeing with the RSX off the board. ***

This was my best reball yet. The RSX sat nicely in place at nice low leaded temps. I was able to see when it settled and gave it a good 10s count before removing heat. This chip was above reflow temps for a brief period of time and then cooled. So I really feel this one has a strong bond! As good as I can achieve with my setup. The board didn't make any tink, pop, or crinkle noises during the reflow or cooldown. After cleaning, all ohms tests look great. The Console was GLOD before, but the 90nm RSX tested bad once removed, so I'm really hoping that was all that was wrong! If it had tested good, then I would be thinking there was something else wrong. As it is, I'm pretty optimistic about this one!

The only thing that eats at me, is why the ohm tests looked good on the MB before removing the 90nm? ***EDIT: It's because I was stupid and was looking at the wrong MB. Mystery solved!***

EDIT:
giphy.gif

Frankenstein Phat PS2.jpg

Code: 
Microsoft Windows [Version 10.0.19044.1526]
(c) Microsoft Corporation. All rights reserved.

C:\Users\HTPC\Desktop\PS3\SYSCON>python ps3_syscon_uart_script.py COM5 CXRF
>$ AUTH
Auth successful
>$ errlog
errlog
ofst[ 32]:err_code:0xffffffff, clock:0xffffffff
ofst[ 36]:err_code:0xffffffff, clock:0xffffffff
ofst[ 40]:err_code:0xffffffff, clock:0xffffffff
ofst[ 44]:err_code:0xffffffff, clock:0xffffffff
ofst[ 48]:err_code:0xffffffff, clock:0xffffffff
ofst[ 52]:err_code:0xffffffff, clock:0xffffffff
ofst[ 56]:err_code:0xffffffff, clock:0xffffffff
ofst[ 60]:err_code:0xffffffff, clock:0xffffffff
ofst[ 64]:err_code:0xffffffff, clock:0xffffffff
ofst[ 68]:err_code:0xffffffff, clock:0xffffffff
ofst[ 72]:err_code:0xffffffff, clock:0xffffffff
ofst[ 76]:err_code:0xffffffff, clock:0xffffffff
ofst[ 80]:err_code:0xffffffff, clock:0xffffffff
ofst[ 84]:err_code:0xffffffff, clock:0xffffffff
ofst[ 88]:err_code:0xffffffff, clock:0xffffffff
ofst[ 92]:err_code:0xffffffff, clock:0xffffffff
ofst[ 96]:err_code:0xffffffff, clock:0xffffffff
ofst[100]:err_code:0xffffffff, clock:0xffffffff
ofst[104]:err_code:0xffffffff, clock:0xffffffff
ofst[108]:err_code:0xffffffff, clock:0xffffffff
ofst[112]:err_code:0xffffffff, clock:0xffffffff
ofst[116]:err_code:0xffffffff, clock:0xffffffff
ofst[120]:err_code:0xffffffff, clock:0xffffffff
ofst[124]:err_code:0xffffffff, clock:0xffffffff
ofst[  0]:err_code:0xa0801200, clock:0x0b488687  2005/12/31 00:00:07
ofst[  4]:err_code:0xa0801004, clock:0x0b488a0b  2005/12/31 00:15:07
ofst[  8]:err_code:0xa0801200, clock:0x0b488f02  2005/12/31 00:36:18
ofst[ 12]:err_code:0xa0901001, clock:0x0b488692  2005/12/31 00:00:18
ofst[ 16]:err_code:0xa0901001, clock:0x0b488800  2005/12/31 00:06:24
ofst[ 20]:err_code:0xa0101001, clock:0x0b4888ba  2005/12/31 00:09:30
ofst[ 24]:err_code:0xa0404002, clock:0xffffffff
ofst[ 28]:err_code:0xa0403034, clock:0xffffffff
[mullion]$
>$ w 3242 03 61 82 80 01 91
w 3242 03 61 82 80 01 91
w complete!
[mullion]$
>$ w 3254 21 EB
w 3254 21 EB
w complete!
[mullion]$
>$ w 348B 8B
w 348B 8B
w complete!
[mullion]$
>$ w 34AF 8B
w 34AF 8B
w complete!
[mullion]$
>$ eepcsum
eepcsum
sum:0xed10
Addr:0x000032fe should be 0xffff657c
sum:0x1800
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ w 32fe 7c 65
w 32fe 7c 65
w complete!
[mullion]$
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x657c
sum:0x1800
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ w 32fe 7c 65
w 32fe 7c 65
w complete!
[mullion]$
>$ w 34fe 15 59
w 34fe 15 59
w complete!
[mullion]$
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x657c
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ AUTH
Auth successful
>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] First Boot.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x21e2
>$
[POWERSEQ] Error : BitTraining RSX:RRAC:BX0:BX:FLEXIO_ID
[SSM] state: 0104 -> 0304
[SSM] ssmCb_AfterBeOn2() called.
[SSM] PowSeq Fail : Detected !
[SSM] state: 0304 -> 0700
[POWSEQ] AV Backend Letup
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[ERROR]: 0xa0404002
[ERROR]: 0xa0403034
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)

[mullion]$
>$ shutdown
shutdown
[SSM] state: 0600 -> 0000
[SSM] Error state is cleared.
(PowerOff State)
>$ w 3254 21 EC
w 3254 21 EC
w complete!
[mullion]$
>$ eepcsum
eepcsum
sum:0x0100
Addr:0x000032fe should be 0x647c
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ w 32fe 7c 64
w 32fe 7c 64
w complete!
[mullion]$
>$ eepcsum
eepcsum
Addr:0x000032fe should be 0x647c
Addr:0x000034fe should be 0x5915
Addr:0x000039fe should be 0x0038
Addr:0x00003dfe should be 0x00ff
Addr:0x00003ffe should be 0x00ff
>$ AUTH
Auth successful
>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] First Boot.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x21e2
>$
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD

Boot Loader SE Version 1.5.0 (Build ID: 1798,18531, Build Data: 2007-01-10_12:09:26)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[INFO]: Connecting to Debug Device (SB UART)
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV THERM] NOTIFY_MODE CMD
[SERV THERM] Thermal Error Detected!
[SERV NOTIF] CONTROL_LED
[SERV NOTIF] RING_BUZZER
[SERV NVS] READ CMD
[SERV NVS] WRITE CMD
[WMZONE] *** Thermal Shutdown (1st BE Primary ) ***
[SSM] *** Thermal Alert (ZONE) ***
[SSM] state: 0400 -> 0700
[POWSEQ] AV Backend Letup
[SSM] ssmCb_AfterBeOn() called.
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[ERROR]: 0xa0801200
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0700 -> 0600
(PowerOff State) (Fatal)
[SERV NVS] *** sending error ***

[mullion]$
>$ bringup
bringup
[SSM] state: 0000 -> 0101
Bringup Mode #0 (0xFF)
[SSM] ssmCb_OnStartingBePowOn() called.
[SSM] Bringup mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Setup called.
[SSM] state: 0101 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x21e2
>$
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD

Boot Loader SE Version 1.5.0 (Build ID: 1798,18531, Build Data: 2007-01-10_12:09:26)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[INFO]: Connecting to Debug Device (SB UART)
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV THERM] NOTIFY_MODE CMD

[mullion]$
>$
[SERV NOTIF] CONTROL_LED
[SERV NOTIF] RING_BUZZER
[SERV NOTIF] CONTROL_LED
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV THERM] NOTIFY_MODE CMD
[SERV NVS] WRITE CMD
[SERV DEVPM] CONTROL_PCI_BUS_POWER_STATE CMD
[SSM] state: 0400 -> 0106
[POWSEQ] AV Backend Letup
[SSM] ssmCb_AfterBeOn() called.
[SSM] state: 0106 -> 0201
[POWSEQ] AV Backend Setup
[SSM] state: 0201 -> 0102
[SSM] state: 0102 -> 0202
[SSM] state: 0202 -> 0103
[SSM] state: 0103 -> 0203
[SSM] ssmCb_BeforeBeOn() called.
[SSM] state: 0203 -> 0104
Psbd_SbTransMode_Half:0x21e2
[SSM] state: 0104 -> 0204
[SSM] state: 0204 -> 0105
[SSM] state: 0105 -> 0400
(PowerOn State)
[SERV NVS] READ CMD

Boot Loader SE Version 1.5.0 (Build ID: 1798,18531, Build Data: 2007-01-10_12:09:26)
Copyright(C) 2006 Sony Computer Entertainment Inc.All Rights Reserved.
[SERV SETCFG] XDR (CH0,CH1) ASSERT
[SERV SETCFG] XDR (CH0,CH1) DEASSERT
[INFO]: Connecting to Debug Device (SB UART)
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV THERM] NOTIFY_MODE CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
loading_status:0x0
WmDiscOpr_ShutterOnEvent
WmDiscOpr_InsertDiscEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_ShutterOnEvent
WmDiscOpr_ChuckOnEvent
[SERV NVS] READ CMD
WmDiscOpr_ChuckOffEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_ShutterOnEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_EjectDiscEvent
WmDiscOpr_ShutterOnEvent
WmDiscOpr_InsertDiscEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_ShutterOnEvent
WmDiscOpr_ChuckOnEvent
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
[SERV NVS] READ CMD
WmDiscOpr_ChuckOffEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_ShutterOnEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_EjectDiscEvent
WmDiscOpr_ShutterOnEvent
WmDiscOpr_InsertDiscEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_ShutterOnEvent
WmDiscOpr_ChuckOnEvent
[SERV NVS] READ CMD
WmDiscOpr_ChuckOffEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_ShutterOnEvent
WmDiscOpr_ShutterOffEvent
WmDiscOpr_EjectDiscEvent

[mullion]$
>$ hdmi vbs
hdmi vbs
[HDMI VBS] Code:00000000
----------------------------------------------------------------
[HDMI VBS] ( 0) BE Module               : Unset
[HDMI VBS] ( 1) Command Module          : Unset
[HDMI VBS] ( 2) I2C Module              : Unset
[HDMI VBS] ( 3) Interrupt Module        : Unset
----------------------------------------------------------------
[HDMI VBS] ( 4) Interrupt Module System : Unset
[HDMI VBS] ( 5) Authentication Module   : Unset
[HDMI VBS] ( 6) State Machine Module    : Unset
[HDMI VBS] ( 7) EDID Read Module        : Unset
----------------------------------------------------------------
[HDMI VBS] ( 8) DDC Module              : Unset
[HDMI VBS] ( 9) FRAME Module            : Unset
[HDMI VBS] (10) HW Module               : Unset
[HDMI VBS] (11) SET Module              : Unset
----------------------------------------------------------------
[HDMI VBS] (12) STATUS Module           : Unset
[HDMI VBS] (13) REQ Module              : Unset
[HDMI VBS] (14) SystemEvent Module      : Unset
----------------------------------------------------------------
[HDMI VBS] (16) CH0 Module              : Unset
[HDMI VBS] (17) CH1 Module              : Unset
----------------------------------------------------------------
[HDMI VBS] (24) DVE Module              : Unset
[HDMI VBS] (25) EEPROM Module           : Unset
[HDMI VBS] (30) Hdmi System             : Unset
[HDMI VBS] (31) Hdmi ERROR              : Unset
[mullion]$
>$ errlog
errlog
ofst[ 48]:err_code:0xffffffff, clock:0xffffffff
ofst[ 52]:err_code:0xffffffff, clock:0xffffffff
ofst[ 56]:err_code:0xffffffff, clock:0xffffffff
ofst[ 60]:err_code:0xffffffff, clock:0xffffffff
ofst[ 64]:err_code:0xffffffff, clock:0xffffffff
ofst[ 68]:err_code:0xffffffff, clock:0xffffffff
ofst[ 72]:err_code:0xffffffff, clock:0xffffffff
ofst[ 76]:err_code:0xffffffff, clock:0xffffffff
ofst[ 80]:err_code:0xffffffff, clock:0xffffffff
ofst[ 84]:err_code:0xffffffff, clock:0xffffffff
ofst[ 88]:err_code:0xffffffff, clock:0xffffffff
ofst[ 92]:err_code:0xffffffff, clock:0xffffffff
ofst[ 96]:err_code:0xffffffff, clock:0xffffffff
ofst[100]:err_code:0xffffffff, clock:0xffffffff
ofst[104]:err_code:0xffffffff, clock:0xffffffff
ofst[108]:err_code:0xffffffff, clock:0xffffffff
ofst[112]:err_code:0xffffffff, clock:0xffffffff
ofst[116]:err_code:0xffffffff, clock:0xffffffff
ofst[120]:err_code:0xffffffff, clock:0xffffffff
ofst[124]:err_code:0xffffffff, clock:0xffffffff
ofst[  0]:err_code:0xa0801200, clock:0x0b488687  2005/12/31 00:00:07
ofst[  4]:err_code:0xa0801004, clock:0x0b488a0b  2005/12/31 00:15:07
ofst[  8]:err_code:0xa0801200, clock:0x0b488f02  2005/12/31 00:36:18
ofst[ 12]:err_code:0xa0901001, clock:0x0b488692  2005/12/31 00:00:18
ofst[ 16]:err_code:0xa0901001, clock:0x0b488800  2005/12/31 00:06:24
ofst[ 20]:err_code:0xa0101001, clock:0x0b4888ba  2005/12/31 00:09:30
ofst[ 24]:err_code:0xa0404002, clock:0xffffffff
ofst[ 28]:err_code:0xa0403034, clock:0xffffffff
ofst[ 32]:err_code:0xa0404002, clock:0xffffffff
ofst[ 36]:err_code:0xa0403034, clock:0xffffffff
ofst[ 40]:err_code:0xa0801200, clock:0xffffffff
ofst[ 44]:err_code:0xa0901001, clock:0x0b488682  2005/12/31 00:00:02
[mullion]$
>$ tmp 0
tmp 0
TZone No:00
1st BE Primary  Temperature:69.73(0x45bf)
[mullion]$
>$ tmp 1
tmp 1
TZone No:01
RSX Primary  Temperature:55.00(0x3700)
[mullion]$
>$ tmp 0
tmp 0
TZone No:00
1st BE Primary  Temperature:69.73(0x45bf)
[mullion]$
>$ tmp 1
tmp 1
TZone No:01
RSX Primary  Temperature:55.25(0x3740)
[mullion]$
>$
[SERV NOTIF] CONTROL_LED
[SERV THERM] NOTIFY_MODE CMD
[SERV NVS] WRITE CMD
[SERV DEVPM] CONTROL_PCI_BUS_POWER_STATE CMD
[SSM] state: 0400 -> 0500
[POWSEQ] AV Backend Letup
[SSM] ssmCb_AfterBeOn() called.
[SSM] Shutdown mode ... req_wake_src = 000002F4, ctxt=00/00
[SSM] Shutdown mode : syspm_stat=00000000/00000000
[POWSEQ] PowerSeq_Letup called.
[SSM] state: 0500 -> 0000
(PowerOff State)

[mullion]$
>$
@sandungas you'll want to know that this has a CXD5301 and required the w 3254 21 EC command to get working. You can see the entire sequence in the log. Pay no attention to the 1200. i forgot to put thermal paste on the die. It didn't like that.
 
Last edited:
the CXD2971AGB/DBG/-1GB etc 90nm RSX are old and wearing out now, It only takes a lift on the rework machine to put it over the edge nowadays. I reball dozens of old Phat PS3's a month and you do get the occassional 90nm that still has a lot of life left in it ( 2.0-3.5ohm) but the majority are low and either under 1.0ohm and no good or getting very close to it. the CXD2971-1GB are the strongest out of the bunch as it was the last produced 90nm RSX. So long story short is that a simple lift is too much heat for thr RSX to handle and it pushes it past the breaking point and does not have enough life left in it for a reball nor a reflow back to the board. This is 90nm RSX's I am talking about,not 65nm or 40nm
 
Last edited:
So I've been following this forum every so slightly. I bought so tantalum capacitors, a 40nm RSX chip, and got a hold of an Orbis Mod chip. The only problem... I do not have the equipment or knowledge on how to remove the 90nm RSX and reball with the 40nm RSX. I live in Indiana and wanting to know if someone can help me get this done.
 
Ben Leeth said:
So I've been following this forum every so slightly. I bought so tantalum capacitors, a 40nm RSX chip, and got a hold of an Orbis Mod chip. The only problem... I do not have the equipment or knowledge on how to remove the 90nm RSX and reball with the 40nm RSX. I live in Indiana and wanting to know if someone can help me get this done.
Click to expand...

Hi friend, to be honest by the time you buy all the equipment needed, it might be cheaper and better to ship everything off to @David Rainer who is a professional with amazing tech repair equipment, experience and knowledge. Hopefully David will see these messages soon and can help you out.
 
mugininja said:
Hi guys...glad to hear we dont need the orbis mod.. thank you guys for all the efforts!

Could you guys have the ps3 bc console with 40nm rsx test the L.A Noire games.
I think this game put a lot of stress on the system.

https://blog.playstation.com/2011/05/19/rockstar-games-and-sony-joint-statement-on-l-a-noire/

hope can see the youtube video for this results. hopefully it stays cool too.
Click to expand...
View attachment 36450
Screenshot_20220227-195526_1.png

Here is L.A. Noire after roughly 1 hour.
Ambient temperature 18-19c

Except this is a standard COK-002 board, with 90nm CPU and 90nm RSX
The Sony statement is absolutely right. Every machine should be perfectly capable of running it safely...
Let's see somebody with frankenstein but 90nm can be fine too
 
You must log in or register to reply here.

Similar threads

Back
Top