Digital Eliteboard - Das Digitale Technik Forum
Registriere dich noch heute kostenloses 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 Bereiche, 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)
weileong27
Newbie
- Registriert
- 12. Dezember 2020
- Beiträge
- 18
- Reaktionspunkte
- 5
- Punkte
- 23
Ich habe das VIM von OBDeleven aktiviert, bevor ich auch mit dem Patchen beginne
- Registriert
- 11. September 2017
- Beiträge
- 1.323
- Reaktionspunkte
- 1.391
- Punkte
- 373
2017er A6 4G mit MHI2 und ASS Soundsystem:
Original FW P3634
Update auf K3663
VIM Aktivierung mit OBD11 App & div. weitere (manuelle) Codierungen ebenfalls mit bösen OBD11
Dann manuell gepatcht (FEC) für ASI und Lifetime Maps
Alles Gut soweit !!!
Original FW P3634
Update auf K3663
VIM Aktivierung mit OBD11 App & div. weitere (manuelle) Codierungen ebenfalls mit bösen OBD11
Dann manuell gepatcht (FEC) für ASI und Lifetime Maps
Alles Gut soweit !!!
Hallo, was hast du mit der alten Mib-Einheit gemacht? Vielleicht kann ich es selbst reparieren, wenn Sie bereit sind, es mir zu senden, um zu versuchen, alles von Anfang an zu wiederholen. Ich habe vier Unit Mib 2 aktiviert und hatte kein Problem, sie funktionieren alle ohne Probleme. Ich bin in Umkreis Stuttgart-Heilbronn.
Es gibt gute Neuigkeiten von mir, meine Unit funktioniert wieder. Dank geht v.a. an @CaneTLOTW und @Honki26 für viele beantwortete Fragen und Anregungen etc. ! Ich fasse den Vorgang nochmal kurz zusammen, vielleicht hilft das künftig dem Einen oder Anderen.
Ich hatte versucht, das MMI-Nav+ meines Audi A4 Allroad MJ 2017 zu patchen um Lifetime-Navikartenupdates freizuschalten. Softwarestand war, nach erfolgreichem eigenen FW-Upgrade, eine funktionierende MHI2Q_ER_AUG22_P5092 MU1329. Ich habe M.I.B. v1.12 genutzt und IFS-Stage2-Patch aufgespielt, vorher erfolgreiches Backup gemacht. Patchen und Kopieren der EL verlief ohne Fehlermeldung und Unitneustart wurde automatisch ausgelöst. MMI startete aber geradewegs in den Bildschirm für Medienzugriff und Bedieneinheit (Drehdrücksteller etc.) war komplett funktionslos. Das MMI startete aller gut 4 Minuten neu in diesen Zustand ohne dass ich irgendwie eingreifen konnte. Telnetzugang auf RCC war nicht mehr möglich. Kurzum, im Auto selbst war nichts mehr zu machen.
Ein späterer Vergleich der RCC-Dumps vor und nach dem Flash durch @CaneTLOTW ergab, dass beim Flashen einige defekte Blöcke entstanden. Das geloggte Verify des Flashvorganges sieht zu kurz aus, aber das MIB-Tool hat leider nicht reflasht oder wenigstens auf das offensichtlich abgebrochene Verifying hingewiesen. Gründe für den mißlungenen Flash kann ich nicht belastbar benennen. Aus der Erinnerung rekonstruiert hatte ich möglicherweise nur Zündung an aber nicht den Motor gestartet. Vielleicht haben sich hierdurch (nach und nach Abschaltung von Geräten) Spannungsschwankungen ergeben, die den Flash beeinträchtigten...?
Es blieb mir nur, UART-Ausrüstung zu beschaffen, die Unit auszubauen und auf dem Tisch zu betreiben. Ich wollte nach dem auch hier im Forum erhältlichen Dokument zum Recovery der kompletten ifs-root.ifs verfahren. Anleitungsgemäß konnte ich das Emergency-IFS zu starten beginnen, allerdings lief der Start nie gänzlich durch, sondern brach immer an der gleichen Stelle ab und der sofortige Neustart führte nur ins normale RCC, wo ich mich zumindest als root einloggen konnte. Aus meiner Sicht waren die zentralen Fehlermeldungen:
- dsploader: DSP loader: image #1 not found! (mE nach das zweite Subimage im ifs-root nach der stage 2 als erstem Subimage, nachvollziehbar mit "fscan")
- checkFreeMem: MIBRoot blocked or not started (cycles elapsed 4): error 0x3 (das dürfte die eigentliche ifs-root stage 1+2 sein)
Dieser Zustand wies viele gravierende Probleme auf, von denen ich jetzt nur diejenigen aufzähle, welche einem Neuflash des offenbar inhaltlich beschädigten RCC Bausteins entgegenstanden:
- der RCC-Flashbaustein (/dev/fs0) war nicht gemountet und konnte auch mit dem üblichen Mountbefehl nicht gemountet werden (mount der SD-Karte über Befehl war jedoch bspw. möglich)
- selbst nach schnellstmöglichem Rootlogin hatte ich maximal ca. 2:35 Minuten Zeit bevor irgendein watchdog die Unit instant abschaltete (dies war nicht aufzuhalten, insbesondere auch nicht mit dem angeblich zumindest im Emergency RCC nutzbaren "slay -9 MIBEmergency")
- die Konsole läuft permanent mit allen möglichen Meldungen voll, so dass man Login und irgendwelche Befehlseingaben quasi "blind" durchführen muss (und zum in Ruhe auswerten der Befehlsausgaben die komplette putty-Sitzung loggen musste), auch "stufu" half nicht dagegen
Nach mehreren Tagen unermüdliche Neustartens der Unit, Fehlersuche, Kommunikation mit meinen Unterstützern und viel eigener Lektüre in Foren, Handreichungen und der Neutrinodokumentation habe ich sodann kurz zusammengefasst folgendes getan:
- SD-Karte vorbereitet mit dem IFS-Patch für meine FW (also genau der Patch, der anfangs gescheitert war, allerdings ist dieser wegen seiner Beschränkung auf stage2 ja kleiner als die gesamte originale ifs-root-ifs und ich hatte für meine folgende Aktion ja nur die verdammten 2:30 Minuten...)
- zusätzlich flashunlock und flashlock auf die SD-Karte gepackt, da diese Programme merkwürdigerweise in meiner /net/rcc/usr/bin nicht vorhanden waren (mglw. hätte das dort vorhandene flashctl geholfen, ich wollte aber nicht noch mehr von Neutrino lernen müssen)
- SD-Karte schon in Slot 1 gesteckt
- sämtliche folgende Befehle in einer separaten Datei für Copy-Paste-Einsatz vorbereitet
- als root in die RCC eingeloggt und schnellstmöglich(!!) abgehandelt:
/sbin/devf-generic -s 0x08000000,64M,,,128k,2,1 -r -D -P 1 # Automount des RCC-Flashbausteins der damit als /dev/fs0 eingebunden wird
mount -uw /net/mmx/fs/sda0/ # vorbereitete SD-Karte mounten
/net/mmx/fs/sda0/flashunlock # RCC-Flashbaustein flashbar machen
flashit -v -a 0x00BA0000 -d -f /net/mmx/fs/sda0/MU1329-ifs-root-part2-0x00ba0000-C005F400.ifs # manueller Flashbefehl
Bibbern und Beten!
Daraufhin wurde der Flashbaustein gelöscht und beschrieben. Das zu flashit gehörende verify habe ich noch für wenige Sekunden anlaufen sehen, dann schaltete die Unit wie üblich ab, war also wie im schlechten Hollywoodfilm...ergo nochmal Bibbern und Beten ;-)
Unit neu gestartet und jetzt sah der Boot in der Konsole tatsächlich gesund aus ;-) Natürlich fehlen beim Tischbetrieb die Bedienelemente, d.h. nach dem erfolgreichen Boot schaltet der dspwatchdog die Unit nach 60 Sekunden ab. Unit wieder ins Auto und sieheda, alles bestens Alle Funktionen laufen wie erwartet und die Lifetimeupdates sind freigeschaltet ;-), denn die angepasste EL war ja schon vom ersten Versuch drauf.
Ein Abgleich des neuerlichen RCC-Dumps sieht auch einwandfrei aus, das Hauptproblem bei mir scheint also tatsächlich behoben.
Leider ist eine Sache noch abzuklären. Auch nach Reflash und mehrfachem erfolgreichen Reboot habe ich im Tischbetrieb das Emergency-IFS nicht durchbooten können. Weiterhin schaltet sich die Unit nach der Stelle
Starting rcc-pata-mdrv...
kommentarlos aus und wieder ein und geht nochmals durch das immer am Anfang zu durchlaufende IPL und sofort ins normale RCC, da ich an der Stelle nicht so schnell sein kann, manuell den RX-Kontakt auf GND zu legen um ins Emergency zu gehen, was ja aber eh nicht funzt...
D.h. entweder ist auf dem MMIs mit Qualcommchip doch irgendwas im Emergency anders als auf den Nvidia-Einheiten oder nur meine Unit hat eine (Hard- und/oder Software)Macke mit dem Emergency-IFS. Ich berichte hier, falls ich da noch etwas herausfinde.
Update1: Jedenfalls sind das originale Emergency-IFS der Firmware und meine Emergency-IFS-Partition im Flashbaustein absolut identisch wie mein Hexeditor sagt.
Fazit aus meiner bescheidenen Sicht:
Der Patch funktioniert grundsätzlich, auch für die Firmwareversion in diesem Thread. Ich rate allerdings dringend zu einer stabilen Stromversorgung beim Flash, d.h. Motor an. Außerdem empfehle ich, sich für den manuellen Patch einzulesen, da das MIB-Tool v 1.12 zumindest nicht alle auftretenden Probleme beim Verify an den Nutzer meldet und stattdessen automatisch Reboot einleitet. Beim manuellen Patchen hingegen kann man auf der Konsole mitlesen, wie sich der flashit-Befehl verhält und ggf. nochmals flashen bei Problemen o.ä.
So, wer jetzt nur komplett Bahnhof verstanden hat, für den ist das ganze Problem nicht relevant/nützlich - oder muss wie ich viel Zeit und einiges an Risikobereitschaft in eine steile Lernkurve investieren ;-)
Ich bin jedenfalls glücklich, Ziel der Lifetimeupdates wurde erreicht ;-)
Ich hatte versucht, das MMI-Nav+ meines Audi A4 Allroad MJ 2017 zu patchen um Lifetime-Navikartenupdates freizuschalten. Softwarestand war, nach erfolgreichem eigenen FW-Upgrade, eine funktionierende MHI2Q_ER_AUG22_P5092 MU1329. Ich habe M.I.B. v1.12 genutzt und IFS-Stage2-Patch aufgespielt, vorher erfolgreiches Backup gemacht. Patchen und Kopieren der EL verlief ohne Fehlermeldung und Unitneustart wurde automatisch ausgelöst. MMI startete aber geradewegs in den Bildschirm für Medienzugriff und Bedieneinheit (Drehdrücksteller etc.) war komplett funktionslos. Das MMI startete aller gut 4 Minuten neu in diesen Zustand ohne dass ich irgendwie eingreifen konnte. Telnetzugang auf RCC war nicht mehr möglich. Kurzum, im Auto selbst war nichts mehr zu machen.
Ein späterer Vergleich der RCC-Dumps vor und nach dem Flash durch @CaneTLOTW ergab, dass beim Flashen einige defekte Blöcke entstanden. Das geloggte Verify des Flashvorganges sieht zu kurz aus, aber das MIB-Tool hat leider nicht reflasht oder wenigstens auf das offensichtlich abgebrochene Verifying hingewiesen. Gründe für den mißlungenen Flash kann ich nicht belastbar benennen. Aus der Erinnerung rekonstruiert hatte ich möglicherweise nur Zündung an aber nicht den Motor gestartet. Vielleicht haben sich hierdurch (nach und nach Abschaltung von Geräten) Spannungsschwankungen ergeben, die den Flash beeinträchtigten...?
Es blieb mir nur, UART-Ausrüstung zu beschaffen, die Unit auszubauen und auf dem Tisch zu betreiben. Ich wollte nach dem auch hier im Forum erhältlichen Dokument zum Recovery der kompletten ifs-root.ifs verfahren. Anleitungsgemäß konnte ich das Emergency-IFS zu starten beginnen, allerdings lief der Start nie gänzlich durch, sondern brach immer an der gleichen Stelle ab und der sofortige Neustart führte nur ins normale RCC, wo ich mich zumindest als root einloggen konnte. Aus meiner Sicht waren die zentralen Fehlermeldungen:
- dsploader: DSP loader: image #1 not found! (mE nach das zweite Subimage im ifs-root nach der stage 2 als erstem Subimage, nachvollziehbar mit "fscan")
- checkFreeMem: MIBRoot blocked or not started (cycles elapsed 4): error 0x3 (das dürfte die eigentliche ifs-root stage 1+2 sein)
Dieser Zustand wies viele gravierende Probleme auf, von denen ich jetzt nur diejenigen aufzähle, welche einem Neuflash des offenbar inhaltlich beschädigten RCC Bausteins entgegenstanden:
- der RCC-Flashbaustein (/dev/fs0) war nicht gemountet und konnte auch mit dem üblichen Mountbefehl nicht gemountet werden (mount der SD-Karte über Befehl war jedoch bspw. möglich)
- selbst nach schnellstmöglichem Rootlogin hatte ich maximal ca. 2:35 Minuten Zeit bevor irgendein watchdog die Unit instant abschaltete (dies war nicht aufzuhalten, insbesondere auch nicht mit dem angeblich zumindest im Emergency RCC nutzbaren "slay -9 MIBEmergency")
- die Konsole läuft permanent mit allen möglichen Meldungen voll, so dass man Login und irgendwelche Befehlseingaben quasi "blind" durchführen muss (und zum in Ruhe auswerten der Befehlsausgaben die komplette putty-Sitzung loggen musste), auch "stufu" half nicht dagegen
Nach mehreren Tagen unermüdliche Neustartens der Unit, Fehlersuche, Kommunikation mit meinen Unterstützern und viel eigener Lektüre in Foren, Handreichungen und der Neutrinodokumentation habe ich sodann kurz zusammengefasst folgendes getan:
- SD-Karte vorbereitet mit dem IFS-Patch für meine FW (also genau der Patch, der anfangs gescheitert war, allerdings ist dieser wegen seiner Beschränkung auf stage2 ja kleiner als die gesamte originale ifs-root-ifs und ich hatte für meine folgende Aktion ja nur die verdammten 2:30 Minuten...)
- zusätzlich flashunlock und flashlock auf die SD-Karte gepackt, da diese Programme merkwürdigerweise in meiner /net/rcc/usr/bin nicht vorhanden waren (mglw. hätte das dort vorhandene flashctl geholfen, ich wollte aber nicht noch mehr von Neutrino lernen müssen)
- SD-Karte schon in Slot 1 gesteckt
- sämtliche folgende Befehle in einer separaten Datei für Copy-Paste-Einsatz vorbereitet
- als root in die RCC eingeloggt und schnellstmöglich(!!) abgehandelt:
/sbin/devf-generic -s 0x08000000,64M,,,128k,2,1 -r -D -P 1 # Automount des RCC-Flashbausteins der damit als /dev/fs0 eingebunden wird
mount -uw /net/mmx/fs/sda0/ # vorbereitete SD-Karte mounten
/net/mmx/fs/sda0/flashunlock # RCC-Flashbaustein flashbar machen
flashit -v -a 0x00BA0000 -d -f /net/mmx/fs/sda0/MU1329-ifs-root-part2-0x00ba0000-C005F400.ifs # manueller Flashbefehl
Bibbern und Beten!
Daraufhin wurde der Flashbaustein gelöscht und beschrieben. Das zu flashit gehörende verify habe ich noch für wenige Sekunden anlaufen sehen, dann schaltete die Unit wie üblich ab, war also wie im schlechten Hollywoodfilm...ergo nochmal Bibbern und Beten ;-)
Unit neu gestartet und jetzt sah der Boot in der Konsole tatsächlich gesund aus ;-) Natürlich fehlen beim Tischbetrieb die Bedienelemente, d.h. nach dem erfolgreichen Boot schaltet der dspwatchdog die Unit nach 60 Sekunden ab. Unit wieder ins Auto und sieheda, alles bestens
Alle Funktionen laufen wie erwartet und die Lifetimeupdates sind freigeschaltet ;-), denn die angepasste EL war ja schon vom ersten Versuch drauf.Ein Abgleich des neuerlichen RCC-Dumps sieht auch einwandfrei aus, das Hauptproblem bei mir scheint also tatsächlich behoben.
Leider ist eine Sache noch abzuklären. Auch nach Reflash und mehrfachem erfolgreichen Reboot habe ich im Tischbetrieb das Emergency-IFS nicht durchbooten können. Weiterhin schaltet sich die Unit nach der Stelle
Starting rcc-pata-mdrv...
kommentarlos aus und wieder ein und geht nochmals durch das immer am Anfang zu durchlaufende IPL und sofort ins normale RCC, da ich an der Stelle nicht so schnell sein kann, manuell den RX-Kontakt auf GND zu legen um ins Emergency zu gehen, was ja aber eh nicht funzt...
D.h. entweder ist auf dem MMIs mit Qualcommchip doch irgendwas im Emergency anders als auf den Nvidia-Einheiten oder nur meine Unit hat eine (Hard- und/oder Software)Macke mit dem Emergency-IFS. Ich berichte hier, falls ich da noch etwas herausfinde.
Update1: Jedenfalls sind das originale Emergency-IFS der Firmware und meine Emergency-IFS-Partition im Flashbaustein absolut identisch wie mein Hexeditor sagt.
Fazit aus meiner bescheidenen Sicht:
Der Patch funktioniert grundsätzlich, auch für die Firmwareversion in diesem Thread. Ich rate allerdings dringend zu einer stabilen Stromversorgung beim Flash, d.h. Motor an. Außerdem empfehle ich, sich für den manuellen Patch einzulesen, da das MIB-Tool v 1.12 zumindest nicht alle auftretenden Probleme beim Verify an den Nutzer meldet und stattdessen automatisch Reboot einleitet. Beim manuellen Patchen hingegen kann man auf der Konsole mitlesen, wie sich der flashit-Befehl verhält und ggf. nochmals flashen bei Problemen o.ä.
So, wer jetzt nur komplett Bahnhof verstanden hat, für den ist das ganze Problem nicht relevant/nützlich - oder muss wie ich viel Zeit und einiges an Risikobereitschaft in eine steile Lernkurve investieren ;-)
Ich bin jedenfalls glücklich, Ziel der Lifetimeupdates wurde erreicht ;-)
Zuletzt bearbeitet:
Ich habe es nicht, es wurde im Rahmen der Garantie ersetzt.
Nach der Erfahrung von @ddynamo. Es wäre nicht besser aus der Anwendung von M.I.B. Entfernen Sie den Neustart aus dem Befehl "3"?
Nach der Programmierung das M.I.B. Log überprüfen und dann den Reboot starten?
Ich weiss nicht, wer der autor M.I.B. ist.
Zuletzt bearbeitet:
Ja, es ist schwer etwas zu sagen, bevor man sieht, wie es sich nach dem Patch mit diesem Programm (M.I.B) verhält. Ich benutze nicht den Modus, diesen Patch und die Befehle, ich habe eine andere Möglichkeit, Mib2 zu aktivieren.
Zuletzt bearbeitet von einem Moderator:
weileong27
Newbie
- Registriert
- 12. Dezember 2020
- Beiträge
- 18
- Reaktionspunkte
- 5
- Punkte
- 23
Code:
Du musst dich
Anmelden
oder
Registrieren um den Inhalt der Codes zu sehen!
Wenn ich diesen Befehl über die MMX-Konsole ausgeben würde, wird dann der RCC-Flash oder der MMX-Flash gemountet?
CaptainCaracho
Ist gelegentlich hier
- Registriert
- 11. März 2014
- Beiträge
- 55
- Reaktionspunkte
- 22
- Punkte
- 28
schau dir doch den Kommentar darunter an # Automount des RCC-Flashbausteins der damit als /dev/fs0 eingebunden wird
weileong27
Newbie
- Registriert
- 12. Dezember 2020
- Beiträge
- 18
- Reaktionspunkte
- 5
- Punkte
- 23
kam dem Laden des RCC-Notfalls sehr nahe. Da nicht genügend Zeit vorhanden ist, um den Upload des Z-Modems abzuschließen, ändere ich die Baudrate auf 460800. Damit war genügend Zeit vorhanden, um den Upload der Emergency.ifs mit 3 MB abzuschließen, bevor das Gerät nach 4 Minuten neu gestartet wird. Das Gerät lädt das Notfall-RCC automatisch, nachdem der Upload abgeschlossen ist, bleibt jedoch eine Weile dort und bietet keine Anmeldeaufforderung. Kurz darauf wird das Gerät zurückgesetzt und ich konnte den Upload nicht erneut abschließen. Es ist wirklich schwierig, die Wiederherstellung über RCC zu versuchen. hoffentlich kann mich jemand dazu über MMX führen
Zuletzt bearbeitet:
Ähnliche Themen
- Gesperrt
- Angepinnt