Frage - Neues unsupported Device - Recovery und System aus Sourcen compilieren

[Astrali]

Hallöle liebe Community!

Ich habe mir vor kurzem ein Smartphone von einem recht unbekannten Hersteller zugelegt und bin -was die Hardware betrifft- auch super zufrieden.
Jedoch wechsele ich gern mal mein ROM und die auswahl ist auf deutschen/englischen Foren und webseiten sehr dürftig.

Mein Chinesisch ist eher schlecht

Nun würde ich mir gern ein CWM Recovery und evtl. ein CM selber compilen.

Der Build server steht, repo ist gesynced.

Jedoch gibt es für dieses gerät auf Github keine manifest.xml (ich konnte keine finden) und somit fehlt mir der komplette vendor tree und mein device tree dürfte auch eher unvollständig sein.

Habe bisher nur alles über das mkvendor.sh script aus der boot.img ausgelesen.


Meine Frage an euch:

Gibt es einen guide der -so richtig neue- Geräte die noch nicht überall quellen haben behandelt?

alles was ich gefunden habe heisst es immer "choose your device and ..."
geht bei mir nicht

aber irgendwie ist das device ja auch dort mal hin gekommen!

Also .. wie geht das?

Für die die es interessiert, es handelt sich um ein FAEA F1
Codename: msm8x25q_n451_f1

Würde mich freuen wenn mir jemand die erleuchtung bringen könnte

Grüssle - Astrali

 

[u.k-f]

Hallo

Allzuviel gibt es nicht, das Porten ist nämlich für jeden Device anders...

Gucke hier mal den Punkt 4 an:

https://www.android-hilfe.de/forum/...en-sourcen-aosp-cm-aokp-aospa-usw.443795.html

Grüße Uwe

 

[Astrali]

Hallo Uwe,

vielen Dank erstmal für deinen Link. Werde mir das alles in ruhe noch mal genau ansehen.

aber bei der stelle:

von ähnlichen Geräten, am besten mit ähnlicher Hardware und vom gleichen Hersteller)

wirds schon schwierig, da der hersteller bisher nur 2 Geräte auf dem Markt hat.
Das was ich hab ist die nummer 1. von der 2. Generation gibt es ebensowenig infos

aber bei dem versuch ein CWM zu compilen hab ich definitiv einen fehler gemacht, da ich bisher immer "lunch" genutzt habe, jedoch das CWM zu dem CM sourcen zählt.

Sollte ich mal mit brunch probieren

Den Device tree habe ich übrigens auch schon (nach dem was ich sehen kann) recht gut erarbeitet gehabt, aber aus versehen nochmal zerstört .. bekomme ich aber wieder hin.
Was mir gänzlich fehlt ist der Vendor tree und die proprietary blobs (laut google).

Sind das bestimmte dateien die ich aus dem original Rom (es gibt auch ein Update Rom als zip) entnehmen kann, oder ist das auch hersteller abhängig?


Du ahnst gar nicht wie sehr ich mich freue das überhaupt mal jemand auf meine frage antwortet

und wie gesagt .. die links von dir (punkt4) schaue ich mir ganz sicher noch genauer an!


Grüssle - Astrali

 

[perpe]

Wenn du ein boot.img hast, dann kommst du sicher auch an das img der original Recovery. Sie kannst du auf Recovery Builder hochladen und dir die CWM automatisch erstellen lassen. Neben der CWM kannst du dann auch dir artefacts runterladen, das sind die device Dateien, die du für einen eigenen build brauchst, wenn du nicht die automatisch erstellte nutzen möchtest oder weiter dich einarbeiten willst.
Da dein Gerät ein Qualcomm CPU hat, müsste die vom builder erstellte Recovery funktionieren.

 

[Astrali]

das ist im grunde eine gute idee, aber eine recovery.img gibt es in dem update zip leider nicht.

alle versuche das recovery vom system zu ziehen werden exact genau so groß wie das boot.img (etwas über 13MB).

Den versuch mit dem Builder habe ich bereits gestartet, dieser läuft auch "angeblich" erfolgreich durch, jedoch habe ich das img dann getestet mittels

