Brick nach Speicherfehler

So sieht das übrigens in mdinfo aus.

IMG_20230319_122601.jpg

Hi @Altarf, sorry dass ich deinen Beitrag übersehen habe. Bei dem von dir beschriebenen Verhalten könnte in der Tat ein defekter eMMC vorliegen, muss aber nicht unbedingt.
Ich vermute deine Wii U ist eine 32GB? Dann brauchst du eine 64GB SD-Karte die Du FAT32 formatieren musst. Windows lässt dich FAT32 nicht auswählen, aber es gibt Tools extra zu diesem Zweck.
Dann lädst du dir die wii-u-nandumper-payload herunter: github.com/wiiu-env/wiiu-nandd…payload/releases/tag/v0.1 und entpackst sie auf die SD Karte. Es sollte dann direkt auf der SD Karte einen Ordner mit dem Namen wiiu geben und darin dann die payload.elf.
Die SD Karte dann sicher auswerfen und in die WiiU stecken.
Dann rufst du im browser der Wii U wiiuexploit.xyz auf und klickst auf Exploit. Dann sollte der nanddumper starten. Hier stellst du dann sicher dass alles auf yes steht (auch der mlc, der standardmäßig auf no steht) und startest den dump dann mit A.

Das dauert dann eine ganze weile, aber behalte den Prozess im Auge und halte nach retrys Ausschau beim mlc. Am ende startet die Wii U automatisch neu und du kannst die SD Karte wieder in den PC stecken. Dort findest du dann einige Dateien auf der SD Karte. Das ist dein Backup das du auf dem PC verschiebst.
Danach machst du dann noch ein zweites Backup.

Die slc.bin kannst du dann mit Hilfe der otp.bin und diesem tool extrahieren: github.com/koolkdev/wiiu-nandextract/releases/tag/0.1.0

In dem sys/logs verzeichnis findest du die logs. Diese kannst du mir per PN schicken (ich würde sie nicht öffentlich posten wegen Seriennummer). Du kannst aber schonmal selbst nach DATA CORRUPTION oder MEDIA ERROR darin suchen.


Die mlc Dateien musst du erst mergen zu einer großen Datei und diese kannst du dann mit wfs-extract: github.com/koolkdev/wfs-tools/releases/tag/v1.0 extrahieren. Dabei tauchen eventuell Fehler auf. Wenn es nur wenige ins save Sateien sind ist es erwartet. Wenn aber viele auftreten auch in Systemdateien ist es schlecht. Poste die liste mit den Fehlern dann am besten hier.



Die aktuelle Hypothese ist, dass 32GB Hynix eMMCs von 2012 und Anfang 2013 ein problem mit der Retention haben und die Daten vorzeitig verlieren. Nicht benutzung könnte dabei eine Rolle spielen, da dann der eMMC Controller keine Chance hat auftretende Errors zu erkennen und zu korrigieren, solange sie noch korrigierbar sind.

Wenn du die Backups hast, kannst Du Aroma oder Tiramisu einrichten und darüber mdinfo starten. mdinfo sagt uns dann was für ein eMMC verbaut ist.

Man kann die Logs auch per ftpiiu dumpen, dann braucht man im gegensatz zum Recovery Menü auch keinen pico oder anderes kompatibles gerät.
Primäres ziel sind aber nicht die logs, sondern erstmal ein Backup zu haben, falls sich der Zustand verschlechter und um einen Überblick über den Zustand zu bekommen. Wenn man das Backup soweiso schon auf dem PC hat, kann man auch die Logs rausziehen...

Nein, mit dem dump kannst du nichts bricken. An der Konsole selbst wird nichts verändert.

FAT32 ist auch ein altes Dateisystem ;). Das empfohlene Tool für die Wii U ist GUIFormat ridgecrop.co.uk/index.htm?guiformat.htm
Wähle 32k (32768) allocation unit size aus.
Aber wahrscheinlich wird jedes Tool funktionieren

You can use the copy command to merge them



Die Punkte halt ersetzten. Die logs sehe ich mir gleich an.

Schlechte Nachrichten: dein eMMC ist auf jeden Fall fehlerhaft.

