Thanks ;-) What I meant if there is any way to decode year from serial number, which is written on the WiiU itself. It would be useful potentially to get the newest models from online places like eBay, etc.
Why is not having switched on the device for a long time the biggest correlating factor with this problem?
@SDIO I entered panic mode LOL and went to check if my latest DUMP was correct:
It's been a few years since I move everything from NAND to HDD, so my extracted files were less than 800mb
I also went ahead and downloaded your new mdinfo to check the CID
Well I hope with only 800mb used on a 32gb NAND, to last a lot more years (the WiiU it's being on weekly use and when not in use idle but with power for at least the past 4 years)
Last edited by Carnage,
AFAIK it isn't. It's Just a theory started by a single reddit user. All other sources who state this refer this single reddit user as their source of information.
Real world data is still too low to draw a picture.
@Carnage chill, everything is fine. You have a Samsung and not a Hynix and your backup doesn't seem to have any corruption.
Flash has only a limited retention period for the data, the hypothesis is that something was wrong with the 32GB Hynix chips in the launch models to have an especially bad retention time. So the data just fades away, when the console is not used, therefore emerging errors are not detected and not corrected, while they are correctable.
I agree that we should not jump to conclusions to early. Btw my console was also not used for a long time. Everything was fine, when it was stored away, but when I started using it again, I got this error left and right till it completely failed, probably because of corruption in the FTL.
Do we have a sense of what the length of time the device was unused which led to the fault? One month, two months, six months?
I´m a tiramisu user from about 1 year ago... but previusly i used the "Red Nand" method (Emulated Nand from SD Card)... its more secure to come back to the "RedNand" method?
The RedNand method always use the emulated nand from the sd once the starting method its over, but when the WiiU starts this is working with one ds title from the original nand and later when the method its finishined work with the emulated nand.
The RedNand method always use the emulated nand from the sd once the starting method its over, but when the WiiU starts this is working with one ds title from the original nand and later when the method its finishined work with the emulated nand.
@SDIO I have one last question, I know my NAND if fine since when dumping it didn't retry or anything when reading the memory, but when extracting the dump it shows this:
Is this NAND backup good if I wanted to restore it later on? or is all the sys folder corrupted which means this NAND backup will be useless in case I want to flash it? That's the only thing I want to know. Thanks!
Is this NAND backup good if I wanted to restore it later on? or is all the sys folder corrupted which means this NAND backup will be useless in case I want to flash it? That's the only thing I want to know. Thanks!
@CrazySquid Most likely that folder is just cached on SLC, so the MLC corruption is by design and you're fine.
//EDIT: And that's why you need matching MLC and SLC backups. In case of emergency you need to flash both back as SLC cache and MLC need to match.
//EDIT: And that's why you need matching MLC and SLC backups. In case of emergency you need to flash both back as SLC cache and MLC need to match.
Last edited by V10lator,
Am I right in thinking one potential long term solution for this will be to redirect the NAND to an emulated NAND on the SD card or an attached USB device?
A few years
RedNAND wont save you from this problem, as it is most likely the retention time and not the write cycles that are the problem. Any for Red NAND you still need the normal eMMC to boot. I would not advise to use Red Nand
I can't tell if the backup is good, because there is a error there. This could either be due to the SLC cache or a bad dump. What speaks against the SLC cache as an explanation is, that this directory shouldn't be written much to, except if you do an Update.
If you want to be sure use the console a little bit and then do a new backup.
The long term solution is to replace the bad eMMC, if you have bad eMMC. There is really not way around that without an exploit that works earlier in the boot process.
I might be wrong on this but in theory a SLC only boot to redNAND should be possible:
- Change vWii to a boot_info exploiter.
- Boot while holding B: Boot to vWii. Now this exploits boot_info and reboots.
- Boot1 reads the warmoot boot_info: Code execution in boot1.
- From this boot1 code execution boot into redNAND.
Boot0, boot1 and vWii are all on SLC and boot_info is on RAM. The vWii->boot_info->boot1 expoit has been proven to work years ago.
Again: I might be wrong on this, so take it with a grain of salt.
I think I have to read up on this boot_info exploiter. But by the point that the Wii U can communicate with the gamepad it's already running on MLC. So that wouldn't work.
But I wonder if you could move titles from the MLC to the SLC. Then you could maybe move enough to the SLC and change the coldboot title.
But I really don't if the Wii U only looks in the mlc for these titles or it just scans every title directory and has some priories assigned to them.
Maybe I will try it on the weekend but on the other hand I really don't feel like bricking the Wii U again and having to connect all the wires for the SLC again and then wait three hours for it to unbrick if it goes wrong. Maybe I try a game title first...
But I wonder if you could move titles from the MLC to the SLC. Then you could maybe move enough to the SLC and change the coldboot title.
But I really don't if the Wii U only looks in the mlc for these titles or it just scans every title directory and has some priories assigned to them.
Maybe I will try it on the weekend but on the other hand I really don't feel like bricking the Wii U again and having to connect all the wires for the SLC again and then wait three hours for it to unbrick if it goes wrong. Maybe I try a game title first...
Thanks! So, the "proper" way to do the backup would be, say, play with the console an hour, and then reboot the console to boot in the nanddumper payload (vie environmentloader) to do the backup? (I'm using Aroma, maybe it's better to download the .elf nandumper and do it from homebrew launcher in Tiramisu without rebooting?)
I also thought of deleting the SLC cache since I guess it gets rebuilt, but I have a feeling that is not a good idea.
No deleting the SLC cache is not a good idea, it could leave the filesystem corrupted. I also didn't find any way to delete it. FTPiiU everywhere won't delete it (just so you know).
I am not sure when the write cache will be written back. Maybe it's enough to just start a big game from NAND, so everything else gets evicted from the cache. Maybe you have to write something else. I don't know the cach algorithm.
@V10lator I think isfshax would be better suited for your idea then the boot_info exploit.
Maybe it would be bossible to patch IOSU on the fly to swap the SDIO interfaces on the fly. Then the SD card in the sd slot could be a 1:1 replacement, with SLC cache for better performance but with the disadvantage that you don't have an FAT32 SD anymore.
But implementing that would be a lot of work and is beyond my skill level right now.
I am not sure when the write cache will be written back. Maybe it's enough to just start a big game from NAND, so everything else gets evicted from the cache. Maybe you have to write something else. I don't know the cach algorithm.
@V10lator I think isfshax would be better suited for your idea then the boot_info exploit.
Maybe it would be bossible to patch IOSU on the fly to swap the SDIO interfaces on the fly. Then the SD card in the sd slot could be a 1:1 replacement, with SLC cache for better performance but with the disadvantage that you don't have an FAT32 SD anymore.
But implementing that would be a lot of work and is beyond my skill level right now.
Hm... I remember that FTPiiU doesn't show the cache in earlier versions, but the Aroma plugin shows it now, but yeah, I will probably let it be, I don't fully know how it works, so I will not mess with it.
I guess I will just try again but this time playing a bit with the console, rebooting and then loading the nanddumper payload.
...or maybe wait for an update to the NAND dumper that flushes the SLC cache before doing the backup or whatever.
