Hardware How I fixed 160-0103 system memory error

[Carnage]

Stop this, please. We're over that already. In other words: Both, me and @Voultar did mistakes. Now it's time to team up to get the best end result for the community.

Great to hear that!

I would like to help with recovering these NANDs. I was going to design an interposer that installs over the BGA site of a removed eMMC that has an SD-Card slot so that the repair is much, much easier.

That's awesome!, really awesome, that would make a much better video, where everything could be addressed.
Anyway I realized no one has come yet to welcome you to this forum, so
Welcome to the forum (Wii-U), there are some trolls but it's really an small and nice community, enjoy your stay
There is a lot of more info on discord if you like to join:
https://discord.gg/geY4G2NZK9
https://discord.com/invite/bZ2rep2

 

[Razor83]

And for the interposer: removing the eMMC is probably outside the skill of many people, including me. especially with the SLC on the other side, which could fall off. Maybe a interposer which goes over the resistors before the eMMC would be easier for most people.

I agree with this idea - much better to have an interposer over the resistors and just cut the clock trace to disable the original eMMC chip. Otherwise I imagine many inexperienced people might attempt to remove the BGA eMMC chip with a hot air gun and destroy their console in the process.

 

[SDIO]

If anyone here on this forum has a Wii-U with a busted eMMC. I will be happy to purchase it from them.

@fadafwet would be a candidate: https://gbatemp.net/threads/corrupted-wiiu-nand-or-not.628159/
@rrthrow maybe this is your chance, but we would need to take a look at your logs first.
And this Matt Faul from twitter also has a good chance to have a faulty eMMC, but his corruption didn't look that bad:
Also keep in mind: after I erased my eMMC completely and rewrote it, it seemed fine again. If the corruption is only in the data, but not in the FTL metdata you might temporarily away with just rewriting the bad data. One thing you could check for is doing multiple dumps and check for random bits.

I can help design hardware that will make replacing the memory much, much easier.

I also thought about designing such an interposer, but at that time it didn't seem like there would be too much demand for that and besides that I am not sure if I could measure good enough so that it will fit in the end. So I would be glad if you did one, you have more experience thare and it would make the process a whole lot easier.
Maybe also add bigger pads or a connector which would allow to access the old eMMC from a PC to have an easy way to get a dump.

Again, I don't doubt that it's happening, I just believe that it's been terribly exaggerated by content creators and that a lot of these "bricks" are 100% recoverable.

if it is caused by a power loss or CHBC sure, but if it is caused by a bad chip the only real fix is to replace it from my perspective.

I know of a person who has one - supposedly started throwing the -103 error after trying to install Wind Waker, then started crashing at the WiiU screen. I asked them about it today, and the console now doesn't boot at all - gives a black screen. They would not have a working NAND backup, though - so I'm not sure if their console would be of any use.

This sounds exactly like what happened to my console. With todays knowledge about the SLC cache and todays tools (UDPIH) there is a good chance to recover it even without backup and without soldering to the SLC. If the eMMC is still readable, but read only, like mine was, he could get a good enough dump through hardware. If that dump then at least can boot to an error message it could be fixed with udpih.

having the option to relatively easily replace them with removable storage would be very nice.

But please keep in mind that it is not "truly removable" as the content is married to the SLC.

This is my thought as well. The Wii U is designed very well. It doesn't get hot even after hours of gameplay taxing the CPU/GPU/RAM.

I guess that's more to the fact, that the Wii U isn't pushing any limits hardware wise and therfore has enough "proven" technologies and margins.

 

[Voultar]

This is the part that's confusing for me. As we all are trying to address this issue at hand here sharing findings, however As you never came into the forum asking for information, nor joined discord, where is a lot of more info given by both @V10lator and @GaryOderNichts and then taking screenshot of @V10lator and calling him:
View attachment 359931
The first thing that came to my mind was
What an AS***LE

