Das Gigaset QV1030 auf dem Weg zu Marshmallow

[Spartaner25]

Da ich im Moment nicht in der Lage bin, das Rom zu testen , wäre es nett, wenn mir jemand sagen könnte, ob die aktuelle CyanogenMOD Basis überhaupt noch bootet bevor ich irgendwelche Änderungen am Devictree etc. vornehme.
Daher wie gesagt, keine Garantie auf gar nichts, ich weiß nicht, ob das Rom überhaupt funktioniert. Es kann daher sein, dass ihr alle Daten verliert etc. .
Und es ist nur die aktuelle CM Basis mit dem Quellcode der auf Github verfügbar ist.
cm-13.0-20160921-UNOFFICIAL-fg6q.zip | by Spartaner25 for Generic Device/Other

 

[RavenFox]

Habe es mal geflasht, bleibt bei mir danach beim Schriftzug Gigaset stehen.

 

[Deepblue25]

Habe es mal geflasht, bleibt bei mir danach beim Schriftzug Gigaset stehen.

OK Oh, klingt nicht gut. Kann das noch wer bestätigen?

P.S.
Vielleicht wäre es ne Idee, dass wir alle als Nutznießer dieser ROM dem Spartaner über eine milde Gabe einen neuen Akku oder gar ein QV1030 beschaffen? Sonst wäre auch für uns alle hier so gut wie Sense... Nur Mal so als Idee in den Raum gestellt.

 

[Vinzent]

Soll durch diese neue Version der Akkubug behoben werden?

 

[Spartaner25]

Habe es mal geflasht, bleibt bei mir danach beim Schriftzug Gigaset stehen.

Nicht gut. Gibt es irgendwelche Meldungen? Kommt adb kurz online? last_kmsg beim nächsten boot in die Recovery unter /proc ?

Vielleicht wäre es ne Idee, dass wir alle als Nutznießer dieser ROM dem Spartaner über eine milde Gabe einen neuen Akku oder gar ein QV1030 beschaffen? Sonst wäre auch für uns alle hier so gut wie Sense... Nur Mal so als Idee in den Raum gestellt.

Danke für den Vorschlag, aber sollte Gigaset die Reparatur ablehnen, würde ich wohl probieren, den Akku durch ein Netzteil zu ersetzen. Irgendwie werde ich das Ding wohl wieder zum laufen kriegen.

Soll durch diese neue Version der Akkubug behoben werden?

Nicht direkt durch die, aber es besteht die Hoffnung, dass durch neue Binärdateien vom Nvidia Note ein solcher Bug behoben sein könnte, zumindest wird darüber im Nvidia Shield Forum berichtet.

 

[hellion]

Soll durch diese neue Version der Akkubug behoben werden?

Wenn damit der Bug gemeint ist, durch den das Tab im Standby heiß und der Akku leer wurde: den hatte ich nur unter CM 12.1; unter CM13 nicht mehr. Die kurzzeitigen WLAN-Unterbrechungen sind das einzige Problem, das mir aufgefallen ist...

 

[Deepblue25]

Ich hatte in letzter Zeit eher mit spontanen Reboots und gigantischen Lags zu kämpfen. Das kann aber an der recht miesen Temperatur-Abführung liegen.

 

[Welander]

würde ich wohl probieren, den Akku durch ein Netzteil zu ersetzen. Irgendwie werde ich das Ding wohl wieder zum laufen kriegen.

Als das normale Ladegerät bei zu geringer Akkuspannung durch die Ladesteuerung abgeschaltet wurde, hat bei mir ein direkt am Akku angeschlossenes Labornetzteil mit Ladestromkontrolle den Akku wieder hochgebracht.

 

[Deepblue25]

Seid aber vorsichtig damit. Mein Akku hatte das damals mit aufblähen quittiert.

 

[subdiff]

Im Zweifel mal ein anderes Netzteil probieren mit mehr Ampere. Bei meinem Smartphone funktionierte auch immer: Lange auf Power bleiben (geht natürlich trotzdem nicht an). Dann an Strom hängen (LED bleibt am Anfang noch aus) und nach ein paar Stunden/Tagen noch am Strom hängend anschalten.

 

[Spartaner25]

