mmc-Tool ohne mmc-Kernel mit Samsung evo Karten

**user234** · 12.03.2021, 08:53

Hallo zusammen,

ich bin gerade dabei für mein RNS310 die SD-Karte mit Kartenmaterial von V11 auf V12 upzudaten. Mangels eines passenden Rechners, der mmc-Kernel untertützt (mein T-460 Rechner von Lenovo ist zu neu dafür) bin ich mit einem nicht gepatchten Kernel und einem aktuellen Linux Mint (sprich Ubuntu) unterwegs und bediene mich dem gepatchten mmc-Tool, welches den herunergeladenen Karten beiliegt. Ich habe auch drei Samsung evo Karten "made in Korea", die dem Anschein nach aus den Jahren vor 2016 stammen sollten, aber 100% sicher bin ich mir dabei nicht, weil ich das entsprechende Tool SD-Info mangels gepatchten Kernels nicht habe.
Bei allen drei Karten lässt sich die CID mit dem der Karten beigelegten mmc (gepatcht) ändern. Man bekommt auch die CID danach mit "cat /dev/..." erfolgreich ausgelesen, die SD-Karte samt Kartenmaterial wird aber von RNS-310 nicht immer erkannt. Das Verhalten ist nicht deterministisch und ich verstehe nicht, woran es liegen kann:
1. Karte. Ursprunglich mit V11 und dem gesetzten CID hat sehr lange funktioniert, bis ich einmalig mit gparted die fat32-Partition gekürzt und dann wieder auf die gesamte Kartenlänge angepasst hatte. CID mehrfach hin und her geändert von V11 zu V12 und wieder zurück. Mittlerweile wird diese Karte nicht mehr von RNS310 als Kartenmaterial erkannt
2. Karte. Scheint etwas mehr fehlerhafte Sektoren zu haben und ist daher etwas kürzer, als zwei andere. Dadurch kann man z.B. die SD-Karte 1 oder 3 nicht mit partclone (mit clonezilla) vollständig auf diese SD-Karte platzieren. Zu clonezilla bin ich aus Verzweiflung gegriffen, als meine anderen Versuche zu keinem Erfolg führten. Mit dieser Karte hatte ich ursprünglich die meisten Sorgen, hatte sie mehrfach formatiert und mit clonezilla darauf Abbild der 1. Karte geladen und alles Mögliche. Die Karte ging nicht im RNS 310! Bis ich gestern dadrauf V12-Daten geschrieben hatte und die CID geändert hatte. Jetzt wird diese Karte plötzlich von RNS310 erkannt! Woodo, aber wirklich.
3. Karte. War ursprünglich in meinem Raspberry Pi drin und entsprechend formatiert. Die Karte habe ich platt gemacht und zunächst mit clonezilla dadrauf Abbild der 1. Karte übertragen, CID geändert. Ging auf Anhieb, Karte von RNS310 erkannt. V12-Daten, drauf, CID geändert => Karte von RNS310 erkannt. Ist derzeit meine produktive Karte sozusagen und die fasse ich nach Möglichkeit nicht mehr an.

Meine Fragen:
a) Kann sein, dass mmc-Tool mit den neuen nicht gepatchten Kernels vielleicht doch nicht so richtig funktioniert und die Karte doch irgendwie falsch beschreibt?
b) Ist die Methode mit "cat /dev/..." die CID auszulesen wirklich sicher und liest wirklich die Daten von der SD-Karte und nicht aus irgendeinem Zwischenpuffer, wo mmc-Tool vorhin die Werte geschrieben hat?
c) Ich formatere die SD-Karten mittlerweile mit gparted und mache da auch die check-Prüfung der Partition inkl. Reparatur damit. Manchmal wird die Reparatur auch tatsächlich durchgeführt, wobei ich ehrlich gesagt nicht verstehe, wobei sich die SD-Karte "zerschiesst", denn ich hänge die immer und überall sauber aus, außer in RNS310.
d) Kann es sein, dass der Hack mit dem Setzen der CID auf evo-Karten nicht immer funktioniert?

Ich versuche mir demnächst irgendeinen Rechner zuzulegen, auf dem der gepatchte mmc-Kernel aus dem Jahre 2016 läuft und der Kartenleser auch unterstützt wird. Dann bin ich nicht so im Blindflug unterwegs. Es könnte aber etwas dauern.

