PS3 Help with CELL remarry (and RSX Orbis mod)

[DeadEnd]

So the modifications intented for the motherboard (the step 3 of both orbis and frankenstein mod) is to trick the syscon by lowering his CPU/GPU voltage threshold limit ?

I still think you have not paid attention to what was shown in the video. As I have shown it there, step 3 is not the same for refurbished boards.



See. That is step A-3 from Sony (The picture only shows RSX section, but it is done to both RSX and Cell. ). It is unique and was not mentioned in the Orbis mod. It's needed to adjust the Vmin limit (minimum allowed voltage will be twice lower). This is part of the VRM logic or what you called "adaptive voltage". The processor will request the required voltage (I think it's VDDC Core) , but there are Vmin and Vmax deviation limits for each.




I suggest you familiarize yourself with VRM. Please read below how Vmin can be changed.

Adjusting Power Good Threshold
Vid pins VID0-5 on the buck controller form a 6-digit code corresponding to the Vout No load setpoint. Power Good Vmin and Vmax thresholds are relative to that set point. With the stock COK-00X voltage divider values (15K and 20k), Vmin = -163mV. Vmax is always +100mV. The Vout voltage cannot deviate more than that. If it does power good goes low and the SYSCON will error.



In some official SONY refurbished consoles, new resistor values (27K and 10K) change Vmin = -400mV. So the Low Voltage threshold is now more than twice as low, allowing much more voltage ripple before it triggers an error.

And if the CELL / RSX go bellow the official threshold (1.2 V, is that right?) the syscon will not make an IC 1001 or 1002 fault (YLOD), so no need to change the NEC/TOKIN capacitor (that was, more or less , a fake fix?). Is that right?

