[Gelöst] Freetzen einer 7590 mit FW 7.12

Massa

Neuer User
Mitglied seit
18 Dez 2004
Beiträge
196
Punkte für Reaktionen
4
Punkte
18
Doch, doch - das hatte ich in Beitrag #35 geschrieben - das relevante Protokoll ist E02_192-168-178-11-new_2020-05-12-37-txt
Vermutlich war das da nicht deutlich genug geschrieben... :oops:

Die relevanten Zeilen im Log sind folgende:
Code:
libscan: scanning eraseblock 2330: OK, erase counter 20
libscan: scanning eraseblock 2331: OK, erase counter 20
libscan: scanning eraseblock 2332: OK, erase counter 20
libscan: scanning eraseblock 2333libmtd: error!: cannot read 64 bytes from mtd6 (eraseblock 2333, offset 0)
        error 1 (Operation not permitted)
ubiformat: error!: failed to scan mtd6 (/dev/mtd6)
EDIT: das verwendete Shellscript war E02-test_me_new.txt
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,168
Punkte für Reaktionen
1,039
Punkte
113
Das hatte ich tatsächlich nicht mitgekriegt - das ist die Gefahr, wenn man nachträglich editiert. Ich hatte den Thread schon offen in einem Tab und ihn beiseite gelegt, um später zu antworten (das mit den LEDs) - da war Deine Ergänzung noch nicht drin und so eine nachträgliche Bearbeitung wird dann auch nicht mehr als Änderung des Thread-Inhalts signalisiert.

=========================================================

Damit ist aber klar, daß das Problem wohl schon beim Lesen des EC-Headers auftritt ... der steht normalerweise in den ersten 64 Byte eines Erase-Blocks (die OOB-Daten benutzt UBI normalerweise auch nicht, da lag ich falsch bzw. das war mir entfallen).

Angesichts Deiner ohnehin geringen Werte für diese Erase-Counter halte ich es für vertretbar, die bisher erfolgten Schreibzugriffe zu ignorieren und zu versuchen, mittels "-e 0"-Option beim "ubiformat" auf die Leseversuche zu verzichten und für alle Blöcke (das gilt ohnehin ja nur für die, die unter UBI-Kontrolle stehen) den Zähler zurückzusetzen. Wenn das Schreiben des EC-Headers schon zum Fehler führt, sollte der PEB aussortiert werden.
 

Massa

Neuer User
Mitglied seit
18 Dez 2004
Beiträge
196
Punkte für Reaktionen
4
Punkte
18
Das hatte ich tatsächlich nicht mitgekriegt - das ist die Gefahr, wenn man nachträglich editiert.
Ich bin eigentlich auch kein Fan davon - normalerweise schreibe ich dann lieber einen neuen Beitrag.
Hier im Forum wurde ich aber schon verwarnt und mehrere aufeinanderfolgende Beiträge "zusammeneditiert" - und das ist noch schlechter, da sieht man dann gar nicht mehr, was nachträglich dazukam...

Angesichts Deiner ohnehin geringen Werte für diese Erase-Counter halte ich es für vertretbar, die bisher erfolgten Schreibzugriffe zu ignorieren und zu versuchen, mittels "-e 0"-Option beim "ubiformat" auf die Leseversuche zu verzichten und für alle Blöcke (das gilt ohnehin ja nur für die, die unter UBI-Kontrolle stehen) den Zähler zurückzusetzen. Wenn das Schreiben des EC-Headers schon zum Fehler führt, sollte der PEB aussortiert werden.
Das hatte ich mich bisher nicht getraut (weil ich nicht wußte, was das genau auslöst) - jetzt werde ich es mal durchführen ;)

Aussführungsbericht wieder hier als "EDIT", falls inzwischen keine weitere Antwort von jemand anderes kam / kommt
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,168
Punkte für Reaktionen
1,039
Punkte
113
Tipp von mir zum "EDIT" - wenn Du den neuen Inhalt als neuen Beitrag schreibst und dann nur den vorhergehenden Beitrag davorkopierst, kriegt der eine neue Nummer und wird auch als "neu" behandelt ... und zwar bei allem (von der E-Mail-Benachrichtigung über die "What's new"-Ausgabe bis hin zu den "Thread was changed"-Mitteilungen per Javascript.). Wenn ein anderer Beitrag dazwischen liegt, bringt das natürlich die Reihenfolge durcheinander - andererseits verlangt auch niemand von Dir in so einer Situation, daß Du den vorhergehenden Beitrag bearbeitest.
 

Massa

Neuer User
Mitglied seit
18 Dez 2004
Beiträge
196
Punkte für Reaktionen
4
Punkte
18
Tipp von mir zum "EDIT" - wenn Du den neuen Inhalt als neuen Beitrag schreibst und dann nur den vorhergehenden Beitrag davorkopierst, kriegt der eine neue Nummer und wird auch als "neu" behandelt ...
das habe ich jetzt nicht verstanden - wenn ich das mache, dann ist das doch ein doppelter Eintrag, oder wird dadurch der ursprüngliche Beitrag automatisch gelöscht?

