EBR / MBR / PTM - Angaben irgendwie doppel gespeichert im Telefon!?

[Toshy]

Hallo.

Zwar gehört es zu meinen anderen Anliegen, ist hier allerdings doch mal eine spezielle Frage, daher ein gesondertes Thema.

ich habe bei meinem THL 5000 32 das Problem, es wieder auf 32 GB Rom zu bringen. Auf manchen Seiten im Internet steht, das es diese Version nie gab, eigenartiger Weise haben diese Shops (die großen THL-shops das alle mal angeboten. Kann man sogar oft noch im Googlecache sehen). War kein Fake, alles lief, Größe paßte auch. Leider kein Stockrom in der Größe zu finden. Es seint so, als ob ich das mit der MBR / EBR und Scatter in Bezug auf die SD teils hin bekomme, wenn auch noch nicht ganz verstanden.

Lese ich so nach dem Flaschen die SD-Kartengröße aus (zum testen verkleinerte Werte) so wird das im handy übernommen (Formatiere mit sp und Recovery), qtadb zeigt die Größe so an, und sogar selbst per adb shell df.

a) allerdings wird die Blk-/Blocksize mit df je nach Flash unterschiedlich angezeigt, mal 1024, mal 4096, nie 512, was an sich ja sein müßte bei der Anpassung in der EBR. Wie kann das sein.

b) Eigenartiger, MKT Droid tool, zeigt immer eine andere Paritionsgröße der SD aus, IMMER die selbe etwas größer aktuell als ich jetzt habe, ich ca. 1,2 gb geflash, angezeigt werden ca. 3,8 GB IM TOOL) Und diese Grenze kann ich wohl nicht nach überschreiben. Dabei fehlen noch die ungefähr 16 gb ROM.

Egal was ich mache, ich bekomme es nicht hin. Backup der Originaldateinen hatte ich nie hinbekommen (außer NVRAM und SYSTEM). Da ich im SP-tool und Recovery alles formatiert habe (auto format, sogar mit bootloader) sollte sich der wert doch ändern. das einzige was ich noch nicht geteste habe ich,

c) das ich "manuell Format" nutze und die Speicherbereiche angebe. Und dann halt ab 0x0 alles lösche. Da steht dann eine Warnung, das auch die "Calibriation" gelöscht wird. Und ich kann halt

emmc_user,
und
emmc_uboot1
und
emmc_uboot2
löschen.

sollte ich einfach mal alles löschen!!!? mit welchen Daten? Ich hoffe, ich kann dann noch normal flasch.
Oder!??? Denn ansonsten hätte die Möglichkeit des Löschens ja keinen sinn. Nur soweit ich verstanden habe, ist das uboot (warum zwei uboot) doch der eigendlich allererste "bootloader", der den eigendlichen bootloader lädt.

d) daher die frage, geht dann das flashen mit ausgeschaltetem Handy doch noch. Ich las etweas, das es da dennoch noch eine quasi nicht löschbare (so klang es dem sinn nach) software (vielleicht in der hardware) drinn bleibt. ich weiß nicht ob das fastboot ist oder im chip eingebrannt.

ich will nur einfach alles komplett platt machen und wissen, daß ich da noch drüber kann.

Falls ihr die ersten Dinge mit dem "wo es sonst gespeichert ist" nicht wisst, vielleicht wenigstens ob ich "gefahrlos" alles löschen kann. Gefahrlos... in Sinne von, weil ich ja wieder mit dem sp Tool flashen kann (oder notfalls fastboot).

Ich vermute, meine Verständnissprobleme lagen / liegen auch daran, daß einfach dieser eine "Wert" der Partitionsgröße sich nie ändert. Ich hatte zwar mal daran gedacht, vielleicht ist der hardwarecodiet, damit man nicht zu groß flasht, aber das kann ja nicht sein, da es real 32 gb waren und wohl sind.

Herzlichen Dank und lieben Gruß
Toshy

 

[dorschdns]

Das uboot hat nichts mit dem Bootloader zu tun Darin sind nur informationen über die Treiber und die Treiber selbst abgelegt.
Für das booten sind boot und preloader verantwortlich.

 

[Tzul]

Das uboot hat nichts mit dem Bootloader zu tun Darin sind nur informationen über die Treiber und die Treiber selbst abgelegt.
Für das booten sind boot und preloader verantwortlich.

Das stimmt so nicht. "UBOOT" / LK ist der Bootloader (man könnte auch sagen Bootloader zweiter Stufe, Preloader ist der erste). Der Bootloader initialisiert einige Hardware, darunter das Display, und lädt dann "boot" (Android) oder Recovery...

