EBR / Scatter /Anpassen des Speichers - Verständnisfragen

[Toshy]

Hallo.
Da mein English leider sehr schlecht ist und mir das Erlernen schwer fällt, sind auch entsprechende Seiten für mich schwer zu verstehen. Ich bitte gerade "Ora" mir meine Dateien anzupassen.

Für weitere Geräte möchte ich dies vielleicht in Zukunft selbst machen oder schauen, ob das nicht ein Tool oder eine Exceltabelle abnehmen kann.

Ich habe nun für den Anfang einige Fragen bzw. "Vermutungen".
Scatterdatei, EBR, Blockmapping habe ich nun öfter als Begriffe gelesen, wo und wie sind die Unterschiede zu sehen, wie gehört das zusammen? Wie ist der Aufbau usw.

1. Was genau sind die EBR-Dateien. Soweit ich verstehe sind das Partitionstabellen deren Aufbau ich noch nicht ganz verstehe. Ein großer Teil der Dateien wird wohl nicht genutzt ( oder wofür) und dann wird wohl ein wenig Platz für Partionsbeschreibungen benutzt, ist die erste Datei voll, wird die Zweite genutzt, dann eventuell weitere. Bei Android wohl selten oder nie mehr als zwei Dateien.

2. Wenn dem so ist, wozu dann noch die Scatterdatei? Ist das nicht doppelt? Oder stehen da einfach mehr Inforamtionen drinn oder sind dort der Übersicht halber alle Daten noch mal auf gleich Art drinn. Ich vermute, es sind weitere Daten. Also EBR reine Partionsdaten, durch Scatterdatei kann wohl auch Namen, Dateisystem usw. vorgegeben werden (für Software zum erstellen).

3. Falls dem so ist, weshalb werden nicht bei allen Einträgen Dateiformate angegeben?

4. Bei Android kann man den selben speicherplatz wohl speicher gemeinsam nutzen, was wohl bei MTK unter 4.x absichtlich noch nicht geht. also man den speicher als internen speicher oder datenspeicher nutzen kann. da wird dann vermutlich auf den selben Speicherbereich verwiesen. ist dem so und falls ja, weshalb überschreiben dann die bereiche sich nicht gegenseitig. also wenn DATA und SD-INT den selben bereich nutzen, würde doch z.B. das Löschen des interen Speichers den Datenteil löschen und das zurücksetzen des Dataspeichers den SD-Karten-Bereich kann mich da mal jemand aufklären?

5. Wie kann man Scatterdateien selber erstellen? Auch bei neuen Geräten? Denn das MTK-Droidtool soll ja angeblich nicht mehr weiter entwickelt werden und schon jetzt nicht mehr alle Geräte unterstützen. Sollte man dies nicht mehr oder minder alles durch ADB auslesen können?

6. Zitat ORA: "Bitte bei Namensgleichen Smartphones stets die Android Version prüfen (Hier i.d.R. ohne Angabe = 4.2.). Da Kitkat eine veränderte Speicheraufteilung hat, führt das Flashen eines gemoddeten 4.2 Datensatzes bei einem 4.4. Smartphone zu einer Fehlfunktion. "
Wie ist das genau gemeint? Der Aufbau der EBR-Dateien bleibht ja, nur was drinn steht ist anders. Partitionen werden angelegt. Wenn Scatterdateien, wie ich oben vermute, für das kopieren oder / und formatieren oder bennen genutzt wird, was kann dann schief gehen? Wenn ich also die Partitionen System, Data.... usw habe und dann flasche, dann sollten doch die IMAGE-Dateien in entsprechende Partionen kopiert werden. Mich würde das mal interssieren, damit ich hier ein Verständnis für diesen Teil von Android erhalte.

Fragen zum Aufbrau von Scatter und EBR stelle ich danach. Ich möchte nämlich auch SYSTEM-Bereich in der Größe ändern.

Lieber Gruß
Toshy

 

[Poppeye]

http://bfy.tw/6Nhu

 

[Toshy]

Bitte diesen dummen sinnlosen Spam unterlasen. Machen sie dazu ein eigenes Thema auf.

 

[Tzul]

