Wii U with solid red light

[BICKnowledge]

Hello peoples,

I'm posting this thread looking for some help fixing a retail Wii U I bought while on holiday in Japan.

Some information about the Wii U in its current state, at the moment trying to power it achieves nothing, I'm only given a solid red light.

On initial press of the power button, I've confirmed two things for certain:

• I can see the it pull approx ~0.5A of power as if it was trying to power up
• I can hear the fan spin up.
• Disk does not spin up (not 100% on this, and console is in pieces at the moment)

I decided to try use the Paid The Beak exploit to try and get ISFSHax installed and hopefully boot into the Wii U.

Long story short, I managed to get ISFSHax installed on the console with problems.

More specifically I managed to install ISFSHax but immediately things seemed a bit wrong, after the installation of ISFSHax completed, I hit the option to restart the console and while the screen went blank the console never actually turned off (confirmed via a constant ~15w of power draw and solid purple light on console).

Upon reboot, without use of Paid The Beak, the console returns to its original state of not being able to boot and only showing a solid red light. Using the Paid The Beak exploit again gets me back into the minute menu, where trying to install again reports that its already installed. So I decided to make backups of the SLC, SLCCMPT, OTP, and SEEPROM.

Trying to boot from SLC or any variety of it halts at the IOS GO GO GO log line and looking at the console light shows a solid purple light and even after an hour doesn't boot. This is the same regardles of whether I patch the slc or sd. I've only managed to get a flashing blue light by trying to re-install the IOSU, and using the boot ios_orig.img option, though this just stays on the flashing blue light for 3+ hours until I ultimately power it off manually.

I've tried various different solutions to other problems such as setting up rednand and or re-installing IOSU, although I would not be surprised if I didn't do these properly and so contributed to my inability to make progress. I'm happy to re-attempt these if others believe there is some chance in retrying them. Additionally In my attempts I've deleted the consoles MLC and SCFM, which as far as I know will just mean save data or similar is lost which is no problem to me.

I've put my SLC.RAW dump via nandBinCheck and it produced the following logs

PS D:\Downloads\NAND Recovery\nandtools> .\nandBinCheck.exe ..\WIIU_BKP\SLC.RAW
** nandBinCheck : Wii nand info tool **
   from giantpune
   built: Mar 24 2017 23:49:06
NAND Type: SLC (WiiU)
checking boot1...
Blocks0to1::CheckBoot1 -> Boot0 block 0 and block 1 not identical!
Boot1 check failed!
checking for lost clusters...
total used clusters 3033 of 0x8000
found 0 lost clusters
UNK ( 0xffff ) 0 ()
free            48bd
verifying ecc...
1 out of 900800 pages had incorrect ecc.
they were spread through 1 clusters in 1 blocks:
 (0)
0 of those clusters are non-special (they belong to the fs)
verifying hmac...
verifying hmac for 487 files
hmac bad (1)
"scfm.img" is 8004000 bytes ( 2001 ) clusters

00000000  ff000000 00000000 00000000 00000000  ................
00000010  00000000 00000000 00000000 00000000  ................
00000020  00000000 00000000 00000000 00000000  ................
00000030  00000000 00000000 00000000 00000000  ................

00000000  ff000000 00000000 00000000 00000000  ................
00000010  00000000 00000000 00000000 00000000  ................
00000020  00000000 00000000 00000000 00000000  ................
00000030  00000000 00000000 a001a001 680f9700  ............h...

00000000  69853343 02199773 e6120cb6 c2126e28  i.3C...s......n(
00000010  552d2b83                             U-+.
bad HMAC for "/scfm.img"
1 files had bad HMAC data
checking HMAC for superclusters...
0 superClusters had bad HMAC data
PS D:\Downloads\NAND Recovery\nandtools>

And as far I understand there a two copies of the boot1 instructions in the SLC and that they're out of sync, and I don't know nearly enough to determine if this is whats causing my other issues with ISFSHax as well as my inability to boot the console.

I've managed to pull the latest log from the SLC dump as well as some config files. The nandBinCheck result leads me to believe the root problem is my Boot1? and from the Ultimate Wii U Troubleshooting Guide Boot1 corruption instructions are not yet available.

My next steps were going to be to try setup a defuse as I already have all the stuff (was originally planning on doing the defuse mod chip but PTB came out before I got to it) but I want to exhaust my other avenues first.

If anyone here familiar with this could offer some insight as to next steps or etc. I'm happy to provide whatever additional information is required, any help would be seriously appreciated!

 

[SDIO]

The two boot1 versions beeing different isn't a problem. It is important that the boot1 version matches the version for the slot in the seeprom. But the versions being different is fishy. So try syncing the seeprom boot1 version. You can do that in the backup and restore menu. Maybe one boot1 is older for some reason or the primary one might just be corrupted. It might take a few attempts. Also make note of the boot1 versions it reports. (and if the version looks fishy, then don't sync)
If you boot with PTB, I wouldn't be surprised if that also intereferes with the reboot. Since it also causes problems with the Power off when installing ISFShax.

 

