2024. március 28., csütörtök

Gyorskeresés

Útvonal

Cikkek » Telefónia rovat

Adattárolás Android rendszeren

  • (f)
  • (p)
Írta: |

A cikk elsősorban a ZTE Blade készülékhez íródott.

[ ÚJ TESZT ]

RAM vs. "ROM"

A ZTE Blade 512 MiB RAM-mal rendelkezik (közvetlen hozzáférésű memória programkódnak és adatoknak), ebből az alkalmazások számára elérhető ~ 416 MiB. A készülék 4 Gbit ~= 512 MB-nyi belső memóriát (internal storage; a továbbiakban "ROM", a becenevével ellentétben írható-olvasható-, NAND-memória, háttértár, "lemez", mtd) tartalmaz (analóg a PC-k merevlemezével, a háttértár funkcióját tölti be); ebből ~ 467 MiB elérhető közvetlenül a rendszer számára (1 MB = 10^6 B, míg 1 MiB = 1024^2 B = 2^20 B). A leggyorsabb tárolóeszköz természetesen a RAM, elérési sebességben utána következik a ROM (~ HDD); a sor legvégén kullog az SD memóriakártya (~ flash tárolóeszköz, pendrive). Érthető, hogy érdemes alkalmazásainkat a belső memóriában (és nem az SD-n) tárolni, a gyors hozzáférés érdekében. Az érdeklődő olvasónak megjegyzem, hogy fizikailag egy házban (csomagban) került elhelyezésre a RAM és a ROM, lásd az első képet.
Megjegyezzük, hogy a szakzsargonban a ROM szót többféle jelentésben is használhatjuk, a kontextusától függően: jelentheti a belső memóriát (ami az elnevezéssel ellentétben (újra)írható-olvasható, bár nem korlátlan alkalommal), és jelentheti a telepítendő zip fájlt is.

Felül: Samsung KA1000015M-AJTT (4 Gbit NAND + 4 Gbit Mobil DDR RAM),
alul: Qualcomm MSM7227 SoC chipset (CPU+GPU+DSP+Modem)

