P { margin-bottom: 0.21cm; }
Der Speicher selber ist ja nicht das Problem.
NAND ist aus den MTK Zeiten mehr als bekannt.
Das Problem ist das Dateisystem mit dem Android arbeitet.
Das ist noch nicht genügend erforscht.
Wenn ich mir die NAND Scatter anschaue ist das schon sehr komplex aufgebaut...
Es gibt 2 grundlegende Vorteile vom UBIFS.
Der erste ist: Es ist einfach sehr schnell.
Der zweite ist: Man braucht nicht wie bei ext4 ein, dem NAND vorgeschaltetes Verwaltungssystem des Speichers (EMMC) . Ähnlich wie bei YAFFS schreibt man direkt in den NAND.
Man kann UBIFS durchaus auslesen und in Linux einhängen. Das Problem ist das Rückschreiben auf das Handy. Hier muss man die Speicherverwaltung genau kennen. Ich habe von einem MT6572 (UBIFS) die system.img ausgelesen und konnte einzelne Dateien davon ohne Probleme kopieren und ändern.
Ich kann auch das Image einpacken und erhalte eine system.img.
Nur das Image funktioniert dann halt nicht im Phone. Komischerweise kann ich dann das geklonte Image auf meinem Linuxrechner auf dem gleichen Weg wie das originale Image auspacken.
Um ein Backup über „Recovery“ zu machen müsste der Kernel für dieses recovery.img UBIFS beherrschen.
Aus genannten Gründen wird ein Image für EMMC keinesfalls auf einem Handy mit UBIFS laufen. Es fehlt also die Hardware für die Speicherverwaltung.
Dagegen kann man raw- Images (nichts anderes macht Droid-Tools) eines UBIFS- Images problemlos auf das Handy zurück schreiben.
Alles was man braucht ist das raw-Image und das Wissen über den Adressbereich des Images.
Hier ist mal der Weg, ein UBIFS in Linux einzubinden.
Code:
mkdir /mnt/ubifs
modprobe ubifs
modprobe nandsim first_id_byte=0xec second_id_byte=0xd3 third_id_byte=0x51 fourth_id_byte=0x95
dd if=system.img of=/dev/mtd0 bs=512k
ubiattach -p /dev/mtd0 -O 2048
mount -t ubifs ubi0_0 /mnt/ubifs
cd /mnt/ubifs
ls
kawa