NAND-Flash(-Chip) umpartitionieren

[JonasOS]

Bernd bei CM bin ich hier, ja ich gebe es zu!
Gerade weil ich es NICHT anfangs verstanden habe!
Meine Hilfe habe ich MEHR als EINMAL dem Forum zu gute kommen lassen!
ALLERDINGS finde ich es persönlich mehr als nur SCHLECHT einfach NUR das Ergebnis zu posten oder wie DU zu FORDERN!
JEDER der so eine sehr fortgeschrittene Modifikation vornimmt sollte das AUCH verstanden haben!

Du hasst alles verstanden?
JA?
Dann bitte keine PNs wegen *heulmein997DgehtNICHT!*

Das Datum zur Eröffnung des Threads hier und auf CM hast Du gesehen? Freu Dich das immerhin ich für die Community versuche nen CUSTPACK freies ROM hinzubekommen! Oder mach es einfach BESSER! Ich jedenfalls konnte noch keine Thread hier auf AH oder XDA sehen von Dir sehen, der auch nur irgendetwas nützliches BEITRÄGT!

 

[BinkaDroid]

Also, ich habe meinen Beitrag hier eingestellt, weil ernie34 am 13.11. (also ganz aktuell) Probleme mit dem Bearbeiten der EBR1.BIN hatte.

Ich habe nicht einfach ein Ergebnis gepostet, sondern schon kleinschrittig erklärt, wie ich den zu ändernden Wert berechnet habe.

Seitdem pflaumst Du mich die ganze Zeit an, und behandelst mich von oben herab wie den letzten Vollpfosten. Ich habe keine Ahnung, warum Du so persönlich und ausfallend wirst.

So, nun noch mal ganz klar und deutlich: Meine Änderungen habe ich nicht geistig umnachtet gemacht, sondern unter folgenden Annahmen:

a) Die interne SD-Karte wird weder von mir, noch vom OS selbst mit irgendwas gefüttert
b) Meine USERDATA-Partition ist nach meiner Änderung 900MB größer
c) Die Größe der internen SD-Karte wird nach dem Formatieren falsch angezeigt (1GB)
d) c) kann ich ignorieren, da diese Partition eben gar nicht benutzt wird
e) die 900MB habe ich genommen, weil ich eben zu doof bin, die FAT-Partition (interne SD) komplett zu entfernen
f) e) ist also ein Kompromiss, bei dem die interne SD zwar dableibt, ich aber trotzdem einen Großteil deren Speicher für mich nutzen kann

So, um das ganze mal zu verifizieren, habe ich meine USERDATA mit Dummie-Dateien vollgestopft (damit eben mal die zusätzlichen 900MB genutzt werden).
Es ist dadurch keinerlei Fehler aufgetreten, die USERDATA wurde ganz normal genutzt, und es bluteten keinerlei Daten hinüber in die interne SD-Karte (wie zunächst von mir befürchtet).

Hab das ganze mal hier auf dem Screenshot verdeutlicht.

 

[ernie34]

Diesen Tonfall kann ich auch beim besten Willen nicht nachvollziehen. Da gebe ich BinkaDroid absolut Recht.

 

[simtel]

Hallo,

ich komme nicht weiter.
Vielleicht kann mir ja jemand behilflich sein, meine Fehler zu finden.

Ziel ist die interne Fat los zu werden.

Also die neue usrdata ist dann: usrdata 59200000 h + fat 417c0000 h
= 9a9c0000 h groß. Daraus ergibt sich für die neue usrdata eine Größe von 2473,75Mb.


Soweit zu meiner Überlegung.

Wenn ich mir jetzt die Sektoren ausrechne kommt es zu den ersten Fehlern.
(Bytesize geteilt durch 512 in dezimal oder in Hex Bytesize geteilt durch 200)

Für usrdata komme ich auf 2920448 Sektoren = in Hex 2c9000 = in MB 1426

Für fat 2145792 Sektoren = in Hex 20be00 = in MB 1047,75

Im Hexeditor würde ich also als neue Größe 004e4d00 (4D4E00 ) eintragen.


Im Hexeditor finde ich aber eine Sektorenanzahl von 2c8800 das entspricht einer Größe von1425 Mb für die userdata.

]Ich verrechne mich also um 1MB[/COLOR].

Was ich aber überhaupt nicht Verstehe ist folgender Umstand:
Laut der Scatterdatei


Startadresse usedata: 0x4a860000
Fat 0xa3a60000
OTP 0xffff0200

Die Fat würde demnach ja eine Größe von 5C590200 haben, also 1477,56298828125 MB.
Mit meinen Zahlen müsste OTP bei 0x E5220000 beginnen, ein Unterschied von 429,81298828125 MB.
Auf dem Screenshot in der Deutschen Anleitung passen die Zahlen zusammen, da dort die Fat tatsächlich mit einer Größe von 5c590200 bzw 1549937088 bytesize angegeben wird.

Die Scatter erhalte ich mit den MTK tool v 2.48.

Wenn ich dann ein Backup starte erhalte ich diese Fehlermeldung:

17/11/13 07:09:27 - PMT tables found
17/11/13 07:09:27 - PMT tables OK, 23 blocks found
17/11/13 07:09:27 --- Kernel Block Map to PMT mismatch!
17/11/13 07:09:27 -------------------------------------------
17/11/13 07:09:27 BlockName Offset
17/11/13 07:09:27 -------------------------------------------
17/11/13 07:09:27 Kernel: __NODL_FAT 0x00000000A3A60000
17/11/13 07:09:27 PMT: FAT
17/11/13 07:09:27 Kernel: __NODL_BMTPOOL 0x00000000FFFF00A8
17/11/13 07:09:27 PMT: Not present! ??????????
17/11/13 07:09:27 -------------------------------------------


Das Backup läuft dann bis hier:

17/11/13 07:36:56 - ERROR : /dev/otp: read error: Invalid argument
17/11/13 07:41:35 --- task end with ERROR ---



Im Log findet sich :
.......

17/11/13 07:07:16 usrdata 0x0000000059200000 0x0000000049960000 2 /dev/block/mmcblk0p7
17/11/13 07:07:16 fat 0x00000000417c0000 0x00000000a2b60000 2 /dev/block/mmcblk0p8
17/11/13 07:07:16 otp 0x0000000004000000 0x00000000ff0f0200 2 /dev/block/mmcblk0
17/11/13 07:07:16 bmtpool 0x0000000001500000 0x00000000ff0f00a8 2 /dev/block/mmcblk0
17/11/13 07:07:16 Part_Nameartition name you should open;
17/11/13 07:07:16 Size:size of partition
17/11/13 07:07:16 StartAddr:Start Address of partition;
17/11/13 07:07:16 Type:Type of partition(MTD=1,EMMC=2)
17/11/13 07:07:16 MapTo:actual device you operate


Die size der OTP ist bei mir 0x0000000004000000 In der deutschen Anleitung: 0xffffffffe87efe00


Also falls jemand noch mitliest und sich darauf einen Reim machen kann….

Über Hinweise die mich aus dem Nebel führen, würde ich mich freuen..

 

[simtel]

Hier ist eine Antwort,
die den Kernel Block Map to PMT mismatch betrifft.