Zur Terminologie: der Phyische Chip ist ein eMMC chip. Die wie bezeichnet diesen Speicher als mlc. Das ist hier also weitgehnst austauschbar. eMMC Ist aber eher das Physische und MLC das Logische aus OS Sicht. Der MLC könnte physisch auch auf einer SD Karte liegen, wie es jetzt bei meiner Konsole der Fall ist.

Erstmal zum Verständnis: es gibt 2 ebenen auf denen Daten geprüft werden. Einmal innerhalb des eMMC Speichers selbst. Er speichert versteckt ECC daten für einzelne Pages vom Flash speicher, anhand er Fehler erkennen kann und falls nicht zu viele bits fehlerhaft sind kann er sie damit sogar korrigieren. Wenn man versucht einen Sektor zu lesen, der nicht mehr korrigierbar ist, meldet der eMMC einen Fehler zurück and die Wii U, wo er zuerst durch den mmc Treiber (mmc_core card) an den Dateisystem Layer (FSA) zurückgegeben wird. Das sind die "MEDIA ERROR" Fehler.

Die zweite Prüfung findet im Dateisystem statt. Hier prüft das Dateisystem nach dem entschlüsseln für komplette Dateien (und Dateisystem Metadaten) ob eine Prüfsumme stimmt, stimmt sie nicht gibt es einen " DATA CORRUPTION ERROR". Fehler auf der ebene sind nicht korrigierbar, sie können nur erkannt werden.
Wenn du den mlc mit wfs-extract extrahierst machst du damit die Prüfung auf alle Dateien im Dateisystem.

Der erste Fehler ist in 32.log vom 2023-03-12 19:23:45 aufgetreten:


Das ist erstmal nur ein "DATA CORRUPTION ERROR" der auf FSA ebene (Dateisystem aufgetreten ist). Alleine muss der noch nichts bedeuten. Das kann auch davon kommen, dass während dem schreiben mal die Konsole ausgeschaltet wurde. Der eMMC war der Meinung auf seiner ebene sind die Daten in Ordnung. Wobei das auch mit vorsicht zu genießen ist, denn mein eMMC hat mir sogar zufällige Daten als in Ordnung zurück gegeben.

Das gleiche auch noch in 33.log. Das gleiche auch noch mal in 34.log, aber hier sieht man zuvor auch noch
was auf einen Hardware Fehler hindeutet
Es endet jeweils mit einem 160-2793 errorcode

In 37.log vom 2023-03-16 08:07:45 finde ich:

Titel 00050000-1019de00 ist "Metroid Prime: Trilogy " Das ist vermutlich der erste Fehler der bei der Installation kam, es ist auch nicht der 103er sondern 162-0000.

Darüber kannst du die Fehlermeldungen vom mmc treiber sehen (mmc_core), der Hersteller wird als Hynix reported und auf dem FSA Layer sieht man das "MEDIA ERROR". Der eMMC hat hier selbst erkannt, dass ein sector bzw 2 sektoren (7980288 und 7980800) nicht mehr lesbar sind.


In 40.log von 2023-03-16 11:09:37 haben wir wieder

Das endet in einem 160-0103 Fehler

In 41.log (2023-03-16 12:25:37) und 43.log (2023-03-16 12:45:11) sind praktisch identsich und zeigen wieder Hardware Fehler:



Der eMMC Speicher sollte meiner Analyse nach möglichst bald ersetzt werden. Solange die Wii U noch so weit funktioniert, kann man ihn dann einfach auf den Ersatz klonen, ohne dass man was an den SLC löten muss, was sehr viel aufwendiger ist. So wie es aussieht, gibt es in absehbarer Zeit auch schon vorgefertigte Lösungen, die dann einfach zu löten sind: gbatemp.net/threads/how-i-fixe…rror.626448/post-10109095


Wegen der SD Karte: Kannst du mal gucken ob Du sie noch in der Datenträgerverwaltung siehst? Aber es kommt schon mal vor das SD Karten sterben, besonders am Anfang...

Kennst du vielleicht jemanden der das für dich tun könnte? Der Ersatz mit der SD Karte ist nicht so schwer, jedenfalls sehr viel einfacher als den MLC zu ersetzen und wie gesagt gibt es dafür wahrscheinlich bald auch eine Hilfe in Form eines boards, das schon lötpunkte an der richtigen stelle hat und man es nur noch drüber legen und kurz mit Lötzinn rann muss.

