Změna velikosti diskových oddílů na MTK6577 telefonu

1.11.2013 03:29 | Přečteno: 2748× | Postřehy linuxáka | | poslední úprava: 1.11.2013 04:09

Tento zápisek popisuje moji zkušenost s hackováním velikosti diskových oddílů na jednom telefonu s Androidem, hlavně pro mně jako reference a možná se hodí i někomu jinému.

Úvod

Někde v temných uličkách a zákoutích internetu jsem si pořídil telefon Inhon G1 (lokální společnost, nenašel jsem anglickou verzi stránek), který je rozměry rozumně malý a výkonem dostatečný (4GB eMMC, 1GB RAM, 1GHz dvoujádro). Provozoval jsem na tom nějakou navigaci, poslouchal nějaké podcastí kecy a četl články (RSS + download, abych nemusel být stále připojen k netu).

Problém

I když jsem k tomu ale přidal paměťovou kartu, projevila se jedna drobná chybička, a to nedostatek paměti. On ten telefon má v základu pro uživatele dva oddíly: jeden ext4 "neviditelný", na který se ukládají aplikace a jejich data, druhý FAT, na který vidí/píšou aplikace ve skupinách sd_read a sd_write.

Pokud člověk přidá paměťovou kartu, sice na ni může ukládat uživatelská data, ale aplikace jako třeba ten Sygic, Google mapy nebo PodKicker pro ukládání dat nadále zvolí interní FAT nebo ext4 a místo tak lehce dojde, nehledě na to, že aplikace jde instalovat jenom na ext4.

Idea

Existují sice obezličky jako Link2SD, ale já jsem chtěl poznat, jak to vlastně přesně v tom telefonu vypadá a vůbec, když potřebuji víc místa na jednom diskovém oddílu, tak ho taky prostě zvětším a netvořím nějaké divoké symlinky z ext4 na FAT oddíl.

Můj plán byl následující: původní ext4 má něco přes 500MB, interní FAT něco přes 1GB (zbytek do 4GB jsou další skryté oddíly, o tom později), paměťovou kartu přímo využívá jenom foťák. Co kdybych spojil FAT a ext4 do jednoho ext4 a kartu používal způsobem, na který byl původně navržený interní FAT oddíl? Kartu neplánuji vyměňovat, zjednoduší se USB mass storage, které normálně ukáže buď jenom interní FAT nebo jenom SD kartu a budu mít kopec místa: 1.5GB na aplikace a 16GB na SD kartě na data.

Postup

Na tyto divokosti je potřeba root oprávnění, ty lze získat nahráním nějakého update.zip na paměťovou kartu a pak jej flashnout přes recovery mode (dostupné tak, že se při startu telefonu drží tlačítko pro přidání hlasitosti). Výchozí recovery ale kontroluje digitální podpisy a privátní klíč Inhonu bohužel nemám, ale dá se to obejít i tak, že se pomocí MediaTek flash tool nahraje jiný rescue mód (Taiwan ROM factory jeden takový založený na tuším Clockworkmodu přímo pro tento telefon má) a pak si můžu dělat co chci. Ten tool je sice jenom pro Windows, ale což, aspoň VirtualBox nezleniví (co jsem opustil jistý jablečný produkt, tak jsem se bál, že už jej nebudu potřebovat).

Změna diskových oddílů

Když nastartujeme telefon do recovery režimu, pustíme adb shell a v něm fdisk, dosteneme něco, co mě napoprvé docela vyděsilo:

Disk /dev/block/mmcblk0: 3883 MB, 3883008000 bytes
1 heads, 16 sectors/track, 474000 cylinders
Units = cylinders of 16 * 512 = 8192 bytes

              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk0p1               3           2  2147483647+  5 Extended