EBR = Extended Boot Record. EBR-Dateien sind Abbilder der EBR-Partitionen. Die Partitionen auf dem Flash-Speicher sind dabei oft größer als nötig, und größer als die Abbilder, die nur die ersten 512 Bytes benötigen. Das entspricht einem "Sektor". Ältere Festplatten wurden in 512-Byte-Sektoren adressiert, d.h. man konnte niemals einzelne Bytes lesen oder schreiben, immer nur einen oder mehrere komplette Sektoren. Der erste Sektor der Festplatte enthielt dabei den MBR (Master Boot Record). MBR und EBRs haben prinzipiell dasselbe Format, ist im Wikipedia-Artikel ausführlich beschrieben. Ein einziger Boot Record hat dabei nur Platz für 4 Partitionseinträge. Um dieses Limit zu erhöhen, wurden EBRs eingeführt.

Obwohl Flash-Speicher ziemlich anders als Festplatten funktioniert, wurde dieses alte Konzept weiterverwendet (bis es auf neueren Geräten endlich durch GPT abgelöst wurde).

Im Gegensatz zu Festplatten wird Flash-Speicher nicht in 512-Byte-Sektoren adressiert, sondern in "Seiten" und "Blöcken". Ein "Block" ist dabei die größere Einheit und besteht aus mehreren Seiten. Die spezifischen Größen können von Flash-Chip zu Flash-Chip variieren, aber typische Werte sind z.B. Seite = 2048 Bytes (2 KiB) und Block = 131072 Bytes (128 KiB), d.h. ein Block = 64 Seiten.
Das Schreiben und Lesen erfolgt immer in Seiten, aber das Löschen kann nur in ganzen Blöcken erfolgen. Soll heißen, wenn man ein einziges Byte auf einen "leeren" Bereich des Flash-Speichers schreibt, dann muss eine komplette Seite geschrieben werden. Möchte man das Byte dann überschreiben, so muss zuerst der komplette Block gelöscht werden, bevor das möglich ist! Da andere Seiten dieses Blocks natürlich auch Daten enthalten können, müssen die vor dem Löschen gesichert und danach wieder zurückgeschrieben werden. Das ist ein ziemlicher Aufwand und schadet der Lebensdauer des Flash-Speichers, da er nur eine begrenzte Zahl von Schreib/Löschzyklen übersteht. Daher hat man sich clevere Techniken überlegt, um den Verschleiß zu minimieren und auf alle Bereiche des Speichers gleichmäßig zu verteilen ("wear levelling"). So würde man in unserem Beispiel vielleicht den Block wegen eines Bytes erst mal nicht löschen, sondern die betroffene Seite als "ungültig" markieren, und das geänderte Byte in einen neue, leere Seite schreiben. Dabei muss man natürlich protokollieren, welche Daten jetzt wo stehen.

Um diese Details muss man sich zum Glück nicht wirklich kümmern, das erledigen Treiber und Hardware automatisch im Hintergrund. Aber es ist wichtig zum Verständnis warum Partitionen immer ein Vielfaches der Blockgröße groß sind (sein sollten), selbst wenn wie im Fall von MBR und EBR nur ein paar Bytes benutzt werden.
Die Blockgröße steht übrigens in der Scatterdatei (block_size).

ist die erste Datei voll, wird die Zweite genutzt, dann eventuell weitere. Bei Android wohl selten oder nie mehr als zwei Dateien.

So ungefähr. Jeder Partitionseintrag des MBR/EBRs zeigt auf eine bestimmte Partition. Ob das bei MediaTek standardisiert ist/war, oder ob es Abweichungen geben konnte, weiß ich nicht. Bei meinem Zopo ZP700 (MT6582) war es jedenfalls so:

MBR zeigt auf: EBR1, protect_f, protect_s, secro
EBR1 zeigt auf: system, cache, data, EBR2
EBR2 zeigt auf: sdcard, (null), (null), (null)

Dabei ist zu beachten, dass die Startadressen dort jeweils LBAs (logische Blockadressen, d.h. Sektornummern) sind, und immer relativ zum jeweiligen Boot Record.
Steht also z.B. im ersten Eintrag von EBR1 die Adresse 165888 (0x28800), und befindet sich die EBR1-Partition an der Adresse 524288 (0x80000), so muss sich die SYSTEM-Partition an Adresse 524288 + 512 * 165888 = 85458944 (0x5180000) befinden!

2. Wenn dem so ist, wozu dann noch die Scatterdatei? Ist das nicht doppelt?

