CR4 XL not working, RGH2+ install

[MrKronic 7]

Now that you mention it, there is a small SMD resistor by where you would solder the NAND points, on the bottom I think (I only have a slim trinity board for reference so I could be wrong) but check to see if R2C8 is properly in place, just look and see if its on straight or if its crooked from maybe some impact damage.

I remember once while repairing someone's console that that resistor was slightly off and as it turned out one side had a cracked solder joint. Maybe yours does too. Not sure, if it looks fine don't screw with it. as far as SMD capacitors go, you can only test the for faults when they're not soldered to anything. Maybe get in there with a magnifying glass and look for visible thermal damage?

Point being, I thought possible short or bridged contact because you said it worked up until desoldering your NAND wires. Maybe check your wire patch, did you use flux like I suggested? Did the solder take hold or is it floating above the area you soldered? Don't tug the wires maybe lightly nudge them with a small plastic probe? If they're stationary, then move on to the next area of the board where you were working.

R2C8 looks fine to me. And regarding wire patches, I checked 'em out to make sure they don't move. As for flux, I used solder paste instead which I use for all PCB jobs. Never had a problem with it at all.

 

Your CPU_RST repairs isn't the best, the wire should definitely NOT go under the x-clamp, it'll quite likely be crushed by the x-clamp at some point... i would suggest making that one slightly longer so it goes where the x-clamp isn't going to damage it...

Another possible reason for the failure is NAND corruption, if you didn't start it after writing, maybe the write didn't go quite as planned, i would suggest you connect the NAND cables again, do a full erase, write the image once again and dump it, if the data is a 1:1 match and it's still not booting up, it's probably a hardware problem... i recall you saying you didn't test it before putting it back in the case? did you at all test it after writing the image?

Unfortunately this is the best I can do with a soldering tip that's larger than the points itself. I made the wires short so that they don't get to move around much. Anywho I moved the wire loop away from the X-Clamp now, if its fine. Not messing around with the joints anymore because I sealed them up with glue (they were perfectly soldered though)

To clarify,I did test out the console right after flashing the image through Xell. The console booted up fine then. At that moment the motherboard was fitted into the metal case with the DVD drive and wireless module installed (besides the fans and ROL board of course). The problem began right after I fitted all of the remaining componets and the screws and put the console back togethter. By all accounts, it probably isn't a NAND problem.

Is there any possibility that this could be an issue with the SOuthbridge? If yes, how do I check to be sure? Or could it be the ROL or the PSU?

 

[Swizzy 2083]

Unfortunately this is the best I can do with a soldering tip that's larger than the points itself. I made the wires short so that they don't get to move around much. Anywho I moved the wire loop away from the X-Clamp now, if its fine. Not messing around with the joints anymore because I sealed them up with glue (they were perfectly soldered though)

To clarify,I did test out the console right after flashing the image through Xell. The console booted up fine then. At that moment the motherboard was fitted into the metal case with the DVD drive and wireless module installed (besides the fans and ROL board of course). The problem began right after I fitted all of the remaining componets and the screws and put the console back togethter. By all accounts, it probably isn't a NAND problem.

Is there any possibility that this could be an issue with the SOuthbridge? If yes, how do I check to be sure? Or could it be the ROL or the PSU?

When you put the screws back into place, you probably damaged one or more of the cables, you should really check for continuity on each one... it's quite possible that you caused damage to one or more of the components on the board aswell when said cable was damaged... you should probably also check if any of them looks crushed or anything like that, this may have lead to the cable being shorted which would've possibly damaged components along it's signal path

Can you also show us some images of the NAND points on the bottom side of the board?

It could actually be a nand issue despite working after flashing it, if you didn't power cycle after booting (unplug power and plug it back in) the SMC that was running was the last one to be there before the actual re-write, but it's highly unlikely to be a bad SMC causing this at this point... however, you could've accidentally erased the NAND by shorting the wrong points (i've seen it happen)

[MrKronic 7]

When you put the screws back into place, you probably damaged one or more of the cables, you should really check for continuity on each one... it's quite possible that you caused damage to one or more of the components on the board aswell when said cable was damaged... you should probably also check if any of them looks crushed or anything like that, this may have lead to the cable being shorted which would've possibly damaged components along it's signal pathCan you also show us some images of the NAND points on the bottom side of the board?It could actually be a nand issue despite working after flashing it, if you didn't power cycle after booting (unplug power and plug it back in) the SMC that was running was the last one to be there before the actual re-write, but it's highly unlikely to be a bad SMC causing this at this point... however, you could've accidentally erased the NAND by shorting the wrong points (i've seen it happen)

Just rechecked all the wires for continuity like you said. They're all clean and none of them appears to be crushed or damaged. Besides, as far as I'm concerned, the only screw that actually intersects with the wire's pathway is a large one that goes at the center. I kept it blank since I knew there was a wire at that point.

I'll try flashing the stock nand to see if it boots then.

Here are the NAND images. Hope they help.

[MrKronic 7]

UPDATE: Console is booting after flashing back to stock!!!! So hardware issue is out.

This time around, I've noticed that the updflash.bin image that is being created by Jrunner always has an older CB version (13121) for some reason even after using the  recommended settings. If I'm correct, then that must be what's causing this problem. Should not have used that s#@* in the first place Anyway, how do I go about building an updflash.bin image in xebuild gui with an altered SMC setting?

[felida 1653]

UPDATE: Console is booting after flashing back to stock!!!! So hardware issue is out.

This time around, I've noticed that the updflash.bin image that is being created by Jrunner always has an older CB version (13121) for some reason even after using the recommended settings. If I'm correct, then that must be what's causing this problem. Should not have used that s#@* in the first place Anyway, how do I go about building an updflash.bin image in xebuild gui with an altered SMC setting?

It uses a diff cb as its less patches.. Swizzy even stated this himself on diff thread.. But principle still applies.. I myself use jrunner.. No probs.. Matter of fact both xebuildgui and jrunner use xebuild to do their work.. Only diff is features mate ;-)

[MrKronic 7]

It uses a diff cb as its less patches.. Swizzy even stated this himself on diff thread.. But principle still applies.. I myself use jrunner.. No probs.. Matter of fact both xebuildgui and jrunner use xebuild to do their work.. Only diff is features mate ;-)

That might be, but something must be up with the NAND image that's causing this. Just reflashed a fresh updflash.bin, console's back to where it started

[StaticPulse 261]

That might be, but something must be up with the NAND image that's causing this. Just reflashed a fresh updflash.bin, console's back to where it started

Just re-wrtie ECC to boot XeLL and I think you should be good to go. If the problem replicates then there may possibly be heat damage? I had something similar happen to me with a Falcon once but it would freeze roughly five minutes after booting.

[MrKronic 7]

Tried that route already.Boots to Xell fine, but the issue pops up right after I flash the updflash file and powercycle console.I presume if it was hardware, even Xell wouldn't have worked.

Also I'm posting an image of Xell if it helps

[Swizzy 2083]

Tried that route already.Boots to Xell fine, but the issue pops up right after I flash the updflash file and powercycle console.I presume if it was hardware, even Xell wouldn't have worked.

Also I'm posting an image of Xell if it helps

IMG_20151115_001334ed.jpg

If XeLL works when you put the console back into the board, it's not a hardware issue... if it don't work with the JRunner image, i can build you a image with the correct SMC with xeBuild GUI... you'll just have to give me your key and nand dump, later on you just tell it to do RGH2 and feed it the hacked dump like usual and it'll be fine... (it doesn't replace the SMC for those, only JTAG's have the smc replaced)