Czwartek, 23 Październik 2014, 13:42

Autor Wątek: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa  (Przeczytany 15051 razy)

0 użytkowników i 1 Gość przegląda ten wątek.

Offline baniaczek

  • GZU
  • Swojak
  • ****
  • Wiadomości: 137
  • Podziękowań: 16
  • Płeć: Mężczyzna
  • Nokia e63-1 [200.21.012]
Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« dnia: Sobota, 05 Kwiecień 2008, 16:02 »
Źródła: na podstawie różnych informacji z xda-developers.com, mobione.pl, msdn i xdaflameusers.com. W załączniku też znajdziesz mnóstwo informacji. Załącznik pochodzi z http://diozoli.click.hu/keret.cgi?/usfull%20progs/romtoolpack/documents 

Niniejszym udzielam zgody na przetłumaczenie tego tekstu na inne języki oraz rozpowszechnianie, ze wskazaniem źródła tekstu.

Kiedyś wstawię to do mobiwiki.

---------

W większości wypadków metoda opisana tu: http://mobione.pl/index.php?page=porting_ROM_porting jest wystarczająca, w szczególności przy przenoszeniu XIPa między urządzeniami o podobnej organizacji pamięci (np. większość nowszych HTC bez względu na typ).

Po przeprowadzeniu całej procedury: ROM będzie zawierać sekcję XIP, do której będzie można mieć pełne zaufanie, że jest poprawna (albo palmtop po prostu nie włączy się). 

---------

Opis dotyczy przenoszenia sekcji XIP [czyli podstawowego fragmentu odpowiadającego za załadowanie sterowników, podstawowych bibliotek itp].
Opis powstał po przeniesieniu XIP z Kaisera 6.1 build 19209, do BlueAngela 6.0 build 18125. Powstał BlueAngel 6.1 build 19209.
Oba urządzenia różnią znacznie - zarówno sterownikami, jak i organizacją pamięci ROM.

Opisaną procedurą nie zmienisz radykalnie wersji systemu (np. z 5.0 na 6.0). Zmiana z 6.0 na 6.1 powinna się udać.

Zmiana wymaga mniej więcej dwóch godzin pracy, benedyktyńskiej cierpliwości i dużej systematyczności - łatwo można pomylić się w dziesiątkach miejsc i całość nie zadziała. Zadanie jest tylko dla zaawansowanych - w sytuacjach niepewnych musisz zdawać sobie sprawę z tego, co robisz i jakoś to rozstrzygnąć. Bo jak nie - to klapa.

Proszę nie pytać - "co robić? - przeniosłem i nie działa". Pewnie gdzieś się pomyliłeś. Zrób to jeszcze raz, tylko uważniej. Tą metodą przeniosłem cztery różne XIPy do BlueAngela i wszystkie działały stabilnie.

--------- Narzędzia:

Potrzebujesz:

XIPport (autor: bepe@xda-developers) i RomMaster (autor: gmap@xda-developers): http://mobione.pl/uploads/rom_tools/XIP_extract.rar (w sieci krąży kilka wersji obu narzędzi; te z podanego linku są sprawdzone i dobre).

M'Reloc (autor: misar@xda-developers): http://mobione.pl/uploads/rom_tools/MReloc.zip Uwaga: M'Reloc ma małe błędy w obsłudze interakcji z człowiekiem. Po pierwsze: nie działa Ctr-C i Ctr-V (trzeba posłużyć się prawym klawiszem myszki). Po drugie: jeśli coś zmienisz (wklejając tekst prawym klawiszem myszki) w polach przeznaczonych na wpisanie adresów, to klawisz "DoIt" pozostaje szary (nieaktywny). Zrób cokolwiek używając klawiatury (np. wciśnij kursor w lewo), to się polepszy. Po trzecie w założeniu klawisz "DoIt" ma być nieaktywny, jeśli nic się nie zmieniło we wspomnianych polach adresowych. M'reloc czasem ma problemy z rozpoznaniem, czy coś się zmieniło, czy nie. Jeśli się zmieniło, a M'reloc uważa, że nie, to trochę z nim powalcz. Zmień coś jeszcze, wciśnij DoIt, zmień jeszcze raz (na wartość, która powinna być), wciśnij DoIt. Tylko ostrożnie - nie pomyl się.

Jeśli portujesz ROM Etena albo Mio (XIP jest skompresowany), to przyda się "srpxtool" ze "scoter kitchen".

Dobry edytor do plików tekstowych: notepad jest stanowczo za słaby. Zawsze i wszędzie polecam wszystkim UltraEdit: http://www.ultraedit.com . On jest warty niebagatelnej ceny $50. Z miliona cech funkcjonalnych UltraEdita w naszym wypadku przyda się: możliwość edycji wielu plików jednocześnie i umiejętność śledzenia zmian w edytowanym pliku (no nie wiem, jak to napisać - jak masz otwarty jakiś plik w edytorze i coś albo ktoś ten plik zmieni, to ultraedit sam bez zawracania głowy sam go załaduje i będziesz widzieć nową wersję) (tę funkcję trzeba włączyć w opcjach, bo standardowo jest wyłączona).
mobi poleca notepad2: http://www.flos-freeware.ch Cytuję: "jest darmowy, posiada bardzo wiele przydatnych funkcji, głównie to zmiana kodowania plików (ansi, unicode, utf itd) funkcje o której wspominasz, tzn. jak edytujesz jakiś plik i otworzysz go w innym oknie, zapiszesz, to poprzednia wersja poinformuje o zmianie z pytaniem czy odświeżyć zawartość. Jest to w razie co, dobra alternatywa dla 50$, które nie każdy ma na wydanie na edytor".

Kalkulator, który umie liczyć szesnastkowo. Wystarczy standardowy kalkulator z Windows po przestawieniu w opcjach w tryb naukowy. Albo licz w pamięci, tylko się nie pomyl.

