RP ✔️ Neuer Controller V3.1 bei aktuellen Xiaomi Rollern: Brickgefahr bei DRV Downgrade / Vorgehen

  • Ersteller Ersteller Gast
  • Erstellt am Erstellt am
Status
Für weitere Antworten geschlossen.
Ich bin der Administrator einer spanischen Telegram-Gruppe mit mehr als 9.000 Mitgliedern
Comunidad Mi Patinete 365 (mp365.es). Es freut mich sehr, ein Mitglied der Spanischen Roller Community hier anzutreffen! Danke, dass du dich hier angemeldet hast, um die von uns geteilten Informationen zu würdigen und gleichzeitig um neue Erkenntnisse zu ergänzen. Es ist schön zu sehen, wie ein gemeinsames Hobby Menschen verschiedener Länder und Sprachen zusammenbringt.
 
Hallo und guten Tag zusammen,

ich bin absolut neu hier in dem Forum :-) Ich wollte die Tage einen neuen pro 2 Flashen bis ich auf den Thread hier aufmerksam geworden bin. Ich hätte eine Frage Gesetz dem Fall es ist der V3.1 Controller verbaut gibt es aktuell keinerlei Möglichkeit etwas zu ändern ausser für 80 € einen anderen Controller zu besorgen ? Wenn dieser verbaut ist was genau muss dann gemacht werden ?


Lieben Gruss
Manuel
 
Hallo und guten Tag zusammen,

ich bin absolut neu hier in dem Forum :) Ich wollte die Tage einen neuen pro 2 Flashen bis ich auf den Thread hier aufmerksam geworden bin. Ich hätte eine Frage Gesetz dem Fall es ist der V3.1 Controller verbaut gibt es aktuell keinerlei Möglichkeit etwas zu ändern ausser für 80 € einen anderen Controller zu besorgen ? Wenn dieser verbaut ist was genau muss dann gemacht werden ?


Lieben Gruss
Manuel
Erster Teil, erste Frage : richtig
Zweiter Teil : fast richtig, soviel muss man nicht ausgeben :
€ 29,63 5%OFF | M365 3,0 version Motherboard Controller Wichtigsten Bord ESC Für XIAOMI Mijia M365 /Pro 1S Pro 2 Elektrische Roller mainboard Teile

Zweite Frage: die angepinnten Anleitungen zu SHFW, CFW oder VLT lesen, je nachde, was man bevorzugt.

Bei konkreten Fragen geht es dann im jeweiligen Thread weiter!

PS: Willkommen im Club 👍
 
S Sven000001 Danke :)

Neu: Hinweis zu DRV016 (Mi3) sowie Details zum verbauten Chip im ersten Post aufgenommen.

Hoffen wir das es bald eine Lösung dafür gibt. ;-)
Ich denke die Lösung besteht darin, eine VLT auf Basis der neusten DRVs zu erstellen (Ausführung im ersten Post). Der VLT WebPatcher unterstützt diese schon voll und ganz (es waren nur minimale Änderung notwendig), da die Files aber aktuell nicht im Netz verfügbar sind, muss man diese selbst vom eigenen Endgerät sichern. Eine Anleitung dafür gibt es von meiner Seite nicht, da ich eine mögliche Verbreitung von geschütztem Material nicht unterstütze.
 
Zuletzt bearbeitet von einem Moderator:
Ich bin gerade über diesen Faden gestolpert und habe zur Sicherheit bei meinem Roller (MFD 08/20) nachgeschaut, dass auch der Controller alt genug ist (hab Glück). Bei der Gelegenheit habe ich gleich noch ein Foto meines Controller-ICs gemacht, da der Schriftzug auf dem vorhandenen Beispielfoto nicht so gut zu erkennen ist.

XUd947s.jpg


Ich könnt es gern übernehmen 🙂
 
Zuletzt bearbeitet:
vielleicht hilfte es ja dem ein oder anderen roller datum 5/21 FF in der seriennummer und controller v3.0 downgrade via pc und midu funktioniert problemlos
 
Danke dir für die Rückmeldung M MR4KA !

Allerdings ist es wichtig zu differenzieren wo das FF auftaucht.
Du sagtest im MiDu-Flasher Thread das es in der SerienNr. des BMS bei dir auftaucht.
Das ist ein großer Unterschied!