Hier jetzt das Ergebnis: irgendwie ignoriert der die "-e 0" Angabe - oder zumindest ändert sich nichts am Verhalten.
Der Aufruf erfolgt jetzt ubiformat /dev/mtd6 -e 0 -y -v - das kann man auch im Log sehen (durch den set -x).
Aber die libscan-Meldungen samt Fehlermeldung aus libmtd sind leider identisch; sehr seltsam - lt. Hilfe aus der Box (ubiformat -h) kennt der aber den -e Parameter...
 

Anhänge

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,168
Punkte für Reaktionen
1,039
Punkte
113
wird dadurch der ursprüngliche Beitrag automatisch gelöscht?
Nein, den mußt Du dann natürlich von Hand entsorgen.

====================================================================

Also steht die Aufgabe an, irgendwie die Blöcke in dem passenden MTD zu löschen - und zwar so, daß dabei zuvor nicht gelesen wird. Das alles in der Hoffnung, daß dabei der PEB 2333 wieder so weit "repariert" wird, daß ein Lesezugriff auf die ersten 64 Byte möglich wird.

Ich sehe da zwei mögliche Wege, aber für beide mußt Du Dich vorher (genau!) vergewissern, welches das richtige MTD ist (das sollte auch nicht vom UBI-Layer in Beschlag genommen sein), denn das variiert von der Nummer her, je nachdem, ob aus dem Flash oder aus dem RAM gestartet wurde. Richtig ist die Partition, die als "ubi" in der Ausgabe von "/proc/mtd" steht.

Der erste Weg wäre der, daß man es mittels des "update_kernel" von AVM versucht. Das kann entweder Daten in den Flash schreiben (wenn -i und -o angegeben wurden - Beispiele in der E03-flash_update) oder es kann auch nur löschen, wenn ausschließlich "-o" angegeben wurde. In jedem Falle sind hier die Character-Devices für die MTDs zu verwenden - also "mtdX" und nicht "mtdblockX". Ich weiß nicht, wie das Programm genau vorgeht (ist halt "closed source" von AVM) - aber einen Versuch ist es allemal wert (dem schließt sich dann ggf. wieder das "ubiformat" an).

Die Alternative, von der ich aber nicht genau weiß, ob sie bei der 7590 funktioniert (und erst recht nicht beim 07.12-Kernel), wäre die Verwendung des "/proc/mtd"-Interfaces. Hier wäre ein echo "mtd [I]X[/I] erase all force" > /proc/mtd den Versuch wert - wenn das mit dem "update_kernel" nicht geklappt hat. Weiter dann wieder mit "ubiformat" - ob es hilft, weiß ich auch nicht.

Es wäre denkbar, daß bei den GRX-Modellen überhaupt kein Schreibzugriff auf "/proc/mtd" implementiert ist - die Kernel-Quellen enthalten in "mtdcore.c" jedenfalls keinen Support für "mtd_write_proc()". Wenn der vorhanden ist, kann man über "mtd X erase { nr | all [ force ] }" alle oder einzelne Blöcke eines MTD löschen, bevor man die dann neu beschreibt. Aber ich kann auch verstehen, wenn AVM das in neueren Modellen nicht länger einbaut - die "Sabotage" einer Box über ein passendes Kommando an "/proc/mtd" war einfach zu leicht, denn damit kann man sich auch den Bootloader löschen. Daher ist auch bei der Wahl der MTD-Nummer (sowohl beim "update_kernel" als auch beim "echo > /proc/mtd") höchste Sorgfalt geboten.

=======================================================================

Ich habe mal einen genaueren Blick in die betreffenden Quelltexte geworfen ... wenn ein NAND-Block bereits in der BBT (Bad Block Table) eingetragen ist, wird der beim "ubi_scan()"-Aufruf im Rahmen von "ubiformat" auch übergangen bzw. als "bad" angenommen. Hier ist das Problem im Moment, daß schon der Leseversuch für den EC-Header scheitert und dieses Scheitern aber, solange der Block nicht in der BBT steht, als "richtiger Fehler" interpretiert wird.

Normalerweise würde man so einen Eintrag in der BBT über einen ioctl()-Aufruf (mit MEMSETBADBLOCK als Operation) vornehmen lassen - es gibt aber in den "mtd-utils" kein passendes Tool. Aber es gibt einen Patch für die "mtd-utils", der ein Tool namens "nandmarkbad" nachrüstet - einfach mal googlen. Wenn also alles andere nicht hilft, müßte man sich das Tool (z.B. mit der Freetz-Toolchain) übersetzen und es von Hand für den Block 2333 im MTD4 (bzw. MTD6, je nachdem, woher das System gestartet wurde) aufrufen.