It could be 1.2v, or it could be lower. Depends which voltage the GPU/CPU will request (it's in the VID). I don't know if it could prevent NEC/Tokin replacements. It's all theoretical . You can make your own conclusions based on all this info.

Did this voltage threshold could not be modify directly onto the syscon, now that we can acess it?

I don't think so. Vmix and Vmin limits are defined by the VRM controller NCP5318. Syscon just logs the errors and if it detects a problem in the power sequence (no pwrgood), it will shut everything down.

So now i understand why this modifications is essential.. But why did it was controversial? it's because of those resistor? but if it already works ?

It is not essential. It is recommended... But the mod will work without it. Even Sony "frankenstein" variant would work without it. But it is beneficial.... @botakompong (The guy from Orbis service ) didn't do it and customers didn't have any trouble with their ps3s. But Sony has done it and the logic is explained. You can decide for yourself if you want to do it or not.

 

[M4j0r]

So i need to flash this jig pup (2.43 CEX) into the nand of my PS3 in order (at least is the first step) to perform the remarry between a news CELL and my current mainboard.

Ok, but with that fact, i've several questions: ^^

First one: all the tutorials that shows how to "downgrad" the firmware by flashing the NAND of the PS3 (with various method: proskeet, E3 flasher, PS3Xploit....) used directly the interface of the PS3, so the PS3 need to be in working condition to perform this modifications. (but since my PS3 have a dead CELL, is it exclud for me?)

The only tutorial where i don't know if it needs the PS3 interface, is this one:
https://www.psdevwiki.com/ps3/Downgrading_with_linux
(In this one, ive unterstand that they extract a .pkg file from the .pup file and install it directly onto the NAND via a promp command, but i don't know how to process :/ )

The Jig file is no PUP but just the os region itself which needs to be written to the ros on the NAND. The console doesn't have to work for that, you can use any compatible programmer or do it in circuit with external power: https://www.psdevwiki.com/ps3/Hardware_flashing .

Second one: some says that if i put an firmware older than the one that originaly came with my console, i will brick it ! did it seems legit to you ?

2.43 should work on your console, the newer RSX might be a problem, so doing the swap after the remarry process is preferred.

Sorry but i don't unterstand your quote :/
If i'm refering to this procedure https://www.psdevwiki.com/ps3/Remarry_Syscon
you refered to the "Case#1 A full dump of the original Syscon SPCR is available"

But since i will maybe doesn't have such informations (since i plan to purchase a solo cpu like this one:Cxd2964agb | eBay
Could i just follow the "Case#2: The original Syscon SPCR is not available" to proceed the remarry ?

Or, since you talk about the NAND and not the Syscon, is it two different stuff?

The NAND storage is not related to Syscon. You both need the matching data on the NAND and Syscon. Syscon can be remarried but for the NAND you need to original perconsole files. So buying only CELL itself doesn't work, you need at least CELL + NANDs.

 

[sandungas]

Yeah, at this point the most important misunderstanding is the fact CELL is married with the contents of the NAND chips
You can try to find a CELL on sale that comes together with a dump of the NAND (made before the console died), that dump contains the data you need to write in your NANDs to match with the new CELL... but i dont know if this kind of sales is usual (CELL + a dump matching with that CELL)... unless you ask someone reputable from a repair service (there are some in the forum)
The other alternative is if you find a damaged motherboard, the only things you need from it are the CELL and the NANDs contents (software) so it doesnt mattters if the motherboard is broken at half... actually finding a motherboard like that broken at half woul be very convenient because it would be very cheap

Btw, in the tables of this link the column at most left named "pc" are the software pieces you need from the donor NAND, this data cant be regenerated so is critical
https://www.psdevwiki.com/ps3/Flash#NAND_Flash
The other data named "pf" doesnt matters because is updated by the PS3 firmware installers, is generic, not linked to the console, this is where you need to write the JIG firmware into the areas named "ros"

And to read/write the NAND chips you need a programmer like teensy++2.0, is a cheap development board and the software is open source https://www.psdevwiki.com/ps3/Teensy++_2.0

The connections to the motherboard are a bit tricky... the problem is your PS3 have 2 NAND chips connected throught another chip named https://www.psdevwiki.com/ps3/Starship2
For curiosity sake... the starship2 is using 2 NAND chips to create some kind of "RAID0" where are virtualized as a single storage device (the data written in them is interleaved in between the 2 NANDs), this is how the PS3 motherboard access the NAND contents, but... the starship uses an encrypted protocol, never was hacked, and we cant access starship2
So... what we are doing is to read/write the NAND chips (individually) by soldering wires directly into the NAND pins (in other words, we are bypassing starship2)

The syscon doesnt regulates power lines itself... the syscon connections are like an spiderweb, there is a control line in between syscon and almost every other important component of the motherboard. This includes some chips dedicated to control power rails, but the syscon is not "cofiguring them", it just switchs them ON/OF (and monitors his outputs to know if the power rails are working fine)
By now i would not worry about power and i will leave the idea of the RSX replacement for later, the challenge replacing CELL is big enought

 

[PSXCON22]

I still think you have not paid attention to what was shown in the video. As I have shown it there, step 3 is not the same for refurbished boards.

View attachment 36099

See. That is step A-3 from Sony (The picture only shows RSX section, but it is done to both RSX and Cell. ). It is unique and was not mentioned in the Orbis mod. It's needed to adjust the Vmin limit (minimum allowed voltage will be twice lower). This is part of the VRM logic or what you called "adaptive voltage". The processor will request the required voltage (I think it's VDDC Core) , but there are Vmin and Vmax deviation limits for each.

View attachment 36100


I suggest you familiarize yourself with VRM. Please read below how Vmin can be changed.






It could be 1.2v, or it could be lower. Depends which voltage the GPU/CPU will request (it's in the VID). I don't know if it could prevent NEC/Tokin replacements. It's all theoretical . You can make your own conclusions based on all this info.




I don't think so. Vmix and Vmin limits are defined by the VRM controller NCP5318. Syscon just logs the errors and if it detects a problem in the power sequence (no pwrgood), it will shut everything down.




It is not essential. It is recommended... But the mod will work without it. Even Sony "frankenstein" variant would work without it. But it is beneficial.... @botakompong (The guy from Orbis service ) didn't do it and customers didn't have any trouble with their ps3s. But Sony has done it and the logic is explained. You can decide for yourself if you want to do it or not.

Ok, so i took my time and rewatch all your videos (and the links that you shared) in the purpose to better understanding your explanation.

So i've understand that i confused many thing :/

First one, i confused the FlexIO VDD voltage modification (step 2 both for the FK and OB mod) and the pwrgood signal modification (step 3 FK). I thought that the step 3 (FK) (apply both on the CELL and RSX) was in the purpose to also lower the FlexIO VDD of the CELL in order to lower his temp. (Sorry for that, your eyes probably bleed when you saw my previous replys ^^' )

Second one, for the VRM and the adaptative VCore. I know that the VRM regulate the voltage of a CPU (or some other component that change their voltage constantly depending on his own workload) to allow it to receive a more constant and linear voltage. But ,as i'm used to CPU overclocking and other PC stuff, i've make a harzadous comparaison between tweaking this voltage behavior trought the BIOS of a PC mobo and the "step 2 modifcation" of those mods. Because, normally, a cpu automaticly change his own voltage feed (used by his "cores") depending on his workload. This option (into the BIOS) is called Adaptative Vcore . (if you want better stability and performance, while performing an overclock, you can disable this option, and set the Vcore with a unique value.)

Maybe i don't use correct comparaisons and terms, and that bring more confusion than other, sorry for that :/

So if i sum up correctly the modification intented in both FK and OB mod : (correct me if i'm wrong)

Step 1) is specific to each mod: whether you directly modify your syscon chip by transplanting a newer one (that is compatible with a 40 nm chip) or use the orbis chip that tricks the syscon by sending a fake 90 nm RSX signal .

Step2) Again 2 differents methods but with the same result. As the RSX is now a 40nm chip and consume less power we had to modify the FlexIO VDD voltage (of the RSX) from 1.2V to 0.95V by :
FK mod: swaping the entire VRM IC6200 (from BD3520 to BD3504) and add 4 new resistors ( 2x1.8K and 2x3.9K )
or
OB mod: swaping the mosfet (located near the IC6200) with an other IC/VRM from a slim model (that will bypass the original IC6200 and send the correct 0.95v to the FlexIO)

Step3) The controversial one: we have to change 2 resistor located near the VRM controller (NCP5318, this component check/watch any voltage fluctuations from the CELL or the RSX), those modications will change the Vmin value and allow the Vout to have more room for any voltage fluctuations. (and with that reduce the chance to have a IC 1001 or 1002 fault)

Step4) For COK-002: We have to remove the R2054 from the board and displace the R2153 (10k) (located nearby) in the R2054 locations (but diagonally so one leg/connector of the resistor will be connect in a nearby track) .