Die Scatterdatei ist primär für das SP Flash Tool!
Ältere MediaTek-Geräte, die MBR/EBR benutzen, enthalten zusätzlich eine "versteckte" Partitionstabelle (PMT / MPT, master partition table). Ja, das ist "doppelt", oder eher "eineinhalb". Denn die PMT enthält Daten aller Partitionen, nicht nur derjenigen, die von MBR+EBRs erfasst werden. Wenn mal also MBR/EBR modifizert und einfach so flasht, dann ensteht eine Diskrepanz zwischen dem was PMT und dem was MBR/EBR über die Partitionierung sagen. Das kann zu Problemen führen.
Deshalb sollte man bei Änderung von MBR/EBR auch die Scatterdatei entsprechend ändern, damit sie sich nicht widersprechen. Und dann mit dem SP Flash Tool im "Firmware Upgrade" Modus flashen, denn nur in diesem Modus wird die PMT anhand der Daten aus der Scatterdatei aktualisiert.

Bei neueren Geräten mit GPT hat man dieses Problem der Widersprüche zwischen PMT und MBR/EBR zum Glück nicht mehr.

3. Falls dem so ist, weshalb werden nicht bei allen Einträgen Dateiformate angegeben?

Du meinst wohl Dateisysteme (ext4, FAT, usw.). Nicht jede Partition hat oder braucht ein Dateisystem.

4. Bei Android kann man den selben speicherplatz wohl speicher gemeinsam nutzen, was wohl bei MTK unter 4.x absichtlich noch nicht geht. also man den speicher als internen speicher oder datenspeicher nutzen kann. da wird dann vermutlich auf den selben Speicherbereich verwiesen. ist dem so und falls ja, weshalb überschreiben dann die bereiche sich nicht gegenseitig. also wenn DATA und SD-INT den selben bereich nutzen, würde doch z.B. das Löschen des interen Speichers den Datenteil löschen und das zurücksetzen des Dataspeichers den SD-Karten-Bereich kann mich da mal jemand aufklären?

Klingt nach "Data-Media-Layout". Bei älteren MediaTek-Geräten war "/sdcard" (also die "interne", der restliche "Telefonspeicher", nicht die tatsächliche SD-Karte) eine eigene Partition. Die einzige, auf die EBR2 zeigt. Das hat sich als nicht besonders praktisch erwiesen. Deshalb haben wir ja das ganze EBR-Änderungszeug gemacht, um die Datenpartition auf Kosten dieser Partition zu vergrößern.

Bei neueren Geräten mit "Data-Media-Layout" ist "/sdcard" keine eigene Partition mehr, sondern ein Verweis auf /data/media/0, also auf einen speziellen Unterordner der Datenpartition. Hat den Vorteil, dass Apps und eigene Medien (Bilder, Musik, usw.) sich den vorhandenen Platz dynamisch teilen, d.h. installiert man weniger Apps, hat man automatisch mehr Platz für eigene Dateien, und braucht man mehr Platz für Apps, löscht man halt ein paar eigene Dateien. Außerdem ist das auch besser für Mehrbenutzerunterstützung. Jeder Benutzer bekommt seine eigene "/sdcard", die dann einfach auf /data/media/1, /data/media/2, usw. verweist. Der einzige Nachteil, den ich kenne, ist dass man so nicht mehr vom PC aus per USB-Massenspeicher-Modus auf /sdcard zugreifen kann, nur noch per MTP-Modus. Der Grund: die alte "statische" /sdcard-Partition war mit dem FAT(32)-Dateisystem formatiert, das jeder PC versteht. Die neue /sdcard ist aber erstens nur ein Verweis und zweitens auf eine Partition, die im ext4-Dateisystem formatiert ist, das Windows-PCs standardmäßig nicht unterstützen.

5. Wie kann man Scatterdateien selber erstellen? Auch bei neuen Geräten? Denn das MTK-Droidtool soll ja angeblich nicht mehr weiter entwickelt werden und schon jetzt nicht mehr alle Geräte unterstützen. Sollte man dies nicht mehr oder minder alles durch ADB auslesen können?