a) allerdings wird die Blk-/Blocksize mit df je nach Flash unterschiedlich angezeigt, mal 1024, mal 4096, nie 512, was an sich ja sein müßte bei der Anpassung in der EBR. Wie kann das sein.

Hallo Toshy. Ich hatte leider noch keine Zeit, auf dein anderes Thema zu antworten.
Du wirfst hier mal wieder einiges durcheinander!
DF zeigt dir die Clustergröße des Dateisystems an, das ist wieder etwas anderes als Sektorgröße (512 Bytes), Flash-Seitengröße (z.B. 2 KiB), und Flash-Blockgröße (z.B. 128 KiB).

Außerdem solltest du die Finger von der Formatierungsseite des SPFT lassen. Lies mal genauer, da steht "EMMC_BOOT1", nicht "uboot1"! Die EMMC-Regionen (boot1, boot2, rpmb, user) sind etwas anderes als die Partitionen!

Wenn das SPFT eine Verbindung mit dem Gerät herstellt, zeigt es links unten einige Details an. Schreib die alle mal auf, oder mache Screenshots. Insbesondere alle Werte unter "EMMC Flash" (Boot1 Size, Boot2 Size, UA Size, ... siehe unvollständiges Beispiel im Anhang).

 

[Toshy]

Du wirfst hier mal wieder einiges durcheinander!
DF zeigt dir die Clustergröße des Dateisystems an, das ist wieder etwas anderes als Sektorgröße (512 Bytes), Flash-Seitengröße (z.B. 2 KiB), und Flash-Blockgröße (z.B. 128 KiB).

Daher frage ich. Leider stand halt BLK/-Blockgröße bei DF, nicht "Cluster" und ansonsten kannte ich nur die Blockgröße vom Flash mit 128. Nur wann jetzt wo und was verwendet wird, warum mal der eine Wert, mal der andere angezeigt wird wurde verstehe ich noch nicht ganz. "Sektoren" gab es ja soweit ich weiß bei Festeplatten usw, bei Flash halt diese Seiten und Blöcke, wann nun was wofür... grummel. noch nicht so ganz kapiert.

Daher ist mein anderer Artikel jetzt auch erst mal nicht sooo wichtig, da bin ich schon sehr weit gekommen. Hier hapert es noch am Verständnisd bzw.... Warum da nicht "größer geflasht" wird, also auf bis zu 32 gb.

Ja, emmc_boot, nicht uboot, beim schreiben aus dem Gedächtnis falsch übermittelt.
Formatieren war aber leider die einzige Möglichkeit, als die PMT-Meldungen kamen. Und die waren von anfang an da. Da war wohl irgendwie was mit der Zeit mehr oder mindern "von alleine" Fehlerhaft gewesen.

Was ist der unterschied von boot1... den emmc-Regionen zu dem Anderen. Falls du die ebr- und mbr-Partitionen meinst, dann ist mir das an sich schon soweit klar. Denke ich ;-) in den "freien Speicherbereichen bzw innerhalb der Partitionen sind dann diese anderen Teile reingeschrieben. Warum, keine Ahnu

ng. Ich habe vermutet, damit sie beim bearbeiten der Partitionen (format) noch erhalten bleiben. ODer meinst du etweas anderes?

Ich lade mal ein Bildschirmfoto hoch. Ob es aber noch die Originalen Daten sind, weil ich nicht. Mir hat halt bisher UA Size, GP1-4 noch nichts gesagt. Bin noch am Suchen nach Informationen dazu.

Was genau die UA-Größe ist weiß ich nicht. Scheinen 14 GB zu sein. Ich kann nur vermuten, daß die Flashspeichergröße ist, abzüglich irgendwelcher "versteckten Systemteile", vielleicht das wo auch Preloader drinn ist (wegen 0x0 von mbr und 0x0 preloder komme ich da drauf).

Ich kann nur vermuten, daß schon kurz nach dem Kauf, einfach durch ein Werksreset und vielleicht formatieren mit der Stockrom was schief lief. Vielleicht wurde einfach irgend etwas falsch eingebaut, weil die meißten Geräte nur 16 GB haben.



Toshy

 

[Tzul]

Leider stand halt BLK/-Blockgröße bei DF, nicht "Cluster"

