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 :)
Ähnliche Themen
171 Antworten
Soooo, alles durchgelesen, vieles nicht verstanden (das geht wohl den meisten so), aber volle Hochachtung für deinen Ergeiz und deine geopferte Zeit! Finde ich wirklich Klasse, auch wenn du dir dafür nix kaufen kannst ;)
Mich stört in meinem A6 4G auch die zu kleine Jukebox Größe, gibt es hier denn auch schon einen Ansatz? Wo ist denn beim MMI 3G Plus die HDD verbaut? Ich würde meine wohl zum Test bereit stellen.
Grüße
Frank
Die Festplatte ist in der Unit in der Mittelkonsole unter dem DVD Laufwerk verbaut.
Im 3GP ist eine 60 GB IDE Platte, leider ist die größte verfügbare ein 100GB Platte aus der Automotiv Serie
Es braucht keine Automotive Series.
Ich bin monatelang mit einer stinknormalen Samsung 320GB Platte rumgefahren.
Ist was passiert - nein.
Und selbst wenn? Wenn man sich vorher ein Image zieht, dann kann man ja jederzeit notfalls wieder eine Platte an den Start bringen ;)
Jaja, nun darf demnächst ein netter Kollege in seinen Postings wieder herziehen... :)
Meintwegen nehmt doch auch den sündhaft teuren Automotive Krempel. ;)
Ich würde aber wirklich eine 128GB SSD verbauen.
Das kann ich persönlich nur empfehlen.
Es gibt natürlich auch noch eine passende 256er SSD. Darüber wird es dann mit SSD schwieriger.
Vergrößern kann ich.
Maximale Titelanzahl anheben kann ich auch.
Und... tata!... das ganze in jeder 5F Unit. Ob nun VW, 3G, 3GP, aktuellem 4G, 4H, 4F, 8K FL was auch immer - sucht es euch aus :)
Ich glaube ich muss da auch mal ein Thema im 4G Bereich eröffnen. Hier findet das ja (fast) keiner.
Zitat:
Original geschrieben von kbankett
Vergrößern kann ich.
Maximale Titelanzahl anheben kann ich auch.
Und... tata!... das ganze in jeder 5F Unit. Ob nun VW, 3G, 3GP, aktuellem 4G, 4H, 4F, 8K FL was auch immer - sucht es euch aus :)
Hmm, können wir das denn auch? Oder bietest Du das als Dienstleistung an :)
Naja, wenn man sich den Linux qnx6fs Treiber anschaut - und ich habe im Kernel Source (ab dem 3.4er Linux Kernel ist mein Treiber offiziell im Sourcecode enthalten) sogar eine Dokumentation geschrieben - dann hat man eigentlich alle Informationen an der Hand, um auch einen Resizer zu schreiben.
Dann könnt ihr das auch.
Ein paar Infos finden sich ja auch hier in dem Thema. Ich habe ja eigentlich immer eine recht offene Informationspolitik betrieben.
Es gibt auch noch andere Wege, die zum Ziel führen... vielleicht sogar einfacher als über den eigenen Resizer - das ist aber hier im Thema natürlich OT ;)
Ansonsten biete ich das gerne auch als Dienstleistung an. Einfach eine PN an mich, dann wird man sich sicherlich einig.
Zitat:
Original geschrieben von kbankett
Es braucht keine Automotive Series.
Ich bin monatelang mit einer stinknormalen Samsung 320GB Platte rumgefahren.
Ist was passiert - nein.
Und selbst wenn? Wenn man sich vorher ein Image zieht, dann kann man ja jederzeit notfalls wieder eine Platte an den Start bringen ;)
Für uns ist das mit den normalen Platten auch kein großes Problem, so wie du schreibst ein dd und schon ist wieder eine neue am Start.
Wenn aber viele Jahre ruhe sein sollte, würde ich schon die Automotiv nehmen, so viel teurer sind sie ja auch nicht ;)
Hallo,
nachdem ich mich nun enige Zeit durch den höchst interessanten Thread gelesen habe
ersteinmal DANKE und grossen Respekt an "kbankett " !!
Das war eine ordentliches Stück Arbeit.
Ich weiss nicht ob Du an den FS Treibern noch weiterarbeitest.
Das QNX6 ist ja dank Dir mittlerweile im Kernel.
der QNX-EFS Patch meckert etwas wenn man ihn gegen den aktuellen
3.10.5 kernel laufen lässt.
include/linux/magic.h
ist jetzt unter
include/uapi/linux/magic.h
in der "inode.c"
d_alloc_root
wurde durch
d_make_root
abgelöst.
Evtl magst du es ja nach pflegen.
So jetzt muss ich erstmal fertig kompelieren, dann wird getestet.
Danke Dir nochmal
vG
Kopuliert ruhig weiter.
Ich gehe zum bahnhof, dass ist alles was ich verstanden habe.
Mein respekt an euch :)
Ich bleibe dann doch lieber bei löcher bohren und stopfen....
Zitat:
Original geschrieben von bertelsmanngmxde
nachdem ich mich nun enige Zeit durch den höchst interessanten Thread gelesen habe
ersteinmal DANKE und grossen Respekt an "kbankett " !!
Das war eine ordentliches Stück Arbeit.
Ja, durchaus :)
Danke!
Du darfst mich aber auch ruhig Kai nennen ;)
Zitat:
Ich weiss nicht ob Du an den FS Treibern noch weiterarbeitest.
Das QNX6 ist ja dank Dir mittlerweile im Kernel.
der QNX-EFS Patch meckert etwas wenn man ihn gegen den aktuellen
3.10.5 kernel laufen lässt.
include/linux/magic.h
ist jetzt unter
include/uapi/linux/magic.h
in der "inode.c"
d_alloc_root
wurde durch
d_make_root
abgelöst.
Ja, das mit dem magic.h habe ich bei mir bereits nachgepflegt.
Die Sache mit dem d_make_root muss relativ neu sein.
Bisher bin ich bei meinen Kerneln da noch nicht drüber gestolpert.
Warum machst du nicht einen neuen Patch und stellst ihn hier rein? ;)
Zitat:
Evtl magst du es ja nach pflegen.
Grundsätzlich ja. Die Resonanz hier war nur so gering, dass ich hier nicht mehr wirklich was veröffentlicht habe.
Eine Sache habe ich bei mir im EFS-Treiber auch noch erweitert.
Das PU->LU Mapping hatte ich damals noch nicht so ganz durchschaut.
Die PUs sind aber nicht statisch 1:1 auf LUs gemappt, sondern können dynamisch in andere Flash-Bereiche (wear leveling) bewegt werden.
Bei den EFS Files von Update-DVDs ist das kein Thema, da ein frisch erzeugtes EFS anscheinend immer PU=LU hat. Von daher an dieser Stelle auch nicht so wirklich spannend und daher habe ich (in Kombination mit der geringen Interessenlage) diese Erweiterung nie gepostet, sondern nur implementiert, als ich persönlich einen Bedarf hatte.
Zitat:
So jetzt muss ich erstmal fertig kompelieren, dann wird getestet.
Dann lass mich mal wissen, ob alles klappt.
Bis auf die Kernel-Änderungen (das ist halt der Nachteil, wenn ein Treiber nicht offiziell im Kernel enthalten ist), hat sich bisher aber (bis auf das Thema PU-LU Mapping) noch keinerlei Problem gezeigt :)
Ehrlich gesagt, hat mich das qnx6fs aber deutlich mehr Nerven gekostet.
Den EFS Treiber habe ich dann in knapp 3 Tagen "mal eben" runtergeschrieben. (inklusive des nötigen reverse engineerings)
Hi Kai,
ich hab echt schon lange keinen Patch mehr erzeugt,
hoff ich habs jetzt auf die Schnelle nicht verbockt.
Ist im Anhang.
Deine Aktualisierungen würden mich natürlich interessieren, auch wenn ich gestehen muss, dass
ich im Moment nur Erahnen kann auf was Du dich dabei beziehst.
Ich versuch gerade noch das IFS zu verstehen, in der Hoffnung es irgendwann auch erzeugen zu können
nicht nur zu dumpen.
lg
Albert
Hi Albert,
Am Ende von dem Patch sind noch Relikte, welche überflüssig sind. (auto.conf / auto.conf.cmd etc.)
Diese solltest du vielleicht noch entfernen ;)
Ansonsten sieht das sehr gut aus! Wirklich gut gemacht!
Was hast du mit dem IFS denn vor?
Grüße,
Kai
Hi,
bin grad ned zuhause
aber ich räum morgen mal auf dann poste ich ihn nochmal.
IFS - verstehen :-)
Startskript ist ja hier z.B. drin, (/proc/boot/.script)
um den QNX Bootprozess zu verstehen
war das schon mal gar nicht so verkehrt.
Dachte es wäre ein guter Einstieg :-)
Um sinnvolle Modifikation zu machen ist das EFS das interessantere,
das ist mir mittlerweile klar :-)
lg
so... aufgeräumt
ist auch gleich viel kleiner :-)
jetzt aber gute Nacht
VG
Naja, es kommt halt drauf an, was man machen möchte.
Im IFS sind so ziemlich alle Binaries und Libraries.
Das Problem mit dem IFS ist nur, wenn man einen Fehler bei der Modifikation macht, dann bootet die Unit nicht mehr und man kann sie so nicht wiederbeleben.
(wollte nur darauf hingewiesen habe ;))
Ja, der Patch sieht augenscheinlich nun gut aus :)
Hallo, gibt es hier inzwischen Neuigkeiten ?
Gibt es eine Anleitung wie man die Titelanzahl erhöht und die größe der Jukebox ?
Der treiber im Linux Kernel ist ja nur RO und nicht RW.
lg