Releases · StroopwafelCFW/wii_u_modchip

23 Jul 00:26

shinyquagsire23

v1.1

ea84680

Binary Zip v1.1 Latest

Latest

What's New?

Fixed OTP dumping failure caused by corrupted PRSH

INSTALLATION INSTRUCTIONS

REQUIRED FILES

boot1.img -- SD card image for minute_minute
boot1_slccmpt.img -- NAND-flashable minute boot1, for using >2GiB SD cards
fw.img -- Main bootloader, minute
wiiu/ios_plugins/wafel_core.ipx -- Stroopwafel core, this plugin loads first and bootstraps all other plugins in wiiu/ios_plugins.
otp.bin -- This can be dumped via the minute menu, under
Backup and Restore > Dump OTP via PRSHhax.
The menu will still be available if otp.bin is not present,
however IOS will not be able to boot.

The following versions are provided in the zip:

pico_defuse @ ea84680
stroopwafel @ 82464ce3b3e43577ab1ca825e9ff34c903a2c7c0
minute_minute @ 464ee918dc97567d79e1b9d2913acb2b879217ec

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, the wiiu folder, and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

Your SD card file structure should contain the following, or it will not boot:

sdmc:/
├── fw.img
└── wiiu
    └── ios_plugins
        └── wafel_core.ipx
        └── wafel_debug_exts.ipx

A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

