Problem beim Rooten mit MTK Droidtool...

[rzdz]

Dazu sagte ich: Mehr Platz in der Scatter reservieren ist ja nicht schlimm...

Das habe ich schon gemerkt, denn das Netz-Scatterfile funktioniert ja.

Jetzt geht es darum, Inkonsistenzen zu beseitigen (und hier sehe ich mindestens eine), was die Partitionsbeschreibung im Gerät angeht, die möglicherweise verhindert, daß ein funktionierendes Scatterfile erzeugt werden kann.

Auch wenn ich mich vielleicht wiederhole.
Ein Scatterfile im Format VOR 1.1enthielt lediglich Start Adresse und ob, oder ob nicht das File "gedownloadet" werden soll.

Ja, das wäre jetzt euch mein Ansatz gewesen für die nächsten Flashversuche, allein schon deswegen, um die Scatterfiles möglichte einfach editieren zu können.
Der viele "unnötige Quatsch" bei dem neuen Fileformat macht die Sache eher unhandlich und unübersichtlich.
PS: der "unnötige Quatsch" macht aber den Unterschied über "funktionieren" oder "nicht funktionieren"
--> Problem beim Rooten mit MTK Droidtool... | Seite 10

Und bei diesem MT6582 SoC funktionierte das reibungslos. Sogar die letzte aktuelle 3er Version des SP FT sollte damit bei Dir vollständig die Arbeit verrichten.

Das werde ich austesten, danke für den Hinweis auf die alte Version.

Andere Frage: Was bemängelst Du eigentlich an der Funktion des Telefons aktuell?

Hauptsächlich, daß man ohne Tricksereien wie manipulierte Scatterdateien kein funktionierendes Backup rücksichern kann, da der Hersteller wohl falsche Partitionsdaten abgelegt hat.

Dann, daß ich nicht sicher sein kann, daß mit solchen falschen Hersteller-Daten ein valides Nandriod Backup mittels Custom-Recovery erstellt und auch wiederhergestellt werden kann (da sind laut Berichten schon einige darauf reingefallen).

Und letztlich:
Bloatware in Masse, zu wenig Speicher, mir persönlich zuviele Google Apps, die ich nicht unbedingt brauche.
Ich möchte eine Light-Version mit separat zu installierenden (Google) Apps.
Cyanogenmod hat mir früher immer gut gefallen, leider nicht verfügbar für das Gerät.

Was ich noch gesehen habe, hat Alcatel die Sourcen auf der Webseite, deswegen hatte ich eigentlich auf verfügbare alternative oder verbesserte ROMs gehofft, das war aber offenbar ein Irrtum.

In Nachhinein gesehen war dieses Handy vielleicht nicht die geschickteste Auswahl, aber wer kann sich schon vorher so weit in allen Details schlau machen.
Aber aus Problemen dazulernen ist ja auch nicht unbedingt schlecht...

 

[N2k1]

Was ich noch gesehen habe, hat Alcatel die Sourcen auf der Webseite, deswegen hatte ich eigentlich auf verfügbare alternative oder verbesserte ROMs gehofft, das war aber offenbar ein Irrtum.

Tja, wenn man im ELEPHONE Forum liest, da denken auch immer alle user, wenn die Sourcen verfügbar wären, gäbe es auch viele verschiedene - voll funktionierende - ROM Versionen.

 

[rzdz]

Auch wenn ich mich vielleicht wiederhole.
Ein Scatterfile im Format VOR 1.1 enthielt lediglich Start Adresse und ob, oder ob nicht das File "gedownloadet" werden soll.
Und bei diesem MT6582 SoC funktionierte das reibungslos.

Also auch diese "Old-Style"-Scatterdatei läuft mit SP FT v5.1516 nicht durch (PMT changed...):

