Cechb01 on 2.35 unable to boot into safe mode

[baileyscream]

Drive board? You mean the daughter board? The OP said he tested others and had the same issue,

You will get the same issue with other boards as there not married to that console

how messing with the NAND would be a solution in this case if we have a hardware issue on the mobo and not the daughter board?

There is no issue on the main board. And by creating a 2.35 patch from the coreOS would have put the firmware back on both ros areas. We could have also taken a look at the dump in hxd to see if there was anything not right.

BTW, the OP said the console turns off, nothing else. That's why I believe it's a YLOD, and what this console does it's pretty common when you have NECs issues.

ylod = yellow light of death
On for a few seconds then powers off = software issue. As I said. It was a known issue when people were changing hdds or had a crash so sony added the recovery to stop people having to return the console for fixing
Its not a YLOD as there is NO Yellow light.

And I said "HEAT A BIT" those NECs, nothing else. I don't know what are you thinking, a common reflow on the processors???

Any heat is bad. Do you not realise what a heatsink is for or what sort of damage warming the board will do when it releases moisture from the board?
You also need to remove the ihs to heat it properly.
If your an armature and warm it before removing the ihs you get 2 things happen
1 the board will flex
2 moisture will collect on the die under the ihs
Both are bad

And finally, the console will give another error code for the daughter board having issues or not being present at all..

Your point being?

Look as I keep saying
YOUR GIVING BAD ADVICE
just stop.

 

[ElGris]

That video explains a lot. Definitely not this case. I thought it was a YLOD, since every brick I saw it was like that. My bad on that.

Btw, every thing you said about the heating, it's wrong. I woulnd't even go further than 50ºC for this matter if I would try to prove anything.

 

[RCWD21]

That video explains a lot. Definitely not this case. I thought it was a YLOD, since every brick I saw it was like that. My bad on that.

Btw, every thing you said about the heating, it's wrong. I woulnd't even go further than 50ºC for this matter if I would try to prove anything.

That shutting off part is what I'm not understanding, it just goes back to standby. I guess its failing some internal checks or something and since it can't get passed that it just defaults to "off"

Sent from my SM-G965U using Tapatalk

 

[sandungas]

That shutting off part is what I'm not understanding, it just goes back to standby. I guess its failing some internal checks or something and since it can't get passed that it just defaults to "off"

Sent from my SM-G965U using Tapatalk

Yep, it looks like it cant load the PS3 firmware and returns to standby, the firmware of the PS3 is splitted in "stages" (and one of them can be swapped by the recovery mode), maybe the PS3 is loading some of that stages, but it cant be completed

You should take a look at the syscon error log, mostly because you have the hardware required for it (and you was about to play with that in other consoles anyway, hehehe), i dont remember if there are some error codes related with this though, but i guess syscon is going to store some info about it

Btw, there was a "port" of the jailbreak dongles for PSP (and even for texas instrument calculators, for geeks), maybe you have something that could do it

 

[baileyscream]

That video explains a lot. Definitely not this case. I thought it was a YLOD, since every brick I saw it was like that. My bad on that.

Btw, every thing you said about the heating, it's wrong. I woulnd't even go further than 50ºC for this matter if I would try to prove anything.

How am I wrong? If you apply heat to the 3 layer board then it bends. Im not wrong on that
It has moisture release under heat. Im not wrong on that.
The actual bgm chip board has moisture that releases and settles on the die. Im not wrong on that.

Just looked and I can see you made a post about removing ihs with some sort of metal strap that you think is good even though it scraped two tracks together. But you even coment on how there is moisture on the die after removing it.
Thats your proof im telling the truth.
Also
Steady hands for an "old lady" [emoji38]

 

[RCWD21]

Yep, it looks like it cant load the PS3 firmware and returns to standby, the firmware of the PS3 is splitted in "stages" (and one of them can be swapped by the recovery mode), maybe the PS3 is loading some of that stages, but it cant be completed

You should take a look at the syscon error log, mostly because you have the hardware required for it (and you was about to play with that in other consoles anyway, hehehe), i dont remember if there are some error codes related with this though, but i guess syscon is going to store some info about it

Btw, there was a "port" of the jailbreak dongles for PSP (and even for texas instrument calculators, for geeks), maybe you have something that could do it

Since this failed after attempting to update to 4.86 from 2.35 is there any risk that part of both firmwares are in there and thats what's causing the issue on top of an apparent issue with the bluray drive?

