Haltbarkeit des GP2x bzw. "Wann gibt mein NAND auf&quot


kilroy

Member
Joined
Nov 6, 2005
Messages
341
Ich versuche mal die Problematik mit dem NAND zusammenzufassen (das NAND ist der interne wiederbeschreibbare Speicher)...

Ein NAND ist ein Flash Baustein, der 100.000 mal beschrieben werden kann (pro Block). Danach geht dieser Block (idR) kaputt.

D.h. jegliche Schreibversuche auf das NAND sollten abgefangen werden.

Leider hat GPH den GP2x nicht so konzipiert... d.h.:

a) beim Hochfahren mountet er das Dateisystem read/write und auch noch mit atime (d.h. jeder Zugriff (AUCH LESEND) verursacht einen schreibzugriff)

b) in den skripten zum starten wird auf dem NAND rumgeh.... extrem viele schreibzugriffe, keine Ahnung welche man da wirklich braucht.

Beispiel:
Code:
<i>
</i># Clean out /etc.
rm -f /etc/mtab~ /fastboot /fsckoptions /forcefsck
>/var/run/utmp
touch /var/log/wtmp
chgrp utmp /var/run/utmp /var/log/wtmp
chmod 0664 /var/run/utmp /var/log/wtmp

# Delete UUCP lock files.
rm -f /var/lock/LCK*

