F
fr3ts0n
Neues Mitglied
- 46
Das Odys Loox ist unkaputtbar! – Ein erlebter Abenteuerbericht
Alltag ...
Da ich für das Odys-Loox ja auch an der Kernelentwicklung beteiligt bin, hat mein Gerät doch eher ein hartes Leben, da die Halbwertzeit eines Testkernels unter Umständen nur in Stunden gerechnet werden kann. Dementsprechend oft wird mein Loox in den Downloadmodus versetzt (mit 'adb reboot bootloader') und erhält so mit dem rkflashtool die nächste Testversion eines Kernels.
Zum Test der geänderten Kernel-Funktionen in anderen Android-Versionen habe ich einige Backup-Images der verschiedenen Systeme auf der SD-Karte, die ich dann frisch fröhlich kreuz und quer zurück-restauriere. Kurz und gut, der Flash meines Loox kam eigentlich nie wirklich zur Ruhe.
Nicht mein Tag ...
Letztes Wochenende nun war es so weit, es kam wie es kommen musste: Da aus unbegreiflichem Grund mein SD-Backup des ICS (Oma 1.2.5) nach dem Restore nicht mehr laufen wollte, entschloss ich mich das System mit RKAndroidTool komplett neu zu flashen. Komplett heißt bei mir mit IDB-Erase und Bootloader flashen (was bisher immer gut funktioniert hat).
Dieser Flashvorgang wurde gerade im ungünstigsten Moment abgebrochen, nämlich nach IDB-Erase beim Flashen des Bootloaders. Nun kam erschwerend auch noch meine eigene Dummheit dazu, denn ich löste mit der Nadel einen Reset aus bevor ich den nächsten Programmierversuch starten wollte → Grober Fehler!
System down ...
Dieser Reset löschte die letzte, noch lauffähige Version des Bootloaders aus dem RAM-Speicher und das Loox war „hirntot“. Weder im Flash, noch im RAM war ein lauffähiger Bootloader zum Systemstart vorhanden. Das Ding wurde am USB des PC's nicht mehr als irgendein Gerät erkannt. Unter Linux war im Systemlog zwar erkennbar, dass das Loox wohl irgendwie am USB „rüttelt“, aber keine Anstalten machte irgendwelche USB-IDs und somit seine Gerätekennung preis zugeben. (Wie denn auch, die Kiste wusste seine eigene Kennung ja selbst nicht mehr)
Kurz und Knapp – Die Kiste liess sich einfach nicht mehr zum Leben erwecken.
(Da ich diese Situation erst im Nachhinein begriff, möchte ich an dieser Stelle nicht erwähnen, mit welchen „freundlichen“ Worten ich meine bisherige Vorgangsweise kommentiert habe)
Lehrgang in Reanimation ...
Da ich nicht glauben wollte, dass mein geliebtes (und gequältes) Looxilein nicht mehr unter den funktionierenden weilen sollte, machte ich mich daran den technischen Hintergrund für das „Dahin-scheiden“ und für eine eventuelle Re-Animation zu recherchieren. Das RK2918-Datenblatt (http://tabreview.ru/content/pdf_docs/RK2918_Datasheet_Rev_1_0.pdf) zeigte, dass der Controller einen Pin besitzt, mit dem offensichtlich ein alternativer ROM-Boot aus dem Controller eigenen ROM-Speicher aktiviert werden kann. - Also gibt es noch einen Bootloader
!
Auch einige Schaltpläne von Rockchip zur Musterbeschaltung des Controllers für MID's kursieren im Internet. (z.B. http://pdaplus.hu/download/maiden/2918sch.pdf, http://mr2857gb.googlecode.com/svn/trunk/rktools/rk2918_smart%20phone%20sdk_0218.pdf) Diese zeigten aber alle auf ernüchternde Weise, dass besagter Pin grundsätzlich auf Masse gelegt wird, was die Chance auf eine praktische Nutzung dieses Pins ohne gröbere Eingriffe auf der Platine annähernd auf Null setzt. Nachdem ich mein Suchmuster nach Tagen von dead/bricked/unbrick „RK2918“ auf „RK29“ schliesslich auf „Rockchip“ erweiterte, kam ich auf einen Beitrag zur Re-Animation eines RK27-basierten Mediaplayers. (Rockchip DEAD Player Recovery Guide)
In diesem Beitrag wird beschrieben, dass der alternative Boot-Mode durch kurzzeitiges Brücken von 2 Datenleitungen D0-D1 am Flash-Chip aktiviert werden kann. Also her mit dem Datenblatt des Flash-Chips und Suche nach den entsprechenden Pins im Chip-Layout. Loox aufmachen, Pins brücken, Kiste starten und … Nichts! Ok, in dem Beitrag wird beschrieben dass die Pins in bereits laufendem Betrieb gebrückt werden. Also Ladekabel einstecken, Pins brücken und … nach einigen Sekunden ertönt das im Bericht angesprochene „Clink Clunk“ wirklich! Mein (virtuelles) Windows meldet ein neues USB-Gerät, was auch sofort als „RK2918 device“ angezeigt wird!
Der Rest war (fast) Routine …
Sofort habe ich mein RKAndroidTool gestartet und eine Meldung wie „Found RK29 device in boot mode“ (oder so ähnlich) erhalten. Der aktuelle Bootloader wurde geflasht. Danach wurde automatisch ein Test durchgeführt, der – oh Schreck – failed meldet.
Bei einem weiteren Programmierversuch ( nur Erase-IDB, und Program Bootloader – und diesmal ohne Reset ) wurde der Test aber fehlerfrei bestanden und die restlichen Blöcke konnten problemlos geflasht werden.
Der letzte Spannungspunkt war überstanden, als das Gerät nach der beendeten Programmierung neu gestartet wurde, aber wie erhofft meldete sich die Recovery zur Vorbereitung der internen sdcard. Nach Ausführung von Oma's Formatierungs-zip startete das Gerät wie gewohnt zum „zweiten Leben“ mit JellyBean …
… Und wenn es wieder mal als „gestorben“ gilt, dann wird das oben genannte für ein eventuelles, drittes „Leben“ wiederholt, denn langsam glaube ich wirklich – Mit ein wenig angewandtem Fachwissen ist das Odys Loox unkaputtbar!
Anmerkung:
Die genannten Vorgänge sollten nur von fachkundigen Menschen durchgeführt werden, da durch die Öffnung des Gerätes und die Arbeit am offenen Gerät sehr leicht grössere Schäden entstehen können. Ich übernehme keine Haftung für eventuelle Schäden, die durch Nachahmung der beschriebenen Tätigkeiten entstehen können.
Mit der Ausführung oben genannter Schritte erlischt natürlich jegliche Garantie/Gewährleistung des Herstellers.
Liebe Grüsse und viel Erfolg
fr3ts0n
Alltag ...
Da ich für das Odys-Loox ja auch an der Kernelentwicklung beteiligt bin, hat mein Gerät doch eher ein hartes Leben, da die Halbwertzeit eines Testkernels unter Umständen nur in Stunden gerechnet werden kann. Dementsprechend oft wird mein Loox in den Downloadmodus versetzt (mit 'adb reboot bootloader') und erhält so mit dem rkflashtool die nächste Testversion eines Kernels.
Zum Test der geänderten Kernel-Funktionen in anderen Android-Versionen habe ich einige Backup-Images der verschiedenen Systeme auf der SD-Karte, die ich dann frisch fröhlich kreuz und quer zurück-restauriere. Kurz und gut, der Flash meines Loox kam eigentlich nie wirklich zur Ruhe.
Nicht mein Tag ...
Letztes Wochenende nun war es so weit, es kam wie es kommen musste: Da aus unbegreiflichem Grund mein SD-Backup des ICS (Oma 1.2.5) nach dem Restore nicht mehr laufen wollte, entschloss ich mich das System mit RKAndroidTool komplett neu zu flashen. Komplett heißt bei mir mit IDB-Erase und Bootloader flashen (was bisher immer gut funktioniert hat).
Dieser Flashvorgang wurde gerade im ungünstigsten Moment abgebrochen, nämlich nach IDB-Erase beim Flashen des Bootloaders. Nun kam erschwerend auch noch meine eigene Dummheit dazu, denn ich löste mit der Nadel einen Reset aus bevor ich den nächsten Programmierversuch starten wollte → Grober Fehler!
System down ...
Dieser Reset löschte die letzte, noch lauffähige Version des Bootloaders aus dem RAM-Speicher und das Loox war „hirntot“. Weder im Flash, noch im RAM war ein lauffähiger Bootloader zum Systemstart vorhanden. Das Ding wurde am USB des PC's nicht mehr als irgendein Gerät erkannt. Unter Linux war im Systemlog zwar erkennbar, dass das Loox wohl irgendwie am USB „rüttelt“, aber keine Anstalten machte irgendwelche USB-IDs und somit seine Gerätekennung preis zugeben. (Wie denn auch, die Kiste wusste seine eigene Kennung ja selbst nicht mehr)
Kurz und Knapp – Die Kiste liess sich einfach nicht mehr zum Leben erwecken.
(Da ich diese Situation erst im Nachhinein begriff, möchte ich an dieser Stelle nicht erwähnen, mit welchen „freundlichen“ Worten ich meine bisherige Vorgangsweise kommentiert habe)
Lehrgang in Reanimation ...
Da ich nicht glauben wollte, dass mein geliebtes (und gequältes) Looxilein nicht mehr unter den funktionierenden weilen sollte, machte ich mich daran den technischen Hintergrund für das „Dahin-scheiden“ und für eine eventuelle Re-Animation zu recherchieren. Das RK2918-Datenblatt (http://tabreview.ru/content/pdf_docs/RK2918_Datasheet_Rev_1_0.pdf) zeigte, dass der Controller einen Pin besitzt, mit dem offensichtlich ein alternativer ROM-Boot aus dem Controller eigenen ROM-Speicher aktiviert werden kann. - Also gibt es noch einen Bootloader
!Auch einige Schaltpläne von Rockchip zur Musterbeschaltung des Controllers für MID's kursieren im Internet. (z.B. http://pdaplus.hu/download/maiden/2918sch.pdf, http://mr2857gb.googlecode.com/svn/trunk/rktools/rk2918_smart%20phone%20sdk_0218.pdf) Diese zeigten aber alle auf ernüchternde Weise, dass besagter Pin grundsätzlich auf Masse gelegt wird, was die Chance auf eine praktische Nutzung dieses Pins ohne gröbere Eingriffe auf der Platine annähernd auf Null setzt. Nachdem ich mein Suchmuster nach Tagen von dead/bricked/unbrick „RK2918“ auf „RK29“ schliesslich auf „Rockchip“ erweiterte, kam ich auf einen Beitrag zur Re-Animation eines RK27-basierten Mediaplayers. (Rockchip DEAD Player Recovery Guide)
In diesem Beitrag wird beschrieben, dass der alternative Boot-Mode durch kurzzeitiges Brücken von 2 Datenleitungen D0-D1 am Flash-Chip aktiviert werden kann. Also her mit dem Datenblatt des Flash-Chips und Suche nach den entsprechenden Pins im Chip-Layout. Loox aufmachen, Pins brücken, Kiste starten und … Nichts! Ok, in dem Beitrag wird beschrieben dass die Pins in bereits laufendem Betrieb gebrückt werden. Also Ladekabel einstecken, Pins brücken und … nach einigen Sekunden ertönt das im Bericht angesprochene „Clink Clunk“ wirklich! Mein (virtuelles) Windows meldet ein neues USB-Gerät, was auch sofort als „RK2918 device“ angezeigt wird!
Der Rest war (fast) Routine …
Sofort habe ich mein RKAndroidTool gestartet und eine Meldung wie „Found RK29 device in boot mode“ (oder so ähnlich) erhalten. Der aktuelle Bootloader wurde geflasht. Danach wurde automatisch ein Test durchgeführt, der – oh Schreck – failed meldet.
Bei einem weiteren Programmierversuch ( nur Erase-IDB, und Program Bootloader – und diesmal ohne Reset
) wurde der Test aber fehlerfrei bestanden und die restlichen Blöcke konnten problemlos geflasht werden.Der letzte Spannungspunkt war überstanden, als das Gerät nach der beendeten Programmierung neu gestartet wurde, aber wie erhofft meldete sich die Recovery zur Vorbereitung der internen sdcard. Nach Ausführung von Oma's Formatierungs-zip startete das Gerät wie gewohnt zum „zweiten Leben“ mit JellyBean …
… Und wenn es wieder mal als „gestorben“ gilt, dann wird das oben genannte für ein eventuelles, drittes „Leben“ wiederholt, denn langsam glaube ich wirklich – Mit ein wenig angewandtem Fachwissen ist das Odys Loox unkaputtbar!
Anmerkung:
Die genannten Vorgänge sollten nur von fachkundigen Menschen durchgeführt werden, da durch die Öffnung des Gerätes und die Arbeit am offenen Gerät sehr leicht grössere Schäden entstehen können. Ich übernehme keine Haftung für eventuelle Schäden, die durch Nachahmung der beschriebenen Tätigkeiten entstehen können.
Mit der Ausführung oben genannter Schritte erlischt natürlich jegliche Garantie/Gewährleistung des Herstellers.
Liebe Grüsse und viel Erfolg
fr3ts0n