Die UUID von der wir hier sprechen, ist jedoch eine im Mikrocontroller fest eingebrannte Kennung des Controllers.
Deswegen kann man auch (zum Glück) daran erkennen das es sich um einen anderen Mikrocontroller handelt.
 
  • Hilfreich!
Reaktionen: MR4KA
ja da habe ich mich fertippt bei mir war es zufällig in der bms und udid drin jeweil die 3,4 te stelle war das FF
edit// des wegen habe ich mit nem zahnstocher unten nach geschaut was auf dem board selber steht v3.0 insofern alles gut gelaufen :D
 
  • Hilfreich!
Reaktionen: VooDooShamane
Also ich denke daraus muss man kein Geheimnis mehr machen und an dieser Stelle auch Credits geben: Conejo, also die Person hinter den "XiaoTea" und "m365rec" Tools, hat es geschafft den GD32 Chip vom neuen Controller zu dumpen und ein Recovery Skript am 23.5. über den ** Bezahlsoftware ** Kanal veröffentlicht, also kein privater Kanal und für jeden zugänglich (siehe Screenshot).

Hier einige Erkenntnisse daraus:
1. Der GD32 Chip hat einen neuen Bootloader
2. Die für die Recovery verwendete DRV stimmt mit der aktuellsten DRV überein -> meine Vermutung hat sich damit bestätigt: die neuen DRVs wurden mit Cortex-M4 Unterstützung kompiliert
3. Um den GD32 Chip beschreibbar zu machen bzw. zu unlocken, muss man einen speziellen Code ausführen. Inwieweit sich der von Conejo entwickelte Unlock Code vom "stm32-unlock" unterscheidet habe ich nicht untersucht

Die Recovery ist für den Mi3 gedacht, aber die enthaltene DRV016 lässt sich durch die DRV248 bzw. DRV321 ersetzen, um einen V3.1 Controller zu retten.

Weitergehend bedeutet das, wie bereits in meinem vorherigen Post vermutet, dass CFWs bzw. VLT auf Grundlage der aktuellsten DRVs erstellt werden können. Es wurde ja schon berichtet, dass ** Bezahlsoftware ** bei den neuen Controllern funktioniert, jetzt wisst ihr wieso.
 

Anhänge

  • Screenshot_2022-06-07-09-22-22-12_948cd9899890cbd5c2798760b2b95377.webp
    Screenshot_2022-06-07-09-22-22-12_948cd9899890cbd5c2798760b2b95377.webp
    76,2 KB · Aufrufe: 303
Also ich denke daraus muss man kein Geheimnis mehr machen und an dieser Stelle auch Credits geben: Conejo, also die Person hinter den "XiaoTea" und "m365rec" Tools, hat es geschafft den GD32 Chip vom neuen Controller zu dumpen und ein Recovery Skript am 23.5. über den ** Bezahlsoftware ** Kanal veröffentlicht, also kein privater Kanal und für jeden zugänglich (siehe Screenshot).

Hier einige Erkenntnisse daraus:
1. Der GD32 Chip hat einen neuen Bootloader
2. Die für die Recovery verwendete DRV stimmt mit der aktuellsten DRV überein -> meine Vermutung hat sich damit bestätigt: die neuen DRVs wurden mit Cortex-M4 Unterstützung kompiliert
3. Um den GD32 Chip beschreibbar zu machen bzw. zu unlocken, muss man einen speziellen Code ausführen. Inwieweit sich der von Conejo entwickelte Unlock Code vom "stm32-unlock" unterscheidet habe ich nicht untersucht

Die Recovery ist für den Mi3 gedacht, aber die enthaltene DRV016 lässt sich durch die DRV248 bzw. DRV321 ersetzen, um einen V3.1 Controller zu retten.

Weitergehend bedeutet das, wie bereits in meinem vorherigen Post vermutet, dass CFWs bzw. VLT auf Grundlage der aktuellsten DRVs erstellt werden können. Es wurde ja schon berichtet, dass ** Bezahlsoftware ** bei den neuen Controllern funktioniert, jetzt wisst ihr wieso.
es gibt aber momentan keine drv248 online zu finden, richtig?
 