fastboot boot recovery.img

dann kommt im fastboot kurz die nachricht "downloading boot"
"rebooting"

dann habe ich allerdings niemals etwas innvolleres als einen schwarzen bildschirm, oder einen bildschirm mit backlight an, jedoch ohne funktion erreicht.

Das wollte ich dann auch nicht unbedingt auf mein gerät flashen.
Oder startet so ein image anders vom gerät, als wenn es nur gebootet wird über fastboot?



Ich hab übrigens derzeit zur hand: ein funktionierendes 3e recovery mit dem ich ziemlich alles flashen kann (mag ich aber nicht).
und von einem anderen user ein fakeflash CWM (also .zip).
das bootet aber nicht direkt, sondern ich kann es über mein 3e recovery "flashen" udn benutzen.

das recovery.img was in einem backup erstellt wird ist ebenfalls wieder ca. 13,2 mb groß und gibt nichts brauchbares im builder.

Kann man anhand des funktionierenden fakeflash´s was bauen/auslesen?

Ich hab schon einiges verzweifelt versucht

Vielleicht hab ich auch noch irgendwo einen denkfehler ..
Ich befasse mich mit android erst seit ca einem halben Jahr, habe aber einigermaßen verständnis für das was in einem system passiert

Ich bin weiterhin für jeden tipp dankbar'!

ach ja ... ich hab mal die mounts ausgelesen .. vielleicht gibt das für erfahrenere nutzer mehr sinn als für mich ...

rootfs / rootfs rw,relatime 0 0tmpfs /dev tmpfs rw,nosuid,relatime,mode=755 0 0devpts /dev/pts devpts rw,relatime,mode=600 0 0proc /proc proc rw,relatime 0 0sysfs /sys sysfs rw,relatime 0 0none /acct cgroup rw,relatime,cpuacct 0 0tmpfs /mnt/asec tmpfs rw,relatime,mode=755,gid=1000 0 0tmpfs /mnt/obb tmpfs rw,relatime,mode=755,gid=1000 0 0debugfs /mnt/debugfs debugfs rw,relatime,gid=512 0 0none /dev/cpuctl cgroup rw,relatime,cpu 0 0/dev/block/platform/msm_sdcc.3/by-num/p17 /system ext4 rw,relatime,data=ordered 0 0/dev/block/platform/msm_sdcc.3/by-num/p18 /cache ext4 rw,relatime,data=ordered 0 0/dev/block/platform/msm_sdcc.3/by-num/p15 /persist ext4 rw,nosuid,nodev,relatime,data=ordered 0 0/dev/block/platform/msm_sdcc.3/by-num/p21 /data ext4 rw,relatime,nomblk_io_submit,noauto_da_alloc,errors=panic,data=ordered 0 0/dev/block/vold/179:33 /storage/sdcard0 vfat rw,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=continue 0 0/dev/block/vold/179:33 /mnt/secure/asec vfat rw,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1015,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=continue 0 0tmpfs /storage/sdcard0/.android_secure tmpfs ro,relatime,size=0k,mode=000 0 0/dev/block/vold/179:20 /storage/sdcard1 vfat rw,nosuid,nodev,noexec,noatime,nodiratime,uid=1000,gid=1023,fmask=0002,dmask=0002,allow_utime=0020,codepage=cp437,iocharset=iso8859-1,shortname=mixed,utf8,errors=continue 0 0/dev/block/dm-1 /mnt/asec/com.digidust.elokence.akinator.paid-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0/dev/block/dm-2 /mnt/asec/com.AffinityBlue.NodeBeat-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0/dev/block/dm-3 /mnt/asec/com.tweakker-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0/dev/block/dm-4 /mnt/asec/Scantech.Terminal-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0/dev/block/dm-5 /mnt/asec/com.RauteMusik.RadioPlayer-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0/dev/block/dm-6 /mnt/asec/com.eamobile.tetris_full_azn_row-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0/dev/block/dm-7 /mnt/asec/ru.org.amip.timezoneservice-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0/dev/block/dm-8 /mnt/asec/com.bigfishgames.andramzn.azadafirefull-1 ext4 ro,dirsync,nosuid,nodev,noatime 0 0/dev/block/dm-9 /mnt/asec/com.mixaimaging.deformerplus-2 ext4 ro,dirsync,nosuid,nodev,noatime 0 0

