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
all the other youtubers are trash trying to get views
Glad to see it's not an unfixable issue, just a bit of tinkering.
A perfect example of planned obsolescence in effect, the emmc wearing out is not hard to predict. Not nearly as much of a problem with PS5 but I still try to put everything I can in the m.2 expansion and avoid using the internal storage.
There's still rumor and reports of people who have their whole OS Flash storage going corrupted which indexing doesn't fix. So before you write off many of those click baiting or covering the news, just please bare that in mind.
The actual command is bcdedit /scanos
as long as the premise of what i meant got through with the messaging im not going to split hairs over specifics :)
Also if the recovery menu by Gary is the ultimate fix, what's this?
To understand there are 3 main reasons why a 160-0103 can occur.
1. MEDIA ERROR: The eMMC itself reports an error because it can no longer read data. (The internal ECC detects that there are too many bit errors, so there is not enough redundancy to correct the errors). You will see "MEDIA ERROR" on mlc01 in the logs and mmcblk error:
This is a sure sign of a hardware error.
2. DATA CORRUPTION: This occurs when the file system detects that the data is corrupted / manipulated. WFS stores a hash for each file, if the hash does not match anymore, because data was corrupted. In the syslog it looks like this:
This can be caused by several reasons, maybe there was a power failure or crash while writing the file or a software error (in IOSU) has overwritten a wrong block. It can also happen if the underlying hardware returns wrong data "silent data corruption". This can happen due to an incorrectly implemented ECC or that simply so many bits have fallen over that the ECC can no longer recognize that the error is no longer recoverable or also general errors in the firmware or FTL.
3. CBHC (Cold Boot Haxchi) Brick. Before Maschell found FailST there was an exploit for DS VC games. To make the exploit run automatically on startup, the "default_title_id" in the system.xml on the SLC was changed to point to the DS game (instead of the Wii U menu). If now this game was deleted (e.g. by a factory reset for reselling) this default_title_idins shows empty and the OS throws either 160-0101 or 160-0103. 160-0101 only occurs with this CHBC brick and not with NAND corruption. 160-0103 can occur with both. If it is a CBHC problem, it will logically only occur at boot time and not in games, settings etc.
Gary's recovery does nothing else with the Set Coldboot Tile option than changing the entry in the system.xml back. There is nothing more behind it, it just changes the value in an xml file. (And with this Gary helped a lot of people).
For the SLC where the system.xml is located there is no persistent cache. The system menu is not touched for this. And the system.xml can't be corrupted by itself either, because then the Wii U would get stuck with a blue blinking LED in boot1, because the system.xml is protected with a hmac and boot1 has to read the default_os_id to know from where it has to load IOSU.
With this information we can say that Voultar has only fixed CBHC bricks, which is not surprising, given the way he acquired his sample (via his modding affine followers). And since he knows it better anyway, he has also refrained from researching.
But he didn't fix any NAND corruption, he didn't fix any system menu and he didn't rebuild any database or cache.
Stop the insults.
Stop arguing... discuss civilly.
Anymore guideline violations will be dealt with.
This is a forum where all members discuss topics/posts in the threads.
Sure enough I followed the Video from @natr0n and bought a pico. I got to the recovery menu and set the Coldboot Title to the EU one (because I am from Europe). It didn't change anything. I tried it a few more times, but now the Recovery Menu isn't shown anymore. The LED still turns purple if I connect the Pico, in case that is important.
Can you help me understand what is going on @lexluthermiester ?
Am I doing something wrong?
Do I need to use this bcdedit command, but where would I enter that?
voultar.com/index.php?route=product/product&product_id=92
gbatemp.net/threads/using-nand-aid-to-repair-a-broken-emmc-fix-160-0103-system-memory-error.636361/
www.boards.ie/discussion/2058305084/my-wii-u-it-met-with-a-terrible-fate
Here's something to consider: MOST WiiU's will not have the NAND problem as Nintendo only used the Hynix NAND in limited numbers. So as much money and time as you will spend on fixing your WiiU, it might be easier to simply buy a new one. However, there is something to be said about the fixing the one you have. And if it's booting up, getting to the point of showing you an error(any error, not just the 160-0103), then the system is still alive, just can't read it's NAND.
So it's up to you(and anyone else who reads this) how much of a deep dive you want to make.
BTW, welcome to TPU! I would normally agree with you, but with the WiiU problems, it's a bit more involved and fine-grained than simple device abuse. In the case of WiiU's, the Hynix NAND supplied to Nintendo had a problem no one knew about until it was too late. It is unlikely that even Nintendo themselves knew about it until this problem came to light.
@padripper Basically all had been said already except: The purple LED indicates that the recovery menu is still working, NAND corruption is now just at a point where the fonts or something like that corrupted. So now you'll have to navigate it blindly. Have a look at the tutorial on GBATemp (the one lexluthermiester linked) for a fork of the recovery menu + a screenshot of its menu which will hopefully help you to navigate it blindly (we're currently working on giving hints on the power LED of the Wii U to make it more simple to navigate blindly but that needs time to get implemented). Also make sure to completely understand that tutorial before trying anything more to fix this.
Also note that on GBATemp NAND-AIDs are getting sold currently. In case you can't access GBATemps trading area ask around if someone has one available or search on eBay (just make sure to not pay more than around 10 € for the full set).
In case you're not good at soldering and don't know someone who could help you with this it might be a good idea to ask at a local phone repair shop or something like that. You'll still need the NAND-AID and at best give them a link to the howto lexluthermiester linked. Would be sad to turn that Wii U into E-waste, so in case this really gets too complicated for you look on eBay: Thanks to developers purchasing such Wii Us they get sold for almost the same costs as working ones... ;)
//EDIT: Also it's not all Hynix ones but only ones produced in roughly 2012 / beginning of 2013 (chip producing date, not Wii U producing date).
@V10lator
Let's let bygones be bygones. Continuing from our PM:
So let's talk tech for sec. Were you serious when you said that the recovery is still running on a black screen? Everywhere I've read and seen indicates that the NAND is unrecoverable at that point. Can it still be recovered from that point? And would the recovery procedure be any different? This I was aware of. It was limited run of the NAND that had a previously unknown issue. Most of it didn't.
Also you can't resize the FS, meaning you'll loose all data when you change the size as you have to reformat. With going same-size you're able to clone and fix the corrupted FS. For reformatting you also need de_fuse (or ISFSHAX but that's not yet ready for primetime).
So in this case I would suggest to stay same-size to make the process as simple as possible.