PRELOADER 0x0
{
}
MBR 0x1000000
{
}
EBR1 0x1080000
{
}
__NODL_PRO_INFO 0x1100000
{
}
__NODL_NVRAM 0x1400000
{
}
__NODL_PROTECT_F 0x1900000
{
}
__NODL_PROTECT_S 0x2300000
{
}
__NODL_SECCFG 0x2d00000
{
}
UBOOT 0x2d20000
{
}
BOOTIMG 0x2d80000
{
}
RECOVERY 0x3380000
{
}
SEC_RO 0x3980000
{
}
__NODL_MISC 0x3f80000
{
}
LOGO 0x4000000
{
}
EBR2 0x4300000
{
}
CUSTPACK 0x4380000
{
}
MOBILE_INFO 0x2a880000
{
}
__NODL_EXPDB 0x2b080000
{
}
ANDROID 0x2ba80000
{
}
CACHE 0x51f80000
{
}
USRDATA 0x65880000
{
}
__NODL_RSV_OTP 0xFFFF0200
{
}
__NODL_BMTPOOL 0xFFFF00A8
{
}

... auch wenn diese Datei den kritischen Eintrag gar nicht explizit enthält:

- partition_index: SYS20
partition_name: USRDATA
...
linear_start_addr: 0x65880000
physical_start_addr: 0x64880000
partition_size: 0x40000000 (geht) ----> 0x82C00000 (geht nicht)
region: EMMC_USER

Sowohl die funktionierende Scatterdatei 7041X als auch die eigene nicht funktionierende 7041D in "Old-Style" ergeben umgewandelt exakt die gleiche, oben gezeigte Datei, die nicht funktioniert.
Offenbar werden die zusätzlichen Einträge (z.B. partition_size) der aktuellen Scatterversion doch vom Flashtool beachtet!

Sogar die letzte aktuelle 3er Version des SP FT sollte damit bei Dir vollständig die Arbeit verrichten.

Das Old-Style-Scatter führt auch bei SPFT v3.x leider nur zu Fehlermeldungen:

SPFT v3.1316 (Download-Modus):


SPFT v3.1224, bereits bei der Scatter-Auswahl:

(Scatter heißt MT6582_Android_scatter_emmc.txt bzw. testweise MT6582_Android_scatter.txt)

Könnte die Verwendung eines älteren MTK Droidtools bei der Erzeugung der Scatterdatei etwas bringen (habe noch keine alte Version zum Download gefunden)?

 

[N2k1]

PMT changed heißt nur, daß EBR im Telefon und EBR bzw. Scatter des Flashs nicht zueinander passen.
Da die EBR ja stimmen, passt die Scatter nicht .. die wurde aber nach den Daten des EBR neu erstellt.
Also nun mit der vermeintlich falschen Scatterdatei einmal mit Firmware-Upgrade alles bereinigen .. danach sollte die zuvor funktionierende Scatter-Date den Fehler melden - dafür die neue Datei nun nicht mehr.

 

[rzdz]

Um jetzt keinen Fehler zu machen:
- welche der folgenden Partitionen muß ich per "Firmware Upgrade" flashen?
- mit v3.1316? (SPFT v5.1516 geht nicht, "PMT changed,... OK", keine Auswahl zum weiter flashen)

PRELOADER
MBR
EBR1
PRO_INFO
NVRAM
PROTECT_F
PROTECT_S
SECCFG
UBOOT
BOOTIMG
RECOVERY
SEC_RO
MISC
LOGO
EBR2
CUSTPACK
MOBILE_INFO
EXPDB
ANDROID
CACHE
USRDATA
OTP
BMTPOOL

 

[N2k1]

Alle, die in der Scatter normal zum Download stehen.
(Alle Haken müssen gesetzt sein)

 

[rzdz]

Also nun mit der vermeintlich falschen Scatterdatei einmal mit Firmware-Upgrade alles bereinigen .. danach sollte die zuvor funktionierende Scatter-Date den Fehler melden - dafür die neue Datei nun nicht mehr.