Ez a készülék 4 Gbit-es Samsung NAND chipet tartalmaz, az újabbakban Hynix chip van
(tárcsázó: *ZTE*CHIPINFO#)

A belső memória

A következőkben a ROM-ra fókuszálunk. A ROM teljes egészében több, egymással nem átfedő részre – partíciókra – felosztható. A Blade-nél 8 partíció található, ezek rendre a recovery, boot, splash, misc, cache, system, userdata, persist neveket viselik. A partíciókra tekinthetünk, mint különálló hardvereszközökre, meghajtókra (akár merevlemezekre). Ha nagy mennyiségű adatot, fájlokat szeretnénk a partícióinkon letárolni, azokat minden esetben meg kell formáznunk (strukturálnunk kell), azaz fel kell készíteni őket az adataink fogadására. A ZTE Blade esetében a 8 partíció közül csupán 4 rendelkezik fájlrendszerrel: ezek a system, userdata, cache, persist nevűek. Az egyes partíciók esetünkben jól definiált funkciókért felelős fájloknak adnak otthont; a recovery partíción találjuk a rendszer speciális, "vészvisszaállító" operációs rendszerét, a recovery-t. A boot partíción a rendszermag és meghajtó programok vannak. A splash partíció tartalmazza a bekapcsoláskor elsőként megjelenített képet. A system tartalmazza az Android operációs rendszer működéséhez szükséges szinte összes fájlt, így általában a legtöbb adatot. A userdata tartalmazza az általunk telepített alkalmazásokat és minden testreszabást, személyes adatokat, beállításokat. Fontos megjegyezni, hogy akár SD-kártyán is tárolhatjuk (telepíthetünk) Market-alkalmazásokat, továbbá itt (és csak itt) tárolhatunk tetszőleges fájlokat (dokumentumok, kép, hang, videó, stb.), akár egy pendrive-on. Elvileg tárolhatnánk fotóinkat akár a system partíción, csak a telefon alkalmazásain keresztül nem, illetve PC-hez csatlakoztatás után csak ADB (Android Debug Bridge) használatával érhetnénk el azokat – tehát lehetőleg a telefon belső memóriáját ne használjuk közvetlenül adattárolásra –, erre a célra szolgál az SD-kártya. Azonban indokolt esetben módosíthatjuk közvetlenül a NAND tartalmát (most a system és userdata partíciókra gondoljunk), oda fájlokat másolhatunk.

Internal Memory (most: userdata partíció), microSD kártya, RAM

A partíciós tábla, Total Phone Transfer, generáció

Az eszközben a NAND-on kívül, PC-s analógiával élve amolyan BIOS-ban (pontosabban: firmware-ben) van letárolva a ROM partíciós táblája, azaz a partíciók elhelyezkedése (nevük (számuk), sorrendjük és hosszuk – röviden geometriának nevezhetjük). A partíciós tábla újraírásával (a "lemez" újrafelosztásával) elveszítünk minden, az egyes partíciókra jellemző struktúrát és adatokat (röviden törlődnek a partíciók és természetesen a teljes tartalmuk is, visszafordíthatatlanul). A partíciós tábla újraírható (a geometria átszerkeszthető) a fórumon "csudazip"-nek nevezett Total Phone Transfer (TPT) eljárás végrehajtásával. Ekkor az SD-kártya "image" mappájába másolt .mbn bináris fájlokban definiált módon újraoszthatjuk a partíciókat. Ezek az .mbn fájlok valójában a telefon firmwaré-t (~ BIOS-át) módosítják, újraírják azt. Tehát a TPT alacsony szintű művelete automatikusan igen sok módosítást hajthat végre, minimális felhasználói közbeavatkozással (kiváló patchelésre, hibajavításra). Ugyanakkor kockázatos, mivel ha nem sikerül sikeresen újraírni a firmware-t, vagy annak egy részét, akkor a telefon nem lesz képes a jövőben automatikusan inicializálni saját firmware-nek frissítését (azaz egy rekonstruáló célú, újabb TPT-t), így "tégla" lett a készülékből, csak szakszervizben javítható, kelthető "életre". Fontos hangsúlyozni, hogy normál ROM telepítéssel szinte lehetetlen elrontani a telefont, ugyanis, ha esetleg megszakad, bármikor újrakezdhetjük. Azonban a TPT alacsonyszintű művelet, ha egyszer megszakadt, korántsem biztos, hogy újrakezdhetjük a folyamatot, ezért magában rejti a téglásítás lehetőségét is. A rendkívül hardver specifikus TPT segítségével a hardverszinthez közeli (tehát a rendszermag, kernel szint alatti) módosítások végrehajthatók, például a RAM címtartomány beállítása, kijelző színhelyességének kalibrálása (kvázi hardver szinten), a partíciós tábla újraírása stb. A TPT ezen túl lehetővé teszi minden partícióra lemezképfájlok felírását. Tehát először létrejön a partíciós tábla, majd megfelelően formázásra kerülnek egyes partíciók, majd egyes partíciókra adatok (~ 100 MiB) íródnak; közben természetesen mély hardver közeli változtatások tucatjai mennek végbe -- mindezek néhány másodpercen belül, teljesen automatikusan az SD-n tárolt bináris konfigurációs fájlok (.mbn) és képfájlok (.img) alapján. Ezek után érthető, miért rendkívül kritikus a „csodazip”, „csudazip” alkalmazása előtt az md5 hash (fájlok sérülésmentességének, konzisztenciájának) ellenőrzése; továbbá az is világos, miért kerültek eltávolításra a fórumból a TPT fájlok linkjei. Továbbá felhívnám a figyelmet arra a tényre is, hogy vannak különböző generációjú firmware-ek Blade esetén (G1 és G2). TPT eljárással jelenleg csak G1-es firmware telepíthető, továbbá a G2-es firmware-állapot nem konvertálható G1-essé. Ezek alapján könnyen belátható, hogy a G1-es firmware-t telepítő TPT alkalmazása G2-es készülék esetén téglásodáshoz vezet(het). A firmware generációjával kapcsolatban megjegyezzük, hogy 2011. április közepéig G1-es állapotú Blade-eket árusítottak Magyarországon, Android 2.1-es gyári operációs rendszerrel. Ezután kezdődött meg a G2-es készülékek árusítása, Android 2.2-es gyári operációs rendszerrel. Ugyan a G1-es készülékek G2-essé alakíthatóak, a konverziót jelenleg senkinek NEM javasoljuk (részben azért nem, mivel nem visszaállítható a G1-es állapot).
Továbbá a TPT módszerek („csodazip”, „csudazip”) alkalmazása mindenképpen kerülendő!

Mr Pigfish szerint ez első generációs készülék

Még egy flash fájlrendszer...

A partíciók tartalmának részletezése előtt ejtsünk néhány szót a ZTE Blade-nél használt fájlrendszerről. A NAND alapú memóriáknál elterjedt a YAFFS (Yet Another Flash File System – a Linux világában gyakoriak a rekurzív, vicces elnevezések) fájlrendszer (FS) használata. A Blade esetében ennek továbbfejlesztett változatával, a YAFFS2-vel találkozunk néhány (fontosabb) partíció esetében. Ez egy, a beágyazott eszközök flash technológiájú adathordozói számára kifejlesztett speciális fájlrendszer formátum, a legtöbb Linux rendszer natívan nem támogatja. Bármely partíció komplett tartalma (bitről-bitre) kiolvasható, archiválható – így a teljes rendszerünkről biztonsági másolatot, pillanatképet készíthetünk – célszerűen a készülék SD-kártyájára, amit aztán megbízhatóbb adattárolóra, pl. egy merevlemezre helyezhetünk. A Linux számára az egyes partíciók teljesen önálló blokkeszközök (speciális, nem pedig reguláris fájlok; kicsit hasonlítanak a mappa fogalmához, amelyeknek nincs méretük, speciális célfájlok). A blokkeszközök, mint fájlok neve a következő: /dev/block/mtdX, ahol X: 0-7 (8 darab), a partíciók neveit már fentebb felsoroltuk (számít a sorrendjük). Ezen blokkeszközök tartalma kiolvasható a "cat" paranccsal és közvetlenül egy fájlba írható a ">" redirect (átirányító) operátorral. Ezt a fájlt (lemez)képfájlnak nevezhetjük (kiterjesztése a konvenció szerint .img, ám ennek nincs jelentősége). A képfájl tehát az eredeti forrásfájlrendszer (itt pl. YAFFS2) egy másik fájlrendszerbe (pl. SD esetén FAT) van ágyazva, egyetlen fájl formájában. Felvetődik a kérdés, hogyan olvashatjuk el a manuálisan, vagy egyéb célszoftverrel (pl. Clockwork Recovery) készített lemezképfájljainkat, amelyek a legtöbb rendszer számára nem mások, mint értelmezhetetlen bináris adathalmazok? Hogyan szedhetjük ki például a telefonkönyvünket egy biztonsági másolatból? Kis trükkel felcsatolhatjuk (mountolhatjuk) a PC-nk Linux fájlrendszerébe a YAFFS2 formátumú képfájljainkat, vagy akár ki is bonthatjuk ("szétszedhetjük") őket, hozzáférve így a NAND adott partíciójának teljes mappastruktúrájához és összes fájljához. Itt az utóbbit ismertetném: töltsük le a unyaffs.h headerfájlt és unyaffs.c C-forráskódot, majd fordítsuk le őket. A keletkező bináris program képes YAFFS2 formátumú képfájlok kicsomagolására. Windowsra már lefordított binárist (unyaffs.exe) is letölthetünk. YAFFS2 fájlrendszerűek a következő partíciók: cache, system, userdata, persist. A többi partíció egyáltalán nem, vagy nem egy fájlrendszerrel rendelkezik. Az egyszerűség kedvéért az utóbbi esetre is mondhatjuk, hogy fájlrendszere "none" formátumú.

Felcsatolt partíciók

A partíciók

A következőkben a 8 partíció közül 6 tartalmát, felépítését részletezném. A partíciók tartalma kiolvasható és felülírható (PC-n fastboot, telefonon flash_image programmal). Azonban ne feledjük, hogy az egyes partíciók igen szigorúan meghatározott méretűek, felépítésűek, funkciójúak, és erősen eszköz/hardver specifikusak – ez különösen igaz a fájlrendszer nélküli partíciókra. Ezért .img fájlok partíciókra írásakor ("flash") különösen körültekintően kell eljárni. ZTE Blade-re csak ZTE Blade-hez készített img-ket (recovery, boot) írjunk, és lehetőleg ellenőrizzük itt is az md5 hash-eket – bár ez a TPT esetén sokkal fontosabb.

MTD-k, azaz "partíciók" (hexadecimális értékek!)

Recovery, boot, avagy hol a kernel?

A recovery és a boot partíciók felépítése teljesen analóg, azonban tartalmuk teljesen eltérő. Ezeken a partíciókon nincs fájlrendszer, azonban felépítésük szigorúan meghatározott. A partíciókra egyenként egy ~ 4 MiB méretű bithalmazként gondolhatunk. A tartalmuk rendre: az első 2048 bájt az ún. kernel-header (rendszermag-fejléc, nincs különösebb funkciója), majd következik a Linux kernel (rendszermag) binárisa gzip-pelve (tömörítve; ez természetesen ARM architektúrára lefordított, optimalizált bináris kód, ember számára értelmezhetetlen; ZTE Blade-specifikus), majd az úgynevezett ramdisk (RAM-lemezkép; szintén gzip-pelve, és még egy további eljárással (cpio) tovább "tömörítve", összefésülve). Minden boot-nál a megfelelő partíció (recovery vagy boot) tartalma a headert leszámítva kicsomagolásra kerül, majd a RAM alsó tartományába betöltődik. Ez a kernel kommunikál a legalacsonyabb szinten a hardvereszközökkel (illesztőprogramokat is tartalmaz), elvégzi a futó folyamatok menedzselését, betölti őket a RAM-ba, felszabadít memóriát, kiolvassa a szenzorok nyers adatait, LED-eket kapcsol be, időzítőket vezérel, beállítja a valós idejű órát, felébreszti az alvó rendszert bizonyos eszközök trigger eseményeire stb. Röviden a hardver és a szoftver közötti elsődleges, legfontosabb, nélkülözhetetlen híd szerepét tölti be. Nem meglepő, hogy a kernel erősen hardver specifikus, hemzseg speciális gyártói megoldásoktól, trükköktől, akár "patkolásoktól". A kernel forráskódja a legtöbb esetben, így a ZTE Blade esetében is publikus; C és C++ nyelvű, sok esetben igen hardver közeli programkód (mindig valamelyik stabil Linux kernelen alapszik, pl. 2.6.29, 2.6.32 verziójúakon alapulókat tette közzé a ZTE). A ROM-főzők ezt (a forráskódot) kedvükre módosítják, patchelik (javíthatnak funkcionalitáson, vagy akár el is ronthatnak dolgokat). A recovery és a boot partíciók utolsó része a legérdekesebb számunkra: ezek egyenként egy-egy mini fájlrendszert tartalmaznak, ramfs-nek, rootfs-nek is nevezhetjük. A boot után az egész rendszer alapmappájaként, gyökereként szolgáló / (root) mappa legtöbb almappáját (tehát a legfelső szintű mappákat) és fájljaikat tartalmazzák. Meg kell jegyeznünk, hogy a legtöbb fájl virtuális (ismerős lehet a fogalom, volt már szó mappa, blokkeszköz típusú speciális fájlokról), azaz nincs méretük, a tartalmuk bármikor megváltozhat, a rendszer üzenhet rajtuk keresztül a felhasználónak (pl. akár a partíciós táblát, LED-ek állapotát, a háttérvilágítás aktuális fényerejét is lekérdezhetjük, illetve szabályozhatjuk az utóbbi kettőt). A rootfs adja az aktuálisan futó Linux rendszer gerincét, a legfontosabb mappákat, inicializációs és konfigurációs fájlokat. Megjegyezzük, hogy Linux alatt a legtöbb konfigurációs fájl ASCII formátumú szöveg, így a megfelelő szakértelemmel rendelkező felhasználók számára azok közvetlenül olvashatók, módosíthatók, átláthatók – ellentétben a Windows konfigurációs állományaival; Linux alatt nincs Registry, meg persze a vele járó sok negatívum sincs jelen. Ki kell emelnünk a rootfs-ből az /init.rc fájlt és az /etc/init.d mappát, amelyek az indításkor végrehajtandó rutinokat tartalmazzák (flash meghajtóeszközök (mtd-k) felmountolása, sok hardvereszköz inicializálása, folyamatok automatikus lefuttatása stb.). Az /etc mappában sok konfigurációs állományt találhatunk. Továbbá meglepően sok rootfs-beli mappa üres, ezek nagyrészt vagy kompatibilitási célokból szerepelnek, vagy a boot után telnek meg fájlokkal (vagy virtuálisakkal, amelyeket automatikus rutinok generálnak, vagy nagyon is létező, NAND-ból beolvasottakkal). A recovery és boot nevű partíciók képesek önmagukban bootolásra (azaz külön-külön eltérő (ámde igen hasonló), teljes értékű kernelt, drivereket tartalmaznak). A recovery bootoltatható a Power+Hangerő le (+ esetleg Menü) billentyűkombinációval: ekkor, ha pl. Clockwork recovery-t írtunk előzőleg ezen partícióra, akkor az azon tárolt speciális (cél) Linux kernel (operációs rendszer) elindul néhány másodperc alatt (közben egy fejjel lefelé fordított A N D R O I D _ szöveget láthatunk felvillanni), majd megjelenik a Clockwork menüje. A gyári (nem módosított) eszközök is tartalmaznak recovery-t, azonban annak igen korlátozott (azaz nincs) a funkcionalitása a Clockwork-höz képest). A boot partícióról bootol az eszköz normál bekapcsolással. Megjegyezzük, hogy a Power+Hangerő fel (+ esetleg Menü) billentyűkombinációval indított rendszer bootloader (download) módba kerül. Ekkor végrehajtható pl. a PC-n tárolt recovery lemezképfájl (.img) recovery partícióra történő felírása: ezután már használhatjuk a recovery-t biztonsági másolatok készítésére a rendszerről, azok visszaállítására, rom telepítésére, partíciók formázására, hibás mtd blokkok („szektorok”) keresésére stb.