No i musisz sprawnie funkcjonować w shellu (cmd.exe albo command.com). A jeśli sprawnie używasz poleceń shella, to kiedyś zastanów się nad przejściem na 4NT (http://jpsoft.com) - w 100% kompatybilny z cmd.exe, a dodaje do shella setki nowych poleceń, opcji, funkcji i zmiennych.
Podane tu polecenia (np. "rommaster ....", "set _flatreleasedir=." i podobne) traktuj jako przykłady - one muszą być wydawane z dobrego katalogu bieżącego, parametry mogą być inne, itd., itp.
Ponownie: jeśli nie wiesz, o co tu chodzi to ten artykuł nie jest dla Ciebie.

--------- Surowce:

Będziemy pracować z plikami XIP.BIN: tym z Twojego urządzenia i tym, który chcesz zaimportować. Pliki te będziemy rozkładać na różne sposoby, składać i modyfikować. Na zakończenie efekt naszej pracy, nowy, śliczny i pachnący XIP.BIN trzeba będzie wstawić do ROMu (czyli do pliku z rozszerzeniem .nb albo .nba), być może ROM trzeba będzie przegotować - jeśli zmiany będą poważne (czyli trochę pozmieniać katalog dump) i przeflaszować. O przegotowywaniu ROMU i flashowaniu nic nie będę pisać - jeśli nie wiesz, jak to się robi, to ten artykuł nie powinien Ciebie interesować.

Dotyczy XIPa/XIPów, które będziesz importować (czyli wkładać do swojego ROMu): Duża część (jeśli nie większość) sekcji XIP z ROMów przygotowywanych na xda-developers jest marnej jakości. Albo mapa się nie generuje, albo boot.hv jest nie zmieniony, albo inne zastrzeżenia można mieć. Spróbuj poszukać ROMu fabrycznie nowego. Nie ważne, z jakiego urządzenia, ważny jest numer wersji systemu i numer builda (bo właśnie tę wersję i ten build wyprodukujesz).

Mogą przydać się też XIPy z innych urządzeń albo inne ROMy z Twojego urządzenia (tu już możesz bez obaw używać ROMów przygotowanych przez innych zapaleńców). Potraktuj je jako kopalnię sterowników - może ktoś kiedyś znalazł nowszy sterownik do czegoś (np. sterownik pamięci albo sterownik do któregoś filesystemu). Ten etap pracy zostaw sobie na deser (prawdopodobnie Twoje sterowniki są wystarczająco dobre), ale jak się bawić, to na całego.

No i będzie Ci potrzebny działający XIP z Twojego urządzenia. Tam są niezbędne sterowniki, nk.exe i parę innych plików, bez których raczej nic nie zdziałasz.

--------- Ekstrahujemy XIP:

XIP wyciąga się z rozkodowanego pliku *.nb albo nk.nba (w przypadku nowszych HTC to jest jeden z plików, które powstają po "NBHextract RUU_signed.nbh", w przypadku starszych - po "xda3nbftool -t -x nk.nbf nk.nba". To nie jest plik *payload* ani imgfs_raw_data.bin).

XIP.BIN powstaje po: "RomMaster.exe nk.nba -w 5 -b 0x310000 -x -o xip.bin", gdzie nk.nba to jest ten plik wspomniany powyżej, powstanie xip.bin, a 0x310000 to jest adres, pod którym siedzi XIP.

Jeśli nie działa, czyli jeśli dostaniesz takie coś:
[Info]          It is a common ROM.
[Error]         File is damaged, end address small than start address.
[Error]         File is damaged, end address small than start address.
To spróbuj inaczej:
BlueAngel: RomMaster.exe nk.nba -w 5 -b 0x1C0080 -x -o xip.bin
Himalaya: RomMaster.exe nk.nba -w 5 -b 0x1C0040 -x -o xip.bin
Albo tak: RomMaster.exe nk.nba -w 5 -b 0x320000 -x -o xip.bin
Albo po prostu: RomMaster.exe nk.nba -w 5 -x -o xip.bin (może RomMaster sam zgadnie, gdzie jest XIP)

Dla swojego urządzenia musisz znać ten adres (żeby potem wiedzieć, gdzie załadować nowy XIP), dla pozostałych wystarczy, ze uda Ci się wyciągnąć XIP.BIN z ROMu.

Jeśli dostaniesz zestaw ostrzeżeń, np. takich:
[Info] It is a common ROM.
[Warning] o32_rom(0x8036ced4)'s o32_data at 0x00000000 is zero.
[Warning] Found dif-referenced region [OLD] Address=0x80256208 Length=0x00000c00 ObjectType=0x00200000
[Warning] Found dif-referenced region [New] Address=0x80256208 Length=0x00000c00 ObjectType=0x00008000
[Warning] Memory Block(0x801c1000,0x8024c01c) overlap with Block(0x801c2ff4,0x801c3020).
[Info] New rom filename is 'xip.bin'.
nie przejmuj się. Ważne jest, czy masz plik XIP.BIN

Jeśli masz tu do czynienia z ROMami Etena, Mio albo innymi, w których XIP jest skompresowany (SRPX) - poczytaj instrukcje ze "scoter kitchen" i poszperaj na www.eten-users.eu. (Uwaga: nie wszystkie XIPy z tych urządzeń są kompresowane).

Jeśli nadal nie możesz wydłubać XIPa, to zapytaj googla o rommaster (może jakiś przykład się znajdzie).

Jeśli nadal masz trudność - obejrzyj plik nk.nba. Poszukaj w nim ciągu znaków "ECEC" (on występuje w kilku miejscach) i spróbuj użyć adresu mniejszego o 0x40 (czyli o 64) niż miejsce wystąpienia sygnaturki "ECEC". Może się udać (zdekoduj i zobacz co dostałeś).

Niektóre ROMy mają więcej niż jedną sekcję XIP. Nas tu interesuje ta, w której siedzi plik nk.exe (za chwilę będzie o dekodowaniu xip.bin).

--------- Dekodujemy XIP.BIN:

Czynności tu opisane powtórz dla każdego pliku XIP.BIN (tymi, z którymi będziesz pracował):
- utwórz katalog i go jakoś nazwij (tak, żebyś wiedział co masz gdzie).
- skopiuj do niego XIP.BIN,
- skopiuj do niego XIPPort.exe i pkgcommon.dll.
- uruchom XIPPort.exe (w danym katalogu),
- wciśnij "dump xip.bin" (powstanie podkatalog "OUT"), a w nim dwa podkatalogi "Files" i "Modules"),
- wciśnij "make pkgs" (zawartość podkatalogów "Files" i "Modules" znacznie się przeorganizuje),
- zmień nazwę katalogu "OUT". Na przykład na "Packages",
- ponownie wciśnij "dump xip.bin" (ponownie powstanie podkatalog "OUT" z zawartością),
(te czynności wykonaj tylko w katalogu, w którym siedzi xip.bin z Twojego urządzenia, w pozostałych możesz pominąć):
-- wciśnij "build xip_out.bin"
-- zanotuj sobie gdzieś wielkość pliku xip_out.bin. W bajtach, a nie tak, jak Windows pokazuje, "dir xip_out.bin" może sie przydać :)
-- wciśnij "write maps" (jeśli XipPort wywalił się z błędem, to poczytaj dopisek w tej części)
-- skasuj xip_out.bin. Interesowała nas tylko jego wielkość.
(i znowu wykonaj czynności we wszsytkich katalogach.):
- skasuj pliki XIPPort.exe i pkgcommon.dll. Żeby nie rozpraszały uwagi (ułatwi to systematyczną pracę).

