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

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

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?
 
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
 
Zuletzt bearbeitet:
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?
 
Zuletzt bearbeitet:
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.
 
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.
Du musst Regestriert sein, um das angehängte Bild zusehen.

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:
Du musst Regestriert sein, um das angehängte Bild zusehen.

Allerdings ist unter rcc/mnt kein Ordner efs-persist :
Du musst Regestriert sein, um das angehängte Bild zusehen.

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?
 

Anhänge

Du musst angemeldet sein, um die Anhangsliste zu sehen.
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.
 
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.

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.
 
Zuletzt bearbeitet von einem Moderator:
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.
 

Anhänge

Du musst angemeldet sein, um die Anhangsliste zu sehen.
Zuletzt bearbeitet:
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.
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?
 
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?
 
Zuletzt bearbeitet von einem Moderator:
Sicher weiß ich nur, dass man den NOR auslöten und extern beschreiben kann.

Kommst du auf MMX noch drauf?
 
Es ist möglich, über den DUB-100 mit MMX zu telneten. In Bezug auf das Entlöten des NOR und das Flashen von einem externen Programmierer konnte ich nicht zu viele Informationen davon googeln. hat es hier schon mal jemand gemacht?
 
Zurück
Oben