oder hier direkt zum einsehen:
https://www.dropbox.com/s/k6kh775g0zu7bpv/mounts.txt

Grüssle - Astrali

 

[finnq]

Um ein Recovery über fastboot zu flashen, musst du den folgenden Befehl nutzen:

fastboot flash recovery recovery.img

 

[Astrali]

ich wollte ja nicht direkt mein funktionierendes recovery durch ein eventuell nicht funktionierendes ersetzen, daher habe ich es erst mal probiert mittels booten des image file.

daher fastboot boot recovery.img

macht es einen unterschied!?

 

[finnq]

Sorry, war da komplett falsch. "fastboot boot" sollte natürlich auch gehen.

 

[Astrali]

gut!

ich dacht schon ich hatte einen bösen syntax fehler

 

[perpe]

Flashen sollte er im Moment noch gar nicht!
Ohne die original Recovery irgendwo in Sicherheit zu haben, sollte man nie eine Custom Recovery flashen.

@Astrali
Geh mal Schritte für Schritt vor
Entpacke das Image der Recovery, die du mit dd erstellt hast. Das sie genauso groß wie die boot.img ist, ist nicht untypisch. Oft haben Recovery und Boot Partition die selbe grösse.
Nach dem Entpacken schaust du dir mal die Dateien an um herauszufinden ob es ein Abbild der recovery oder der Boot Partition ist.
Wenn es die Recovery ist können wir weiter reden.

 

[Astrali]

ich schau mal was ich machen kann

worin sollte der unterschied liegen?
bisher sehen alle die ich entpackt habe gleich aus ..

base
cmdline
pagesize
ramdisk.gz
zImage (kernel denke ich)

 

[u.k-f]

Der Unterschied liegt im Inhalt der ramdisk.gz

Im cwm sind ganz andere files in der ramdisk.gz als im e3 recovery

Grüße Uwe

 

[perpe]

Bin wieder am Laptop und kann ausführlicher schreiben.

Du entpackst erst mal das original Recovery Image, welches du mit dd gemacht hast. Geh am besten nach der Anleitung auf HOWTO: Unpack, Edit, and Re-Pack Boot Images - Android Wiki vor.
Du musst also noch die ramdisk.gz auspacken. In der verlinkten Anleitung ist das erklärt.
Wenn die Datei /etc/recovery.fstab vorhanden ist, dann ist es auch ein Abbild der Recovery. Hebe eine Kopie des Images dann sicher irgendwo auf.
Falls die Datei nicht vorhanden ist, ist es auch kein Abbild der Recovery. Das ist dann schon mal schlecht. Versuch auf dem Gerät die Recovery Partition zu finden und erstelle eine Sicherung.

Edit. u.k-f war schneller, ihr macht das schon

 

[Astrali]

ihr seid spitze!

ich werd das aber wohl heut nicht mehr machen können.

Ich gehe mal davon aus das es euch auch morgen abend noch gibt

Tausend dank so weit!!!

 

[perpe]

Ich habe dir dann noch was zum Testen

Boote mal noch einmal die recovery vom recovery builder und schau, ob du über adb mit deinem Gerät dann kommunizieren kannst. Falls das funktioniert, dann brauchst du eine angepasste graphics.c. Dann hast du ein Problem, da der Adreno 203 mit WXGA/720p noch nicht weit verbreitet ist. Ältere Versionen haben eine andere Auflösung. Kannst aber trotzdem mal bei Geräten mit dem GPU schauen, was für eine graphics.c sie nutzen und sie mal mit auf den recovery builder laden.
Das dein Bildschirm an geht und sich dann nichts mehr tut und an bleibt, deutet etwas darauf. Wenn er danach nicht automatisch bootet ist es auch kein Kernel Panic.

Vergiss auch nicht die Artefakte vom Recovery Builder, sie kannst du nehmen um die Recovery selber zu kompilieren.

 