Aber Deine 7590 hat ohnehin einen Flash-Chip mit ONFI (Open NAND Flash Interface), im Gegensatz zu meiner 7580 - daher ist das mit den direkten Vergleichen immer etwas schwierig. Aber soweit ich weiß, gehört auch die BBT-Verwaltung zu den Features, die beim ONFI gefordert sind - daher sollte auch Dein Chip eigentlich eine BBT (im Flash) verwalten und wenn man den Block da als "bad" markiert hat, sollten das alle weiteren Zugriffsversuche auch berücksichtigen.
 

Massa

Neuer User
Mitglied seit
18 Dez 2004
Beiträge
196
Punkte für Reaktionen
4
Punkte
18
Nein, den mußt Du dann natürlich von Hand entsorgen.
Achso, jetzt habe ich verstanden, wie Du's gemeint hast :)

Der erste Weg wäre der, daß man es mittels des "update_kernel" von AVM versucht.
BINGO - das war die Lösung :cool:
Ich habe das jetzt in mein E02-Script eingebaut (vor dem ubiformat) und jetzt hat es funktioniert, das ubiformat ist anschließend komplett ohne Fehler durchgelaufen.
Code:
echo "[ubi] formatting ubi volumes in /dev/mtd${mtd_ubi_nr} ..."
ubidetach -p /dev/mtd${mtd_ubi_nr}
if [ -x "/sbin/update_kernel" ]; then
  echo "[ubi] using /sbin/update_kernel for cleanup of /dev/mtd${mtd_ubi_nr}"
  /sbin/update_kernel -o /dev/mtd${mtd_ubi_nr}
fi
ubiformat /dev/mtd${mtd_ubi_nr} -e 0 -y -v
l_rc=$?
if [ ${l_rc} -eq 0 ]; then
  ubiattach -p /dev/mtd${mtd_ubi_nr}
  l_rc=$?
  echo "[ubi] formatting ubi volumes done with ${l_rc}"
else
  echo "[ubi] formatting ubi volumes failed with ${l_rc}!"
  return ${l_rc}
fi
Er hat danach (vermutlich im E03-Script, das ja dann auch noch aufgerufen wird) wahrscheinlich noch seltsame Sachen gemacht, aber im Prinzip hat es funktioniert.
Ich habe anschließend noch versucht, das ganze Prozedere ohne "recovered=2" im "firmware_info" auszuführen, um zu sehen wie er da reagiert - das hat zwar auch funktioniert, aber "richtig" gebootet hat er immer noch nicht.

Am Schluss habe ich dann einfacherhalber nochmal das AVM-Recovery arbeiten lassen - danach war die Box wieder komplett erreichbar - inklusive Web-GUI.
Jetzt kann ich mich wieder daran machen, mein Freetz-NG Image draufzuballern und zu sehen, ob das funktioniert - aber das muss bis morgen warten ;)

Vieeeeelen Dank @PeterPawn für Deine Hilfe (und Geduld mit mir) - ich habe auf jeden Fall jetzt sehr viel gelernt!

Der Vollständigkeit halber habe ich mein E02-Script mit dem es dann funktioniert hat sowie die daraus resultierenden Logs angehängt.

Was noch immer komisch ist: die Info-LED hat zu keinem Zeitpunkt des Update / Recovery irgendwie "gezuckt" - da muss ich nochmal gesondert nach schauen.
(beim Einstecken des Stromsteckers geht's zuerst mit der Power-LED los, dann kommt die "Lichtorgel" - da leuchtet die Info-LED orange...)
 

Anhänge

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,168
Punkte für Reaktionen
1,039
Punkte
113
Na also ... dann viel Spaß und viel Glück mit Freetz in der Zukunft.

Da es hier im weiteren dann um den NG-Fork geht, bin ich auch raus.
 

Massa

Neuer User
Mitglied seit
18 Dez 2004
Beiträge
196
Punkte für Reaktionen
4
Punkte
18
Na also ... dann viel Spaß und viel Glück mit Freetz in der Zukunft.
Danke nochmal für Deine Hilfen und Erklärungen! :cool:

Da es hier im weiteren dann um den NG-Fork geht, bin ich auch raus.
Schade...
(ich bin hier vor einiger Zeit umgestiegen, weil bei mir die -NG Version besser funktioniert hatte und ich über mehrere Fehler gestolpert bin, die beim "Freetz-NG" gefixt sind, aber beim "Ur-Freetz" bis heute nicht...)

Ich fände ja eigentlich auch deine "Modulversion" spannend - aber ich bin mir nicht sicher, in wieweit, die den "täglichen" Gebrauch verwendbar ist?! :)
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
13,168
Punkte für Reaktionen
1,039
Punkte
113
ich bin mir nicht sicher, in wieweit, die den "täglichen" Gebrauch verwendbar ist?!
Das ist ohnehin noch nicht komplett ... es geht nur langsam vorwärts. Es gibt halt viel Grundlagenarbeit und dann ändert sich das auch noch ständig, weil AVM ja auch nicht die Entwicklung einstellt. Seitdem es die Wrapper-Partitionen der VR9-Boxen nicht mehr gibt, ist es auch schwerer, einfach so etwas in das originale AVM-System einzubauen, ohne es zu entpacken, zu ändern und dann neu zu packen.