Partition 1 does not end on cylinder boundary
/dev/block/mmcblk0p2            2757        3396        5120  83 Linux
Partition 2 does not end on cylinder boundary
/dev/block/mmcblk0p3            4213       87284      664576  83 Linux
Partition 3 does not end on cylinder boundary
/dev/block/mmcblk0p4           87413      152948      524288  83 Linux
Partition 4 does not end on cylinder boundary
/dev/block/mmcblk0p5          153077      218612      524288  83 Linux

Nemám tušení, proč nejsou oddíly zarovnané na cylindry, proč jsou mezi nimi mezery nebo proč není v tabulce oddílů /dev/block/mmcblk0p6 (který je ale v /dev filesystému a je autodetekován přes vold jak by člověk očekával). Pokud tomu někdo rozumíte, napište do diskuze prosím Moje pracovní teorie je, že emulované cylindry nejsou platné a tudíž si výrobce mohl dovolit to zarovnat jinak a fdisk z busyboxu tomu nerozumí.

Druhá zajímavost je umístění rozšířeného oddílu hned na začátek a nastavení velikosti na -1, aby reprezentoval celou eMMC nehledě na její velikost. Pokud to někdo někde viděl, taky se podělte.

Každopádně, trochu jsem si s tím pohrál (mezi původním p2 a p3 jsou podle scatter.txt nějaké asi důležité data a tak jsem zachoval počátek systémového oddílu a pozici sec_ro -- pravděpodobně něco kvůli DRM nebo jinému šifrování) a tady se můžeme pokochat výsledkem:

Disk /dev/block/mmcblk0: 3883 MB, 3883008000 bytes
1 heads, 16 sectors/track, 474000 cylinders
Units = cylinders of 16 * 512 = 8192 bytes

              Device Boot      Start         End      Blocks  Id System
/dev/block/mmcblk0p1            2757        3396        5120  83 Linux
/dev/block/mmcblk0p2            4213       65536      490592  83 Linux
/dev/block/mmcblk0p3           65537       98304      262144  83 Linux
/dev/block/mmcblk0p4           98305      474000     3005568  83 Linux

Nastavení vold

Výchozí nastavení vold počítá se dvěma SD kartami (jedna emulovaná 1.5GB a druhá opravdová), kdy ta první je neplatná a druhá bude nově primární, tak potřebujeme změnit /etc/vold.fstab. Původní nastavení je

dev_mount sdcard /storage/sdcard0 emmc@fat /devices/platform/goldfish_mmc.0 /devices/platform/mtk-sd.0/mmc_host
dev_mount sdcard2 /storage/sdcard1 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-sd.1/mmc_host

a nově jenom

dev_mount sdcard /storage/sdcard0 auto /devices/platform/goldfish_mmc.1 /devices/platform/mtk-sd.1/mmc_host

Úprava jádra

Zdrojáky k jádru bohužel výrobce přímo neposkytuje (a to, co poskytují ostatní, jestli vůbec, je často neúplné a nejde přímo zkompilovat), tak si jádro upravíme svépomocí. Někde v jádru je tabulka, podle které se spojitou paměť eMMC mapuje na jednotlivé celky (jako třeba nvram, sec_ro, logo, ..., ale taky diskové oddíly, i když v tomto případě je ta informace zdvojená s údaji uvedenými v MBR), některé z těchto celků skončí v /dev/block/mmcblk0* a na některé z nich se vytvoří symlink v /, konkrétně vypadají takto:

shell@android:/ # ls -l /emmc*
lrwxrwxrwx root     root     1970-01-01 08:00 emmc@android -> /dev/block/mmcblk0p3
lrwxrwxrwx root     root     1970-01-01 08:00 emmc@cache -> /dev/block/mmcblk0p4
lrwxrwxrwx root     root     1970-01-01 08:00 emmc@fat -> /dev/block/mmcblk0p6
lrwxrwxrwx root     root     1970-01-01 08:00 emmc@sec_ro -> /dev/block/mmcblk0p2
lrwxrwxrwx root     root     1970-01-01 08:00 emmc@usrdata -> /dev/block/mmcblk0p5

