Problem beim Rooten mit MTK Droidtool...

[rzdz]

..........| meine original Scatterdatei .| Scatterdatei Netz
----------|------------------------------|----------------------------------------
EBRs Orig.| nicht flashbar "PMT changed" | flashbar,"Telefonspeicher" 2GB/1,7 frei
----------|------------------------------|----------------------------------------
EBRs Ora. | nicht flashbar "PMT changed" | flashbar,"Telefonspeicher" 0,7GB/0,5 frei
----------|------------------------------|----------------------------------------

Nur dieses Ergebnis interessiert mich!

Mir schon klar.
Aber ich möchte, daß Du auch siehst, daß ich alle Kombinationmöglichkeiten durchgetestet habe. Und das nicht nur einmal.

Und hier jetzt hoffentlich der Screenshot, den ich seit 2 Stunden nicht hochladen kann, weil der Forumsserver bockig ist:

 

[rzdz]

Aktueller Status:
Bootloop Nr. 2 gebaut.

Auslöser:
Dachte, ich müßte unbedingt nochmal ausprobieren, alle gesicherten Partitionen mit der funktionierenden Scatterdatei (aus dem Netz) als "Firmware Upgrade" zu flashen, also auch diese:
PRO_INFO
NVRAM
PROTECT_F
PROTECT_S
SECCFG
EXPDB
Dazu wurden in der Scatterdate die is_download: false - Einträge in true geändert.
Dann Cache und DalvicCache gelöscht; Werksreset. Flashen lief problemlos durch.

Folge:
Bootbild erscheint und bleibt hängen, die sonst folgende Bootanimation erscheint dann nicht mehr.
Batterie raus und rein half nicht. USB Verbindung (Handy ausgeschaltet) wird vom PC noch mit Verbindungston quittiert.

Fehlerbehebung:
Nachdem die Methode weiter oben (Preloader flashen, dann UBOOT und Recovery) nicht half, Alcatel Onetouch Upgrade S gestartet, ist problemlos durchgelaufen. Nach 15 Minuten normaler Neustart.

Hat jemand eine Idee, warum das Flashen der "is_download: false-Partitionen" diesen Absturz verursacht hat?

 

[N2k1]

Das hat nicht den Absturz verursacht.. wenn das ohne PMT-Problem durchläuft, kannst DU es ja nochmal testen, indem Du nur diese Partitionen flashst.
Aber ich würde mich darauf konzentrieren, die Scatter den EBR (oder umgekehrt) anzupassen, so daß man einzelne Partitionen flashen kann.

 

[rzdz]

Das hat nicht den Absturz verursacht.

Was kann es sonst gewesen sein, ich habe ja sonst nichts gemacht?

Aber ich würde mich darauf konzentrieren, die Scatter den EBR (oder umgekehrt) anzupassen, so daß man einzelne Partitionen flashen kann.

Das sollte der letzte Versuch ja bezwecken, deswegen "Firmware upgrade" und "alle Partitionen".
Mit der Netz-Scatterdatei kann ich ja bereits einzelne Partitionen flashen.
Nur die 2GB große Original-USRDATA habe ich noch nicht probiert, und stattdessen zur Netz-Scatterdatei gehörende 18MB große USRDATA benutzt.
Habe keinen Nachteil dadurch im Betrieb des Geräts feststellen können (aber auch nicht alles getestet).

Ich bin am überlegen, ob ich nicht einfach diese funktionierende Netz-Scatterdatei und die 18MB-USRDATA als "Masterdateien" zum zukünftigen flashen aufhebe, und die von MTK DT erzeugten regelmäßig ignoriere.
Bin mir aber nicht sicher, daß das System dann in allen Fällen sauber zugreifen kann, denn irgendwo sind ja noch die falschen Partitionsinfos abgelegt...

 

[N2k1]

Das sollte der letzte Versuch ja bezwecken, deswegen "Firmware upgrade" und "alle Partitionen".

Deshalb ja Firmware upgrade - und nicht einfach alles formatieren. Dann kümmert sich das SPFT darum, daß nichts verloren geht.

