QPC Tips: September 2010

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

Procesor 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 (http://www.xs4all.nl/~itsme/projects/xda/tools.html), 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".

NOTE:
1) Se poate intra direct in windows explorer FARA EDITARE DE REGISTRI sau modificari de orice fel:
-creati cu notepad sau similar in radacina unui card SD un fisier cu numele YFGo2CE.bld care sa contina macar un caracter(lungimea minima de 1 octet); ATENTIE, numele fisierului este case sensitive, luati exact denumirea pe care v-am dat-o!!!
-introduceti cardul si fie resetati prin gaura din dreapta, fie faceti hard reset din optiunea data de soft;
-dupa pornire va intra in ecranul windows
-scotand cardul si resetand din nou, revine in meniul initial

2) Puteti schimba usor imaginea de logo cu orice imagine doriti.
-selectati imaginea dorita si o aduceti exact la dimensiunea de 480x272 pixeli, apoi o salvati in format BMP cu 24 biti culoare si denumirea (!!case sensitive!!) Logo72C.bmp
-plasati imaginea in radacina unui card SD , introduceti cardul si apoi hard reset

*** dupa incarcarea imaginiii stergeti fisierul bmp, deoarece la fiecare hard reset o va incarca din nou ***

3) Cum spuneam mai sus, instalarea unui soft de navigatie de pe card prevaleaza softului propriu de pe flash disc (cititi comm-ul anterior)

4) Exista posibilitatea (extrem de simpla) a reinstalarii ROM si/sau a boot loaderului, tot de pe card SD; nu voi da numele acestor fisiere pentru a nu tenta pe nimeni de a experimenta in necunostinta de cauza. Daca cineva, vreodata, pasionat de bucataria de rom-uri, va modifica un ROM pentru a-i include programe(dll-uri) suplimentare, sa-l creeze in format .img si sa ma contacteze pe privat. De asemenea, printr-o secventa magica plasata intr-un fisier text se poate chiar formata discul intern nand... . Evident, toate acestea sunt facilitati oferite de catre boot loader.

Muncind la dezasamblarea boot loaderului (rezultatele partiale se vad deja in commul anterior), am dat peste instructiunile prin care apeleaza coprocesorul: ii zice p15 (coprocesor15) . Iata cum arata o astfel de instructiune(comentariul imi apartine):
0020138: ee110f10 mrc p15,0x0,r0,c1,c0 ;requests co-proc15 to perform op0 on c1&c0, res in r0

As mai adauga pentru cei interesati ca partitia ascunsa se poate accesa temporar deschizand cu orice explorer discul ResidentFlash si sus in bara se lipeste dupa nume cifra 2, apoi ok

Cat despre WINCE6, asta a aparut demult, deja a ajuns la versiunea 4 (wince6.4)... chiar si eu am generat cateva romuri experimentale (pt studiu) cu platform builder 6.

Precizare:
Toate trucurile prezentate se refera la WAYTEQ 770, dar pot (eventual) functiona si pe alte aparate chinezesti daca sunt indeplinite cumulativ urmatoarele conditii:

1) in \windows exista un executabil cu numele YFLoader.exe
2) este prezent directorul ascuns ResidentFlash2 si in aceast director gasiti un subdirector cu numele YFAP20, YFAP30 sau YFAPP

Nota:
Rescrii SO cu formatare. Pune langa fisierul img si un YFormat.bld care sa contina sirul "666F726D6174" fara ghilimele. Il faci cu Notepad pt ca asta nu adauga caractere de control.

QPC Tips

Monday 20 September 2010

(Aproape) totul despre WAYTEQ 770(BT)

ROM DUMP - A practical guide

Saturday 11 September 2010

Links

Friday 3 September 2010

China GPS (YF) - Adding a new item in the menu