A boot és recovery partíciók felépítése, ezekben lakik egy-egy kernel is

A recovery (a képen a Clockwormod Recovery) egy egyszerű Linux rendszer;
a gyári recovery ("FTM mód") csak speciális PC-s programmal áll szóba, a felhasználóval nem

Splash, avagy a zöld robot

Ezután következik a splash partíció, amelynek szintén nincs fájlrendszere. A splash valójában nem más, mint egyetlen, jól definiált méretű és színmélységű, továbbá kódolású (R5 G6 B5) bitkép fájl. Ez jelenik meg néhány másodpercre közvetlenül a Power gomb hosszú lenyomását követően. Megjegyezzük, hogy főleg kompatibilitási okokból kifolyólag a boot partíció ramdiszkje is tartalmaz egy bitképet (elindított rendszeren a /logo.bmp helyen találjuk). A ZTE Blade-en azonban csak a splash-beli kép jelenik meg. Mérete közel van az 1 MiB-hoz, azonban a bitkép mérete jól definiáltan 768 070 bájt (felbontása: 800x480, színmélysége 16 bit, nélkülözni kell a futáshossz kódoláson (ZRLE) alapuló és egyéb tömörítéseket, és a megadott színprofilt kell használni). Legegyszerűbben a GIMP képszerkesztő programban hozhatjuk létre az előírt formátumú .bmp fájlt.