Could i mix this 2 mods ? since the FK mod seems cleaner than the OB one? (use the Orbis chip for step 1 but follow the FK modifications for step 2 ,3 and 4) or did the BD3504 is impossible to find ?
And for more durability, could i also add the NEC/tokin modification ?( by replacing each one of them by 4 EEF-GX0E471L from panasonic ? )

Thank you for all your works! you and the whole PSX-Place community ^^

 

[DeadEnd]

Step 1) is specific to each mod: whether you directly modify your syscon chip by transplanting a newer one (that is compatible with a 40 nm chip) or use the orbis chip that tricks the syscon by sending a fake 90 nm RSX signal .

Step2) Again 2 differents methods but with the same result. As the RSX is now a 40nm chip and consume less power we had to modify the FlexIO VDD voltage (of the RSX) from 1.2V to 0.95V by :
FK mod: swaping the entire VRM IC6200 (from BD3520 to BD3504) and add 4 new resistors ( 2x1.8K and 2x3.9K )
or
OB mod: swaping the mosfet (located near the IC6200) with an other IC/VRM from a slim model (that will bypass the original IC6200 and send the correct 0.95v to the FlexIO)

Step3) The controversial one: we have to change 2 resistor located near the VRM controller (NCP5318, this component check/watch any voltage fluctuations from the CELL or the RSX), those modications will change the Vmin value and allow the Vout to have more room for any voltage fluctuations. (and with that reduce the chance to have a IC 1001 or 1002 fault)

Step4) Only applies for COK-001 and 002. We have to remove the R2054 from the board and displace the R2153 (10k) (located nearby) in the R2054 locations (but diagonally so one leg/connector of the resistor will be connect in a nearby track) .
For COK-002, we have to add R2002 (47k)
For this last step, i don't know the reason beneath this modification. :/