Wie auf Wikipedia beschrieben ist "Cluster" Windows-/Microsoft-Terminologie. Bei Linux heißt das eben leider auch "Block" - aber da DF Dateisysteminformationen anzeigt, liegt es nahe, dabei nicht an Flash-Blöcke zu denken, denn die liegen in der Hierarchie näher an der Hardware.

Warum da nicht "größer geflasht" wird, also auf bis zu 32 gb

Vielleicht weil das physisch unmöglich ist mit einem 16 GB Flashspeicherchip.

Formatieren war aber leider die einzige Möglichkeit, als die PMT-Meldungen kamen. Und die waren von anfang an da. Da war wohl irgendwie was mit der Zeit mehr oder mindern "von alleine" Fehlerhaft gewesen.

Dann hast du eine falsche Scatterdatei benutzt, deren Informationen von den PMT-Daten auf dem Handy abwichen. Durch dein Formatieren hast du die PMT gelöscht - hättest aber besser die Scatterdatei korrigieren sollen.

Was ist der unterschied von boot1... den emmc-Regionen zu dem Anderen

EMMC = Embedded MultiMediaCard. Kurz gesagt sind das "intelligente" Flashspeicherchips mit integriertem Controller, die für internen Speicher benutzt werden und dabei ähnlich wie MMC/SD-Karten angesprochen werden (SD-Karten sind eine Weiterentwicklung von MMC). Früher wurden mal "dumme" Flashspeicherchips verwendet ohne eigenen Controller, die dann per Software verwaltet werden mussten (Stichwort MTD). Heute findet man aber bei Android-Geräten meistens EMMC. Und dieser Standard teilt den Flashspeicher eben in mehrere Regionen ein, die nach der Herstellung/Initialisierung von der Größe her nicht änderbar sind. Die Regionen siehst du in deinem Screenshot: Boot1 (da steckt das Bootprogramm drin, bei MediaTek der Preloader), Boot2 (bei MediaTek leer), RPMB, GP1-4 (General Purpose / Allzweck, meist unbenutzt), und schließlich die Region für "normale" Benutzerdaten (UA / user data area). In dieser letzten Region befindet sich dann all die bekannten Partitionen (MBR, usw.).
Deine UA ist 0x3AB800000 = 15032 MiB groß. D.h. dieses Gerät hat höchstwahrscheinlich einen 16 GiB EMMC-Chip und nicht 32 GiB!

 

[Toshy]

Vielleicht weil das physisch unmöglich ist mit einem 16 GB Flashspeicherchip.


Dann hast du eine falsche Scatterdatei benutzt, deren Informationen von den PMT-Daten auf dem Handy abwichen. Durch dein Formatieren hast du die PMT gelöscht - hättest aber besser die Scatterdatei korrigieren sollen.

Grins. Ja, nur noch mal zur Sicherheit genannt, es sind wirklich 32 GB.

Das mit der Scatter kann sein, oder auch nicht. Das doofe war ja, schon als ich das erste Mal vor vielen Monaten das erste mal die Scatter auslaß wurde eine 16 GB Version ausgeworfen. Also konnte ich nur die jetzt nutzen bzw. merkrte das beim zurück spielen nicht. Vorab hatte ich damals nichts im Handy geändert. Außer das ich dann irgendwann mit MKT Droid gerootet habe bzw. es versucht und das das bei gelegte CWM Recovery aufgespielt habe (automatisch meines angepaßt).

Seit dem war es die selbe Scatterausgabe, ähnlich oder gleich den 16 GB Stock. Allerdings konnt ich dennoch ohne Probleme die 32 GB nutzen. Selbst nach einigen Löschvorgängen der SD. Erst nach dem jetzt das Handy total nicht ging (keine Schreibzugriffe auf die SYSTEM, viel getestet, sah nach Partitionsfehler oder so aus, das das was beim Absturz zerschossen wurde), spielte ich halt einfach das bissl Backup was ich hatte zurück. Na, versuchte es.Ging nicht wegen PMT Fehler. Also wie auch im Internet beschrieben, Versuch mit Upgrade, FormatDownload, Format usw.
Wie gesagt, ich hatte die vom MTK-Tool ursprünglich erstellte Scatter genutzt, die aber eigenartiger Weise schon, wie ich jetzt weiß, den falschen Wert hatte. Warum auch immer.
Die PMT war also wohl schon vor dem Formatieren defekt, das war ja der Grund meiner Formatierungsversuche (mit angepaßter Scatter und EBR2)

