Hacking Hardware Homebrew Assistance in Unbricking an Old Wii U

[Scoobz3096]

Hello, alright so-

I have an original Wii U from about when it released in 2012 with the error code 160-0103, to which it bricked and showed signs of failing for a year or two beforehand in 2017. In the recent days however, I started trying out the UDPIH method, to which I could use just fine. After trying out the basic procedure of assigning the coldboot, it still would show the error screen on startup.

Since then, I have managed to dump the logs, otp.bin, and the mlc_checker, as well as cleaning up the mlc file to show only where the errors are, and at this point, I'm just curious to where I should even go- whether or not it's worth trying, or knowing if my NAND is corrupted or my eMMC, and if there's potential to fix it. I've only done brief research into both, so I figured it's likely better to ask to see where this should go.

I've attached all the log files, and I greatly appreciate any assistance- thanks in advance!

 

[SDIO]

I only see DATA CORRUPTION ERROR but no MEDIA ERROR. The latter would clearly indicate a eMMC failure. But the fact that you have multiple corrupted files makes me believe that this is also probably a eMMC failure.
When you go to System Information, what is the Manufacturer of the MLC and what is the CID?

 

[Scoobz3096]

I only see DATA CORRUPTION ERROR but no MEDIA ERROR. The latter would clearly indicate a eMMC failure. But the fact that you have multiple corrupted files makes me believe that this is also probably a eMMC failure.
When you go to System Information, what is the Manufacturer of the MLC and what is the CID?

In system information, my manufacturer ID is 0x11 (Toshiba),
and the CID is 11010030303847344200891767377f00

 

[SDIO]

This is a really hard call to make. On one hand there are a few things speaking agains a hardware failure and thus replacing the eMMC might be unnecessary hassle and expense but on the other hand if it is really a hardware failure trying to fix it on the broken hardware might corrupt the file system even more and cause more problems down the line. At the moment the corruption doesn't seem to bad, even though you have corrupted directories, which is quite annoying.

OpenFile;/vol/storage_mlc01/usr/save/system/boss/80000001/task.db;-00030015

this isn't a true error, it's just opened by another process.


Things that speak against a hardware failure:
- We don't see MEDIA ERROR in the log, which would be a clear indicator of a Hardware Failure
- It's a Toshiba, we usally only have failures on Hynix, Toshiba are the most reliable.
- There aren't that many files corrupted. On dying hynix consoles we usually see more corruption.
- These files, that are corrupted are written often. We usually se failure on files that are written seldom. Because with the Hynix the problem seem to be leaky gates and so the oldest data there is most likely to corrupt. And with data in that is regulary written, there is a higher chance that you cut power in the wrong moment and thus create corrupted files. In theory the file system should prevent such failures but we don't know how good it really is at that. Also it could be that the eMMC isn't as good in handling these situations and looses data the FS already assumes to be safe.

Why it could still be hardware failure:
- Because we don't see many Toshibas failing, we don't have much experience on how they fail, maybe they corrupt the data silently, without reporting that the data is corrupt. In that case we would get the picture we have here.
- There are multiple files, directories corrupted. If it was a just caused by a power outage in the wrong moment, I would expect only one or two files to be corrupted.
- These files are written often. As already said, the toshibas might fail in a different way. Maybe they have bad wear leveling and just constantly wrote to the same cells, making them fail.

To see what replacinf the eMMC would involve, see this thread: https://gbatemp.net/threads/wii-u-n...nd-replacement-interposer-public-test.630798/

Either way the first action should be to do a backup. I assume you already dumped otp and seeprom.
You can use the recovery menu from here to do a backup: https://gbatemp.net/threads/wii-u-stuck-on-logo.630328/post-10120270
Please just turn the console off and keeps it off, if you plan to replace the eMMC.
Also it will show errors while dumping the slc, these are caused by problems with the dumper and don't indicate a slc failure.
Keep an eye on the errors on bad block during the MLC dump. Any errors there indicate fa failing eMMC. If you see errors or badblocks there or are unsure, please send the logfile it produces.