Could i mix this 2 mods ? since the FK mod seems cleaner than the OB one? (use the Orbis chip for step 1 but follow the FK modifications for step 2 ,3 and 4) or did the BD3504 is impossible to find ?
And for more durability, could i also add the NEC/tokin modification ?( by replacing each one of them by 4 EEF-GX0E471L from panasonic ? )

Thank you for all your works! you and the whole PSX-Place community ^^

You got the first steps right. Step 3 isn't really that controversial. It's just good to do it if you can.

About step 4, you still didn't watch all my videos. Here is the corrected version about those resistors. You don't need to add 47k for Cok002. For cok001 you have to remove R2001 and either leave stock R2002 or replace it with a 47k. The reason we do it is because sony has done it to refurbished boards. We are simply repeating their steps. In my first video I didn't explain this part correctly because we misunderstood the instruction from @botakompong .

You can make combination of the mods. I don't know how easy it is to find BD3504 or a voltage regulator from slim boards. It depends on your situation. I personally don't mess with the Nec/Tokins. I tend to follow what the orbis guy did, I add 2 extra tantalums next to tokins on the other side of RSX. That should be enough. But again, you are also free to replace them all... I just think removing them adds stress to the board.

 

[PSXCON22]

The Jig file is no PUP but just the os region itself which needs to be written to the ros on the NAND. The console doesn't have to work for that, you can use any compatible programmer or do it in circuit with external power: https://www.psdevwiki.com/ps3/Hardware_flashing .

2.43 should work on your console, the newer RSX might be a problem, so doing the swap after the remarry process is preferred.


The NAND storage is not related to Syscon. You both need the matching data on the NAND and Syscon. Syscon can be remarried but for the NAND you need to original perconsole files. So buying only CELL itself doesn't work, you need at least CELL + NANDs.

The Jig file is no PUP but just the os region itself which needs to be written to the ros on the NAND. The console doesn't have to work for that, you can use any compatible programmer or do it in circuit with external power: https://www.psdevwiki.com/ps3/Hardware_flashing .

Ok, so the JIG file is parts of this 2.43 release: https://www.psdevwiki.com/ps3/2.43_CEX ? and this JIG file allow the PS3 to be put in a special service mode ? this particular Service mode needed to perform the remarry ?

2.43 should work on your console, the newer RSX might be a problem, so doing the swap after the remarry process is preferred.

Ok, i will perform the repair in this order.

The NAND storage is not related to Syscon. You both need the matching data on the NAND and Syscon. Syscon can be remarried but for the NAND you need to original perconsole files. So buying only CELL itself doesn't work, you need at least CELL + NANDs.

Ok, so NOW i understand why they all advised me to just find another deffective BC PS3 and let this one RIP ><

However with all those informations i will try to find a irremediably broken COK-002 (with CELL, NANDs and Syscon) and try to perform a remarry (even if it will may take time to find one.. )

Many thanks for your time and experience !

PS: i will try to sum up all the informations that you gave me.

 

[PSXCON22]

Yeah, at this point the most important misunderstanding is the fact CELL is married with the contents of the NAND chips
You can try to find a CELL on sale that comes together with a dump of the NAND (made before the console died), that dump contains the data you need to write in your NANDs to match with the new CELL... but i dont know if this kind of sales is usual (CELL + a dump matching with that CELL)... unless you ask someone reputable from a repair service (there are some in the forum)
The other alternative is if you find a damaged motherboard, the only things you need from it are the CELL and the NANDs contents (software) so it doesnt mattters if the motherboard is broken at half... actually finding a motherboard like that broken at half woul be very convenient because it would be very cheap

Btw, in the tables of this link the column at most left named "pc" are the software pieces you need from the donor NAND, this data cant be regenerated so is critical
https://www.psdevwiki.com/ps3/Flash#NAND_Flash
The other data named "pf" doesnt matters because is updated by the PS3 firmware installers, is generic, not linked to the console, this is where you need to write the JIG firmware into the areas named "ros"

And to read/write the NAND chips you need a programmer like teensy++2.0, is a cheap development board and the software is open source https://www.psdevwiki.com/ps3/Teensy++_2.0

