Wii U Stuck on Logo

[ChefVortivask]

Hello everyone,

First time poster here. I decided to make this post since I am having issues with my Wii U. Currently, my Wii U will not boot up to the main menu. It stays stuck on the Wii U logo indefinitely.

There are a few things to note about my console. The console is the black 32 gb model. I believe it was bought during the 2012 holiday season (release) as we were expecting to play Pikmin 3 before it got delayed. The system has never been modded in any fashion. It was not the most heavily played console, and I can't even give a good estimate of when it was last used (at least more than 3 years).

I have already tried doing the UDPIH, however it does not seem to be working. When using the second recovery menu, I get a white screen with some blue lines (see attached image). I believe this is similar to what @fadafwet described in his post. I was able to get the logs from the system, which I have attached to this post. Any idea what the issue may be and how to fix it? Any help would be much appreciated.

 

[ChefVortivask]

It seems you are right. I came back to it and it was done. I've attached mlc.log as a zipped folder. It looks like there are a lot of errors.

 

[SDIO]

Yes looks like your eMMC is corrupted. Also it's a Hynix from 2012 (the risk group).

Post automatically merged: Apr 9, 2023

So the eMMC should be replaced. Here I wrote a thread about how I did it: https://gbatemp.net/threads/how-i-fixed-160-0103-system-memory-error.626448/

The best thing would be to read out the current eMMC through hardware and clone it to an SD card, that you would solde rin place. If you didn't turn on your wii U since the dump you can in theory skip the read out of the current eMMC trough Hardware and instead use the Backup.But I still recommend the dump through Hardware, as I don't trust the dumper 100% yet.

 

[ChefVortivask]

Yes looks like your eMMC is corrupted. Also it's a Hynix from 2012 (the risk group).

Post automatically merged: Apr 9, 2023

So the eMMC should be replaced. Here I wrote a thread about how I did it: https://gbatemp.net/threads/how-i-fixed-160-0103-system-memory-error.626448/

The best thing would be to read out the current eMMC through hardware and clone it to an SD card, that you would solde rin place. If you didn't turn on your wii U since the dump you can in theory skip the read out of the current eMMC trough Hardware and instead use the Backup.But I still recommend the dump through Hardware, as I don't trust the dumper 100% yet.

I'm willing to wait on @Voultar s board to replace the eMMC. I haven't turned on the Wii U since the dump but if I understand correctly, I shouldn't turn it on until the eMMC is replaced. Also, I read through your full post, and I'm confused as to how read out the current eMMC through hardware. Could you elaborate on this?

 

[V10lator]

@ChefVortivask The whole point of keeping the Wii U powered off is so you don't need to do a hardware dump.

What you need to do next is to write the software dump you made onto a 32 GB SD card (write it raw, not as a file, and do not use bigger or smaller cards), then use Voultars board to replace the eMMC with the card and that's it.
In case you power the Wii U on before that the SLC cache and the content of your software dump will missmatch, so it won't work.

 

[ChefVortivask]

@ChefVortivask The whole point of keeping the Wii U powered off is so you don't need to do a hardware dump.

What you need to do next is to write the software dump you made onto a 32 GB SD card (write it raw, not as a file, and do not use bigger or smaller cards), then use Voultars board to replace the eMMC with the card and that's it.
In case you power the Wii U on before that the SLC cache and the content of your software dump will missmatch, so it won't work.

I've unplugged the Wii U to make extra sure that it does not get powered on again. I'll need to get a 32 gb SD card for the mod. I've already read posts that say I need an SDHC. Any recommendations on cards?

 

[V10lator]

Any recommendations on cards?

I'm using a SanDisk Max Endurance. Saw another user using a SanDisk High Endurance. I guess @SDIO uses a normal SanDisk card but not sure.
My personal choice is just to prelong the lifetime for as much as possible before I need to replace the card again but to be fair any 32 GB card should do it.

 

[SDIO]

Here is the the description of the hardware dump: https://gbatemp.net/threads/successfully-dumped-wiiu-emmc-nand-with-hardmod.457165/
Instead of the of that SD adapter thing and a Cardreader I used an raspberry pi. There I could just connect it to the gpios instead and it gives more control in case something goes wrong

