ablbd
Membru Senior
 Inregistrat: acum 15 ani
|
|
Topicul despre WAYTEC 770 (BT) este structurat pe doua capitole:
1) Primul capitol este de interes general si cuprinde prezentarea pe scurt a acestui PNA;
2) In al doilea capitol, ce are ca tinta pe cei (mai) avansati in Windows CE si nu numai, voi prezenta cateva ciudatenii pe care le-am descoperit in saptamana de cand il am.
I.Prezentare generala
Procesr Centrality Atlas III ARM 926T -400*MHz(se afirma in prospect!)
Display TFT 480x272 (nb stralucire foarte buna, se vede excelent si pe soare puternic)
Flash disk intern de 2GB, RAM 64MB
Windows CE5.00 (Build 1400) cu suport SDHC
ActiveSync implicit, comutabil pe Mass Storage
*In realitate 324MHz; specificatiile de fabrica sunt 396MHz, insa n-am auzit de niciun aparat echipat cu acest procesor care sa mearga mai sus de 324MHz.
Nota: cand se comuta de pe ActiveSync pe Mass Storage, aparatul se reseteaza si intra in regim Mass Storage la introducerea cablului USB, numai ca pe ecran persista o imagine ce arata conexiunea si nu se poate face nimic in timpul asta; apasarea bulinei rosii din coltul dreapta-sus readuce meniul dar intrerupe legatura Mass Storage. Voi reveni cu detalii asupra acestui aspect in partea a 2-a.
Vizualizare fotografii, player audio, player video
Navigatie IGO 8.0.0 FE
Suplimentar fata de acestea, varianta Wayteq 770BT are in plus:
Bluetooth – functioneaza ca HandsFree simultan cu navigatia
Modulator FM :
-in regim de navigatie si/sau hands-free transmite pe o frecventa selectabila fie vocea navigatiei fie semnalul de la telefon; permite formarea de numere pe o tastatura cat ecranul
-in regim audio-video transmite coloana sonora;
Icoanele din dreapta permit conectarea la internet prin intermediul telefonului; modalitatea de conectare (GPRS/3G) depinde de telefon
*cu softul original nu merge simultan navigatia si playerul audio, dar exista solutii pentru orice, nu-i asa? :D
II. Ciudatenii (*pentru avansati)
Dat fiind ca aparatul are suport SDHC, primul lucru a fost sa cercetez registrii (remote, cu CeRegEditor). Mi s-a parut firesc sa gasesc \Drivers\BuiltIn\SDBusDriver si corespondentul sau Drivers\SDCARD cu tot tacamul de sub el. Surpriza a fost ca in directorul \Windows nu exista nici SDBus.dll si nici SDMemory.dll, prin urmare chestiunea a fost rezolvata fara aceste drivere "clasice". Am gasit \Drivers\SDMMC si dll-ul aferent, de 34KB, cam dublu fata de fratiorul mai mic din .Net 4.2 si CE5 timpurii, care erau fara suport SDHC.
O alta chestiune intriganta a fost prezenta unei chei: \Drivers\BuiltIn\NewFlashDrive:
Mergand pe fir, gasesc o structura extrem de ciudata la definirea sistemului de fisiere:
Remarcati cheia MYFATFS ! In tabela de partitii i s-a creat un nume nou: 41 (in hex) si toate indiciile duceau catre o partitie FAT ascunsa. Am modificat cheile de protectie care o faceau ascunsa, insa nimic. Atunci am realizat ca discul flash este montat in cursul procesului de boot folosind copia registrilor aflata in ROM (Boot.hv), deci orice setare din registrii nu mai e luata in seama. Si totusi se poate, printr-un artificiu:
se pune MountHidden = DW:0 peste tot unde apare MYFATFS (definit ca “ResidentFlash2”), apoi din Storage Manager selectez “Properties” pentru partitia 01, “Dismount” si apoi “Mount”. De asta data este obligat sa citeasca registrii, drept pentru care apare un nou folder numit (cum altfel?!) ResidentFlash2. Ei bine, aici se gasesc toate programele si dll-urile ce deservesc YFLoader.exe (meniul principal, prima poza). Ba mai mult, desi YFLoader.exe face parte din ROM, el are atribut de “file” si se poate copia in voie, la fel si toate dll-urile aferente Framework 2.0 (implementat de producator) precum si o serie de alte fisiere din \Windows.
Partea frmoasa abia acum urmeaza. Discul flash are 4 partitii: P00 – 25MB, P01 – 50MB, P02 – user si P03 –hive. La limita, un ROM ar putea incapea in 25MB, dar ce este cu partitia 1? Stiu deja ca are inglobata si o partitie FAT, insa fisierele de acolo au in total 14,2 MB, deci raman cca 35MB liberi. Parca mai seamana cu dimensiunile unui ROM ;)
Pasul urmator a fost sa copiez fizic cele 2 partitii pentru a putea vedea ce e in fiecare. In mod cert una dintre ele trebuie sa contina ROM-ul, dar atunci ce e in cealalta? Copiile le-am facut tot remote, folosind “pdocread” -ul lui itsme ), cel mai recent zip.
Verific rapid cu un hexeditor daca partitia 0 contine un header de ROM si constat ca el este prezent.
(O paranteza mai mare)
Procedeu (pentru cine nu stie): puneti hexeditorul sa caute in imaginea binara secventa (in hex) FE 03 00 EA si verificati daca la offsetul 0x40 se gaseste sirul ascii ECEC. Daca ambele elemente sunt prezente, in mod cert avem de-a face cu un ROM entry.
Pentru posesorii altor tipuri de aparate si vor sa experimenteze:
Se poate intampla in unele ROM-uri ca prima secventa sa nu fie prezenta. In cazul acesta cautati prima aparitie a sirului ECEC si verificati daca este sau nu o intrare valida in ROM. In primul rand, daca primul caracter din ECEC nu se gaseste intr-o adresa multiplu de 4, cautati urmatoarea sa aparitie.
Verificare: primii 4 octeti dupa "ECEC" reprezinta adresa virtuala (little endian) unde se va incarca imaginea si ar trebui sa fie de forma xx xx xx 8x. Motivul este ca adresa virtuala la care se incarca ROM-ul trebuie sa fie >= cu 0x80000000; important este sa fie >8x . Urmatorii 4 octeti (little endian) reprezinta offestul adresei fizice unde incepe headerul ROM. Aceasta trebuie sa fie o adresa rezonabila, adica pe de o parte sa fie in interiorul spatiului de 32MB si pe de alta parte sa fie in interiorul imaginii binare. Nu uitati ca un ROM poate contine imagini multiple, fiecare dintre acestea incepand cu "ECEC" si ca secventa ECEC trebuie in mod obligatoriu sa se gaseasca la o adresa multiplu de 4.
Secventa FE 03 00 EA reprezinta in cod masina o instructiune de salt neconditionat la offset 0x1000 fata de adresa primului byte (FE). Cum datele sunt in little endian, instructiunea arata de fapt EA 00 03 FE:
- bitii 31-28: conditie (in cazul nostru 0xE ,1110) = salt neconditionat
- bitii 27-25 : opcode (in cazul nostru 101 ) = salt;
- bitul 24: felul saltului (0=simplu, 1=cu retur la adresa din R14); la noi este 0, deci urmatorii 4 biti au valoarea 0xA = salt simplu fara retur
- bitul 23: semn
- bitii 22-0: offsetul unde se face saltul; inainte de executie, bitul 23 (daca e prezent) trece in carry iar bitii 22-0 sunt deplasati spre stanga cu 2 pozitii (echivalentul inmultirii cu 4) iar rezultatul se aduna la PC; acest sistem permite salt inainte sau inapoi intr-un domeniu de +-32MB
**Nota la calculul adresei ** procesorul ARM are un pipe-line de 3 instructiuni, ceea ce inseamna ca la momentul executiei efective PC a fost incrementat cu 8 (2 instructiuni).
In atare conditii, offsetul de salt va fi (0x3FE)*4 + 8 = 0x1000
(inchid marea paranteza)
Dumprom (tot de la itsme) gaseste in partitia 0 o singura imagine valida (cea a kernelului) si mai gaseste o intrare valida dar care excede spatiul partitiei P00. Acelasi dumprom in partitia P01 gaseste si cea de-a doua imagine, drept pentru care apar in directorul de lucru toate fisierele din \windows. Mai pe scurt: partitia 0 contine doar kernelul iar partitia 1 contine tot ROM-ul. Cercetand putin partitia 0, gasesc ca la adresa 0x20000 incepe un cod enorm, foarte probabil ca fiind boot loader, ce tine pana aproape de 0x180000 unde incepe ROM (doar cu kernel). Asta e o veste buna, deoarece multe PNA-uri nu poseda asa ceva, ci doar un bootstrap (un cod mititel care incarca direct sistemul de operare). Oricum, am devenit curios aspupra motivului existentei kernelului si in partitia 0, adica daca ajunge vreodata sa fie executat ori ba.
Stiind ca acest "pdocread" copiaza fizic toate datele din partitie, primul bloc are o importanta mare, desi la prima vedere pare o aiureala: aici se gaseste MBR (Master Boot Record). Nu mi-am propus sa prezint semnificatia tuturor datelor din MBR ci doar a acelora care sunt relevante cazului de fata, si anume: exista 4 seturi succesive de 16 octeti, cate unul pentru fiecare partitie. Primul set incepe la offset 0x1BE (fata de inceputul MBR). Ultimii 2 octeti dim MBR au valorile 0x55 si 0xAA, reprezentand semnatura “Boot record”.
Semnificatia celor 16 octeti aferenti unei partitii este
a) offset 0 : Indicator de boot (0x80 pentru partitie activa, 0 altfel)*
b) offset 1-3: CHS de inceput (Cylinder, Head, Sector)
c) offset 4: Descriptor pentru tipul partitiei**
d) offset 5-7: CHS de final
e) offset 8-11: Pozitia primului bloc de date din partitie [sectoare]
f) offset 12-15: Marimea partitiei, [sectoare]**
*WINCE poate sa nu respecte aceasta conventie, punandu-si incatoare proprii
**Valori raportate de Storage Manager sau alte utilitare
Mai trebuie amintit ca un sector are 512 octeti (0x200) si ca de regula datele de CHS sunt irevelante.
Dupa aceasta introducere, iata setul din MBR partitia 0:
PO c)=0x21; e)=0xC000; f)=0xC000
P1 c)=0x41; e)=CC00; f)=18000
…..
Sa vedem ce face sistemul de gestionare al fisierelor, fie ca este unul propriu boot loaderului fie ca lanseaza driverele aferente in baza unei codari directe din partitia 0 dupa hard reset: deschide MBR din p0 si citeste datele referitoare la p0 (important-creaza un handle pentru partitia 0); gaseste acolo ca sectorul de inceput este la offset 0xC000, numai ca acest sector este de fapt primul sector al partitiei 1 (lungimea totala a partitiei 0 este tot 0xC000, a se vedea valoarea f) ). Acolo gaseste tot un MBR, dar stie sa trateze problema considerandu-l un EBR (Extended Boot Record), prin urmare citeste noul set de date aferente partitiei 0:
P0 c)=0x21; e)=0xC00; f)=C000
P1 c)=0x41; e)=CC00; f=18000
……
Valoarea P0 -> e) ii spune sa mearga la offsetul 0xC00 * 0x200 = 0x180000, unde gaseste "ROM start" asa cum l-am descris mai sus. IMPORTANT: in acel moment, file managerul (oricare ar fi el) inca mai considera ca este in partitia 0, desi citeste si incarca ROM din spatiul fizic al partitiei 1!! Dupa ce se incarca sistemul, handlerul este eliberat si lucrurile reintra in normal. Raspunsul pare clar: dupa un hard reset, sistemul foarte probabil ca nu va folosi copia kernel din partitia 0 decat cel mult punctual, pt anumite drivere. Nu se stie insa ce ar face boot loaderul daca din cauza unor erori grave nu ar putea incarca ROM-ul din partitia 1 in spatiul virtual; este posibil ca in aceasta situatie sa apeleze (integral) la kernelul de rezerva, oferind utilizatorului posibilitatea refacerii partitiei 1 sub un Windows minimal dar functional. E de amintit faptul ca imaginea din partitia 0 contine inclusiv driverul pentru flash disk precum si structura integrala a registrilor cumuland fisierele boot.hv, default.hv si user.hv. Subiectul acesta ramane deschis pana cand reusesc sa vad ce face codul respectiv, banuit cu temei a fi un boot loader veritabil. Studiul codului respectiv ar putea duce si la aflarea mecanismului de activare a meniului sau, ceea ce ar insemna un mare pas inainte.
Cateva observatii despre regimul Mass Storage. Deservirea acestui mod se face de un soft dedicat, aflat in folderul ResidentFlash2, pe nume USBConnect.exe. O parte a dependentelor externe se gasesc in acelasi folder , restul (coredll.dll si mfcce400.dll) in \Windows.
Inainte de reset, meniul de comutare modifica niste chei specifice regimului mass storage / ActiveSync (HKLM\Drivers\USB\FunctionDrivers\ClientDriver: "\Drivers\USB\FunctionDrivers\Mass_Storage_Class" sau Serial_Class si DefaultClientDriver intre "\Mass_Storage_Class" sau "\Serial_Class"); mass storage va merge doar atata timp cat este activ programul USBConnect. Interesant este faptul ca acest program realizeaza conexiumea mass storage folosindu-se de un driver din suita bluetooth, mai exact de BTDRV.dll, in conditiile definite la HKLM\Drivers\BuiltIn\BTPort. In timpul conexiunii se creaza un proces activ pentru portul COM2:, mentinut doar atata timp cat programul USBConnect este in executie. Ar mai fi de adaugat ca pe durata conexiunii sistemul nu "vede" nici nand-flash si nici vreun card extern, asa ca nu e intamplator faptul ca in regim mass storage persista cu incapatanare acel ecran.
Respectivul pachet ar fi o optiune interesanta pentru aceia care isi doresc temporar o asemenea conexiune, insa este nevoie de un btdrv.dll incarcabil in memorie, deoarece cel din ROM este XIP (ii lipseste tabela de relocare). Poate ca odata voi reface aceasta tabela pentru dll-ul in cauza, dar daca cineva dintre voi este in posesia unuia care se poate incarca in RAM, sunt dispus la continuarea imediata a proiectului "mass storage".
23.2KB
Modificat de ablbd (acum 15 ani)
_______________________________________
E400, Wayteq 770BT, Wayteq 920BT
|
|
... ca loc in rom este berechet (cca 1,4 MB liber) care prin compresie inghite echivalentul a 2,8-3MB de fisiere necomprimate.
Poate ma poti ajuta.