Habe nach Deiner Anweisung diese "nicht passende" "Old-Style"-Scatterdatei genommen:
Problem beim Rooten mit MTK Droidtool... | Seite 10
Nachdem der erste Versuch "mit NODL" nach dem Firmwareupgrade zwar durch lief, aber nicht zu einer geänderten Scatterdatei führte, habe ich alle "NODL" entfernt, damit alle Partitionen beim Download ausgewählt werden können.

2. Versuch:
Es wurden alle Partitionen kopiert, auch die, die im Scatter ursprünglich NODL waren (außer OTP und BMTPOOL, dafür sind ja keine Backup-Dateien vorhanden):



Es ergibt sich auch nach "Firmware upgrade" wieder die alte Blockmap + Scatter:




Vielleicht eine blöde Frage:
Formatiert werden muß vorher aber nicht explizit, oder?
(Falls ja: auch den Preloader formatieren?)

Ein Scatterfile im Format VOR 1.1 enthielt lediglich Start Adresse und ob, oder ob nicht das File "gedownloadet" werden soll. Und bei diesem MT6582 SoC funktionierte das reibungslos.
Sogar die letzte aktuelle 3er Version des SP FT sollte damit bei Dir vollständig die Arbeit verrichten.

Sieht für mich nicht ganz so problemlos aus (auch mit SP FT v3.1316):

... danach sollte die zuvor funktionierende Scatter-Date den Fehler melden - dafür die neue Datei nun nicht mehr.

Offenbar bleiben die alte Partitiondaten trotz "Firmware-Upgrade-Modus" irgendwo bestehen, wo sich MTK DT dann später die unveränderte "Blockinfo" her holt und daraus die (unveränderte) Scatterdatei erzeugt.

 

[N2k1]

Nicht die nodl-Optionen ändern!
Einfach per Firmware-Upgrade flashen und danach nochmal - ohne etwas zu ändern als "download" versuchen zu flashen.
Es wird ja effektiv nur die PMT geändert, die Du nicht auslesen kannst.
Es geht also nur um die Behebung dieses Fehlers, so daß danach einzelne Bereiche geflasht werden können.
Wichtig: EBR und Scatter müssen passen!

 

[rzdz]

Nicht die nodl-Optionen ändern!
Einfach per Firmware-Upgrade flashen und danach nochmal - ohne etwas zu ändern als "download" versuchen zu flashen.

Könnte sein, daß das eben funktioniert hat.
Habe die Stock Recovery durch Custom überflasht, ohne Fehlermeldung! (CustomRecovery startet auch)
D.h. die einzelnen Blöcke lassen sich so auch flashen (mit der fremden 7041X Scatter ging das aber auch schon vorher).

Habe mir eben mit MTK DT nochmal die Blockinfo angesehen:
unverändert (also nicht zum Flashen geeignet, brauche mir das eigene Scatterfile also auch nicht zum x-ten mal zu speichern).


Kann man diesen Fehler nicht dauerhaft beheben?

Also nun mit der vermeintlich falschen Scatterdatei einmal mit Firmware-Upgrade alles bereinigen .. danach sollte die zuvor funktionierende Scatter-Date den Fehler melden - dafür die neue Datei nun nicht mehr.

Meintest Du mit der "vermeintlich falschen Scatterdatei" meine eigene (nicht funktionierende) oder die funktionierende aus dem Netz (vom falschen Modell 7041X)? So gesehen sind sie beide irgendwie "falsch"...
Hatte oben bei den letzten beiden Flashversuchen die Scatterdatei im alten Format verwendet, die sind von beiden "falschen Scatter-Dateien" ja identisch, da sie nur Startdressen und Blocknamen enthalten.

 

[rzdz]

Neues Problem aufgetaucht, aber bereits gelöst (das alte noch nicht)!

Spoiler