Eine andere Möglichkeit mit Software aufspielen wird es wohl nicht irgendwann geben? Hab deine Erklärung mit den etwaigen Hardwarefehlern gelesen aber möchte es noch nicht so ganz wahrhaben...

Naja Hardware Fehler sind in der Hardware und lassen sich schlecht in Software beheben. Es gäbe die theoretische Möglichkeit eine Homebrew zu schreiben, die ein aktuelles Abbild zieht, den Speicher dann löscht und das Abbild wieder zurück schreibt. Das habe ich in Hardware gemacht, aber es wäre theoretisch auch von der Wii U aus möglich. Mein eMMC hat dadurch zumindest temporärer wieder korrekt funktioniert, bis er dann durch meine ganzen Versuche die viel geschrieben haben endgültig durch war. Diese Homebrew Anwendung müsste man aber erst mal schreiben und testen. Selbstredend ist bei so einer Aktion das Brick Risiko extrem hoch.
Um das ins Recovery Menü einzubauen müsste ich herausfinden wie ich da eigenen code im IOS-FS Modul ausführen kann. Aktuell läuft alles in IOS-MCP weshalb ich nur über FSA Funktionen auf den Speicher zugreifen kann. Darüber kann ich den Lösch Befehl nicht senden, der es dem eMMC erlauben würde seine internen Strukturen neu zu organisieren.
Ich wüsste wie ich es in den bekannten Wii U NAND Dumper einbauen könnte, allerdings kann ich den auch noch nicht aus dem Recovery Menü starten. Aber wenns hart auf hart kommt würden wir den exploit in die "Gesundheits- und Sicherheitsinformationen" Applikation patchen und den COld Boot title dazu ändern. Darüber sollte es möglich sein den NAND Dumper zu starten.
Die frage ist nur ob es den Aufwand Wert ist, weil eigentlich muss der Speicher ersetzt werden.

Edit: Hab jetzt die MLC Dateien via CMD gemerged aber die extractor.exe funktioniert nicht bzw. ich hab keine Ahnung davon

Ich glaube ich habs hinbekommen und sieht nicht nach wenig aus...

Ja das hast du richtig gemacht und es sieht wirklich nicht gut aus. Das einzig positive ist, dass nur 7 Systemdateien beschädigt sind (die die mit /sys/ beginnen).
Wir könnten versuchen die über den WUP Server zu ersetzten. Das wird allerdings nur ein sehr temporärer fix sein.
Jetzt dürfte der eMMC noch in einem Zustand sein, in dem man ihn noch übertragen und dann fixen kann. Wenn wir noch viel probieren, kann es sein, dass der dann so zerschossen ist, dass man nur noch ein Backup zurückspielen kann. In dem Fall müsste man dann auch den SLC zurück spielen, was wesentlich aufwendiger wäre, da mehr zu löten und man einen speziellen Mikrocontroller dafür braucht. Überträgt man den MLC solange er noch halbwegs in Ordnung ist, kommt man um das SLC flashen rum. Außerdem ist das einzige Backup das wir haben von meinem Dumper, von dem fraglich ist ob der SLC Dump gut ist.

Das musst du wissen mit welchem weg du fortfahren willst. Wenn du noch schnell das Geld im eShop ausgeben willst, macht vielleicht der letzte weg mit dem Dateien fixen Sinn, das könnte noch schnell möglich sein bevor der Shop schließt. Aber ich glaube nicht dass die Konsole damit dann noch lange funktioniert.


Nein brächte man nicht. Über UDPIH haben wir den Weg rein ins System. Wenn man weiß wie kann man darüber auch IOSU neu starten um sicherzustellen, dass man den NAND exklusiv hat und natürlich auch zurückspielen.
Code um ein Backup durch FSA zurückzuspielen könnte ich auch jetzt sofort rauslassen. Allerdings besteht die Gefahr dass im Hintergrund noch auf den SLC zugegriffen wird oder sonst was schief geht. Daher werde ich das nicht posten, vor allem nicht ohne es erst selbst getestet zu haben.
Das beste wäre im recovery menü IOS_FS zu patchen und dann einen IOSU restart durchzuführen. Dafür fehlt mir aber noch das wissen, daher habe ich aktuell nur die unsaubere Methode über FSA, die ein viel zu hohes Brick Risiko hat.

