Problem beim Rooten mit MTK Droidtool...

[Ora]

Kannst Du bitte kurz beschreiben, mit welchem scatter und welchem preloader.bin Du es wieder zum Flashen überreden konntest?
Da Du ja vorher formatiert hast, wurde ja auch der MBR neu geschrieben.
Alles andere ist jetzt Routine. Die Bootschleife entsteht dann, wenn man usrdata nicht zurück setzt, also mit flasht.

 

[rzdz]

Scatterfile-Unterschiede:

Unterschiede rot markiert. (beide Scatterdateien und dumchar_info im Anhang)

Analyse:
Projektname: (irrelevant,von mir überprüft)
PRELOADER: filename: irrelevant, solange die in der Tabelle ausgewählte Datei im Ordner der Scatterdatei auch tatsächlich so heißt
MOBILE_INFO: operation_type: invisible <> update (noch durch die Spezialisten zu klären)
USRDATA: filename: irrelevant, solange die in der Tabelle ausgewählte Datei im Ordner der Scatterdatei auch tatsächlich so heißt
_operation_type: invisible <> update (noch durch die Spezialisten zu klären)
_partition_size: unterschiedlich (noch durch die Spezialisten zu klären)

(noch durch die Spezialisten zu klären):
partition_index: SYS21
_partition_name: RSV_OTP <> OTP
_physical_start_addr: 0xFEFF0200 <> 0xFFFF0200
_partition_size: 0x4000000 <> 0x2b00000
_boundary_check: true <> false
_is_reserved: false <> true
_operation_type: INVISIBLE <> RESERVED

(eine kurze Erklärung zu den unterschiedlichen Einträgen/Steruerflags in den Scatterfiles wäre sehr hilfreich, habe ich noch nirgends gefunden).

Wegen der unterschiedlichen Partitionsgröße habe ich die Partitionen ab USRDATA bei dem letzten (letztendlich lauffähigen) Versuch nicht mehr mit geflasht, um keine abgehackten oder überlappten Partitionen zu provozieren.