Übrigens, neben den beschriebenen Methoden hier mit speziellen Notebooks und Handys habe ich noch eine Idee, Raspberry Pi dafür zu verwenden. Denn rein theoretisch hat er doch eine native mmc-Unterstützung und man kann dem RPI beibringen, vom USB-Stick zu booten. Dann wäre mmc-Schnittstelle ja frei. Allerdings muss ich dafür einen entsprechenden gepatchten ARM-Kernel dann finden, was vermutlich sehr schwierig sein wird. Außerdem ist RPI eher Debian und nicht Ubuntu basiert, was zusätzliche Abhängigkeitsprobleme mit sich bringen kann. Aber so einen RPI dafür zu ertüchtigen wäre wirklich nicht schlecht, wenn es denn gehen würde.

**jori** · 12.03.2021, 10:39

@Link nur für registrierte und freigeschaltete Mitglieder sichtbar. - deine probleme die da hast, haben nichts mit dem (nicht vorhandenen) gepatchten kernel zu tun. das gepatchte kernel ist nur nötig um 'gelockte' sd-karten für das RNS315 (amundsen+, etc..) wieder entsperren zu können. für das ändern der CID empfehle ich gerne 'evoplus_cid', das ist eindeutig die bessere wahl. das 'mmc' tool ist von irgendjemanden für dieses vorhaben nachträglich gepatcht worden. der aber offensichtlich auch nur ein imaginäres halbwissen hatte und nicht wirklich wusste was er da tat.

was das erstellen einer navigations-karte für das RNS310 angeht, schlage ich prinzipiell vor, als erstes immer zu versuchen die CID zu ändern, wenn das mit einer karte funktioniert, dann im nächsten schritt die jeweilige sd-karte auf ein maximum von ca. 8gb zu partitionieren. das entspricht in etwa der grösse, mit denen die original vw-karten ausgeliefert werden. danach ein 'slow-format' für die jeweilige karte ausführen und die map-daten raufkopieren. für das RNS310 müsste es das eigentlich schon gewesen sein, die karte sollte danach auch in einem navi funktionieren.

das ganze gefriemel mit dem clonen der sd-karten ist unnötig und macht letztendlich, wie du selber schon festgestellt hast, nur mehr ärger als gewünscht. denn meiner erfahrung nach ist einer der entscheidenen faktoren, ob eine navi-karte letztendlich funktionert, auch die max. grösse der partition (8GB).

'sdinfo' ist ab der version 1.8 auch nicht mehr abhängig von einem gepatchten kernel und läuft seitdem und bis dato auf jedem der offiziellen ubuntu versionen und deren derivate. siehe: (SD-Info) ein Tool zum Karten-Update RNS310/RNS315 (AMUNDSEN+).

mfg jori...

**user234** · 12.03.2021, 19:35

Vielleicht habe ich irgendeine ältere sdinfo, aber bei mir meckert sdinfo in der Originalversion auf meinem MINT 20.1 mit dem 5.xx kernel:
WRONG KERNEL: 5.4.0-66-generic "./sdinfo requires kernel 4.1.0-mmc"
Die Datei habe ich aus dem Image von Simply&Clever extrahiert. Das Image habe ich hier von dir irgendwann mal 2019 bekommen.

Glücklicherweise ist die Datei ein shell-Skript. Habe nun die Überprüfung am Anfang im Skript auskommentiert und nun läuft es und meldet sich als Version 1.7...

Und jetzt kommt es (sdinfo war doch gut!):

Anscheinend sind meine Karten doch mit dem Produktionsdatum 09/2017 (wenn man sdinfo glaubt) eigentlich zu neu dafür (zumindest 2 von 3, die dritte muss ich noch prüfen), dass ich überhaupt CID ändern kann. Das könnte meine Probleme erklären. Die Frage ist aber: Warum kann ich CID bei den Karten dennoch ändern? Und warum klappt es manchmal und die Karte wird dann von RNS310 erkannt?

Ich habe jetzt auch die CID mit evoplus_cid aus dem gleichen Simply&Clever gesetzt: Keinerlei Fehlermeldungen und die CID wird auch gesetzt.

Die einzige "Sünde", den ich jetzt noch mache: Ich belasse die Partition auf der Karte bei ihrer voller Größe von etwa 32GB. Aber auch das scheint ja manchmal zu klappen. Ich werde es demnächst auch mit 8GB versuchen, wie empfohlen, glaube aber irgendwie nicht wirklich, dass es daran liegt. Denn in 2 von 3 Fällen klappt es ja.

