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
Ja, das war ja direkt das, was ich zuerst ausprobiert habe.
Ich habe ein 1:1 Image auf eine 320er Platte gespielt und das hat natürlich funktioniert.
Eine größere Partition mit einem normalgrossen Filesystem habe ich derzeit bei mir eingebaut. Funktioniert auch.
So, ich habe wieder etwas weiter gewerkelt.
Auch wenn ich geschrieben hatte, dass es nicht nach einem QNX6 Filesystem aussehen würde, so muss ich diese Meinung nun revidieren.
Ich kann auf jeden Fall zwei Superblocks identifizieren, die anscheinend abwechselnd verwendet werden und wohl auch eine Sequenznummer enthalten.
Ich habe einfach mal einen Dump vor dem Löschen eines Files gezogen und einen danach.
Diese Operation sollte bei einem Filesystem einfach minimale Auswirkungen habe und daher einen Vergleich vereinfachen.
Das verwendete FS verhält sich wie eine Splittergranate. (ich bezeichne das jetzt einfach mal so *g*)
Die Änderungen werden nicht in die existierenden Bitmap-/Inodes geschrieben, sondern es werden Kopien derer mit den Änderungen abgelegt und danach verlinkt.
Ebenso verhält es sich mit der Supernode. Es werden Daten in die jeweils inaktive Supernode geschrieben und diese dann aktiv geschaltet.
Leider macht es die Analyse nicth gerade leichter, da durch eine einfach FS-Operation an vielen Stellen Änderungen passieren und da man nun die Verlinkungsstruktur verstehen muss, um z.B. an die für die Speicherplatzbelegung sehr wichtigen Bitmap-Nodes ranzukommen und diese Struktur zu erweitern.
Ich werde heute mal ein taufrisches QNX6 FS auf einer anderen Platte erzeugen und mir anschauen, wie sich dieses verhält. Vielleicht sind die Unterschiede ja garnicht so gross ...
Hier ein aktueller Status-Update. (hoffe ich langweile euch nicht zu sehr ...)
Die beiden Superblöcke befinden sich an den Adressen (relativ in der Partition) 0x0 und 0x2a3183000 (0x1200 vor Ende der Partition / des Filesystems).
Beim originalen QNX6 befindet sich der 1. Superblock an 0x2000. Dies ist auch der erste Grund, warum ein Mount unter QNX nicht funktioniert.
Da die restliche FS-Struktur genauso wie beim QNX6 aussieht, war ich gestern erst voller Hoffnung, dass ein Verschieben des 1. Superblocks an die Position 0x200 vielleicht ja schon reichen könnte um das FS unter QNX zu mounten.
Gesagt, getan - funktioniert aber leider nicht. (es kommt eine Meldung "Filesystem villeicht nicht vollständig formatiert" - oder so ähnlich)
Ok, dann habe ich die Superblöcke eines QNX6FS und des 3G-FS gegeneinander gelegt und musste leider rausfinden, dass es sich beim 3G Filesystem entweder um eine modifizierte Version des QNX6FS handelt oder - was ich, so wie es aussieht, für deutlich wahrscheinlicher halte - das MMI 3G FS ein früher Entwicklungsstand des QNX6FS ist.
Immerhin, ein paar Felder konnte ich dabei schon identifizieren:
0x8 - 2bytes superblock sequence number
0x14 - 2bytes Checksum? (da bin ich mir noch nicht sicher)
0x34 - 4bytes usable total size of filesystem (1k blocks)?
0x40 - 4bytes total size of filesystem (1k blocks)
Die Pointer in den Bitmap und Inodes sind 4 Bytes lang. Die Blockgröße des FS ist 1024 Bytes.
Ich bin nur noch nicht ganz hinter die Adressierung gekommen. Fakt ist die in den 4 Byte Pointern ist das MSB (most significant bit) rechts und nicht links.
Beispiel: AB C4 93 00 entspricht 93 C4 AB = (dec) 9684139
Ich nehme mal an, dass in dem Beispiel diese Zahl für die Blockadressierung steht, also für die Position in der Partition mit der Blockgröße von 1024 multipliziert werden muss.
Ob da jetzt aber noch ein Offset hinzukommt, oder nicht, da bin ich mir aktuell noch nicht sicher. Dem muss ich als nächstes nachgehen.
Weiter ist wichtig die Pointer im Superblock, welche in die nächte Verkettungsebene zeigen, zu identifizieren.
Um so ein Filesystem zu vergrößern muss man auf jeden Fall die Anzahl der Bitmap-Nodes vergrößern. (Inodes unter Umständen auch - könnte aber auch ohne gehen, dann kann man nur nicht analog mehr Dateien im FS ablegen)
Achja, die "total size" Werte in den Superblöcken anzupassen braucht ihr nicht mehr ausprobieren. Das habe ich natürlich auch schon ausprobiert. (nur der Vollständigkeit halber, ich war mir auch vorher zu 99.999% sicher, dass dies alleine nichts bringen wird)
So viel zu meinem Wochenende *lol*
Kai
Zitat:
Original geschrieben von kbankett
Hier ein aktueller Status-Update. (hoffe ich langweile euch nicht zu sehr ...)
Alles andere als das, ich finde das Thema höchst spannend!! Leider ist die "Betriebssysteme" Vorlesung schon zu lange her um selbst noch auf derlei Gedanken zu kommen (zum Glück kann ich aber noch folgen :-P).
Gruß,
Klayman
Ähnliche Themen
So, nachdem ich mal wieder ein paar Tage Luft hatte, habe ich mich mal weiter an die Sache gesetzt.
Die Adressierung im FS habe ich jetzt im Griff. Directory Einträge auch.
Die Blockgröße ist 512 Byte.
Hauptverzeichnis, Unterverzeichnisse, Files, Blockverkettungen, Filegrößen, lange Dateinamen, Zugriffsrechte, Zeitstempel etc. dito.
Nächster Schritt ist das Bitmap-File, da ich denke, dass dieses bei einer FS-Vergrößerung auch mit vergrößert werden muss.
Ich muss mir auch noch anschauen, an welcher Stelle der Superblock auf das Root-Verzeichnis verweist.
Vielleicht sollte ich dann mal einen Linux-Treiber schreiben? 😉
Es geht voran ...
Hallo kbankett
ich verstehe zwar nur Bahnhof 😁 , finde das ganze Projekt aber sehr spannend & interessant.
Werde Deine Schritte weiter verfolgen und drücke Dir (und uns 😉 die Daumen das Du es zum laufen bekommst...
Meinst Du nicht das es zu längeren "Anspieldauern" kommen wird, wenn Du sagen wir mal 200GB Musik auf die Platte
haust und dann davon etwas abspielen willst? Wie gesagt bin Laie und das kam mir halt gerade so in den Sinn...
Viele Grüsse und "Daumen hoch"
Pertin
Nein, unter Windows dauert es ja auch nicht länger ein File zu öffnen, wenn du eine größere Festplatte hast 😉
Naja, es ist noch ein langer Weg ... (und das WE fast rum)
Seit ihr eig. noch weiter gekommen in dem bereich?
Ja, durchaus.
Ich hänge derzeit an dem Problem, dass der Superblock eine Checksumme enthält.
Leider habe ich bisher noch nicht herausgefunden, wie diese berechnet wird.
CRC32 (selbst mit brute force über den gesamten Suchraum, um eine "Grundadresse" zu finden), XOR, Summenbildung etc. habe ich schon durchprobiert.
Man kann sich einfach ein QNX6 (Live CD) runterladen und dann auf einer Festplatte ein QNX6fs anlegen.
Wenn man sich dann die beiden Superblöcke (1. findet man irgendwo bei 0x2000, 2. findet man, wenn man vom Ende der Platte ein bisschen zurück geht) anschaut, so sieht man, dass nach einem Schreibzugriff immer eine Sequenznummer erhöht wird.
Die höhere Sequenznummer identifiziert den derzeit aktiven Superblock.
Spannender ist aber - ich meine so auswendig, dass ab dem 4. Byte ein 4 Byte langer Wert kommt, der sich nach jeder Superblockänderung (nach jedem Schreibzugriff) wirklich komplett ändert.
Verändert man probeweise nur ein Bit entweder irgendwo im Superbock, so wird das FS vom MMI nicht mehr als gültig angesehen. Was noch einmal bekräftigt, dass es sich bei den 4 Bytes um eine "Checksumme" handelt.
Mir schweben verschiedene Ansätze vor, mit der Sache voranzukommen. Man könnte z.B. mit einem Disassembler das mkqnx6fs binary zerlegen und sich dort anschauen, wie diese Checksumme berechnet wird.
Bisher hat mir dafür nur die Zeit gefehlt ... 🙁
(neben einem guten Disassembler, der auch mit QNX Binaries klarkommt. Knapp 1000 EUR war es mir dann aber auch nicht wert mir einen zu kaufen - also wer Zugriff auf so etwas hat, gerne eine PN schicken)
Ansonsten habe ich praktisch schon das ganze qnx6fs zerlegt. Ich kann direkt das Hauptverzeichnis finden, in Unterverzeichnisse gehen, Filenamen finden, die zu den Filenamen passenden Verkettungen verfolgen, Bitmap-Blocks lesen etc. etc.
(alles natürlich im Moment noch manuell - im Hexeditor)
Ohne die Checksumme im Superblock berechnen zu können, komme ich aber nicht weiter, da jeder Schreibänderung am FS zwingend eine Superblockänderung nach sich zieht.
Ist die Jukebox nicht auf 4000 Dateien beschränkt?
Demnach würde eine größere HD nur bedingt was bringen.
Gruß
Hallo Kai!
Ich habe auch vor geraumer Zeit (fast 2Jahren) mal versucht die verbaute HDD zu ersetzen, bin aber schon bei der Suche nach einem gleichwertigen Ersatz größerer Kapazität gescheitert. Die einzigen die an die beachtlichen Daten, der bei mir verbauten Toshiba Festplatte heran kamen waren SSD´s. Einen Betriebstemperaturbereich von -30 bis +85°C und 800G Stoßbelastung im Betrieb sind schon eine echte Hausnummer und der eingebaute Stoßsensor mit Antischockelektronik ist schon sehr speziell. Da kann man den ganzen PC-Schrott eigentlich nur weglegen, wenn man bei unseren schlechten Straßen länger Freude an Musik und Navi haben möchte. Habe hier mal die technischen Daten meiner Festplatte herausgesucht: --> Daten Hast Du eigentlich das gleiche Festplatten Modell? Mein MMI ist MJ2009.
Ich kann leider die gemachten Erfahrungen von Messknecht01 nicht teilen. Mir ist erst vor 3 Wochen eine 2TB Platte (ausgeschaltet) von einem Mediaplayer aus nur 50cm Höhe vom Stuhl gefallen und leider Exitus, die Köpfe schlagen an. 😠
Ich habe mich, bei dem derzeitigen Preisniveau der SD Karten, mit den beiden 32GB-Karten im MMI eigentlich zufrieden gegeben. Der Preis für die schnellen SSD´s ist immer noch ganz schön hoch im Vergleich zu den SDHC-Karten. Ich glaube, ich könnte den Jahresurlaub im Auto verbringen und würde es nicht schaffen, alle Titel zu hören.😉
Ich verfolge trotzdem weiterhin mit großem Interesse Deine Bemühungen, etwas Licht in die Geheimnisse der MMI-Festplattenverwaltung zu bringen. Wenn mich nicht alles täuscht, hatte ich im Hiddenmenü gesehen, das man die Quelle von der das Navi sich die Kartendaten holen soll auswählen konnte (HDD, SD, USB, DVD). Demzufolge müssten ja auch alle Treiber dafür im Flashspeicher vorhanden sein, wahrscheinlich betrifft das aber nur die Navi-Datenquelle, nicht die Jukebox.
Naja, kann schon sein, dass trotzdem nur maximal 4000 Dateien möglich sind, keine Ahnung. Ausprobiert habe ich das noch nicht.
Ja, wenn dann würde ich auch eine SSD einbauen. Eine SATA SSD hätte ich sowieso noch rumliegen. Leider hat das 3G ja noch einen PATA IDE Anschluss, ansonsten wäre da sowieso schon eine SSD drin.
Von den PATA SSDs sind nicht so viele gebaut bzw. verkauft worden.
Mittlerweile bekommt man die aber auch schon zu einem annehmbaren Preis.
Wie auch immer. Für Tests reicht auch eine Festplatte mit schlechteren Spezifikationen. Normale 2.5" Festplatten in diesem Kapazitätsbereich bekommt man ja auch schon nachgeworfen. Selbst wenn mal eine den Löffel abgiebt, hat man ja noch am selben Tag einen Ersatz.
Klar, ich verwende auch SD-Karten. Reicht mir soweit auch. Trotzdem wäre es nett auf der Platte auch lesen und schreiben zu können 😉
Achja, die Jukebox scheint fest auf qnx6fs gestellt zu sein. Ich habe alle möglichen anderen Filesysteme ausprobiert - es wird nichts anderes erkannt. (ja, ich gehe auch davon aus, dass die Treiber für andere Filesysteme grundsätzlich vorhanden sein müssen)
Es handelt sich zusätzlich um ein modifiziertes qnx6fs. Ein aktuelles mit QNX erzeugtes qnx6fs funktioniert leider auch nicht 🙁
(sonst wäre die Sache ja auch ein Kinderspiel)
In allen 3Gs sind diese Toshiba-Festplatten verbaut. Schön ist auch, dass diese Platten nicht so heiss werden.
Ich hatte mal eine Zeit lang eine Samsung eingebaut, die aber leider deutlich wärmer wurde.
Wenn muss man schauen, dass man eine Festplatte nimmt, die wenig Strom verbraucht. Die Luftzirkulation in der Rechnereinheit ist sehr schlecht.
Ja, das ist genau auch mein Problem, SSD mit SATA und mit dem Adapter passt sie nicht rein. Mal sehen ob ich da noch was basteln kann.
Grüße aus dem Windmühlenland
Ja, mit einem Adapter das wäre natürlich schön.
Man könnte natürlich auch einen Adapter von 2.5" PATA auf 3.5" PATA nehmen - da gibt es ja passende Kabel (früher z.B. für Amiga 600/1200), und dann weiter von PATA auf SATA über einen Wandler.
SATA kann man dann ja ein kurzes SATA Kabel nehmen.
Die Platte müsste man dann natürlich wahrscheinlich irgendwie anders fixieren und für den Strom natürlich auch noch was legen.
Edit #1:
Man könnte natürlich auch versuchen ein IDE -> CF-Flash Kabel zu verwenden und eine große CF-Karte dran zu stöpseln.
Sowas gab es nämlich auch mal für die besagten Amigas.
Muss ich doch gleich mal nach suchen was große CF Karten so kosten ... 😉
Edit#2: Ok, die großen CFs sind auch nicht so wirklich günstig. Wenn man natürlich nur einen Ersatz für die 40GB sucht, reichen sie von der Kapazität aus und sind auch groß genug. (64GB)
Wäre dann aber eine "saubere" Sache 🙂
So, ich habe a) die passenden Tools "gefunden" und b) endlich mal ein wenig Zeit gehabt.
Die Checksummenberechnung (crc32) habe ich nun in Assemblerform vor mir; die Polynomtabelle auch.
So wie es scheint wurde eine abgeänderte Polynomtabelle verwendet.
Mal sehen ... hoffe ich komme am WE dazu die Routine in C nachzubauen - nehme aber an, dass es sich um eine normale crc32-Routine handelt. Wenn sich das bewahrheitet, dann sollten die Anpassungen schnell gemacht sein 🙂
Danach dann mal schauen, ob ich endlich ein Bit im Superblock ändern kann, und das Filesystem danach noch gemountet wird.
Ich kann nur hoffen, dass zwischen QNX6 und dem 3G an der Berechnung nichts geändert wurde.
Die relevanten Auszüge sind angehangen. Vielleicht findet sich hier ja ein Freiwilliger, der diesen Code gegen eine normale crc32-Routine checkt und mir die Polynomtabelle mal rausschreibt, so dass ich sie direkt übernehmen kann.
Noch lieber wäre mir natürlich gleich ein fertiges C-Programm, welches so arbeitet, wie die originale Routine 😉