Schlechte Neuigkeiten:
Jetzt funktioniert gar keine Scatterdatei mehr... (zeigt bei allen "PMT changed...")
Ein Blick auf die Blockinfo mit MTK DT zeigt keine Änderung.

Gemacht habe ich eigentlich nichts am Handy, außer ein paarmal hochgefahren, das MTK-DT-autoerzeugte CWM 5.5.04 geflasht, aber nicht verwendet (außer mal kurz ins Recovery gestartet). Und ein paar Stunden "sacken lassen..."

Das Handy startet noch normal, wird vom PC als "Telefonspeicher" erkannt, MTK DT zeigt die Details an, SP FT zeigt kurz den roten Balken beim Einstecken des ausgeschalteten Handys.

$ cat /proc/dumchar_info und $ cat /proc/emmc spucken die gleichen Listen aus wie vorher, allerdings ist bei
$ cat /proc/partitions die Liste jetzt um die letzen beiden (roten) reduziert:

cat /proc/partitions
major minor #blocks name

7 0 1254 loop0
253 0 393216 zram0
179 0 3789312 mmcblk0
179 1 1 mmcblk0p1
179 2 10240 mmcblk0p2
179 3 10240 mmcblk0p3
179 4 6144 mmcblk0p4
179 5 627712 mmcblk0p5
179 6 8192 mmcblk0p6
179 7 627712 mmcblk0p7
179 8 320512 mmcblk0p8
179 9 2142208 mmcblk0p9
179 64 2048 mmcblk0boot1
179 32 2048 mmcblk0boot0
179 96 7841792 mmcblk1
179 97 7837696 mmcblk1p1​

Wie bekomme ich das störrische Ding jetzt wieder flashbar?
Da ich in der Shell keine Rootreche mehr habe, kann ich wohl auch mit dd nicht die Stock Recovery zurück kopieren.
Rooten per Kingoroot muß jetzt nicht unbedingt nochmal sein (aber als letzten Ausweg...).
Mittels Alcatel OT Upgrade S den Serienzustand wiederherzustellen, war eben etwas störrisch (blieb eben ewig bei 0% Download stehen, um dann auf 100% zu springen).

OK, Alcatel OT Upgrade S war erfolgreich, Recovery läßt sich wieder flashen!

Vielleicht ist das kurzzeitige Problem von eben ein Hinweis darauf, daß es durch das Flashen im "Firmware Upgrade Modus" doch dauerhafte Änderungen im Handy gab, die eine neue Scatterdatei erfordert hätten, da alle vorhandenen Scatter plötzlich nicht mehr funktionierten.

 

[rzdz]

Abschließend einen herzlichen Dank an meine beiden Helfer N2k1 und Ora!
Auch wenn das Problem nicht ganz gelöst werden konnte, ist zumindest das Flashen mit der fremden Scatterdatei möglich, und mittlerweile erprobt.
Ob es ganz fehlerfrei funktioniert, werde ich wohl erst später sagen können (gehe aber davon aus).
Jetzt werde ich jedenfalls erst mal zwischen verschiedenen Stock-Android-Versionen hin und her springen, um mir die passenste Version auszusuchen, und dann etwas abzuspecken und zu verbessern, soweit ich das hinbekomme...

(PS: Das versprochene "How to" bekomme ich jetzt nicht mehr ganz gebacken, das ging zu sehr durcheinander.
Werde später nochmal einen Anlauf speziell für das C7 7041D angehen.)

 

[Audi-RS]

Stop!
Da ist etwas faul
type: YAFFS_IMG
Das sollte ext4 sein!