EDIT: Alle drei SD-Karten sind 09/2017. Dennoch laufen 2 davon ohne Probleme mit V12 und die dritte (die gestern noch mit V11 lief) will heute einfach nicht.
sdinfo meldet übrigens bei allen drei SD-Karten völlig identische Daten, auch Serial-Nr, CSD und SCR, alle Werte sind bei allen drei Karten gleich.

EDIT2: An der Größe der Partition liegt es auch nicht. Habe gerade mit gparted die Partition auf 8GB verkleinert. Rest ist unformatiert. Die Karte wird dennoch nicht erkannt. Die beiden anderen aber reproduzierbar schon. Ich versuche noch die CID bei der Karte hin und her zu ändern, z.B. auf den Wert von V11 und dann wieder auf den Wert von V12 zurück.

**jori** · 12.03.2021, 22:33

@Link nur für registrierte und freigeschaltete Mitglieder sichtbar. - wenn du die CID der karten ändern kannst, sind die karten mit sehr hoher wahrscheinlichkeit aus einer produktion vor dem 2.quartal 2016. und wenn du vor dem ändern der CID, die original-CID nicht mit 'sdinfo' und der option 'save' gesichert hast, dann sind die eigentlichen und echten informationen der abgeänderten sd-karten nicht mehr wiederherzustellen. das was du da siehst und von 'sdinfo' ausgegeben wird, sind die fake-CID's, die du mit 'mmc' und/oder 'evoplus_cid' gesetzt hast. deswegen sind die auch alle identisch.

mfg jori...

**user234** · 13.03.2021, 12:57

@Link nur für registrierte und freigeschaltete Mitglieder sichtbar. : Mit den fake-CID's hatte ich es mir schon gedacht. Aber ist dann auch das Produktionsdatum, was sdinfo da zeigt auch fake? Und ja, Originaldaten hatte ich leider nicht abgespeichert, weil ich bis gestern davon ausgegangen war, dass sdinfo ohne gepatchtes kernel nicht laufen würde.
Zu meinen Experimenten mit der dritten SD-Karte, die nicht wollte. Ich vermute mal, dass es bei der Karte eher an der Formatierung lag und nicht an CID, denn wie gesagt, die CIDs kann ich ja ändern. In deine These mit 8GB-großen Partition glaube ich nicht so wirklich, weil ich es bei der besagten Karte nachweislich gesehen hatte, dass es nichts bringt, die Partition nachträglich zu verkleinern und weil es bei mir bei den zwei anderen und mittlerweile auch bei dieser dritten Karte mit der vollen Größe von 32 GB funktioniert. So wie du es aber machst, die Partition von Anfang an kleiner zu halten, könnte aber eine ähnliche Nebenwirkung erzielen, indem man den restlichen Bereich der Karte somit quasi künstlich sperrt, dass da keine Daten von Betriebsystem geschrieben werden können bzw. evtl. auch von dem RNS310 nicht gelesen werden. Und genau in diesen "restlichen Daten" bzw. im "restlichen Bereich" der Karte vermute ich, dass da der Hund vergraben ist, warum es bei mir nicht funktioniert hat.
"Geheilt" hatte ich meine dritte Karte damit, dass ich "dd if=/dev/null of=/dev/mmc... bs=1M" gemacht hatte, quasi die komplette Karte "genullt". Denn auch die Formatierung, egal ob "schnell" oder "voll" löscht dir letztendlich die Daten nicht von der Karte. Und meine Karten hatte ich früher voll im Einsatz bei meinem RaspberryPi mit zum Teil auch einer anderen Partitionsstruktur. Ja, "Nullen" einer SD-Karte ist keine gute Idee, gebe ich zu, aber wenn es in dem Falle hilft...
Im dem Image mit V12 (was ich von "Überraschung" habe) gab es auch neben "cryptnav" noch Ordner "Music" drauf. Ich vermute mal, dass es vielleicht sogar gehen würde, in diesen Ordner Musik-Daten abzulegen und sie nachher abzuspeichern. Mein nicht deterministisches Verhalten (mal geht, mal nicht) kann genau mit diesem Ordner zu tun haben. Denn kopiert hatte ich die Daten unter Windows. Und dort macht Windows es manchmal von oben nach unten und manchmal andersrum. Und genau das könnte das Problem sein, dass physikalisch der Ordner "Music" da vielleicht auf der Karte an erster Stelle lag und erst danach "cryptnav". Und da hilft dir nicht, den Ordner nachher auch zu löschen. Denn wirklich gelöscht wird dabei nichts. Darum deine Empfehlungen mit Linux zu kopieren und nur "cryptnav" mitzunehmen sonst nichts gehen schon in die richtige Richtung, erklären aber nicht die eigentliche Ursache.
Meine "Thesen" hier sind natürlich auch nur Vermutungen, soweit ich mich aber mit Dateisystemen auskenne, scheint es mir zumindest eine plausible Erklärung des Phänomens zu sein. Man sollte es aber natürlich verifizieren.
Danke!