Ich denke, es war nur als Beispiel gedacht, natürlich kann man auch eine 236 bzw. 304 nehmen.....
 
ist die 248 nicht ohne hin schon die verschlüsselte??
Soweit ich es verstanden habe ist es nur die BLE 157 die verhindert das man über bluetooth flashen kann, DRV hat damit nichts zu tun. Also wenn man ein modell mit neuem controller hat, aber noch mit älterer BLE geliefert sollte man zumindest eine custom firmware auf DRV 248 basis (zb VLT) ohne weiteres nutzen können. nur gibts die stock firmware zum patchen nirgends online und die meisten werden nicht die möglichkeit haben sie selber zu dumpen
 
  • Hilfreich!
Reaktionen: 4Ultra
T tekashi6ix9ine Alles richtig verstanden, top!
Olli_69 Olli_69 Sicher ist nur, dass die aktuellsten DRVs kompatibel sind. Es kann sein dass die von dir genannten Versionen gehen, aber es lässt sich mit bloßem Auge nicht sagen. Wird eine DRV für einen bestimmten Prozessortyp erstellt, dann wird der Code für diesen Prozessor optimiert. Diese Optimierungen machen es jetzt aber einem neuen Prozessor schwierig bis unmöglich, das richtige zu tun.

Es ist ja auch so, dass man sich durch das Flashen keinen Hard-Brick (=Gerät startet gar nicht mehr) sondern nur einen Soft-Brick holt, also das Gerät lebt noch, meldet aber ständig Fehler und ist faktisch unbrauchbar. Das deckt sich mit der Theorie, dass der neue Prozessor Teile Firmware versteht, aber andere Teile (die optimierten) nicht. Gesichert ist, dass man sich mit der DRV248 / DRV321 / DRV016 als Basis keinen Brick holt, weil diese eben für den alten und neuen Prozessor erstellt wurden.

Die neuen DRVs unterscheiden sich technisch nicht von den jeweils vorherigen Versionen. Es gibt in der DRV keine neue Verschlüsselung und auch keinen Downgrade-Schutz. Lediglich das GM wurde deaktiviert wie VooDooShamane VooDooShamane erkannt hat. Wie in diesem Beitrag erklärt, wurde dazu ein neues Flag eingeführt, somit ist das GM nur noch möglich, wenn der Roller eine spezielle Werks-Seriennummer hat. Ich denke das ist dafür, damit Distributoren vor der Auslieferung die individuellen Seriennummern festlegen können. Wie auch immer: LTGM und alle anderen Mods gehen nach wie vor.

Von meiner Seite ist das alles, was ich dazu an Informationen habe.
 
M MrScooterGuy Mit ** Bezahlsoftware ** kann man nur ** Bezahlsoftware ** flashen (nach Bezahlung).

Wie hier beschrieben gibt es einen Weg firmwareseitig bzw. daran anschließend über eine App herauszufinden, welcher Chip verbaut ist. Die Firmware kennt 3 Typen: den alten STM32 Chip und zwei neue GD32 Chips. Diese unterschiedlichen Chips sind nicht nur den aktuellsten DRVs bekannt, sondern auch den jeweils vorherigen Versionen DRV247 und DRV319. Daher vermute ich stark, dass diese DRVs ebenfalls mit dem neuen Controller kompatibel sind. Dafür lege ich meine Hand aber nicht ins Feuer und ich rate auch niemandem, das zum jetzigen Zeitpunkt auszuprobieren, ohne das Risiko eines Bricks einzukalkulieren.
Wichtig: DRV236 und DRV304 treffen die Unterscheidung nicht und sind damit mit dem V3.1 Controller inkompatibel!
 
Alles richtig was nandtek hier schreibt.
Das deckt sich mit meinen Beobachtungen.
Meine Vermutung ist allerdings das die DRV247/319 nur kompatibel mit dem GD32F103CBT6 mcu sind, da der den ARM Cortex-M3 Befehlssatz hat den auch der alte STM32F103x macht.
Man kann in den Header Informationen der DRV248/321 erkennen, das sie um eine weiteren MCU erweitert wurden.