Solange sie nicht läuft sollte es nicht so schnell schlimmer werden, Wenn du jetzt noch 5 Jahre wartest kann es natürlich sein, dass der eMMC noch mehr "vergisst" aber auf ein paar Wochen kommst jetzt nicht drauf an.

Ich habe mir kurz vor eShop Schließung noch Metroid Fusion und Zero Mission geholt und Letzteres bereits 3 Stunden gezockt. Dachte mir, dass ich die beiden Games durchzocke und dann solange noch nutze bis sie stirbt. Mit der Platine von Voultar könnte ich sie dann trotzdem wieder reanimieren oder? Hab ja das Backup gemacht oder ist das unbrauchbar? Ich raff das mit dem SLC und MLC leider noch immer nicht ganz und mein Englisch lässt zu Wünschen übrig.

Der SLC beinhaltet einen cache für dem MLC (eMMC) der cache muss immer exakt zum MLC passen, sonst wird das Dateisystem inkonsistent. Dafür reicht schon das Neustarten, damit sich genug ändert. Der cache speichert einen teil der daten aus dem MLC zwischen, da er schneller ist und mehr Schreibvorgänge aushält. Wenn also ein savegame gespeichert wird landet es wahrscheinlich zuerst im cache. Genauso häufig gelesene Blöcke wie teile der Verzeichnisstruktur können im SLC zwischengespeichert werden. Stellst du jetzt ein älteres Backup vom MLC wieder her, hat der SLC cache noch die neuen Daten die nicht zu den alten passen und gibts so tolle Sachen wie beschädigte Dateien und Ordner, die sich weder löschen noch überschreiben lassen.

Wenn du wartest bis es "zu spät" ist und du das Backup wieder einspielen musst, reicht es nicht aus nur das MLC Backup auf die SD Karte zu spielen, sondern du müsstest auch den SLC aus dem Backup wiederherstellen. Und um den zu flashen muss wesentlich mehr gelötet werden, man muss die Wii U weiter auseinander bauen und braucht einen speziellen Mikrocontroller, der nicht mehr hergestellt wird. Man will es also vermeiden.

Wenn Du den eMMC ersetzt, solange er noch gut genug ist, kann man den aktuellen zustand auslesen und dann auf den Ersatz (z.B. SD Karte) übertragen ohne dass der SLC zurückgeflasht werden muss. Es ist also wesentlich weniger Arbeit, vor allem wen Voultar das Adapter Board fertig hat.


Genau, dem kann ich zustimmen. Aber dann wäre es besser eventuell nichts zu sagen, bevor man was falsches sagt.

Bzw. lässt sich per Software allein kein Backup zurückspielen.

Technisch ist es schon möglich, sofern man in der Lage ist noch eigenen Code auszuführen. Es wurde nur noch nicht implementiert, aber da sind wir gerade dran.

Wir wollen ja gerade das einspielen das @BaamAlex beschreibt verhindern. Das wäre der Fall wenn wir das SLC backup zurückspielen müssten.
Dein Backup solltest du trotzdem nicht verwerfen. Falls irgendwas ganz schief läuft kann man die Konsole damit immer wieder herstellen, notfalls auch mit mehr Aufwand.

Für das QSB von Voultar reichen recht einfache lötkenntnisse: gbatemp.net/threads/how-i-fixe…rror.626448/post-10115383 Wenn du überhaupt keine Löterfahrung hast, wäre es aber trotzdem besser es von einem Bekannten machen zu lassen.
Wenn deine Wii U bis dahin noch in der Lage ist zu booten, können wir dann ein aktuelles MLC Image ziehen, es auf eine SD schreiben und das Board einlöten.
Falls du wirklich überhaupt niemand hast, der dir damit helfen kann, kannst Du auch mal in einer PN schreiben wo du ungefähr wohnst, vielleicht ist es nicht zu weit. Zwei mal herumschicken lohnt sich kaum.