am 09.09.2015 15:13
am 09.09.2015 15:13
Wir freuen uns wie immer über Feedback. Danke für Eure Geduld!
am 10.09.2015 10:14
am 10.09.2015 10:14
daddle schrieb:
Hallo!
Doch, erst kommt Ota #3, danach kommt Ota #3R2!
Bin gestern abend nochmal mit einem Clean Flash von Lollipop zurück auf Stand Ota #2,.
Dann kommt zuerst Ota #3, danach Ota #3R2.
Ota #3R2 ist auch mit ca 10MB nur halb so gross wie Ota #3 mit ~24MB!
Und die Images in Ota #3R2 (esp.img und capsule.bin) und im RecoveryPackage V2 sind nach Grösse und Inhalt dentisch.
daddle
Die spannende Frage ist: Wie stabil ist Dein WLAN jetzt?
10.09.2015 10:28 - bearbeitet 10.09.2015 21:10
10.09.2015 10:28 - bearbeitet 10.09.2015 21:10
Hi, guten Morgen!
Ist noch zu kurz zum beurteilen.
Die Flash-Orgien kosten immer viel Zeit, besonders da ich von jedem Zwischenschritt jeweils ein CWM-Backup mache, alles bisher ohne Root, versteht sich!
Besonders das letzte CWM-Backup nach zig App-Updates hat Stunden gedauert, so dass ich darüber eingeschlafen bin, und ich erst ab heute morgen rebooten und das WakeUp-Verhalten testen kann. (Kein Wunder dass es so lange dauerte, hat 3x hintereinander das Backup gezogen???)
Habe daher nur kurze Sleep -Phasen von nicht mehr als einer viertel Stunde! Da funktioniert es bisher insoweit dass Wlan nach WakeUp immer sofort aktiv war. Push-Verhalten im StandBy habe ich noch nicht testen können. Sobald ich sicherere Erkenntnisse habe melde ich mich wieder.
Eine Frage noch, warum funktionierte in der flash.bat das "fastboot.exe erase capsule " nicht, wenn es doch in der flash.sh so von Euch angegeben (benutzt) war? Oder kann das nur die fastboot Linux-Version?
Hatte ich genau wie in der flash.sh zwischen oem partition und oem stop partitioning nach erase factory eingefügt..
Grüsse, daddle
am 10.09.2015 10:36
am 10.09.2015 10:36
daddle schrieb:
Eine Frage noch, warum funktionierte in der flash.bat das "fastboot.exe erase capsule " nicht, wenn es doch in der flash.sh so von Euch angegeben (benutzt) war? Oder kann das nur die fastboot Linux-Version?
Grüsse, daddle
Nein, geht auch unter Linux nicht. Erklärung, vermutlich (müsste Intel uns beantworten): Wird zwar geflasht wie eine Flash-Partition, geht aber tatsächlich nicht ins Flash, sondern ins EEPROM des BIOS. Ist also eine Besonderheit des Intel-Systems. Wir haben das BIOS erstmalig für Euer Recovery Package in unser normales Flash-Script aufgenommen, die Fehlermeldung aber offenbar ignoriert, weil das eigentliche Flashen des BIOS ja geklappt hat.
Grüße
Der Doktor
10.09.2015 10:51 - bearbeitet 10.09.2015 10:53
10.09.2015 10:51 - bearbeitet 10.09.2015 10:53
es sind wohl zwei baustellen 😉
in dem chip für das bios steht ausschliesslich das bios drin.
mit festem einsprung und nach file_ende eben ein eof.
selbst wenn ein neues bios kleiner wäre macht der müll danach also nix aus.
beim flash-speicher macht ein erase und neupartionieren sinn um ggf. partitionen anzupassen
und um daten(alt)müll zu vermeiden.
am 10.09.2015 12:21
am 10.09.2015 12:21
Recovery Package mit repariertem Windows-Script ist oben, zu erkennen an der Versionsnummer 2.1.
10.09.2015 12:45 - bearbeitet 10.09.2015 12:57
10.09.2015 12:45 - bearbeitet 10.09.2015 12:57
@TheDoctor schigg 🙂
wenn ihr euch nun noch sicher seit dat' die flash.xml überflüssig war und von nix ausgelesen und gebraucht wird...
immerhin stand in der flash.bat des Recovery4.4.4 -> fastboot.exe -S 200M flash system system.img
die weder in V2 oder in V2.1 steht - jedoch in der früheren .xml
Edit1: wobei die partition.tbl bei allen dreien gleich ist
am 10.09.2015 13:26
am 10.09.2015 13:26
Hallo daddle,
daddle schrieb:Hallo!
Doch, erst kommt Ota #3, danach kommt Ota #3R2!
Bin gestern abend nochmal mit einem Clean Flash von Lollipop zurück auf Stand Ota #2,.
Dann wird zuerst das Update Ota #3, danach Ota #3R2 zum Download angeboten.
Danke für diese INFO.
Gruß
Klaus
10.09.2015 14:40 - bearbeitet 10.09.2015 19:06
10.09.2015 14:40 - bearbeitet 10.09.2015 19:06
TheDoctor schrieb:Nein, geht auch unter Linux nicht. Erklärung, vermutlich (müsste Intel uns beantworten): Wird zwar geflasht wie eine Flash-Partition, geht aber tatsächlich nicht ins Flash, sondern ins EEPROM des BIOS. Ist also eine Besonderheit des Intel-Systems. Wir haben das BIOS erstmalig für Euer Recovery Package in unser normales Flash-Script aufgenommen, die Fehlermeldung aber offenbar ignoriert, weil das eigentliche Flashen des BIOS ja geklappt hat.
Grüße
Der Doktor
Danke für die Erklärung. Es könnte auch noch einen weiteren Grund geben; liest man während des Bios-flash die kleinen Mitteilungszeilen, steht da dass Anteile des alten Bios in mehreren Schritten zwischengespeichert werden, damit der nächste Flash-Abschnitt weitergehen könne. Würde es vorher erased, würde das Update vermutlich stoppen. Dazu die Zeile aus dem Biosflash-Verlauf zu Anfang:
> "Backed up Bios Image for seamless recovery" ,
und noch andere Zwischen-Backups im weiteren Verlauf
Danach erased das capsule.bin oder im Bios eingebaute Routinen diese Abschnitte selbstständig. (Meldung: xxx destroyed)
2. Frage: Beim Rückflash auf Ota #2 mit der älteren passenden capsule.bin verhält sich der Flash-Vorgang anders als beim Flashen auf eine höhere Version; vor allem zum Schluss wenn die SEC-Firmware geflasht werden soll, sagt es
All Bios ingredients updated - continue with SEC firmware update...
NewVersion 1.1.0. 1013 (zu flashende) OldVersion 1.1.0. 1030 (vorhandene)
und dann laufen jede Menge immer gleichlautende Zeilen durch:
. Fw Update in progress - Percentage 20%, Stage: 6/17, Last Update Status 572,
.
. gefühlt ca. 100 Male,
und zum Schluss 'Updating ESRT table', und 'press any key to ...`'
Flashe ich dann das neuere Bios mit dem RecoverPaket V2 (oder auch nur die neuere capsule.bin, sicherheitshalber im Verbund mit esp.- u. droidboot.-img ), sieht man das die SEC-Firmware den neueren Stand 1.1.0.1030 beibehalten hat, und jetzt, da gleicher SEC-FW-Stand, nicht neu geflasht wird.
Das bedeutet die SEC-Firmware wird nicht auf 1.1.0.1013 zurück geflasht, es bleibt immer SEC-firmware Version 1.1.0.1030 drauf!
3.Frage: Was bewirken die Parameter "-S 200M"? Diese wurden ja bei Paket V1 in der Linux flash.sh nicht benutzt, wohl in der flash.bat, und im neuen Paket V2 weder in der flash.sh noch in der flash..bat benutzt?
Bitte beantworte mir Unwissendem diese Fragen, kurz und knapp genügt mir!
Grüsse, daddle
Die flash.xml hat mir auf jeden Fall geholfen den Flashvorgang zu verstehen, besonders da das Bios sonst in den OTA-Updates "capsule.bin", im Recover-Paket V1 aber BIOSUPDATE.fv heisst, im Paket V2 wieder capsule.bin. Folgender Auschnitt aus der xml erklärt wieso:
</code_group>
<code_group name="capsule">
<file TYPE="capsule">
<name>BIOSUPDATE.fv</name>
<version>eng.bios</version>
</file>
die file TYPE "capsule" hat also den <name> BIOSUPDATE.fv, eine Art Platzhalter-Funktion.
und in der >command> Anweisung steht:
<command> <string>fastboot flash capsule $capsule_file</string> <timeout>1800000</timeout> <retry>2</retry> <description>Flashing 'capsule' image.</description> <mandatory>1</mandatory> </command> In der Zeile <command string> fastboot flash capsule... wird dann für "$capsule_file"
aus der <code_group> für file TYPE"capsule" der angegebene <"name"> <BIOSUPDATE.fv>
genommen.
Im Recover-Paket V2 ist wieder eine abgeänderte xml, in der dieser Umweg über das
Namen-Wechsel-Dich-Spiel nicht mehr nötig ist.
Ich glaube die xml braucht man hier sowieso nicht, da ja in der flash.bat die Zeile: "fastboot.exe flash capsule BIOSUPDATE.fv" genau diese Anweisung, die BIOSUPDATE.fv in den Bereich "capsule" zu flashen, direkt an fastboot gibt!,
Schema: fastboot.exe flash <Bereich od.Partitionsname> <Name des zu flashenden Image od. zu flashender Bin-Datei>
Grüsse, daddle
10.09.2015 15:01 - bearbeitet 10.09.2015 16:03
10.09.2015 15:01 - bearbeitet 10.09.2015 16:03
@daddle normal ist eine .xml ja zum verstehen da 😉
(google liest ja auch auf einer homepage die sitemap.xml (sofern vorhanden) aus - 'benuzt' diese aber auch)
deswegen fragte ich mich ob die nicht auch beim flashen hinzugezogen wird/werden kann.
hast zwar nen kleinen paste_fehler gemacht - abba oki (stört hier jedoch eh nicht) 😉
ansonsten hast du mit dem was diesbezüglich schreibst wohl recht.
grüssinx
Edit1: ich hatte ja im post #16 festgestellt das die fehlt 😉
10.09.2015 15:33 - bearbeitet 10.09.2015 15:54
10.09.2015 15:33 - bearbeitet 10.09.2015 15:54
War kein copy&paste Fehler soweit ich erkennen kann. Habe aber den Satzbau extra für dich nochmal umgestellt, damit auch jeder den Satzinhalt verstehen kann.
Aber wenn jeder eine xml lesen kann, dann hättest du doch nicht danach gefragt?
Wie gesagt die fastboot-Befehls-Syntax in der flash.bat macht das m.E. im Recover-Paket.
Ich glaube die xml kommt nur zum Zuge wenn man das über einen Installer macht; jener der auf der Droidboot-Maske u.a mit nachfolgender Meldung immer für Irritationen sorgt:
"E: No valid installer medium found"
Aber genug OT, sonst wird hier nur noch mehr "gespammt". grüsse, daddle
Edit: Im neuen Paket V2.1 wurde die flash.xml weggelassen. Das beantwortet doch deine Frage!
Allerdings ist die installer.cmd verblieben, braucht man doch auch nicht soweit ich das überblicke! Aber ich bin kurzsichtig!