Diese 2 GD32 Mikrocontroller sind mir nun bekannt und bestätigt:
GD32E103CBT6 (ARM Cortex-M4)
(bestätigt von L leelt)
GD32F103CBT6 (ARM Cortex-M3)
(Controller der mir aktuell zum testen vorliegt)
Danke nochmal an N Nebelfee2010 für das Vertrauen und zusenden.
20220607_220409.jpg


Beide Mikrocontroller haben einen Flash-speicher von 128kb.
Also genauso wie der alte STM32F103.

Diesen Mikrocontroller den ich gerade hier in einem v3.1 controller vorliegen habe gibt es auch noch in der GD32F103C8T6 Variante.
Dort ist fast alles gleich, ebenfalls ARM Cortex-M3, nur der Flash-speicher hat eine Größe von 64kb.
Der Dump von conejo aus dem Telegramm hat nur 64kb.
Entweder hat Conejo das B für eine 8 gehalten, oder er hat wissentlich von dem eigentlich 128kb großen Flash-speicher nur 64kb gezogen weil nach 64kb eh nix mehr kommt.
Die andere Möglichkeit wäre das conejo tatsächlich die GD32F103C8T6 Variante mit nur 64kb Flash-speicher vorliegen hatte.
Letzteres würde bedeuten es gibt sogar noch eine dritte Variante des GD32 MCU die in den v3.1 Controller verbaut wird.

Weitere Informationen werden folgen.
 
Zuletzt bearbeitet:
Vielen Dank für das Teilen der Informationen VooDooShamane VooDooShamane.
Bitte nicht falsch verstehen, mir geht es hier um akkurate Informationen, da dieser RP Thread als Referenz dienen soll.

ARM Cortex-M3 Befehlssatz
Cortex-M4 enthält den M3 Befehlssatz. Es ist also bei beiden Chips derselbe Befehlssatz.

Meine Vermutung ist allerdings das die DRV247/319 nur kompatibel mit dem GD32F103CBT6 mcu sind, da der den ARM Cortex-M3 Befehlssatz hat den auch der alte STM32F103x macht.
Durchaus möglich, wenn die eingangs erwähnten Kompiler-Optimierungen nur für die aktuellsten DRVs duchgeführt wurden. Das was du sagst ist wichtig und die Frage berechtigt: es muss noch geprüft werden, ob DRV247/319 tatsächlich auch mit dem M4 Kern funktionieren!

Man kann in den Header Informationen der DRV248/321 erkennen, das sie um eine weiteren MCU erweitert wurden.
Ich sehe nur, dass dort andere Register verwendet werden. Das ist aber nicht unüblich, siehe DRV155.

Entweder hat Conejo das B für eine 8 gehalten
Nein.... "GD32E103CB Unprotector by Conejo/** Bezahlsoftware **"

wissentlich von dem eigentlich 128kb großen Flash-speicher nur 64kb gezogen weil nach 64kb eh nix mehr kommt.
Genau so ist es. Bei den Firmwares kommt nach 64kb grundsätzlich nichts mehr und damit die kompatibel zu alten MCUs bleibt, darf es das auch nicht.

GD32F103C8T6 Variante mit nur 64kb Flash-speicher vorliegen hatte.
dritte Variante des GD32 MCU die in den v3.1 Controller verbaut wird.
Bitte keine Gerüchte in die Welt setzen. Eine solche Variante ist weder der Firmware selbst bekannt noch gibt es dazu Informationen im Netz.
 
Zuletzt bearbeitet von einem Moderator:
  • Hilfreich!
Reaktionen: 4Ultra und Chrillema
Nein.... "GD32E103CB Unprotector by Conejo/** Bezahlsoftware **"
Um den GD32E geht es mir garnicht.
Der hat 128kb Flash-speicher. (Siehe vorherigen Post)
Mir geht es um die F Variante.
Dort gibt es einen mit 8 statt B der eben nur 64kb hat.
Es war nicht meine Absicht "Gerüchte" in die Welt zu setzen.
Ich habe lediglich eine berechtigte Vermutung aufgestellt.
Zu den anderen Dingen kann ich momentan nichts sagen, da ich unterwegs bin.
 
  • Hilfreich!
Reaktionen: 4Ultra
Status
Für weitere Antworten geschlossen.