Habe keinen Nachteil dadurch im Betrieb des Geräts feststellen können (aber auch nicht alles getestet).

Nachteil ist nur, daß Deine Daten nicht da sind.
USRDATA = Daten des Users
Dort landen Deine installierten Programme und deren Daten.
Wenn Du nun also eine Scatter-EBR-Kombination hast, die ohne "PMT changed" daherkommt, dann hast Du alles.

 

[rzdz]

Deshalb ja Firmware upgrade - und nicht einfach alles formatieren. Dann kümmert sich das SPFT darum, daß nichts verloren geht.

Ich habe ja nichts manuell formatiert, und ob etwas verlorengegangen ist, kann ich nicht beurteilen.
Ist halt nicht mehr hochgefahren...

Nachteil ist nur, daß Deine Daten nicht da sind.
USRDATA = Daten des Users
Dort landen Deine installierten Programme und deren Daten.

Das ist mir im Moment nicht wichtig, da das Handy ja neu ist.
Die Serien-Apps liegen woanders, oder? (da muß ich auch noch ausmisten)

Wenn Du nun also eine Scatter-EBR-Kombination hast, die ohne "PMT changed" daherkommt, dann hast Du alles.

Ja, habe ich: die 7041X-Scatter vom Netz.
Die EBRs und MBR der 7041X und meiner 7041D sind übrigens identisch.

Nur wäre es schön, wenn zu einem späteren Zeitpunkt, nach x Modifikationen, Installationen etc., jederzeit mit MTK-DT ein Scatter erstellt werden könnte, der dann auch mit SP-FT funktionsfähig Backups wiederhergestellt werden können.
Das ist das, worauf ich hier Wert lege, und warum mich die momentane Inkonsistenz so stört.

 

[N2k1]

Die Serien-Apps liegen woanders, oder? (da muß ich auch noch ausmisten)

Normal unter /system/app oder /system/priv-app

Und wenn Du jetzt per MTK DT eine Scatter erstellst, weicht sie von der Scatter ab, die Du beim Flashen hattest?

 

[rzdz]

Und wenn Du jetzt per MTK DT eine Scatter erstellst, weicht sie von der Scatter ab, die Du beim Flashen hattest?

Ja, es entsteht immer wieder die Scatterdatei vom Anfang, mit der sich nichts flashen läßt wg. "PMT changed".
Das ist ja das Problem...

Man müßte halt definitiv wissen, wo MTK-DT die Infos für die Scatterdatei herholt, und womit SP-FT dann vergleicht.
Vielleicht hat ja auch eines der Tools einen Bug, das die Scatterdatei falsch erzeugt, oder falsch verglichen wird...

Hier noch ein interessanter Link zu dem Thema mit genau diesem Gerät:
Problems - Post #61 - XDA Forums

 

[N2k1]

Das MTK DT holt die Infos aus /proc/eMMc - da kannst Du ja vergleichen.
Das bedeutet aber, daß Die EBR nicht zur Scatter passen..

BTW: Die System- und Custpack-Partition könnte man zusammenfassen ..

 

[rzdz]

BTW: Die System- und Custpack-Partition könnte man zusammenfassen ..

Was bringt das?

 

[N2k1]

Die sind wechselseitig verlinkt, ich weiß nicht, warum die überhaupt getrennt wurden..
Wenn man "basteln" will, ist das sehr verwirrend - finde ich.

 

[rzdz]

Wenn man die ganzen Links dann austauschen will, ist das doch bestimmt eine Riesen-Aktion, oder?

 

[N2k1]

Eigentlich "nur ein ineinander Kopieren"

 

[rzdz]

Laßt uns erst mal das Flashproblem lösen.

Ich habe die Infos aus cat /proc/emmc ,cat /proc/dumchar_info, ausgelesenem und Netz-Scatterfile gegenübergestellt:


Grün sind die Bestätigungen, rot die Abweichungen.

Ich sehe im cat /proc/emmc bei emmc_p1: 00000400 00000002 "ebr1" einen auffälligen Eintrag,
bei Partitionsbezeichnung RSV_OTP im Scatterfile und bei den rot markierten im funktionierenden Netzscatterfile.
Den Eintrag RSV_OTP hatte ich auch schon in OTP geändert, was nichts am PMT changed error änderte.

