Lenovo Tab 2 A10-70F Linksammlung (Firmware, Recovery, Root)

Danke, aber ich muss jetzt erstmal ein neues Thema zu dem Gerät aufmachen, weil meines spinnt total rum. Es ist mir trotz zig versuchen seit Stunden nicht möglich mein Google Konto einzurichten. Das wäre aber hier OT. Wenn das Problem gelöst ist melde ich mich wieder.

So, Problem gelöst: Google Konto Einrichtung nicht möglich

Hab mir den Startbeitrag nochmal durchgelesen. Die aktuelle Lenovo Software ist installiert. Da ich nicht rooten möchte lasse ich es dabei. Danke für deine Hilfe!

Erst mal vielen Dank an @Tzul und die anderen für das umfangreiche und verständliche Tutorial. Ich möchte auch etwas dazu beitragen und nachfolgend meine Erfahrungen (und ganz am Ende neue Erkenntnisse) schildern.

Ich arbeite hauptsächlich mit Linux - und wenn Windows unbedingt nötig (u.a. mein Scanner) mit Virtualbox. Ich hatte mit SPFT leider keinen Erfolg. Nach vielen vergeblichen Versuchen Sicherungen mit Readback anzulegen (mit Linux und Windows sehr oft versucht, es kam immer nur zu kurzem Verbindungsaufbau, roter Balken mit Text "100% AD", dann nur noch weiterlaufende Zeit) haben mich viele (Fehl-)Versuche und weitere Recherchen zu "fastboot" und "adb" in Verbindung mit "TWRP" geführt (hatte leider diesen schon sehr langen Threat nur bis Seite 3 gelesen!).

Von Linux aus mit fastboot das Tablet entsperrt (dafür Tablet in "fastboot"-Modus gebootet), dann das Recovery-Image von TWRP mit "fastboot" geflasht. Danach unbedingt neu einmalig in den Recovery-Modus neu booten, sonst wird das alte Recovery wieder hergestellt!
Die Versuche System oder Userdata zu flashen schlugen wegen mir bis dahin unbekannter Größenbeschränkungen fehl!?!
Deshalb habe ich dann vom PC aus mit "adb" auf dem Gerät bzw. der darin befindlichen externen SD-Karte notwendige Verzeichnisse angelegt und die Imagedateien für Lollipop 5.0.1 aus deinem aktuellstem SPFT-Archiv (151222) rüber kopiert (irgendwie wollte ich die Karte nicht raus nehmen>:-o). Dann konnte ich mit Hilfe des im Recovery-Modus verfügbaren TWRP meine unbedingt gewünschten Sicherungen anlegen und danach auch alle relevanten Partitionen flashen.