*) jeśli XipPort wywalił się z błędem przy "write maps":
coś już wspominałem o marnych ROMach nie fabrycznych? Usiłujemy tu wygenerować plik "MAP.txt" - mapę rozlokowania plików i modułów w sekcji XIP. Tylko po to, żeby ją sobie obejrzeć. Jak się nie da, to nie ma co wykonywać wysiłku.

--------- Wielkość XIP:

XIP jest mały. Bardzo mały. Często za mały.
Zaledwie klika megabajtów. W zasadzie nie ma tam miejsca, żeby coś dodać. Może się zdarzyć, że okaże się, że nowy XIP nie mieści się w przeznaczonym dla niego miejscu. Trzeba będzie coś usunąć (to znaczy usunąć z XIP i dodać do samego ROMu, czyli do katalogu dump, albo do kuchni). Usuwać (czyli przenosić) trzeba z rozwagą, bo jednak grzebiemy przy plikach, które są odpowiedzialne za początek procesu ładowania systemu operacyjnego.

Nie sugeruj się wielkością pliku XIP.BIN. RomMaster ekstrahuje go na podstawie nagłówka części ROMu, a ten nagłówek nie musi być prawidłowy. Możesz założyć, że ten nagłówek jest wystarczająco dobry, żeby ROM nie był uszkodzony. W zasadzie możesz założyć, że nagłówek jest błędny. Później będzie mowa o parametrach "physfirst" i "physlast" (i ewentualnej korekcie) - one odpowiadają za określenie ilości miejsca na XIP.

Np. w przypadku BlueAngela: xip.bin ma 3,561,326 bajtów, podczas, gdy sam XIP może mieć co najwyżej 2,883,552 bajtów. Jeśli spróbuje się pop prostu zmienić nazwę "xip_out.bin" na "xip.bin" i włożyć taki "xip.bin" do ROMu, a ROM do BlueAngela, to BlueAngel nie wystartuje :(

Wiesz tylko tyle: obszar przeznaczony na XIP jest nie jest mniejszy niż (wcześniej zanotowana) wielkość pliku xip_out.bin, wygenerowanego po "dump xip.bin" i "build xip_out.bin".
Nie mam pojęcia, ile masz miejsca w sekcji XIP. Jak już skończysz przenoszenie XIPa, to:
- porównaj wielkość pliku xip_out.bin (tego który otrzymasz jako rezultat swojej pracy) z tą wielkością uprzednio zanotowaną (oryginalnego xip_out.bin),
- zajrzyj do pliku z ROMem (nk.nba) (z punktu "Surowce"),
- skocz do adresu, pod którym siedział oryginalny XIP (adres znasz z punktu "Ekstrahujemy XIP"),
- przeskocz o tyle bajtów, ile miał oryginalny xip_out.bin (nie "xip.bin"),
- obejrzyj dokładnie zawartość tylu bajtów, o ile będą różnić sie wielkości nowego i oryginalnego xip_out.bin
- ten obszar pamięci zostanie zamazany nowym XIPem. Zastanów się, czy nie widzisz tam nic niepokojącego. Choćby jednego bajtu różnego od 0xFF i 0x00.

--------- Kontemplujemy XIP - nagłówki ROMu i mapy alokacji:

W katalogu OUT znajdują się dwa bardzo ważne pliki:

Mój PARTHDR.txt:
   ulRomUnknown:          EA0003FE
   dwRomHdrAddress:       0000CD08
Nie mam pojęcia, co tu jest opisane, ale plik jest niezbędny do modyfikacji XIP.

Mój ROMHDR.txt:
   dllfirst:            D=01FA01FE
   dlllast:               02000000
   physfirst:           P=801C0000
   physlast:              8052576E
   nummods:              (00000000)
   ulRAMStart:          R=901F0000
   ulRAMFree:             90276000
   ulRAMEnd:              98000000
   ulCopyEntries:        (00000000)
   ulCopyOffset:        P+000A3FE8
   ulProfileLen:          00000000
   ulProfileOffset:       00000000
   numfiles:             (00000000)
   ulKernelFlags:         00000000
   ulFSRamPercent:        00000004
   ulDrivglobStart:       00000000
   ulDrivglobLen:         00000000
   usCPUType:             000001C2
   usMiscFlags:           00000002
   pExtensions:         P+00002FF4
   ulTrackingStart:       00000000
   ulTrackingLen:         00000000
Znaczenie poszczególnych linii ROMHDR.txt jest opisane tu: http://msdn2.microsoft.com/en-us/library/aa908726.aspx
W szczególności:
Różnica physlast i physfirst jest wielkością xip.bin. Jeśli wiesz dokładnie, ile masz miejsca na sekcję XIP, to sprawdź i ewentualnie popraw "physlast" - XipPort ją honoruje, a jak się nie mieści to informuje w mapach alokacji o błędach. physfirst+physlast nie może zachodzić na ulRAMStart.
Wartości dllfirst i dlllast będziemy niedługo stale oglądać sprawdzając mapy alokacji XIP.

MAP.txt:
MAP.txt powstaje po wciśnięciu "write maps" w XipPort.
Nas będzie interesować przez cały czas pracy początek tego pliku aż do
801c0000 - 801c0000 L00000000 Start: first physical addressNa zakończenie pracy jednym z kryteriów poprawności XIP jest: "w pliku MAP.txt nie może znaleźć się ani jeden znak wykrzyknika".

MAP.physical.txt:
MAP.physical.txt powstaje po wciśnięciu "write maps" w XipPort.
Nas będzie interesować tylko na zakończnie pracy - jednym z kryteriów poprawności XIP jest: "w pliku MAP.physical.txt nie może znaleźć się ani jeden znak wykrzyknika".

--------- Kontemplujemy XIP - pliki i moduły:

Jeden plik z XIP jest reprezentowany w katalogu OUT przez dwa pliki: jakis_plik i jakis_plik.imageinfo.txt. Zawsze trzeba operować (dodawać, usuwać, zmieniać) na parze plików.
Gdyby zaszła potrzeba dodania do XIP jakiegoś pliku, to trzeba wytworzyć dla niego .imageinfo.txt. Ostrożnie - XipPort jest wrażliwy na odpowiednie liczby spacji w poszczególnych liniach. Najprościej jest skopiować jakieś inne .imageinfo.txt i zmienić:
  File name: sysroots.p7b
   dwFileAttributes:      00000007
   ftTime:                01C6E6BEA69B2D00
   nRealFileSize:         000039A5
   nCompFileSize:         000039A5
   lpszFileName:        P+000B3FD4
   ulLoadOffset:        P+000E94C0
W pierwszej linii - nazwa pliku,
dwFileAttributes zazwyczaj wynosi 7 (read_only = 1, hidden = 2, system = 4, itd. - trzeba dodać odpowiednie wartości),
ftTime - niech zostanie jakiekolwiek,
nRealFileSize i nCompFileSize - wielkość pliku (raczej takie same),
lpszFileName i ulLoadOffset zostaw byle jakie - same się potem poprawią.

Jeden moduł z XIP jest reprezentowany w katalogu OUT przez: katalog z częściami modułu i plik jakis_modul.txt. Zawsze trzeba operować (dodawać, usuwać, zmieniać) na parze: katalog + plik .txt.
Gdyby zaszła potrzeba dodania do XIP jakiegoś modułu, to ... Jeszcze nie wiem :) Jak dodam, to opiszę.

