Just a question, but how did you backup your NAND? Via the Aroma NAND Dumper payload? Or the .elf homebrew?
@CrazySquid I did via Aroma NAND Dumper. The thing is that I don't remember playing with the console before doing the Dump.
when I did my backups Aroma didn't exist. I think I launchen the payload directly via the browser. But there is also the possibility I launched the dumper through Haxchi and HBL . But it shouldn't matter anyway.
Yep, I was just wondering if maybe they used this app:
https://github.com/koolkdev/wiiu-nanddumper/releases
But if he got a perfect NAND Dump from Aroma, then I guess it's the same. I will use my console later on and dump it via Aroma (Will have to reboot to use the PayloadLoader), keeping MLC usage to a minimum so I avoid writing to the SLC cache (I'm not sure how it works, but I guess that if it has low writes to the MLC, then the SLC cache is not used that muc, which should help giving a NAND backup without errors).
Also, sorry if I'm being a bit tiresome with all of this! But I believe I already have the info I need to handle this on my own.
Thanks guys!
Managed to get proper MLC, SLC and SLCCMPT backups with zero errors! Extracted MLC is 717MB.
I used a slow formating for my 64GB SDCard with a 32k cluster, used the Aroma NAND Dumper payload. Before that I used FTPiiU to manually dump my whole MLC from the console (So, the files there gets read, not sure if this actually impacts the SLC cache, but I did just to try).
After that, I used wupserver with the flush_mlc() command. And finally, used the Wii U opening some apps for a few time, and rebooting a few times as well.
Then, went for the backup part, dumped all... and got the perfect dump done. No retries were shown in the GamePad, so everything is good now, I leave this if it's useful for someone out there, thanks guys
I wouldn't recommend slow formatting SD cards. It has no advantage and only uses up P/E cycles and might make it even slower. (now every block was written to so the controller has less erased pages to play with.
If you use FTPIiiU it should use the cache. But I am not sure how the Wii U decides what to put in the cache. Because with the such a small cache (only 128MB) and huge game files I wouldn't expect a simple LRU algorithm to work well.
@CrazySquid if you read everything with FTPiiU anyway and extracted the mlc backup you could compare them to see if it is really the same. But thats not really necessary, just to see if the tools really work as we expect them. But if you already deleted it, don't waste your time with that.
If you use FTPIiiU it should use the cache. But I am not sure how the Wii U decides what to put in the cache. Because with the such a small cache (only 128MB) and huge game files I wouldn't expect a simple LRU algorithm to work well.
@CrazySquid if you read everything with FTPiiU anyway and extracted the mlc backup you could compare them to see if it is really the same. But thats not really necessary, just to see if the tools really work as we expect them. But if you already deleted it, don't waste your time with that.
Ah, you are right. I was aware of the slow formatting rewritting with zeroes all the SDCard sectors, I think I have read somewhere that a slow formatting was recommended for checking bad sectors, so I used that. Then they are written with zeroes, and then apply the filesystem on top of that, making a full format.
I just did it to be completely sure that the SDCard was in good shape (also forgot to say that I did run chkdsk on it, and it showed no errors, so once I was sure that everything was good I then started using the SDCard again with the U.
But yeah, I believe that most of that was unnecesary, I was a bit OCD right there lol, next time will just check with chkdsk and that's it
Also yep, checked both the FTPiiU dump and the NAND Dumper MLC dump, and both seems to be equal (same size, both are 717MB).
Compared both using WinMerge, It is expected for me for the data to have a few differences at the binary level between both dumps since when dumping with FTPiiU (before making the full backup with NAND Dumper), I gave my Wii U a bit of use (opened a few apps and moved stuff around the menu that may have affected the barista files and other things). But I think both dumps are correct, there are not missing files between both and when I opened files to see the difference between them, both seemed consistent to the naked eye (I mean, I don't understand what it says of course, but it doesn't seem like there is corruption in data just a few differences, but it's mostly the same)
So even if there is a few differences in the "usr save" part of the MLC (all system apps appears to be identical at the binary level, same for the rest of the memory) I believe that both the FTPiiU dump and NAND dumper dump were successful, with the difference of them being the Wii U being used in between the dumps.
Last edited by CrazySquid,
fully agree on that.
@skawo you can find a diagram by the user nino in the original German thread: Brick nach Speicherfehler
Last edited by SDIO,
- Joined
- Aug 11, 2007
- Messages
- 1,754
- Trophies
- 1
- Location
- North West England
- Website
- youtube.com
- XP
- 1,560
- Country
Voultar, who last week was looking for WiiUs with this error code, managed to get hold of one and fix it within a few hours... That's fast.
He believes that they may all be fixable without and soldering or intrusive works. However, that's subject to him testing on various other consoles of course.
Voultar WiiU Fixed Thread
He believes that they may all be fixable without and soldering or intrusive works. However, that's subject to him testing on various other consoles of course.
Voultar WiiU Fixed Thread
Based on the logs shared in the thread, it just seems like a CBHC bricked console to me.
He also said it's a Toshiba and that the speculation supposedly that Samsung eMMC is problematic. But from my understanding Samsung was pretty solid in the Wii U.
If it was really corruption caused by a bad eMMC this fix is probably just temporary. Just like I got my Wii U booted on the eMMC again before it failed for good.
I guess we have to wait for more details.
If it was really corruption caused by a bad eMMC this fix is probably just temporary. Just like I got my Wii U booted on the eMMC again before it failed for good.
I guess we have to wait for more details.
@ghjfdtg fully agree. I like his videos but this paragraph really buggers me:
I bough another Wii U with "MEDIA ERROR" and I have another Wii U with an unknown Fault lying around.
With MEDIA ERROR the eMMC literally says that it is bad. And I had my eMMC return random data before dying and he claims it can be solved in software.
I am confident I could get a "MEDIA ERROR" console to boot again on it's original eMMC, but that would only be a temporary fix.
When the MEDIA ERROR console arrives, I can take a look at the CID, which will give us another Datapoint
He has one console and thinks he knows better than everyone else. Like he is the first one to even look at the logs.
I bough another Wii U with "MEDIA ERROR" and I have another Wii U with an unknown Fault lying around.
With MEDIA ERROR the eMMC literally says that it is bad. And I had my eMMC return random data before dying and he claims it can be solved in software.
I am confident I could get a "MEDIA ERROR" console to boot again on it's original eMMC, but that would only be a temporary fix.
When the MEDIA ERROR console arrives, I can take a look at the CID, which will give us another Datapoint
I don't think that I know everything about this, nor do I think I'm the first person to look at a log dump. Why would you say something so obtusely ignorant? I'm just looking into a problem and conducting my own analysis. I now remember why so many people have abandoned these forums because of toxic shit like this.
The problem here is that you literally announced that you believe all consoles displaying the issue are easily fixable after seemingly only seeing _one_ (?) of them, and you even plan to quickly make a video about it. I know you said you still needed to see more consoles, but that's precisely the thing - you shouldn't proclaim such general statements until you have such data.
Rushing out to announce something prematurely is one of the most common ways misinformation is created, and it is one of the very things you're accusing the journalists of doing.
Rushing out to announce something prematurely is one of the most common ways misinformation is created, and it is one of the very things you're accusing the journalists of doing.
I made it absolutely crystal clear that what my current beliefs are might not necessarily represent reality. I'm not representing my findings as the beat all, cure all solution to the MYRIAD of reasons and explanations for why a Wii-U can brick.
I'm refuting the erroneous claims that because of a tiny thread with 30 people complaining about their Wii Us being busted that there's a memory epidemic stirring about. At least I'm investigating this and exploring possibilities which is certainly more than what I've seen, elsewhere in media. Not every 160-0101 or 160-0103 might be a complete death sentence.
Last edited by Voultar,
Sorry, I saw the original post and no "corrections" after, since I don't follow nor plan to follow anyone on twitter.
The correction was made 8 hours after the original post. 8 hours during which people have read your bold announcement about all consoles being fixable. Since you felt a correction had to be made, even you yourself can see how your original post clearly misled into people thinking something you didn't actually want to say.
The correction was made 8 hours after the original post. 8 hours during which people have read your bold announcement about all consoles being fixable. Since you felt a correction had to be made, even you yourself can see how your original post clearly misled into people thinking something you didn't actually want to say.
