Aktuelles
Digital Eliteboard - Das Digitale Technik Forum

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Registriere dich noch heute kostenlos, um Mitglied zu werden! Sobald du angemeldet bist, kannst du auf unserer Seite aktiv teilnehmen, indem du deine eigenen Themen und Beiträge erstellst und dich über deinen eigenen Posteingang mit anderen Mitgliedern unterhalten kannst! Zudem bekommst du Zutritt zu Bereichen, welche für Gäste verwehrt bleiben

Reparatur TT One XXL Classic: Startet nicht nach eMMC-Tausch (Speicher)

    Nobody is reading this thread right now.
Ich wurde gerufen :p

Hm, es gibt bestimmt eine Möglichkeit, den Bootprozess über JTAG/RS232 oder so zu verfolgen. Zum GPS-WNRO hatte ich damit noch nicht so viel Praxiserfahrung, deswegen wüsste ich jetzt nicht direkt, wie das geht. Evtl. helfen da die Archive über die ursprünglichen TomTom-Hacks Anfang der 2000er:

Was mir so spontan einfiele: hast du mal versucht, eine bitweise Kopie des Original-eMMCs auf den neuen zu machen? Wobei ich mir davon nicht zu viel versprechen würde, denn den Originalen kann man ja formatieren und er funktioniert. Aber vielleicht gibt es trotzdem so ne Art "Magic Bit", dass den Speicher kennzeichnet.

Ansonsten könnte man ein kleines Programm schreiben, dass die ttn-Datei ersetzt und etwas auf den Speicher schreibt/dort eine Datei erstellt? Dann wüsste man, ob der Bootloader den Massenspeicher einbindet und die Navcore (ttn) zu starten versucht oder ob es schon davor hängt.
 
Leider habe ich keinerlei Programmierkenntnisse, dafür brauche ich einen Fachmann, der an der Stelle unterstützt.
Was mir so spontan einfiele: hast du mal versucht, eine bitweise Kopie des Original-eMMCs auf den neuen zu machen? Wobei ich mir davon nicht zu viel versprechen würde, denn den Originalen kann man ja formatieren und er funktioniert. Aber vielleicht gibt es trotzdem so ne Art "Magic Bit", dass den Speicher kennzeichnet.

Ansonsten könnte man ein kleines Programm schreiben, dass die ttn-Datei ersetzt und etwas auf den Speicher schreibt/dort eine Datei erstellt? Dann wüsste man, ob der Bootloader den Massenspeicher einbindet und die Navcore (ttn) zu starten versucht oder ob es schon davor hängt.
Kannst Du sowas? :p

Die bitweise Kopie wäre noch eine Möglichkeit zum "einfachen" testen - dazu brauche ich aber wieder Hilfe von jemandem, der ein XL besitzt und das Image runterziehen kann (geht z.B. mit "USB Image Tool", so kopierte Sticks sind z.B. bootfähig, wenn der Spender ebenfalls bootbar ist) und mir zukommen lässt oder irgendwo hochlädt. Das dauert leider extrem lange, eMMC ist unterirdisch langsam, 1GB braucht min. 15-20 Minuten.
Ich will nicht wieder den eMMC tauschen, um selbst ein Image anzufertigen.
 
Zuletzt bearbeitet:
Hmmm...gibt's da nicht irgendwelche Platinen, mit denen man eMMC an den PC anschließen kann?

Zum Programmieren: ja, kann ich. Aber mir ist dann noch eingefallen, dass da vor dem Start der ttn ja trotzdem noch der Boot-/init-Prozess dranhängt und ja irgendwie der Kernel vorher geladen wird. Muss mir das nochmal angucken und durchdenken.
 
Danke, das wäre super.

Es gibt Programmieradapter für eMMC, die sind aber schweineteuer, wenn sie Sockel für den 153-FBGA bzw. 169-FBGA-Footprint haben.
Ich kann das nicht beweisen, aber würde wahrscheinlich nicht weiterhelfen. Meine Vermutung geht eher in Richtung eine Art BIOS, dessen Code nicht auf dem eMMC liegt; habe dazu schon was geschrieben, hier nochmal die Zusammenfassung:
  • Neben der CPU sitzt ein EON EN39SL800, das ist lt. Datenblatt ein 8Mbit Flashspeicher
  • Mit entferntem eMMC startet das Navi, es kommt aber das rote X, da kein Betriebssystem gefunden werden kann
  • Mit entferntem eMMC wird im Diagnosebildschirm die korrekte Geräteseriennummer angezeigt, also muss diese Information woanders als im eMMC liegen.
  • Mit den 4/8GB-eMMC kommt das TomTom-Logo und bleibt da stehen, d.h. dass das BIOS mindestens den eMMC findet und versucht zuzugreifen - sonst käme ja wieder das rote X.
  • Da es mal Bootloader-Updates gab, die die Kompatibilität/Funktion mit "größeren" SD-Karten ermöglicht hat (wobei es das XL und XXL nicht mit SD-Slot gab), vermute ich, dass man das nur für den Wechselspeicher programmiert hat, weil mit einem SD-Adapter bootet das Navi problemlos von einer Speicherkarte.
 