Az mtd2-ben lakik a zöld robot

A system partíció, mint Live CD

A system partíció tartalmazza az Android operációs rendszer szinte összes fontos rendszerfájlját, leszámítva a kernelt, amely a boot partíción foglal helyet, speciális formátumba csomagolva. Rom "felrakásakor" az ideális esetben előzőleg formázott system és boot partíciókba íródik az SD-kártyára előzőleg felmásolt zip fájl tartalma. Tehát a rom telepítés nem más, mint a <rom>.zip-ben lévő boot.img képfájl kiírása bitről-bitre a boot nevű partícióra és a zip system mappájának tartalmának felírása az ideális esetben YAFFS2-re formázott system partícióra. A system partíció tartalma ezután nem változik, mérete konstans – normál felhasználás során futó rendszeren nem írható, mivel ro-ként (read-only, csak olvasható) van csatolva a RAM-ba betöltött ramfs /system nevű csatolási helyére (mountpoint). Ennek ellenére természetesen futó rendszeren is módosítható a system tartalma, miután azt újramountoltuk (írhatóként; természetesen rootolt rendszer szükséges ehhez). Tehát a boot és a system nevű partíciók tartalmaznak minden, a rendszer elindításához szükséges információt, továbbá minden rendszeralkalmazást (~ "gyárilag" telepített programokat (/system/app helyen); amelyek közül törölhetünk is, ám legyünk óvatosak: egyes .apk-k törlése bizonyos funkciók működési zavaraihoz vezet). "Ideális" esetben a boot és system partíciók tartalma a gyárban feltöltésre kerül, ezután, mint egy CD-ROM vannak kezelve, azaz csak olvasható háttértárolóként érhetők el. A helyzet hasonló egy Ubuntu Live CD-ről indított PC rendszerhez. Tehát leegyszerűsítve, a futó rendszert egyrészt a RAM-ba betöltött kernel és ramdiszk, másrészt a system partíció jelenti, ahonnan – mint egy CD-ről – alkalmasint betölthetünk a RAM-ba alkalmazásokat (ezek a folyamatok, processzusok). Itt hívnám fel a figyelmet az Android rendszerek memóriakezelésének egy fontos sajátosságára: NEM kell bezárni az alkalmazásokat, mivel a rendszer felszabadít memóriát, ha szükséges (a legtöbb felhasználó Windows rendszeren "szocializálódott", ahhoz képest azonban más elvek szerint működik a Linux kernel memóriamenedzsmentje). Az alkalmazások bezárogatása az akkumulátor merüléséhez vezethet, tehát elérhetjük azt, amit próbáltunk elkerülni! Továbbá a task killerek alkalmazásával a rendszer válaszideje megnőhet, így kerüljük azok használatát. Tehát ne feledjük, hogy az Android memóriakezelése (a Linux kernelnek köszönhetően) igen sok tekintetben intelligensebb a Windows Mobile-okénál, ezért ne használjunk automatizált task killereket, mert a legtöbb esetben többet árt, mint használ.
A system partíció mérete alapesetben ~ 207 MiB. Azonban ha a rom-unk 100 MiB-ot foglal, akkor parlagon fog heverni, kihasználatlanul ~ 100 MiB a belső memóriából. Most válik világossá az újrapartícionálás létjogosultsága. Kérdés, hogy a személyes, saját adataink: pl. letöltött (később eltávolítható) Market alkalmazásaink, beállításaink, nem SIM-kártyán tárolt telefonszámaink és SMS-eink, csengőhang hangerő értékünk, stb. hol kerül tárolásra?