Zajrzyjmy do jakiegoś katalogu z modułem. Na przykład pm.dll
Znajdziemy tam kilka plików S000, S001, S002, ... (tam są umieszczone różne sekcje kodu). W ogóle nie będziemy się nimi interesować.
Cały czas będziemy operować na "imageinfo.bin" (programem M'Reloc) i "imageinfo.txt" (edytorem tekstowym). M'Reloc po zmianie modułu nie synchronizuje zawartości imageinfo.txt. Trzeba będzie robić to za niego edytorem :(
Otwórz jakiś katalog z modułem programem M'Reloc, otwórz imageinfo.txt edytorem i znajdź pierwsze dwa wystąpienia nazwy tego modułu w pliku map.txt (jeśli masz mapę).

Przykładowo dla modułu pm.dll (z mojego XIP):
imageinfo.txt:
  Module name: pm.dll
   e32_vbase:           V=03E62000
   o32[1].o32_realaddr: D=01FF0000

map.txt:
01ff0000 - 01ff1000 L00001000 initialized data of region_1 pm.dll
03e62000 - 03e71000 L0000f000 Virtual base address of pm.dll

M'Reloc pokazuje:
   e32_objcnt:   4
   e32_vbase:    03E62000
   e32_vsize:    0000F000
   o32_vsize:    00001000
   o32_realaddr: 01FF0000

Nie jestem do końca pewny, ile informacji XipPort czerpie z imageinfo.txt, a ile z imageinfo.bin przy re-alokowaniu modułów,
ile informacji z imageinfo.txt, a ile z imageinfo.bin przy tworzeniu mapy alokacji (Przypuszczam, że relokacja odbywa się głównie na podstawie imageinfo.bin, a mapa relokacji na podstawie imageinfo.txt). Nie ma to wielkiego znaczenia - jakość XIP możemy ocenić tylko na podstawie plików z mapą. Żeby mapa była prawidłowa, to pliki imageinfo.txt muszą dobrze odzwierciedlać zawartość imageinfo.bin.


Naszym zadaniem będzie takie ułożenie modułów, żeby w pliku MAP.TXT nie zachodziły na siebie w obu początkowych częściach:
"... initialized data of region..." i
"... Virtual base address of ..."
Resztę załatwi za nas przycisk "realloc P".


Pułapka 1: imageinfo.txt dla plików *.exe wygląda zupełnie inaczej (bo są inaczej ładowane). Na szczęście nie będziemy nic z nimi robić (oprócz usuwania i kopiowania).

Pułapka 2: Dla nielicznych modułów o32_realaddr odnosi się do "o32[2].o32_realaddr", a nie jak zwykle do "o32[1].o32_realaddr". Łatwo zauważyć różnicę: w pliku imageinfo.txt przy właściwym o32_realaddr jest "D=JakasLiczba", przy pozostałych: "V+JakasLiczba" albo po prostu "JakasLiczba". Musi być ""D=" na właściwym miejscu. Różnicę tę można też wychwycić w pliku map.txt (w pierwszej części). Dla większości modułów znajduje się wpis (przykład) "01fed000 - 01fee000 L00001000 initialized data of region_1 relfsd.dll", a dla tych nietypowych:
"01fee000 - 01fef000 L00001000 initialized data of region_2 cecompr.dll"

Pułapka 3: Będziemy przepisywać dziesiątki liczb. Jeśli tylko możesz - korzystaj z copy/paste. Zminimalizujesz ryzyko pomyłki, którą będzie bardzo trudno zidentyfikować.

--------- Kontemplujemy XIP - pakiety:

Czas obejrzeć podkatalogi "OUT" i Packages". Jeden i drugi zawiera te same pliki, tylko inaczej poukładane.

Koncepcja "pakietów" z pewnością nie jest Ci obca z różnych kuchni. To są prawie takie same pakiety, jak te w katalogu SYS i OEM. Nie będę się nad nimi rozwodzić. Z importowanego XIPa interesuje nas przed wszystkim pakiet "MSXIPKernel" (zarówno w katalogach "FILES", jak i "MODULES"), z XIPa z naszego urządzenia - "OEMXIPKernel" (albo podobne). Popatrz na te pakiety i ich zawartość i spróbuj rozsądnie wybrać ze starego XIPa wszystkie całe pakiety, co do których możesz przypuszczać, że zawierają sterowniki od Twojego urządzenia, a z importowanego XIPa całe pakiety, o których możesz przypuszczać, że nie zawierają sterowników.
Pułapka: "bmui.nb0", jeśli masz z nim do czynienia, potraktuj jak sterownik (nie należy go przenosić z importowanego XIP).

--------- Składamy nowy XIP:

- Utwórz nowy katalog na nowy XIP.
- Skopiuj do niego XIPPort.exe i pkgcommon.dll.
- Utwórz podkatalogi OUT, OUT\FILES i OUT\MODULES.
- Skopiuj do katalogu OUT pliki PARTHDR.txt i ROMHDR.txt (ze swojego, starego XIP).
- Skopiuj do katalogów OUT\FILES i OUT\MODULES (ze swojego, starego XIP) pliki i moduły z pakietów, które zawierają sterowniki do Twojego urządzenia.
- Skopiuj do katalogów OUT\FILES i OUT\MODULES (z importowanego XIP) pliki i moduły z pakietów, które nie zawierają sterowników (co najmniej MSXIPKernel).
- Skasuj moduły (jeśli takie masz): osaxst0.dll, osaxst1.dll, hd.dll, kd.dll.
- Porównaj zawartość starego i budowanego XIP. Jeśli się różnią, to zastanów się "dlaczego w nowym XIP nie ma jakiegoś pliku albo modułu, który był w oryginalnym XIP z Twojego urządzenia" i ""dlaczego w nowym XIP pojawił się jakieś plik albo moduł, którego nie było w oryginalnym XIP z Twojego urządzenia". Jakoś rozstrzygnij te dylematy.
Uwaga 1: Pamiętaj, że kopiowanie pliku to w istocie kopiowanie pary plików, kopiowanie modułu to kopiowanie pary katalog+pliku.
Uwaga 2: W czasie kopiowania plików nie powinieneś mieć do czynienia z dublowaniem plików i modułów (powinieneś był zdecydować, z którego XIPa ma pochodzić każdy moduł i plik).

--------- Relokujemy:

Naszym zadaniem będzie takie ułożenie modułów, żeby w pliku MAP.TXT nie zachodziły na siebie w obu początkowych częściach: "initialized data of region" i "Virtual base address of", czyli żeby w dwóch pierwszych częściach nie było znaków  wykrzyknika. Dopuszczalne jest, żeby były między nimi nie wykorzystane obszary pamięci (w mapie są sygnalizowane napisem "NUL").

Przykładowy początek pliku map.txt:
01fa01fe - 01fa01fe L00000000 Start: first DLL address
01fa01fe - 01feb000 L0004ae02 NUL
01feb000 - 01fec000 L00001000 initialized data of region_1 ceddk.dll
01fec000 - 01fed000 L00001000 initialized data of region_1 msflash.dll
01fed000 - 01fee000 L00001000 initialized data of region_1 relfsd.dll
01fee000 - 01fef000 L00001000 initialized data of region_2 cecompr.dll
01fef000 - 01ff0000 L00001000 initialized data of region_1 regenum.dll
01ff0000 - 01ff1000 L00001000 initialized data of region_1 pm.dll
01ff1000 - 01ff2000 L00001000 initialized data of region_1 mspart.dll
01ff2000 - 01ff3000 L00001000 initialized data of region_1 imgfs.dll
01ff3000 - 01ff4000 L00001000 initialized data of region_1 fsreplxfilt.dll
01ff4000 - 01ff5000 L00001000 initialized data of region_1 fsdmgr.dll
01ff5000 - 01ff6000 L00001000 initialized data of region_1 fatutil.dll
01ff6000 - 01ff7000 L00001000 initialized data of region_1 fatfsd.dll
01ff7000 - 01ff8000 L00001000 initialized data of region_1 encfilt.dll
01ff8000 - 01ff9000 L00001000 initialized data of region_1 diskcache.dll
01ff9000 - 01ffa000 L00001000 initialized data of region_1 devmgr.dll
01ffa000 - 01ffc000 L00002000 initialized data of region_1 crypt32.dll
01ffc000 - 01ffd000 L00001000 initialized data of region_1 coredll.dll
01ffd000 - 01ffe000 L00001000 initialized data of region_1 certmod.dll
01ffe000 - 01fff000 L00001000 initialized data of region_1 cachefilt.dll
01fff000 - 02000000 L00001000 initialized data of region_1 busenum.dll
02000000 - 02000000 L00000000 End: last DLL address

02000000 - 03dc0000 L01dc0000 NUL
03dc0000 - 03dc6000 L00006000 Virtual base address of ceddk.dll
03dc6000 - 03dd0000 L0000a000 NUL
03dd0000 - 03dda000 L0000a000 Virtual base address of msflash.dll
03dda000 - 03de0000 L00006000 NUL
03de0000 - 03de7000 L00007000 Virtual base address of relfsd.dll
03de7000 - 03df0000 L00009000 NUL
03df0000 - 03df7000 L00007000 Virtual base address of cecompr.dll
03df7000 - 03e5e000 L00067000 NUL
03e5e000 - 03e62000 L00004000 Virtual base address of regenum.dll
03e62000 - 03e71000 L0000f000 Virtual base address of pm.dll
03e71000 - 03e79000 L00008000 Virtual base address of mspart.dll
03e79000 - 03e83000 L0000a000 Virtual base address of imgfs.dll
03e83000 - 03e8d000 L0000a000 Virtual base address of fsreplxfilt.dll
03e8d000 - 03ea2000 L00015000 Virtual base address of fsdmgr.dll
03ea2000 - 03eab000 L00009000 Virtual base address of fatutil.dll
03eab000 - 03ebe000 L00013000 Virtual base address of fatfsd.dll
03ebe000 - 03eca000 L0000c000 Virtual base address of encfilt.dll
03eca000 - 03ed0000 L00006000 Virtual base address of diskcache.dll
03ed0000 - 03edc000 L0000c000 Virtual base address of devmgr.dll
03edc000 - 03f4e000 L00072000 Virtual base address of crypt32.dll
03f4e000 - 03fe4000 L00096000 Virtual base address of coredll.dll
03fe4000 - 03ff0000 L0000c000 Virtual base address of certmod.dll
03ff0000 - 03ffa000 L0000a000 Virtual base address of cachefilt.dll
03ffa000 - 04000000 L00006000 Virtual base address of busenum.dll
04000000 - 801c0000 L7c1c0000 NUL

W pierwszej części ("initialized data of region"):
- pierwsza kolumna zawiera o32[1].o32_realaddr (czasem o32[2].o32_realaddr, była o tym wzmianka w pułapkach),
- trzecia kolumna zawiera o32[1].o32_vsize (albo o32[2].o32_vsize), zaokrąglone w górę do pełnych 0x1000,
- druga kolumna to po prostu suma pierwszej i trzeciej.
Pierwsza część nie może wykraczać poza dlllast (ani dllfirst).

W drugiej części ("Virtual base address of"):
- pierwsza kolumna zawiera e32_vbase,
- trzecia kolumna zawiera e32_vsize, zaokrąglone w górę do pełnych 0x1000,
- druga kolumna to po prostu suma pierwszej i trzeciej.
Druga część nie może wykraczać poza 04000000 (ani dllflast).

W załączniku: prosty arkusz dla excela (XipMap.zip). Należy do niego wpisać dla każdego modułu (czyli tylko dla *.dll) nazwę, e32_vsize i o32_vsize oraz wartość dlllast z ROMHDR.txt i uzyska się propozycję alokacji modułów. W arkuszu są pewne funkcje - należy pozwolić na ich uruchomianie. Użyj kopiuj/wklej, jeśli zabraknie rządków w arkuszu.

Potem należy każdy moduł zrelokować do zaproponowanych adresów, zarówno programem M’Reloc, jak i zmienić (edytorem tekstowym) zawartość pliku imageinfo.txt (linie e32_vbase i o32[1].o32_realaddr).

Po relokacji należy uruchomić program XipPort i wygenerować mapy. Mapy powinny generować się poprawnie, pierwsze dwie części pliku MAP.txt powinny być zgodne z oczekiwaniami (w szczególności - nie powinny tam występować znaki wykrzyknika). W przeciwnym razie - prawdopodobnie wkradł się jakiś błąd w wykonaniu opisanej procedury.

Czas wcisnąć klawisze (kolejno): "realloc P", "write maps" i "build xip_out.bin".

Oba plik map.txt i map.physical.txt nie powinny zawierać znaków wykrzyknika (w całej treści). Jeśli coś jest nie w porządku na tym etapie - prawdopodobnie nie ma już miejsca w XIP.

--------- Sprawdzenie:

- Należy utworzyć nowy katalog,
- skopiować do niego XIPPort.exe i pkgcommon.dll,
- skopiować do niego właśnie utworzony plik xip_out.bin,
- zmienić nazwę xip_out.bin na xip.bin,
- uruchomić XipPort,
- wcisnąć klawisz "dump xip.bin",
- wcisnąć klawisz " write maps ",
- jeszcze raz obejrzeć pliki map.txt i map.physical.txt (znowu szukamy wykrzykników).

Opisany test sprawdza, czy nie popełniono błędu w czasie relokowania programem M’Reloc i jednocześnie edytorem tekstowym.

Jeśli wszystko jest w porządku, to można skasować katalog, w którym było przeprowadzane sprawdzenie i wrócić do pliku xip_out.bin z poprzedniego punktu.

--------- Wstawianie xip_out:

Tak przygotowana sekcja XIP jest gotowa do włączenia do pamięci ROM (do tego samego pliku, z którego XIP był pobierany w punkcie "Ekstrahujemy XIP"). Można to zrobić znów programem XipPort.

Jeśli jest taka potrzeba, to ROM należy ponownie przegotować i można flashować. Powinno się udać.

Happy XIPing
« Ostatnia zmiana: Wtorek, 08 Kwiecień 2008, 23:15 wysłana przez baniaczek »
Respect++ if PrzydaloSie();

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Wiadomości: 8377
  • Podziękowań: 140
  • Płeć: Mężczyzna
  • Samsung Galaxy S4
    • Wirtualne Zacisze utak3ra
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #1 dnia: Środa, 09 Kwiecień 2008, 01:21 »
Bach, dzięki wielkie za ten post :) Rozjaśnił m.in. moje pewne wątpliwości co do rozbieżności w o32_realaddr  :peace:

forum.mobione.pl

Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #1 dnia: Środa, 09 Kwiecień 2008, 01:21 »

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Wiadomości: 8377
  • Podziękowań: 140
  • Płeć: Mężczyzna
  • Samsung Galaxy S4
    • Wirtualne Zacisze utak3ra
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #2 dnia: Piątek, 11 Kwiecień 2008, 10:41 »
Dodałem linka do tego wątku na stronie http://www.mobione.pl/index.php?page=porting_ROM .
Potem jeszcze dodam jako cały artykuł.

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Wiadomości: 8377
  • Podziękowań: 140
  • Płeć: Mężczyzna
  • Samsung Galaxy S4
    • Wirtualne Zacisze utak3ra
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #3 dnia: Sobota, 12 Kwiecień 2008, 12:06 »
Baniaczek, mówisz, że ten nowy system ładowania sterowników przez device.exe zadziałał Ci?  Bo właśnie przygotowuję się do odpalenia całkiem nowego XIPa - lecz niestety muszę wyjść narazie  O0  Nie będę mógł myśleć o niczym innym ;)  Jak wrócę, będę próbował.

