uImage_recovery erstellen?

[McBane87]

Hallo Zusammen,

Vielleicht kann mir jemand von euch auf die Sprünge helfen.
Ich schaue mir gerade das Repo vom CyanogenMod an und habe zumindest Testweise erstmal ein Recovery.img gebaut. Wie kann ich daraus ein uImage_recovery bauen?

Gruß McBane

 

[perpe]

uImage ist ein bisschen zu allgemein gefasst.
Auch wenn sie alle auf Das U-Boot basieren, so ändert es doch nichts daran, dass viele Prozessorhersteller an dem Format Änderungen vornehmen, gerade wenn es dann auch im Zusammenspiel mit Android ist.

Wenn du also geschrieben hättest, um welchen CPU es sich handelt, hätte man dir ehr helfen können.

So mal nur allgemein: das CWM recovery.img bringt dir erst mal nichts, du kannst sie jedoch entpacken, hast dann Kernel und die Ramdisk, diese zwei muss du dann ins uImage Format deines Geräts bringen. Die verbeitesten Boards bei Android Geräten, die uImage nutzen sind wohl jene von Amlogic. Für Amlogic M3 findest du z.B. in der Repo https://github.com/wuzf/Android/tree/master/unpack repack kernel/Amlogic M3 pack und entpack Scripte (sind natülich für uImage, deine recovery muss du wie sonst üblich entpacken), . Ähnliches muss du mal für dein Gerät/CPU googlen, wenns es von Amlogic ist die Wahrscheinlichkeit groß, dass du die selben Scripte nutzen kannst, solltest du jedoch trotzdem vorher prüfen.

 

[McBane87]

Hi,

Danke auf jedenfall schon mal für deine Antwort.
Es handelt sich tatsächlich um ein Amlogic-Gerät.

Odys Uno X8
Cortex A9, Amlogic MXS

Die Scripte habe ich auch schon gefunden und auch schon etwas probiet.
Nur entweder bin ich noch nicht weise genug um diese korrekt zu benutzen, oder es geht einfach nicht mit dem MXS. Scheinbar muss ich da ja als Vergleich auch ein Original uImage_recovery nutzen, bloß ich bleibe iwie immer dabei hängen, dass die Scripte der Meinung sind das Originale uImage_recovery sei:

[Sinngemäß]
Bad Magic Word
No Uimage

Ich lege mal in den Anhang das was ich bisher habe.

 

[perpe]

Bei den MX gab es wohl einige Änderungen. Am besten suchst du nach dem CPU und Recovery dafür, irgendwo wirst du schon die richtigen Tools/Scripte in einer Repo finden. Anfangen kannst du mit
New ROM MTD format AML8726-MX (Jynxbox M6))
Und
How To Unbrick Your Amlogic AML8726-MX Series Tablet - v2.0 - Ainol Novo 7 Crystal - SlateDroid.com

In den zwei Foren sind einige Profis unterwegs, die sich mit diesen CPUs auskennen. Wurstele dich durch

Schau dich auch auf Tablet - Amlogic openlinux um, Amlogic hat vieles als Open Source veröffentlicht, dort müsste eigentlich auch brauchbares drin sein, jedoch müsstest du ziemlich viel Code runterladen.

 

[McBane87]

Ok, danke.
Dann werd ich mich da vielleicht mal durchfragen.
Irgendwie bringt mich das Lesen dort nicht wirklich weiter.
Die rennen da iwie in eine andere Richtung als ich will......

 

[perpe]

Nein, das ist genau die richtige Richtung.
Bevor du eine eigene Recovery erstellst und sie flashst, musst du wissen, wie dein Gerät funktioniert und wie du es im Notfall auch retten kannst. Dieses Wissen erhältst du in den Threads und in den Links dort. Das Hintergrundwissen brauchst du, wie willst du ohne eine funktionierende Recovery erstellen?

Du findest dort z.B. auch eine Anleitung wie man diese Geräte von SD Karte booten kann. Für dich ist das ganz wichtig, da du so eine eigene Recovery gar nicht aufs Gerät flashen brauchst sondern gefahrlos von der SD testen kannst.

Du weißt aktuell kaum was über dein Gerät, so kannst du keine Recovery erstellen und sicherstellen, dass du diese Recovery auch gefahrlos nutzen kannst. Was sind das für Dateien in dem Archiv? Hast du dich mit ihnen beschäftigt, vor allem mit der Datei uImage_recovery.orig? Ist dir aufgefallen, dass es gar kein uImage ist sondern im stinknormalen Android boot/recovery Image Format?

 

[McBane87]