Foglalt és szabad lemezterület, partíciónként

Userdata, avagy hol vannak az adataim?

A válasz az előbbi költői kérdésre a userdata partíció (gyakran data-nak rövidítik). Ugyanis ezen /data helyre felcsatolt partíció hordozza MINDEN személyes adatunkat (természetesen az SD-kártyával együtt). A data partíció az első boot során "népesedik be" fájlokkal, majd a telefon használata során monoton csökken a szabad hely rajta, mígnem el nem fogy –, ha sok száz alkalmazást telepítünk. Azonban ekkor jön a képbe az újrapartícionálás: felhasználhatjuk a system kihasználatlan ~ 100 MiB-ját, azaz hozzátapaszthatjuk a data-hoz (amelynek mérete alapesetben ~= (közelítőleg egyenlő) a system méretével, azaz ~ 200 MiB), hogy másfélszer annyi helyünk legyen az alkalmazásainknak. A rendszer folyamatosan írja a userdata partíciót a normál használat során, ellentétben a system-mel. Ezen partíció fő funkciója könnyen kitalálható: a letöltött Market alkalmazásainkat és azok járulékos adatait (testreszabását, saját beállításainkat) tárolja. Tehát a futó rendszer a /-ből (gyökérből) és egyéb, a RAM-ba betöltött rootfs-beli mappákból és fájlokból, továbbá a /system helyen felcsatolt, alapesetben csak olvasható és a /data helyen felmountolt, írható-olvasható, megfelelő nevű partíciókból áll.

