[Answered] PS3 CECHE 3.61 YLOD during hardware downgrade help?
After flashing my modified dumps then the ps3 would turn on with a green LED and after about 20sec it would go back to standby. No beeps or red LED.
while waiting on my service dongle to come in then I got ahold of an Iphone 3G that a friend had and set it up for the PSFreedom exploit. It didn't work for me after multiple attempts so I just waited for the dongle.
Once I got the dongle in then i turned the PS3 on with out anything connected to the USB and I got the YLOD... I then flashed back the original dump and verified it using progskeet. still YLOD.
I researched YLOD and figured maybe the console was about to have a solder issue with the RSX anyway and all the messing with it caused it to happen. I then reflowed it, no change.
I pulled the heat spreader off the RSX and felt for it and the CELL to heatup when power on a few times and they do... So here is where I am now but could use some advice form some of the experienced ones here.
I had two good dumps from each chip and using devwiki I dont see an issue but maybe I am missing it.
Maybe my data on the dump that pertains to the console keys is still good and I can plug someone elses good data in the other places of the dump?
If anyone wants to verify the dumps for me then you can download at [Register or Login to view links]
all powers supply rails looks good, fan kicks on too
bad harddrive? it acts fine on the PC so I formatted it and also tried another good 1TB drive
rig is not setup correctly when powering on? I connect the power supply, fan, and HDD (may not need HDD connected though?)
I have another CECHE and a CECHB coming in too that each have some issues reading disc but I got cheap so I figure I can fix them and sell them if I can get this unit going.
i've never had a nand console before but i downloaded your dumps then used flowrebuilder to UNSCRAMBLE then interleave two NAND flashes. it extracted fine and i had a look though it. your backups seem fine so the console should be recoverable. maybe you had a problem reprogramming the nand chips? ground the tristate then dump the nands again and compare to verify that the data was written correctly
YLOD means somethings wrong on the hardware or software, it does not limit only with overheating issue with reflow or reball solution.
Since the thing "YLOD that is" triggers during hardware downgrade, this is more fault on your SYSCON, and the thing that SYSCON is screwed up , that means your SOL. As of the moment, there are no ways to recover from SYSCON bricks. It's possible to recover from it but no one attempts too since it's inside the Cell's EEPROM you will be dealing for. and there is no way you can access that with handy tools today.
Thanks for the verification Technodon, I am glad to hear a 2nd opinion on the dumps. At the same time then it worries me about it not being the dump since I have checked the hardware and an unable to find an issue with it. It is good news for me to be reminded about grounding the tristate. I read about it some time ago and will have to find the details again but at the time it was not something that I needed to look into.
niwakun, I am lightly familiar with the SYSCON operations which send the command out to things like the CELL processor and wait for an ok command to come back during boot. With the light knowledge I have of it then the typical YLOD response that I get from the console is telling me that the SYSCON is doing its job most likely since I have not messed with it directly to damage it and it is telling me YLOD. right?
I have the CECHB in now too but it took some pretty bad damage in shipping pretty much all over. after reseating the harddrive then it is working okay except maybe the blue tooth for the controllers. I will be modding it from 4.25 OFW too. I just dont want to write off my CECHE though so i will check out grounding the tristate chip. I did verify the patched dump and then the original dump flashing using progskeet a couple times while trying to unbrick. Thanks and I will let you know how it goes.
I missed this on the wiki. I will have to try it too. I have already tested all the fuses and thermisters
YLOD - Yellow Led of Death (Flashes Green, Yellow then Red)
Failure in the hardware_init stage. Suspects: RSX, CELL BE, XDR Ram, GDDR Vram, Syscon, South Bridge, Starship2 (if NAND SKU), NAND/NOR Flash, Power Supply, Fuses, Regulators, Cooling/Fan
If you ground out tristate on a console with YLOD, it would GLOD instead if it is caused by bad flash. This makes it an easy way to check if the YLOD is flash caused (most common) or RSX caused (second most common).
I grounded C1 of the Starship2 and still get the YLOD so according to the instructions and 2nd opinion on the flash being good then i must have bad hardware... now that I understand how the ready circuit going to the SYSCON works from the Starship2 then i think I can use this method to test the RSX, CELL, and other components...
In trying to figure our what inputs to the SYSCON will cause a YLOD then here is what I have found so far. All POW_FAIL input for BE, PSU, and RSX are typically high when all is happy and mine is.
The SS2_BRDY has to be low to be happy (mine is low too so I feel I eliminated a bad dump as the cause for my YLOD). The service manual for my COK-002 has been a great help along with ps3 dev wiki's boot and syscon information but still chasing the other inputs that I think can casue the YLOD.
So far I am working on finding the RSX_int and the BE_int capacitors to have a test point for them.