abbrechen
Suchergebnisse werden angezeigt für 
Stattdessen suchen nach 
Meintest du 

LIFETAB S1034X Online Update #3 Version 2

103 ANTWORTEN 103
TheDoctor
Specialist
Nachricht 1 von 104
188.616 Aufrufe
Nachricht 1 von 104
188.616 Aufrufe

LIFETAB S1034X Online Update #3 Version 2

Hallo allerseits,
 
das verbesserte OTA #3 Version 2 ist nun verfügbar, ebenso ein aktualisiertes Recovery Package, das genau diesen Stand herstellt. Release Notes folgen weiter unten. Zum weiteren Prozedere:
  
  • Das neue OTA #3 Version 2 ist ausschließlich vom alten OTA #3 aus erreichbar.
  • Das neue OTA #3 Version 2 wird anfangs als Beta markiert sein (Häkchen setzen).
  • Wir nehmen das Lollipop Upgrade offline, bis wir ein stabilieres Release haben.

Wir freuen uns wie immer über Feedback. Danke für Eure Geduld!

 
Viele Grüße
Der Doktor
 
LIFETAB S1034X Update #3 Version 2
 
Dieses Update für Ihr MEDION LIFETAB S1034X enthält die folgenden Verbesserungen:
 
  • Die Stabilität der WIFI-Verbindung im Standby wurde deutlich verbessert.
  • Der Bootloader kann wieder über die entsprechende Tastenkombination aktiviert werden.
  • Die Batterieanzeige im ausgeschalteten Zustand funktioniert wieder.
  • Das Gerät liefert nun die korrekte Bildschirmgröße von 10.1 Zoll (an bestimmte Apps, z.B. MS Office).
Dies ist das letzte Update für Android 4.4.4 KitKat. Es bereitet Ihr Gerät auf Android 5.0 Lollipop vor.
 
ACHTUNG! Dieses Update für Ihr LIFETAB S1034X enthält ein neues BIOS. Dies ist ein grundlegender Teil der Gerätesoftware. Bitte stellen Sie sicher, dass der Netzadapter eingesteckt ist, während das Update ausgeführt wird. Das Update wird das Gerät mehrfach neu starten und darf nicht unterbrochen werden. Folgen Sie den Anweisungen auf dem Bildschirm. Wenn das Update Sie bittet, eine Taste zu drücken, nutzen Sie eine der Lautstärketasten.
 
103 ANTWORTEN 103
TheDoctor
Specialist
Nachricht 11 von 104
124.846 Aufrufe
Nachricht 11 von 104
124.846 Aufrufe


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?

daddle
Superuser
Nachricht 12 von 104
124.830 Aufrufe
Nachricht 12 von 104
124.830 Aufrufe

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! Verlegener Smiley

 

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
Specialist
Nachricht 13 von 104
124.819 Aufrufe
Nachricht 13 von 104
124.819 Aufrufe


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

 

McB
Superuser
Superuser
Nachricht 14 von 104
124.809 Aufrufe
Nachricht 14 von 104
124.809 Aufrufe

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.

TheDoctor
Specialist
Nachricht 15 von 104
124.763 Aufrufe
Nachricht 15 von 104
124.763 Aufrufe

Recovery Package mit repariertem Windows-Script ist oben, zu erkennen an der Versionsnummer 2.1.

McB
Superuser
Superuser
Nachricht 16 von 104
124.741 Aufrufe
Nachricht 16 von 104
124.741 Aufrufe

@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

KlausX
Superuser
Nachricht 17 von 104
124.696 Aufrufe
Nachricht 17 von 104
124.696 Aufrufe

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

daddle
Superuser
Nachricht 18 von 104
124.662 Aufrufe
Nachricht 18 von 104
124.662 Aufrufe


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

 


@TheDoctor 

 

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! Lachender Smiley

 

Grüsse, daddle

 

 

@McB

 

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

McB
Superuser
Superuser
Nachricht 19 von 104
124.648 Aufrufe
Nachricht 19 von 104
124.648 Aufrufe

@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 😉

daddle
Superuser
Nachricht 20 von 104
124.619 Aufrufe
Nachricht 20 von 104
124.619 Aufrufe

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.  Lachender Smiley

 

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! Frustrierte Smiley

103 ANTWORTEN 103