Support [Audi] MIB2/MHI2Q - AUG22 - MHI2Q_ER_AUG22_P5092 MU1329 - ifs-root EL Patch (ASI, CarPlay, Android Auto, Map Update)

[miouser]

@EderOrange​

eine die MHI2Q heißt. ist doch logisch.

 

[weileong27]

Hallo, ich habe das IFS-Stammverzeichnis von der Adresse BA0000 gepatcht und jetzt startet MIB2, bleibt aber beim Laden der Navigation mit 11% hängen. Es startet automatisch nach ca. 4 Minuten 30 Sekunden. Ich kann nicht mehr über Dlink zu RCC (Port 123) telneten, aber Telnet in MMX (Port 23) ist möglich. Der Versuch, über den mmx-Modus auf RCC zuzugreifen, zeigt jedoch, dass der RCC-Host nicht verfügbar ist. Ich habe versucht, das IPL über das Bank-Setup durchzuführen, aber der IFS-Notfall wird nicht geladen. Kann ich das Gerät zur Reparatur einsenden? oder eine mögliche Empfehlung, um zu versuchen, das Gerät in seinen Standardzustand zurückzusetzen

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Hallo, ich habe irgendwo gelesen, dass es möglich ist, das Notfall-IFS über zmodem hochzuladen, aber ich konnte keine Details dazu finden. Ich freue mich über jeden Rat. Die Firmware-Version lautet MHI2Q_ER_AUG22_P5092 MU1329

 

[CaneTLOTW]

Wenn die ab ba0000 geflashed hast, gibt es keinen Grund, warum IPL nicht funktionieren sollte. Dein LOG oben sieht dahingehen auch komisch aus, da die Unit scheinbar mitten drin neu startet.
Was für eine Stromversorgung wird genutzt?

 

[weileong27]

Ich benutze eine 12V DC Versorgung. Beeinträchtigt die Stromversorgung den Betrieb des Geräts? Ich habe von der Adresse BA0000 geflasht, aber ich glaube, ich habe einen Fehler gemacht und an einer niedrigeren Adresse geflasht. Es gibt sowieso eine Möglichkeit, IFS im Notfall zu laden, um von zmodem wiederhergestellt zu werden

