MMI 3G größere Festplatte einbauen
Bevor das Thema "MMI 3G nachrüsten" zu unübersichtlich wird, mache ich lieber mal ein neues Thema auf ...
So, ich habe gestern mal auf verschiedenen Wegen versucht die Jukebox größer zu machen.
Zuerst habe ich den kompletten Dump von meiner originalen Festplatte auf die 320er gespielt. (byteweise unter Linux mit dd)
Die 320er Festplatte hat dann einwandfrei im 3G funktioniert.
Leider ist die 10GB Partition, in der ich auch die importierten Files (hexedit) gefunden habe, die 2. Partition und es folgen noch die 3., extended, 5. und 6. Partition.
Hier mal ein fdisk-Dump von der originalen Platte / der originalen Partitionstabelle:
Disk /dev/sdc: 40 GB, 40007761920 bytes
255 heads, 63 sectors/track, 4864 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes
Device Boot Start End Blocks Id System
/dev/sdc1 * 1 3003 24121566 4d QNX4.x
/dev/sdc2 3004 4380 11052720 4e QNX4.x 2nd part
/dev/sdc3 4381 4486 843412 4f QNX4.x 3rd part
/dev/sdc4 4487 4864 3028252 5 Extended
/dev/sdc5 4487 4813 2618595 bb Boot Wizard Hid
Warning: Partition 5 does not end on cylinder boundary.
/dev/sdc6 4814 4820 48195 bb Boot Wizard Hid
Warning: Partition 6 does not end on cylinder boundary.
/dev/sdc7 4821 4864 345397 bb Boot Wizard Hid
Warning: Partition 7 does not end on cylinder boundary.
Da man die 2. Partition (in diesem Fall /dev/sdc2) nicht vergrössern kann, da direkt im Anschluss weitere Partitionen folgen, habe ich 2-7 gelöscht, die 2. größer gemacht (z.B. 256GB) und dann die übrigen dahinter so angelegt, wie sie von der Größe her waren.
Die originalen Partitionen habe ich vorher einzeln mit dd gedumpt und dann auf die jeweiligen Partitionen zurückgespielt.
Das 3G bootet einwandfrei, leider ist die Jukebox in der Quellenauswahl ausgegraut 🙁
Ok, nächster Versuch war mit "diinit -h /dev/sdc2" ein neues, leeres QNX4-Filesystem auf /dev/sdc2 zu erzeugen.
Mounten konnte ich dieses frische Filesystem einwandfrei mit dem Linux QNX4 (readonly) Treiber - ganz im Gegensatz zu der originalen 2. Partition. Diese hat sich bisher hartnäckig gegen ein Mounten gewehrt.
Leider kein anderes Bild am 3G 🙁 Eine kleinere (nur 20GB) 2. Partition habe ich in beiden Konstellationen auch ausprobiert. (hätte ja sein können, dass 256GB einfach zu viel für das arme, kleine 3G ist 😉
Hat aber leider auch keinen Unterschied gemacht.
Spasseshalber habe ich auch mal ein EXT2 Filesystem drauf gepackt. QNX kann eigentlich auch mit einem Linux EXT2 FS umgehen. Leider auch kein Erfolg.
Im Moment bin ich der Meinung, dass das originale QNX4 Filesystem abgewandelt wurde und wahrscheinlich auch noch eine bestimmte Datei im Filesystem dem 3G sagt, dass es eine gültige, funktionierende Jukebox-Partition/Filesystem zur Verfügung hat.
Ich befürchte daher, dass man sich wirklich die Mühe machen muss das Filesystem genauer zu verstehen, um die nötigen Anpassungen vorzunehmen.
Insbesondere müssten man mal schauen, ob bestimmte Verzeichniss-/File-Einträge für die Jukebox nötig sind.
So viel erst einmal dazu ... vielleicht findet sich hier ja noch jemand, der irgendetwas rausfindet ...
Kai
Beste Antwort im Thema
Achso ... Feedback ist natürlich auch durchaus erwünscht! (positives wie negatives)
Also bitte nach dem Test bitte einmal kurz ein paar Zeilen schreiben, das wäre wirklich super 🙂
176 Antworten
Das wäre ganz nett.
Lass uns im Neuen nochmals Kontakt aufnehmen - erstmal viel Spaß mit dem neuen Dicken 4G😉.
Zitat:
Original geschrieben von 4F-Devil
Das wäre ganz nett.
Lass uns im Neuen nochmals Kontakt aufnehmen - erstmal viel Spaß mit dem neuen Dicken 4G😉.
Jepp, wir bleiben in Kontakt und der Sache auf der Fährte... 😁 😁 😁
So, jetzt geht es endlich voran.
Ich habe heute ein paar Stunden an den Bitmaps vom qnx6fs verbracht.
Mir ist jetzt klar wie die Node-Ebenen erstellt und adressiert werden.
Der Zusammenhang mit dem Superblock ist nun auch glasklar.
Auf dem Weg habe ich auch gleich noch ein paar Dinge rausgefunden.
Z.b. wie der 2. Superblock mit dem 1. Superblock und der Gesamtanzahl der zur Verfügung stehenden Blöcke zusammenhängt, die in jedem der Superblöcke steht.
Gleichzeitig ist mir auch klar geworden, warum die Entwickler von dem FS überhaupt keine andere Möglichkeit hatten sowohl die Gesamtanzahl an Blöcken, als auch die Gesamtanzahl an Inodes im Superblock anzugeben 🙂
(so schliesst sich der Kreis ...)
Die Superblöcke vom 5F Filesystem und vom aktuellen qnx6fs unterscheiden sich leider. So wie es aussieht, habe ich aber auch im 5F Superblock die passenden Stellen gefunden. (bedingt dadurch, dass man die übrige Struktur vom FS auch garnicht ohne Anzahl der Blöcke und Anzahl der Inodes implementieren kann, mussten sich diese Werte auch im 5F Superblock finden (s.o))
Was feht jetzt noch?
Tja, ich muss ein Programm schreiben, welches mir:
a) den 2. Superblock passend zur (bezogen auf eine größere Partition) dann weiter hinten liegenden Endadressse umbewegt
b) die Anzahl der Bitmap-Nodes passend zur neuen FS-Größe vergrößert
c) diese neuen Bitmaps (besonders am alten und neuen Ende jeweils der neuen Gegebenheit anpasst)
d) dabei u.U. weitere Zwischennodes einfügt und im Superblock verankert
e) die Menge der insgesamt zur Verfügung stehenden Blöcke in beiden Superblöcken anpasst
f) die Checksumme von beiden Superblöcken neu berechnt und schreibt
Weiter muss ich das ganze dann:
g) mit einem qnx6fs ausprobieren (bessere Möglichkeit etwas zu debuggen als am 5F - eine 5F-Console wäre schon eine tolle Sache ...)
h) wenn es unter QNX klappt, dann mit dem 5F FS ausprobieren
Punkt a) habe ich gestern bereits erledigt.
f) ist auch fertig (Checksummenberechnung)
Ihr müsst euch aber noch ein wenig gedulden ... wenn jemand nächste Woche für mich zur Arbeit geht, dann wird es bestimmt nächste Woche fertig 😁
Und weiter geht der Monolog ... 😉
Die Punkte oben habe ich alle noch am letzten WE abgearbeitet, hatte aber trotzdem noch das Problem, dass QNX den 2. Superblock nicht gefunden hat.
Das Problem hat mich dann heute beschäftigt. Ich kann sagen, dass meine Aussage, dass der 2. Superblock immer x Bytes vom Ende der Partition entfernt liegt, falsch war 😁
Nachdem ich die korrekte Berechnung nun rausgefunden habe, geht unter QNX wenigstens der chkqnx6fs (Filesystemcheck) so weit, dass ich endlich sehe, wo ich noch gepfuscht (die Stellen, die mir in meiner Implementierung noch bekannt waren) bzw. anscheinend was noch nicht richtig berechnet habe.
So wie ich erkennen kann, ist es aber nichts sonderlich wildes. Ich denke mal, dass ich die gemeldeten Fehler bis zum WE alle raus habe.
Mal sehen wie weit ich komme, ansonsten werde ich am nächsten WE wohl die Bitmap-Vergößerung auf einem tieferen Level implementieren.
Bei dem Code, den ich bisher habe, klappt die Vergößerung nur im Bereich zwischen 0kb und 131072kb Filesystemgröße.
Zum testen ist ein kleines FS übersichtlicher, daher bin ich da nicht so ganz traurig drüber, dass die Aktion bei kleinen FS ein bisschen einfacher ist.
Eine Migration zwischen einem 0-131072kb und einem 131072-ca. 33GB Filesystem ist mit dem derzeitigen Source auch noch nicht möglich. Ist alles aber nur Fleissarbeit. Die grundsätzliche Logik ist klar.
Bei > ca. 33GB ändert sich da noch einmal was. Das ist im Moment natürlich auch noch nicht fertig implementiert.
Showstopper sehe ich im Moment nicht ... alles grasgrün ... hoffen wir mal, dass es mit dem 3G FS dann auch klappt. Wie gesagt, der Superblock ist ein wenig unterschiedlich, sollte aber natürlich nichts machen, solange ich die nötigen Bytes finde, die im aktuellen QNX6FS verwendet werden und welche ich (im Zuge der Vergrößerung) verändern muss.
Anbei mal ein Bild, um euch bei Laune zu halten 😎
(es zeigt den FS-Check von einem von 16mb auf 32mb vergrößerten FS)
Ähnliche Themen
So ... habe jetzt gerade mal die Blockanzahlberechnung korrigiert, so dass nun die richtige Anzahl an zur Verfügung stehenden Blöcken in die Superblocks geschrieben wird.
Ein Fehler weniger ... muss jetzt aber ins Bettchen 😉
Edit 02:41:
Jaja ... konnte mich immer noch nicht losreißen ... typisch Geek halt ...
Die letzten beiden Bilder sind nun aktuell. Wieder weniger Fehler.
Ich habe auch mal einen Superblock-Check angehangen. Da sieht man, dass die Blockanzahl für ein ehemalig 16mb Filesystem sehr gut aussieht 😁
Zitat:
Original geschrieben von kbankett
So ... habe jetzt gerade mal die Blockanzahlberechnung korrigiert, so dass nun die richtige Anzahl an zur Verfügung stehenden Blöcken in die Superblocks geschrieben wird.
Ein Fehler weniger ... muss jetzt aber ins Bettchen 😉Edit 02:41:
Jaja ... konnte mich immer noch nicht losreißen ... typisch Geek halt ...
Die letzten beiden Bilder sind nun aktuell. Wieder weniger Fehler.
Ich habe auch mal einen Superblock-Check angehangen. Da sieht man, dass die Blockanzahl für ein ehemalig 16mb Filesystem sehr gut aussieht 😁
Freak! Aber ich kann sowas nur gut heißen 😁
Super, dass du dich da so reinhängst - ist ja´schon einiges an know-how nötig dafür...
So ... nachdem ich die ganze Nacht durchgemacht habe gibt es wieder einen neuen Screenshot 😁
Es ist nur noch ein Fehler übrig. Ich bin mir auch relativ sicher, wo der herkommt.
Dafür brauche ich aber bestimmt noch einmal 2-3 Stunden um die nötige Funktion zu implementieren.
Danach kommen dann größere Filesysteme dran. (in der nächsten Stufe passt das dann auch für die 3G Partitionsgrößen ... dann wird es richtig spannend 🙂)
Nu aber erstmal arbeiten, Firmenweihnachtsfeier und wenn ich dann noch tippen kann, dann kommt nächste Nacht auch noch der letzte Fehler noch dran.
Und da wird im QNX-Forum doch glatt behauptet, man könne kein qnx6fs vergrößern *lol*
So, nachdem ich heute den ganzen Tag meine Familie mit ausreichend Valium außer Gefecht gesetzt habe ...
(natürlich nur ein kleiner Scherz)
gibt es ein neues Update.
Der letzte verbleibende Fehler hat mich noch richtig Nerven gekostet.
Insgesamt habe ich da bestimmt 10-12 Stunden dran gesucht. (mag dran liegen, dass ich einfach zu blond bin ... jaja ... schon verstanden 😉)
Bilder sagen aber mehr als Worte 😁
Auf dem Bild ist einmal zu sehen, wie ich hd10t178 (2. Partition auf der Platte / 32mb Größe) erst durch einen Filesystem-Check laufen lasse.
(auf dieser befinden sich die Daten von der 1. Partition, welche 16mb groß ist und deren Daten ich danach durch einen selbst geschriebenen Konverter modifizieren lasse)
Es werden keine Fehler mehr gefunden.
Nächster Schritt ist ein mount. Unter Unix muss man alle Filesysteme mounten, bevor man sie verwenden kann)
Der Befehl "df" steht für device free und zeigt die belegte / zur verfügung stehende Kapazität an.
Wichtig, die Werte sind in 512kb Blöcken. (habe leider vergessen -k anzugeben; mit -k hätte er sie mir bestimmt auch in Kilobyte (1k-Blöcken) angezeigt)
Danach das ganze dann noch einmal mit der "Spenderpartition" hd10t177.
Am Ende dann noch ein Schreibtest, indem ich eine Datei "test.txt" anlege, "123456" reinschreibe und danach den Inhalt der Datei mit "cat" wieder ausgebe.
Wer hätte es gedacht ... es kommt auch wieder "123456" raus 🙂
Ich muss den letzten Schritt noch ein wenig besser verstehen. (den, der mit der letzten Fehlermeldung zu tun hatte)
Ich habe zwar herausgefunden was ihn gestört hat, mir ist aber noch nicht so ganz das "warum" klar.
Dann werde ich das noch in den Konverter einbauen. Diesen letzten Schritt habe ich im Moment noch manuell im Hexeditor durchgeführt.
Danach mal eine größere Partition (>131MB) ausprobieren. Ich denke ich werde mal was in der Größe von der 3G zweiten Partition (~10GB) auf die doppelte Größe ausprobieren 🙂
So long ... stay tuned ...
Kai
Nächste Schritte:
- herausfinden wie die "system area" berechnet wird / abgegrenzt ist
- Rekursive Routine(n) schreiben, die Inodes/Directory-Nodes/Fileverkettungen aus der "Restricted System Area" in den "non-restriced Bereich" bewegt (/bewegen). (und dabei auf dem Weg alle Pointer passend ändert)
(- qnx6fs Defragmentierung imlementieren (wenn ich sowieso gerade dabei bin und sonst schon alles dafür fertig habe))
- Klage vor dem EuGH gegen selbstlöschende Zigarretten anschieben (kann sonst nicht vernünftig arbeiten, weil mir sonst beim tippen immer die Fluppen ausgehen und ich nicht mehr denken kann)
- größere Filesysteme unterstützen
(- Jobangebot von Audi oder sonstwem wegen zu geringen Gehaltsvorstellungen - ja, ich bin durchaus käuflich, und wer meint, dass ich mir im nächsten Schritt nicht das Flash-FS vornehmen werde, ist schief gewickelt; zuerst will und werde ich einen Login-Zugriff auf das QNX haben - ausschlagen *lol*)
- MMI 3G FS Anpassungen und Testläufe
- (automotive taugliche) PATA SSD auswählen (oder irgendeine SATA Alternative angeschlossen bekommen)
- Linux QNX6FS Treiber schreiben (immer noch kein Freiwilliger?)
Habe meiner Frau schon mitgeteilt, dass ich bis zum neuen Jahr beim Linux-Treiber sein will.
Leider hat die "restricted system area" ein paar Implikationen, die einen deutlichen Mehrarufwand erfordern ... nichts unlösbares, aber mehr Zeitaufwand halt ...
Vielleicht sollte ich einfach mal anfangen einen Blog zu schreiben ... hoffe es wird euch hier nicht zu langweilig mit meinem getipsel.
Andererseits denke ich mir, dass man das Thema ansonsten beim lesen ja auch gut auslassen kann 😉
Wieder einen Tag dran verbracht ...
Die Berechnung der "restricted system area" habe ich nun endlich rausgefunden. Ist eine Berechnung über 10 Ecken. In meinen Augen verschwendet QNX da sogar ein paar Blöcke. Sollte man vielleicht mal an die Entwickler melden 😉
Im Konverter habe ich jetzt die Rekursion für die Inodes so weit fertig, dass ich diesen Berechnungswert zwingend brauchte um weiter zu machen, da ich ja wissen muss, bis zu welcher Blocknummer ich die Blöcke verschieben muss, wenn sie dann nach der Vergrößerung in den "restricted" Bereich fallen.
Ausserdem muss ich natürlich auch wissen, wo der Bereich denn endet, damit ich die betroffenen Blöcke dann auch sicher ausserhalb dieses Bereiches hin umbewege.
Weiter hatte ich heute unter der Dusche eine (eigentlich) coole Idee.
Warum nicht einfach nur einen Konverter von 3G FS auf qnx6fs (und umgekehrt) schreiben?
In der Theorie eine super Idee! Deutlich weniger Arbeit als nun Blöcke hin und her zu schubsen und die ganzen Pointer auf die Blöcke zu verbiegen.
Ok, also mal angeschaut, ob ich das so umsetzen kann. Theorethisch ja - praktisch leider nein.
Die Partitionstabelle in Verbindung mit dem 3G FS macht mir da einen Strich durch die Rechnung.
QNX6 verlangt anscheinend zwingend einen Bootblock am Anfang jeder Partition. Das 3G FS hat am Anfang jeder Partition keinen Bootblock - jedenfalls weigert sich QNX die Superblöcke zu finden, wenn ich ein 3G FS versuche zu checken. (Wenn für dieses Problem jemand eine Lösung finden sollte, dann immer her damit! Den FS-Konverter von 3G auf QNX und umgekehrt hätte ich wahrscheinlich in ein paar Stunden fertig)
Ok, dachte ich mir, dann halt die Partition um 0x2000 (Bootblockgröße) vergößern und 0x2000 Bytes am Anfang hinzufügen ... tja, geht nur leider nicht, da man eine Partition - jedenfalls bei heute üblichen Festplattengrößen - nicht nur um 8192 Bytes (0x2000) vergrößern kann.
Ändert sich die Partition aber mehr als diese 0x2000 Bytes, so muss man das FS vergrößern, damit die Struktur wieder passt. (und da schliesst sich der Kreis wieder und mir ist klargeworden, dass ich bisher durchaus nicht auf dem Holzweg gewesen bin)
Wäre halt schön gewesen ... also wie gehabt weiter ...
Interessante Sache die du dir da an die Brust genommen hast.
Eins verstehe ich jedoch nicht. Warum wird das von Audi aus so kompliziert gemacht?
Welche Vorteile hat das im Vergleich zum z.B. normalen NTFS oder ähnlichen Systemen?
Sorry für die Frage, bin leider nicht vom Fach.
Gruß
Eugen
Es ist nicht kompliziert gemacht worden.
Ehrlich gesagt ist ein NTFS-Dateisystem deutlich komplizierter gestrickt. (was meinst du, warum es immer noch keinen nativen, schreibfähigen NTFS-Treiber unter Linux gibt)
Naja, Harman-Becker ist der Hersteller des Systems und war damals auch Besitzer von QNX.
Mittlerweile ist QNX ja von RIM augekauft worden.
Wenn man so ein System wie das MMI 3G entwickeln will, dann stellt sich direkt die Frage auf welcher Basis man dies tun möchte.
Ein eigenes Betriebssystem entwickeln - viel zu aufwändig.
Windows verwenden - läuft nicht auf Embedded-Plattformen und ist viel zu Resourcenintensiv.
Linux - ja, könnte man wahrscheinlich tun. Linux war damals im Embedded-Bereich aber noch nicht so weit wie heute.
QNX war da in meinen Augen schon keine falsche Wahl. Läuft auf so ziemlich jeder Hardware, niedrige Resourcenanforderungen, Echtzeitfähigkeit, Java verfügbar, Browser etc. alles da.
Also denke ich mal, dass man beschlossen hat QNX zu kaufen. Nachdem der Fokus nicht mehr auf QNX lag, hat man es an RIM verkauft.
Das QNX4 Filesystem kann man in meinen Augen vergessen. Da ist das qnx6fs schon deutlich weiter.
Bei der Auswahl hat aber natürlich nie die Möglichkeit von einem anderen Betriebssystem aus zugreifen zu können eine ernsthafte Rolle gespielt.
Alles in allem also schon gut erklärbar. Einen bösen Willen kann ich da wirklich nicht erkennen.
ich versteh davon zwar genauso wenig wie wenn du kyrillisch schreiben würdest, aber ich find es genial wie du dich da dahinterklemmst!
Dafür von mir alle 10 Daumen hoch!!
😁😁😁😁😁😁😁😁😁😁
Kai, sehr geile Sache. Lese immer mit, weil es mich auch sehr interessiert! Freut mich das Du schon so weit gekommen bist.
So, bin diese Nacht wieder gut vorangekommen.
Es funktionieren nun alle bisherigen Schritte automatisiert. (und es kommt am Ende sogar noch ein gültiges Filesystem raus 😉)
Mein Konverter kann nun automatisiert die Größe des neuen reservierten Bereichs auf das Byte genau aus Superblock-Feldern berechnen, die Blöcke im (nach FS-Vergößerung) reservierten System-Bereich (recursiv) identifizieren, diese identifizierten Blöcke umbewegen (aus dem reservierten Bereich raus) und dann sowohl die File-Pointer in den Inodes, als auch die Bitmaps dementsprechend anpassen.
War mal wieder ein echt harter Bitkampf (hatte ich eigentlich schon erwähnt, dass ich Bitmaps hasse?)
Irgendwie will mein ddd (ein grafischer Debugger für Linux / ein grafisches Frontend für gdb) nicht so recht. Von daher kämpfe ich mich zu debugging durch seitenlange fprintf(stdout) Ausgaben, wobei ich mir alle relevanten Variablen auf die Konsole dumpe.
Egal. Früher gab es auch keinen grafischen Schnickschnack 😉
(mit gdb auf der Kommandozeile habe ich mich nie angefreundet - ist mir jetzt einfach zu viel Aufwand da dann jetzt erst einmal einzusteigen)
So, was sagt denn die ToDo Liste:
- Erkennung des Superblocks mit der höchsten Seriennummer (Ja ... Im Moment vertraue ich auf ein frisches Filesystem. Bei diesem haben beide Superblöcke die selbe Seriennummer, von daher habe ich bisher einfach immer den ersten Superblock als Master genommen)
- Ausgiebige Tests mit vorgefüllten und migrierten Filesystem (maximale Inode-Belegung, große Files etc. / insbesondere bei großen Files könnten durchaus noch Ostereier warten ... mal sehen, ob meine Recursionen auch sauber mit einer Fileverkettungsbaumstruktur klarkommen / mehr als 16 Blöcke Filegröße (16kb) zieht weitere Baumebenen nach sich, in denen sich Zeiger auf potentiell zu verschiebende Blöcke finden)
- Erweiterung auf den nächsten Baumlevel um die 3G Größenordnung adressieren zu können (Bitmaps, Inodes)
- Anpassung auf die 3G FS Struktur (da wird das mit dem Debuggen richtig schwierig, da das sichtbare Ergebnis ja leider äußerst binär ausfällt - Jukebox ist grau hinterlegt (funz nicht) oder funzt)
- Irgendwann sollte ich auch mal mehr als nur die 2. Partition unterstützen. Im Moment hole ich mir nur die Partitionsdaten von der 2. Partition (dort liegt beim 3G ja die Jukebox). Das ist aber eine kleine Fingerübung. Irgendwann, wenn ich zwischendurch mal Langeweile habe ...
So, nu noch ein bisschen Schlaf und dann morgen weiter im Programm.
Stay tuned ... 😉