Auch ist uboot.bin als LK.bin im eigenen Backup gewesen, das ich dann umbenannt habe.
Frage mich wo der Name LK.bin herkam, wenn im Scatter und dumchar_info uboot.bin steht.

Wie kommen die Einträge in cat /proc/emmc und cat /proc/dumchar_info zustande?
Sind das einfache Herstellereinträge oder werden sie vom System aus MBR und EBRs erzeugt?

 

[N2k1]

Ich sehe im cat /proc/emmc bei emmc_p1: 00000400 00000002 "ebr1" einen auffälligen Eintrag,

Was ist daran auffällig? Die Sektorgröße ist mit 512 Bytes angegeben (0x200) - damit ist 2 * 0x200 = 0x400 = 1024 Bytes
Tatsächlich sind MBR, EBR1 und EBR2 sogar nur 512 Bytes groß - am PC kommen sie aber mehrfach vor.

bei Partitionsbezeichnung RSV_OTP im Scatterfile und bei den rot markierten im funktionierenden Netzscatterfile.
Den Eintrag RSV_OTP hatte ich auch schon in OTP geändert, was nichts am PMT changed error änderte.

Das sind nur Bezeichnungen.

Auch ist uboot.bin als LK.bin im eigenen Backup gewesen, das ich dann umbenannt habe.
Frage mich wo der Name LK.bin herkam, wenn im Scatter und dumchar_info uboot.bin steht.

Normal heißt der Bereich uboot - da dort (izwischen) aber viel mehr passiert, heißt der Bereich LittleKernel - also LK.
Das ist der eigentliche BootLoader... (nicht das Boot-Image, wie oft behauptet wird)

Nun zu den Sachen, die Du verlinkt hast..
Sowohl im Dump - als auch in der funktionierenden Version sind Fehler drin.
OTP und BMTPool überlappen einander. Das ist schlicht falsch!
Zudem dürfte Deine Data-Partition sogar größer sein als sie ist - aber Verschwendung ist nicht gleichbedeutend mit falsch ;-)

 

[rzdz]

Was ist daran auffällig? Die Sektorgröße ist mit 512 Bytes angegeben (0x200) - damit ist 2 * 0x200 = 0x400 = 1024 Bytes

Auffällig finde ich, daß die Größenangabe der EBR1-Partition in cat /proc/eMMC: 0x400
und in cat /proc/dumchar_info und Scatterfile mit 0x80000 voneinander abweichen.

Das sind nur Bezeichnungen.

Ja, aber was mach SPFT wenn da die falsche Bezeichnung steht beim zurückflashen?
Heißt dann die Partition auf dem Handy plötzlich RSV-OTP statt wie vorher nur OTP, und wird die Partition dann noch normal vom System gefunden?

Normal heißt der Bereich uboot - da dort (inzwischen) aber viel mehr passiert, heißt der Bereich LittleKernel - also LK.
Das ist der eigentliche BootLoader... (nicht das Boot-Image, wie oft behauptet wird)

Danke für die Erklärung.
Mich wundert halt, wo MTK DT die Bezeichnung LK her hat, wenn im Gerät nur UBOOT verwendet wird.

Nun zu den Sachen, die Du verlinkt hast..
Sowohl im Dump - als auch in der funktionierenden Version sind Fehler drin.
OTP und BMTPool überlappen einander. Das ist schlicht falsch!

Ja, daß da irgendwas nicht stimmt, habe ich schon vermutet.
Auch ist da mal ein Offset von 0x1000000 zwischen linear und physikalischer Adresse, mal nicht.
Was ich aber seltsam finde, ist die Tatsache, daß die fremde Scatterdatei trotzdem akzeptiert wird.

Zudem dürfte Deine Data-Partition sogar größer sein als sie ist - aber Verschwendung ist nicht gleichbedeutend mit falsch ;-)

Wie groß ist sie denn wirklich?
Gibt es eine Möglichkeit, das herauszufinden?