[BICKnowledge]

In my previous debugging, I tried to sync the boot1 version . Though that was after I got a seeprom backup, so I hope thats okay.

Ill try get the boot1 version reported tomorrow when I get back home, I’m assuming the sync boot1 recovery menu displays the boot1 version?

Post automatically merged: Oct 26, 2025

Ok found it ISFSHax reports boot1 version as being 8377.

I took a look at the syncing the boot1 version using ISFSHax and the log shows the following:

"Refusing to sync NAND boot1 version 0x6000005f (erased NAND page?)"

SEEPROM boot1 version are already synced with NAND

Press POWER/Q or EJECT/P to return

I also took a look at the seeprom.bin dump, and compared to another posted for another WUP-50 console, and they look similar enough as far as I can tell so that look OK.

I also managed to fix my SLC.RAW to a degree.

I looked at the hex for the boot1 area and was missing the Ancast header (0xEFA282D9) for the first block of boot1. Luckily it seems block2 was in tact (had the ancast header). So I copied over block2 (0x21000-0x41FFF) to block1 (0x0-0x20FFF) and running that via nandBinCheck results in:

PS C:\Users\Administrator\Documents\WIIU_BKP> .\nandtools\nandBinCheck.exe E:\SLC.RAW
** nandBinCheck : Wii nand info tool **
   from giantpune
   built: Mar 24 2017 23:49:06
NAND Type: SLC (WiiU)
checking boot1...
Boot1 hash: "3806d41a5c5f139f5b09bbe5b74a5ec45e0f5507"
Boot1 OK!
checking for lost clusters...
total used clusters 3033 of 0x8000
found 0 lost clusters
UNK ( 0xffff ) 0 ()
free            48bd
verifying ecc...
0 out of 900800 pages had incorrect ecc.
they were spread through 0 clusters in 0 blocks:
 ()
0 of those clusters are non-special (they belong to the fs)
verifying hmac...
verifying hmac for 487 files
hmac bad (1)
"scfm.img" is 8004000 bytes ( 2001 ) clusters

00000000  ff000000 00000000 00000000 00000000  ................
00000010  00000000 00000000 00000000 00000000  ................
00000020  00000000 00000000 00000000 00000000  ................
00000030  00000000 00000000 00000000 00000000  ................

00000000  ff000000 00000000 00000000 00000000  ................
00000010  00000000 00000000 00000000 00000000  ................
00000020  00000000 00000000 00000000 00000000  ................
00000030  00000000 00000000 a001a001 680f9700  ............h...