Da gibt es mehrere Wege.
Man kann in den Fastboot-Modus starten und dann per "fastboot getvar all" Infos vom Bootloader bekommen, inklusive Partitionsliste (in umgekehrter Reihenfolge!).
Man kann sich in Android den Inhalt diverser virtuellen Dateien anschauen, die Infos zur Partitionierung enthalten (/proc/dumchar_info, /proc/emmc, /proc/partinfo).
Man kann eine bereits vorhandene Scatterdatei eines Geräts mit gleichem Chip als Vorlage nehmen, und mit dem SP Flash Tool per "Readback" die PMT oder GPT auslesen.
Man kann die Logdateien des SP Flash Tools untersuchen, denn das Tool zieht von sich aus bei jeder Verbindung mit einem Gerät dessen Partitionsinfos, um die Gültigkeit der Scatterdatei zu prüfen...

6. Zitat ORA: "Bitte bei Namensgleichen Smartphones stets die Android Version prüfen (Hier i.d.R. ohne Angabe = 4.2.). Da Kitkat eine veränderte Speicheraufteilung hat, führt das Flashen eines gemoddeten 4.2 Datensatzes bei einem 4.4. Smartphone zu einer Fehlfunktion. "
Wie ist das genau gemeint?

Von Android 4.2 auf 4.4 wurde z.B. die Größe der Partitionen BOOT und RECOVERY erhöht, von 6 auf 16 MiB. Das erlaubt größere Linux-Kernels und bessere Recoverys (TWRP).
Durch diese Änderung verschieben sich aber die Startadressen aller folgenden Partitionen, inklusive system, cache und data. Und ihre Größen ändern sich eventuell auch.
Das macht "alte" MBR/EBR und Scatterdateien natürlich ungültig, weil dann die Werte nicht mehr stimmen!

 

[Toshy]

erit:
Bitte erst erst kurz hier schauen, falls etwas drann ist an der Sache, würde wären meine Verständnisprobleme Teils erklärt:
Nachtrag, bitte zu erst kurz schauen bezüglich meiner kurzen Frage Angelegenheit:
http://www.chinamobiles.org/threads/mt65-xx-modifikation-stock-rom-vergroessern-internen-telefonspeicher-durch-ebr-flash-sammlungen.40633/page-28#post-704391
Falls da was drann ist, würde es meine Verständnissprobleme zum größeren Teil erklären.


Vorab: Aktuell geht es mir um das Verständnis, auch wenn ich weiß, daß in zukünftigen Geräten der interner SD-Speicher und App speicher sich den Speicher dynamisch teilen, so kann man das auch dann noch für Android benötigen. Alleine schon um z.b. die Systempartition zu vergrößern, was auch gehen müßte. Daher lohnt sich das vielleicht auch noch für die nächsten Jahre zu wissen. Und Gebrauchtgeräte kann man so auf Schwung bringen.

Hallo ich möchte dir für deine ausfühlich Antwort danken. Ich wollte nur nicht unnütz anworten ohne das ich weiter bin. Ich hatte längere Zeit auf Ora gewartet.
Nun, damit sind einige Dinge klarer und haben noch etwas mehr geholfen, besonders im Zusammenspiel mit anderen Seiten. So z.b. rex-shen.net/understanding-mtks-mbrebr-file-format/
Dennoch sind noch fragen offen. Denn wer damit direkt noch wenig zu tun hat, den verwirrden Dinge. Vor allem weil ja auch manchmal fehler in Scatter (Stock, andere, ausgelesene ) sind und man dann nie sicher sein kann, ob der Fehler im Verständis oder Daten liegen. Ich vermute bei mir aktuell noch beides. (Ich versuche die Tage hoffentlich, falls Ora nicht dazu kommt, mir ein 16 gb ROM auf ein 32gb Rom zu ändern, für das ich keine Stockrom finde).

Vorläufige Nachfragen:

Noch habe ich schwierigkeiten ganz sicher die Positionsdaten der MBR/EBR zu berechnen. Die Absoluten Daten, halt für die Scatter und umgekehrt bzw. zur Kontrolle. Was auch noch ein einem kleinen Verständisproblem liegt oder mir hier fehlerhaft vorliegen Daten.