Welche von den restlichen Partitionen ab SYS20 müssen noch überflasht werden, wenn sie vorher formatiert wurden?
(Kennt jemand ein Übersicht, welche Daten überhaupt in den Partitionen liegen?


@Ora:
Wenn Du magst kannst Du ja auch hier schon mal reinschauen (aber mit deinem Chrome siehst Du die Bilder nicht, die sind aber wichtig). Habe dort gerade selbst nochmal gelesen, was da Sache war, und jetzt wird mir schon einiges klarer...

 

[N2k1]

Naja, wenn es derzeit wieder bootet, dann ist der Rest nur "Kleinkram", den wir hinbekommen werden.
Welche Partitionen das sind steht in der eMMC bzw. Dumchar_info
Formatieren und mounten ist dann auch kein Problem.
Auch die passenden Daten sollten sich aus dem ersten Backup rekonstruieren lassen.
Am Ende dann bitte für alle ein HowTo erstellen - und alle benötigten Teile einfügen, da das gerät ja scheinbar "bockig" ist.

 

[rzdz]

Das sehe ich auch so, und das "How To" erstelle ich sowieso (schon damit ich selbst nachsehen kann, falls es später nochmal Probleme geben sollte).

Habe meinen letzen Beitrag etwas ergänzt (Screenshot, Scatterdateien, Fragen an die Experten)

Kannst Du bitte kurz beschreiben, mit welchem scatter und welchem preloader.bin Du es wieder zum Flashen überreden konntest?

Nachdem mein eigenen Preloader (7041D), mit dem von Oras 7041X und einen 7041D aus dem Netz binär identisch war, habe ich meinen mit der Scatterdatei aus Oras ZIP geflasht. Daher muß meine Datei wohl OK sein. Es gab aber weitere 7041D-Varianten, davon abwichen, also Vorsicht mit Verallgemeinerungen. Es gibt auch noch 7040E die auf dem 7041D laufen sollen, überprüft habe ich das jedoch nicht.
Grundsätzlich habe ich jetzt nur eigene ausgelesene Dateien mit Hilfe und nach Inansichtnahme "deiner" Scatterdatei geflasht, beziehungsweise die von MKT-DTgepatchten eigenen Dateien, allerdings nur SYS0 bis SYS19.
Ab SYS20 ist noch alles so, wie es nach dem vermeintlichen Vollformatieren war. Dazu brauche ich jetzt noch die Info, welche der Partitionen abSYS20 noch geflasht werden müssen (oberflächlich gesehen läuft das Handy wieder).

Ich möchte Euch beide (und eventuell auch andere Experten) daher bitten, die Fragen oben letzten und diesem Beitrag (meist rot markiert) nochmals anzuschauen und ggf. zu beantworten, damit ich die Erkenntnisse auch in das "How To", das ich dazu schreiben möchte, noch einarbeiten kann.

PS:
Ich hänge hier mal in loser Reihenfolge angesammelte Infolinks an:

Info zur Scatterfile-Struktur:

What is a scatter-file?

partition_index: SYS1
partition_name: MBR
file_name: MBR
is_download: true
type: NORMAL_ROM
linear_start_addr: 0x0
physical_start_addr: 0x0
partition_size: 0x80000
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00, where (?)

- Partition_index - index number of the section, for example, SYS1;
- Partition_name - the name of the section, for example, MBR;
- File_name - name of the file containing the image of a partition, or NONE;
- Is_download - sign bootability partition (something like __NODL_);
- Type - the type of partition. It indicates the contents of the section. It can take the following values:

EXT4_IMG - section contains part of the file system EXT4;
NORMAL_ROM - section contains a saved image or a separate file;
SV5_BL_BIN - section contains the "raw code" (Raw Code), ie executable code;​

- Linear_start_addr - starting address of the accommodation section in the file firmware bytes;
- Physical_start_addr - starting address of the accommodation section in the device memory (physical address) bytes;
- Partition_size - partition size bytes;
- Region - accommodation section. It can take the following values:

EMMC_BOOT_1 -
EMMC_USER -​

- Storage - HW_STORAGE_EMMC
- Boundary_check - a sign of the need for the level of the interface (in the internal database or PMT);
- Is_reserved - a sign of the need for backup;
- Operation_type - the type of operation. It can take the following values:
BINREGION - Region "raw code";
BOOTLOADERS - loader;
INVISIBLE - invisible section;
PROTECTED - secure partition;
RESERVED - Reserved;
UPDATE - updated section.
- Reserve

EXAMPLE complete scatter-second version of the file, specified in the file "Scatter_v2.txt".

Working with the scatter file.
Any flasher uses only scatter file for the full markup memory.
If you sews one or more partitions, the placement of partitions takes the flasher from the internal "database" - File PMT (Partitions Map Table). He reads the offset value for the partition (physical address) and copies, ie. "Stitches" section of the image in memory, since this physical address.
Since scatter file contains a list of addresses and physical placement of all sections of memory, it can be changed to make this re-initialization of memory. To do this, you must change the offsets required sections.
For example, in the program data are located USRDATA user: logs operation and error data records games, etc. Therefore, this section is more likely to overflow, which leads to the appearance of messages like "Memory is full."
Typically it has a scatter file offset 0x34f80000 and size 0x74f80000-0x34f80000 = 0h40000000 (or 1GB = 1,073,741,824). Increase it, for example, 256MB (268,435,456). Then, the partition size will be = + 268435456 1073741824 1342177280 (or 0h50000000 in hex). Ie we added another section 0h10000000 bytes. Then, the offset of the next section will move by the same amount:
It was - 0h74f80000
It was - 0h84f80000
If you do so with a displacement of all subsequent sections, it will move all of them, and this value will increase the total size of the memory occupied by firmware. And this is unacceptable. Therefore, we must reduce the size of any subsequent section. We have a section of the user (FAT).
Change its size, we can not, because it is located to the end of the current memory. It just automatically shortened.
It would seem all but sections can be shortened to a certain limit (to "zero"). Therefore, if the offset of the last section passes the upper limit of memory, you have to roll back all the changes or decrease the size of the "gain" section.

Info zu MBR:

What is the MBR-file?

Introduction.
For the operating system (OS), you must create an allocation table of its parts. This table is stored in the MBR (Master Boot Record - Master Boot Record), which is physically located at the beginning of memory.
The MBR contains a partition table itself, the signature of the file (ie, a sign Boot Record) and executable code used by some operating systems to boot.

The structure of the MBR and EBR files.

MBR has a size of 512 bytes, i.e. One physical sector and has the following structure:

The structure of the master boot record (MBR)
------------------------------------------
Address Content
------------------------------------------
0000h Code loader
01BEh four partition table entries
01FEh 2-byte signature of the MBR (0h55AA)
------------------------------------------

Each partition table entry is 16 bytes long, and the contents depend on the operating system. For mobile devices, the recording format of the partition table is as follows:

The structure of the partition table entries
------------------------------------------
Offset Length Description
------------------------------------------
00h-03h 4 Not used (always 0x0)
04h 1 type code section
05h-07h 3 Not used (always 0x0)
08h 4 Offset section (in 512-byte sectors)
0Ch 4 The number of sectors in this section (section length)
------------------------------------------

Offset section is indicated by the first sector described this table memory. Ie If the field offset section is set to 0x400, and the table itself (MBR) is located in the memory starting from the address 0h00600000 (this is indicated in the scatter-file), this section will be physically located in memory address

0h00600000
+ 0h00080000 (0x400 * 0x200 = 0h00080000)
---------------
0h00680000

Type Code section describes its contents. Thus, if the section contains no information, i.e. empty, then the code is set to 0x00.
If more than 4 partitions in a MBR table, they do not fit, then start up an additional table - expansion. It's called EBR1 (Extended Boot Record). Code of this section 0h05. Codes are often used partitions in the table.
Section containing EBR1 has exactly the same structure, except that the executable code. If the number of partitions to fit in an extra table, one of the records will contain a description of the following table, which has the name of EBR2. And so on as needed.

Codes partition types
------------------------------------------
Code Type section
------------------------------------------
00h Blank post (free space)
01h FAT-12
05h Advanced section
0Bh FAT-32
----
82h Linux swap
83h Linux
----
EEh GPT
FFh BBT (Bad Block Table)
------------------------------------------


Working with the MBR and EBR files.
The files containing the table MBR and EBR, changes are made after adjusting the scatter-file. Knowing the size of the original and offset section, it can be found in the table BR.
Then, the new values of these parameters are transferred from the byte sector, dividing by 512 (0x200), and fit into the appropriate fields of the table.


Literature.
1.Master Boot Record. Master boot record - Wikipedia, the free encyclopedia

 

[rzdz]

Die Scatterdatei vom 7041X (Ora) würde grundsätzlich funktionieren, aber ab SYS20 / USRDATA sehe ich da das Problem, daß meine gesicherte Userdata.img mit 2,04GB nicht in die 1GB große Partition gemäß der 7041X-Scatterdatei reinpaßt:

- partition_index: SYS20
partition_name: USRDATA
file_name: userdata.img Größe meiner userdata.img 2,04MB (0x82C00000)
is_download: true
type: YAFFS_IMG
linear_start_addr: 0x65880000
physical_start_addr: 0x64880000
partition_size: 0x40000000 (in meiner Scatterdatei: 0x82C00000)
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00

- partition_index: SYS21
partition_name: OTP
file_name: NONE
is_download: false
type: NONE
linear_start_addr: 0xFFFF0200
physical_start_addr: 0xffff0200 (in meiner Scatterdatei: 0xFEFF0200)
partition_size: 0x2b00000 (in meiner Scatterdatei: 0x4000000)
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: false (in meiner Scatterdatei: true)
is_reserved: true (in meiner Scatterdatei: false)
operation_type: RESERVED (in meiner Scatterdatei: INVISIBLE)
reserve: 0x00

- partition_index: SYS22
partition_name: BMTPOOL
file_name: NONE
is_download: false
type: NONE
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

Der Rest, der dann "hinten übersteht", überschreibt dann vermutlich die Partitionen SYS21 und SYS20 (OTP + BMTPOOL).

Was bedeutet "type: NONE", " operation_type: RESERVED bzw. INVISIBLE"?
Wenn ich den Eintrag...

file_name: NONE
is_download: false

...richtig verstehe, werden diese Partitionen nicht gesichert und rückgesichert - ist das korrekt?
Demnach habe ich davon auch keine Sicherung, und kann mir nicht erlauben, die eventuell vorhandenen Daten zu überschreiben, oder?

 

[N2k1]

Ich will auch noch immer nicht glauben, daß es eine YAFFS Partition ist, da wir sie ja als ext4 ansprechen können.
Aber die Größe ist hier nur bedingt relevant, da danach ja Platz ist.

 

[rzdz]

Ich will auch noch immer nicht glauben, daß es eine YAFFS Partition ist, da wir sie ja als ext4 ansprechen können.

Ich gehe davon aus, daß es EXT4 ist und MKT DT hier einen Bug eingebaut hat, der YAFFS statt EXT4 reinschreibt.
Da im Netz Dutzende andere Alcatel C4 7041-Scatterdateien mit dem gleichen "Fehler" im Umlauf sind, wird das auf die Funktion beim Flashen wohl keinen Einfluß haben (in den alten Scatterdateien gab es den Eintrag "type" ja gar nicht, und es hat trotzdem geflasht).
Meine Flashversuche bis SYS19 haben ja offenbar auch funktioniert.

Aber die Größe ist hier nur bedingt relevant, da danach ja Platz ist.

Du meinst SYS21 und 22 (OTP + BMTPOOL) können ohne Probleme mit dem Rest von SYS20 überschrieben werden?
Welche Daten sind da überhaupt abgelegt?
Wenn das "Reserve" ist, wofür?

 

[rzdz]

Ich sehe hier gewisse Parallelen zu meinem Problem mit dem "hinten überstehenden" USRDATA und dem jetzt schon bestehenden Problem "PMT paßt nicht" vom SP Flashtool. Könnten man mit der Methode beide Probleme bereinigen (habe es noch nicht 100% verstanden)?

Optional könnte man ja vielleicht auch die Recovery-Partition auf 7 oder 8MB vergrößern, damit ein aktuelles TWRP reinpaßt (aber erst, wenn ich ein Stock-Backup mit funktionierendem Scatterfile habe)?

 

[Ora]

Zur Größenangabe in der Scatterdata von usrdata:

- partition_index: SYS20
partition_name: USRDATA
file_name: userdata.img Größe meiner userdata.img 2,04MB (0x82C00000)
is_download: true
type: YAFFS_IMG
linear_start_addr: 0x65880000
physical_start_addr: 0x64880000
partition_size: 0x40000000 (in meiner Scatterdatei: 0x82C00000)
region: EMMC_USER
storage: HW_STORAGE_EMMC
boundary_check: true
is_reserved: false
operation_type: UPDATE
reserve: 0x00

Diese Große bestimmt NICHT der Parameter partition_size.
oftmals findet man dort auch nur 0x0.
in der Version vor 1.1 gab es den auch nicht, und auch ein solches Scatter funktioniert auch.
zB. so:

RELOADER 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
{
}

da gibt es im wesentlichen nur die Startadresse und über __NODL_ wird gesteuert ob diese Partition geladen weird oder nicht.

Die Infos zur Größe stehen im MBR, EBR1 und EBR2 (deshalb ja auch die PMT Warnungen).
Das mach ich mir ja beim Resizing der Usrdata Partiton zu nutze.

Stelle mal das aktuelle Scatter, EBR1 und EBR2 und das Bild des MTK DT Mappings hier rein.

Es wird ja die FAT Partition gar nicht aufgeführt...

 

[rzdz]

Bitte sehr:

 

[Ora]

Nimm Dir Zeit... ich schau erst wieder später vorbei.

 

[rzdz]

Der Vollständigkeit halber hier noch die dumchar_info und Co.:

root@YARISXL:/ # cat proc/dumchar_info
cat proc/dumchar_info
Part_Name       Size                  StartAddr       Type    MapTo
preloader    0x0000000001000000   0x0000000000000000   2   /dev/misc-sd
mbr          0x0000000000080000   0x0000000000000000   2   /dev/block/mmcblk0
ebr1         0x0000000000080000   0x0000000000080000   2   /dev/block/mmcblk0p1
pro_info     0x0000000000300000   0x0000000000100000   2   /dev/block/mmcblk0
nvram        0x0000000000500000   0x0000000000400000   2   /dev/block/mmcblk0
protect_f    0x0000000000a00000   0x0000000000900000   2   /dev/block/mmcblk0p2
protect_s    0x0000000000a00000   0x0000000001300000   2   /dev/block/mmcblk0p3
seccfg       0x0000000000020000   0x0000000001d00000   2   /dev/block/mmcblk0
uboot        0x0000000000060000   0x0000000001d20000   2   /dev/block/mmcblk0
bootimg      0x0000000000600000   0x0000000001d80000   2   /dev/block/mmcblk0
recovery     0x0000000000600000   0x0000000002380000   2   /dev/block/mmcblk0
sec_ro       0x0000000000600000   0x0000000002980000   2   /dev/block/mmcblk0p4
misc         0x0000000000080000   0x0000000002f80000   2   /dev/block/mmcblk0
logo         0x0000000000300000   0x0000000003000000   2   /dev/block/mmcblk0
ebr2         0x0000000000080000   0x0000000003300000   2   /dev/block/mmcblk0
custpack     0x0000000026500000   0x0000000003380000   2   /dev/block/mmcblk0p5
mobile_info  0x0000000000800000   0x0000000029880000   2   /dev/block/mmcblk0p6
expdb        0x0000000000a00000   0x000000002a080000   2   /dev/block/mmcblk0
android      0x0000000026500000   0x000000002aa80000   2   /dev/block/mmcblk0p7
cache        0x0000000013900000   0x0000000050f80000   2   /dev/block/mmcblk0p8
usrdata      0x0000000082c00000   0x0000000064880000   2   /dev/block/mmcblk0p9
otp          0x0000000004000000   0x00000000feff0200   2   /dev/block/mmcblk0
bmtpool      0x0000000001500000   0x00000000feff00a8   2   /dev/block/mmcblk0
Part_Name:Partition name you should open;
Size:size of partition
StartAddr:Start Address of partition;
Type:Type of partition(MTD=1,EMMC=2)
MapTo:actual device you operate
root@YARISXL:/ #
---------------------------------------------------------------------------------------------------------
shell@YARISXL:/ $ cat /proc/emmc
cat /proc/emmc
partno:  start_sect  nr_sects  partition_name
emmc_p1: 00000400 00000002 "ebr1"
emmc_p2: 00004800 00005000 "protect_f"
emmc_p3: 00009800 00005000 "protect_s"
emmc_p4: 00014c00 00003000 "sec_ro"
emmc_p5: 00019c00 00132800 "custpack"
emmc_p6: 0014c400 00004000 "mobile_info"
emmc_p7: 00155400 00132800 "android"
emmc_p8: 00287c00 0009c800 "cache"
emmc_p9: 00324400 00416000 "usrdata"

---------------------------------------------------------------------------------------------------------

shell@YARISXL:/ $ shell cat /proc/mtd
shell cat /proc/mtd
/system/bin/sh: shell: not found

---------------------------------------------------------------------------------------------------------

shell@YARISXL:/ $ cat /proc/partitions
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

Den Unterschied linear_start_adr und physical_start_adr im Scatterfile habe ich noch nicht verstanden (in den alten Scatterfiles gab es nur eine Startadresse pro Block).
Kannst Du es mir bitte erklären?

 

[Ora]

Kannst Du es mir bitte erklären?

Nein, aber es zählen nur die physikalischen...
- Fragen:
Du bekommst jetzt keine PMT Warnung beim Flashen mehr?
Wie groß wird der eMMC Speicher den angegeben?
Im Moment hat Du ja nur einen 2,04 GB großen Data Bereich... stimmt dass?
Der Eintrag im EBR2 korrespondiert damit nicht, der sagt einen viel kleineren Bereich voraus... (642.777.088 Byte)

 

[rzdz]

Du bekommst jetzt keine PMT Warnung beim Flashen mehr?

Alles unterhalb der USRDATA (SYS0-19) gingen mit deiner 7041X-Scatterdatei meine alten Sicherungsdateien ohne Fehlermeldung zurück zu flashen.
Ab SYS20 (USRDATA) habe ich es mit der 7041X_Scatterdatei noch nicht versucht, da ich eine Überlappung der anschließenden Bereiche und damit eventuell Datenverlust befürchte.
Mit meiner Scatterdatei bekomme nach wie vor beim Versuch irgend eine Partition zu flashen die PMT-Warnung (getestet auch mit der Old-Style-Scatterdatei mit meinen Anfangsadressen).

Der Bereich USRDATA ließ sich also nicht neu flashen und ist demnach entweder immer noch auf dem Stand "versehentlich mitformatiert" oder sogar noch im Zustand davor, was ich aber nicht überprüfen kann.

Wie kann ich diese SYS21+22-Bereiche (OTP+BMTPOOL) jetzt sichern, bevor ich die USRDATA mit der 4071X-Scatter versuche zu flashen?
Ich habe zwar noch die erste ROM_0-Datei mit 3.62MB Größe, die aber beim Weiterverarbeiten mit MTK DT nur bis inkl. USDATA in einzelne Images zerteilt wurde. Die Bereiche OTP und BMTPOOL (also oberhalb 0x65880000+0x82C00000=0xE8480000 = 3,62MB) wurden damals nicht ausgelesen und demnach auch keine Image-Dateien erzeugt. Die USRDATA.IMG hat auch bis ca. 0x79000000 Daten <>0x00, und ich habe euch schon Scatterdateien gesehen, die eine Partitionslänge von etwa 0x79000000 auswiesen.

Im Moment hat Du ja nur einen 2,04 GB großen Data Bereich... stimmt dass?

Zumindest ist die USRDATA.IMG so groß, und die in meinem Scatterfile angegebene Partitionsgröße auch (ohne daß ich etwas geändert hätte).

Wie groß wird der eMMC Speicher den angegeben?

Wie bekomme ich das zweifelsfrei angezeigt?
Prospekt-Angabe: 4GB Flash, 2GB interne SD (von den 4GB oder zusätzlich?), 1,7GB frei (im Telefonspeicher oder auf der "internen SD").

Per USB stellt sich das auf dem PC so dar:

wobei die 8GB-SD-Karte die zusätzlich eingesteckte ist, auf der momentan die ganzen Recovery-Backups und anderes Gerödel liegen.

Per ADB sehe ich das hier:

root@YARISXL:/ # free
free
             total         used         free       shared      buffers
Mem:        475060       403204        71856            0        24848
-/+ buffers:             378356        96704
Swap:       393212        50288       342924
root@YARISXL:/ # df
df
Filesystem             Size   Used   Free   Blksize
/dev                   231M    68K   231M   4096
/mnt/secure            231M     0K   231M   4096
/mnt/asec              231M     0K   231M   4096
/mnt/obb               231M     0K   231M   4096
/system                603M   399M   204M   4096
/custpack              603M   578M    25M   4096
/data                    2G   251M     1G   4096
/cache                 307M     5M   301M   4096
/protect_f               8M     4M     4M   4096
/protect_s               8M     4M     4M   4096
/mnt/cd-rom              1M     1M     0K   2048
/mobile_info             7M     4M     3M   4096
/data/nvram/md/s         5M     4M     1M   4096
/storage/sdcard1         1G   251M     1G   4096
/storage/sdcard0         7G     6G   530M   32768
/mnt/secure/asec         7G     6G   530M   32768
root@YARISXL:/ #

Nein, aber es zählen nur die physikalischen...

Kann es sein, daß Du die "linearen Adressen" meinst?
Weil Preloader und MBR haben beide physical_start_adr 0x00 in der Scatterdatei stehen, und das kann ja eigentlich nicht sein.

Die physical_start_adr kann auch kein (vom mir zuerst vermuteter) Offset der Daten vom Anfang der jeweiligen Partition sein, dann wäre das folgende Beispiel EBR2 Unsinn...

partition_name: EBR2
file_name: EBR2
is_download: true
type: NORMAL_ROM
linear_start_addr: 0x4300000
physical_start_addr: 0x3300000
partition_size: 0x80000

...denn 0x43000000(Partitionsanfang)+0x3300000(vermuteter Offset)=0x7600000, und das liegt weit oberhalb der oberen Partitionsgrenze von
0x4300000(Partitionsanfang)+0x80000(Partitionslänge)=0x4380000(Partitionsende)

Es bleibt rätselhaft...

Ich hoffe nur, daß in den beiden Bereichen keine Hardware-Kalibrationswerte liegen...

 

[Ora]

bevor ich die USRDATA mit der 4071X-Scatter versuche zu flashen?

-- ist mir ehrlich gesagt zu kompliziert
-- wenn es mit der 4071X-Scatter ohne PMT Warnung geht, ist das ein Zeichen, das er nicht auf Widersprüche stößt, egal ob Du eine oder alles flashst.
-- für mich zeigt aber die Analyse der EBR's das aktuell etwas nicht stimmt, und auch deshalb die PMT Meldung kommt.
-- ich würde an Deiner Stelle dieses Problem mit einem "Firmware upgrade" und richtigen EBR's lösen.

DU hast ein 4 GB ROM!
3,69677734375 GB sind verteilt der Rest wäre ein Fat- Bereich, den ich nicht sehe.
Auf alle Fälle ist der EBR1 falsch, den EBR2 muss ich erst noch analysieren.

... Und wenn Du Bammel hast, dann flashe doch mit einem Dummy usrdata.img (ich nehme immer das secro.bin dafür)

Anbei die auf Dein aktuelles Blockmapping (Deine Scatter) angepassten EBR1 und EBR2 Dateien.

Also ich würde

• mit DEINEM Satter
• mit den angepassten EBR1 und EBR2
• und der Option "Firmware Upgrade"

einen Flash versuchen.

 

[N2k1]

für mich zeigt aber die Analyse der EBR's das aktuell etwas nicht stimmt, und auch deshalb die PMT Meldung kommt.
-- ich würde an Deiner Stelle dieses Problem mit einem "Firmware upgrade" und richtigen EBR's lösen.

Richtige EBR - oder zu diesen EBR passende Scatter .. kann man drehen wie man will.
Da kann das MTK DT aber nichts dafür, da es aus der Dumchar_info (bzw, eMMC) die falschenDaten erhält.

der Rest wäre ein Fat- Bereich, den ich nicht sehe.

Der wird als YAFFS in der Scatter angegeben - war aber (wenn ich mich richtig erinnere) ext4 formatiert.

 

[rzdz]

Danke für Eure Antworten.
"Firmware Upgrade" damit die MBR korrigiert wird?
Ja, EXT4 ist in einigen Bereichen wohl richtig, siehe Blockinfo

 

[Ora]

EBR's und MBR....

 

[N2k1]

Wie kann ich diese SYS21+22-Bereiche (OTP+BMTPOOL) jetzt sichern, b

Unnötig. OTP = Tabelle der als schlecht markierten Blöcke (wird bei einem Format erneuert - aber auch bei mehrmaligem fehlerhaften Zugriff)
BMTPool = Nach dort wird verlinkt, wenn man auf einen als schlecht markierten Data-Block (im eMMC) zugreift.
Jeder Flash-Speicher hat Fehler!
Der Eine mehr, der Andere weniger. Aber bis zu einer bestimmten Anzahl ist das alles OK (wie auch bei Festplatten)

2GB interne SD (von den 4GB oder zusätzlich?),

Von den 4 GB.

Weil Preloader und MBR haben beide physical_start_adr 0x00 in der Scatterdatei stehen, und das kann ja eigentlich nicht sein.

Sind "switchbare Bereiche" - die sehen einander nie.

Die physical_start_adr kann auch kein (vom mir zuerst vermuteter) Offset der Daten vom Anfang der jeweiligen Partition sein, dann wäre das folgende Beispiel EBR2 Unsinn..

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

 

[rzdz]

EBR's und MBR....

Das heißt, die eben geflashten EBRs und MBR werden dann sowieso korrigiert?
Spielt dann die Länge vom USRDATA keine Rolle?
Wozu ein Dummy, würde der dann automatisch neu erstellt? Oder nur als Platzhalter?

- ich würde an Deiner Stelle dieses Problem mit einem "Firmware upgrade" und richtigen EBR's lösen.

... Und wenn Du Bammel hast, dann flashe doch mit einem Dummy usrdata.img (ich nehme immer das secro.bin dafür)

Anbei die auf Dein aktuelles Blockmapping (Deine Scatter) angepassten EBR1 und EBR2 Dateien.

Also ich würde

• mit DEINEM Satter
• mit den angepassten EBR1 und EBR2
• und der Option "Firmware Upgrade"

einen Flash versuchen.

Eben genauso gemacht: Invalid ROM or PMT Adress (anderer Fehler)

Auf alle Fälle ist der EBR1 falsch, den EBR2 muss ich erst noch analysieren.

Ist der EBR2 in Deinen ZIP nicht fertig? Verändert hast Du jedenfalls ein paar Byte.

Danke für die Erläuterungen N2k1!

Wenn ich am Ende des Speichers nichts wichtiges überschreiben kann, dann kann ich doch mit meiner Scatterdatei meine Backupdateien und den EBRs+MBR von ORA ein Firmwareupgrade versuche (also nicht den Dummy sondern USRDATA-Original benutzen)?
Preloader mitgeflasht.
Eben gemacht: PMT changed, must be downloaded (=alter Fehler)