Then I saw that video title that looks clearly like "clickbait" (come on, you are claiming a fix for $8). I watched the video and on the first minutes you clearly stated that it was a "rough and poorly edited video".
I mean. What's the rush? Why rush on making a video where you had so little data about. I then browser through your channel expecting rushed and clickbait videos, and to my surprise you have only made 4 videos in the past 6 months, and none of them were rushed.
So after all of that my impression change from "What an AS***LE" to "He seems like a nice and knowledge guy, Why did that escalated so quickly?"
It gave me the same vibes back (on the Wii scene) when Marcan and Waninkoko where working on a Region Changer, and the latter rushed that release, it ended with a lot of bricked Wiis.
And to answer your question "Even if it's just 20% or 35% of consoles, it's worth it, no?"
No, it's not worth it, as it is rushed and people will get to the wrong conclusion


That's awesome!, really awesome, that would make a much better video, where everything could be addressed.
Anyway I realized no one has come yet to welcome you to this forum, so
Welcome to the forum (Wii-U), there are some trolls but it's really an small and nice community, enjoy your stay
There is a lot of more info on discord if you like to join:
https://discord.gg/geY4G2NZK9
https://discord.com/invite/bZ2rep2

I recognize that this probably isn't the place for me. I'm not interested in keeping information suspended in a vacuum. I'm not really interested in discussing this any further.

See you all!

 

[skawo]

But please keep in mind that it is not "truly removable" as the content is married to the SLC.

Would you happen to know if in case of trying to power the console after the SD disconnecting, would the SLC get desynced?

Also, how exactly do you program the SD card with your nand dump? I've tried to look for this information but I'm not entirely sure - do you just extract the image contents and plop them over onto the SD root, or something?

 

[SDIO]

I agree with this idea - much better to have an interposer over the resistors and just cut the clock trace to disable the original eMMC chip. Otherwise I imagine many inexperienced people might attempt to remove the BGA eMMC chip with a hot air gun and destroy their console in the process.

If the resistors get removed, it shouldn't matter if the clock is still connected. Cutting the clock would still be necessary to do the dump through a PC or Raspberry.

@Carnage I feel a similar way, but I don't think this thread is the right place to discuss that, if it should even discussed at all. I want to keep it here to the technical facts. And yes I know even I discussed it here, but I think it's enough.

Post automatically merged: Mar 18, 2023

Would you happen to know if in case of trying to power the console after the SD disconnecting, would the SLC get desynced?

No I don't think so. We disconnect the eMMC all the time for a dump through hardware and as far as I know it never casued problems. I think Nintendo was smart enough to handle cases where writes fail. It would still be annoying to have to open the console back up, so I will put a little tape over it.

Also, how exactly do you program the SD card with your nand dump? I've tried to look for this information but I'm not entirely sure - do you just extract the image contents and plop them over onto the SD root, or something?

Yes in linux that would be the dd command. Under Windows it would be something like win32 Imager. The dd command is nicer though, as it let's you skip zeros (with conv=sparse) and if the SD card was trimmed before it gives the controller in the SD card a few more spare blocks, which could improve write performance and wear leveling a little bit.

 

[V10lator]

a few of the systems that I've fixed that were generating 160-0101 and 160-0103 are untouched, unmodded systems. One system comes from someone who was playing Zelda WindWaker HD and lost power.

Could you share the logs of these consoles with us, please? So at best the whole log folders.
Beside that "loosing power" sounds like data corruption thanks to... Well, a brownout. As MLC keeps multiple bits in a single cell a WW HD (save file?) corruption might corrupt completely unrelated things, like the Wii U menu.

I believe that a lot of people can revive their systems by simply recaching in the coldboot title ID that's either getting corrupted by CBHC or some other means.

I fully agree on this.

As we all are trying to address this issue at hand here sharing findings, however As you never came into the forum asking for information, nor joined discord

Stop this, please. We're over that already. In other words: Both, me and @Voultar did mistakes. Now it's time to team up to get the best end result for the community.

 

[SDIO]