The connections to the motherboard are a bit tricky... the problem is your PS3 have 2 NAND chips connected throught another chip named https://www.psdevwiki.com/ps3/Starship2
For curiosity sake... the starship2 is using 2 NAND chips to create some kind of "RAID0" where are virtualized as a single storage device (the data written in them is interleaved in between the 2 NANDs), this is how the PS3 motherboard access the NAND contents, but... the starship uses an encrypted protocol, never was hacked, and we cant access starship2
So... what we are doing is to read/write the NAND chips (individually) by soldering wires directly into the NAND pins (in other words, we are bypassing starship2)

The syscon doesnt regulates power lines itself... the syscon connections are like an spiderweb, there is a control line in between syscon and almost every other important component of the motherboard. This includes some chips dedicated to control power rails, but the syscon is not "cofiguring them", it just switchs them ON/OF (and monitors his outputs to know if the power rails are working fine)
By now i would not worry about power and i will leave the idea of the RSX replacement for later, the challenge replacing CELL is big enought

First, many thanks for your reply, your clarified many things!^^

The other alternative is if you find a damaged motherboard, the only things you need from it are the CELL and the NANDs contents (software) so it doesnt mattters if the motherboard is broken at half... actually finding a motherboard like that broken at half woul be very convenient because it would be very cheap

I thing that is the wisely thing to do (and the only option available), and now one of my goal. Even if finding one of those is like finding a needle in a haystack ><

Btw, in the tables of this link the column at most left named "pc" are the software pieces you need from the donor NAND, this data cant be regenerated so is critical
https://www.psdevwiki.com/ps3/Flash#NAND_Flash
The other data named "pf" doesnt matters because is updated by the PS3 firmware installers, is generic, not linked to the console, this is where you need to write the JIG firmware into the areas named "ros"

So the ros is where the main data of the firmware is situated? it's there that i need to flash the 2.43 PS3updat.pup ? or did i need to extract some kind of package from the .pup file and flashing it into the ros section of the NAND?

And to read/write the NAND chips you need a programmer like teensy++2.0, is a cheap development board and the software is open source https://www.psdevwiki.com/ps3/Teensy++_2.0

Thanks ^^

The connections to the motherboard are a bit tricky... the problem is your PS3 have 2 NAND chips connected throught another chip named https://www.psdevwiki.com/ps3/Starship2
For curiosity sake... the starship2 is using 2 NAND chips to create some kind of "RAID0" where are virtualized as a single storage device (the data written in them is interleaved in between the 2 NANDs), this is how the PS3 motherboard access the NAND contents, but... the starship uses an encrypted protocol, never was hacked, and we cant access starship2
So... what we are doing is to read/write the NAND chips (individually) by soldering wires directly into the NAND pins (in other words, we are bypassing starship2)