Tak swoją drogą.... ten nowy testowy build od AT&T ma jakieś 10MB mniej w SYSie, niż mój ;) i bardzo dobrze....

Offline baniaczek

  • GZU
  • Swojak
  • ****
  • Wiadomości: 137
  • Podziękowań: 16
  • Płeć: Mężczyzna
  • Nokia e63-1 [200.21.012]
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #4 dnia: Sobota, 12 Kwiecień 2008, 13:23 »
Zadziałał, ale z bólem.
Trzeba czasem ręcznie zrelokować (przed G'Relocem) niektóre moduły. Nie znalazłem jeszcze zasady (bo nie szukałem). U Ciebie może nie być potrzeby - BA ma jednak dość specyficzny układ pamięci.
Podobne kłopoty miałem w zasadzie przy każdym buildzie. Kłopoty dotyczyły różnego zestawu modułów, ale za każdym razem to były moduły ładowane przez device.exe.

Gdyby Ci nie wstało, to może analiza zawartości załącznika pomoże Ci szukać przyczyn:
W załączniku: pliki z SYS\OS.
W katalogu SYS_OS_OK - moduły poprawnie bootującego się systemu
W katalogu SYS_OS_WRONG - te same moduły, z którejś kuchni bepe. Użycie któregokolwiek z nich (choćby jednego) powoduje, że system nie wstaje.
Co ciekawe: binaria wygenerowane recmod'em na podstawie modułów z obu katalogów są identyczne. Usmażone ROMy w obu przypadkach wyglądają poprawnie, żadnych overlapów.
Nie wiem, dlaczego się nie bootuje - KITLem nie potrafię dostać się do BA.
Gdybyś znalazł ideę relokowania - daj znać.

-----------
Testowy ROM AT&T - masz na myśli build 19209 od Kaisera? Wg. mnie to jest fake. Albo bardzo testowy ROM. Po przeniesieniu tylko samego XIPa (z SYSem 19716) melduje mi wersję: CE OS 5.2.19199 (build 19716) (albo jakoś tak, z pamięci piszę). Jak skończę grzebanie (łatki od cmonex i próba konwersji modułu z IMGFS do XIPa), to wrócę do 19202
« Ostatnia zmiana: Sobota, 12 Kwiecień 2008, 13:52 wysłana przez baniaczek »
Respect++ if PrzydaloSie();

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Wiadomości: 8377
  • Podziękowań: 140
  • Płeć: Mężczyzna
  • Samsung Galaxy S4
    • Wirtualne Zacisze utak3ra
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #5 dnia: Sobota, 12 Kwiecień 2008, 14:43 »
Trzeba czasem ręcznie zrelokować (przed G'Relocem) niektóre moduły. Nie znalazłem jeszcze zasady (bo nie szukałem). U Ciebie może nie być potrzeby - BA ma jednak dość specyficzny układ pamięci.


No dokładnie, to samo ma Hima. Wiz ma jednak już inny układ, podobny do wszystkich nowych :)

Gdyby Ci nie wstało, to może analiza zawartości załącznika pomoże Ci szukać przyczyn:


Hmmm....  ?-?  a załącznik gdzie?  :8)
EDIT: OK, dodałeś załącznik :)