I am using a Sandisk Ultra, because that's what I had lying around and I trust it more then the Samsung I had lying around. If the SD card dies in a way that it is not readable anymore, then you have a problem. So reliability should be the top priority. After that comes access time. Bandwhich doesn't matter too much, as it is limited by the bus to 25MB/s anyway.

 

[ChefVortivask]

So it seems the hardmod dump might be unnecessary? It wouldn't hurt anything, but I can just use the backup I've already dumped?

 

[SDIO]

I still recommend the dump with the hard mod, as we still not fully understand how the slc cache affects the dump done by the method we use in the recovery menu. If you do the SD mod you have done the tricky soldering part required for the hardware dump anyway.
But yeah in theory it would also work with the dump you already have

 

[V10lator]

@SDIO While you're right that we don't really understand the cache your codes do unmount the MLC before dumping, so the content can't change anymore. Also keep in mind that I was able to use a software dump without any issues (except these corrupted folders but they where present on the original eMMC already, so no caching issue).

Also I think a hardware dump copies more than needed (after all we have a 32 MB size difference between soft- and hardware dump). Like I think it copies some chip-specific data which doesn't even belong to the filesystem (some OTP area or something).

 

[ChefVortivask]

I have all my parts in to install the NAND-AID from @Voultar. I do have one question though. Does a trace need to be cut to bypass the original eMMC, or does shorting the DIS jumper take care of that?

 

[SDIO]

You either need to cut the trace or remove the resistors. If you don't cut the trace you need to leave the dis jumper open and also won't be able to dump the eMMC trough hardware.

 

[ChefVortivask]

You either need to cut the trace or remove the resistors. If you don't cut the trace you need to leave the dis jumper open and also won't be able to dump the eMMC trough hardware.

I apologize if this has already been pointed out, but which trace and resistor are you referring to. Also, just so it's clear, if the dis jumper is left open, the trace AND the resistor can remain untouched?

 

[SDIO]

no, you either have to remoe the resitors from the data and cmd line or you have to cut the clk trace between the pads. The goal is to prevent the old emmc from interfering. The goal of the dis jumper is to ground the clk trace on the eMMC side if and only if it is cut. Or alese you would short the entire clk to ground which would also prevent the sdcard from working

 

[ChefVortivask]

no, you either have to remoe the resitors from the data and cmd line or you have to cut the clk trace between the pads. The goal is to prevent the old emmc from interfering. The goal of the dis jumper is to ground the clk trace on the eMMC side if and only if it is cut. Or alese you would short the entire clk to ground which would also prevent the sdcard from working

So based on what you said before and now, cutting the trace is the most straightforward way of doing this when compared to removing the resistors.

 

[ChefVortivask]

@SDIO While you're right that we don't really understand the cache your codes do unmount the MLC before dumping, so the content can't change anymore. Also keep in mind that I was able to use a software dump without any issues (except these corrupted folders but they where present on the original eMMC already, so no caching issue).

Also I think a hardware dump copies more than needed (after all we have a 32 MB size difference between soft- and hardware dump). Like I think it copies some chip-specific data which doesn't even belong to the filesystem (some OTP area or something).

Do I just copy over/transfer the mlc.bin.part files?

 

[SDIO]

On windows you first need to merge the parts into one (with copy /b for example) and then you can use Win32Diskimager to write them to the raw SD card.
Make sure you don't accidentally overwrite something when you try to merge them and also take care they are in the right order

 

[ChefVortivask]

On windows you first need to merge the parts into one (with copy /b for example) and then you can use Win32Diskimager to write them to the raw SD card.
Make sure you don't accidentally overwrite something when you try to merge them and also take care they are in the right order

Thank you. Does the name of the merged file matter?

 

[SDIO]

No, because you write the raw contents to the SD, the metadata like the filename will be lost anyway

 

[ChefVortivask]

Got it. I merged the files in the correct order and am now ready to write the file to the sd card. It did say that writing to a physical device could corrupt the device. Should I just ignore this?