**jori** · 13.03.2021, 14:29

@Link nur für registrierte und freigeschaltete Mitglieder sichtbar. - egal auf welchem weg du die CID-daten ausliest, ob komfortabel mit 'sdinfo' oder händisch mittels 'cat' etc. die ausgegebenen werte basieren immer auf daten, die die CID enthält. dazu gehören auch das produktionsdatum, der name der karte, die firmwareversion etc. daher findest du nach dem ändern der CID nur noch daten vor, die für die sd-karte nicht mehr gültig sind.

zu der zeit (ca. 2007-2009) als das RNS310/315 entwickelt wurde, waren sd-karten mit grössen über 8GB noch rar und entsprechend teuer. auch die firmware der navis wurde also unter diesen bedingungen entwickelt. je nachdem wie weit der entwicklungsstand deiner navi-firmware ist, kann sie möglicherweise auch mit grösseren sd-karten umgehen. das aber kannst du nicht garantieren, bei der fülle an geräten die derzeit noch auf dem markt sind. nicht alle haben den gleichen softwarestand. auch die original sd-karten von VW zum update für das RNS310/315 haben nur eine grösse von 8GB. das wird schon gründe haben, daher meine empfehlung bei max. 8GB zu bleiben was das maps-update angeht.

ein voll-format löscht dir auch die sd-karte. das ist mir neu, das danach noch alte daten auf sd-karte/festplatte zu finden sind. wenn du eine sd-karte mit 'dd' nullst oder besser mit einer anderen kennung als NULL überschreibst und du sie dann danach noch einmal mittels voll-format formatierst ist deine mit 'dd' geschriebene kennung auch futsch, oder?! würde mich jedenfalls sehr wundern, wenn das nicht so ist.

mfg jori...

**user234** · 13.03.2021, 21:14

Vollformat löscht nicht die Daten der Karte im Unterschied zu dd. Weder von Windows noch von Linux. Es wird lediglich die Formatierung vorgenommen. Bei der Formatierung werden typischerweise die ersten Bytes des jeweiligen Dateinamen "gelöscht", mehr ist es nicht. Was da genau der Unterschied zwischen "Vollformat" und "Schnellformatierung" unter Windows, weiß ich nicht genau, weil es mich bis jetzt nicht genau interessiert hat, könnte aber gerne hier ein Paar Dumps vom jeweiligen Device posten nach einem Schnellformat und nach einem Vollformat. Ich bin mir aber ziemlich sicher, dass auch nach einem Vollformat auf der Karte noch die Daten übrig bleiben. Oder was denkst du, wofür all die Restore- und Shredder-Programme da sind? Genau um diese Daten wiederherzustellen.
Wenn du nach dd wieder formatierst, ist die komplette Nullung natürlich nicht mehr vorhanden, es wird die FAT-Tabelle angelegt usw. ABER die Bereiche mit den Daten sind dann genullt. Im Unterschied zur einfachen Formatierung ohne Nullung. In dem Falle sind die Bereiche, wo Daten liegen noch mit den alten Daten belegt, bis dahin nicht irgendwas Neues geschrieben wird. Und genau darin sehe ich das eigentliche Problem von RNS310, was aus unerklärlichen Gründen (bewusst oder unbewusst) mit diesen Bereichen nicht richtig umgehen kann.
Das deine Tipps mit der Vorgehensweise für die breite Masse der Firmwares wahrscheinlich am Ende die beste Lösung ist, sehe ich auch so. Ich sehe sie dann aber eher als Empfehlungen. Und in meinem konkreten Fall hat mir nicht nur das stupide Einhalten dieser Empfehlungen geholfen (was vielleicht in 98% der Fälle funktioniert), sondern auch etwas um die Ecke denken und z.b. "dd" anwenden.

