Add option to disable HDD power saving

[jmbass]

Problem

Some USB hard disks enter aggressive power-saving states while a game is
idle. Their multi-second wake latency can exceed the Wii USB stack timeout
and leave a game frozen or on a black screen at its next load transition.

A similar failure was reported by another user with a Maxone 2.5-inch Wii
drive: Game freezes at transition help.

Change

Add an opt-in Disable HDD Power Saving option under Global Settings →
Hard Drive Settings. On the next launch, while the mounted USB disk is still
available through IOS58, the loader:

1. Sends the non-mutating ATA CHECK POWER MODE command to test SAT
   pass-through support.
2. Independently attempts to disable ATA Advanced Power Management.
3. Independently attempts to disable the ATA standby timer.
4. Reports full, partial, unsupported, or transport-failure results before
   continuing normal startup and reloading into cIOS.

The setting defaults to OFF. It targets only the disk already selected and
mounted by USB Loader GX. It does not write sectors, partitions, bridge
EEPROM, or firmware. The ATA settings are volatile and reset when the HDD
loses power.

Disabling power saving may keep a mechanical disk spinning continuously,
increasing power consumption, temperature, noise, and accumulated running
time. The option should therefore be enabled only when needed.

Implementation notes

• The setting uses the existing default/load/save and Hard Drive Settings
  menu patterns.
• It is applied after the configuration is loaded but before the loader
  reloads into cIOS. At that point the selected disk is still mounted through
  the IOS58/libogc backend, which exposes the raw SCSI command path needed for
  SAT. This is why enabling the option takes effect on the next launch.
• The commands use the existing mounted device handle and LUN. There is no
  VID/PID allowlist, so the implementation is not tied to the tested Maxone
  enclosure, and the helper does not enumerate or open another USB device.
• ATA pass-through requires a 16-byte SCSI CDB. __send_cbw() previously
  advertised every CDB longer than six bytes as ten bytes; it now preserves
  the supplied length. Existing six- and ten-byte commands retain their
  previous advertised lengths.

Tested hardware

• Nintendo Wii
• USB Loader GX r1283
• Maxone USB 3.0 1 TB enclosure
• JMicron JMS578 USB-to-SATA bridge (152d:0578, firmware 0215)
• HGST HTS541010A9E680 1 TB 5400 RPM HDD, firmware JA0OA560
• FAT32 Wii game partition

The tested HDD restores ATA APM level 1 after power loss. Before disabling
power saving, an uncached read after 45 seconds idle took approximately 2.25
seconds. The same Windows test took approximately 0.06 seconds after disabling
APM and the ATA standby timer.

After a full Wii and HDD cold boot, the integrated setting successfully
prevented the previously reproducible idle/load freezes in:

• The Legend of Zelda: Twilight Princess
• Guitar Hero III

Hardware coverage is currently limited to the bridge and HDD listed above;
other SAT bridge and drive combinations have not been physically tested.

Verification checklist

• Clean build with the repository's pinned devkitPPC container
• Setting defaults to OFF and persists through the existing configuration
  file
• The enablement Notice explains the next-launch behavior and warns about
  increased power use, temperature, noise, and running time
• Full Wii and HDD cold boot without first running the standalone utility
• Previously reproducible idle/load transitions tested in two games

Screenshots

Setting	Enablement notice

Build verification

Built successfully using the same toolchain and command as the repository
workflow:

docker run --rm \
  -v "$PWD:/project" -w /project \
  devkitpro/devkitppc:20250527 \
  sh -lc 'make clean && make release -j2'

[wiidev]

Could you run FwUpdateTool to create a backup of your firmware and then upload it? You should just need to click on RD Version, then Backup Old Firmware Only, and then click on Run.

If the firmware is similar enough to my own, I should be able to try it on my enclosure. If I can then replicate the issue, I might know of a more universal fix that would work for a wider range of devices, including ones that don't allow APM to be disabled or have their APM setting reset by their firmware after 5 to 10 minutes.

[jmbass]

Hello @wiidev ! Thanks for reviewing.

Yes, I have a pristine firmware backup made with RD Version and Backup Old Firmware Only. I made two reads before modifying anything and verified that their SHA-256 hashes matched.

One clarification that may help your investigation: on this enclosure I tested the bridge standby setting separately from the drive’s ATA power management.

Setting the JMS578 standby timer to zero produced a verified NVRAM change at offset 0xC4F2 (0x28 → 0x20), but the approximately 2.7-second wake delay after roughly 45 seconds idle remained.

The internal drive is an HGST HTS541010A9E680. After a full power cycle it reported ATA APM level 1. Disabling ATA APM and the ATA standby timer reduced a comparable Windows raw-read test from approximately 2.25 seconds to 0.06 seconds. After power loss, APM returned to level 1 and the delay returned. The USB Loader GX change fixes this unit by reapplying those volatile ATA commands during startup.

So the reproduced issue on this particular enclosure appears to be drive-side APM rather than the JMS578’s own standby timer. I agree that comparing the bridge firmware could still be useful for a more universal solution, especially for drives or bridges that reject APM changes or restore them after several minutes.

The backup is 50,688 bytes and contains the Maxone USB identity strings and unique enclosure serial number.
I will provide the pristine original.bin, rather than one of the intermediate modified readbacks.

original.bin.zip

[wiidev]

