The NAND dumps in the build are not from a 4GB Corona....

If you've wired it up properly, VCC removed will prevent the console from glitching. Most home-made enable/disable switches use this technique with no consequence.

I would advise posting your full xebuild log to ensure the smc was patched accordingly. I would also compare the decrypted patched SMC with similar from another Corona to see whether Xebuild is dealing with it properly.

The biggest issue is people thinking the ECC has been written when in fact it hasn't.

You can test this by removing the VCC cable from your glitch chip. If it boots to retail dash, nothing was written.

If you want to resolve those bad block mappings, create a new image using 'noremap' option in xebuild and then use a 360 app called 'NANDFlasher 360 v1.20' to write to to the console. It'll erase the NAND and write the image, automatically mapping the blocks it deems as bad.

You need the CPU key, first and foremost. Any other dump of a NAND you have may fail for three reasons:

1. Wrong encryption of NAND.
2. CB fuse revocation.
3. CF/CG fuse revocation.

As you don't have the original keyvault, this console can never be used as retail. It needs to be an RGH only.

So therefore you need the CPU key from this console (use a Coolrunner / CPLD with an RGX ECC) and decrypted donor files from another trinity (kv_dec.bin, smc_dec.bin & smc-config.bin).

Then use something like J-Runner to build an RGH image using these files and the CPU key.

Yep - do as phonsey suggests. You've half-cooked the firmware (one of the reasons you shouldn't use the console as a power source) so just send the erase command again.

No-one should be needing MRA, especially if you have the key already.

Cool Glad you got it sorted.

If the firmware is corrupted, it won't respond to anything.

Unless you physically did something wrong like plug in upside-down, it should do SOMETHING.

Send vendor intro and turn the drive off and on as indicated. The area to the right of JF should have a status (0x80 for example). If this changes at any point, the drive is responsive still. So stop the vendor intro by pressing ESC and send a lite-on erase command to the port, THEN try Vendor intro again.

Hi

There's no 'notorious E79' issue with any JTAG. In truth it always comes down to two things:

1. Soldering.
2. Wiring config not matching the chosen SMC config.

There's a 3rd variable in that some GPUs have faulty TDI/TMS connections and I've personally had to replace 1 GPU which was still failing after a reball.

However since you did manage to get Xell working at one point, I don't think this is the issue.

So..

1. Choosing a wiring method and stick to it. Two diodes and a bridge (either solid or with a 330ohm resistor) should be fine. If you're sticking with standard config, that's DB1F1 and RoL. If you're going AUD_CLAMP, it's DB1F1 and Q2N1.

2. Once you've decided, write XeLL. If you went with RoL, untick AUD_CLAMP in J-Runner. If not, tick it.

3. Unplug the 360 for 20 secs to clear the SMC cache - this part is VERY important. If you don't, you'll still be using the SMC cache in the southbridge from the previous config.

It should boot XeLL provided your wiring is all good.

In my experience, if you need to put pressure on a RAM brick to make a console boot, it needs a reflow.

I generally use standard SMC wiring on all consoles without issue, with the obvious exception of Zephyrs which prefer the DB1F1/AUD_CLAMP route.

If you're getting sporadic E79 errors and you've tried both ARGON_DATA and AUD_CLAMP, it may be a problem with the GPU or connections therein. Remember that TMS and TDI go directly to the GPU via 1.5k resistors and it wouldn't be the first time I've had to reflow a GPU in order to resolve similar issues. In one instance I had to replace the GPU completely.

If you can boot to XeLL, you have the CPU key of the console.

So what you're saying is the KV used in the dump is not from this console originally.

Therefore you just need a decrypted NAND and then use this with the rest of the image you have.

So you have nothing from your existing dump?

After doing a number of these, I recommend the following path.

Replace the main MT IC first. Leave the SPI to one side. If you Vendor Intro the board, you should get a 0x72 with a flash ID of FF / FF and a nice message in JF about returning the MRA switch - this is obviously because the SPI isn't there at all.

Once you're happy with the PCB responding to Vendor Intro, go ahead and install the SPI IC. No point in doing both then trying to troubleshoot them together.

What's the history of the console?

I've not seen a GPU-related RRoD Jasper yet.

I would look at replacing the HANA firstly.

Remove R7R17 and check resistance. It should be 10k. If it's not, replace it. You can use R6T3 as a replacement and protect your console from being updated in the future.

If it reads at 10k, Check resistance from CPU_PLL_BYPASS and GND. If it's 0 Ohm, you've killed the CPU.

Why wouldn't you want the full data burned onto a disc? Are you not aware that some games fail during play because they're missing data in the last 3%?