=> fscan
0x08000000..0x0801391b IPL [ver.16153A, options = 4]
0x08020000..0x083b0e5b QNX IFS [ver.1, RAW, UCL]: EMERG / 3B9
0x0bd00000..0x0bdc6923 DSP1 file (BGZ boot table format, ver.17145A)
0x0bf00000..0x0bf5ffff BIOS packet (BIOS first): _arm-cortexA8_xxxx-yyyy-zzzz_0 000_T32
[=> do_fscan: ARM = 0/0 DSP = 0/0

 

[CaneTLOTW]

Übersetzte deine Post nach Deutsch

Ja, du musst unterhalb von 540000 geflashed haben.

 

[weileong27]

Es tut mir leid, dass ich auf Englisch gepostet habe. Ich habe auf Deutsch gepostet, aber Chrome hat die Übersetzung ins Englische gemacht. . Ich hatte die Übersetzung deaktiviert und meinen gesamten Beitrag bearbeitet. Meine Frage ist jetzt, was ist die Methode für die Wiederherstellung jetzt?

 

[CaneTLOTW]

Du kannst die Beiträge doch editieren und ab jetzt google translate nutzen .

zModem müsste der richtige Weg sein, habe damit aber selber noch nichts gemacht. Ich höre mich mal um.

 

[durchblicker]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

@ddynamo gibts schon Neuigkeiten von deiner Seite?

 

[ddynamo]

Ein wenig Neues... ich stehe zumindest mit CaneTLOTW in Kontakt. Und ich habe mir Technik bestellt für einen UART-Zugriff. Ich hoffe, das kommt vor Weihnachten, dann könnte ich über die Feiertage bissel rumbasteln.

Jedenfalls habe ich der Unit sowohl das FW-Update als auch das VC-Update bereits nochmal auf der SD-Karte in der originalen Ordnerstruktur - angeboten ohne Erfolg.

Wenn ich eine SD-Karte mit Musikdateien einlege, liest er diese aus, spielt aber nichts ab. Dafür dreht sich rechts oben weiter der Kreis, als ob er was auf der Karte suche würde.

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Ich weis aber mittlerweile, dass ich innerhalb meines ca. 4-Minuten-Fensters zwar nicht mehr per Telnet auf rcc komme, über mmx (Port 23) aber sehr wohl noch auf rcc komme:

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Allerdings ist unter rcc/mnt kein Ordner efs-persist :

Spoiler

Du musst dich Anmelden oder Registrieren um diesen Inhalt sichtbar zu machen!

Müsste der denn nicht da sein und EL sowie FEC enthalten?
Ich traue mir jedenfalls zu, innerhalb meines knappen 4-Minuten-Zeitfensters über den D-Link-Adapter den Ordner zu erstellen und EL sowie FEC einzuspielen?
Wäre das sinnvoll und wie muss die Struktur genau aussehen? EL und FEC liegen wohl in einem Unterordner /FEC? Dann gäbe es noch die Variant.txt unter /SDWL? Und noch mehr?

 

[CaptainCaracho]

Ich vermute er hat vermutlich die gesamte patched-ifs-root ab Adresse BA0000 geflasht . Das ist das typische Verhalten, dass danach RCC nicht mehr erreichbar ist weil kein Telnet mehr darauf vorhanden ist. Du musst per Emergency Update erstmal das Gerät wiederherstellen und dann nochmal richtig machen.

 

[durchblicker]

@CaptainCaracho
Interessante Info. Wie stellt man das an, dass man das ganze falsch flasht? Wäre vielleicht eine wichtige Zusatzinfo in der Anleitung, damit künftig niemand diesen Fehler mehr macht.

 

[weileong27]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Kann ich wissen, wie ich das Gerät durch Aktivieren des Notfall-Updates wiederherstellen kann?

Ich habe die Patch-Datei für Stufe 2 (ca. 15 MB) verwendet und folge diesem Befehl.
# only stage 2 image:
# only stage 2 image:
on -f rcc flashit -v -a 0x00BA0000 -d -f /net/mmx/fs/sda0/MU1329-ifs-root-part2-0x00ba0000-C005F400.ifs

Da ich das Notfall-IFS nicht über "boot -t emerg" aufrufen konnte, extrahierte ich die emerg.ifs mit einer Größe von ca. 3 MB (ab Adresse 2000) und übertrug sie per zmodem. Der Plan war, danach von diesem Image zu booten. Die Übertragung konnte die Übertragung jedoch nicht abschließen und blieb bei 57% hängen. Ich brauche vielleicht eine kleinere Größe.

 

[ddynamo]

Hallo allseits,
ich habe (schlechte) Neuigkeiten. Bin exakt nach dem im Forum verlinkten Dokument "MIB2 - Nvidia recovery on bench top" vorgegangen.
Die MMI-Unit liegt auf dem Tisch, und ich habe versucht per UART ins Emergency zu booten. Das scheint auch zu klappen, allerdings laufen wahnsinnig viele Meldungen durch das Log, was mich zwingt, Login (root) und Passwort (2yavoUEZ) quasi blind einzugeben. Das schlimmste ist aber: der Befehl "slay -9 MIBEmergency" stoppt nichts, die Unit schaltet sich nach gut einer Minute gnadenlos ab! D.h. ich komme vor lauter Logmeldungen (in putty läuft das Terminal trotz der kurzen Zeit über) und wegen der Kürze der Zeit nicht ansatzweise zur Fehlersuche.

CaneTLOTW hat sich dankenswerterweise Zeit für eine Teamviewersession genommen, ihm geht es aber wie mir, er bekommt weder das Log ruhig noch kann er das Runterfahren verhindern. Ich habe zwei Logdateien angehängt. Zuerst das um den Beginn der Sitzung beschnittene Log von der Session mit CaneTLOTW sowie ein vollständiges Kitty-Log von einem eigenen Versuch.

Vielleicht kann jemand etwas damit anfangen? Unsere Vermutung geht zu einem MMX-Problem, aber da bin ich ja noch viel ratloser als Cane...

Update 1:
Oder haben die Qualcommeinheiten irgendwelche Besonderheiten, bspw für den Recoveryprozeß?

Update 2:
Nach Rücksprache mit CaneTLOTW versuche ich trotz der widrigen Umstände nochmal meine originale EL und FEC einzuspielen, um Fehler in diesem Prozeßteil auszuschließen.

 

[CaneTLOTW]

Du musst dich Anmelden oder Registrieren um den Inhalt der Angebote zu sehen!

Wenn du ab 0x00BA0000 geschrieben hast muss dein RCC Emergency noch funktionieren, außes es war 0x00BA000. Alles unter 0x00540000 ist schlecht.

Bist zu mit zmodem weiter gekommen?

 

[weileong27]

zmodem gibt es keine Fortschritte, da der Upload nicht rechtzeitig abgeschlossen werden konnte. Ich vermute, dass es einen Watchdog gibt, der das System neu startet, bevor der Upload abgeschlossen werden kann. Gibt es überhaupt einen Flash von einem externen Programmierer?