1. MBR/EBR: Dein Wert x80000 ist die Byteanzahl, sonst in der MBR liegen ja nur Sekoren vor. Ich vergleiche und berechne aktuell in einer Exceltabelle, auch zum Versehen. Erstes Problem wie man zu den Werten kommt. 512 Byte oder heute öfter 4k auf Festplatten sind normal je...Sektor.
a) Die Blockgröße gekommt man wohl nur aus dem Internet heraus, wenn man eine passende Scatterdatei findet ( oder diese ausliest, was bei einem ganz defektern Firmware wohl nicht mehr geht). Stimmt das? Nur aus den Dateien? Scheint wohl bei mir 128k zu sein.
b) die Blockgröße ist wohl eher für das Verständnis der Angelegenheit und falls man die Partitionsgrößen ändern ein sinnvolle Einheit an die man halt denken sollte (mehrfache von...). Siehe auch unter d)
c) Die Sektorengröße: Hier habe ich die größen Probleme. Diese benötige ich um die realten Partitionswerte heraus zu bekommen, nur woher kann ich diesen Wert sicher bekommen? Pauschal / Norm 512 Byte? Siehe auch d)
d) Die Blockgröße in der Scatter ist glaube ich bei allen die ich habe 0x20000 (131072 Byte). Lese ich mit adb shell df (nicht ganz passende Firmware vorher mit format geflash, vorher komplett format) aus, so erscheint dort meißt "Blksize 4096" bei fast allen partitionen, bei einigen "Blksize 32768". Das scheinen die interen sdcard zu sein bzw. deren verweise darauf. Wie finde ich nun raus was korrekte sectoren oder blockgrößen sind bzw. was sind das für Blksize aus der shell. irgendwie bin ich da doch verwirrt.

2. MBE/EBR: Wie bekomme ich die wirklichen Startadressen raus. Ich habe die aus der Scatter, also das die MBR auf 0x0 anfängt und eine länge von 0x80000.
a) die MBR müßte da ganz am Anfang kommen, also sollte man sich über die Startposition wenig gedanken machen. Aber wie kommt man zu dieser größe? ist die immer gleich? Die MBR-"Partition" ist ja nicht das gleiche wie die MBR (512 B) Wie man an diesen Wert heran kommt, was er bedeutet ist mir nicht klar. denn wenn es eine volle Blockgröße wäre, dann wäre es ja weniger.
b) es gibt eine Preloaderpartition 0x40000. Startet auch auf 0x0 ist aber wohl kleiner. Irgendwo laß ich die, was dort was "swap"t ;-) Aber so oder so wird da ja speicher Verbraucht. Was besonders dann wichtig ist, wenn man jetzt wie ich (oder allgemein) die Scatter und MBR so anpassen muß, das die "vergessenen" 16 gb wieder genutzt werden. Irgendwo muß die Partition psysikalisch liegen. Also wenn ich ein die gesammten 32 gb ausnutzen will (oder auch 16 gb), dann muß ich den vergrauch des preloader ja auch einberechnen. nur... wenn er auf dem selben bereich liegt, oder .... irgenwie... hmmm...
c) Relative Positionen in den MBR/EBR:
Kurz erstmal den Preloader weg gelassen, wenn ihr / du mir das noch kurz erklärt, wäre es super.
MBR-partion fängt auf 0x0 (0) an, hat dann die 524288 bype laut scatter als Größe. Die MBR selbst liegt ganz am Anfang und hat 512 Byte. Ds einzige was ich nun logisch oder sicher empfinden würde wäre, wenn die EBR dann anfängt bei
524288 byte (also NACH der MBR anfangen zu zählen) + 1024 (sektoren laut mbr) * Sektorengröße (evtuell wohl 512 Byte). Ist das so? Hast du zwar oben an sich geschrieben, nur zur sicherheit, wegen der folgenden Fragen.

3.
Zitat: "Dabei ist zu beachten, dass die Startadressen dort jeweils LBAs (logische Blockadressen, d.h. Sektornummern) sind, und immer relativ zum jeweiligen Boot Record.
Steht also z.B. im ersten Eintrag von EBR1 die Adresse 165888 (0x28800), und befindet sich die EBR1-Partition an der Adresse 524288 (0x80000), so muss sich die SYSTEM-Partition an Adresse 524288 + 512 * 165888 = 85458944 (0x5180000) befinden!
"
Ich fange mal von Vorne an, MBR-"Partion" bzw. MBR mit freiem Speicher danach von Byte 0 - 524288. bzw. wohl 524288-1
a) Jetzt steht in der MBR im ersten eintrag der EBR1 EIntrag mit Start 1024 (wohl Sektor) und ohne länge bzw. maximal. Ist wohl Konvention. Fämgt die EBR1 dann nun an Byte 1024 *512 (524288) +524288 an (also 1MB)? Oder nicht nach der MBR sondern 1024 Sektoren nach dem Beginn der MBR also 0 + 524288 was dann ja direkt das Folgebyte der MBR wäre. Oder 1024 sektoren nach dem Ende der letzten in der MBR genannten Partition?
b) Weiteres hängt natürlich von a) ab. Die letzte Partition der MBR endet bei 55 MB wenn ich das richtig sehe. Beginn wie ich oben frage mit BEGINN DER MBR gerechnet (also 0) oder eine der anderen Versionen. Das würde dann für mich bedeuten, das die EBR (mit dem Speicherbereich dazu) wohl noch vor der ersten in der MBR genannten Partion liegen würde, aber direkt nach der MBR. Richtig / Falsch / ???