minute can be configured to autoboot into IOS via sdmc:/minute/minute.ini. To trigger the menu manually, press (but do not hold) the power button 3-5 times (like you're trying to get into the BIOS on a computer), or until the menu shows up on the serial console. From here you can swap the SD card and make NAND backups. To back up MLC, it is currently recommended to Format redNAND with a 64GB SD card, and then copy the partitions off the SD card.

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

minute now supports restoring NAND backups, however there still may be some lingering bugs. AS LONG AS YOU HAVE A KNOWN-GOOD SLC.RAW and SLCCMPT.RAW BACKED UP SOMEWHERE SAFE, YOU WILL BE FINE!! I managed to completely wipe my SLCCMPT and restore it, but I also had one restore where some sectors didn't program for some reason. It could have just been my SD card though.

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

REDNAND

RedNAND can be configured using sdmc:/minute/rednand.ini. If you have an older redNAND (de_Fuse 0.7 or so), you can use the following INI file:

[partitions]
slccmpt=true
slc=true
mlc=true

[scfm]
disable=false
allow_sys=false

[disable_encryption]
mlc=false

GPU OVERCLOCKING

minute has experimental support for overclocking (or underclocking) the Radeon GPU by specifying PLL parameters in the ini file. This can potentially harm your Wii U if you don't check your math! Or your Wii U will just not boot into the menu or may otherwise become unstable in normal usage.

Manual PLL overrides overview:

div_select = ?
clkV is spread spectrum related maybe?
clkS is clock source...?

clkXtal = 27MHz
clkO = clkO0Div, clkO1Div, or clkO2Div (based on div_select)
clkF = (clkFMsb << 16) | (clkFLsb << 1)
freqMhz = clkXtal * (clkF/0x10000) / (clkR+1) / (clkO/2)

Example unmodified INI values:

; Defaults:
; GPU = 544.999878MHz
; 27 * (0x285ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_r = 0x0
gpu_clk_f = 0x285ED0
gpu_clk_s = 0x1C2
gpu_clk_v = 0x7
gpu_clk_o_0div = 0x4
gpu_clk_o_1div = 0x4
gpu_clk_o_2div = 0x0

Example overclock:

; GPU = 679.999878MHz (1.25x)
; 27 * (0x325ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_f = 0x325ED0

The GPU gets unstable at around 770MHz in my testing.

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.
A brief purple flash means that the custom boot1 has loaded, and glitching was successful. If it stays solid purple, then it has loaded fw.img from the SD card.
A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root, or the SD card failed to mount.

Assets 3

13 May 02:27

shinyquagsire23

v1.0

ea84680

Binary Zip v1.0

What's New?

minute/minute boot1 now supports ECO mode (standby, yellow LED)
Pico firmware now supports ECO mode
Significant redNAND improvements (SFCM disabling, encryption disabling, etc)

INSTALLATION INSTRUCTIONS

REQUIRED FILES

boot1.img -- SD card image for minute_minute
boot1_slccmpt.img -- NAND-flashable minute boot1, for using >2GiB SD cards
fw.img -- Main bootloader, minute
wiiu/ios_plugins/wafel_core.ipx -- Stroopwafel core, this plugin loads first and bootstraps all other plugins in wiiu/ios_plugins.
otp.bin -- This can be dumped via the minute menu, under
Backup and Restore > Dump OTP via PRSHhax.
The menu will still be available if otp.bin is not present,
however IOS will not be able to boot.

The following versions are provided in the zip:

pico_defuse @ ea84680
stroopwafel @ 82464ce3b3e43577ab1ca825e9ff34c903a2c7c0
minute_minute @ 60ef681343019146d8a4447d190b423174ea6501

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, the wiiu folder, and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

Your SD card file structure should contain the following, or it will not boot:

sdmc:/
├── fw.img
└── wiiu
    └── ios_plugins
        └── wafel_core.ipx
        └── wafel_debug_exts.ipx

A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

REDNAND

RedNAND can be configured using sdmc:/minute/rednand.ini. If you have an older redNAND (de_Fuse 0.7 or so), you can use the following INI file:

[partitions]
slccmpt=true
slc=true
mlc=true

[scfm]
disable=false
allow_sys=false

[disable_encryption]
mlc=false

GPU OVERCLOCKING

Manual PLL overrides overview:

div_select = ?
clkV is spread spectrum related maybe?
clkS is clock source...?

clkXtal = 27MHz
clkO = clkO0Div, clkO1Div, or clkO2Div (based on div_select)
clkF = (clkFMsb << 16) | (clkFLsb << 1)
freqMhz = clkXtal * (clkF/0x10000) / (clkR+1) / (clkO/2)

Example unmodified INI values:

; Defaults:
; GPU = 544.999878MHz
; 27 * (0x285ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_r = 0x0
gpu_clk_f = 0x285ED0
gpu_clk_s = 0x1C2
gpu_clk_v = 0x7
gpu_clk_o_0div = 0x4
gpu_clk_o_1div = 0x4
gpu_clk_o_2div = 0x0

Example overclock:

; GPU = 679.999878MHz (1.25x)
; 27 * (0x325ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_f = 0x325ED0

The GPU gets unstable at around 770MHz in my testing.

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.
A brief purple flash means that the custom boot1 has loaded, and glitching was successful. If it stays solid purple, then it has loaded fw.img from the SD card.
A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root, or the SD card failed to mount.

Assets 3

16 Aug 22:44

shinyquagsire23

v0.8

c4743ad

Binary Zip v0.8 Pre-release

Pre-release

What's New?

Improved Pico firmware's PRSHhax reliability, maybe.
minute boot1 now blinks a yellow LED until it successfully mounts any inserted SD card.
Added support for flashing sdmc:/boot1_slccmpt.img to vWii NAND, instead of a 2GiB SD card.
- This change requires reflashing the Pico firmware.
- Copy boot1_slccmpt.img to the SD card and flash via Backup and Restore > Restore BOOT1_SLCCMPT.IMG
- This allows booting with a >2GiB/SDHC SD card inserted (de_Fuse is still required)
- Normal booting (ie, without an SD card inserted) is currently unimplemented if boot1_slccmpt.img is flashed.
- If your console fails to boot with de_Fuse following flashing boot1_slccmpt.img, downgrade your Pico firmware to v0.7 to force an SDcard-only or normal boot.
- There is no currently guarantee that an SD card boot1.img will load before vWii NAND's boot1. SD card and NAND have equal and ~random boot priority.
Added support for flashing sdmc:/boot1_slc.img to Wii U NAND.
- This allows flashing CDN boot1 images to NAND.
- This option is ONLY for restoring boot1 on corrupted systems. Do not flash minute boot1.img/boot1_slccmpt.img to NAND or it will break PRSHhax.
(v0.7.1): Fix boot1.img hanging on loading sdmc:/fw.img.
(v0.7) This is the first release featuring Stroopwafel! Support is still being built out, however it is stable and allows for co-existence with Aroma for homebrew.

INSTALLATION INSTRUCTIONS

This is a pre-1.0 release for early adopters who want to know if their RPi Pico is wired correctly for de_Fuse, as well as developers interested in coldboot CFW. A lot of stuff currently is not implemented and/or needs improvements. However, what is provided is enough to verify that the Pico is installed correctly.

REQUIRED FILES

boot1.img -- SD card image for minute_minute
fw.img -- Main bootloader, minute
wiiu/ios_plugins/wafel_core.ipx -- Stroopwafel core, this plugin loads first and bootstraps all other plugins in wiiu/ios_plugins.
otp.bin -- This can be dumped via the minute menu, under
Backup and Restore > Dump OTP via PRSHhax.
The menu will still be available if otp.bin is not present,
however IOS will not be able to boot.

The following versions are provided in the zip:

pico_defuse @ c4743ad
stroopwafel @ 131384b3c39d11c5597f9f7c08f7731b0ed58f68
minute_minute @ 89eb0031a59f350f59d198b0cf4b19bd97d0e5e4

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, the wiiu folder, and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

Your SD card file structure should contain the following, or it will not boot:

sdmc:/
├── fw.img
└── wiiu
    └── ios_plugins
        └── wafel_core.ipx

A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

GPU OVERCLOCKING

Manual PLL overrides overview:

div_select = ?
clkV is spread spectrum related maybe?
clkS is clock source...?

clkXtal = 27MHz
clkO = clkO0Div, clkO1Div, or clkO2Div (based on div_select)
clkF = (clkFMsb << 16) | (clkFLsb << 1)
freqMhz = clkXtal * (clkF/0x10000) / (clkR+1) / (clkO/2)

Example unmodified INI values:

; Defaults:
; GPU = 544.999878MHz
; 27 * (0x285ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_r = 0x0
gpu_clk_f = 0x285ED0
gpu_clk_s = 0x1C2
gpu_clk_v = 0x7
gpu_clk_o_0div = 0x4
gpu_clk_o_1div = 0x4
gpu_clk_o_2div = 0x0

Example overclock:

; GPU = 679.999878MHz (1.25x)
; 27 * (0x325ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_f = 0x325ED0

The GPU gets unstable at around 770MHz in my testing.

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.
A brief purple flash means that the custom boot1 has loaded, and glitching was successful. If it stays solid purple, then it has loaded fw.img from the SD card.
A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root, or the SD card failed to mount.

Assets 3

21 Jul 18:41

shinyquagsire23

v0.7.1

260d068

de_Fuse ZIP v0.7.1 Pre-release

Pre-release

What's New?

Hotfix (v0.7.1): Fix boot1.img hanging on loading sdmc:/fw.img.
This is the first release featuring Stroopwafel! Support is still being built out, however it is stable and allows for co-existence with Aroma for homebrew.

INSTALLATION INSTRUCTIONS

REQUIRED FILES

boot1.img -- SD card image for minute_minute
fw.img -- Main bootloader, minute
wiiu/ios_plugins/wafel_core.ipx -- Stroopwafel core, this plugin loads first and bootstraps all other plugins in wiiu/ios_plugins.
otp.bin -- This can be dumped via the minute menu, under
Backup and Restore > Dump OTP via PRSHhax.
The menu will still be available if otp.bin is not present,
however IOS will not be able to boot.

The following versions are provided in the zip:

pico_defuse @ 489a877
stroopwafel @ 131384b3c39d11c5597f9f7c08f7731b0ed58f68
minute_minute @ ddeb63cff77aab4193d6fd83ab39024033d5cee6

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, the wiiu folder, and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

Your SD card file structure should contain the following, or it will not boot:

sdmc:/
├── fw.img
└── wiiu
    └── ios_plugins
        └── wafel_core.ipx

A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

GPU OVERCLOCKING

Manual PLL overrides overview:

div_select = ?
clkV is spread spectrum related maybe?
clkS is clock source...?

clkXtal = 27MHz
clkO = clkO0Div, clkO1Div, or clkO2Div (based on div_select)
clkF = (clkFMsb << 16) | (clkFLsb << 1)
freqMhz = clkXtal * (clkF/0x10000) / (clkR+1) / (clkO/2)

Example unmodified INI values:

; Defaults:
; GPU = 544.999878MHz
; 27 * (0x285ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_r = 0x0
gpu_clk_f = 0x285ED0
gpu_clk_s = 0x1C2
gpu_clk_v = 0x7
gpu_clk_o_0div = 0x4
gpu_clk_o_1div = 0x4
gpu_clk_o_2div = 0x0

Example overclock:

; GPU = 679.999878MHz (1.25x)
; 27 * (0x325ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_f = 0x325ED0

The GPU gets unstable at around 770MHz in my testing.

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.
A brief purple flash means that the custom boot1 has loaded, and glitching was successful. If it stays solid purple, then it has loaded fw.img from the SD card.
A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root.

Assets 3

15 Jul 21:56

shinyquagsire23

v0.7

260d068

de_Fuse ZIP v0.7 Pre-release

Pre-release

boot1.img in this release is bugged, use a newer release

What's New?

This is the first release featuring Stroopwafel! Support is still being built out, however it is stable and allows for co-existence with Aroma for homebrew.

INSTALLATION INSTRUCTIONS

REQUIRED FILES

boot1.img -- SD card image for minute_minute
fw.img -- Main bootloader, minute
wiiu/ios_plugins/wafel_core.ipx -- Stroopwafel core, this plugin loads first and bootstraps all other plugins in wiiu/ios_plugins.
otp.bin -- This can be dumped via the minute menu, under
Backup and Restore > Dump OTP via PRSHhax.
The menu will still be available if otp.bin is not present,
however IOS will not be able to boot.

The following versions are provided in the zip:

pico_defuse @ 489a877
stroopwafel @ 131384b3c39d11c5597f9f7c08f7731b0ed58f68
minute_minute @ a891e347707747baf2c5f77a01dd3739c9470bdc

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, the wiiu folder, and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

Your SD card file structure should contain the following, or it will not boot:

sdmc:/
├── fw.img
└── wiiu
    └── ios_plugins
        └── wafel_core.ipx

A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

GPU OVERCLOCKING

Manual PLL overrides overview:

div_select = ?
clkV is spread spectrum related maybe?
clkS is clock source...?

clkXtal = 27MHz
clkO = clkO0Div, clkO1Div, or clkO2Div (based on div_select)
clkF = (clkFMsb << 16) | (clkFLsb << 1)
freqMhz = clkXtal * (clkF/0x10000) / (clkR+1) / (clkO/2)

Example unmodified INI values:

; Defaults:
; GPU = 544.999878MHz
; 27 * (0x285ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_r = 0x0
gpu_clk_f = 0x285ED0
gpu_clk_s = 0x1C2
gpu_clk_v = 0x7
gpu_clk_o_0div = 0x4
gpu_clk_o_1div = 0x4
gpu_clk_o_2div = 0x0

Example overclock:

; GPU = 679.999878MHz (1.25x)
; 27 * (0x325ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_f = 0x325ED0

The GPU gets unstable at around 770MHz in my testing.

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.
A brief purple flash means that the custom boot1 has loaded, and glitching was successful. If it stays solid purple, then it has loaded fw.img from the SD card.
A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root.

Assets 3

16 May 01:08

shinyquagsire23

v0.5.1

489a877

de_Fuse ZIP v0.5.1 Pre-release

Pre-release

What's New?

Fixed a bug where only 16 out of 64 ISFS FATs were read, which sometimes caused fw.img to load from SLC incorrectly.
From @OancaAndrei: git cherry-pick'd MLC restoring in Backup and Restore menu. Currently does not support SLC writing from partitions.
Added force_pause option to [boot] INI section, allows pausing before booting for SD swapping.

INSTALLATION INSTRUCTIONS

REQUIRED FILES

boot1.img -- SD card image for minute_minute
fw.img -- Main bootloader, minute
ios.patch -- de_Fuse_iosuhax patch for 5.5.1ish, I think technically it will work on 5.5.5 though?
otp.bin -- This can be dumped via the minute menu, under
Backup and Restore > Dump OTP via PRSHhax.
The menu will still be available if otp.bin is not present,
however IOS will not be able to boot.

The following versions are provided in the zip:

pico_defuse @ 489a877
de_Fuse_iosuhax @ 3f32c2ab234f7371794738a1135ee65b8d753801
minute_minute @ 16d382d83c8f1a5551c021d4a06a4911e020bc54

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, ios.patch and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

GPU OVERCLOCKING

Manual PLL overrides overview:

div_select = ?
clkV is spread spectrum related maybe?
clkS is clock source...?

clkXtal = 27MHz
clkO = clkO0Div, clkO1Div, or clkO2Div (based on div_select)
clkF = (clkFMsb << 16) | (clkFLsb << 1)
freqMhz = clkXtal * (clkF/0x10000) / (clkR+1) / (clkO/2)

Example unmodified INI values:

; Defaults:
; GPU = 544.999878MHz
; 27 * (0x285ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_r = 0x0
gpu_clk_f = 0x285ED0
gpu_clk_s = 0x1C2
gpu_clk_v = 0x7
gpu_clk_o_0div = 0x4
gpu_clk_o_1div = 0x4
gpu_clk_o_2div = 0x0

Example overclock:

; GPU = 679.999878MHz (1.25x)
; 27 * (0x325ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_f = 0x325ED0

The GPU gets unstable at around 770MHz in my testing.

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.

Contributors

OancaAndrei

Assets 3

03 May 02:45

shinyquagsire23

v0.5

489a877

de_Fuse ZIP v0.5 Pre-release

Pre-release

What's New?

Added more safeties around SMC/button presses
Fixed redNAND formatting not aborting properly on the first prompt
Added upp/uploadpatch interactive console cmd for uploading ios.patch over serial.
Added support for manual GPU overclocking via sdmc:/minute/minute.ini (see below)

INSTALLATION INSTRUCTIONS

REQUIRED FILES

The following versions are provided in the zip:

pico_defuse @ 489a877
de_Fuse_iosuhax @ 3f32c2ab234f7371794738a1135ee65b8d753801
minute_minute @ bcd13ef3e4c40442c206a5b54401976c7824bfd4

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, ios.patch and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

GPU OVERCLOCKING

Manual PLL overrides overview:

div_select = ?
clkV is spread spectrum related maybe?
clkS is clock source...?

clkXtal = 27MHz
clkO = clkO0Div, clkO1Div, or clkO2Div (based on div_select)
clkF = (clkFMsb << 16) | (clkFLsb << 1)
freqMhz = clkXtal * (clkF/0x10000) / (clkR+1) / (clkO/2)

Example unmodified INI values:

; Defaults:
; GPU = 544.999878MHz
; 27 * (0x285ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_r = 0x0
gpu_clk_f = 0x285ED0
gpu_clk_s = 0x1C2
gpu_clk_v = 0x7
gpu_clk_o_0div = 0x4
gpu_clk_o_1div = 0x4
gpu_clk_o_2div = 0x0

Example overclock:

; GPU = 679.999878MHz (1.25x)
; 27 * (0x325ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_f = 0x325ED0

The GPU gets unstable at around 770MHz in my testing.

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.

Assets 3

30 Apr 22:49

shinyquagsire23

v0.4

489a877

de_Fuse ZIP v0.4 Pre-release

Pre-release

What's New?

Added TV display output for the menu.
Added option in Backup and Restore to change the SEEPROM SATA drive type.
Added support for using the serial console for Power/Eject prompts.
The Konami code is now required for SEEPROM restores.
Fixed a bug where if SMC is held in reset (or is otherwise unresponsive somehow) it will no longer spam the menu with fake button presses.
Improved serial scrollback.
Misc reliability improvements.

INSTALLATION INSTRUCTIONS

This is an initial release for early adopters who want to know if their RPi Pico is wired correctly for de_Fuse. A lot of stuff currently is not implemented and/or needs improvements. However, what is provided is enough to verify that the Pico is installed correctly.

REQUIRED FILES

The following versions are provided in the zip:

pico_defuse @ 489a877
de_Fuse_iosuhax @ 3f32c2ab234f7371794738a1135ee65b8d753801
minute_minute @ 687492e22978eb565d8413aed16513df84add147

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, ios.patch and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.

Assets 3

26 Apr 09:21

shinyquagsire23

v0.3

0f424d0

de_Fuse ZIP v0.3 Pre-release

Pre-release

What's New?

boot1.img now verifies the BoardConfig CRC32, and if it is not valid, DRAM is initialized using fallback defaults.
Added PRSHhax-based OTP dumping support for all boot1 versions available on CDN (prod and dev)
Added BOOT1_SLC.RAW dumping and restoring
Added support for restoring seeprom.bin
- This option can result in an inability to dump OTP via PRSH hax if you do something stupid!
- I added as many verification/safety measures as I could to make sure that PRSH hax wouldn't get locked out, but at the end of the day it's the user's responsibility to keep otp.bin and seeprom.bin backed up and safe.
- A incomplete list of things that can stop working irrecoverably if you lose your seeprom.bin backup and flash something incorrect includes:
  - The disk drive
  - Saves stored on USB drives
Added support for syncing SEEPROM boot1 versions with NAND after flashing BOOT1_SLC.RAW
- This option requires a copy of otp.bin from the same console (and this is verified).
Adjusted redNAND partitioning to place 1MiB of free space at the start of the SD card for Ancast images.
Misc reliability improvements

INSTALLATION INSTRUCTIONS

REQUIRED FILES

boot1.img: SD card image for minute_minute
fw.img: Main bootloader, minute
ios.patch: de_Fuse_iosuhax patch for 5.5.1ish, I think technically it will work on 5.5.5 though?
otp.bin: This can be dumped via the minute menu, under Backup and Restore > Dump OTP via PRSHhax. The menu will still be available if otp.bin is not present, however IOS will not be able to boot.

The following versions are provided in the zip:

pico_defuse @ 07afb41
de_Fuse_iosuhax @ 3f32c2ab234f7371794738a1135ee65b8d753801
minute_minute @ 4e23ca71d225f40bf9fa6ef518715806fd22f04f

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, ios.patch and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

minute can be configured to autoboot into IOS via sdmc:/minute/minute.ini. To trigger the menu manually, press (but do not hold) the power button 3-10 times (like you're trying to get into the BIOS on a computer), or until the menu shows up on the serial console. From here you can swap the SD card and make NAND backups. To back up MLC, it is currently recommended to Format redNAND with a 64GB SD card, and then copy the partitions off the SD card.

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.

Assets 3

25 Apr 02:11

shinyquagsire23

v0.2

0f424d0

de_Fuse ZIP v0.2 Pre-release

Pre-release

What's New?

Hotfix: Fixed OTP not dumping w/o otp.bin on the SD card (lol)
OTP dumping via Backup and Restore > Dump OTP via PRSHhax
SLC.RAW and SLCCMPT.RAW restoring, via Backup and Restore.
Faster/more reliable serial console input.
A serial fw.img chainloader for minute_minute dev
- Set env var MINUTE_MINUTE_FW_IMG to the absolute path to fw.img.

INSTALLATION INSTRUCTIONS

REQUIRED FILES

boot1.img: SD card image for minute_minute
fw.img: Main bootloader, minute
ios.patch: de_Fuse_iosuhax patch for 5.5.1ish, I think technically it will work on 5.5.5 though?
otp.bin: This can be dumped via the minute menu, under Backup and Restore > Dump OTP via PRSHhax. The menu will still be available if otp.bin is not present, however IOS will not be able to boot.

The following versions are provided in the zip:

pico_defuse @ 07afb41
de_Fuse_iosuhax @ 3f32c2ab234f7371794738a1135ee65b8d753801
minute_minute @ 8f38801979632f8901cae18fd0afe175eda721ed

STEPS

Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
Copy fw.img, ios.patch and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via Backup and Restore > Dump OTP via PRSHhax.
Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.

ACCESSING THE MINUTE MENU

A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg minicom -b 115200 -o -D /dev/cu.usbmodem11101).

An example of an autoboot minute.ini is as follows:

[boot]
autoboot = 1
autoboot_timeout = 3

RESTORING NAND BACKUPS

I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.

A corrupt NAND will look as follows in IOSU logs:

"Attached volume to slc01 (raw)"
"Attached volume to slccmpt01 (raw)"
A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).

TROUBLESHOOTING

You will want a serial console connected for this, see above for help.

If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.

A successful de_Fuse looks like this:

[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...

If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.

Assets 3

Releases: StroopwafelCFW/wii_u_modchip

Binary Zip v1.1

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES

STEPS

ACCESSING THE MINUTE MENU

RESTORING NAND BACKUPS

REDNAND

GPU OVERCLOCKING

TROUBLESHOOTING

Binary Zip v1.0

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES

STEPS

ACCESSING THE MINUTE MENU

RESTORING NAND BACKUPS

REDNAND

GPU OVERCLOCKING

TROUBLESHOOTING

Binary Zip v0.8

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES

STEPS

ACCESSING THE MINUTE MENU

RESTORING NAND BACKUPS

GPU OVERCLOCKING

TROUBLESHOOTING

de_Fuse ZIP v0.7.1

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES

STEPS

ACCESSING THE MINUTE MENU

RESTORING NAND BACKUPS

GPU OVERCLOCKING

TROUBLESHOOTING

de_Fuse ZIP v0.7

boot1.img in this release is bugged, use a newer release

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES

STEPS

ACCESSING THE MINUTE MENU

RESTORING NAND BACKUPS

GPU OVERCLOCKING

TROUBLESHOOTING

de_Fuse ZIP v0.5.1

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES

STEPS

ACCESSING THE MINUTE MENU

RESTORING NAND BACKUPS

GPU OVERCLOCKING

TROUBLESHOOTING

Contributors

de_Fuse ZIP v0.5

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES

STEPS

ACCESSING THE MINUTE MENU

RESTORING NAND BACKUPS

GPU OVERCLOCKING

TROUBLESHOOTING

de_Fuse ZIP v0.4

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES

STEPS

ACCESSING THE MINUTE MENU

RESTORING NAND BACKUPS

TROUBLESHOOTING

de_Fuse ZIP v0.3

What's New?

INSTALLATION INSTRUCTIONS

REQUIRED FILES