Edit: Meine Recherche hat ergeben, dass Windows seit Vista tatsächlich bei der Vollvormatierung die Daten nullt, was bei den ursprünglichen Versionen definitiv nicht der Fall war. Darum war es wahrscheinlich bei mir im Gehirn seit den Zeiten eingebrannt, dass Windows es per see nicht macht. Gparted verhält sich da natürlich auch klassisch, denn Formatierung heißt eben nur Formatierung und nicht Nullung. Ein Paar kleine Unterschiede zu meiner dd-Methode gibt es jedoch schon. Und da wären wir wieder bei den "unbenutzten Bereichen":
1. Soweit ich es verstanden habe, "nullt" Windows nur den Datenbereich der jeweiligen Partition. Sprich, wenn du einen unpartitionierten Bereich mit Restdaten hättest, wird diese Windows-Nullung diesen Bereich nicht "durchfahren".
2. Bei mir legt Windows immer (auch gleich nach der Vollformatierung) ihren komischen versteckten Ordner "System Volume Information" an. Man kann den natürlich nachträglich unter Linux löschen, aber damit ist das Dateisystem schon mal "beschmutzt", bevor man dadrauf überhaupt noch was geschrieben hat. Vielleicht kann man es unter Windows irgendwie abstellen, dass der Ordner immer angelegt wird, ich hatte mich damit aber nicht befasst und bin stattdessen lieber zu gparted und Linux gegangen. Und da ist das Verhalten bei der Formatierung anders.

**jori** · 14.03.2021, 02:50

@Link nur für registrierte und freigeschaltete Mitglieder sichtbar. - eine formatierung (voll/quick) bezieht sich immer auf eine partition, nie auf die ganze platte/stick/karte. den gleichen effekt wie mit 'dd' kannst du auch mit 'disks' erzeugen, das ist ein bischen system-konformer als 'dd' und wie ich finde auch einfacher zu bedienen als 'gparted'. 'disks' ist beim programmstart auch deutlich schneller beim scannen der devices. dort reicht es alle partitionen der gewünschten sd-karte zu löschen, eine neue fat32-partition über den gesamten speicherplatz anzulegen und beim format den button 'erase' anstellen. dann wird auch jeder datenblock auf der sd-karte, wie bei 'dd' zusätzlich gelöscht (vollformat).

mfg jori...

**user234** · 14.03.2021, 10:12

@Link nur für registrierte und freigeschaltete Mitglieder sichtbar. : Danke! Wieder was dazu gelernt. Wie gesagt, ich hatte Windows-eigene Formatierungswerkzeuge nie so richtig benutzt, da sie etwas eingeschränkter sind, was die Formatierung angeht (nur FAT und NTFS) und zudem noch galangt man dort zur Partitionierung nur über Systemsteuerung->Verwaltung->... Früher hatte ich alternative Partitionswerkzeuge benutzt, wie Acronis und Co. Mit der Zeit gab es aber keine kostenlosen Versionen mehr und gparted und clonezilla hatten dann irgendwann mal einen brauchbaren Stand erreicht, dass man sie vernünftig nutzen konnte. Darum mache ich es seit 5-10 Jahren fast ausschließlich damit. Gparted ist auch bei jeder Ubuntu-artiger Live-CD / Live-USB dabei, sodass man dafür nicht lange suchen muss. Ja, das Starten von gparted ist nicht unbedingt schnell und auch das Kopieren einer Partition dauert da deutlich länger als bei kostenpflichtigen Alternativen, aber dafür kostet es nichts und funktioniert. Genau so, wie clonezilla. Clonezilla installiere ich inzwischen bei jedem debian-Derivat bei mir. Aber ich schaue es mir mit 'disks' gerne an.
Danke!

Edit: Es war nicht so einfach "disks" unter Mint zu finden, weil es unter dem Namen kaum zu finden ist. War eigentlich auch standard-mäßig installiert und ist unter "Einstellungen->Laufwerke" zu finden. Gut zu wissen. Das Tool ist nicht so klicki-bunti gemacht wie gparted, darum ist es mir gar nicht aufgefallen, obwohl ich Mint schon seit 2-3 Jahren intensiv nutze. Aber wenn man es näher betrachtet, ist das Tool wirklich etwas strukturierter gemacht und bietet deutlich mehr Werkzeuge am Board.