I've updated the firmware on a few consoles without even having a bluray drive installed and it went perfectly fine (cant remember the models but one of them was my fully functional A model and it hasn't had any issues whatsoever. Maybe I got lucky, who knows but I'm determined to figure the issue out with this console and if anything new comes up I'll be sure to post it over there in the syscon thread to help that out

Sent from my SM-G965U using Tapatalk

 

[ElGris]

If I recall well I have SS motherboard with the same issue that I don't even check yet. Green light for a short time and then turn off. Could be the same issue, and lucky I have an E3 flasher. This weekend I'm gonna report if I find something.

How am I wrong? If you apply heat to the 3 layer board then it bends. Im not wrong on that
It has moisture release under heat. Im not wrong on that.
The actual bgm chip board has moisture that releases and settles on the die. Im not wrong on that.

Just looked and I can see you made a post about removing ihs with some sort of metal strap that you think is good even though it scraped two tracks together. But you even coment on how there is moisture on the die after removing it.
Thats your proof im telling the truth.
Also
Steady hands for an "old lady" [emoji38]

Dude, 50ºC for a few seconds is nothing. You're exaggerating quite a bit.

 

[baileyscream]

If I recall well I have SS motherboard with the same issue that I don't even check yet. Green light for a short time and then turn off. Could be the same issue, and lucky I have an E3 flasher. This weekend I'm gonna report if I find something.


Dude, 50ºC for a few seconds is nothing. You're exaggerating quite a bit.

An ss motherboard? Do you mean a superslim board?

 

[nCadeRegal]

Bailey is the expert here who i would turn to for advice with anything related to the flash. I get it you have your ideas also elgris, but realize that you are just guessing and it is not the best advice.
Bailey has helped resolve hundreds of issues if not thousands over the years when it comes to flashing. Its who I call into a thread when it involves any nor or nand issue

 

[sandungas]

Since this failed after attempting to update to 4.86 from 2.35 is there any risk that part of both firmwares are in there and thats what's causing the issue on top of an apparent issue with the bluray drive?

I've updated the firmware on a few consoles without even having a bluray drive installed and it went perfectly fine (cant remember the models but one of them was my fully functional A model and it hasn't had any issues whatsoever. Maybe I got lucky, who knows but I'm determined to figure the issue out with this console and if anything new comes up I'll be sure to post it over there in the syscon thread to help that out

Sent from my SM-G965U using Tapatalk

Yes i think is something like that there are some areas in the flash that are fine, and others are damaged or invalid

It could happen also what bguerville mentioned some posts ago, at the end of the firmware installation there is a point where the syscon stores a hash or the ros area when the firmware has been installed, and then it "flips" a flag that indicates which one is the active ros area
So... maybe you have some mistmatch in those hashes or the flag that indicates the active ros

Usually this problems are fixed by rebuilding the flash dump using a copy of the ros areas from other console... to make them match with whatever firmware version/hash your syscon is asking for

Now with the UART syscon access you could take a look at the commands availabels to see if there is some of them that tells the required version or hash... not sure if they exists though

 

[RCWD21]

Yes i think is something like that there are some areas in the flash that are fine, and others are damaged or invalid

It could happen also what bguerville mentioned some posts ago, at the end of the firmware installation there is a point where the syscon stores a hash or the ros area when the firmware has been installed, and then it "flips" a flag that indicates which one is the active ros area
So... maybe you have some mistmatch in those hashes or the flag that indicates the active ros

Usually this problems are fixed by rebuilding the flash dump using a copy of the ros areas from other console... to make them match with whatever firmware version/hash your syscon is asking for

Now with the UART syscon access you could take a look at the commands availabels to see if there is some of them that tells the required version or hash... not sure if they exists though

Well I guess its a good thing I have valid flash dumps from a couple other consoles if that is indeed the case.

I'll be pulling the console apart here in a few to get the syscon stuff started. Hopefully things work out with the laptop and I can get some results.

Should I post it here in this thread or over in the syscon thread?

Sent from my SM-G965U using Tapatalk

 

[RCWD21]

This is probably the freshest looking factory thermal paste I've come across in a fat ps3. Its started to dry out but really not that bad.

But here goes my first venture into sysvon territory, wish me luck!

Sent from my SM-G965U using Tapatalk

 

[sandungas]

Well I guess its a good thing I have valid flash dumps from a couple other consoles if that is indeed the case.

