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.
