Stupid question maybe already answered but I'm not a tech guy. Is a bad nand chip completely replaceable with a better one and then rewrite everything to slc, new mmc etc using a previous full dump?
If it comes to that and we need to replace the eMMC with an SD card, are there any read/write speed bottlenecks that should be taken into consideration?
I was looking at high endurance cards that can sustain many more writes from SanDisk and Samsung and both are about 100/30MB/s, are those fast enough?
I was looking at high endurance cards that can sustain many more writes from SanDisk and Samsung and both are about 100/30MB/s, are those fast enough?
By default after power on the lines of the eMMC should be in open-drain mode so they won't interfere much if at all. Source:
"EMBEDDED MULTIMEDIACARD(e•MMC) e•MMC/CARD PRODUCT STANDARD"
You can search for "JESD84-B51.pdf". Newer versions than this are paywalled unfortunately.
edit:
If you cut the clock line the eMMC will never initialize and won't come out of open-drain mode.
Last edited by ghjfdtg,
Great
Would there be any potential speed increase in using a faster card, or is the console bandwidth limited?
Limitted. Also pretty sure it's less than 100 MB/s (the chips might top out at that but the bus and stuff seems to be slower, more like around 26 MB/s).
did you dump it with your PC ? can you show me how ? i dont have a big enough sd card for the moment
Nah, unfortunately you have dump the NAND on the WiiU to SD. Screenshot there just shows the extraction process.
I had to get a big enough SD first, as well.
I had to get a big enough SD first, as well.
i've finally extracted the logs. i actually did it both ways... anyway, not sure how best to identify issues there are a ton of logs to sort through.
actually, looks like 24.log is from yesterday:
00:00:00:992: MCP: life time number of fatal errors - 322
I pasted the first portion of the log into ChatGPT and asked it if it thought it showed corruption, ending with this line: 00:00:02:731: CCR_MAIN: activating root hub.
it had this to say:
"Based on the provided log, I cannot identify any volume corruption.
The log shows the initialization of various components of the Wii U system, such as USB root hubs, storage devices, and file systems. It also shows the version and build information of the Cafe OS SDK, which is the operating system used by the Wii U.
There is a line that shows the initialization of the slc01 volume, which is a part of the internal NAND storage used by the Wii U. However, the log does not contain any error messages or indications of volume corruption.
If you suspect that there is volume corruption in your Wii U NAND dump, you may want to look for other indicators, such as error messages during boot or inconsistencies in file system structures. It may also be helpful to compare the dump to a known good dump to identify any differences."
Last edited by wavebeam,
That's what I thought. Good to know, I would go for the high endurance cards then. I just didn't want the system to get any slower than it already is
I think I have enough working Wii Us, I search for the broken ones. So thanky, but no, I don't need it at the moment.
Yes, my whole post is about that. You can relace it either with another eMMC chip or and SD Card.
The SDIO bus has a 4 bit data bus and the Wii U is running it at 52Mhz SDR. So you are limted to 26MB/s by the bus. You should focus more on the access time.
5 retries sounds bad and it would worry me, but luckily it doesn't seem like files became corrupted. These files there are all db, so I assume they were just recently written and are still in the SLC cache. You can try to dump them through FTP to be totally sure, but I don't see a problem with the file system.
So maybe your eMMC has the problem and you are right on the Edge. Doing the NAND dump was probably a good thing, as it should have triggered the internal error correction of the eMMC and correct still correctable errors transparently.
But I would recommend you doing a second backup. If you have 5 retries, the dump might be more corrupt than it needs to be because of suboptimal error handling in the dumper (I am looking into fixing that). Also it would be interesting if you still get retrys.
Post automatically merged:
@wavebeam I don't see mlc corruption in your logs. You are probably fine
Last edited by SDIO,
I did do a second dump. The second dump also had 5 retries, but in a different spot. The same files were reported during extract. I can indeed extract those files fine with FTP.
I would do the mod asap, but I'm still unsure about a few things;
The nand dumper we have right now immediately reboots after the dump is done, which I assume would already desync the slc from the one that was just backed up. So... just yank the cord before that happens?
Will the SLC definitely not have any changes made due to the mlc backup happening?
Are there any preparations to do to the SD card, or do you just dd the mlc.bin you get from the dumper and that's that?
I would do the mod asap, but I'm still unsure about a few things;
The nand dumper we have right now immediately reboots after the dump is done, which I assume would already desync the slc from the one that was just backed up. So... just yank the cord before that happens?
Will the SLC definitely not have any changes made due to the mlc backup happening?
Are there any preparations to do to the SD card, or do you just dd the mlc.bin you get from the dumper and that's that?
Last edited by skawo,
The best method at the moment would be to dump the eMMC in hardware. You have to solder anyway to the SDIO bus.
If you can wait a few days, I will have a dumper for the recovery menu ready, which unmounts mlc and slc and doesn't automatically reboot, so you should be able to get a consistent dump that way, if you prefer
If you can wait a few days, I will have a dumper for the recovery menu ready, which unmounts mlc and slc and doesn't automatically reboot, so you should be able to get a consistent dump that way, if you prefer
I do own a Wii U with 160-0103 system memory error but it stopped displaying anything after a few reboots.
@Ferris1000 then you need to dump the eMMC through Hardware and replace it with an SD Card.
you could try the recovery menu with udpih and see if the led turn purple, but I don't expect it to work
Post automatically merged:
you could try the recovery menu with udpih and see if the led turn purple, but I don't expect it to work
Last edited by SDIO,
I already tried udpih but it didn't worked on this Wii U,
I don't have a backup for this Wii U because when I got it already had the 160-0103 error.
I will dump the NAND via Hardmod when I'll find some time to do it, maybe the Community will come up with a solution to rebuild a NAND from scratch but I don't think that will be the case because of the Encryption,
the eMMC you dump through the hardmod could still be good enough. I would recommend doing multiple dumps and compare them.
Without a NAND backup you just have to be super careful to not mess up the SLC cache.
I woudln't be suprised if we can get it to boot again to a error message and from there on we can use udpih to fix the broken files
It would be helpful for me, if you could run a dump with it and show me the output and the generated mlc.log.
Please don't trust the generated dump, but it would be good to see what wfs-extract thinks about it.
You need to run it through UPIH. It replaces the recovery menu.
EDIT: I found some problems with the dumper, that I want to fix first. I removed it and will upload the new version, when it is ready
Without a NAND backup you just have to be super careful to not mess up the SLC cache.
I woudln't be suprised if we can get it to boot again to a error message and from there on we can use udpih to fix the broken files
Post automatically merged:
You can just dd to it. But if your cardreader supports it, you can run blkdiscard before on the card, so the controller can earase everything in advance. If the card is discarded before it might also make sense to skip FF blocks, but I think dd can only skip zeros. But I am not really sure if the hassle would be worth it
Post automatically merged:
If your eMMC produces consistently read errors, it's perfect to test the error handling of my dumper code.
It would be helpful for me, if you could run a dump with it and show me the output and the generated mlc.log.
Please don't trust the generated dump, but it would be good to see what wfs-extract thinks about it.
You need to run it through UPIH. It replaces the recovery menu.
EDIT: I found some problems with the dumper, that I want to fix first. I removed it and will upload the new version, when it is ready
Last edited by SDIO,
You are the man. I can do this on a WiiU I have that crashes with 160-0103 on the setup when I go to create the Mii. Would this be helpful at all? I plan on doing the SD card Mod but dumping the eMMc was the most worrying part for me. This would help me out greatly.
-
AncientBoi
-
Sicklyboy
-
Sonic Angel Knight
-
Xdqwerty
what are you looking at?
-
-
@
Psionic Roshambo:
Like not emulating the entire SNES but just a loader and the enhancement chips perhaps even slightly overclocked like FX-2 -
-
-
-
-
-
-
@
SylverReZ:
@Psionic Roshambo, The Doom NES cartridges, a few batches were made. One was given to AVGN as seen in his Doom video.+1 -
-
@
Sicklyboy:
I finally modeled and 3d printed the new HDD cages I need in order to build my 2nd NAS. Original ones don't fit the mounting holes on the hdds I'm using. Been sitting on this project for over 2 years smfh
-
-
@
Sicklyboy:
I'm finally gonna get this NAS racked and powered on tonight, install truenas core, and burn the disks in with badblocks
-
@
Sicklyboy:
Also another 70TB going in the front mount drive bays of this server. 182tb raw, going to probably use a zfs RAID-Z3 for 3 parity disks, so 140TB usable
-
@
Sicklyboy:
I could claw back 14tb by only doing 2 parity disks but I feel like with 13 disks in the RAID I'd be kind of pushing my luck on rebuild time if I encounter a disk failure
-
-
-
-
-
-
-
-
-
-