I think that for this part i need to learn many more before atempting anything ..
I will follow as much tutorials as possible ( https://drive.google.com/file/d/0B-...aTg/view?resourcekey=0-mer3No5adEdmR47M2-6HXg it's in french but should be helpfull at least for me)

By now i would not worry about power and i will leave the idea of the RSX replacement for later, the challenge replacing CELL is big enought

Yes, you right, i prioritising the remarry before the orbis mod

Thanks, again, for your reply ^^

 

[PSXCON22]

You got the first steps right. Step 3 isn't really that controversial. It's just good to do it if you can.

About step 4, you still didn't watch all my videos. Here is the corrected version about those resistors. You don't need to add 47k for Cok002. For cok001 you have to remove R2001 and either leave stock R2002 or replace it with a 47k. The reason we do it is because sony has done it to refurbished boards. We are simply repeating their steps. In my first video I didn't explain this part correctly because we misunderstood the instruction from @botakompong .

You can make combination of the mods. I don't know how easy it is to find BD3504 or a voltage regulator from slim boards. It depends on your situation. I personally don't mess with the Nec/Tokins. I tend to follow what the orbis guy did, I add 2 extra tantalums next to tokins on the other side of RSX. That should be enough. But again, you are also free to replace them all... I just think removing them adds stress to the board.

About step 4, you still didn't watch all my videos. Here is the corrected version about those resistors. You don't need to add 47k for Cok002. For cok001 you have to remove R2001 and either leave stock R2002 or replace it with a 47k. The reason we do it is because sony has done it to refurbished boards. We are simply repeating their steps. In my first video I didn't explain this part correctly because we misunderstood the instruction from @botakompong .

Sorry for this one, i saw that i confused your 2 videos when i write my reply, i will make a correction on my previous reply.

You can make combination of the mods. I don't know how easy it is to find BD3504 or a voltage regulator from slim boards. It depends on your situation. I personally don't mess with the Nec/Tokins. I tend to follow what the orbis guy did, I add 2 extra tantalums next to tokins on the other side of RSX. That should be enough. But again, you are also free to replace them all... I just think removing them adds stress to the board.

Maybe i will find a BD3504 on a DIA or SEM mobo revisions of a fat PS3 or VER for a slim one ?

Ok, i take your advice. But before doing it, i need to sucessfully proceed the remarry, and it wil take times .....

However, many thanks for your time, explanations and patience ^^

 

[sandungas]

So the ros is where the main data of the firmware is situated? it's there that i need to flash the 2.43 PS3updat.pup ? or did i need to extract some kind of package from the .pup file and flashing it into the ros section of the NAND?

Yes, the ros contains the operative system, the PUP format is like a container with other containers inside, the ros is a file named CORE_OS_PACKAGE.pkg
In a standard PS3 firmware installation the contents of the CORE_OS_PACKAGE.pkg are extracted inside the inactive ros area then his status is changed to active. And the other ros (that was active) is marked as inactive and keeps the data from the previous firmware
In other words... a standard PS3 firmware installation only updates the inactive ros area
Incase you dont know which ros is inactive you can overwrite the same data in both ros areas, this way you are sure the new data is going to be loaded

Is pretty much what happens when you install a PUP 2 times consecutivelly, the first installation overwrites one of the ros areas, and the second installation overwrites the other ros area... but you need to do it with a flasher

 

[PSXCON22]

Yes, the ros contains the operative system, the PUP format is like a container with other containers inside, the ros is a file named CORE_OS_PACKAGE.pkg
In a standard PS3 firmware installation the contents of the CORE_OS_PACKAGE.pkg are extracted inside the inactive ros area then his status is changed to active. And the other ros (that was active) is marked as inactive and keeps the data from the previous firmware
In other words... a standard PS3 firmware installation only updates the inactive ros area
Incase you dont know which ros is inactive you can overwrite the same data in both ros areas, this way you are sure the new data is going to be loaded

Is pretty much what happens when you install a PUP 2 times consecutivelly, the first installation overwrites one of the ros areas, and the second installation overwrites the other ros area... but you need to do it with a flasher

Yes, the ros contains the operative system, the PUP format is like a container with other containers inside, the ros is a file named CORE_OS_PACKAGE.pkg

Yes, i see this file in this thread: https://www.psdevwiki.com/ps3/Downgrading_with_linux.
And i used the PS3 PUP extrator v1.0 software to extract this package (+/- 4.5 Mo) from the 2.43 PUP

In a standard PS3 firmware installation the contents of the CORE_OS_PACKAGE.pkg are extracted inside the inactive ros area then his status is changed to active. And the other ros (that was active) is marked as inactive and keeps the data from the previous firmware
In other words... a standard PS3 firmware installation only updates the inactive ros area
Incase you dont know which ros is inactive you can overwrite the same data in both ros areas, this way you are sure the new data is going to be loaded

Ok, so i thing that you make a reference to ros0 and ros1 situated onto the ros section of the NAND?

So once i created several dump from NAND 0 and 1, and compared them with each others with HxD (to chek if they aren't corrumpted)
I will need to mix the 2 dump from both NAND 0 and 1 with FlowRebuilder and it's, normally, into this mixed dump that i install the core_os_package.pkg? By targeting directly the correct offset of the ros 0 and 1 and rewrite them with the content of the .pkg file?
Or did a dedicated software already exist?

I bought several tool for this purpose, like a bus pirate V3.6 (with the connectors) for the syscon and a teensy 2.0 ++ with a 360 48 Pin NAND clip for the NANDs (and it was not such expensive)

Many thanks for your tips!^^

 

[PSXCON22]

The Jig file is no PUP but just the os region itself which needs to be written to the ros on the NAND. The console doesn't have to work for that, you can use any compatible programmer or do it in circuit with external power: https://www.psdevwiki.com/ps3/Hardware_flashing .

2.43 should work on your console, the newer RSX might be a problem, so doing the swap after the remarry process is preferred.


The NAND storage is not related to Syscon. You both need the matching data on the NAND and Syscon. Syscon can be remarried but for the NAND you need to original perconsole files. So buying only CELL itself doesn't work, you need at least CELL + NANDs.

So, i will sum up all the informations that you (and sandungas) shared with me:

So in order to proceed a syscon remarry, you need 2 identicals PS3 mainboard (COK-002 for my purpose):

-One, the receiver, that will receive the new CELL CPU
-One, the donor, that need to have a intact CELL CPU and NAND's.

On the donor board, you have to created severeal dump from his NANDs (NAND 0 and 1), check if their aren't corrumpted and copy the matching perconsole flash parts (bootldr and asecure_loader)
And use a BGA rework station to take off the CELL CPU)

Once that done, on the receiver side. You have to :

1) Make a dump from his 2 NANDs (check if they are not corrumpted and mixed them together). (by using teensy 2.0 ++ with 360 48 pin NAND Clip and a external alimentation, check the dump with HxD, and mix them up with FlowRebuilder)