Ja du hast natürlich recht, dass ich dadurch lerne wie ich mein Gerät eventuell wieder reparieren kann falls ich zu voreilig war oder sonst was nicht funktioniert hat. Aber mein Ziel das bootable uImage-recovery ist da nicht beschrieben. Und ich habe ja auch gar nicht vor das recovery zu flashen. Deshalb will ich ja auch das uImage_recovery haben um es per Tastenkombi zu laden ohne was kaputt zu machen.

Ist dir aufgefallen, dass es gar kein uImage ist sondern im stinknormalen Android boot/recovery Image Format?

Nein bisher nicht. Es ist aber auch schwierig etwas herauszufinden was man nicht kennt Das würde aber erklären warum alle Scripte der Meinung sind es sei kein uImage. Bloß was beduetet das jetzt für mich? Kann ich die Recovery.img einfach in uImage_recovery umbennen? Vermutlich nicht.

 

[perpe]

Nein, schwer nicht wirklich.

Wenn du ein echtes uImage im Terminal mit "file Dateiname" prüfst, erkennt es den Filemagic von u-boot (u-boot legacy uImage...)
Wenn du deine Datei mit file überprüfst, kommt nur ein "data", das steht auch bei den Android boot/recovery image Dateien. Dann kann man schon mal spaßeshalber versuchen zu entpacken, kannst aber auch die Datei mal mit einem Hex-Editor aufmachen und siehst, dass es den Android Header hat. (erwähnte ich schon Hintergrundwissen )

Daraus folgt, dass du dein recovery.img im Grunde nehmen/umbennenen kannst, sofern es mit den richtigen Angaben erstellt wurde und du auch sichergestellt hast, dass es alles notwendige enthält. Natürlich sind alle Angaben ohne Gewähr, überprüfen und sicherstellen muss du es schon selber. Das ist nur eine Folgerung aus der Logik. Wie erwähnt lerne dein Gerät kennen, bevor du etwas flashst. So wurde z.B. in den verlinkten Threads irgendwas von Sicherheitsmechanismen geschrieben...

 

[McBane87]

Also meine Recovery.img umbenennen hat nichts gebracht. Das heißt nun entweder das IMG funzt nicht oder das umbenennen ist nicht ausreichend.
Es scheint auch so das ein extra u-boot.bin Datei mit auf der SD liegen soll, wenn ich mich bisher richtig belesen habe. Ändert aber erstmal nix weiter.

Aber da kommen mir gleich nochmal 2 Fragen:

Kann man eigentlich in diesem frühen Stadium iwas mitloggen?

Was genau ist ein CWM Fakeflash. Alle Erklärungen weisen imme nur daruaf hin, dass die Originale Recovery-Partition nicht beschrieben wird, sondern es iwie temporär auf Gerät geschrieben wird. Aber was bedeutet das genau? Liegt es dann im RAM? Darf ich dann nicht Ausschalten? Die Erklärung ist mir einfach zu wenig.... :-(

 

[perpe]

Was willst du den mitloggen, kommt doch ganz drauf an, was du mit dem Image gemacht hast. Hast du es auf das Gerät geflasht oder was?

Hast du mal deine original Recovery entpackt und reingesehen? Sie mal mit anderen Standard Stock Recoveries verglichen? Ohne das zu machen, kannst du auch nicht wissen, ob dein Gerät zusätzliche Informationen in der Recovery braucht. Gute Vergleichsrecovery sind da z.B. die Nexus Stock Recoveries, findest du in jedem Factory Image von Google.

Hast du andere Custom Recoveries für den CPU gefunden, dann kannst du sie mit deiner Vergleichen.

Mehr als das kann ich dir nicht helfen, da ich mich weder mit dem Gerät noch dem CPU auskenne, das Wissen muss du schon selber zusammen suchen und dir aneignen.

Die Erklärungen sind dir zu wenig, weil dir das Basiswissen fehlt. Das muss du dir schon erst vorher aneignen.
Eine Recovery besteht im Normalfall aus Kernel und Ramdisk, ebenso auch das boot.img. Beide sind im selben Format. Sie sind so gepackt auf das Gerät geschrieben, beim booten wird erst der Kernel und dann die Ramdisk in den RAM geladen und erst dort entpackt und der Recovery Dienst gestartet. Dieser Dienst schaut bei der Stock Recovery, ob die Datei /cache/recovery/command existiert, in dieser Textdatei stehen die Anweisungen drin, z.B. "--update_package=SDCARD:update.zip" (um eine zip von SD zu flashen) oder "--wipe_data" (für einen Factory Reset), die Android an die Recovery weitergeben hat.
Wenn also der Recovery Dienst die Anweisung erhalten hat nach einer ZIP auf der SD zu schauen, macht es das auch. Wenn es die ZIP gefunden hat, wird geprüft, ob die Signierung stimmt, falls ja, wird die update-binary aus der ZIP gestartet, dieses lädt das updater-script und führt die darin enthaltenen Anweisungen aus.
Diese Methode kann man nun auch nutzen um eine Fakeflash Recovery statt z.B. eine Update.zip zu flashen, die die System Partition verändert. Bei der Fakeflash Recovery werden die Datein also nicht in die Systempartition geschrieben und auch nicht dahin auf dem Speicher, wo das recovery.img geschrieben ist, sondern direkt in den RAM, wo eben auch die aktuell Dateinen der Recovery liegen (nicht der Prozess, dieser hat seinen eigenen Bereich im RAM), diese werden dabei überschrieben und am Ende der Recovery Dienst abgewürgt/gekillt. Der Dienst startet dann automatisch neu (im Normalfall, ansonsten muss man es noch mit auf den Weg geben über das updater-script). Beim Neustart des Dienstest wird dann die neuen Recovery Dateien genutzt. da die alten im RAM überschrieben wurden. Somit startet dann eben die Fake Recovery.
All das geschieht im RAM und dadurch wird nichts am Gerät verändert, außer natürlich man nutzt dann die Fake Recovery um was anderes zu flashen.

Wie man eine Fake Recovery erstellt, wird u.a. auf My Brain Hurts: Porting Clockwork Recovery to New Devices) erklärt (sofern es noch aktuell ist)