Co ciekawe: binaria wygenerowane recmod'em na podstawie modułów z obu katalogów są identyczne. Usmażone ROMy w obu przypadkach wyglądają poprawnie, żadnych overlapów.


Bah, faktycznie dziwne. Zobaczymy, czy u mnie coś takiego wystąpi - aczkolwiek prawdopodobnie nie...

Nie wiem, dlaczego się nie bootuje - KITLem nie potrafię dostać się do BA.


A nie wywalałeś przypadkiem osaxst0.dll i hd.dll?...

Testowy ROM AT&T - masz na myśli build 19209 od Kaisera? Wg. mnie to jest fake. Albo bardzo testowy ROM.


Packages melduje:

Cytuj
  SYS: 5.2.19209.1002
  SYS: 5.2.19202.1000
  OEM: 3.14.0.0
  OEM: 17.6.31401.502
  OEM: 0.0.1.0
  NET: 2.0.7045.0
  OEM: 17.3.31401.502


OK, a jakiego Ty ROMu używasz?



dodano: Sobota, 12 Kwiecień 2008, 13:58

BTW.... baniaczek, widziałeś może to? Popatrz, może Ci się coś przyda  :D
http://www.4shared.com/dir/2624296/935cd692/Roms.html

Offline baniaczek

  • GZU
  • Swojak
  • ****
  • Wiadomości: 137
  • Podziękowań: 16
  • Płeć: Mężczyzna
  • Nokia e63-1 [200.21.012]
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #6 dnia: Sobota, 12 Kwiecień 2008, 14:47 »
Nie wiem, dlaczego się nie bootuje - KITLem nie potrafię dostać się do BA.