00000000  69853343 02199773 e6120cb6 c2126e28  i.3C...s......n(
00000010  552d2b83                             U-+.
bad HMAC for "/scfm.img"
1 files had bad HMAC data
checking HMAC for superclusters...
0 superClusters had bad HMAC data
PS C:\Users\Administrator\Documents\WIIU_BKP>

Though unfortunately writing the 'fixed' SLC to the consoles hasn't really changed anything

 

[SDIO]

Flash just the slc_boot1. If you restore the whole SLC it might exclude the boot1 (but it should report it if it does)

 

[BICKnowledge]

Took a backup of boot1_SLC, and looked at the dump, it looks as though it had not been updated to my fixed version.

I tried to use the minute recovery menu to flash boot1 specifically and it errored out. I tried with both the backup of BOOT1_SLC.RAW and with my fixed version.

I also tried to restore the SLC again and the same warning about boot1 and ISFSHax comes up but otherwise seems like its not restoing the boot1 area.

Asked chat gpt to see what it would come up with for this error and I think it might be trying to gaslight me into renaming my SLC.RAW to BOOT1_SLC.RAW and trying to run the BOOT1_SLC restore with that .

 

[SDIO]

You probably need to use this minute: https://gbatemp.net/threads/how-to-set-up-isfshax.642258/post-10705309
The released one doesn't allow writing the boot1 from ptb.
The boot1_slc.raw should be 132KiB. I think you already copied that from the second slot to fix your slc image.

 

[BICKnowledge]

Just tried the version of minute you referenced and restored my BOOT1_SLC.RAW (132KiB) it failed for a different reason this time. Seems like it has a problem with the boot1 I restored?

Should the BOOT1_SLC have not contained ECC or something?

Also the ISFSHax thinks its no longer installed as there are apparently uncorrectable ecc errors:

So restoring the SLC as a whole is unavailable since it thinks ISFSHax isnt installed as well as defuse

 

[SDIO]

If you restore the raw, then it should contain the spare data. If you restore the bin, then it should only contain the user data, so it would be 128KiB for bin.

The minute I linked you shouldn't give you the "SLC Restore not allowed" message. Did you make sure to rebuild your PTB SD with that?

 

[BICKnowledge]

Ah, I didn't rebuild the PTB minute menu, I have a second SD (64gb), with ISFSHax that I updated. By replacing the fw.img file.

So I should be using the fw.img to build a new PTB packae and use that to restore? If thats the case how would I get the SLC.RAW on there as once I flash the SD card with PTB it won't show up in windows for me to drop to SLC dump on there.

Post automatically merged: Oct 28, 2025

Edit: I just tried to building a new PTB package and used me other SD card to restore from and that began the restore process.

Post automatically merged: Oct 28, 2025

I've tried flashing both SLC.RAW and BOOT1_SLC.RAW but ISFSHax is still showing uncorrectable ecc errors. And otherwise console state hasn't changed outside of this.

Seems as though no matter what I flash nothing changes, installing ISFSHax somehow completes but once I try to uninstall it errors out with

nand: uncorrectable ecc errror
nand: uncorrectable ecc errror
nand: uncorrectable ecc errror
nand: uncorrectable ecc errror
EEROR: Failed to find isfshax superblock (-1)

 

[SDIO]

If you dump the SLC again and compare it with what you flashed, do you see differences? Maybe the block where the boot1 lives became bad

 

[BICKnowledge]

I do see some differences but not in the boot1 area, first difference detected is at 0x20F39781

I think boot1 might be fine system wise, i believe it might just be the superblock area?

Ill try it again tomorrow morning, just in case but otherwise if slc has potentially gone bad, what would be next steps?

 

[SDIO]

What does nandbin check say to the redumped SLC?
Did the boot1 versions sync?
In minute you can print the super block info, show a picture of that

 

[BICKnowledge]

So first result of nandbincheck is what I flashed, second is what I got back:

Original

PS Z:\Wii U\nandtools> .\nandBinCheck.exe E:\SLC.RAW
** nandBinCheck : Wii nand info tool **
   from giantpune
   built: Mar 24 2017 23:49:06
NAND Type: SLC (WiiU)
checking boot1...
Boot1 hash: "3806d41a5c5f139f5b09bbe5b74a5ec45e0f5507"
Boot1 OK!
checking for lost clusters...
total used clusters 3033 of 0x8000
found 0 lost clusters
UNK ( 0xffff ) 0 ()
free            48bd
verifying ecc...
0 out of 900800 pages had incorrect ecc.
they were spread through 0 clusters in 0 blocks:
 ()
0 of those clusters are non-special (they belong to the fs)
verifying hmac...
verifying hmac for 487 files
0 files had bad HMAC data
checking HMAC for superclusters...
0 superClusters had bad HMAC data
PS Z:\Wii U\nandtools>

Dumped after flash

PS C:\Users\Administrator\Documents\WIIU_BKP> .\nandtools\nandBinCheck.exe .\CUR_SLC.RAW
** nandBinCheck : Wii nand info tool **
   from giantpune
   built: Mar 24 2017 23:49:06
NAND Type: SLC (WiiU)
checking boot1...
Boot1 hash: "3806d41a5c5f139f5b09bbe5b74a5ec45e0f5507"
Boot1 OK!
checking for lost clusters...
total used clusters 3033 of 0x8000
found 0 lost clusters
UNK ( 0xffff ) 0 ()
free            48bd
verifying ecc...
0 out of 900800 pages had incorrect ecc.
they were spread through 0 clusters in 0 blocks:
 ()
0 of those clusters are non-special (they belong to the fs)
verifying hmac...
verifying hmac for 487 files
0 files had bad HMAC data
checking HMAC for superclusters...
0 superClusters had bad HMAC data

Superblocks:

 

[SDIO]

If you install isfshax, which superblocks oes it report to be installed to? Usually it installs to the highes 4. And strangely the highest 4 in your case report bad. If they are bad, it should try to install to other blocks. But it's strange that only these 4 are bad while the others are fine and they are also nowhere near worn to their expected P/E cycles.

 

[BICKnowledge]

They were originally fine, but only when I tried to flash the boot1_slc incorrectly (only updated my second SD cards fw.img) did it say those blocks were bad.

And every time I try install isfshax it seems to increment and tryjing to uninstall errors out with -1, could not find isfshax superblock.

Also looked into my SLC.RAW, I believe I may have installed ISFSHax before my backup as I can see references in the dump. My uneducated guess would be if restorce SLC.RAW and try install ISFSHax again and see that the top 4 blocks have gone back up to 60 that potentially the SLC.RAW already having ISFSHax may be related?

Also would using the original fw.img instead to flash SLC.RAW be worth trying?

 

[SDIO]

That is strange. It seems like the ISFShax installer isn't writing these blocks correctly, but minute is. And strangely only the ISFShax superblocks and not the other superblock it updates to blacklist the ISFShax blocks.
I have never seen anything like that before.
I probably have to make a version of minute that ignores the ECC so we can see what's actually written and have a closer look at the installer

 

[BICKnowledge]

Since its a problem with superblocks, I take it I should probably hold off of experimenting in case I make things worse?

 

[SDIO]

I don't think it will get worse. You have a SLC backup that is good and minute seems to be able to write the SLC just fine. The question is why the installer is failing at that.
Also make sure you don't have the otp.bin from another console on the SD, as that might mess things up.

 

[BICKnowledge]

I managed to fix the uncorrectable ecc?

I just flashed my original SLC.RAW with my original dump and then flashed the original boot1_slc.raw and now ISFSHax is detected as installed again. Tested by uninstalling ISFSHax and re-installing after reboot.

So I'm going to un-install ISFSHax, take another backup.

Once that's done I'll repair boot1 again, and flash the fixed boot1 to the console

Post automatically merged: Nov 1, 2025

Ok, made another backup of the SLC with both ISFSHax installed and boot1 flashed and chucking that via nandBindCheck results in:

PS C:\Users\Administrator\Documents\WIIU_BKP> .\nandtools\nandBinCheck.exe C:\Users\Administrator\Downloads\SLC.RAW
** nandBinCheck : Wii nand info tool **
   from giantpune
   built: Mar 24 2017 23:49:06
NAND Type: SLC (WiiU)
checking boot1...
Boot1 hash: "3806d41a5c5f139f5b09bbe5b74a5ec45e0f5507"
Boot1 OK!
checking for lost clusters...
total used clusters 3033 of 0x8000
found 0 lost clusters
UNK ( 0xffff ) 0 ()
free            48bd
verifying ecc...
0 out of 900800 pages had incorrect ecc.
they were spread through 0 clusters in 0 blocks:
 ()
0 of those clusters are non-special (they belong to the fs)
verifying hmac...
verifying hmac for 487 files
hmac bad (1)
"scfm.img" is 8004000 bytes ( 2001 ) clusters

00000000  ff000000 00000000 00000000 00000000  ................
00000010  00000000 00000000 00000000 00000000  ................
00000020  00000000 00000000 00000000 00000000  ................
00000030  00000000 00000000 00000000 00000000  ................

00000000  ff000000 00000000 00000000 00000000  ................
00000010  00000000 00000000 00000000 00000000  ................
00000020  00000000 00000000 00000000 00000000  ................
00000030  00000000 00000000 a001a001 680f9700  ............h...

00000000  69853343 02199773 e6120cb6 c2126e28  i.3C...s......n(
00000010  552d2b83                             U-+.
bad HMAC for "/scfm.img"
1 files had bad HMAC data
checking HMAC for superclusters...
0 superClusters had bad HMAC data
PS C:\Users\Administrator\Documents\WIIU_BKP>

I hoped this would mean the console would boot successfully now but I'm not that lucky. I take it that rebuilding the MLC is probably my next step as to why its not booting? (deleted the MLC and SCFM early on). Though at the moment the console still has a solid red light, so if SLC and Boot1 were OK I would have thought the symptoms would have changed?

In regards to rebuilding the MLC.
I've delete MLC and SCFM again downloaded the Japanese MLC titles and placed under wafel_install and added wafel_setup_mlc.ipx to my wii u/ios_plugins.

Currently running Patch (sd) and boot IOS (slc), get to the GO GO GO stage and hangs there indefinitely, that staus light just stays purple.

 

[SDIO]

Is the boot1 version synced with the seeprom?