[Astrali]

also ich kann mein smartphone grad nicht anstecken, aber ich weiss sicher noch das ADB ging (bei mehreren versuchen), da ich mit adb reboot neu gestartet habe

das mit der anderen graphics.c ist ein prima plan!

werd morgen nachmittag auf arbeit in meiner pause mal auf die suche gehen ..
hab momentan zuhaus auch noch viel um die ohren und bastel immer in den lücken am smartphone

Vielen Dank für den wink mit dem ganzen Zaun! (adreno 203)

Artefakte sicher ich mir dann komplett

 

[perpe]

Wenn adb in der recovery ging, dann liegt es an der graphics.c
Bei den Artefakten vom builder ist der devices Ordner drin, da ist der Quellcode enthalten, um die recovery zu erstellen.

Schau mal auf http://en.m.wikipedia.org/wiki/Snapdragon_(system_on_chip). Dort sind alle Snapdragon SoCs aufgelistet, steht auch immer die GPU dran und ein paar Geräte, die damit laufen. Orientiere dich am Anfang daran, such dir die Geräte mit Adreno 203 raus und geh auf die Suche nach CM bzw CWM Quellcode für sie, evtl. findest du so eine graphics.c (wobei ich befürchtet, dass es dir nicht viel bringen wird)

 

[u.k-f]

Ich muss zugeben dass ich etwas verwirrt bin von der Aussage, 'anderes graphics.c'

Das graphics.c das ich aus den CM-Sourcen habe macht mir eigentlich einen recht universellen Eindruck, benötigt aber einen #define , der das Pixel-Format festlegt.

Insofern würde ich vorschlagen wollen, einfach diesen Bereich:

#if defined(RECOVERY_BGRA)
#define PIXEL_FORMAT GGL_PIXEL_FORMAT_BGRA_8888
#define PIXEL_SIZE   4
#elif defined(RECOVERY_RGBX)
#define PIXEL_FORMAT GGL_PIXEL_FORMAT_RGBX_8888
#define PIXEL_SIZE   4
#else
#define PIXEL_FORMAT GGL_PIXEL_FORMAT_RGB_565
#define PIXEL_SIZE   2
#endif

händisch anzupassen.

MfG Uwe

 

[perpe]

Es soll möglichst viele Geräte abdecken, macht es jedoch nicht immer. Probleme können an diversen Stellen auftreten. Je nach Gerät halt. Deswegen gibt es bei CM auch die Möglichkeit eine eigene graphics.c einzubinden.

Es kommt immer auf den GPU und den Kernel an, was der Hersteller geändert hat. Manche ändern etwas am Framebufferformat so dass die graphics.c nichts mehr damit anfangen kann. Hatte auch schon mal ein Gerät das fb0 und fb1 hatte, zum laufen hat es fb1 gebraucht in der graphics.c ist fb0 festgelegt. Kann also unterschiedliche Gründe haben. Was er machen kann, bevor er irgendetwas ändert, die logs von der Recovery auslesen. Mit ADB Zugriff muss das möglich sein, dann hätte er schon mal einen Anhaltspunkt. In die Logs der original Recovery schauen kann auch was bringen.
Gut wäre es natürlich auch, wenn er den Kernel Quellcode hat, dort kann er sehen wie der framebuffer aufgebaut ist. Je nach Kentnissen könnte er dann die graphics.c anpassen.

Zur Vorllständigkeit: es ist nicht irgendeine graphics.c gemeint sondern die in bootable/recovery/minui

 

[Astrali]

wie ich sehe ist die diskussion heiss im gange
hab grad noch mal frisch ein dd von den in frage kommenden partitionen gemacht.
lade das grad auf meine dropbox hoch, kanns dann später auf meinen root server ziehen, dort entpacken und mal schauen was drin ist

wenn jemand schauen will, das ganze landet nach komplettem upload hier:
https://www.dropbox.com/sh/aymuqbfhfxq2c5m/wmvZxMhxSY

melde mich dann noch mal was ich so gefunden habe

Grüssle - Astrali