# Delete stale subsystem files.
rm -f /var/lock/subsys/*

# Delete stale pid files
rm -f /var/run/*.pid

# Load modules
if [ -f /etc/rc.d/rc.modules ]; then
    /etc/rc.d/rc.modules
fi

D.h. ein Bootvorgang schreibt mindestens mal 50 mal auf das NAND... d.h. nach 2000mal Booten oder 1000mal Booten und ein paar Programme starten fängt das NAND an, kaputt zu gehen...

Einige Devs haben schon Modifikationen an den Dateien vorgenommen, um die Schreibzugriffe zu begrenzen. Ich werde wenn ich mutig bin, eine weitere - hoffentlich komplett dann ohne Schreibzugriffe - Modifikation vornehmen und diese testen... allerdings bin ich im Moment ohne serial Interface dazu noch nicht bereit...

Ein Dev hat schon einmal eine Basismodifikation veröffentlicht, die das Filesystem read only mountet nach dem Starten - allerdings klappen dann böse Spiele nicht mehr, und das ist eigentlich auch gut so.

WARNUNG

Das Einspielen dieser Modifikationen kann den GP2x bricken!

NUR FÜR GANZ MUTIGE: http://www.scrameta.net/noatime.html
 
böse sache...
ich fand in dem zusammenhand ein bisschen hintergrund info sehr intressant:
http://de.wikipedia.org/wiki/NAND-Flash
 
Oh ja, und der Hauptteil fehlt:

Was sagt GPH dazu - kann ED das mal nachfragen, wie problematisch die das erachten?

Ich würde mich schon SEHR wohler fühlen, wenn das U-Boot das nicht ATIME, sonder NOATIME mounten würde - dann hätte ich bedeutend weniger Bauchschmerzen!
 
Hm, laut dem WIKI liegen die Schreibzyklen beim NAND bei 1 Million...?

Aber ich hak mal nach.
 
Das Skript kann übrigens gefahrlos aufgespielt werden, habe ähnliches schon seit Wochen in meinem /etc/profile drin ;)
 
Auch ich habe es jetzt drauf und es läuft wie erwartet ohne Probleme...
 
Wäre irgendwie schade um das Geld.
Und deshalb würde ich, wenn mein GP2X schon innerhalb der Garantie aufgibt, ihn zurückschicken, weil ich stark bezweifle, dass die das als "Verbrauchsgut" bezeichnen können, was eben irgendwann "alle wird".

Ich mein, bei aller Liebe... ich akzeptiere viele Mängel am GP2X, aber nicht, dass er innerhalb von ein paar Monaten zum Ziegelstein wird. Andererseits machen sich die Leute schon lange extreme Sorgen um den internen NAND, und ich habe noch von niemandem gelesen, der 1) gesicherte Infos zum Thema von GPH hat oder 2) einen wegen NAND-Ausfall geziegelten GP2X hat.

Abwarten und Tee trinken. Mal sehen, was ED erfährt.
 
Gibt es keine Möglichkeit den Bootsektor so umzuschreiben das von der SD karte Gebootet wird? Diese ist ja schliesslich auswechselbar
Dann wäre der Nand Speicher nicht belastet?
Hab natürlich null Peilung vom Innenleben des GP2X Deswegen vergebt mir wenn ich unsinn schreib :)
 
Bob Weasel said:
Gibt es keine Möglichkeit den Bootsektor so umzuschreiben das von der SD karte Gebootet wird? Diese ist ja schliesslich auswechselbar
Dann wäre der Nand Speicher nicht belastet?
Hab natürlich null Peilung vom Innenleben des GP2X Deswegen vergebt mir wenn ich unsinn schreib :)

Doch, das kommt ja auch mit der HH-Firmware.
 
Das ist nicht das einzige Problem. GPH nutzt auf dem NAND das JFFS2 Filesystem, ein Journaling-Filesystem für Flashspeicher. Allerdings muss ein Journaling System naturbeding Daten auf dem NAND speichern.

Darüber hinaus läuft auf dem Ding noch devfsd. Was bei einem an sich statischen System sinnlos, bei einem NAND System noch dazu eine bescheuerte Idee ist.

Das System nutzt darüber hinaus auch einen Garbage Collector, der sporadisch anspringt und diese "Logeinträge" des Systems wieder löscht. Den habe ich inzwischen im Verdacht, für die kurzen Hänger verantwortlich zu sein, die hin und wieder auftreten.

Ich spiele gerade mit dem Gedanken, das Ding komplett auf ext2 oder noch besser CramFS umzustellen. Natürlich ist die Gefahr, mir die Konsole zu bricken extrem hoch :(
 
Add: Der Bootloader liest ja bereits SD Karten aus (oder versucht es ;) ) um die Firmware flashen zu können. Eventuell kann man den so umbiegen, das er auch direkt von SD booten kann - Linux ist es scheißegal, von welchem Medium es gebootet wird.

Hat GPH den Source dazu freigegeben?

EDIT: Dumme Frage, wenn ein Blick ins Archiv genügt ;)

BTW: Der Richtige Ort für diese Änderung ist /etc/fstab und nicht /etc/profile - die wird als letzte beim Booten ausgelesen, also wenn der größte Schaden schon begangen ist.

EDIT: Nur leider ist es nicht so einfach. Habe die fstab geändert, Dateisystem wird immer noch als rw gemountet. Darüber hinaus habe ich eine SD Karte jetzt mit ext2 formatiert, schon alleine, damit ich ein ordentliches sync habe. Leider hat was immer auch für das mounten der Karte beim Einlegen während das Gerät läuft auch vfat fest verdrahtet. Bleibe da aber erstmal dran.
 
Ich brauche einen Schnaps.

1. Zum rw - Problem:

Der Kernel mountet den NAND in rw, der Kernelparameter dafür wird ihm explizit von U-Boot übergeben. Die /etc/fstab wird gar nicht genutzt, statt dessen findet der komplette Bootvorgang in /etc/rc.d/rc.sysinit statt.

Sehr schön. Ich werde noch rumbasteln und im Laufe des Tages eine Version haben, die ohne devfsd auskommt, ohne die diversen Logeinträge und genau hier das System als ro remountet.

EDIT: Ich sehe in der rc.sysinit, dass dort vorgesehen war, die ganzen notwenigen logeintragungen (utmp ...) in eine ramdisk zu schreiben. 1-2 kb sind ja auch nicht tragisch. Warum das aber nicht durchgezogen wurde ... und auch hier, nachrüsten nicht möglich ohne neuen kernel :(

2. Problem, anderes Dateisystem als FAT auf der Karte

Nach zwei Stunden Suche habe ich jetzt auch den Grund gefunden, warum jede eingelegte Karte zwangsweise als vfat gemountet wird. Weil die entsprechenden Typen bei Dignsys so komplett inkompetent sind, dass sie den Mountbefehl samt Pfad, Dateisystem und Device fest im Kernel hardwired haben. Wozu um alles in der Welt? :(

Da ich keine Hoffnung auf Besserung durch ein Firmwareupdate habe werde ich also versuchen müssen, den Kernel zu crosscompilen ohne mir den GP2X zu bricken. Aber das wird ja mit dem nächsten Akt wieder hinfällig und so oft will ich einen Drahtseilakt ohne Serielles Kabel dann doch nicht machen.

Sorry, aber ich bin gerade stinksauer.

Und als wäre das nicht schlimm genug hat GPH das ganze nochmal - sicher ist sicher - in gp2xmenu eingebaut. Dem konnte ich aber noch mit einem Hexeditor Herr werden.

EDIT: Immerhin habe ich jetzt die Antwort darauf, wie die USB Verbindung in gp2xmenu initialisieren. Wen es interessiert:

insmod /lib/modules/2.4.25/kernel/drivers/usb/gadget/net2272.o
insmod /lib/modules/2.4.25/kernel/drivers/usb/gadget/g_file_storage.o file=/dev/mmcsd/disc0/part1
 
zu 1.) sorry, vergass ich zu erwähnen, ja, U-Boot mountet das alles, deswegen können wir das nicht einfach ändern

zu 2.) Omg, das ist dämlich... hardwired :(

zu dem USB, habe das schon letztens gewiki'd, falls jemand sich die Skripte mal auf den GP2x ziehen will - laut meiner Tests läuft das alles stabil so weit:

http://wiki.gp2x.org/wiki/Turning_on_and_off_the_USB_mass_storage_driver

EDIT: Nach einem usbOn.gpe kann man prima das Menü verlassen und andere Programme starten. Nur das Erscheinen von Dateien, die andere Programme schreiben, ist noch was merkwürdig (trotz sync dauert es ne Weile) - da muss ich mal noch nachgucken
 
Miyu said:
EDIT: Nur leider ist es nicht so einfach. Habe die fstab geändert, Dateisystem wird immer noch als rw gemountet. Darüber hinaus habe ich eine SD Karte jetzt mit ext2 formatiert, schon alleine, damit ich ein ordentliches sync habe. Leider hat was immer auch für das mounten der Karte beim Einlegen während das Gerät läuft auch vfat fest verdrahtet. Bleibe da aber erstmal dran.

Deine SD-Karte auf ein anderes Dateisystem umzustellen ist dennoch recht einfach möglich, solange es vom GP2X-Kernel unterstützt wird. Die Karte wird von der /etc/profile gemountet, wo vfat in der Tat fest verdrahtet ist, das müsstest du dann ändern.
 
Ich hoffe, es gibt noch ne Lösung für das NAND Problem. Ich möcht mir ja nen robusten, stabilen GP2X kaufen, den ich auch noch in 5 Jahren ohne Probleme verwenden kann. ^^"

Auch währe es für den Laien sicher hilfreich, wenn man ohne großen Aufwand das problem umgehen kann. Was ich hier so lese, setzt ja tiefgreifende Kentnisse vom Innenleben des GP2X vorraus. Es sollte denn am Ende schon einfacher zu bewerkstelligen sein, das Leben des GP2X zu verlängern.
 
wejp said:
Deine SD-Karte auf ein anderes Dateisystem umzustellen ist dennoch recht einfach möglich, solange es vom GP2X-Kernel unterstützt wird. Die Karte wird von der /etc/profile gemountet, wo vfat in der Tat fest verdrahtet ist, das müsstest du dann ändern.

So schlau war ich bereits :) Habe mir inzwischen auch einen Mounter geschrieben, der die Karte je nach Filesystem mit unterschiedlichen Optionen mountet. Nur das Problem bleibt, dass sowohl der Kernel beim einlegen einer Karte als auch das gp2xmenu die Karte zwangsweise als vfat mounten wollen, was natürlich scheitert.
 
Fusion_Power said:
Auch währe es für den Laien sicher hilfreich, wenn man ohne großen Aufwand das problem umgehen kann. Was ich hier so lese, setzt ja tiefgreifende Kentnisse vom Innenleben des GP2X vorraus. Es sollte denn am Ende schon einfacher zu bewerkstelligen sein, das Leben des GP2X zu verlängern.

Im Moment ist das ja alles noch eine technische Debatte ;) Denke am Ende muss man nicht mehr machen, als eine gpu zu starten.
 
Aber was passiert, wenn trotz aller Bemühungen um die NAND-Erhaltung der GP2X sein Leben aushaucht. Auch nach der Garantiezeit sollte er doch einwandfrei laufen, wie man es von einem Handheld erwarten würde, oder ?
 
Jede Technik geht irgendwann mal kaputt. Hier geht es ja nur darum, den Zeitpunkt möglichst lange hinauszuzögern :)
 
Back
Top