Wenn also die Scatter die PMT nun überschrieben hat, mit falschen Wert, dann muß das ja auch gehen mit dem richtigen. Und das bekomme ich nicht hin. Ich habe grob 900 mb syste, aktuell 10 gb data und sd läßt maximal unter 4 gb zu. wengier bekomme ich per scatter und ebr2 hin, aber mehr nicht. selbst wenn ich erneute (autoflash) nutze usw. und hier kapiere ich was nicht. wie oben beschrieben.

Deine UA ist 0x3AB800000 = 15032 MiB groß. D.h. dieses Gerät hat höchstwahrscheinlich einen 16 GiB EMMC-Chip und nicht 32 GiB!

Und das ist das was wirklich nicht sein kann und nicht so ist. Nicht nur das ich es so damals gekauft habe (16 gb version auch), es ist auch ausreichend getest, nicht nur mit apps, sondern ich habe den speicher oftmals fast bis auf das letzte bitt, oder bis dahin ausgenutzt. tv-serien / dokus drauf bis der speicher voll war (glaube ca. 24 gb) und die dann durch geschaut. keine Dateifehler oder so. Es sind also 32 gewesen. Ich selbst hatte schon jetzt öfter an eine Fakeangabe gedacht, nur kann es halt nicht sein. Seit zwei Jahren oft genug ausgenutzt.
Die Aufteilung ist wie du sagst wohl hardwaretechnisch fixiert, ich denke da vor allem an diese boot1 und boot2, aber es kann ja sein, daß der rest halt zwar in der hardware für die chips natürlich noch mal steht, aber für die benutzer das irgend wo rein geschrieben wird und da was falsch eingetragen ist. vielleicht genau in diesen "Kalibrierungsdaten".

JEtztm, wo du mir schreibst, daß im emmc_boot1 der preloader ist, dürfte ja gar nichts passieren, wenn ich emmc_user komplett radiere.
ich hatte ja sogar irgend wo im Internet gelesen, das selbst ohne preloader es da doch och ne möglichkeit gibt. Aber das muß man ja nicht testen ;-)
Zwar ist mir ein 16 gb handy das funktiort lieber als eines mit 32 das ich als Wurfgeschoss nehmen kann, aber ich kann mir wirklich nicht oft was leisten. Und... das gerät ist für meine Zwecke genial, sehr schnell, vor allem wenn man halt 32 gb internen speicher hat. und bei extrem vielen apps (system und user sind zusammen weit über 300).......
das währen 16 fehlende GB nicht so toll.

Zwei Tage hatte ich zweifel an der Speichergröße des Chips, aber die sind wieder verflogen. Warum es da teils "Originale Geräte" gibt, die es in der Ausstattung wiederum "nicht offiziell" geben dürfte, ist gar nicht so schwer zu verstehen. Die wissen selbst manchmal nicht was sie tun. grins ;-) Na ja, und die Lizenzpolitik. Die stellen ja nicht immer selbst her, sondern geben die Lizenz für Serien ab, ganz offiziell. Und da passiert es schon mal, das ein kleines Leistungsmerkmal geändert wird. Bei mir scheint es der Speicher zu sein. Lustig ist dann nur, das einige Shopsmitarbeiter manchmal selbst behaupten, daß es so und so ein modell gar nie hergestellt wurde, dabei haben sie die jeweiligen sogar selbst verkauft. hihi.

Mir bleibt also wohl nichts überbrig, also noch mehr zu formatieren, also Userdata komplett. Einfach testen.... oder berechnen? 32 gb oder 32gb-boot1 und boot2 oder oder oder...

Auf jeden Fall waren deine Informationen schon mal interssant und hilfreich.

Danke
Toshy[DOUBLEPOST=1471556907,1471555154][/DOUBLEPOST]Noch mal nach gefragt. 0x3AB800000 = 15032 MiB sind ja 14 gb (umgangssprachlich, genauer GiB). Wo sind die anderen 2 GiB? Bzw. warum stehen da nur 14..
alleine cache,system, data und restSD sind schon bei ganz knapp über 14 GiB. außerdem hat das handy von haus aus 1 GiB virtuellen Ram / swap. wo auch immmer der gespeichert wird. wohl nicht auf den sichtbaren partitonen. eine 1 GiB datei oder so habe ich nicht mal mit DiskUsage oder so gefunden, auch wenn der Pfad in "Ramexpander" angezeigt wird.
Aber die 2 GB sind jetzt nicht so wichtig, die Aufteilung ist für mich zwar interssant, ändert allerdings wenig an meinem Problem. Außer, wenn ich jetzt Manuell anpasse, da auch Platz für sein muß ;-)