@N2k1 diesen Beitrag habe ich durchgelesen weil ich auch das gleiche Problem mit meinem Gerät habe. Es
handelt es sich um ein das Phone von HDC S6 EX , CPU MTK6582 , Android 5.0.2 mit einer Applikation von Samsung S6.
Habe versucht mit Droidtools u. Sp-Flash das Gerät zu rooten. ( vorher habe ich viele Root-Programme wie Kingroot, Kongroom, Kongoroot, Vroot, Iroot,etc.vergeblich versucht ! )
Bei Droidtools bekomme folgende Meldung:
ACHTUNG! Abfragen von Bestätigung sind auf dem Bildschirm des Gerätes möglich!
--- Fehler : SU unzugänglich
--- Durch CWM ist es möglich, Root auf diesem Telefon zu erhalten! Siehe folgende URLs : ...............

Das SP-Flashtool hat beim Erzeugen von backup keine Recovery.img Datei erstellt. Eine weitere Fehlermeldung bringt Droidtool : NO fand KernelGZ
und NO split Boot img
Mir ist auch aufgefallen, daß in der Scatterdatei für die usrdata keine ext4 format eingetragen ist.

Könntest Du mir Tipp geben wie ich die Fehler beseitigen und das Gerät rooten kann.

Danke im Voraus

[DOUBLEPOST=1443295276,1443294446][/DOUBLEPOST]@N2k1 bitte den obigen Artikel lesen

 

[DerToshy]

Nein!
Physikalischer Start ist ohne Offset - linearer Start mit.

Ich möchte mal kurz auf diese beiden Angaben zurück kommen. Bis auf einige Foreneinträge habe ich bisher weder beim Auslesen der Scatterdatei noch bei ROM-Vorlagen (auch Stock) jemals unterschiedliche Angaben bei den Werten gesehen beide Werte sind bei mir immer identisch. Okay, super viel ROMs habe ich mir noch nicht angeschaut, dennoch eigenartig. Warum "sollten und sind wohl manchmal" die Angaben unterschied und warum "manchmal" doch nicht und warum löst das (hoffentlich) keine Fehler aus.

Ich dachte ich habe beim repartitionieren bisher die notwendigen Dinge verstanden, allerdings zwei oder drei Verständnisprobleme habe ich noch (auf ab Android 5 interessant, da ich u.a. die Systempartion vergrößere).

Ich hatte bisher den Fehler gemacht, die Herstellerangaben der Größe nicht in 1000er-Schritten zu verwenden und hatte 1024... genommen.
Allerdings auch hier wundert mich etwas. Nutze ich als Größe des Speichers die "Prospektangaben" oder ähnliches und nehme nun die 10er-Potenzen (x1000x1000 usw.) um die Größe in Bytes zu erhalten und dann bei ändern natürlich die 1024-Berechnung zu nutzen stimmen die Werte fast überein mit einigen Scatterdateien aus Stockroms welche auch die FAT-Partitonsgröße angeben. Allerdings nur FAST.
Nehme ich die GB größe, rechne in Bytes um, ziehe den Preloader und den gesamten Bereich aus der Scatter (also bis Ende der FAT, falls mal angegeben), dann bleibt ein gewisser Bereich ungenutzt.
Mit dem BMTPOOL stimmt das allerdings nicht überein, wie diese Angaben zustande kommen habe ich noch nicht rausgefunden. BMTPOOL beginnt immer irgendwie von der SPeicheradresse innerhalb des FAT-Bereiches (aber nicht zu Anfang) und die Größe ist meißt so klein, daß er weiterhin im FAT-Bereich liegt. Das ist eigenartig. Es ist also nicht der freie Bereich am Ende. Ich vermute da schon seit einiger Zeit, daß die ROM-Herrsteller mit dem BTMPOOL selbst nichts anfangen können und diesen Wert vielleicht manchmal selbst falls anpassen. Dies ist allerdings aus Mangel an Erfahrung nur eine Vermutung. Ich bin da etwas frustriert beim erstellen meiner Partitionen. Zwar scheint alles zu funktionieren, allerdings sicher kann man sich da nie sein... Speicher / Schreibfehler / Abstürze bei vollem Flashsspeicher... man weiß ja nie sicher wo die Fehlerquelle liegt.

Daher versuche ich noch immer dies zu verstehen.