4. So, ich gehe jetezt in die EBR1, wo auch immer sie liegt ;-)
a) Also wenn du das so schreibst, das die erste "EBR-Partiton" EBR-Start + Positon ist, ist das an sch verständlich. Gilt dann für die EBR2 das diese an EBR2-Startpos + Partionseintragposition beginnt? Oder alle folgenden EBR beziehen sich auf die EBR1?
b) Jetzt ein wenig das Problem, oder das große. Die Partitionen der EBR1 beziehen sich auf deren Startpositon, aber wo befindet sich nun die EBR1 genau. Wenn sie, wie ich auch wegen der Scatterreihenfolge vermute, nach der MBR beginnt und vor der ersten MBR-Partition, dann kann es da doch zu überscheidungen kommen. die Startposition der ersten EBR1-Partition muß also größer sein als das Ende der letzten MBR-Partition.
Allerdings, auch wenn die Scatter auf diese Reihenfolge hinweise (Reihenfolge Liste, nicht die WErte, die ich ja noch nicht absolut sicher verstehe). Dann muß man ja echt aufpassen, daß man da richtig rechnet und hin und her rechnen. Einfach wäere es ja, wenn die Bezugspunkte halt der Ende der letzten Partion aus der vorherigen MBR / EBR wären. Andererseit könnte man so dann die EBR hinpacken wie man will, so wie die Partitionen und die Bereiche umkopieren wie man will, ohne das man alles umkopieren muß. Nur... ich bin mir da halt noch nicht sicher.


So, mal schauen ob das irgend wann wer liest und beantwortet. Ich habe nur versucht es deutlich zu erklären.

Kurz zusammen gefaßt. Woher nimmt man die Sektorengrößen und gibt es da je Partition vielleicht unterschiedliche...Wie sollte man das denn dann noch in der MBR berechnen!!?? Und zur Sicherheit wie sind noch mal die Bezugspunkte der Verweise / EBR zu einander. Und was ist mit dem "Preloaderbeich" und dessen Speicher der ja doch irgendwie mit einbezogen werden muß wenn man den Speicher komplett verwendet, sonst fehlt zum Schluß was.

Danke und Gruß
Toshy

Nachtrag:
Was hat es mit dem BMTPOOL in Bezug auf die Positionen auf sich. In allen Scatterdateien die ich habe scheint sich meinem Verständnis nach der Speicherbereich zu überschneiden.
Auszug:
- partition_index: SYS18
partition_name: USRDATA
file_name: userdata.img
is_download: true
type: EXT4_IMG
linear_start_addr: 0x3f000000
physical_start_addr: 0x3f000000
partition_size: 0xfa000000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00

- partition_index: SYS19
partition_name: FAT
file_name: NONE,
is_download: false
type: EXT4_IMG
linear_start_addr: 0x139000000
physical_start_addr: 0x139000000
partition_size: 0x0
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: INVISIBLE
reserve: 0x00

- partition_index: SYS20
partition_name: BMTPOOL
file_name: NONE
is_download: false
type: NORMAL_ROM
linear_start_addr: 0xFFFF00a8
physical_start_addr: 0xFFFF00a8
partition_size: 0x1500000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: false
is_reserved: true
operation_type: RESERVED
reserve: 0x00

 

[Toshy]

Nachtrag, bitte zu erst kurz schauen bezüglich meiner kurzen Frage Angelegenheit:
http://www.chinamobiles.org/threads/mt65-xx-modifikation-stock-rom-vergroessern-internen-telefonspeicher-durch-ebr-flash-sammlungen.40633/page-28#post-704391

Falls da was drann ist, würde es meine Verständnissprobleme zum größeren Teil erklären.