How to set up ISFShax + Stroopwafel

Special Thanks to @rw-r-r_0644 for finding and implementing ISFShax.

Warning


Although this is in use by many users and has proven itself as safe and reliable, you still use this at your own risk. Messing with the isfs superblocks is dangerous and can brick your Wii U. The superblock linked here was tested and confirmed working. Installing an broken superblock will brick your Wii U.
Also keep in mind: if you are restoring a old SLC backup, which was taken before installing ISFShax, ISFShax will be removed by restoring that backup. Newer versions of minute try to preserve ISFShax when restoring the SLC.

To protect against Nintendo pushing a boot1 update (very unlikely, but you newer know), which would brick a console with ISFShax, boot1 updates get blocked by the 5isfshax.ipx plugin. Older versions did block system updates in general. If you need to do a system update, make sure you have the latest version of said plugin.

To install Aroma DO NOT use wiiu.hacks.guide, follow the Instructions in the "Installing Aroma" section instead to install Aroma after you installed ISFShax. If you already installed Aroma using wiiu.hacks.guide, it's fine, but make sure to still follow the "Installing Aroma" section.

If you came here to change the region, make sure you are using https://gbatemp.net/threads/region-changing-the-wii-u.650802/ and NOT wiki.hacks.guide


If you run into problems with this guide, please use this Thread for help.

Update


28.02.2026 - Replace GUIFormat with Rufus because of this: https://github.com/hacks-guide/Guide-WiiU/issues/283
02.02.2025 - isfsh.ax website
26.01.2025 - Remove updatre block
20.01.2025 - Removed encrypted fw.img due to update fw_img_loader and changed file names
13.07.2024 - No longer require the wiiu/root.rpx. Replace Tiramisu with Aroma as default. Add Haxchi as Entry Exploit.
04.04.2024 - Add Fastboot
13.03.2024 - System updates now get blocked by the wafel_isfshax_patch.ipx plugin.
29.12.2023 - Standby Services are now supported. For that to work you need to have the latests ISFShax superblock installed and need to use the latest minute fw.img and wafel_core.ipx. Also autoboot needs to be enabled.


What is this for?


ISFShax exploits boot1 with specially crafted ISFS (the filesystem of the SLC) superblock. Once installed, ISFShax provides similar capabilities to defuse. Since it launches before IOSU, it can be used to apply early patches to IOSU and can be used to fix most bricks. But it won't protect you of bricks caused by: breaking boot1, seeprom bricks or installing a broken ISFShax superblock. ISFShax also doesn't help you if you already bricked the Wii U.
Use cases are:
These patches are applied using Stroopwafel CFW. Stroopwafel provides a framework for plugins to apply their own patches. ISFShax here acts as a loader for minute, which will then load IOS and apply stroopwafel and the plugins to it. This guide will also give you the base Stroopwafel, so you can add plugins like SDUSB

Wafel Installer


As a alternative to following this manual guide, you can now use the wafel installer. It guides you through the setup of ISFShax, Stroopwafel and optinally Aroma.
If your console already has problems and you need ISFShax to deal with a error, then I strongly suggest you use the manual guide below.
If you want to follow the manual setup, skip to the next section (Choosing the Exploit).

If you are already using Aroma, put the wafel_installer.wuhb into your wiiu/apps folder on the SD. You find the download here: https://github.com/zer00p/wafel_installer/releases
If you haven't modded your console yet, or lost the SD or SD content, just go to https://wafel.xyz on the Wii U web browser (Internet applet) and you can launch the wafel installer directly from that website.


Choosing the Exploit


Don't forget to download the files below, before jumping to the exploit specific instructions.

There are multiple ways to launch the ISFShax installer:
If you already have Tiramisu or Aroma installed and can launch it follow the Instructions for Aroma
If you already have Haxchi or CBHC installed follow Instructions for Haxchi
If the Browser still works and you can launch the browser exploit u.wiidb.de follow the Instructions for Browser
If you can't access the Browser, but Settings still work follow Instructions for DNSpresso
If you your Wii U crashes in the initial setup on Mii creation follow Instructions for DNSpresso
If your Wii U can't launch the browser anymore or can't connect to the internet follow the Instructions for UDPIH
If none of the other exploits work, use Paid The Beak (PTB)

Preparing the SD card