So viel von meiner Seite dazu. Nimm dir die Zeit dich mit dem Thema richtig auseinander zu setzen, so bringt es kaum was.

 

[McBane87]

Ich danke dir auf jedenfalls vielmals für deine antworten auch wenn ich dich scheinbar mit meinen Fragen langweile/nerve

Ich kann nur sagen ich durchforste schon seit Tagen die Foren und Anleitungen.
Auch habe ich schon Dateien innerhalb der Recoveries verglichen und angepasst.
Alles bisher erfolglos. Also es ist nciht so, dass ich es auf dem Silbertablett haben will. Das Tablet läuft auch so ohne CyanogenMod oder CWM bisher zufriedenstellend. Ich spiele bloß gerne mit anderen Sachen um neues zu erfahren

Was ich mit den Logs machen würde?
Naja, es wäre schön zu sehen ob der Kernel geladen wird und wenn ja was danach kommt und an welcher Datei er sich vielleicht die Zähne ausbeißt oder welche fehlt. Ohne Logs stochert man immer so im Dunkeln

 

[perpe]

Nein, du langweilst mich nicht. Es ist nur müssig, wenn man merkt, dass Grundlagen fehlen. Bin ja nun keine Lehrerin und kann nur Anhaltspunkte geben, was sich dann nun mal alles andere als einfach gestallte, wenn man weder weiß was der andere gerade gemacht hat noch inwiefern er sich auskennt. Es liegt ja nun an dir, die Anhaltspunkte zu verwerten
Ich weiß z.B. immer noch nicht, was du mit deiner Recovery gemacht hast und was dann passiert ist. "hat nichts gebracht" ist halt sehr inhaltslos, kann man sich nichts drunter vorstellen.

Kernel Logs bekommst du über dmesg. Wenn deine Recovery adb kann, dann
entweder über "adb shell dmesg" bzw. adb shell cat /proc/kmsg.
Logcat müsste in der Recovery auch funktionieren. Die selben Mittel, wie beim normalen System eben auch.
Oder du bootest nach dem erfolglosen versuch ins System und schaust unter /proc/last_kmsg nach, dort sind die Kernellogs vom letzten Systemstart und lauf drin, quasi Archiv.

 

[McBane87]

"hat nichts gebracht" ist halt sehr inhaltslos

Ja da hast du natürlich recht. Und deine Stupser haben mich auch auf jedenfall schon weiter gebracht als vorher. Ich weiß zum Beispiel nun, dass das Original uImage Recovery auf jedenfall eine recovery.img ist und das wenn man die splittet der Kernel ein uImage (LZMA compressed) ist. Zumindest behauptet der Befehl "file" das.

Ich hab mich bloß bisher noch nicht so wirklich durchgerungen welche Methoden ich von meinen hunderten Versuchen hier schildern soll. Ich weiß langsam schon selbst nicht mehr was ich alles probiert habe und was nciht. Aber meine letzten versuche kann ich dir schildern:

Das Anoil Crystal scheint dem Uno X8 sehr ähnlich zu sein. Zumindest was Board+CPU+RAM+Flash angeht. Trotzdem funktionieren die dort berietgestellten uImage_recoverys bei mir nicht. Bedeutet Android-Logo erscheint und beliebt stehen oder Variante 2: Logo erscheint und kurze Zeit später Bild schwarz = shutdown.

Ich habe mir also so ein paar uImage Scripte von dort besorgt die für Windows sind. Es gibt zwar auch welche für Linux aber die habe ich in vorherigen Versuchen verwendet. Aktuell ist gerade das für Windows. Link