I'll be pulling the console apart here in a few to get the syscon stuff started. Hopefully things work out with the laptop and I can get some results.

Should I post it here in this thread or over in the syscon thread?

Sent from my SM-G965U using Tapatalk

For rebuilding prposes is needed to have NAND dumps with a 2.35 installed, then crop the ros areas that contains the coreOS files, and patch them in your dump

For ther syscon UART experiments is better to write in the other thread because there are more chances to find someone that could help you

 

[RCWD21]

For rebuilding prposes is needed to have NAND dumps with a 2.35 installed, then crop the ros areas that contains the coreOS files, and patch them in your dump

For ther syscon UART experiments is better to write in the other thread because there are more chances to find someone that could help you

Is it possible to update those files to 4.86 and then just downgrade later on if I feel like it?

I ask because both dumps I have are both on 4.86 ofw

Sent from my SM-G965U using Tapatalk

 

[sandungas]

Is it possible to update those files to 4.86 and then just downgrade later on if I feel like it?

I ask because both dumps I have are both on 4.86 ofw

Sent from my SM-G965U using Tapatalk

The syscon stores hashes of the flash ros areas
The idea is to write in flash the same ros data required by syscon

You was messing around with 4.86 and 2.35 so there are 2 tests that worths to be made:
-write the ros for 2.35 in both ros areas
-write the ros for 4.86 in both ros areas

This way the syscon flag that indicates which ros is active doesnt matters because we are writing the same data in both ros areas. This is how it was fixed since lot of time ago, mostly because we dont know which ros area is the active one, so we write both

But now with the syscon UART commands maybe you are going to be able to retrieve some info that could indicate what is requesting

 

[RCWD21]

The syscon stores hashes of the flash ros areas
The idea is to write in flash the same ros data required by syscon

You was messing around with 4.86 and 2.35 so there are 2 tests that worths to be made:
-write the ros for 2.35 in both ros areas
-write the ros for 4.86 in both ros areas

This way the syscon flag that indicates which ros is active doesnt matters because we are writing the same data in both ros areas. This is how it was fixed since lot of time ago, mostly because we dont know which ros area is the active one, so we write both

But now with the syscon UART commands maybe you are going to be able to retrieve some info that could indicate what is requesting

Ok, that makes some sense (still wrapping my head around all this honestly but I'm confident in my soldering skills and what not.

The iron is warming up now so I'll post any findings or troubles over in the syscon thread once I get things in place

Sent from my SM-G965U using Tapatalk

 

[baileyscream]

For rebuilding prposes is needed to have NAND dumps with a 2.35 installed, then crop the ros areas that contains the coreOS files, and patch them in your dump

For ther syscon UART experiments is better to write in the other thread because there are more chances to find someone that could help you

He will be safer getting the ros from 2.35 update pups than trying to find a dump with 2.35 to extract.
Will save him getting confused and flashing per-console from another ps3 to this one as I suspect will happen

 

[RCWD21]

He will be safer getting the ros from 2.35 update pups than trying to find a dump with 2.35 to extract.
Will save him getting confused and flashing per-console from another ps3 to this one as I suspect will happen

So basically if I'm understanding correctly I need to extract what I've got on the console now and patch it with the full 2.35 update pup vs trying to sort out what's what between possibly 2 partial bits of firmwares that are corrupt in some way since updating failed?

Sent from my SM-G965U using Tapatalk

 

[baileyscream]

So basically if I'm understanding correctly I need to extract what I've got on the console now and patch it with the full 2.35 update pup vs trying to sort out what's what between possibly 2 partial bits of firmwares that are corrupt in some way since updating failed?

Sent from my SM-G965U using Tapatalk

I think we're a bit split on what you should do

1. @sandungas wants you to check the syscon

2. I think its safer to put the console into fsm with a psgrade dongle and reinstall your firmware that way.
If it will.

 

[ElGris]

An ss motherboard? Do you mean a superslim board?

Yeap, it's a MSX.

When you turn it on, the console will stay only on green light for about 42 secs EXACTLY. This B lasts 52 secs, 10 more than mine. Since I used the tristate for backing up the NOR, the console didn't turn off at all, and I could work without problem.

This lets me believe that there isn't something "damaged", as the console is running as it should be and even the SYSCON is managing the fan rpms.

What I got from the NOR is weird too. The first backup I got was just fine, the others two are giving me bad news. Now I don't understand why I'm getting this difference, I didn't remove the clip for the 3 backups..