Die Gute Nachricht ist, ich hab den Wiederstand meines Tablets wohl gebrochen, und es geht jetzt wieder.
Auch wenn die Lade-LED immer nach kurzer Zeit ausging beim ranstecken, hatte der Akku wohl irgendwann durch dies Mikroladungen ein Niveau erreicht, was ihm erlaubte, einen Neustart ins Recoverysystem durchzustehen, wo er ganz regulär aufgeladen wurde. Am besten ist es wohl, sich keine Gedanken über die Logik zu machen.
Die schlechte Nachricht ist, ich habe keine Idee, warum die neuen Builds nicht starten wollen, da keinerlei Logs erzeugt werden. Falls Gigaset mir einen gefallen tuen wollte: Sagt mir, wo ich einen UART im Gerät finde, damit ich nicht immer Trial-and-Error spielen muss. (Sony hat damit immerhin kein Problem)
Edit: Da das vorherige Bootimage ein bisschen liberaler was, kam ich damit ein bisschen weiter beim booten und habe Logs bekommen. Und wie sich herausstellt war das ganze wohl ein Fehler in der OSI-Schicht 8, die es irgendwie geschafft hat, dass die Vendordateien nicht reinkopiert wurden. Ein UART hätte ich trotzdem gerne.
Edit2:Also, ein bootfähiges Rom habe ich mittlerweile wieder, alles läuft auch. Es gibt nur das Problem, dass der Homebutton zwar aufs Gedrückt werden reagiert, aber keine Aktion mehr ausführt und die Quicksettings der Benachrichtigungsleiste lassen sich nicht mehr rausfahren, auch nach mehreren Factory-Resets. Ich weiß nur nicht, wie ich das als Fehler hätte einbauen können, laut repo status ist mein Build Directory clean. Ist jemand sowas ähnliches bei früheren Roms passiert?

 

[subdiff]

Nein, mir nicht. Wenn du den Code auf Github hochlädst, versuch ich den neuen Build nochmal selbst zu kompilieren und auszutesten.

 

[Spartaner25]

Der Code ist auf Github. Ich habe mit dem alten Code gebaut, um nicht neue Fehler reinzupacken.
Device auf branch cm-13 in device/quanta/fg6q, kernel auf branch cm-13 in kernel/quanta/fg6q und vendor auf cm-13 in vendor/quanta/fg6q.
Bei Bedarf könnte ich auch eine etwas umfassendere Anleitung zum kompilieren erstellen.

 

[freibooter]

Bei Bedarf könnte ich auch eine etwas umfassendere Anleitung zum kompilieren erstellen.

Das halte ich für eine extrem gute Idee. Es wäre schade, wenn uns dein Erfahrungsschatz verloren gehen würde. Je mehr du die Einstiegsschwelle senkst, um so eher findet sich jemand, der die Arbeit ggf. fortsetzen kann.

 

[Spartaner25]

Ich hoffe es hat keiner was gegen ein Github Wiki, bei Bedarf könnte das ganze natürlich noch auf deutsch übersetzt werden und weitere Details hinzugefügt werden etc., aber im Grunde genommen ist das alles: Build-CyanogenMod-for-the-Quanta-FG6Q-Gigaset-QV1030

 

[freibooter]

Perfekt, vielen Dank. Alles was ich brauche.

Ich werd's bei Gelegenheit selbst mal probieren. Kannst du noch was zum Status der Binaries sagen?

 

[Spartaner25]

Da habe ich noch nicht weiter gemacht, weil mir im Moment diese Homebutton und Benachrichtigungsleisten Geschichte mehr Sorgen bereitet.
Im Grunde genommen gibt es zwei Optionen, ich probiere alle wichtigen Binaries von der Quelle in den bestehenden Vendor Ordner reinzukopieren. Oder ich nehme einfach den Vendor Ordner vom roth und benenne hier und da was um, was auch zukünftige Updates erleichtern würde und auch gar nicht so blöd wäre, da die meisten Geräte spezifischen Binärdateien sowieso in der Devicerepo sind.

 

[subdiff]

Ok, ich werd jetzt nochmal den Source komplett neuladen und mach's dann deiner Anleitung entsprechend. Was ist eigentlich mit der github-page passiert? Ich hätte hier noch einen (potentiell veralteten) clone derselben, falls du sie aus Versehen gelöscht und kein Backup hast.

 

[Spartaner25]

Löschen tue ich nichts, egal wie peinlich mir die Programmierfehler/Website ist, keine Sorge.
Die Seite ist hier: GitHub - fg6q/android_device_quanta_fg6q at gh-pages. Ich sehe gerade durch den Umzug habe ich die Seite gekillt, das war nicht die Absicht .
Das Blöde ist eben, dass die an die Devicerepo gebunden ist,unter fg6q/fg6q.github.io · GitHub bzw. der Adresse fg6q.github.io könnte ich eben eine komplett neue Seite zum Thema "fg6q" erstellen. Aber ich denke mal, ich werde erstmal das Wiki bei Github ein bisschen füllen.

 

[subdiff]

Jo, einfach das Device repo in das fg6q.github.io repo kopieren/pushen und alle branches bis auf gh-pages hier löschen (den dann noch in master umbenennen).
Ansonsten hab ich grad gemerkt, geht's aktuell auch hierüber: CyanogenMod for QV1030/Quanta FG6Q