Purchased another Wii U console that isn't working. This one was 10 dollars because it has no audio/video output according to the seller. I figured I would take a crack at it and see if I can fix it. So far I have 2 fully working Wii U that had bad eMMC. I don't know if this one has a similar problem or if its entirely something else. Lets dive into it.
Its a model WUP-101(02) 32GB
IMG_7999.JPG
IMG_8001.JPG
Based on the ports on the back its an earlier model from the first production of the Wii U. The later models are all black in the ports. This doesn't mean it necessarily has a defective eMMC, but without system information dump, logs or opening the unit up right now I wouldn't know if it has one of the notorious Hynix chips. Before we go that route I want to see if its actually booting and we are just getting a black screen or is the console not booting at all.
Plugged the Wii U into power & HDMI. All I got was no signal on my tv, but the console does boot with a steady blue light on the front, which is interesting. I shut it down and tossed in the recovery memory and used a UDPIH and got the most beautiful display out!!!
IMG_8002.JPG
Yikes, not sure what the problem is. I am going in blind here so I am going to attempt to navigate the recovery menu and get a log file dump to see what might be going on. If I get a log file dump, that proves the console is booting and just not displaying an output properly.
Recovery Menu I am using is attached to this post.
In order to get logs I have to press Eject 8 times and Power 1 Time. Problem is sometimes pressing the eject button doesn't move the cursor in the recovery menu.
Well I was able to dump the logs, but unfortunately there are no logs. This isn't looking good at all. However on the other hand it proves that the recovery console is indeed working so I wonder if this is a hardware problem. I am going to try to blindly dump the SLC/MLC. If I can dump those and they are intact mostly, we may be able to salvage this console and fix it. If I cannot dump those then this console probably isn't fixable.
I decided to run the MLC Checker instead since it creates a log file. I did interrupt it after nearly 9 hours. It didn't finish as the log file doesn't stay Finished near the end. It has alot of corruption from what it did make it through. I don't have any way of knowing if this is 10% of the MLC or 90%. I might run it again and let it go for a couple days.
Here is what the log shows:
ReadDir;/vol/storage_mlc01/sys/title/00050010/10040100/;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/10041100/code/;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10043100/code/cos.xml;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10043100/code/title.tmd;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10043100/content/drc_fw.bin;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/10044100/content/;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/code/updater.rpx;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/10045100/content/layout/;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/EU_Dutch/;-0003001B
ReadDir;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/EU_English/;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/EU_German/updater.msbt.zlb;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/EU_Italian/updater.msbt.zlb;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/EU_Portuguese/updater.msbt.zlb;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/JP_Japanese/updater.msbt.zlb;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/US_French/updater.msbt.zlb;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/US_Portuguese/updater.msbt.zlb;-0003001B
ReadDir;/vol/storage_mlc01/sys/title/00050010/10045100/content/message/US_Spanish/;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/10045100/content/shaders/;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/content/sound/SE_BAR_WAITING.dsp;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/meta/bootDrcTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/meta/bootMovie.h264;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/meta/bootTvTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10045100/meta/iconTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/code/set.rpx;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/content/Common/Package/Set.pack;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/content/Common/Package/Set2.pack;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/content/Common/Sound/Set/cafe_barista_set.bfsar;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/10047100/content/Common/Sound/Set/stream/;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/content/Us/Model/ConfigTvCap_Us.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/content/UsEnglish/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/content/UsFrench/Message/AllMessage.szs;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/10047100/content/UsPortuguese/;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/content/UsSpanish/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/meta/bootDrcTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/meta/bootMovie.h264;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10047100/meta/bootTvTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/code/pcl.rpx;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/content/Common/Package/Pcl.pack;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/10048100/content/Common/Sound/Pcl/;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/content/Us/Layout/ParentalRating_usa_fr_Us.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/content/Us/Model/ParentalTvCap_Us.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/content/UsEnglish/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/content/UsFrench/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/content/UsPortuguese/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/content/UsSpanish/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/meta/bootDrcTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/meta/bootLogoTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/meta/bootMovie.h264;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/meta/bootTvTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10048100/meta/iconTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/code/acs.rpx;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/code/app.xml;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/code/cos.xml;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/code/title.fst;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/code/title.tmd;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/content/Common/Package/Acs.pack;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/content/Common/Sound/Acs/cafe_barista_acs.bfsar;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/content/Us/Model/AccountTvCap_Us.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/content/UsEnglish/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/content/UsFrench/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/content/UsPortuguese/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/content/UsSpanish/Message/AllMessage.szs;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/meta/bootDrcTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/meta/bootLogoTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/meta/bootMovie.h264;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/meta/bootTvTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/meta/iconTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/10049100/meta/meta.xml;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/1004a100/;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/libfont4_sdk20000.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/libjpeg.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/libopenssl.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/libpixman.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/libwk_peer.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/libwk_peer_access.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/libwkc.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/libxml2.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/mvplayer.rpl;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/title.fst;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/title.tmd;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/code/wave.rpx;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/content/browser/effective_tld_names.dat;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/content/browser/MediaControls.css;-0003001B
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/content/browser/rootca.pem;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/content/browser/Skin.dat;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/content/browser/UserCss.dat;-0003001B
ReadDir;/vol/storage_mlc01/sys/title/00050010/1004b100/content/font/;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/content/initial.oma;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/1004b100/content/layouts/;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/1004b100/content/mediaplayer/;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/1004b100/content/message/;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/content/preload.oma;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/1004b100/content/shader/;-00030041
ReadDir;/vol/storage_mlc01/sys/title/00050010/1004b100/content/sound/;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/meta/bootDrcTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/meta/bootLogoTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/meta/bootMovie.h264;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/meta/bootTvTex.tga;-00030041
ReadFile;/vol/storage_mlc01/sys/title/00050010/1004b100/meta/iconTex.tga;-00030041
When I attempt to check the SLC it creates no log file even after running for over 10 hours. So there may be something wrong with the SLC. I don't know if this means the console isn't repairable but its looking that way. My understanding is that if the SLC is missing and there is no backup there is no way to repair it because it has to stay in the synced state with the MLC. I still have to open it up and inspect it. I will have to do that another day.
I took the console apart and it is indeed a Hynix chip. See picture
IMG_8005.JPG
I inspected the HDMI Port and the rest of the board under a microscope to see if there was any obvious signed of damage. There was nothing I could find except a small section with cracked solder joints on 2 components, a fuse and a capacitor. Marked in the picture below:
IMG_8009.JPG
My camera isn't good enough to see the cracked solder joints. The naked eye cannot see them either. They are obvious under a microscope though. I repaired them and plugged the console back in to see if the HDMI output was fixed. Its not. I believe this is a software issue.
I was able to blindly load Minute on the console, by hitting eject 18 times, power 1 time, eject 1 time and power 1 time.
minuteloaded.JPG
I was able to dump SEEPROM & OTP from Minute and I am currently dumping the SLC-RAW. I am also going to dump the SLCCMPT-RAW.
SLCraw.JPG
Perhaps this is a good sign that this console may be fixable. I am going to install ISFShax and see how far I can get.
YES!!! Alright with the minute menu I was able to dump the log files and the console does indeed have them. 99 in total actually. Added to this post.
Look at what we have in them too....the curse of the Wii U console...Another bad eMMC
01:48:35:267: FSA: ### MEDIA ERROR ###, dev:mlc01, err:-2228230, cmd:11, path:(null)
01:48:35:323: mmc_core card err: idx=3, lba=8798208, blks=1024, xfer=0x1, ret=0x00200b40
01:48:35:358: mmc_core card err: idx=3, lba=8798208, blks=1024, xfer=0x1, ret=0x00200b40
01:48:35:359: mdblk: err=-131099, mid=0x90, prv=0x5c, pnm=[HYNIX ]
01:48:35:359: FSA: ### MEDIA ERROR ###, dev:mlc01, err:-2228230, cmd:11, path:(null)
01;48;35;236: FS: READ_FILE upid:[15] sts:[MEDIA_ERROR] hnd:[0x3b72240] dst:[0x18e97940] size:[1] cnt:[1048576] pos:[0]
01;48;35;236: SystemFatal(core1)
I think I am going to install a NAND-AID to this console and see if I can rebuild the MLC. Perhaps the eMMC in the console is so far gone that it cannot load even the basic requirements to get video out. I will do some more testing and then move forward with a NAND-AID and just rebuild the file system.
Did some testing, eMMC is def too far gone to recovery data from. So I installed the NAND-AID and this time I tossed in a 64GB SD Card. It turns out the Wii U without any modifications actually supports up to 64GB cards as a replacement eMMC. If you want larger cards you have to install and permanently run an ISFShax mod. I am going to rebuild the file system and see if we can get this Wii U working again.
IMG_8011.JPG
NAND-AID installed successfully. The rebuilding of the file system went without a hitch. That being said, Long story short, it was working great until I went to install an update for a game and got Error 105-3016. The video shows exactly what happen. In a nut shell I tried to delete some corrupt data towards the end and after 20 minutes of it sitting on the deleting data screen I decided to pull the plug. This was clearly a mistake. The console turns on with a solid blue light. It will not boot into the Wii U menu. It will not load the recovery menu using the UDPIH. I am unable to get it to do anything.
A video of everything that happen is below. Sorry for the loud Wii U Menu audio among other audio issues, its the first video I have created and there is much room for improvement.
I will have to do some research and see if I can somehow get the console to come back to life. I am not entirely sure what happen from unplugging it from power. Maybe it corrupted the SLC, if that is possible. At this point it appears to be bricked.
I am unable to get the Wii U to do anything. Blue light turns on, it doesn't respond to UDPIH/Recovery Menu. Disc drive does something interesting if I hit the eject button it will spit out a disc if there is one in there. Doesn't matter how long I leave it on light stays blue and eject continues to work.
Its a confusing situation as the console was on for 3 hours while I rebuilt the MLC, Configured the Wii U Menu and then attempted to install an update/troubleshoot Error 105-3016. All it took was that single pulling of the power adapter after 20 minutes of it sitting on deleting data do not power off screen to apparently brick/kill the console. In hindsight I should have let it run for a couple hours to see if the delete message would clear. I can only assume that pulling the power plug damaged the SLC or something else happened. At this point I am going to move on to another console.
Hi tzirf,
just saw this. An interesting problem indeed.
This is probably either a problem with the SD card or the scfm.img on the SLC. Can you sent me the latest logs you dumped, they might give a hint which one it is. The SLC checker in the recovery doesn't check the scfm.img (which isn't possible for several resons)
The 105-3016 error probably has nothing to do with the 105-3015. At least the cause seems to be a completely different. 105-3015 is caused by just wrong permissions while 105-3016 were corrupted data. The Wii you probably couldn't delete the download because either it Filesystem Metadata of that file (and not the data in the file itself) became corrupt or because there was a corrupted folder (which is also FS Metadata)
When it hung, waiting longer wouldn't have helped. It hung because something went wrong with the mlc which also is the cause why it doesn't boot anymore.
In addition to looking at the latest logs (which isn't always the one with the highest number, because it wraps around at 99), you could try to image the SD in a PC to see if that gives any errors and then also if you can writ back to the SD. Also I would recommend checking the soldering of the NAND.
If the problem isn't just the SD card failing and going ro, then you might need to defuse since you removed ISFShax. That shouldn't be a problem with your soldering skilly, it's just a little annoying. But first we should check out the other things.
A few small things:
You will always get a orange blinking LED during the setup, if the mlc was already setup, even if there is no corruption. It will try to create some folders, that will fail, because they already exist then that turns the LED orange. You can see what exactly failed in the log written by the installer to the SD.
UDPIH works with ISFShax installed, you just need to boot and insert the pico at the right time. If you modified the Pico formware with a sleep, so you don't have to do the timing manually and just plug it in before, the timing with and with out ISFShax will even be the same, as USB power only gets turned on by IOSU and from that point the time is constant.
I found your voice very quiet, especially in relation to the Wii U sounds, maybe you can increase the volume in the future.
Maybe put a warning before the flickering or cut it out, because it can cause seizures for some people.
Hello SDIO,
I assume you are the one who created these wonderful tools and made them available. Thank you for sharing them with everyone online. Without them I wouldn't have been able to repair any of the Wii U consoles that I have repaired and so far I am up to 10 consoles fixed and only 1 not fixed. Some of these I haven't posted because they were completed before I started documenting the repairs.
I appreciate the suggestions. I have the console put back together, unfortunately I removed the NAND-AID already, and in doing so I tore a couple pads off at the resistors in front of the NAND. I cannot take a picture of it right now as the console is still assembled. I don't think I can get logs or anything at this point. The console doesn't respond. I did run wire from the traces to the resistors and verified with a multi-meter that they were connected.
As for the video, yeah its my first video ever, its rough. Thanks for the feedback. I should be able to make better videos in the future.
I didn't have plans on cracking this Wii U back open, but if it can be saved using Defuse, I am willing to go back to working on it. The only logs I have are in a post above. Unfortunately I wasn't able to get log files to dump after the console stopped responding to the recovery menu/UDPIH.
When you say
QuoteUDPIH works with ISFShax installed, you just need to boot and insert the pico at the right time. If you modified the Pico formware with a sleep, so you don't have to do the timing manually and just plug it in before, the timing with and with out ISFShax will even be the same, as USB power only gets turned on by IOSU and from that point the time is constant.
Does this mean you can have ISFShax installed and still get to the recovery menu by inserting the Pico at the correct time?
You dumped the logs in the video, after the error happened the first time. If you still have them, they might tell us what was failing.
What did you do with the SD card, after you removed NAND-AID? If you didn't image it and overwrote it, you would have to defuse in any case.
Quote from: SDIO on Feb 12, 2024, 07:52 PMYou dumped the logs in the video, after the error happened the first time. If you still have them, they might tell us what was failing.
What did you do with the SD card, after you removed NAND-AID? If you didn't image it and overwrote it, you would have to defuse in any case.
Yes I believe these are the log files. I have attached them to this post. Also no the SD Card I believe I wiped and used in another Wii U as its been difficult for me to find Micro SD Cards for these consoles and I needed one at the time. I am okay with trying to do defuse. I don't know anything about it. Sounds like it requires a bunch of micro soldering though based on what you said in your previous post.
Hm the zip is missing the meta.bin, which tells us, which is the latest log.
For defuse have a look here: https://github.com/shinyquagsire23/wii_u_modchip/tree/main/pico_defuse The testpads are all fairly large and easy to solder to.
Quote from: SDIO on Feb 12, 2024, 08:16 PMHm the zip is missing the meta.bin, which tells us, which is the latest log.
For defuse have a look here: https://github.com/shinyquagsire23/wii_u_modchip/tree/main/pico_defuse The testpads are all fairly large and easy to solder to.
I apologize. I didn't know the meta.bin had the latest logs. :-[ Does this help? ;D
Hm, 31 is the lates logs (the meta.bin says 0x97f = 2431, 2431 % 100 = 31) and that still has Hynix in the error. So seems like there wan't a log written.
So without defuse I can't tell. And even with hard to tell, because you would delete the scfm.img to reinstall and with that you would probably also delete the corruption
Yeah I realized after the fact that while I worked on this console I made many mistakes. It was one of the consoles that if I could go back I would have done things differently. I will have to give defuse a try and post back. I might be able to solder the wires in the correct location on the Wii U later this week.
@SDIO I am going to start the soldering for Defuse. I was looking over the picture they provide and I have some questions of where exactly some of these wires need to be soldered on the Pico. It is probably just my ignorance since I am not familiar with using the Pico GPIO in this way. My question is TP176/TP48 in the picture seems to connect to multiple GPIO Points on the Pico. Its highly possible I am misunderstanding what is being shown in the picture. Do I have to solder to each one of these points?
Also, if Defuse is able to fix this console, can I remove the Pico after the repair is complete? or is this something that must stay with the console?
Yes you need to connect some of them to multiple GPIOs of the pico, as it drivers would be to drive some of the signals otherwise.
You can remove the pico again once the console is fixed and can boot without patches
I decided to take another look at this console. I was going to just get Defuse setup, by soldering a Pico to the board. For some reason I decided to check continuity on the resistors in front of the eMMC. 2 of them have it but 3 of them don't. There is definitely something going on here.
The ones marked in purple have continuity, the ones marked in orange do not.
IMG_8005.JPG
I don't think defuse is going to tell me what the problem is unless I figure out what is going on with these resistors. I am thinking about removing them from the board and retesting with just solder bridging the gaps. It wouldn't surprise me if these resistors are damaged.
@SDIO Do you know if the resistors here are necessary? can I remove them and get the console to at least boot the recovery menu?
I was able to re-solder the resistors and they now have continuity. I don't know if doing that makes any difference when using defuse.
That being said, the console still does the same thing. Solid blue light, cannot get it to boot into the recovery menu no matter what I try. Also no matter what length of time passes, pressing the eject button will get the disc drive to try to eject a disc, even though there isn't one in the drive. I am going to start the soldering for defuse at this point.
These resistors don't matter if you install NAND-AID. They have something around 22ohm, so your multimeter in continuity mode might or might not see that as continuity. If one is dead it can also just be bridged, without negative consequences.
The left of these resistors goes to the host controller on the Wii Us SoC and the right to the eMMC.
If you use NAND-AID, you disable the eMMC anyway and solder to the left pad, so it doesn't matter if these resistors are there.
Also defuse doesn't need them.
Quote from: SDIO on Feb 28, 2024, 02:25 PMThese resistors don't matter if you install NAND-AID. They have something around 22ohm, so your multimeter in continuity mode might or might not see that as continuity. If one is dead it can also just be bridged, without negative consequences.
The left of these resistors goes to the host controller on the Wii Us SoC and the right to the eMMC.
If you use NAND-AID, you disable the eMMC anyway and solder to the left pad, so it doesn't matter if these resistors are there.
Also defuse doesn't need them.
I checked the resistors and the measurements I am getting are not even close to 22ohms. I am measuring from 2-5ohms on all but 1 of them, which is measuring only .6ohms. I suspect there is a short around this area on the board. My gut is telling me to solder a NAND-AID back into the console and see if I can get to the recovery menu. It could be a complete waste of time. However for some reason I feel like the other NAND-AID stopped working for some reason and that was why this console ended up where it is.
check for shorts between the signal lines and between the signal lines and gnd and 3V3. Also see what happens if you just remove the resistors.
Quote from: SDIO on Feb 28, 2024, 02:47 PMcheck for shorts between the signal lines and between the signal lines and gnd and 3V3. Also see what happens if you just remove the resistors.
If I remove the resistors. Would the console still be able to boot far enough to get into a recovery menu?
For UDPIH to work you need a functioning MLC, either on the eMMC or NAND aid. Since the SLC will missmatch the eMMC anyway, it probably also won't if you connect to eMMC through the resistors.
I removed the resistors and now R30, R29, R28, R31, R27 on the left side all measure 37K ohms. just to be clear, yes those are kilo-ohms.
Did you also check for shorts on the right (eMMC) side?
If that looks good too, you could give it a shot and see if it boots far enough with the eMMC to load the recovery. As already said it probably won't because of scfm, but there is a small chance you get lucky and maybe can get around defuse that way.
Quote from: SDIO on Feb 28, 2024, 04:47 PMDid you also check for shorts on the right (eMMC) side?
If that looks good too, you could give it a shot and see if it boots far enough with the eMMC to load the recovery. As already said it probably won't because of scfm, but there is a small chance you get lucky and maybe can get around defuse that way.
No shorts on the right side. All resistor points measure 243K ohms on eMMC side.
Alright. Apologize for the delay here. Had some things going on and didn't have time to sit down and work on this console. It looks like defuse is the only answer to solving this problem. I did reinstall a NAND-AID. Console does the same thing solid blue light and I cannot get the recovery menu to boot. That being said the first pad was ripped off when I removed the original NAND-AID and I am not 100% positive that a connection is being made there. If there is no connection, then it doesn't matter that I installed a NAND-AID. It wouldn't work. I will have to see if there is another point I can test this from .
Edit: I was able to trace the signal back and test it from a point away from the NAND-AID. All pads are soldered correctly. So I can rule that out. The console needs defuse to diagnose it. I plan on doing it. I probably won't get to it until next week. I have 2 Wii U consoles I need to fix ahead of this.
I am resurrecting this thread. I apologize for the long wait on this one. Its been on the back of my workbench for many months now but I finally installed defuse with this console. The documentation seems to be sparse so I need to get a few things setup and then hopefully I can diagnose this console and see what is happening.
There is a readme file included with Defuse that gives some insight on setting it up and some diagnostic steps. I have posted it below
What's New?
-----------------
- Fixed OTP dumping failure caused by corrupted PRSH
INSTALLATION INSTRUCTIONS
-------------------------
REQUIRED FILES
--------------
- boot1.img -- SD card image for minute_minute
- boot1_slccmpt.img -- NAND-flashable minute boot1, for using >2GiB SD cards
- fw.img -- Main bootloader, minute
- wiiu/ios_plugins/wafel_core.ipx -- Stroopwafel core, this plugin loads first and bootstraps all other plugins in wiiu/ios_plugins.
- otp.bin -- This can be dumped via the minute menu, under
`Backup and Restore` > `Dump OTP via PRSHhax`.
The menu will still be available if otp.bin is not present,
however IOS will not be able to boot.
The following versions are provided in the zip:
- [pico_defuse](https://github.com/shinyquagsire23/wii_u_modchip/tree/main/pico_defuse) @ ea84680c5d1e7636c8e8f5da938905581e985c55
- [stroopwafel](https://github.com/shinyquagsire23/stroopwafel) @ 82464ce3b3e43577ab1ca825e9ff34c903a2c7c0
- [minute_minute](https://github.com/shinyquagsire23/minute_minute) @ 464ee918dc97567d79e1b9d2913acb2b879217ec
STEPS
-----
1) Flash pico_defuse.uf2 to the Raspberry Pi Pico via USB. This can be done by copying the file to the USB Mass Storage device that appears.
2) Flash boot1.img to a 1GB SD card. Some 2GB cards may work, but 1GB seems to be the sweet spot--it just has to be non-SDHC. boot1.img includes an MBR header, so you may have to format the FAT32 partition after flashing in order to continue. Flashing can be done via win32diskimager, dd, or any other SD card formatter.
3) Copy fw.img, the wiiu folder, and otp.bin to the root of the SD card. If you do not have otp.bin, it can be dumped via `Backup and Restore` > `Dump OTP via PRSHhax`.
4) Power on the Wii U console. If it is working correctly, the power LED will flash and turn purple. By default, the minute menu will appear on the serial console, however an INI file can be placed on the SD card to trigger autobooting.
Your SD card file structure should contain the following, or it will not boot:
```
sdmc:/
├── fw.img
└── wiiu
└── ios_plugins
└── wafel_core.ipx
└── wafel_debug_exts.ipx
```
A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root.
ACCESSING THE MINUTE MENU
-------------------------
A serial console is required to operate the menu, for now. On Windows you can use PuTTY, on Linux/macOS you can use minicom (eg `minicom -b 115200 -o -D /dev/cu.usbmodem11101`).
minute can be configured to autoboot into IOS via sdmc:/minute/minute.ini. To trigger the menu manually, press (but do not hold) the power button 3-5 times (like you're trying to get into the BIOS on a computer), or until the menu shows up on the serial console. From here you can swap the SD card and make NAND backups. To back up MLC, it is currently recommended to Format redNAND with a 64GB SD card, and then copy the partitions off the SD card.
An example of an autoboot minute.ini is as follows:
```
[boot]
autoboot = 1
autoboot_timeout = 3
```
RESTORING NAND BACKUPS
----------------------
minute now supports restoring NAND backups, however there still *may* be some lingering bugs. AS LONG AS YOU HAVE A KNOWN-GOOD SLC.RAW and SLCCMPT.RAW BACKED UP SOMEWHERE SAFE, YOU WILL BE FINE!! I managed to completely wipe my SLCCMPT and restore it, but I also had one restore where some sectors didn't program for some reason. It could have just been my SD card though.
I plan on continuing to work on this, since I also want to recover a unit which has had its NAND entirely wiped with no backups. However, the current state of things is as I said.
A corrupt NAND will look as follows in IOSU logs:
- "Attached volume to slc01 (raw)"
- "Attached volume to slccmpt01 (raw)"
- A ton of spam about bad hashes (this also happens if otp.bin is invalid or zeroed).
REDNAND
-------
RedNAND can be configured using sdmc:/minute/rednand.ini. If you have an older redNAND (de_Fuse 0.7 or so), you can use the following INI file:
```
[partitions]
slccmpt=true
slc=true
mlc=true
[scfm]
disable=false
allow_sys=false
[disable_encryption]
mlc=false
```
GPU OVERCLOCKING
---------------------
minute has experimental support for overclocking (or underclocking) the Radeon GPU by specifying PLL parameters in the ini file. **This can potentially harm your Wii U if you don't check your math!** Or your Wii U will just not boot into the menu or may otherwise become unstable in normal usage.
Manual PLL overrides overview:
```
div_select = ?
clkV is spread spectrum related maybe?
clkS is clock source...?
clkXtal = 27MHz
clkO = clkO0Div, clkO1Div, or clkO2Div (based on div_select)
clkF = (clkFMsb << 16) | (clkFLsb << 1)
freqMhz = clkXtal * (clkF/0x10000) / (clkR+1) / (clkO/2)
```
Example unmodified INI values:
```
; Defaults:
; GPU = 544.999878MHz
; 27 * (0x285ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_r = 0x0
gpu_clk_f = 0x285ED0
gpu_clk_s = 0x1C2
gpu_clk_v = 0x7
gpu_clk_o_0div = 0x4
gpu_clk_o_1div = 0x4
gpu_clk_o_2div = 0x0
```
Example overclock:
```
; GPU = 679.999878MHz (1.25x)
; 27 * (0x325ED0 / 0x10000) / (0+1) / (0x4/2)
[clocks]
gpu_clk_f = 0x325ED0
```
The GPU gets unstable at around 770MHz in my testing.
TROUBLESHOOTING
---------------
You will want a serial console connected for this, see above for help.
If the console LED stays red after pressing the power button, and then boots normally after ~30s, this means that either de_Fuse failed to detect success, or the SD card was invalid.
A successful de_Fuse looks like this:
```
[pico] Changed state: WIIU_STATE_POWERED_OFF -> WIIU_STATE_NEEDS_DEFUSE
Starting... 1152
Results:
Winner! 0xfb80
01
02
03
04
05
08
09
0a
0b
0c
0d
0e
13
14
15
18
1b
1c
1d
1e
1f
25
88
89
8a
...
```
- If the initial lines are not 01, 02, 03, ..., this means the DEBUG GPIOs are not wired correctly.
- If the final line is 0x1E and the error code is 0x00, that is an invalid SD card. Invalid SD cards seem to hang boot0.
- If the final line is 0x25, and 1e and 1f are in the output, this means the SD card was valid, but not flashed correctly (or otherwise failed to read).
- If the final line is 0x25, and 1e and 1f are NOT in the output, this means that the EXI CLK wire is not connected correctly, or there is an issue with the EXI data wire.
- A brief purple flash means that the custom boot1 has loaded, and glitching was successful. If it stays solid purple, then it has loaded fw.img from the SD card.
- A brief purple flash followed by a blinking orange LED means that fw.img was not found on the SD card root, or the SD card failed to mount.
Alright, trying to complete the older projects before starting any new ones. I finally got this system put back together so I could plug it in and start figuring out Defuse. I opted to make the cables long enough so I could wrap them around and place the Raspberry Pi Pico on the front of the console. May not have been the most ideal way of doing this, but it worked for my situation and allows me to easily plug this into a computer.
With too many components that could slip all over the place I decided to partially reassembly the console. This may not be necessary to do in all circumstances, especially if you don't have to move the console.
I will admit that attaching the Pico to the back of the console is likely an easier method as it requires much short wires to connect it. Might pose some challenges if you need to connect to a PC for debugging.
IMG_8877.JPG
Unfortunately I am not able to move forward because the SD Card doesn't appear to be detected. The instructions for Defuse state that you should use a 1GB card. That isn't possible for me as I do not have one that small. I did format a 1GB partition on a 32GB SD Card but it doesn't seem to like that.
When I power the console on it, the LED turns Red and stays red, which I believe indicates that the SD Card is invalid. If I remove the SD Card while the console is still powered on the LED immediately starts blinking blue. I am not able to find any mention of this online to determine what it means, but it may just means the console is looking for an SD card because when I insert the card it goes back to the Red LED.
As for what I see using Putty, its in the image below. I don't know what this specific Error indicates...
Putty Error.JPG
however I know Defuse is working because the serial console will the following message when the Wii U console is powered off:
PuttyWiiUnopower.JPG
Based on everything I can find (there isn't much documentation I can find for Defuse) the mod requires a 1GB SD Card to be successful. I don't know if this is entirely true as I am unable to locate anyone who has used Defuse and disclosed the SD Card/Size they used with it.
I don't think its going to be possible for me to locate a 1GB SD Card in 2024. These things just don't exist and even the 2nd hand market doesn't seem to have them, which isn't surprising because they have no value and most of them likely end up being tossed in the trash. Well here is to another day. Tomorrow I will double check all the solder points just to be certain Defuse is installed properly. If it is, I can only assume at this point the problem is an invalid SD Card.
Double checked Defuse. Everything is soldered correctly. I am going to have to find a 1GB SD Card for further testing. Unfortunately all the ones I have located today were SDHC cards, which do not work. :'(
I purchased a 1GB SD Card that should work for this. Will continue diagnosing this console when it arrives.
Defuse is apparently very picky about the SD Card used with it. I didn't think I would have this much difficulty finding one. I have tried 4 or 5 1GB SD Cards and none of them worked. The readout is that defuse doesn't detect a valid SD Card. Well I came across this SD Card today.
SDCard.JPG
If an official Nintendo one from the Wii won't work then I am not sure what to do. A part of me has doubts about this one working because the same manufacturer (SanDisk) produced several of the other cards I tried that failed to work. Well only one way to find out, give it a try and hope for the best.
YES!!! We are in!!!!! Defuse is now working.
Defuse working.JPG
Alright so it appears not to load the otp.bin file. Which is a bit concerning because I have it on the SD Card. I guess this is where the troubleshooting starts and I see if I can identify what the problem is. Unfortunately Defuse has very little documentation online and I am unable to find much reference to anything that is happening on screen.
A couple thinks that stand out to me are the sdcard: doesn't support SDR25, staying at SDR12. Also the fact that the crypto bytes of the OTP loaded might mean that the otp is somehow corrupt on this console. Just throwing out some guesses as I am not 100% sure what I am looking at here. You can see this in the picture below for reference.
Defuse Loaded.JPG
I guess at this point I can try dumping the OTP.Bin from the console again just to be sure the one I have isn't corrupt. Since Minute is loading I can actually Dump OTP Via PRSHhax.
If you are using the Dump otp.bin via PRSHhax from the "Backup and Restore" menu a successful dump will look like this from the serial console:
OTP dumped.png
Alright I Dumped the OTP.bin via PRSHhax and now Defuse automatically loads into the Minute menu, which means the other OTP.bin I had must have been corrupt. When the OTP.bin is working properly it loads directly into the minute menu, for those interested in knowing if there is a readout that tells you it successfully loaded, there is from the Serial Console and it looks like this:
otpbin loaded.png
Alright an update to this console. I was able to get ISFShax installed on the console.
I installed a 64GB SD Card and noticed that it isn't detecting it. When I attempt to erase the MLC, it detects an SD Card but it has the wrong size, its detecting 8GB when the card is a 64GB and then I just get "resetting due to timeout" error. This means the SD card isn't accessible, but also its reporting the incorrect size.
Upon disassembling the console to inspect the NAND-AID I noticed something strange. The NAND-AID wasn't sitting flush to the Wii U PCB. It should be mentioned that I was only able to see this using a Microscope. To the naked eye everything looked good.
I grabbed my hot air station and removed the SD Card Slot and once it was out of the way it was obvious where the failure was. The Ground pad on the NAND-AID had failed. This reminded me that this was the console I had serious trouble removing the old solder from the Wii U ground pad. Apparently I didn't do a good enough job.
So this time I went ahead and removed all the solder from the board, right down to the pad and added all new solder. NAND-AID is now sitting flush with the board and has a strong solder joint to the ground pad.
I will get an SD Card Slot installed tomorrow and get everything reassembled and tested to see if the SD Card shows up this time.
I replaced the SD Card Slot and the SD Card does show up properly now, but I still get the resetting due to timeout error when trying to erase the MLC. I am out of ideas at this point....
I dumped the log files and have attached them. Log file 13 is the most recent, but it would appear to be an old log from when I initially repaired this console.