2) Write the informations, contained in the bootldr and asecure_loader section from the donor board's dump file , into the same section of the receiver board's dump. (if you have a good programation software to perform this step ?
https://www.psdevwiki.com/ps3/Flash#NAND_Flash

3) install the CORE_OS_PACKAGE.pkg (that contain the JIG) from a 2.43 cex firmware pup into the ros0 and 1 of the receiver's board's dump.

4) split this dump in two (with flowrebuilder) and flash them into the receiver board's NANDs.

5) Swap the CELL CPU with the new one.

6) Connect the bus pirate onto the syscon chip. (https://www.psdevwiki.com/ps3/SC_EEPROM#Dumping_SC_EEPROM_-_hardware_way)

7)Make a dump of your syscon eeprom.

8)If you want to acess the different SNVS region of the dump, you need the different magical keys. (https://www.psdevwiki.com/ps3/Keys#SNVS_Keys)

9) Once you decrypted the dump, blank the entire SNVS (from offset 0x0000 to 0x27FF) with FF

10) Write onto the 48 first bytes of the SNVS this magical keys:
5E B4 F7 C9 50 62 F1 B2 EC F7 EE 1A 3C E3 D8 D0
C5 C2 73 4B A4 13 3D 2C 9E EE 88 ED 0C A8 15 C7
8F 59 DC E4 35 A8 11 BD 8B EC 4E 95 09 F1 E7 38

11)Write 0x00 onto the offset 0x7207 (to active the product mode)

12)Flash the SC eeprom with this dump.

13)use the UART interface to start the PS3 (2x) (see on the prompt what happen)

14) use lv2diag.self / manufacturing_updater_for_reset.self to update the ps3 firmware.


15) Write 0xFF onto the offset 0x7207 ( to desactive the product mode)

Et voila!

 

[M4j0r]

2) Write the informations, contained in the bootldr and asecure_loader section from the donor board's dump file , into the same section of the receiver board's dump.
https://www.psdevwiki.com/ps3/Flash#NAND_Flash

You probably want to copy all "pc" parts of the flash.

3) install the CORE_OS_PACKAGE.pkg (that contain the JIG) from a 2.43 cex firmware pup into the ros0 and 1 of the receiver's board's dump.

The one from this site: https://www.psdevwiki.com/ps3/2.43_CEX which says: "(JIG) - warning, do not use/install, only for documentative/completion!".

8)If you want to acess the different SNVS region of the dump, you need the different magical keys. (https://www.psdevwiki.com/ps3/Keys#SNVS_Keys)

The eeprom is plain, you need no keys.

You could also just use the syscon from the donor console or copy the eeprom contents, that way there's no need to remarry.