Monday, March 20th 2023
Nintendo Wii U Memory Failures Investigated by Homebrew Community, Hynix Chips in the Spotlight
The homebrew and modification community has delved deeper into the recent bout of bricked Nintendo Wii U consoles, unlucky owners are seeing their systems throwing up error codes that indicate an internal memory failure. As covered on TPU almost two weeks ago, it was speculated that leaving a Wii U in a long-term state of unuse was a root cause of the problem. It is now theorized that a simple choice of memory chip is the real issue behind the corruptions, and not a case of leaving your unplugged Wii U stashed in a box somewhere.
An online database has been established on hackmd.io, and a member is collecting hard data from Wii U owners across various online communities and sources. Early indications show that consoles fitted with a Hynix eMMC are leading the pack in terms of number of system failures, Samsung-equipped models are placed in a distant second place, and the Toshiba variant is reported as having zero problems.Early release versions (2012 - 2013) of the Deluxe Black 32 GB edition are most likely to be fitted with the problematic Hynix memory module, according to further research carried out by the community. The basic White 8 GB edition is thought to be entirely unaffected by corruption issues, due to it featuring a different Samsung board. The hombrew community has found two methods to restore normal operation on a corrupted console. One involves circumventing the internal memory entirely by using an external SD card as a primary memory module, and the other fix requires a Raspberry Pi Pico to be connected to the console via USB.Gamers are in a rush to shore up their Wii U and 3DS game libraries in anticipation of Nintendo's shuttering of online services on March 27, which has likely contributed to the uptick in discoveries of bricked systems. There has been a lot of activity and communication on Twitter regarding the Wii U memory lottery - key figures are keen to provide tips and are also asking for feedback from anyone with a bricked system:
Sources:
HackMod Wii U Dead eMMC List, OatmealDome Tweet, Voultar YouTube Channel
An online database has been established on hackmd.io, and a member is collecting hard data from Wii U owners across various online communities and sources. Early indications show that consoles fitted with a Hynix eMMC are leading the pack in terms of number of system failures, Samsung-equipped models are placed in a distant second place, and the Toshiba variant is reported as having zero problems.Early release versions (2012 - 2013) of the Deluxe Black 32 GB edition are most likely to be fitted with the problematic Hynix memory module, according to further research carried out by the community. The basic White 8 GB edition is thought to be entirely unaffected by corruption issues, due to it featuring a different Samsung board. The hombrew community has found two methods to restore normal operation on a corrupted console. One involves circumventing the internal memory entirely by using an external SD card as a primary memory module, and the other fix requires a Raspberry Pi Pico to be connected to the console via USB.Gamers are in a rush to shore up their Wii U and 3DS game libraries in anticipation of Nintendo's shuttering of online services on March 27, which has likely contributed to the uptick in discoveries of bricked systems. There has been a lot of activity and communication on Twitter regarding the Wii U memory lottery - key figures are keen to provide tips and are also asking for feedback from anyone with a bricked system:
32 Comments on Nintendo Wii U Memory Failures Investigated by Homebrew Community, Hynix Chips in the Spotlight
As said you can't resize the filesystem and filesystem size and physical size need to match. So what's possible is:
- Clone a 8 GB eMMC onto a 8 GB SD.
- Clone a 8 GB eMMC onto a 16 GB SD (only 8 GB will be usable through).
- Clone a 32 GB eMMC onto a 32 GB SD.
For all other you'll have to apply constant OS patches (so need de_fuse or ISFSHAX) and reformat the filesystem (which also needs de_fuse or ISFSHAX + you'll loose all your data).
More technical explaination: The Wii U OS does this:
If physical size < 32 GB its a 8 GB console, so FS must be 8 GB.
Else if physical size < 64 GB it's a 32 GB console, so FS must be 32 GB.
Else it's a 64 GB console, so FS must be 64 GB.
Credits for reverse engineering the OS here + designing the patches used in de_fuse / ISFSHAX is Gary (GaryOderNichts on GBATemp).
With reformatting you start with a more or less factory fresh Wii U (still some things left on the SLC, like old tickets and stuff which survive even a factory reset). Recovery procedure is just the same: You clone, then you fix the corruptions on the clone. Note that FS metadata corruptions aren't fixable, so we can fix corrupted files (by simply replacing them) but corrupted folders or quotas we can just move away so the Wii U won't crash anymore (except when doing a factory reset, that's the reason for the "Bonus: Work around factory reset crash loop" section at the GBATemp howto you linked previously). This is true no matter you have screen output on the recovery menu or not through.
So in a case of having corrupted metadata it's up to the user to either live with factory reset crashing or reformatting (and with it upgrading to 64 GB as it makes no sense to use less when you need to reformat anyway).