(de) ▼ 
Click here to read this page in English
Cliquez ici pour lire cette page en français
Klik hier om deze pagina in het Nederlands te lezen41825leden
533online
146685berichten
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
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
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! 