Ja, gut möglich, dass das der Bootloader ist. Wäre ungewöhnlich, wenn der im eMMC sitzt. Dann könnte man ihn ausversehen löschen. Zumindest so, wie der eMMC eingebunden wird.

Die SD-Karte hast du dann wie angeschlossen? Oder hast du einen SD-Slot hinzugefügt?

Ansonsten noch zur Referenz:
 
Die SD-Karte hast du dann wie angeschlossen? Oder hast du einen SD-Slot hinzugefügt?
µSD-Karte im Adapter, dessen Kontakte an die entsprechenden Pads auf der Platine mit Kabeln angelötet. So wie bei vielen, es etliche Bauberichte zu den Umbauten inkl. Bildern, z.B. hier (sorry, Fremdforum): View topic - Tomtom XXL added 8gb SDCARD ! succes
Oder hier: Adding extra internal memory

Vermutlich sind die Pads auf den Datenleitungen, Clock, usw. ursprünglich nur für Diagnosezwecke im Werk gedacht.

Edit von Mod: Fremdlink durch DEB-Link ersetzt (das Bild ist das selbe:cool:)
 
Zuletzt bearbeitet von einem Moderator:
Ich denke, die Pads sind einfach vom Design dort geblieben. Evtl. war es ursprünglich mal mit SD-Karte geplant worden, bzw. einfach in den Entwurf mit reingekommen. Und später dann dagegen entschieden bzw. Design zweckentfremdet.

Warum dann aber nicht einfach eine SD-Karte statt eMMC verwenden?
 
@Chudewudiseydevü erstelle erstmal folgende Datei mit dem Namen "ttn" (nur ttn, sonst nichts, keine Endung, kein .txt oder so) im Hauptverzeichnis des TomTom:

Code:
#! /bin/sh

echo "Test" > /mnt/sdcard/emmctest.txt &

Wenn du das TomTom dann startest warte mal eine Minute, und danach schließt du es wieder an den PC an. Ist dann danach auf dem internen Speicher eine emmctest.txt vorhanden?
 
Zuletzt bearbeitet:
Hallo & Danke!

leider nein. Es wird keine Textdatei geschrieben.

Hier der Inhalt der ttn-Datei ohne Endung im Hexeditor, passt das so? In ANSI wird das zu dem o.g. Text.
23 21 20 2F 62 69 6E 2F 73 68 0D 0A 0D 0A 65 63 68 6F 20 22 54 65 73 74 22 20 3E 20 2F 6D 6E 74 2F 73 64 63 61 72 64 2F 65 6D 6D 63 74 65 73 74 2E 74 78 74 20 26
Noch etwas:
Ich habe die splashw.bmp getauscht, das ist das Hintergrundbild, das nach dem einlesen des Speichers kommt, das wird angezeigt. Also wenigstens das Bild wird eingelesen.
 
Schade! Aber warum öffnest du die in einem Hex-Editor? Das ist eine ganz normale Textdatei! Ans Ende sollte evtl. noch ein Zeilenumbruch, wobei das eigentlich(!) nichts ausmachen dürfte.

Hmm, das mit der splashw.bmp ist wiederum interessant. Die wird aber meiner Vermutung nach vom Bootloader geladen, denn im init-Script finde ich dazu nix. Leider gibt's zum Bootloader echt wenig Infos und das ist meines Wissens auch kein Open Source.

Ich könnte mir vorstellen, dass dem Linux-Kernel der Treiber für den Flashspeicher fehlt und er ihn deshalb nicht einbinden kann. Der Bootloader könnte in einer Art generischem Modus auf eMMC zugreifen, sodass es dort funktioniert.

Man kann möglicherweise über modifizierte Init-Scripts noch einiges rausfinden, aber das ist schon mühsam, wenn man das Gerät nicht selbst hat. Am besten wäre wirklich, du besorgst dir den Zugang zur seriellen Schnittstelle!

Was ist denn die aktuell installierte Bootloader-Version? EDIT: Ach, ganz am Anfang: 5.5821. Es gibt ja mindestens 5.5825...zumindest für mein Rider.
 
Zuletzt bearbeitet:
@Chudewudiseydevü wenn du noch irgendwie die Möglichkeit hast, von SD zu booten, dann pack auf die SD mal folgende Datei als "ttn":

Code:
#! /bin/sh

dmesg > /mnt/sdcard/dmesg.txt &

Darin kann man dann gucken, was der Kernel tut und dann sollte man auch sehen, ob es Fehlermeldungen beim Einbinden vom eMMC gibt!

3. Idee:
Mal ein alternatives Navi-System testen. Navit/NavitTom/OpenTom bietet da was. Z.B. hier:
Das Interessante ist dabei aber auch, dass dort das Log des Kernels nicht unterdrückt wird, sondern auf dem Bildschirm angezeigt. Also im Prinzip das, was oben der Befehl mit "dmesg" ausgibt.
 
Zuletzt bearbeitet:
Zurück
Oben