Egy alkalmazás által tárolt adatok (userdata és cache partíciókon)

Cache és egyéb meglepetések

A fenti konklúziót árnyalja a cache, misc és persist partíciók jelenléte. A cache átmeneti adatokat tárol, bizonyos értelemben hasonló a Linux rendszereken ismert swap-hez, amelynek azonban a ZTE Blade esetén nincs létjogosultsága (ugyanis relatíve sok RAM-ot tartalmaz). A cache és persist a normál használat során fel vannak csatolva a telefon fájlrendszerére, ami ugye a RAM-ba gyökerezik. A cache-ben átmenetileg tárolódhatnak személyes adatok. Komplett rendszer backup esetén a mentése fontos, mivel a rendszerünk konzisztenciája megsérülhet, ha egy alkalmasint végrehajtott teljes visszaállítás esetén nem rekonstruáljuk a mentéskori állapotra. A misc partíció nem használ fájlrendszert, adattartalma nem releváns a szempontunkból, ahogyan a YAFFS2 formátumú persist-é sem. Csupán annyit jegyzünk meg, hogy a persist csatolva van futó rendszeren. A cache partíció mérete 41 MiB. Az összes többi partíció mérete együttesen kitesz ~ 1-2 MiB-ot. Ha összesítjük a partíciók kapacitásait, meglepő következtetésre juthatunk: 4 (recovery) + 4 (boot) + 1 (splash) + 41 (cache) + 207 (system) + 208 (data) + 2 (misc, persist) (MiB) = 467 MiB. Ez bizony elmarad az 512 MB ~= 488 MiB-tól! Hova lett ~ 20 MiB-nyi kapacitás? A kérdés megválaszolását a kedves olvasóra bízzuk.*