Und, hast Du eine Idee, wie es jetzt weitergehen könnte?

 

[N2k1]

Zuerst zur Größe: Wenn per Scatter mehr reserviert wird, als man benötigt, dann ist alles gut.. anders herum gibt es Probleme.
Eigentlich ist das alles keine Hexerei. Wenn alle Partitionen angegeben sind, so sollte folgendes gelten.
Start1 + Größe1 = Start2
Start2 + Größe2 = Start3
...
StartXY + GrößeXY = Ende_des_eMMC

 

[rzdz]

Zuerst zur Größe: Wenn per Scatter mehr reserviert wird, als man benötigt, dann ist alles gut.. anders herum gibt es Probleme.
Eigentlich ist das alles keine Hexerei. Wenn alle Partitionen angegeben sind, so sollte folgendes gelten.
Start1 + Größe1 = Start2
Start2 + Größe2 = Start3
...
StartXY + GrößeXY = Ende_des_eMMC

Ist PRELOADER "phys. Start Adr."dann die Ausnahme (wg. umswitchen, wenn ich Dich richtig verstanden habe) oder sind dann alle nachfolgenden "phys. Start Adressen" um 0x100000 zu niedrig?
Den Rest der Berechnung hatte ich ja schon früher überprüft:
Problem beim Rooten mit MTK Droidtool... | Seite 3
Das hier funktionierte auch mit den korrigierten Werten nicht:

Links: Scatterdatei Rechts: $ cat /proc/dumchar_info

- partition_index: SYS20
partition_name: USRDATA USRDATA
file_name: data.img
is_download: true
type: YAFFS_IMG
linear_start_addr: 0x65880000 0x65880000 (berechnet)
physical_start_addr: 0x64880000 0x64880000
partition_size: 0x82C00000 0x82C00000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00

- partition_index: SYS21
partition_name: RSV_OTP OTP
file_name: NONE
is_download: false
type: NONE
linear_start_addr: 0xFFFF0200 0xE8480000 (berechnet) ABWEICHUNG !!!!
physical_start_addr: 0xFEFF0200 0xfeff0200 (???) neu berechnet: 0xE7480000
partition_size: 0x4000000 0x4000000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: INVISIBLE
reserve: 0x00

- partition_index: SYS22
partition_name: BMTPOOL BMTPOOL
file_name: NONE
is_download: false
type: NONE
linear_start_addr: 0xFFFF00A8 0xEC480000 (berechnet) ABWEICHUNG !!!! (bis hierher ließ sich ROM_0 auslesen, nicht wesentlich weiter)
physical_start_addr: 0xFFFF00A8 0xfeff00a8(???) neu berechnet: 0xEC480000 oder 0xEb480000
partition_size: 0x1500000 0x1500000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: false
is_reserved: true
operation_type: RESERVED
reserve: 0x00

Ende: (berechnet) 0x1014F00A8 (> 4GB???) 0xED980000 ABWEICHUNG !!!

Eben mal quick and dirty aus dem alten Text zusammengesucht.
Muß ich aber nochmal ganz genau überprüfen (morgen), insbesondere die "neu berechneten" Werte!

Was passiert denn, wenn ich die Scatterdatei jetzt doch funktionieren würde?
Werden dann die letzten beiden Partitionen auch ohne vorhandene Backup-Dateien funktionsfähig verschoben?
Ein Auslesen der Dateien scheint ja nicht möglich zu sein. (bis 0xEC480000 ließ sich ROM_0 auslesen, nicht wesentlich weiter)

Was sagst Du denn hierzu:

Auffällig finde ich die Abweichung der Größenangabe der EBR1-Partition: 0x400 in cat /proc/eMMC und 0x80000 in cat /proc/dumchar_info und im Scatterfile.

Ist das erlaubt, solange die Scatterdatei mehr Größe reserviert als in cat /proc/eMMC steht?

 

[N2k1]

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

 

[Ora]

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. Sogar die letzte aktuelle 3er Version des SP FT sollte damit bei Dir vollständig die Arbeit verrichten.
Andere Frage: Was bemängelst Du eigentlich an der Funktion des Telefons aktuell?