A nie wywalałeś przypadkiem osaxst0.dll i hd.dll?...

Przede wszystkim to rok temu wywaliłem Windowsa 2000, a pod Win2k3 PlatformBuilder nie chodzi. Jakoś nie mam czasu zebrać się i z powrotem zainstalować 2k albo XP.
Jak miałem Win2000, to nie wiem, czy potrafiłem KITLa, bo wtedy jeszcze głupi byłem i nic nie wiedziałem.

Packages melduje:

Packages nic nie mówi o XIPie.

OK, a jakiego Ty ROMu używasz?
Stan na dziś? Mieszanka straszna: XIP ten niby 19209, SYS głównie 19716 od bepe, a te moduły SYS\OS, które poprawnie się ładują też 19716, ale od wietnamczyków.
Nawet stabilnie to chodzi.
Respect++ if PrzydaloSie();

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Wiadomości: 8377
  • Podziękowań: 140
  • Płeć: Mężczyzna
  • Samsung Galaxy S4
    • Wirtualne Zacisze utak3ra
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #7 dnia: Sobota, 12 Kwiecień 2008, 15:36 »
OK, a jakiego Ty ROMu używasz?
Stan na dziś? Mieszanka straszna: XIP ten niby 19209, SYS głównie 19716 od bepe, a te moduły SYS\OS, które poprawnie się ładują też 19716, ale od wietnamczyków.
Nawet stabilnie to chodzi.

