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
Add your own comment

32 Comments on Nintendo Wii U Memory Failures Investigated by Homebrew Community, Hynix Chips in the Spotlight

#26
lexluthermiester
V10latorThe Wii Us OS supports 8, 32 or 64 GB only.
Did not know that. Haven't tried it personally.
V10latorSo in this case I would suggest to stay same-size to make the process as simple as possible.
With the 8GB WiiU, upgrading it to 16GB or 32GB should be seamless as the WiiU OS natively supports upto 32GB.
Posted on Reply
#27
V10lator
lexluthermiesterWere you serious when you said that the recovery is still running on a black screen?
Yes. As long as the power LED turns purple the recovery menu is running. Ofc. there are also other cases, so what color the LED shows is important. :)
lexluthermiesterCan it still be recovered from that point? And would the recovery procedure be any different?
Yes it can and the procedure is the same. Only difference is that you need to navigate the recovery menu blindly.
lexluthermiesterWith the 8GB WiiU, upgrading it to 16GB or 32GB should be seamless as the WiiU OS natively supports upto 32GB.
The OS supports up to 64 GB natively. Looks like Nintendo planned a 64 GB console but never released it. ;)

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).
Posted on Reply
#28
lexluthermiester
V10latorOfc. there are also other cases, so what color the LED shows is important. :)
Ok, fair enough.
V10latorYes it can and the procedure is the same. Only difference is that you need to navigate the recovery menu blindly.
Ok, and it still recovers properly?
V10latorThe OS supports up to 64 GB natively. Looks like Nintendo planned a 64 GB console but never released it. ;)
Nice. Wish they had. I personally love the WiiU, one of my Fav Nintendo consoles.
V10latorAs 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).
Based on what I've read, it seems like you could reformat the 8GB to 16GB/32GB, losing all data, but having a factory fresh WiiU? Is that not right?
Posted on Reply
#29
V10lator
lexluthermiesterBased on what I've read, it seems like you could reformat the 8GB to 16GB/32GB, losing all data, but having a fresh factory fresh WiiU? Is that not right?
32 GB will work without constant patches, yes. With 16 GB you'll have to use the constant patches. When you plan to upgrade anyway w/o using constant patches I would suggest to upgrade to 64 GB through as that's the max the OS supports. ;)
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).
lexluthermiesterOk, and it still recovers properly?
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).
Posted on Reply
#30
lexluthermiester
V10lator32 GB will work without constant patches, yes. With 16 GB you'll have to use the constant patches. When you plan to upgrade anyway w/o using constant patches I would suggest to upgrade to 64 GB through as that's the max the OS supports. ;)
Ok, I'll remember that.
Posted on Reply
Add your own comment
Dec 18th, 2024 04:58 EST change timezone

New Forum Posts

Popular Reviews

Controversial News Posts