Ale když jsme si už změnili rozdělení disku, tak tyto symlinky nebudou platné. Podobná tabulka v jiném případě vypadá takto (odsud a odsud):

struct excel_info PartInfoEmmc[PART_NUM]={
                        {"preloader",262144,0x0,0},
                        {"dsp_bl",1966080,0x40000,0},
                        {"mbr",16384,0x220000,0},
                        {"ebr1",376832,0x224000,1},
                           ...
                        {"android",537919488,0x2004000,6},
                        {"cache",537919488,0x22104000,2},
                        {"usrdata",537919488,0x42204000,3},
                        {"fat",0,0x62304000,4},
                        {"bmtpool",10485760,0xFFFF0050,0},
 };

V této struktuře si jádro pamatuje název bloku, velikost, adresu prvního bajtu a poslední číslo je buď nula (nevytvoří symlink) nebo číslo oddílu (podle fdisku), kam symlink povede.

Rozhodl jsem se najít v obrazu jádra binární reprezentaci této struktury (nebo podobné, zrojáky mám přeci jenom pro podobný model od jiného výrobce) a těch pár čísel upravit ručně v hexeditoru. Ale než se dostaneme k tomu, musíme jádro trochu zpracovat.

Rozbalení obrazu

Obraz jádra je ve formátu pro uboot, tj. hlavička popisující zařízení a případné parametry jádra, pak jádro a initrd s initskripty a nejnutnějšími binárkami. Jelikož je tento formát relativně hojně používaný, existuje skript split_bootimg.pl na jeho rozsekání na jednotlivé kousky. Tak se do toho rovnou pustíme:

jan@bolt $ ./split_bootimg.pl boot.img
Page size: 2048 (0x00000800)
Kernel size: 3347584 (0x00331480)
Ramdisk size: 598759 (0x000922e7)
Second size: 0 (0x00000000)
Board name: 20130830
Command line: 
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.

Samotný kernel i ramdisk pak (v mém případě, podle různých tutoriálů usuzuji, že to není pravda na všech zařízeních) začíná 512-bajtovou hlavičkou popisující věci jako třeba identifikátor (KERNEL nebo ROOTFS) a velikost, tak ji oddělíme:

mv boot.img-ramdisk.gz boot.img-ramdisk
dd if=boot.img-ramdisk of=boot.img-ramdisk.hdr bs=512 count=1
dd if=boot.img-ramdisk of=boot.img-ramdisk.gz bs=512 skip=1
dd if=boot.img-kernel of=kernel.hdr bs=512 count=1
dd if=boot.img-kernel of=kernel bs=512 skip=1

Kernel ale budeme muset dál rozpitvávat. To, co jsme totiž získali v kernel, je totiž jenom krátký kód pro gunzip. Ten je 18404 bajtů dlouhý (zjistíme třeba vyhledáním identifikačních čísel podle specifikace gzip, tj. bajtů 0x1f a 0x8b).

kernel_size=`stat -c %s kernel`
unpacker_head=18404

dd if=kernel of=kernel-aaa bs=$unpacker_head count=1
dd if=kernel of=kernel-payload.0 bs=$unpacker_head skip=1

Pak na konci (tj. za zkomprimovaným obrazem jádra) leží ještě nějakých 56 bajtů jiných dat, které si taky pro přehlednost oddělíme (velikost určíme automaticky srovnáním s rezipem):

gunzip < kernel-payload.0 > kernel-unpack
gzip -9 < kernel-unpack > kernel-rezip.0

unpacker_tail=$(( `stat -c %s kernel-payload.0` - `stat -c %s kernel-rezip.0` ))
rm kernel-rezip.0

payload_size=$(( $kernel_size - $unpacker_head - $unpacker_tail ))

dd if=kernel-payload.0 of=kernel-zzz bs=$payload_size skip=1
dd if=kernel-payload.0 of=kernel-payload bs=$payload_size count=1
rm kernel-payload.0

