ablbd
Membru Senior
 Inregistrat: acum 15 ani
|
|
Dat fiind ca sunt posesorul unui astfel de aparat, am avut suficient timp ca sa-l studiez si multe din detaliile acestei prezentari probabil ca nici cei care fac service la ele nu le cunosc.
Sar peste caracteristicile generale, mentionez doar ca are 32M ram si imaginea completa a sistemului de operare ocupa aproape tot atata. As incepe cu prezentarea si descrierea partitiilor de pe memoria interna flash de 1G. Partitia 0, de aproximativ 1M, aparent este ceva in plus deoarece contine extrem de putine date si niciun executabil. Mai tarziu veti vedea ca acele date sunt esentiale pentru ca sistemul sa poata fi incarcat. Ea urmeaza imediat dupa MBR (descrierea acestei structuri am prezentat-o in articolul despre Wayteq), adica din sectorul 1 si are lungimea de 0x8CB sectoare(1 sector = 512 octeti sau 0x200 in hex). Sistemul de operare propriu-zis se gaseste in partitia 1, care incepe cu sectorul 0x8CB si are lungimea de 0xF820 sectoare (32,522,240. octeti). Partitia 2 este cea user (FAT), are 990,521,344. octeti iar partitia 3 (0x1800 sectoare, 3,145,728 octeti) contine registrii. Dintr-o singura privire asupra MBR se poate spune imediat care este partitia ce contine sistemul de operare, deoarece acesta va fi obligatoriu plasat intr-o partitie de tip BINFS (0x21).
Inainte de a trece mai departe, vreau sa fac o paranteza mare si sa va prezint secventa de incarcare a oricarui sistem de operare WinCE. Pe de o parte poate fi instructiv si pe de alta parte (sper) ca va lua cheful multora de a experimenta cu incarcarea unor romuri ce provin din alte aparate, poate chiar foarte asemanatoare cu cel in cauza.
Dupa orice pornire la "rece" (alimentarea oprita complet), va fi executat un mic programel scris in asamblor de la adresa 0x0. De cele mai multe ori acesta rezida tot pe flash si trebuie sa incapa intr-un singur sector. Este asa-numitul bootloader primar (IPL=Initial Program Loader) care are menirea sa initializeze la nivel minimal hardware-ul si sa lanseze bootloaderul secundar (SPL). IPL se afla intr-un bloc de NAND care nu intra in socoteala pe care v-am prezentat-o. De ce e nevoie sa incapa intr-un singur sector? Raspunsul este ca memoriile NAND, spre deosebire de cele NOR, sunt organizate pe sectoare iar pentru ca un program sa poata fi executat nemijlocit din el trebuie ca sa beneficieze de un spatiu contiguu de adrese. Organizarea pe sectoare asigura un spatiu contiguu si direct adresabil egal cu lungimea unui sector. Aceasta lungime depinde de tipul nemoriei NAND si este de 512 octeti (mai nou 1024 sau chiar 2048 !). Sursa asamblor a IPL se gaseste in Platform Builder sub denumirea de "startup.s". Operatiunile executate de catre IPL sunt, in aceasta ordine: activeaza semnalul de refresh pentru RAM, seteaza intreruperile pentru mod IRQ, configureaza MPLL, initializeaza controlerul memoriei apoi se autocopiaza in RAM si continua de acolo. De aici incolo nu mai are prea multa treaba: configureaza managementul de memorie (MMU), copiaza in RAM bootloaderul secundar(SPL) si sare la adresa de start a acestuia. De retinut aici este faptul ca toate adresele fizice si locatia pe NAND a SPL sunt codate in interiorul IPL, deoarece acele valori se stabilesc la generarea romului si prin compilare vor fi introduse sub forma unor constante in interiorul IPL. Va dati seama ce se intampla daca un necunoscator se apuca sa incarce un rom in care amplasarea fizica pe NAND a lui eboot.bin este alta decat cea din IPL...
Bootloaderul secundar deja poate fi scris in C++, deoarece rolul sau este de a incarca sistemul de operare. Spun primar pentru ca el mai poate avea si un alt rol: acela de a putea fi accesat din exterior printr-o comunicatie rapida de tip LAN si de a efectua pe aceasta cale interventii asupra sistemului: formatarea NAND, incarcarea (sau upgrade) de sistem de operare, setarea frecventei procesorului, a demultiplicatoarelor de frecventa pentru display, bus si IO, etc. SPL are un meniu mai complex sau mai simplu, dar functiile de baza sunt cele descrise anterior. Dat fiind ca articolul este in principiu dedicat aparatului Evolio, exemplul de meniu SPL va fi, evident, pentru Evolio:
EBoot Version: MLC_V1.9!!
Ethernet Boot Loader Configuration:
---------------------------------------
1) IP address : 0.0.0.0
Subnet mask: 0.0.0.0
2) Boot delay: 5 seconds
3) DHCP: ENABLED
4) Toggle EBOOT Menu: DISABLED
5) Startup image: LAUNCH EXISTING
6) Set Clock
7) MAC address: 00:00:00:00:00:00
8) Bluetooth address: 00:00:00:00:00:00
9) Format Boot Media for BinFS
0) Get Clock
A) UPDATE image from SD/MMC card
D) DOWNLOAD image now
L) LAUNCH existing Boot Media image
S) Save Configuration and Exit
U) Using AtlasMgr to download NK image
I) DOWNLOAD image via USB RNDIS Ethernet
R) LAUNCH existing Boot Media image via USB RNDIS KITL
C) Read-Only User FAT partition (type 0x12) block num: 0
P) Read-Only User FAT partition (type 0x12): Not exist
H) CLONE SD/MMC card to/from MLC NAND Flash
M) Launch DM
O) Erase all & reset TOC
V) Image check sum
T) Debug MLC
---------------------------------------
Enter your selection:
Norocosii (nu e cazul la Evolio) mai beneficiaza de o optiune extrem de valoroasa, aceea de a face o salvare a sistemului de operare existent. Salvarea nu este un simplu dump ci va genera intreaga suita de fisiere necesare unui flash complet! O alta optiune, de asemenea inexistenta in meniul Evolio este formatarea partitiei hive. Va intrebati cum poate fi folositoare o formatare? Sa presupunem ca ati umblat in HKLM/init si ati perturbat secventa de incarcare. Sistemul ramane agatat si nu se conecteaza prin ascivesync. Daca eu din bootloader formatez partitia hive (care contine registrii), la urmatorul hard reset sistemul de fisiere va reconstitui intreaga partitie din copia aflata in rom. Totusi ebootul Evolio ofera posibilitatea de a instala un sistem provenit din alt aparat; pentru asta se acceseaza optiunea H), se cloneaza NAND flashul pe un card sd iar in aparatul ramas in pana se face operatiunea inversa, rescriindu-se intreg discul flash cu datele de pe cardul sd. Din pacate nu exista control asupra partitiilor si clonarea se face integral pentru 1G, deci poate dura minim 30 de minute. Mai exista si riscul unor date corupte din cauza vreunui defect al cardului sd. Verificand optiunea 0) - get clock - am constatat ca EVolio are setata frecventa la 372MHz, ceea ce nu-i deloc rau tinand seama de faptul ca procesorul duce maxim 400MHz. Optiunea 6) - set clock - permite setarea manuala a frecventei, dupa care trebuie setata varianta de divizoare; iata cum arata acest dialog:
Enter your selection: 6
Input CPU Freq:
1) CPU:DSP:SYS:IO 2:2:2:1
2) CPU:DSP:SYS:IO 4:2:2:1
3) CPU:DSP:SYS:IO 6:4:2:1
4) CPU:DSP:SYS:IO 3:2:1:1
Input Clock Ratio:4
CPU:DSP:SYS:IO = 348:232:116:116 MHz+TOC_Write *
-TOC_Write
*Am setat pentru exemplificare frecventa mai jos, la 348 MHz, apoi am revenit la 372MHz
Presupunand ca nu tinem bootloaderul ocupat cu studii asupra meniului de care dispune sau ii dam din meniu comanda "L", SPL trece la incarcarea kernelului (nk.exe). Iata cum arata lansarea kernelului Evolio din meniul bootloaderului:
Enter your selection: l
OEMPlatformInit: IMAGE_TYPE_RAMIMAGE|IMAGE_TYPE_BINFS
INFO: Loading image from Boot Media to RAM (address=0x8CB50000, sectors=0x1671, launch address=0x8CB51000)...
IsValidMBR: MBR sector = 0x0 OpenPartition: Partition Exists=0x1 for part 0x21.
BP_SetDataPointer at 0x0ReadData: Start = 0x0, Length = 0x2CE200. pbSector=AC021200Using device name: 'AT4X0HH_0'
-OEMPreDownload: BL_JUMP
::OEMLaunch, ImageStart:0x0, ImageLength:0x0, LaunchAddr:0x0
Eboot setup Kitl from media boot
INFO: using TOC[1] dwJumpAddress: 0x8CB51000
Jumping to image at virtual address 0x8CB51000h
+ToPhysicalAddr:0x8CB51000
-ToPhysicalAddr:0xC0B51000
::: Physical Launch Address: 0xC0B51000h
In termeni consacrati, cu asta se termina faza I de bootare. Kernelul odata plasat la locul lui in memorie, SPL ii transfera controlul. In majoritatea sistemelor de operare WInCE nu se face o delimitare foarte clara intre SPL si prima parte din kernel, deoarece o parte a kernelului este comuna cu SPL. Cert este ca se trece din acest moment la faza II, ceea ce presupune maparea in memorie a tuturor componentelor vitale din ROM, desi ele vor fi executate acolo unde sunt. Ma refer aici in primul rand la intregul sistem pentru gestiunea fisierelor; setarile te tip registru sunt preluate din boot.hv, care se afla in rom. Dupa incarcarea sistemului de fisiere, nu mai deranjeaza faptul ca NAND-ul este organizat pe blocuri, deoarece binfs.dll se ocupa de aceasta problema si face ca executabilele "sa para" a fi plasate intr-o zona contigua de memorie. Nu insist asupra notiunilor de memorie fizica, virtuala si despre modul cum acestea sunt echivalate in MMS, doritorii de amanunte vor putea gasi mijloace de informare incepand cu msdn.microsoft si terminand cu nenumarate publicatii tiparite. Va spun doar ca echivalarea virtual-fizic se face pe baza unei tabele si este hotarata de catre cel (cei) care au generat acel ROM. Exista niste principii generale de mapare, dar valorile exacte sunt totusi decise in Platform Builder. Important este ca in acest moment trebuiesc executate anumite programe intr-o anumita ordine. Secventa respectiva este stabilita in HKLM/init (descriere amanuntita tot la Wayteq) si eliminarea oricarei componente de care depinde urmatoarea duce la blocarea intr-o bucla de asteptare.
Sa revenim la Evolio... dar cazul poate fi extrapolat la multe alte aparate. Acum, ca stiti in mare care sunt fazele de incarcare, sa se intoarcem la acea partitie 0. Ei bine, acolo se gasesc date de bootare necesare SPL. EL afla de acolo informatii privind modul de divizare a frecventei procesorului pentru diferitele componente ale sistemului(display, bus, IO), afla unde este localizat kernelul, lungimea acestuia, adresa virtuala unde urmeaza a fi incarcat precum si locatia asa-numitului XIP Chain, pe care le incarca in memorie (virtuala) - in fapt mapeaza respectivele parti in memoria virtuala.
O paranteza mai mica: ROM-ul poate fi compus dintr-o singura bucata sau din mai multe, numite imagini. Ideea structurilor cu imagini multiple era ca sa se poata face upgrade doar la o anumita parte a sistemului de operare fara a afecta restul. Cu o singura exceptie (nu spun cine pentru a nu face reclama), aceasta posibilitate nu a fost (mai) niciodata exploatata. Kernelul este incarcat de catre SPL. Daca sunt mai multe imagini, de restul va trebui sa se ocupe kernelul iar pentru asta are nevoie de o lista a tuturor imaginilor (inclusiv a sa) care se numeste "XIP chain".
In cazul lui Evolio, adresa fizica (locatia in interiorul, sa zicem, al unui fisier de dump) a "xip chain" nu poate fi dedusa/calculata din pointerii pe care-i gasim in imaginea rom-ului, dar pana in momentul de fata este singurul caz de acest fel pe care l-am intalnit. Toate celelalte imagini aveau pointerul catre xip-chain calculabil si, ceea ce este mai important, in interiorul fisierului fizic, mai precis in spatiul dintre prima si a doua imagine. Singura modalitate de a localiza xip-chain la Evolio este extragerea sa din sectoarele NAND unde este plasat. In principiu, un dump complet al partitiei 1 va contine si xip-chain, insa acesta se gaseste la sfarsitul fisierului si nu poate fi regasit prin pointerii in cauza. Toata povestea asta are si o morala: datele continute in acea partitie nr.0 sunt critice pentru bootarea sistemului. Modificarea unui singur bit acolo poate da peste cap totul. Mai grav de atata este sa se purceada la un flash cu un ROM de origine dubioasa, pentru ca prin flash NU SE VA RESCRIE SECTORUL DE DATE iar romul proaspat intrudus mai mult ca sigur ca are nevoie de cu totul alti parametri decat cel original. Eventuala exceptie ar fi ca romul nou sa nu necesite sector de date, dar putin mai incolo veti intelege ca sunt sanse mici sa mearga...
Revenind la date, fiecare firma care creaza sisteme de operare isi structureaza acele date oarecum dupa bunul plac, ceea ce inseamna ca un anumit octet poate avea cu totul alta semnificatie la doi producatori diferiti. Definirea (implicit si semnificatia) acelei zone se face prin niste structuri care se ataseaza SPL inainte de compilare, astfel incat fiecare dezvoltator poate muta anumite campuri, poate introduce parametri noi, spatii mai mari sau mai mici, etc. Exista sanse de coincidenta doar in cazul aparatelor nu prea indepartate ca generatie si obligatoriu produse de catre aceeasi firma. Desi la capitolul sectorului de date, trebuie sa amintesc aici si faptul ca, spre deosebire de coredll.dll, NK.exe = kernelul este cat se poate de specific unui anumit hardware, la fel ca driverele si deosebit de sensibil la locatia de memorie in care se gaseste... ceea ce inseanma ca, desi aparent sunt "clone" ale unui aparat, in interior ar putea diferi (NAND, display, etc), kernelul sa nu stie lucra cu acel hard. Asta inseamna ca jucandu-va de-a "flash-ul" cu un sistem provenit de la o alta clona, s-ar putea sa produceti o cat se poate de eleganta... caramida.
Precizez aici ca unele aparate nu au deloc o sectiune de date iar altele o pot avea in aceeasi partitie cu imaginea(imaginile). In acest din urma caz, de regula sectorul datelor urmeaza imediat dupa MBR, cu alte cuvinte sectorul nr.1 (numerotarea are 0 ca baza!)
Cum recunoasteti aceasta zona de date? Simplu: cautati prin dump cuvantul magic NTOC (care vine de la Nand Table of Content, se mai numeste "semnatura"). Dupa el vin niste canpuri cu informatii pentru niste setari hardware, apoi un alt cuvant magic: TOBE. Inaintea lui, pe 4 octeti, se gaseste versiunea iar dupa urmeaza 16 octeti alocati numelui SPL, apoi un flag care defineste tipul imaginii(4 octeti), apoi marimea sa in sectoare (4 octeti), adresa de memorie virtuala unde urmeaza a fi incarcat(4 octeti), adresa memoriei virtuale la care se lanseaza in executie (jump address, 4 octeti). De aici incolo gasiti o structura repetitiva pana la prima valoare zero, formata din 2 x 4 octeti: sectorul de inceput al segmentului si lungimea in sectoare al respectivului segment. Eu unul nu am vazut niciun ROM in care sa nu fi fost amplasata o anumita imagine pe o zona contigua de sectoare dar, dupa cum se vede, "constructorii" au prevazut si posibilitatea fragmentarii. Urmeaza un alt cuvant magic, de data asta neunitar. Puteti gasi HSFC, ISFC, etc. si aceeasi structura a datelor ca mai sus, insa pentru kernel. ROM-ul EVolio mai contine suplimentar adresa virtuala, locatia si lungimea xip-chain iar la final un checksum al intregului rom. Am amintit dar repet: nu toate romurile vor contine o asemenea sectiune. In unele cazuri se insereaza niste date in zona dintre cuvantul magic ECEC (inceputul oricarei imagini este adresa ECEC - 0x40) si inceputul codului executabil; spatiul este chiar generos, aproape 0x600 !. O alta particularitate este ca in cazul in care exista sectiune de date, de regula se reiau respectivele date in prima imagine din cele existente. Pe pozitia lui NTOC va fi ECEC, lipsesc datele pentru setarile hardware (cca 16 octeti) insa restul este identic cu ce gasim in partitia (sau sectorul) respectiv/a.
Despre partitia 1 mai pe scurt. Contine 3 imagini:
Imaginea 1 - kernel (adresa virtuala 0x8cb50000, lungime maxima 0x400000, contine 22 module (exe + dll) + 8 fisiere. Merita insirate doar pentru ca sa vedeti de ce anume este nevoie in faza II de boot: nk.exe, device.exe, atserisr.dll, binfs.dll, busenum.dll, ceddk.dll, coredll.dll, ddi.dll, devmdr.dll, diskcache.dll, fatfsd.dll, fatutil.dll, filesys.exe, flashdrv.dll,fsdmgr.dll, pm.dll, regenum.dll, sdmlc.dll, utldrv.dll si versionshow.exe. Astea au fost module, sunt si cateva fisiere: boot.hv (registrii pentru boot), default.hv (tot registri), initobj.dat, initdb.dat, tahoma.ttf, user.hv(ultima parte de registri), versionshow.lnk si wince.nls. O observatie importanta: desi kernelul are acces din rom toata structura de registrii, va lua de acolo doar setarile necesare pana la momentul in care sistemul de fisiere este initializat. Dupa acel moment, toate cheile sunt citite din partitia 3. Ordinea (probabila) de boot: nk.exe, coredll.dll, busenum.dll, device.exe care, la randul sau, incarca tot ce tine de sistemul de fisiere si nu numai.
Imaginea2 - drivere: 24 de module (dll) + 2 fisiere; cele 2 fisiere sunt un exe si un dll ce tin de gps;
- Imaginea 3 - tot restul: 128 de module + 62 fisiere.
Nu vreau s-o lungesc prea mult dar presupun ca s-ar putea naste intrebarea: care este diferenta dintre un modul si un fisier? In principiu sunt multe diferente, chiar si prin felul in care sunt amplasate in rom: modulele au fost separate in parti componente (sectiunea de cod, numita .text), sectiunea de date (.data), resurse (.rsrc), etc, pe cand fisierele sunt eventual comprimate dar intregi. Diferenta majora este ca modulele sunt XIP, adica sunt executate acolo unde sunt ele in NAND, pe cand fisierele sunt incarcate la nevoie pentru executie in RAM, deci "consuma" din ram-ul utilizator. Poate cu alta ocazie (si daca prezinta interes), v-as putea prezenta exact structura unui rom. Pana una-alta, va recomand pe aceasta tema un tutorial bun ("CE rom editing" la), dar incepand de la xip-chain are mici greseli, este usor confuz si incomplet in privinta structurilor de date. Probabil datorita faptului ca respectivul tutorial este mai degraba axat pe metodele de a modifica un rom, dar nu va bucurati prea tare: uneltele de acolo sunt valabile pentru CE3 si CE4 timpurii si doar pentru romul anumitor tipuri de aparate.
In incheiere, 3 avertismente:
1. Explicatiile sunt date mai sus: fara un backup adecvat, sa nu introduceti niciodata pe un card sd combinatia de fisiere chain.lst + chain.bin + TINYNK.bin (ori nk.bin) + drivers.bin si sa faceti hard reset cu cardul in aparat.
2. Chiar daca aveti un backup bun al SO si vreti sa flashuiti altul, nu cumva sa lasati pe sd un fisier numit eboot.bin (sau macar sa nu fie prezent in chain.lst), caci el este SPL; odata incarcat pe NAND, exista riscul ca sa nu functioneze din varii motive (sector de date, hardware, adrese, etc) si aparatul este definitiv scos din functiune. De aici mai poate fi salvat doar daca toate conditiile insirate mai jos sunt cumulativ indeplinite: a)exista un fisier bootabil al eboot.bin original; b)exista o copie bootabila a SO riginal(fisierele de la pct.2); c)exista un service sau oricine care este capabil sa reincarce eboot.bin prin JTAG.
3. Nu ma intrebati nici pe forum si nici pe privat cum se acceseaza meniul eboot; din fericire nu puteti intra in el prin nicio combinatie dintre butonul de stand-by si cel de oprire... Daca ajungeti suficient de avansati, veti descoperi singuri iar pana atunci este preferabil sa nu umblati pe acolo.
Modificat de ablbd (acum 14 ani)
_______________________________________
E400, Wayteq 770BT, Wayteq 920BT
|
|
Se conecteaza la calculator si se deconecteaza imediat dupa aia cu acel sunet specific din Windows cand scoti un device USB si-l introduci din nou. Daca-l las asa se conecteaza si se deconecteaza la infinit cred ca si cum as scoate si baga cablul usb mereu. 
, doar e scos de la naftalina, se mai poate face ceva???