* Egy kis segítség: gondoljunk arra, hogy a telefonunk egy embedded (beágyazott) rendszer; és az internal storage != (nem egyenlő) merevlemez, hanem "több" puszta háttértárnál. Tehát bizonyosan a RAM és a "ROM" kapacitásának egy része a hardvereszközök számára van kizárólagosan fenntartva, így számunkra (pontosabban az alkalmazások számára) nem látható.

Az érdeklődő olvasók számára megjegyzem, hogy vannak rejtett "partíciók" is: olyan lemezrészek, amelyeken a rendszer tárolja a lemez geometriáját; ezek mbn formátumú bináris állományok. Tehát a NAND-ban tárolódik a firmware egy része is.

A firmware tartalmazza az elsődleges és másodlagos bootloader rutinokat, a GSM/UMTS-rádió/modem vezérléséhez szükséges kódokat, további chipek vezérlőrutinjait (köztük a NAND, a HW-billentyűk, a digitizer és LCD drivereket (lásd az első Blade-eket érintő színhibát/gradiens hibát, ami firmware eredetű volt, de már javították)), egyes egyedi azonosító kódokat, a rejtett és látható partíciók geometriáját, applikáció drivereket, RAM-térképet (map) (lásd az első Blade-eket érintő hibát, amely miatt az 512 MB RAM-ból csak 256 MB volt elérhető, a probléma firmware eredetű volt, de már javították a gradiens hibával együtt), firmware frissítést inicializáló rutinokat (lásd: bootloader, fastboot, esetleg download mode, TPT), egyéb alacsony-szintű diagnosztikai (debug)/szerviz módok vezérlőrutinjait.

A NAND-ban lévő firmware ún. rejtett partíciókban van tárolva.
A rejtett partíciók nevei (Gen1!, sorrendben, zárójelben a megfelelő mbn/img bináris):
MIBIB (???.mbn), QCSBL (qcsbl.mbn), OEMSBL1 (oemsbl.mbn), OEMSBL2 (oemsblhd.mbn ???), AMSS (amss.mbn), APPSBL (appsboot.mbn ???), FOTA (???.mbn), EFS2 (cefs.mbn), APPS (appsboothd.mbn ???), FTL (???.mbn), EFS2APPS (???.mbn).

A firmware iránt érdeklődő Olvasónak ajánlom a következő személyes bejegyzésemet:

http://logout.hu/bejegyzes/anglergab/zte_blade_tpt_gen1_vs_gen2/hsz_1-50.html

Hirdetés

Copyright © 2000-2024 PROHARDVER Informatikai Kft.