Teď si konečně můžeme hrát s jádrem, jak ho gcc stvořil. Nejdřív najdeme tabulku těchto bloků eMMC -- to bohužel nejde podle textových identifikátorů, protože ty jsou uložené jinde a v tabulce bude jenom pointer na ně. Ale naštěstí ze scatter souboru nebo z fdisku víme hned několik čísel, které se v ní vyskytují: třeba android oddíl je na 0x026e8000, /cache na 0x2b0e8000, pracovní ext4 na 0x4b1e8000 a uživatelská FAT na 0x6b2e8000 a tak po chvilce hledání v hexeditoru dostaneme něco velmi, velmi slibného:

jan@bolt $ hexdump -C kernel-unpack | grep -B5 -A5 '00 80 1e 4b'
0067e9c0  00 80 6e 02 00 00 00 00  01 00 00 00 03 00 00 00  |..n.............|
0067e9d0  00 00 00 00 00 00 00 00  28 cb 5a c0 00 00 00 00  |........(.Z.....|
0067e9e0  00 00 10 20 00 00 00 00  00 80 0e 2b 00 00 00 00  |... .......+....|
0067e9f0  01 00 00 00 04 00 00 00  00 00 00 00 00 00 00 00  |................|
0067ea00  70 51 5c c0 00 00 00 00  00 00 10 20 00 00 00 00  |pQ\........ ....|
0067ea10  00 80 1e 4b 00 00 00 00  01 00 00 00 05 00 00 00  |...K............|
0067ea20  00 00 00 00 00 00 00 00  cc 50 5c c0 00 00 00 00  |.........P\.....|
0067ea30  00 00 00 00 00 00 00 00  00 80 2e 6b 00 00 00 00  |...........k....|
0067ea40  01 00 00 00 06 00 00 00  00 00 00 00 00 00 00 00  |................|
0067ea50  d4 50 5c c0 00 00 00 00  00 00 50 01 00 00 00 00  |.P\.......P.....|
0067ea60  a8 00 ff ff 00 00 00 00  01 00 00 00 00 00 00 00  |................|

Před adresou je velikost oddílu (třeba 0x02010000, resp. něco přes 512MB nebo 0x0 pro FAT, co předpokládám reprezentuje celý zbytek eMMC) a pár bajtů po této adrese máme i příznak pro symlink (před ním se ještě někdy z nějakého důvodu vyskytuje jednička, kterou jsem se rozhodl spokojeně ignorovat). Když změníme vše, co jsme zpáchali tak, aby to odpovídalo nové skutečnosti, dostaneme následující (změny jsou vyznačené):

0067e920  00 80 b8 01 00 00 00 00  01 00 00 00 01 00 00 00  |................|
...
0067e9b0  8c 02 5a c0 00 00 00 00  00 80 f1 1d 00 00 00 00  |..Z.............|
0067e9c0  00 80 6e 02 00 00 00 00  01 00 00 00 02 00 00 00  |..n.............|
0067e9d0  00 00 00 00 00 00 00 00  28 cb 5a c0 00 00 00 00  |........(.Z.....|
0067e9e0  00 00 00 10 00 00 00 00  00 00 60 20 00 00 00 00  |..........` ....|
0067e9f0  01 00 00 00 03 00 00 00  00 00 00 00 00 00 00 00  |................|
0067ea00  70 51 5c c0 00 00 00 00  00 00 00 00 00 00 00 00  |pQ\.............|
0067ea10  00 00 60 30 00 00 00 00  01 00 00 00 04 00 00 00  |..`0............|
0067ea20  00 00 00 00 00 00 00 00  cc 50 5c c0 00 00 00 00  |.........P\.....|
0067ea30  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
0067ea40  01 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|

Rekonstrukce obrazu

Když jsme si to takto hezky pozměnili, potřebujeme to zase zakomprimovat, vložit do toho dekompresoru a to vložit do bloku dat pro uboot. Taky je potřeba zajistit, že zkomprimovaný obraz jádra bude stejně velký jako předtím -- po prvním pokusu zjistíme, že je trochu menší (nahradili jsme původní čísla trochu "kulatějšími" s více nulami), takže na konec dorazíme podpis -- ten nebude nic nikdy stejně číst, gunzip bude spokojený a já budu mít tři vlastní bajty v paměti telefonu (je ale potřeba trochu zkusmo zjistit, co je potřeba přidat na konec, aby se to zkomprimovalo na stejnou velikost).

gzip -9 < kernel-patched2 > kernel-rezip-patched
cat kernel.hdr kernel-aaa kernel-rezip-patched kernel-zzz > mine.img-kernel

./mkbootimg --kernel mine.img-kernel --ramdisk boot.img-ramdisk \
  --board 20130424 -o boot-mine.img

Úprava ramdisku

Pokud chceme taky změnit obsah ramdisku, můžeme si ho rozbalit a pak zase vytvořit:

mkdir ramdisk-stock
cd ramdisk-stock
gunzip < ../boot.img-ramdisk.gz | cpio -idv
cd ..

# patch...

cd ramdisk-mine
find . | grep -v '^\.$' | sort | cpio -ov -H newc -R root:root | gzip > ../mine.img-ramdisk.gz
cd ..

Pokud je velikost jiná (což se typicky stane, pokud přidáme/odebereme/změníme nějaké soubory v něm), je to nutné taky opravit v hlavičce, aby uboot věděl (88168858 je magické čtyřčíslí, které identifikuje začátek bloku, po kterém hned následuje velikost):

function fsx() {
  printf "%.8x" `stat -c %s "$1"` | sed -E 's/(..)(..)(..)(..)/\4\3\2\1/';
}
function repm() {
  sed 's/ 88168858......../ 88168858'`fsx "$1"`'/';
}

xxd -g0 boot.img-ramdisk.hdr | repm mine.img-ramdisk.gz | \
  xxd -r -g0 > mine.img-ramdisk.hdr
cat mine.img-ramdisk.hdr mine.img-ramdisk.gz > mine.img-ramdisk

Já jsem nic moc neměnil, ale ty initskripty vypadaly lákavě

Drobnosti na které si dát pozor

V datovém oddílu je uložen adresář nvram, kam se ukládá stav telefonu před vypnutím (hlavně obsah paměti čipů pro bluetooth, wifi, telefonu, kalibrační data senzorů a podobně). Během popsaného procesu je potřeba jej zazálohovat a pak obnovit, jinak se ztratí mnoho užitečných informací. Pak se člověk diví, proč blbne signál nebo proč má divnou MAC adresu.

Závěr a TODO

Docela jsem si pohrál, zjistil, jak android vypadá velmi těsně nad hardwarem, početl jsem si zdrojáky Mediateku (i když ne přímo na můj model) a mám mnohem víc místa na aplikace. Samé pozitiva a sociální jistoty prostě

Ještě by to chtělo si trochu pohrát se Settings.apk, které obsahuje informace o oddílech taky -- takto mi to zobrazuje SD kartu jako "interní paměť" a neustále hlásí, že SD karta samotná je nepřítomná (tj. nelze ani odmountovat apod.). To mi ale moc nevadí, protože ji stejně neplánuji vybírat a protože si na ni aplikace ukládají data, stejně by to nebylo moc ku prospěchu věci.

A možná někdy zaspamuji Inhon, aby mi poslali jejich verzi zdrojáků jádra (moc licencím nerozumím, jsou to povinni udělat?) a třeba si na to sestavím vlastní distribuci, včetně plnotučného linuxu.

Kdo to dočetl až sem a ví, o čem tu kvákám, si zaslouží plný respekt a má u mně během příštího Computexu (nebo jiné akce) pivo

       

Komentáře

[geoRG77]

Hodne pekna prace :) Podle licence jsou povinni poskytnout zdrojaky nebo aspon pouzite patche na jadro. Cinani to ale povazuji za sve know-how a vymahatelnost licenci je tam tak tristni, ze bych od nich zadne zdrojaky neocekaval (cest vyjimkam jako je Ainol, ale i tam to neni idealni).

[Jan Zahornadsky]

No, můj odhad je, že těch patchů nebude hodně, soudě podle toho, že je na tom téměř původní Android a zdrojáky pro Mediatek (od kterých je v tom telefonu většina železa), které se na githubu povalují, mi během toho hraní sloužily jako dobrý manuál. I když konkrétní konstanty si člověk musel zjišťovat sám.

Třeba když poznamenám něco v tomto smyslu o těch Číňanech, tak se Tchajwanci hecnou

[Avalon]

Risky business

[Jan Zahornadsky]

In what sense?

[Avalon]

It's looks too difficult... Possible phone bricking?

[Jan Zahornadsky]

I don't believe in bricking. Backup everything, backup often, have a way to restore to the previous state.

[Kvasnic]

Bad fish! Back to school!

[Tomáš Pelc]

Tak tohle je tedy něco!!! Jenže já na to nemám Na svém HTC Desire se pořád potýkám s velikostí "Interního uložiště". Bez Link2SD bych byl vyřízený a to tam nemám téměř žádné hry. Kdyby tak existovalo nějaké safe howto, nejspíš bych do toho šel. Cyanogenmod jsem zvládl, takže bych se už toho tolik nebál.

[Dreit]

Tak to jsme dva

[KS]

Hustě!

[gtz]

hezký návod

[mimi.vx]

k cemu tak slozite kyz uz davno na to existuje appka .. ktera to udela ve dvou krocich ,....

[mimi.vx]

+ k cemu na emmc zarovnavat na cylindry z rotacnich disku?

[Jan Zahornadsky]

1. Která? Pokud myslíš Link2SD, tak ta nezmění velikosti oddílů, ale vytvoří symlink. Kromě principu je tam taky problém v tom, že ld je z nějakého důvodu neresolvuje, takže apk tam klidně můžeš hodit, ale pokud má aplikace nativní knihovnu, ta musí stále do /data. A vždy si lze říct, že "because I can"

2. Pokud víš, proč je původní rozdělení tak jak je, rád si to poslechnu, já jsem jen laik samouk.

[mimi.vx]

dej hledat MTK Repartition .. je primo app na repart eMMC u MTK telefonu .. a umoznuje nastavit tebou pozadovanou velikost s tim ze nejlepe funguje 2-2.5GB na data ...

napr ceky navod je zde http://androidforum.cz/riesenie-problemu-s-malou-vnutornou-pama-ou-2-t42983.html i s linky na DL app .

a nebo se podivat na XDA-dev..

 

Link2SD sem nepouzil od doby co ma zena rozbila sve ZTE Blade

[Jan Zahornadsky]

Vypadá to hezky, vidím, že se vyznáš Ale pokud nechce mít nad tím člověk plnou kontrolu a jenom chce změnit ten poměr velikostí, tak ostatně stačí pomocí toho SP flash toolu nahrát jiný mbr a ebr1, na co ani nepotřebuješ appku. Já jsem navíc chtěl změnit velikost oddílu pro android, cache, vyhodit fat úplně a mít všechny oddíly jako primární, tak jsem se vydal touto cestou. Kdybych si nechtěl s tím hrát, tak mi levněji než ztrávený čas vyjde si koupit telefon s větší pamětí a tento zahodit

Prostě dělat to složitě mi přijde lepší, pokud si chci poexperimentovat se systémem, protože klikáním na tlačítka v toolech se člověk většinou moc nenaučí.

[mimi.vx]

to že si chceš hrát tě šlechtí ...

 

s SP flash toolem bych si moc nezahrával .. přece jen s ním natvrdo bricknout tlf není problém a slouží hlavně k servisní práci ...

 

+ta appka ma vyhodu ze jednou rozložené odíly fungují i s 90% rom a různými verzemi droida ,,,

 

jinak o TLF na MTK ví nejíc rusové a vietnamci .. good je třeba 4pda.ru