Aufgrund dieses Tutorials wusste ich von Problemen mit WLAN-Zugriff auf das 5GHz-Band, worauf ich vorher nicht geachtet hatte. Direkt nach dem Flashen hat es funktioniert. Nach dem Installieren vieler Apps und Updates bemerkte ich, dass es wieder weg war. Zuerst vermutete ich, aufgrund einer entsprechenden Äußerung in einem Forum, dass nachinstallierte Apps dafür verantwortlich sind und setzte mit Hilfe der Standardfunktion das System in "Auslieferungszustand" zurück - was zu meiner Beruhigung sauber geklappt hat (hierbei wurden die neu aufgespielten Partitionen als Basis genommen). Dann installierte ich nach und nach die von mir gewünschten Apps und startete zwischendurch immer wieder das System neu, um zu sehen ob immer noch das 5GHz Band gefunden wird.
Irgendwann nach ZArchiver war es dann soweit und das 5GHz Band wurde nicht gefunden. Bevor ich deinstallierte habe ich erst mal probiert ob evtl. die Einstellungen in SuperSU damit zu tun haben könnten und habe dort geändert. Plötzlich wurde das Band nach Neustart wieder gefunden.
Nach dem nächsten Neustart war es wieder weg! :-((
Durch weiteres Probieren stellte ich dann fest, dass jetzt nach Neustarts das 5GHz-Band immer nicht erkannt wird aber nach aus- und einschalten des WLANs gefunden wird. Kann jemand aus dem Forum meine Beobachtung bestätigen?

Daraus ergeben sich die folgenden Fragen:
Womit kann das zusammenhängen? Und wie könnte es behoben werden?

@newbietux Welche Version des SPFT hast du benutzt? Ein paar ältere funktionieren wohl nicht richtig. Du hast es sowohl in Windows als auch in Linux probiert?
"100% DA" bedeutet, dass das SPFT den Download Agent zum Tablet geschickt hat. Entweder es war ein falscher DA, oder er ist nicht richtig angekommen.

Fastboot kann auf diesem Tablet maximal 128 MB übertragen (siehe "fastboot getvar max-download-size" oder "fastboot getvar all"), ein Flashen der großen Partitionen System und Userdata kann man damit also vergessen.

Wegen 5 GHz WLAN, schau dir mal dein NVRAM an, genauer gesagt /data/nvram/APCFG/APRDEB/WIFI. Diese Datei muss an den Offsets 0x100 und 0x106 jeweils ein Byte mit dem Wert 01 haben (siehe Seite 2).

@Tzul Ich habe SPFT v5.1604 (Windows; kann ich aber nur mit "virtualbox" betreiben) und v5.1552 (Linux) verwendet.
Die geschilderten Probleme traten beim Readback auf. Da ich auf diese Weise keine Sicherung erstellen konnte habe ich auch kein Download (flashen) durchgeführt.

Mein Vorgehen mit fastboot, adb und TWRP habe ich geschildert um anderen Usern zu zeigen, dass man mit genügend Hartnäckigkeit, viel Lesen und Probieren auch auf "verschlungenen Pfaden" zumZiel gelangen kann.

Ich habe meine WIFI-Datei an den benannten Offsets von 00 zu 01 geändert und im Verzeichnis

Tzul schrieb:

/data/nvram/APCFG/APRDEB/WIFI

Zum Vergrößern anklicken....

ausgetauscht. Jetzt kommt aber nach dem Neustart unter Einstellungen / WLAN immer ein Eintrag mit

NVRAM WARNING: Error = 0x01

Zum Vergrößern anklicken....

Leider ist der Fehler auch jetzt noch - nach zurück kopieren der Originaldatei - da!!!???

Auch jetzt nach wiederherstellen des kompletten Verzeichnisses "nvram"!!!

Warum aber funktionierte das 5 GHz WLAN nach dem Flashen und (bis heute vor meinem "Anpassungen" an der WIFI-Datei) nachdem man WLAN de- und wieder aktiviert hat?

@newbietux Vielleicht hilft das hier für die Linux-Version des SPFT.

Wenn man Änderungen an der WIFI-Datei vornimmt, muss man auch die letzten beiden Bytes löschen (die Prüfsumme: 0xAA 0x??; die Datei ist danach 512 Bytes groß), sonst werden die Änderungen wieder überschrieben.
Diese NVRAM-Fehlermeldung kommt eigentlich nur, wenn die Dateien nicht existieren. Hast du eventuell Besizter/Gruppe/Zugriffsrechte geändert?
Wenn du das /data/nvram/ Verzeichnis komplett löschst, dann sollte es beim nächsten Booten wieder komplett aus der NVRAM-Partition hergestellt werden. Vorausgesetzt natürlich die NVRAM-Partition enthält gültige Daten.

@Tzul Danke für die Tipps.
Die Regel in /etc/udev/ruled.d/51-android.rules hatte ich gesetzt.

Ich hatte gestern auch die letzten beiden Bytes auf 00 gesetzt und das Problem war nach dem Neustart immer noch so.
Außerdem hatte ich mit dem TWRP im Recoverymode die gesicherten nvram-daten wieder hergestellt. Danach immer noch das gleiche Problem.
Vor einer reichlichen Woche hatte ich schon einmal eine sehr ähnliche Lage, nachdem ich die von Dir bereitgestellte WIFI-Datei in mein nvram-Verzeichnis übernommen hatte. Damals half dann das Zurücksetzen in den Werkszustand - das wollte ich mir diesmal aber sparen.

Ich schaue mir noch einmal die Berechtigungen an - aber dann bin ich erst mal mit meinen Ideen am Ende.

Es ist für mich aber trotzdem unlogisch bzw. schwer verständlich, dass nach dem Zurücksetzen und mit der originalen WIFI-Datei - mit 00 an den Offsets 0x100 und 0x106 - das 5 GHz gefunden und verwendet wird ... bis dann nach einigen Updates und App-Installationen das 5 GHz-Band erst nach de- und wieder-aktivieren des WLANs funktioniert.
[doublepost=1459367054,1459365471][/doublepost]Jetzt nachdem ich das nvram-Verzeichnis gelöscht und neu gestartet hatte war die o. g. Fehlermeldung weg. Also mache ich jetzt mal lieber von [BOLD]diesem[/BOLD] Zustand des nvram-Verzeichnisses - und dem Rest des Tablets - eine aktuelle Sicherung.

Nach de- und reaktivieren des WLANs war auch das 5 GHz wieder verfügbar!?

Danke erst mal @Tzul. Ich lasse das Thema WLAN jetzt erst mal in Ruhe - solange es so weit funktioniert.

newbietux schrieb:

Ich hatte gestern auch die letzten beiden Bytes auf 00 gesetzt und das Problem war nach dem Neustart immer noch so.

Zum Vergrößern anklicken....

Das bringt nichts. Man muss diese Bytes wie gesagt löschen. Die Datei WIFI ist mit Prüfsumme 514 Bytes groß. Wenn man sie ändert, muss man die Prüfsumme entweder korrigieren (geht nur, wenn man den Algorithmus zur Berechnung kennt), oder eben abschneiden, so dass die Datei nur noch 512 Bytes groß ist. Der MediaTek NVRAM Daemon ersetzt nämlich Dateien mit falscher Prüfsumme wieder durch die Originale, aber Dateien mit fehlender Prüfsumme behält und ergänzt er lustigerweise.

Es funktioniert jetzt wieder alles? Gut.

Ich wollte mal ein kurzes Status abgeben, Updates per OTA lassen sich NICHT installieren, wenn weitere Änderungen am System vorgenommen wurden.

Selbst wenn:

• [root]
• Recovery

wiederhergestellt/entfernt wurden.

Das heißt:

• xposed
• Busybox
• Link2SD
• AdBlock
• usw ...

müssen ebenfalls verschwinden.

Das kommt ja einem System-Wipe gleich , von daher werde ich es bei "großen Updates" weiter probieren.

Danke für die Anleitung und die Links.

Ich bin den schnellsten Weg gegangen um root zu erhalten. Über fastboot brauchte ich weder das tool noch irgend einen treiber installieren.

Wie bekomme ich die original FW wieder auf mein Tab L.

Per SPFT Tool,mit der SPFT Datei das ist klar,aber wie oder was muß man dort einstellen?

Muß hier auch root, Twrp vorher und ähnliches entfernt werden?

Das Tab sollte wieder dank der Datei,ja wieder vom Urschleim starten.

@Falsche Uhrzeit Ja, per SPFT. Was du einstellen musst, ist im ersten Beitrag beschrieben, und es gibt dort auch eine Kurzanleitung in Bildern.
Root usw. musst du vorher normalerweise nicht entfernen. Denn wenn du die System-Partition mit der originalen überschreibst, verlierst du Root sowieso. Dasselbe gilt für das Recovery.

Ja Danke dir,

der Donwnload des SPFT ROM's hat ja ewig gedauert.
Nach dem entpacken, sieht man das es einzelne System Partitionen sind, die über das Tool geflasht werden können.

Dachte es wäre eine *.img oder *.bin Datei.

Hallo Miteinander,

Ich habe jetzt mal ein Full Backup der S000117_160226 vom Tab 2 A10-70L über SPFT gemacht, und alles gesichert, was die Scatter hergab.

Nun habe ich allen Partitionen einen richtigen Namen gegeben (21 Stück gesamt).

Da aber beim ReadBack immer nur ROM1, ROM2, ROM3 ... angegeben wird, habe ich jetzt Propleme die Datei-endungen der Partitionen zu bestimmen.

Z.b. bekommt das Recovery.img zugewiesen, aber das nvram.bin .

Ein paar Endungen konnte ich mir "abgucken", aber leider nicht alle.

Hat jemand eine Idee?

@Falsche Uhrzeit Die Dateiendungen sind egal. Du könntest einfach ".bin" für den Rest nehmen.
Wenn du in die Scatterdatei schaust, findest du die Dateinamen ("file_name") aller Partitionen, die als downloadbar markiert sind. Protect1&2 gehören z.B. nicht dazu. Du kannst sie protect1.img und protect2.img nennen, da es ext4-Partitionen sind, aber das ist wie gesagt egal und sowieso nicht konsistent (boot und recovery haben auch ".img" als Endung, sind aber keine ext4- oder sonstige Dateisysteme).

Die Dateien tee1 und tee2 müssten identisch sein (kann man z.B. per Eingabeaufforderung mit dem Befehl "fc /b tee1 tee2" testen). Also kannst du eine davon löschen und die andere wie in der Scatterdatei angegeben "trustzone.bin" nennen.
Der Preloader hat wahrscheinlich auch einen längeren Namen (mit Projekt-ID), und das Readback des Preloaders muss sowieso etwas nachbearbeitet werden, bevor man es wieder flashen kann.

hi,
leider bekomme ich beim flashen mit SPFT immer folgende Meldung



was läuft hier falsch?

gruss
nexus-freak

@nexus-freak Sicher, dass die Scatterdatei, die du verwendest, zum Gerät passt?
Der Meldung nach stimmt der Chip-Typ nicht überein.

hi,

peinlich peinlich, genau da liegt der Fehler. Les schon sein Tagen im falschen Thread. Habe das A7-10 Tablet und nicht das A10-70

sorry

aber danke für den Hinweis

gruss
nexus-freak

Eine Frage zur Sicherung über TWRP.
Sollte man hier alle Bereiche sichern oder nur bestimmte?

@spass Sichern kann man alles, wenn der Speicherplatz auf dem Sicherungsmedium nicht knapp ist.
Ich würde mindestens Proinfo und Nvram sichern, da dort Daten enthalten sind, die du nicht von anderen Tablets gleichen Modells bekommen kannst. Das gilt natürlich auch für die Benutzerdaten / Telefonspeicher (userdata).
Ansonsten sind das Boot Image und die Android Systempartitionen am wichtigsten.