Hehe, to podobnie, jak mój obecny ;) A właśnie mieszam jeszcze bardziej.....  wyjdzie z tego 19199+19202+19209+19716  :D  z czego połowa też od wietnamców.

Offline globalbus

  • GZU
  • Core
  • ****
  • Wiadomości: 1969
  • Podziękowań: 77
  • Płeć: Mężczyzna
  • N900 + Zest
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #8 dnia: Sobota, 04 Październik 2008, 17:13 »
To ja dodam swoje do tematu ;)

Istnieje narzędzie znacznie ułatwiające tą pracę i skracające wielokrotnie czas potrzebny na przeportowanie XIPa http://forum.xda-developers.com/showthread.php?t=390222

To cudo wyświetla na bieżąco mapę relokacji i pozwala w szybki sposób rozsadzić moduły we właściwych miejscach. Coś jak arkusz baniaczka + "write maps" z xipport + m'reloc w jednym. Bo właściwie m'reloc jest wymagany do ruszenia programu ;)

Offline utak3r

  • Global Moderator
  • Core
  • *****
  • Wiadomości: 8377
  • Podziękowań: 140
  • Płeć: Mężczyzna
  • Samsung Galaxy S4
    • Wirtualne Zacisze utak3ra
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #9 dnia: Sobota, 04 Październik 2008, 17:20 »
 :szok:
Normalnie piwo Ci postawię....

forum.mobione.pl

Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #9 dnia: Sobota, 04 Październik 2008, 17:20 »

Offline globalbus

  • GZU
  • Core
  • ****
  • Wiadomości: 1969
  • Podziękowań: 77
  • Płeć: Mężczyzna
  • N900 + Zest
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #10 dnia: Sobota, 04 Październik 2008, 18:58 »
Jeszcze jedna informacja, XipAddrTools też jest pod pewnym względem ujemny, czasami jak coś zmodyfikujemy i nie widać efektów w tabelce, należy ponownie włączyć program.

nothin

  • Gość
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #11 dnia: Sobota, 04 Październik 2008, 22:14 »
To ja dodam swoje do tematu ;)

Istnieje narzędzie znacznie ułatwiające tą pracę i skracające wielokrotnie czas potrzebny na przeportowanie XIPa http://forum.xda-developers.com/showthread.php?t=390222

To cudo wyświetla na bieżąco mapę relokacji i pozwala w szybki sposób rozsadzić moduły we właściwych miejscach. Coś jak arkusz baniaczka + "write maps" z xipport + m'reloc w jednym. Bo właściwie m'reloc jest wymagany do ruszenia programu ;)


:O

Offline globalbus

  • GZU
  • Core
  • ****
  • Wiadomości: 1969
  • Podziękowań: 77
  • Płeć: Mężczyzna
  • N900 + Zest
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #12 dnia: Środa, 12 Listopad 2008, 20:17 »
jeszcze jedna informacja, program można zaprząc do sporządzenia tabelki z modułami w imgfs :D
między innymi możemy się dowiedzieć ile zostało nam wolnego miejsca w virtual base :szok:

nokser

  • Gość
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #13 dnia: Niedziela, 28 Grudzień 2008, 00:29 »
Muszę przyznać,że twój artykuł bardzo mi pomógł i wiele rozjaśnił..... :peace:

Offline globalbus

  • GZU
  • Core
  • ****
  • Wiadomości: 1969
  • Podziękowań: 77
  • Płeć: Mężczyzna
  • N900 + Zest
Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #14 dnia: Niedziela, 10 Maj 2009, 20:13 »
ja teraz będę dokładał informacje do metod ręcznych
PathHDR.txt
ulRomUnknown - nie wiem do czego służy, ale we wszystkich romach wynosi tyle samo "EA0003FE"
wartość dwRomHdrAddress określa położenie ROMHDR.bin w pliku xip, można ją odczytać z wartości dword (little endian) za sygnaturą ECEC, oraz odejmując od tej wartości physfirst.
Idąc dalej tropem, możemy znaleźć dzięki tej wartości umieszczony w xip sektor ROMHDR.bin, zawiera on te same wartości co ROMHDR.txt, jest to czysty plik wartości dword w little endian (poza usCPUType i usMiscFlags, które są wartościami word) z którego możemy odtworzyć ROMHDR.txt

W ROMach WM5/6 dwRomHdrAddress jest wpisany jako 2 wartość dword za ECEC, w romach wince i wm2003 trzeba ją dopisać ręcznie, wtedy możemy potraktować cały rom urządzenia (wince) jako jeden wielki xip i w pełni go wyedytować (nie zdziwcie się, że  w tym wypadku mapa relokacji będzie posiekana)



dodano: Środa, 31 Grudzień 2008, 14:25
chyba ten plik powinien być dodany do tego artykułu
mreloc dla modułów w sekcji RAM

forum.mobione.pl

Odp: Budujemy nowy ROM: Przenoszenie XIP prawie na maksa
« Odpowiedź #14 dnia: Niedziela, 10 Maj 2009, 20:13 »