As MLC keeps multiple bits in a single cell a WW HD (save file?) corruption might corrupt completely unrelated things, like the Wii U menu.

I am not sure about that. I would expect MLC (or it's controller) to keep all the bits of a cell in the same LBA. Distributing it over multipe LBAs would negativly impact the performance and would cause more P/E cycles. So I don't see why they should implement it that way.

 

[Voultar]

So, one of these systems had 160-0101 error, it was not a CBHC system or modded in any way. The person who I purchased it from said they were playing WindWaker when the power went out. When they tried turning the system back on, 160-0101 would come up.

It doesn't seem to me that 160-0101 is ONLY caused by a botched softmod install where the title id pointer gets thrashed.

 

[V10lator]

I would expect MLC (or it's controller) to keep all the bits of a cell in the same LBA. Distributing it over multipe LBAs would negativly impact the performance and would cause more P/E cycles.

Normally I would fully agree but with the Wii Us properitary file system and that SLC cache, which both are things we don't really understand, who knows what magic is going on behind the scenes?

The person who I purchased it from said they were playing WindWaker when the power went out. When they tried turning the system back on, 160-0101 would come up.

I'll ask again: Could you share the logs of this system, please? Just see what I Just replies to @SDIO: There are things we don't understand yet, so inspecting logs helps a lot. Well, it might not help this special console (which seems to be fixed already anyway) but it might help us to get a better understanding about the properitary secrets of the Wii Us storage.

 

[rcpd]

@Voultar please don’t let a few idiots keep you from the forums. You are clearly trying to help and we appreciate that immensely. Any help is better than zero help, and I for one certainly appreciate your effort to discover the root cause.

Having said that, is it possible you both are correct and that the NAND is actually corrupt and what you do to it does help? Perhaps the units you’ve acquired haven’t become corrupt bad enough to die completely yet, as several people here have done exactly this to revive their units temporarily but some have had the issue return worse. So I’m curious to see you continue to play with them and see if the error comes back. Or, perhaps you did just find several units with bad coldboot titles.

As requested, I would also like to read the logs of the units you’ve fixed.

 

[V10lator]

@Voultar please don’t let a few idiots keep you from the forums. You are clearly trying to help and we appreciate that immensely.

I fully agree. @Voultar sorry again for me overreacting before knowing you. I know I did a hard mistakes and I am ashamed for this. Please stay with us.

In case you dislike GBATemp there are also Discord servers you could hop on and who are better moderated than this forum.

 

[rcpd]

I fully agree. @Voultar sorry again for me overreacting before knowing you. I know I did a hard mistakes and I am ashamed for this. Please stay with us.

In case you dislike GBATemp there are also Discord servers you could hop on and who are better moderated than this forum.

Would you mind just posting the link? I'm very new to Discord, but I wouldn't mind hanging out and learning a few things.

 

[V10lator]

Would you mind just posting the link?

Sure thing:
4TU: https://discordapp.com/invite/F2PKpEj
Nintendo Homebrew: https://discord.gg/C29hYvh
Gary's: https://discord.gg/geY4G2NZK9
NUSspli: https://discord.gg/B8ZBd6mrnV
...there are more servers, like Aroma Discord, but I'm just advertising servers I'm active at.

 

[skawo]

The whole SLC thing really changes this from what looks to be some fairly trivial soldering to a nail biter. After reading through everything again, I'm still not entirely sure of what would be the safest method to get a proper dump that will definitely work when popped onto an SD without needing to reprogram the SLC.

Wish I had a spare WiiU to try it on first, but as is, might wait until there's more info about this and more people've tried it :/

 

[rcpd]

Sure thing:
4TU: https://discordapp.com/invite/F2PKpEj
Nintendo Homebrew: https://discord.gg/C29hYvh
Gary's: https://discord.gg/geY4G2NZK9
NUSspli: https://discord.gg/B8ZBd6mrnV
...there are more servers, like Aroma Discord, but I'm Just advertising servers I'm active.

My username is the same there. I'll just lurk for a while and learn some stuff. I'm sure I'll have questions but I'm pretty good about reading previous chats to get caught up so I'm not asking the same questions that have been asked over and over.

 

[SDIO]

Yes I would be very interested in the logs annd the system.xml. if rewriting the CB title id and with that the system.xml I would like to understand whats happening there. It sounds a little bit scary that the system.xml is corrupting seemingly on it's own.

Post automatically merged: Mar 18, 2023

The whole SLC thing really changes this from what looks to be some fairly trivial soldering to a nail biter. After reading through everything again, I'm still not entirely sure of what would be the safest method to get a proper dump that will definitely work when popped onto an SD without needing to reprogram the SLC.

If you don't want to reflash the SLC the only MLC you can use is the current one. You would neet to clone it to the SD and make sure that after that point you are only using the SD.
If the copy turns out to be to corrupted to fully boot, then you need UDPIH to fix it.

We are currently discussing creating a tool which would allow you to flash back an backup with software. In that case you may have luck booting with a mismatching MLC to then flash back a matching SLC + MLC combo.

But I would definitly recommend to colne the current eMMC if you don't want to solder to the SLC.

Wish I had a spare WiiU to try it on first, but as is, might wait until there's more info about this and more people've tried it :/

The Wii U to try this is on the way to me. But I will still try to get the NAND dumper for the recovery menu ready first. So that just in case it goes wrong I have a working combo. But my plan is to do this without having to solder to the SLC or flashing it by other means.

 

[Voultar]

Let me ask a basic question.

Let's say that the MLC is totally gone (eMMC) but the SLC, OTP and SEEPROM are all intact and have been dumped.

We have the crypto keys, we have the vWii data and we have the Wii-U system partition; What's keeping us from taking this data and rebuilding the MLC partition onto a new memory module? The MLC to my understanding is just the game/save storage location.

 

[SDIO]

we don't know enough about the Wii U file system to create a new one from scratch or to reencrypt one from a different Wii U. The encryption is interwoven with the file system and uses IVs which are stored inside the FS. So it's not like a luks with the fs on top of it. Thats also why the wfs tools are limeted, when it comes to write access. @kooldev (the creator of wfs-tools) wrote some time ago that he is working on reverse engineering the missing fields and sections of the file system, but I haven't heard anything about that.

One other way I could Imagine would be to use the format usb device function of a working Wii U to create a new file system and then mount it there to fill it. But for that we would need to trick the OS into using the mlc key (and I think IV) from the broken Wii U. And I don't know enough of the System to pull such a thing of, but others might be, but thats probably something you would ask in these discord servers. I thought it might be possible to change the key in the seeprom, but after a quick look into it, I concluded that it is not that easy because of the IV, which I can't control with the seeprom.

But we would still have the problem with the SLC cache. I couldn't find any information on that and we would also need to reset it. Maybe it's enough to just delete that file but I didn't try yet. That would be something to test in the firmware emulator, but I couldn't get it working yet.

So in theory it would be possible, but practically we don't have the tools yet, because more reverse engineering is needed.

 

[V10lator]

What's keeping us from taking this data and rebuilding the MLC partition onto a new memory module?

That's a damn good question. I think (@Maschell @GaryOderNichts @QuarkTheAwesome or anyone else: Correct me If I'm wrong, please) the most important issue is that the filesystem on the MLC isn't understood good enough to rebuild it (PC tools are able to read with the limitted knowledge but not to write and esp. not to format).

Next issue would be the SLC cache. With a fully intact, freshly created FS we might be able to just delete the cache so the Wii U rebuilds it but that's Just guesswork on my end: We don't know how this cache works exactly.

//EDIT: You ninjad me and you seem to have way more knowledge about the FS than me. Anyway:

And I don't know enough of the System to pull such a thing of

In the worst case (would need to look this up) some OTP key is involved in this. Now OTP is burned into the CPU (really burned: eFuses) so can't be changed.