I tried to replicate the issue by flashing the firmware onto my enclosure, which changed it from 00.05.00.08 to 00.02.01.05. However, I didn't encounter any freezes during loading, transition sections, or even when standing around doing nothing in any of the games.

The USB Loader GX change fixes this unit by reapplying those volatile ATA commands during startup.

The problem I have with this approach is that I already know it won't help every drive, since some don't allow APM to be disabled, while others will reset the setting after a few minutes. Plus, it then becomes another debugging step that forums and Discord servers need to parrot to users.

Historically, some of the JMS578 firmware versions have been really buggy, which is why threads like this one on GBAtemp exist.

The d2x cIOS already reads a random sector every 10 seconds to keep drives awake. Could it be that your enclosure needs the interval to be shorter than that? You could test this yourself by forking the repo and editing this line to something like (1000 * 1000 * 5).

Just so you're aware, I'm currently working on the next major loader and d2x cIOS updates, and I don't push any of my changes to GitHub until I'm ready to share a new release. So, if adjusting the interval for reading a random sector helps avoid freezes, just let me know and I'll adjust it in my local copy.

If adjusting the interval doesn't help, then I might consider adding the optional ability to disable APM and the standby timer directly to the cIOS, since then it would work from any loading IOS, and, if necessary, I could even have it check and resend the ATA commands while you're playing a game.

[jmbass]

Hi @wiidev, thanks for the suggestion. I tested the shorter watchdog interval, but unfortunately it did not prevent the freeze.

My existing installation was already current:

• IOS249[56], revision 21011, d2x-v11-beta3
• USB Loader GX was explicitly configured to use IOS249 for the control

I built d2x-v11-beta3 from commit 33ad1ee with only this change:

-#define WATCHDOG_TIMER (1000 * 1000 * 10)
+#define WATCHDOG_TIMER (1000 * 1000 * 5)

I installed it separately as IOS252[56], revision 21999, named d2x-v999-watchdog5s, and explicitly selected IOS252 for the second test. The other cIOS modules were the official v11-beta3 binaries, I only replaced EHCI.app for the custom build.

For both tests:

• I disabled my Disable HDD power saving option so no ATA power commands were sent.
• The Wii and HDD were fully power-cycled.
• The same FAT32 partition, game and reproduction steps were used.

Test procedure:

1. Leave the Twilight Princess save-selection screen idle for over one minute.
2. Select a save.
3. Continue past the brightness warning.

With both IOS249’s 10-second watchdog and IOS252’s 5-second watchdog, the game black-screened at that point. The HDD activity LED continued flashing throughout the idle period, so periodic USB activity was still occurring.

As a positive control, enabling my USB Loader GX’s Disable HDD power saving feature prevents this freeze. Twilight Princess and Guitar Hero III both survive their previously reproducible idle/loading failures with that option enabled.

So reducing the random-sector interval from ten to five seconds does not address my unit. Given that the bridge firmware alone did not reproduce the problem in your enclosure I believe this is dependent on the internal HGST drive’s APM behaviour. Your proposal regarding a cIOS-level ATA commands with periodic reapplication now seems like the more promising direction to me. I would be happy to test or contribute that implementation.

[wiidev]

Good news. I can now reproduce the issue.

I happened to have an old 2.5" HGST drive, so I connected it to a PC via SATA and used FTool (FT216M2 for my drive) to change the APM value from 128 to 1. Then I followed these steps:

Test procedure:

1. Leave the Twilight Princess save-selection screen idle for over one minute.

2. Select a save.

3. Continue past the brightness warning.

You might be able to do the opposite to permanently fix your drive too.

I'll see if I can come up with another solution, or at least make disabling APM a seamless process for users.

[jmbass]

That's cool! thank you for taking the time to reproduce it with another HGST drive.

I did investigate changing the drive itself before implementing the USB Loader GX workaround. Through the JMS578 bridge, the standard ATA APM command works, but only for the current power session: After completely removing power and reconnecting the enclosure, it returns to APM level 1.

I also changed the JMS578’s persistent EEPROM standby setting to zero and verified the resulting firmware backup. That did not eliminate the wake delay or the Wii freezes, that's how I confirmed that the bridge’s standby timer and the internal HGST drive’s APM default are separate settings.

FTool may provide a permanent fix for this particular disk, but your procedure used a model-appropriate FTool build and a native SATA connection. My drive is in the Maxone enclosure with only an USB access available. I have not found a verified FTool version or a supported procedure for changing its persistent APM default through that bridge. Doing so would require opening the enclosure, connecting the drive directly to SATA and modifying its persistent drive configuration - I don't have the hardware to do that right now.

In any case, it could be a useful personal hardware-level solution if I can identify and validate the exact tool but it would remain model-specific and, in my opinion, more invasive than a reversible software workaround. It also would not help users with sealed enclosures, no native SATA access (like myself) or drives whose persistent settings cannot be modified safely.

I agree that making this seamless (at the cIOS layer) would be a better general solution than requiring users to diagnose and modify individual drives. I’m happy to test any implementation you develop. I'd also be happy to rework it around whichever architecture you consider appropriate if you're open to outlining the interface or behaviour you want and letting me prepare the patch for review, if you prefer.

[wiidev]

Can you confirm that this version fixes the issue for you? It's based on the current enhanced branch and only requires this one file to be modified.

This should be an improvement, since it doesn't require users to adjust any settings and keeps APM enabled, which should result in lower power consumption compared to disabling APM entirely.

I've already ported it to the cIOS, since it does fix things for my drive.