Hier habe ich nun zuerst versucht den Kernel der aus meiner gesplitteten recovery.img stammt und tatsächlich mal ein uImage ist in diesem Script zu entpacken. Klappt auch. Jetzt habe ich das pure Kernel Image und initramfs, welches sehr spärlich ist, da scheinbar keine Daten enthalten sind. Nun kopiere ich den root-Ordner meiner neu erstellten CWM-Recovery in den Ordner initramfs der vom uImage-Tool entpackt wurde. Als nächstes lasse ich das Script das uImage wieder zusammenbauen. Leider ohne erfolg, da es der Meinung ist das alte ramfs war viel kleiner und so könne das nun nicht gehen.

Jetzt fange ich an zu Tricksen mache mir ein Backup der puren Kernels aus meinem Originalen uImage-Kernel und entpacke in den Tools stattdessen das uImage_recovery welches für das Crystal gedacht ist und von SlateDroid stammt. Nun lösche ich den Kernel des Crystals und ersetze ihn mit dem vom Uno X8. Und das initramfs habe ich auch mein eigenes statt dem extrahierten in den Ordner kopiert. Nun hab ich das Script wieder das uImage zusmmenpacken lassen. Diesmal war ihm das ramfs nicht zu groß, da er es mit der Größe des Crystals verglichen hatte. Nun hatte ich also mein richtiges uImage_recovery mit meinem Kernel und meinem RAMFS.

Also hab ichs getestet. Tastenkompi Vol+ und Power. Tablet zeigt Android-Logo. Tablet macht Bildschirm schwarz, aber nicht schutdown, denn Hintergrundbeleuchtung ist an. Ab dieser Stelle passiert aber nix mehr. Habe auch so 5-10min gewartet. Logcat mit ADB=Fehlanzeige.

Das war tatsächlich aber mein bester Testdurchlauf bisher. Ich hatte endlich mal etwas mehr als nur das Logo im Standbild. Nun habe ich mir die Init-Scripte und udev-scripte der Original Recovery und der cwm-recovery angeschaut. Habe fehlende zeilen in den cwm-scripten hinzugefügt. Am auffälligsten waren dabei wohl sämtliche einträge der udev.amlogic.rc welche komplett gefehlt haben und das laden eines Moduls (deferreddrv.ko), welches ich noch hinzugefügt habe sowohl das modul als auch die scriptzeile.
Danach habe ich das uImage wieder mit dem Trick zusammengebaut und getestet. Nun bekomme ich Logo->schwarz->reboot->normaler systemstart.

OK, nächster versuch dachte ich. Back to the roots. Das original war ein Android IMG-File. Also mein nun modifiziertes initramsfs welches cwm enthält und die angepassten scripte mit dem moduel plus original kernel (uImage, LZMA compressed) als IMG-File gebaut:

mkbootimg.exe --kernel uImage_recovery.orig-kernel --ramdisk ramdisk_cwm_mod.cpio.gz  --base 0x10000000 --pagesize 2048 -o recovery-cwm_mod.img

 file uImage_recovery.orig
uImage_recovery.orig: Android bootimg, kernel (0x10008000), ramdisk (0x11000000), page size: 2048

file recovery-cwm_mod.img
recovery-cwm_mod.img: Android bootimg, kernel (0x10008000), ramdisk (0x11000000), page size: 2048

Jetzt wieder getestet.
Logo kommt. Schwarzes aber beleuchteter Bildschirm mit einem kleinen weißen pixel oben in der linken ecke. danach reboot und diesmal aber nicht normaler systemstart sondern original recovery 3e gestartet. ADB aber immernoch fehlanzeige.

Interessant ist das dieser kleine weiße pixel auch beim original Recovery kurz vorher kommt bevor dann das Menü da ist.

EDIT
Ich habe es jetzt geschafft mir ein funktionierendes CWM zu basteln.
Allerdings leider nicht selbst gebaut. Aus irgendeinem Grund funktionieren die selbst gebauten nicht.
Was ich nun getan habe ist ein vorhandenes CWM vom Onda Vi30 zu nehmen und dieses aufzuspalten in Kernel und Ramdisk.
Dann habe ich in der Ramdisk die default.prop und recovery.fstab ersetzt und den Kernel hab ich auch mit meinem ersetzt.
Jetzt Ramdisk + Kernel wieder zusammengebaut. Aber als IMG-Datei nicht als uImage. Und habe es dann einfach uImage_recovery genannt.

TWRP hatte ich zwar auf die gleiche weise zum starten gebracht, jedoch wollte der TouchScreen dann iwie nicht.
Hat zum Teil von allein geklickt und zum Teil überhaupt nicht reagiert.