Also, wohl einfach mal testen, was beim Formatieren und zurückspielen passiert

 

[Toshy]

eine app wirft mit aus "keine FDISK compatible Partitionstabelle" nur mal so als hinweis.

 

[Tzul]

Grins. Ja, nur noch mal zur Sicherheit genannt, es sind wirklich 32 GB.

Was zu beweisen wäre...
Ich glaube dir durchaus, dass es THL 5000 mit 32 GB geben kann, auch wenn offiziell nur Modelle mit 16 GB bekannt sind.
Bei meinem alten Zopo ZP700 war es nämlich ähnlich: das hatte offiziell 4 GB, aber später habe ich noch eins mit 8 GB bekommen, obwohl beim Händler und sogar auf der Verpackung noch 4 GB standen.
Sowohl das SPFT als auch Android haben den Chip als 8 GB ausgewiesen, und alles hat problemlos funktioniert, bis ein-zwei Jahre später der Touchscreen angefangen hat, herumzuspinnen...

Wenn auf deinem Gerät Android oder ein Recovery läuft, könntest du mal ein Terminal oder ADB Shell öffnen, dann:

cd /sys/class/block/mmcblk0/device/
cat name
cat cid
cat csd
cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd

Der letzte Befehl braucht root, also wenn ein "Permission denied" Fehler kommt, dann "su -c cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd".

Das wird dir den Namen sowie die Konfigurationsregister des eMMC-Chips auflisten. Die Werte könntest du mir mitteilen, dann werde ich sie prüfen (insbesondere ext_csd).
Alternativ könntest du auch dein Handy öffnen, den/die eMMC-Chip(s) finden und ihre Modellnummern prüfen.

Die Aufteilung ist wie du sagst wohl hardwaretechnisch fixiert, ich denke da vor allem an diese boot1 und boot2, aber es kann ja sein, daß der rest halt zwar in der hardware für die chips natürlich noch mal steht, aber für die benutzer das irgend wo rein geschrieben wird und da was falsch eingetragen ist.

Sagt dir SLC, MLC, TLC etwas? Single Level Cell, Multi Level Cell, Triple Level Cell... beschreibt, wie viele Bits pro Flashzelle gespeichert werden. SLC = 1 Bit pro Zelle, schell, robust, aber teuer. MLC = 2 Bit pro Zelle, TLC = 3 Bit pro Zelle (höchste Datendichte, aber langsamer und stirbt früher). Die verschiedenen eMMC-Regionen können mit verschiedenen Levels konfiguriert werden, also z.B. BOOT1 = SLC (maximale Robustheit und Lebensdauer, weil hier der wichtige Bootcode steht), User Area = MLC oder TLC (höhere Speicherkapazität).

Es ist daher theoretisch möglich, dass deine User Area ursprünglich TLC war und dann auf MLC umkonfiguriert wurde --> Kapazität halbiert. Oder von MLC auf SLC, aber das halte ich für noch unwahrscheinlicher. Ich kenne auch nicht alle Feinheiten des eMMC-Standards und weiß nicht, ob eine solche "Leveländerung" überhaupt möglich ist, nachdem der Chip die Fabrik verlassen hat.

Mir bleibt also wohl nichts überbrig, also noch mehr zu formatieren, also Userdata komplett. Einfach testen.... oder berechnen? 32 gb oder 32gb-boot1 und boot2 oder oder oder...

Nein, das hilft alles nichts. Solange die Hardware (der eMMC-Chip) meldet, dass nur 15/16 GB Speicher da sind, kannst du formatieren und flashen bis du schwarz wirst, da wird sich nichts ändern. Du kannst kein 32 GB Dateisystem anlegen, wenn auf der darunterliegenden Hierarchie-Ebene nur 16 GB verfügbar sind.

Noch mal nach gefragt. 0x3AB800000 = 15032 MiB sind ja 14 gb (umgangssprachlich, genauer GiB). Wo sind die anderen 2 GiB? Bzw. warum stehen da nur 14..

Gute Frage. Die anderen Regionen (BOOT1&2, RPMB) benötigen natürlich auch noch ein bisschen Speicher (und wenn sie als SLC konfiguriert sind, dann entsprechend "mehr"). Außerdem gibt es Reserveblöcke, die abgenutzte Flash-Blöcke ersetzen sollen. Und vielleicht mogeln die Flash-Hersteller auch ein bisschen, ähnlich wie die Festplattenhersteller (z.B. Faktor 1000 statt 1024 benutzen).

 

[Toshy]