Windows hides file name extension by default. I highly recommend turning this feature off to avoid confusion (also it's a good idea in general to see what type of you are dealing with): https://www.howtogeek.com/205086/beginner-how-to-make-windows-show-file-extensions/

Make sure the SD card is formatted to FAT32 (already the case if you are using it for Homebrew).
Cards up to 32GB come already with FAT32 from the factory. If you need to reformat them, I recommend using the offical formatter: Windows / Mac or Linux
For cards above 32GB you can't use the official formatter: On Linux you can use gparted, on mac the built in DiskUtility. On Windows, you have to use a third party tool like Rufus or if you have the latest Windows 11 you can use the command prompt (launch as Admin):
Bash:
format /FS:FAT32 X: (replace X with the letter of the SD card!)

A zip archive with all the files required can be downloaded here: https://isfsh.ax/
Extract it and move everything inside the sd folder to the root of the SD card. If asked, merge folders and replace existing files.

If you are upgrading an existing ISFShax setup: make sure to clean out the ios_plugins directory, since file names did change. These files need to be deleted, if they exist: wafel_core.ipx,wafel_isfshax_patch.ipx, 0core.ipx, 6isfshax.ipx.

You can a also download all the files manually from the git repos:
Get the following files and put them in the root of the SD. Choose the release tagged with "Latest" for each. / is the path seperator wiiu/payload.elf for example means: have a folder wiiu and put the file payload.elf inside.

Instead of downloading all the files manually, you can now use the isfsh-downloader script from the attached isfshax.zip file to download all files automatically.

If you have already ISFShax files from a previous install on the SD, make sure you clean out wiiu/ios_plugins before, some file names changed and you don't want duplicates

[TABLE=full]
[TR]
[td width="16.6667%"]Method[/td][td width="16.6667%"]Name[/td][td width="16.6852%"]filename[/td][td width="16.6852%"]Path on SD[/td][td width="16.6667%"]Link[/td][td width="16.6667%"]Comment[/td]
[/TR]
[TR]
[td width="16.6667%"]All[/td][td width="16.6667%"]ISFShax installer[/td][td width="16.6852%"]ios.img[/td][td width="16.6852%"]ios.img[/td][td width="16.6667%"]https://github.com/isfshax/isfshax_installer/releases[/td][td width="16.6667%"][/td]
[/TR]
[TR]
[td width="16.6667%"]All[/td][td width="16.6667%"]ISFShax superblock[/td][td width="16.6852%"]superblock.img
superblock.img.sh[/td][td width="16.6852%"]superblock.img
superblock.img.sh[/td]
[td width="16.6667%"]https://github.com/isfshax/isfshax/releases[/td][td width="16.6667%"][/td]
[/TR]
[TR]
[td width="16.6667%"]All[/td][td width="16.6667%"]stroopwafel[/td][td width="16.6852%"]00core.ipx[/td][td width="16.6852%"]wiiu/ios_plugins/00core.ipx[/td][td width="16.6667%"]https://github.com/StroopwafelCFW/stroopwafel/releases[/td][td width="16.6667%"][/td]
[/TR]
[TR]
[td width="16.6667%"]All[/td][td width="16.6667%"]ISFShax patch[/td][td width="16.6852%"]5isfshax.ipx[/td][td width="16.6852%"]wiiu/ios_plugins/5isfshax.ipx[/td][td width="16.6667%"]https://github.com/isfshax/wafel_isfshax_patch/releases[/td][td width="16.6667%"][/td]
[/TR]
[TR]
[td width="16.6667%"]All[/td][td width="16.6667%"]minute[/td][td width="16.6852%"]fw.img[/td][td width="16.6852%"]fw.img[/td][td width="16.6667%"]https://github.com/StroopwafelCFW/minute_minute/releases[/td][td width="16.6667%"][/td]
[/TR]
[TR]
[td width="16.6667%"]Browser DNSpresso Aroma[/td]
[td width="16.6667%"]fw.img loader[/td][td width="16.6852%"]payload.elf[/td][td width="16.6852%"]wiiu/payloads/fw_img_loader/payload.elf[/td][td width="16.6667%"]https://github.com/wiiu-env/fw_img_payload/releases[/td][td width="16.6667%"]extract zip[/td]
[/TR]
[TR]
[td width="16.6667%"]Browser DNSpresso
Aroma
[/td]
[td width="16.6667%"]PayloadLoaderPayload[/td][td width="16.6852%"]payload.elf[/td][td width="16.6852%"]wiiu/payload.elf[/td][td width="16.6667%"]https://github.com/jan-hofmeier/PayloadLoaderPayload/releases[/td][td width="16.6667%"][/td]
[/TR]
[TR]
[td width="16.6667%"]DNSpresso[/td][td width="16.6667%"]PayloadFromRPX[/td][td width="16.6852%"]root.rpx[/td][td width="16.6852%"]launch.rpx[/td][td width="16.6667%"]https://github.com/wiiu-env/PayloadFromRPX/releases[/td][td width="16.6667%"]extract zip[/td]
[/TR]
[TR]
[td width="16.6667%"]UDPIH[/td][td width="16.6667%"]minute boot1[/td][td width="16.6852%"]boot1.img[/td][td width="16.6852%"]boot1now.img[/td][td width="16.6667%"]https://github.com/jan-hofmeier/minute_minute/releases[/td][td width="16.6667%"][/td]
[/TR]
[TR]
[td width="16.6667%"]UDPIH[/td][td width="16.6667%"]recovery menu[/td][td width="16.6852%"]recovery_menu[/td][td width="16.6852%"]recovery_menu[/td][td width="16.6667%"]https://github.com/GaryOderNichts/recovery_menu/releases[/td][td width="16.6667%"][/td]
[/TR]
[TR]
[td width="16.6667%"]Haxch[/td][td width="16.6667%"]fw.img loader[/td][td width="16.6852%"]wiiu/apps/fw_img_loader/*[/td][td width="16.6852%"]wiiu/apps/fw_img_loader[/td][td width="16.6667%"]https://github.com/jan-hofmeier/unencrypted_fw_img_payload/releases[/td][td width="16.6667%"]extract fw_img_loader_hbl.zip and keeps structure[/td]
[/TR]
[/TABLE]

The structure on the SD should look like this:
Code:
boot1now.img (UDPIH Only)
recovery_menu  (UDPIH Only)
launch.rpx (DNSpresso Only)
fw.img
ios.img
superblock.img
superblock.img.sha
wiiu
    payload.elf (Browser, DNSpresso, and Aroma Only)
    payloads (Browser, DNSpresso, and Aroma Only)
        fw_img_loader
            payload.elf
    ios_plugins
         00core.ipx
         5isfshax.ipx
    apps
        fw_img_loader (Haxchi Only)
            fw_img_loader.elf
            icon.png
            meta.xml

Launching into minute


This step heavily depends on the used Exploit.

  1. Hold B on the Gamepad while booting (if coldboot is enabled) or launching the H&S app
  2. A black and white menu should show up asking you to choose a payload.
  3. Select fw_img_loader

  1. Load the Homebrew Launcher
  2. Start the fw.img loader app

  1. Open the Browser and browse to u.wiidb.de
  2. Click on "HAXX"
  3. Immediately hold B until you see the payload menu
  4. select the fw_img_loader

If you can a access the settings:
  1. just follow these instructions to trigger the exploit (you already have the right files on the SD): https://gbatemp.net/threads/dnspresso-a-wii-u-dns-exploit.642123/
  2. Immediately hold B after starting the test until you see the payload menu
  3. select the fw_img_loader

If you are stuck on the Mii creation in the Inital setup:
  1. If you already connected your Wii U to your AP / Router, turn the AP / Router or the Wifi on it off.
  2. When the setup asks you if you already have a NNID, say yes (even if you don't have one)
  3. Now it tries to connect to the Internet, but will fail and ask you to take you back to the Wifi settings, follow back to thge settings.
  4. Turn your Router / AP on again and give it time to start.
  5. If you don't already have your Wifi configured there, connect to it now, but enter a wrong password.
  6. Edit your wifi connection and configure 85.215.57.182 as Primary DNS, if you entered a wrong password before set the right one now.
  7. Press (B) Back and select Connection Test.
  8. Immediately hold B after starting the test until you see the payload menu
  9. select the fw_img_loader

  1. Load the recovery using UDPIH: https://gbatemp.net/threads/udpih-usb-host-stack-exploit-recovery-menu.613369/ (don't replace the recovery_menu)
  2. The LED should turn purple and a countdown timer for loading boot1now.img should appear, wait the 5 seconds
  3. Unplug the Pico
Note: If the LED turned purple, the UDPIH exploit worked, even if you don't see anything on the screen


Now you should see the minute main menu. If not, something went wrong. Make sure you have the correct fw.img file on the SD.
In minute you move the cursor with the power button and enter with the eject button (swapped compared to the recovery menu).

ISFShax isn't installed yet! minute is just loaded temporarily and gone after a reboot.

Note: minute only outputs 1080p through HDMI, no picture on the gamepad, and nothing on the analog outputs.
Some people reported that the screen output is not working for them when minute was loaded from the recovery_menu. If you made sure nothing else is the problem (right fw.img, TV supports 1080p HDMI), you can try following along blindly by pressing the appropriate buttons. Make sure to wait long enough between the presses, so the system has time to load. Without display output skip the first backup and go directly to Installing ISFShax.
minute.png

minute main menu​

Backup



If you already have an SLC backup or it is inconvenient for you to do one (no screen output), then you can skip this.
  1. Navigate to Backup and Restore
  2. Dump SEEPROM & OTP(This will be needed for redNAND / region changing)
  3. Dump SLC.RAW
  4. Return to Main Menu
Note: some correctable ECC errors are expected, so no need to worry if you see a few.

Installing ISFShax


  1. Choose Boot `ios.img` (6x Power, 1x Eject)
  2. Now the ISFShax installer should launch (this takes a few seconds)
  3. Follow the Instructions on the screen, the buttons are the same as in minute. (3x Eject, 1x Power, 3x Eject)
  4. The console should now turn off.
  5. If the install was successful the Wii U should directly start into minute and the power LED on the console will be purple, once you turn it on.
isfshaxsuccess.png

successful isfshax install​

Backup ISFShax (Optional)


Dump the SLC.RAW again. This will overwrite the previous SLC.RAW file on the SD. This is required if you need to restore the SLC for unbricking, without loosing ISFShax. Keep that backup in a safe place.
If you skipped the first Backup also backup OTP and SEEPROM now.

Booting


If you came here from the redNAND, the MLC rebuild or the Region Change guide continue with that tutorial now.

For now your Wii U loads minute (fw.img), which then applies the required patches from SD card. (IOSU needs to be patched, so it doesn't fall over the ISFShax superblock).
To boot into the Wii U OS select Patch (sd) and boot IOS (slc) <-- This is the third option, not the first!

If your console just bootloops through minute over and over again, you are probably coldbooting Aroma and replaced the wiiu/payload.elf with the fw_img loader. Just replace the wiiu/payload.elf again with the Aroma one (applies to Tiramisu too).

To make the Wii U booting automatically, without you having to press any buttons in the minute menu, you have to complete the "Autobooting with SD" section further down.

Autobooting with SD


To make the Wii U autoboot with an SD card inserted you need to create the filesd:/minute/minute.ini (you might need to create the minute folder) with the following content:
Code:
[boot]
autoboot=3
autoboot_timeout=0
The attached isfshax.zip file contains a few example minute.ini files for autobooting slc, sd or rednand. You can copy and rename the appropriate one. The files in the zip already have the .ini file name extension. if you don't see it, then DO NOT add it, as Windows is hiding it.

You can adjust the timeout (in seconds) to your liking. The autoboot option specifies which entry from the minute menu will be loaded. 1 corresponds to Patch (slc) and boot IOS (slc), which loads the ios_plugins from the SLC (see below for how to setup the files on SLC). If you haven't installed them to the SLC or want to load them from the sd for another reason you can change that value to 3 which corresponds to Patch (sd) and boot IOS (slc)

As an Alternative check out the Fastboot option below.

Installing Aroma / Tiramisu


  1. To install Aroma or Tiramisu put the corresponding files on the SD.
    Tiramisu: https://tiramisu.foryour.cafe/
    Aroma: https://aroma.foryour.cafe/ (You don't need to have install Tiramisu to have Aroma, also the FTPiiU plugin will become handy later)
  2. Put the 5payldr.ipx in the ios_plugins folder https://github.com/jan-hofmeier/wafel_payloader/releases (if you used the downloader, the plugin is already installed)
Note: if the Aroma Updater wants to update the payload.elf, it is safe to do so.

Optional: Installing Plugins to SLC (instead of SD)


Now the Wii U will boot like normal without the SD. To achieve that ISFShax applies a minimal set of patches to the system (to tolerate the ISFShax superblock). Since these patches kept minimal, they are not optimized and some things like leaving the settings will take longer.
To make the full minute+stroopwafel run from the internal memory we can install minute fw.img and the ios_plugins to the SLC. This can be accomplished using FTPiiU Everywhere / the Aroma ftp plugin, which can be launched from Tiramisu and is already part of the Aroma Package (enable Everywhere in the settings) or you can use the haxcopy homebrew. Using haxcopy is recommended for most users.

If you are using haxcopy to update an existing install, make sure that the plugins have the same file name as before, else you might get duplicates, which can cause problems

If you are redNAND user, remove the hax folder and creare a new one and copy the fw.img from the root of the SD into there, before running haxcopy. The hax folder form the download contains the fastboot fw.img, which doesn't work with redNAND. By installing the normal minute and not having the ios_plugins folder on the menu, the Wii U will display the minute menu.

If you downloaded the files from isfsh.ax or used the download script, all the files where already put in the hax folder, so you can skip 1-5. Note that the download uses the fastboot minute (explained below).
  1. create a folder hax on the SD card (this will be copied to the slc)
  2. copy the fw.img to the hax folder
  3. create a subfolder ios_plugins in the hax folder
  4. copy 00core.ipx it to the hax/ios_plugins folder
  5. copy 5isfshax.ipx to the hax/ios_plugins folder
  6. if you want to coldboot aroma or tiramisu, copy the 5payldr.ipx to hax/ios_plugins folder
  7. If you need any other plugins like the wafel_unlimit.ipx, you have to rename and copy it to the hax/ios_plugins folder
  8. Copy the haxcopy app to the wiiu/apps folder (like you usually install homebrew)
  9. Put the SD in the Wii U and run haxcopy to copy the hax folder to the slc.
On Aroma you have to make sure access to system files is enabled:
  1. Open the Aroma Plugin Configuration Menu using L + Down + SELECT (-) on the GamePad or Pro Controller (or B + Down + Minus (-) for WiiMotes)
  2. Open the FTPiiU option, then settings and set ‘Allow access to system files’ to ‘true’ by pressing A

Uploading the files:

If you are redNAND user only upload the fw.img and skip the ios_plugins. Also make sure to use the full minute and not the fastboot minute.
  1. (Tiramisu only) Make sure FTPiiU Everywhere is running on the Wii U
  2. Using a FTP client on the PC browse to /storage_slc/
  3. If you see a scfm.img file and sys folder go into the sys folder. If you see a bunch of folders (config import logs proc rights security title tmp) just go to the next step.
  4. create a subfolder hax and enter it
  5. Make sure your FTP client is in binary mode (not ASCII mode)
  6. upload the minute fw.img to the /storage_slc/sys/hax folder
  7. create another subfolder ios_plugins in /storage_slc/sys/hax
  8. enter that /storage_slc/sys/hax/ios_plugins folder
  9. upload 00core.ipx
  10. upload 5isfshax.ipx
  11. upload 5payldr.ipx
  12. If you need other plugins like the wafel_unlimit.ipx, you have to rename and upload them too
Now the Wii U should autoboot with the installed plugins if no SD card is inserted.
If a SD card with a fw.img is inserted, that will be loaded instead of the installed. So if you want to make sure the fw.img from the slc is used, rename or remove the fw.img from SD. You can also boot the plugins from SLC by booting the first option Patch (slc) and boot IOS (slc) from the minute menu.

Since ISFShax v5.0 the Wii U will first try to load the fw.img from the SD and if that fails it will try to load it from SLC.
Previous versions of ISFShax will first try to load the fw.img from the SLC and if that fails it falls back to the SD.
If you installed a broken fw.img which doesn't load, you can force isfshax to load the fw.img from sd by repeatedly pressing the power button till the menu shows up.

Warning: A factory reset will delete the hax folder. Without the fw.img on the SD the Wii U will then just have a black screen with a orange LED with the latest ISFShax it will apply minimal patches to boot and it will still block updates, but some things like leaving the settings might me slower. It's recommended to setup minute and stroopwafel again.

Optional: Fastbooting (Advanced)


To make the Wii U boot as fast as possible, without showing minute, you can now use the fw_fastboot.img. This won't work with redNAND.
It is hardcoded to go straight to the first option (booting the slc, with patches from SLC) when loaded from slc or the third option when loaded from SD. It won't display anything and ignore any autoboot configuration in the minute.ini.
If you used haxcopy with the hax folder from the isfsh.ax download or the download script, then the fastboot minute is already installed.

To install it manually replace the the fw.img in the hax folder on the SLC with the fw_fastboot.img (renamed to fw.img)

In case you ever get stuck and need to load the full minute from SD you can do this:
  1. Place the minute fw.img on the SD card
  2. repeatedly press the power button until the minute menu shows up on the screen. (Since ISFShax v5.0 you don't have to do this, since it will try the SD first by default)

Updating ISFShax


To update ISFShax replace the files on the SD card. While doing this make sure to clean out the wiiu/ios_plugins and hax/ios_plugins directory, since file names did change. These files need to be deleted, if they exist: wafel_core.ipx,wafel_isfshax_patch.ipx, 0core.ipx.

To update the installed ISFShax superblock, you need to go trough the installer again (Boot ios.img) but generally you don't need to, if everything works. DON'T uninstall it, just install the new superblock, it will overwrite the old one.

If you installed files to the SLC, you can use haxcopy to update those. All plugins (like SDSUSB) that are not in the hax/ios_plugins folder will be removed in the process, so make sure you have them there, if you use them.
If you are redNAND user, remove the hax folder and creare a new one and copy the fw.img from the root of the SD into there, before running haxcopy. The hax folder form the download contains the fastboot fw.img, which doesn't work with redNAND. By installing the normal minute and not having the ios_plugins folder on the menu, the Wii U will display the minute menu.


Installing System Updates


To protect against Nintendo pushing a boot1 update (very unlikely, but you newer know), which would brick a console with ISFShax, boot1 updates get blocked by the 5isfshax.ipx plugin. Older versions of the plugin did block system updates in general. If you need to do a system update, make sure you have the latest version of said plugin.

To install a system update (e.g. for vWii Decaffinator), make sure you have the latest version of the plugin (and stroopwafel). To do this just replace the 5isfshax.ipxin the wiiu/ios_plugins folder with the lastes one.
If you have Aroma or Tiramisu, you also need to remove the 5payldr.ipx to prevent Aroma from loading, since Aroma also comes with it's own update block.

Which files can be removed?


If you installed the the files to the SLC, then you don't need to keep any files on the SD, but I would still recommend keeping the hax folder to make future updates easier (so you have all the plugins you installed).
For SD booting / redNAND you just need to keep the fw.img, the wiiu/ios_plugins and your config int the minute folder.
Also if you are using Aroma, you want to keep the wiiu/payload.elf (and the other Aroma files) of course.
The otp.bin / seeprom.bin and SLC.RAW should be copied to a safe place and can also be removed from the SD.
The ios.img would only be needed for uninstalling ISFShax, so if you don't plan on doing that, you can remove it too.

But there is no harm in just leaving all the files on the SD.

Uninstalling ISFShax


DON'T just restore an older SLC backup, as that would break SCFM!
You DON'T need to uninstall ISFShax to update it. Also uninstalling and reinstalling it won't fix anything. Just installing the new superblock over the old replaces it completely.

  • Make sure your Wii U doesn't depend on any patches (linke wafel_unlimit_mlc.ipx or redNAND). You can check that by booting the Patch ISFShax and boot IOS (slc) option in minute and check if it boots fully and works correctly.
  • Delete the /storage_slc/sys/hax folder if you set up the slc booting
  • run the ISFShax installer again from minute and follow the on-screen instructions to uninstall.

Plugins


Here is a list of currently available stroopwafel plugins, you can use with ISFShax:
If you have more plugins, tell me and I can add them to the list

Description of the Files


In case you are interrested in how all the files work together and which you need to keep, you can keep reading on:

superblock.img
This contains the actual ISFShax. It is a specially crafted superblock for the SLC File System (ISFShax) to exploit a vulnerability in boot1 and give us arbiary code excution. It also contains a mini version of minute, which will be executed to load the full minute (fw.img) from SD or SLC.

superblock.img.sha
This is the checksum for the superblock, to make sure it didn't corrupt along the way, as a bad superblock would lead to a brick.

fw.img
this contains the full minute, which gives you the menu after turning on. It can be used for creating and restoring backups and similar tasks and it acts as a bootloader stroopwafel. When selecting one of the First 3 Boot options, it will load IOSU (the OS/Firmware that runs on the ARM processor) and also loads the plugins from the ios_plugins folder. It will then patch IOSU to first execute the first plugin, which should be stroopwafel, before launching IOSU. At that point you see the GO GO GO message, as IOSU takes over.

00core.ipx
This is stroopwafel. It contains a patches for handeling IOSU reloads (so these go through minute, to apply the patches again), redNAND and to facilliate a framwork for other plugins to apply patches and also exports functions to be used by plugins.

5isfshax.ipx
This plugin patches IOSU to ignore the ISFShax superblock and use the normal superblocks instead. (A superblock contains the file system meta data, like folder structure and used blocks. The SLC has 64 superblocks (to spread the wear), which are written in round robbin, whenever something is change don the slc. ISFShax is installed to 4 superblocks for reduandency)

5payloader.ipx
This redirects the men.rpx (the Wii U Menu) to the root.rpx of aroma, so Aroma gets loaded on boot. If the root.rpx is missing it will load the menu normally.

ios.img
This is the ISFShax installer. It installs the superblock.img to 4 of the superblocks, and marks these superblocks as bad in the normal superblock, so they won't be overwritten.

wiiu/payload.elf
This file gets loaded by most exploits (Like the Browser exploit or the Aroma Payloadloader). In this case it contains the menu, that comes up by holding b and letting you select another payload. By default it would load the Environmentloader for Aroma, if installed.

wiiu/payloads/fw_img_loader/payload.elf
This patches IOSU to load the fw.img from SD and then tells it to reload. This is used to initially load minute, before ISFShax is installed.

wiiu/apps/fw_img_loader/fw_img_loader.elf
This is the a version of the fw_img_loader that can be loaded as an app from the Homebrew Launcher. (Haxchi)

launch.rpx
This is loaded by DNSpresso and loads the wiiu/payload.elf

recovery_menu
The recovery menu is loaded by UDPIH. It has some options to fix certain problems, but we are just using it to load minute. If the recovery_menu sees the boot1now.img, It will skipp the menu and after a countdown use PRSHhax to reset the Wii U into boot1now.img

boot1now.img
SInce PRSHhax exploits boot1 early, many hardware initilizations still needed to be done. This is done by boot1now, which is a mini version of minute, similar to the one embedded in the ISFShax superblock. It will then load the fw.img from the sd.

ISFShax.drawio.png


This means after ISFShax is setup, you only need to keep the fw.img, wiiu/ios_plugins and your config in the minute folder. If you are fastbooting from the SLC, then you don't need anything on the SD.

Credits


  • @rw-r-r_0644 for finding and implementing isfshax
  • @GaryOderNichts for their direct contributions, help and two of the exploits (UDPIH and DNSpresso)
  • @vgmoose for all the support and for the Wii U that replaced the one Idestroyed during early isfshax testing
  • @Maschell for his help and all other contributions to the Wii U scene
  • hexkyz for the warmboot boot1 exploit which made all of this possible
  • @shinyquagsire23 for de_Fuse, minute and stroopwafel
  • Salt Team for the original minute CFW
  • dimok789, FIX94 and others for the iosuhax CFW
  • fail0verflow for mini
  • @skawo screenshots
  • and all other contributors to the Wii U scene!
[/SPOILER][/SPOILER]
 

Attachments

Last edited by SDIO,
I did some more investigations, because it didn't make sense. And I was wrong on the boot1 not turning on the ODD. Boot1 turns on the ODD power just before it launches the IOS. If you listen closely you can even hear one short movement of the drive, which gets interrupted, before it does the full one. On stock the time between boot1 turning on the power and IOS initializing SATA was just much shorter then with stroopwafel. The delay caused by stroopwafel made it more noticable, since it gave the drive the time to finish the first movement.

What I did now was adjust isfshax, minute and stroopwafel, to match the stock boot1 behavior more closely:

The ISFShax superblock will turn on the drive power, if it launches IOS directly in fallback mode. If it launches minute, it keeps the power off.

Minute will then turn on the power at the last possible moment if the SATA type is not set to none and if the drive power wasn't disabled in the minute.ini. For HDDs minute will turn the power on as early as possible, to give them more time to spin up.

The delay on stroopwafel was caused by serial logging. Stroopwafel will now don't output anything on the debug interface. Also debug_printf from plugins is disabled. Adding the debug plugin will enable all the logging and debug_printf again. Stroopwafel will still take a little longer than stock but it's now much closer.

I attached all the files for testing. @buddy @derivativeoflog7 I would expect it to work work for you with the default config. And once you set the odd_power=false in the minute.ini I would expect the problem to come back. But it's also possible that it will work for you since the timings now changed. In case you get the problem again, you can try to add the 3deoddpo.ipx to the ios_plugins. This adds the delay back, that helped you already. But it might not since the timings are now all different.

In general I recommend trying with odd_power=false and only if that causes problems to try the problem. What you should not do is odd_power=true(which is the default if not set or using the fastboot) and having the 3deoddpo.ipx plugin at the same time, as this will give you the worst of both worlds (the drive will make more sounds)
 

Attachments

  • Love
Reactions: DolphinPussy
I attached all the files for testing. @buddy @derivativeoflog7 I would expect it to work work for you with the default config. And once you set the odd_power=false in the minute.ini I would expect the problem to come back. But it's also possible that it will work for you since the timings now changed. In case you get the problem again, you can try to add the 3deoddpo.ipx to the ios_plugins. This adds the delay back, that helped you already. But it might not since the timings are now all different.

In general I recommend trying with odd_power=false and only if that causes problems to try the problem. What you should not do is odd_power=true(which is the default if not set or using the fastboot) and having the 3deoddpo.ipx plugin at the same time, as this will give you the worst of both worlds (the drive will make more sounds)
On first review, the 5.3 test files and default settings seem to have worked for the usual overnight test.

Going to give the odd_power=false option a try and see how that behaves.
 
On first review, the 5.3 test files and default settings seem to have worked for the usual overnight test.

Going to give the odd_power=false option a try and see how that behaves.
So i've been powered down for 8 hours now with the odd_power=false set and just powered on, and started right up. Looking promising, but I'll have another go tomorrow morning again and see if the same holds true then.

And just for audio confirmation it's loading the right way:

odd_power=true = 1.25 (approx) drive startup sounds
odd_power=false = 1 drive startup sound
 
  • Like
Reactions: DolphinPussy
In general I recommend trying with odd_power=false and only if that causes problems to try the problem. What you should not do is odd_power=true(which is the default if not set or using the fastboot) and having the 3deoddpo.ipx plugin at the same time, as this will give you the worst of both worlds (the drive will make more sounds)
w/ usbmlc ok?
[boot]
autoboot=3
autoboot_timeout=1

[sata]
odd_power=false

[storage]
usb_mlc_delay=2000
sata_init_delay=500

[debug]
disable_serial=false

Btw if isfshax is the name of isfahan (iran) that is awesome
 
Last edited by DolphinPussy,
So i've been powered down for 8 hours now with the odd_power=false set and just powered on, and started right up. Looking promising, but I'll have another go tomorrow morning again and see if the same holds true then.
Update: The odd_power=false alone did not end up working, froze up again on boot this morning.

I've added the 3deoddpo.ipx to the plugins directory, and will test with that in place.
Post automatically merged:

12 hours later, with odd_power=false, and the 3deoddpo.ipx in the ios_plugins folder, it still froze up upon boot.

So with the 5.3 test ver so far, looks like only the odd_power=true in the minute.ini appears to be working for me.
 
Last edited by buddy,
  • Like
Reactions: DolphinPussy
I made a version with a 5 and one witrh a 10 second delay. Maybe one of them helps. You should also be able combine them by adding them multiple times under different names and the delay should just add up.

But I am afraid, you have to live with the odd_power=true, if you want a reliable setup.
 

Attachments

I made a version with a 5 and one witrh a 10 second delay. Maybe one of them helps. You should also be able combine them by adding them multiple times under different names and the delay should just add up.

But I am afraid, you have to live with the odd_power=true, if you want a reliable setup.
Ok thanks, I'll mess around with those also and see what I can find.

What was the delay set to with the initial 3deoddpo.ipx?

I don't mind the odd_power=true if it works reliably. I never minded the double disc noise up through 5.0 either.

The changes you made to the test 00core.ipx seemed to work OK when testing that, was there a reason you didn't want to continue going that route?
 
  • Like
Reactions: derivativeoflog7
The initial one had 1 second
Post automatically merged:

The changes you made to the test 00core.ipx seemed to work OK when testing that, was there a reason you didn't want to continue going that route?
The problem is, it's not reliable in general. The plugin is just that one patch extracted. But since the timing changed in the new stroopwafel, it stopped working again.
What I have now is closer to stock by default, so that seems like the safer approach. There are a few different Drives out there and board revisions and even the WUP-01 boards are not all populated the same.

People who are annoyed by the double initialization, now can try to disable it.
And by default people have the most reliable setup with the first noise cut as short as possible.
The plugin now was just a try to get rid of the first initialization entirely for consoles which are unstable with the power turned off in minute.

I think that's a good compromise.

Another option would be to just pulse on the power in minute, so the drive doesn't have a chance to make a noise, but the caps get charged. But not sure if that actually works and not sure if that might be bad for the drive.
 
Last edited by SDIO,
  • Like
Reactions: DolphinPussy
Had a totally different reply in the works, but just started up again and this is really odd...a few hours back after the last lockup attempt, I reverted back to the odd_power=true in the minute.ini, and I had removed the 3deoddpo.ipx from the ios_plugins directory to get back to the 'default' 5.3 config. Shut down, started up, got the mini drive noise, followed by the full one and booted fine. Just tried powering on now, and seemed to take longer, I believe I heard two full drive startup sounds, and the WiiU froze up again. Force shut down, powered back on and got the mini drive sound, followed by the full one, and started up OK. I'll shut down and leave it again for the night and do some more tests in the AM. Re-cheked the minute.ini and true option was in there correctly, and the 3deoddpo.ipx was definitely removed from ios_plugins. The only other file I added in addition to the 5.3 test files was the (though I did that yesterday) was the 5sdusb.ipx file. Will check tomorrow.
Post automatically merged:

Ok not sure what that was last night. This morning it started up fine. I'll just leave things as they are for now, and see how it goes from here. I appreciate your time looking into this for so long, and all the test builds provided even though I and @derivativeoflog7 seem to be in the minority on this issue.
 
Last edited by buddy,
I don't mind the odd_power=true if it works reliably. I never minded the double disc noise up through 5.0 either.
Same, having to get back up after realizing the console froze is much more annoying than hearing a noise twice or a small added delay to make booting reliable (Aroma adds a bigger delay anyway).
 
Same, having to get back up after realizing the console froze is much more annoying than hearing a noise twice or a small added delay to make booting reliable (Aroma adds a bigger delay anyway).
i'll just speak for myself, but i didn't particularly 'mind' it initializing twice, i just wanted to know if it was, in fact, working as intended.. or if something had gone wrong on my end, i thought maybe i configured auto-booting incorrectly (between aroma & isfshax there's a lot going on there now).

but if that's the way it's gotta be, no problem. if it's not necessary and/or intentional and can be tweaked in an update, even better and i appreciate SDIO's efforts even if it was only a minor annoyance. i wont pretend to have been keeping up with the thread, but it sounds like you couple guys are having a mysterious hardware related issue more than anything, and the consoles were crashing after a long rest even with the double drive sound. super weird. mine is a launch day north american black model with lots of miles on it haha.. so i'm glad it's still kicking, and the less my drive moves these days the better!
 
I did some more investigations, because it didn't make sense. And I was wrong on the boot1 not turning on the ODD. Boot1 turns on the ODD power just before it launches the IOS. If you listen closely you can even hear one short movement of the drive, which gets interrupted, before it does the full one. On stock the time between boot1 turning on the power and IOS initializing SATA was just much shorter then with stroopwafel. The delay caused by stroopwafel made it more noticable, since it gave the drive the time to finish the first movement.

What I did now was adjust isfshax, minute and stroopwafel, to match the stock boot1 behavior more closely:

The ISFShax superblock will turn on the drive power, if it launches IOS directly in fallback mode. If it launches minute, it keeps the power off.

Minute will then turn on the power at the last possible moment if the SATA type is not set to none and if the drive power wasn't disabled in the minute.ini. For HDDs minute will turn the power on as early as possible, to give them more time to spin up.

The delay on stroopwafel was caused by serial logging. Stroopwafel will now don't output anything on the debug interface. Also debug_printf from plugins is disabled. Adding the debug plugin will enable all the logging and debug_printf again. Stroopwafel will still take a little longer than stock but it's now much closer.

I attached all the files for testing. @buddy @derivativeoflog7 I would expect it to work work for you with the default config. And once you set the odd_power=false in the minute.ini I would expect the problem to come back. But it's also possible that it will work for you since the timings now changed. In case you get the problem again, you can try to add the 3deoddpo.ipx to the ios_plugins. This adds the delay back, that helped you already. But it might not since the timings are now all different.

In general I recommend trying with odd_power=false and only if that causes problems to try the problem. What you should not do is odd_power=true(which is the default if not set or using the fastboot) and having the 3deoddpo.ipx plugin at the same time, as this will give you the worst of both worlds (the drive will make more sounds)
Does odd_power also work on the fastboot build, or is that just hardcoded to ignore any and all configs?
 
No, fastboot ignores the minute.ini
It won't use false if set, but it does respect true as that's the default now with 5.3, correct? Actually just tested with fastboot and looks (sounds) like it does.

Again, thanks for taking the time to look into this. Right now with the 5.3 version(s) things haven't failed yet.
 
It just doesn't read the minute.ini at all and just uses the default which is true for odd_power.

Once I have confirmation from @derivativeoflog7 that it works, then I will set it as the latest release (instead of pre release)
 
  • Like
Reactions: buddy
It just doesn't read the minute.ini at all and just uses the default which is true for odd_power.

Once I have confirmation from @derivativeoflog7 that it works, then I will set it as the latest release (instead of pre release)
This morning I installed the last fastboot build you posted, but after half a day it crashed
Tho maybe I did something wrong, I'll reinstall everything and try again
 
This morning I installed the last fastboot build you posted, but after half a day it crashed
Tho maybe I did something wrong, I'll reinstall everything and try again
Actually, you might be right, don't think it's you. When I was testing things out the other night, after having been fine after a previous successful overnight startup, I did run into one time in the evening (non-fastboot) where i thought I didn't her the short initial drive noise, and just hear the usual drive startup sounds (thought it was the double) and the console failed to boot. It was kind of late here, thought I was tired and maybe I wasn't sure. Powered it off for the night, was fine again in the AM.

However, just happened again now Things were working fine this morning and earlier this afternoon even, all times had that initial short drive sound before the full one. Console had been off now, not long, maybe between 2-5 hours, just fired it up, and again didn't seem to hear that initial quick drive initialization and it hung again, so it seems it's still happening, but much less frequent, not as predictable to reproduce as was originally for me apparently.
 
Can you try pairing it with the previous stroopwafel release?

Also what do you see on the screen when it happens?
 
Last edited by SDIO,

Site & Scene News

Popular threads in this forum