Ź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: 0000CD08Nie 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: 00000000Znaczenie poszczególnych linii ROMHDR.txt jest opisane tu:
http://msdn2.microsoft.com/en-us/library/aa908726.aspxW 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=01FF0000map.txt:
01ff0000 - 01ff1000 L00001000 initialized data of region_1 pm.dll
03e62000 - 03e71000 L0000f000 Virtual base address of pm.dllM'Reloc pokazuje:
e32_objcnt: 4
e32_vbase: 03E62000
e32_vsize: 0000F000
o32_vsize: 00001000
o32_realaddr: 01FF0000Nie 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 NULW 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