C:\Program Files (x86)\HANDY.ord\android.system.adb.backup.root.Mtk_Droid_Tool_v2_5_3 (multilingual).MTK DT>adb shell
root@THL:/ # cd /sys/class/block/mmcblk0/device/
cd /sys/class/block/mmcblk0/device/
root@THL:/sys/class/block/mmcblk0/device # cat name
cat name
HAG2e
root@THL:/sys/class/block/mmcblk0/device # cat csd
cat csd
d02701320f5903ffffffffef8a4040d3
root@THL:/sys/class/block/mmcblk0/device # cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd
bug/mmc0/mmc0:0001/ext_csd <
/system/bin/sh: cat: /sys/kernel/debug/mmc0/mmc0:0001/ext_csd: No such file or directory
1|root@THL:/sys/class/block/mmcblk0/device # su -c cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd
rnel/debug/mmc0/mmc0:0001/ext_csd <
255|root@THL:/sys/class/block/mmcblk0/device # cat /sys/kernel/debug/mmc0/mmc0:0001/ext_csd
debug/mmc0/mmc0:0001/ext_csd <
/system/bin/sh: cat: /sys/kernel/debug/mmc0/mmc0:0001/ext_csd: No such file or directory
1|root@THL:/sys/class/block/mmcblk0/device #

Tja, hmm, scheint nicht viel zu liefern.

ich habe gerade eine version der 16gb Firmware drauf, ob es gerade eine angepaßte ebr2 und scatter ist, weiß ich nicht. sollte mit den Funktionen aber wohl nicht zu tun haben, hoffe ich.

 

[Toshy]

Auch wenn jetzt nur mal nebenbei angemerkt, ein wenig paßt es auch hier zu. Ich habe so die Vermutung, daß in etlichen Scattervorlagen Fehler drinn sind. Anscheinend sind nicht meine Excelformeln falsch, sondern nur etliche Scatterdateien die ich damit einlese. Aber diese Roms scheinen dann doch zu laufen, nur wie lange....
Interessant:
Jetzt mal was ganz interessantes, ich habe mal versucht die eine und andere vermutlich ganz echte Stockrom zu holen und zu testen, vergleiche ich da scatterstartpositon mit den mbr/ebr1/2 stimmt alles.
Jetzt habe ich z.b. durch readback vom spflashtool und dann mit mtkdroidtool erstellte scatter mit den ebenfalls erstellten MBR / EBR verglichen, so stimmen die Werte von Scatter und ebr2 (erst mal nur ebr2 verglichen) NICHT überein!!!!!

100%ig darf man sich wohl nicht auf die Scatter oder MBR-Angaben verlassen, sollte die doch mal vergleichen.
Wenn das Flashtool nun hin und wieder meckert wegen der PMT, weshalb kann es dann zu solchen fehlern beim flashen kommen. Alles oder ganz genau scheint da doch nicht alles überprüft zu werden. hmmm. auch eigenartig das mit den psysikalischem und linearen angaben ind er scatter. Fast überall sind diese Angaben gleich, aber manchmal unterschiedlich (linear scheint auf den ersten Blick der absoluten Wert zu sein, der psysikalische der relative) und manchmal sind preloader und mbr auf 0x0 und manchmal die mbr genau nach dem preloader. Es würde mich nicht untern wenn dies an unterschiedlichen Flashtoolvarianten liegt. Vielleicht wo die boot1 und boot2 noch nicht getrennt aufgeführt wurden, falls das mal so war. Nur... das verwirrt mich jetzt immer mehr.

Das Testhandy läuft zwar, muß im Aufbau aber fehlerhaft sein. MBR und EBRs sind ja an sich Partitionstabellen, in Android aber wohl gibt es für die weiteren noch eine Stelle wo die gespeichert ist. Wo aich immer. Leider scheinen die nicht immer übereinzustimmen, das muß doch früher oder später zu Fehlern führen

Doof, dann wäre auch das mit hilfe von ORAs angepaßten Dateien meines Sohnes nicht korrekt, da dort wohl fehler "mitgeschleppt" wurden. Ich muß das noch genau anschauen. Na ja, man kann die Partitionen ja sichern, Tabelle anpassen und wieder aufspielen.

Okay, mit meinem 32GB Problem hat das auf den ersten Blick wenig zu tun, vielleicht nichts, andererseit könnte das ja auch durch fehlerhafte Scatter bzw Partitionstabellen entstanden sein.

Man man, mein Kopf raucht doch echt die Tage, aber eher aus Frust ;-)