[Windows Mobile Software Development] Ameet:
Manual Full XIP Porting

Tools you need

: (attached the tools in this thread for easy access)

HEX Calculator (recommended – HEX workshop (Not Free)), suggested Windows Calculator

XIPPort.exe

M’Reloc.exe

NBMerge.exe

Insert.exe

OS.nb.payload from 19965 build (shipped ROM)

Cup of nice strong Coffee (A Must) :D

Brief

:

There are many different ways to port the XIP. Few mention of using the 723*.dsm for the build number, few others mention of using the coredll.dll module to have the latest build numbers. As my friends, Noonski and !Aman! always say “Only numbers are just eye wash, core system is what matters the most” Based on this as inspiration, I am posting this guide for manual XIP porting. A few places you may find colors in this guide, these are to visually link the data for easy understanding

The only files removed from the ported XIP are (these are removed to keep the new XIP within the original size):

osaxst0.dll + osaxst0.dll.imageinfo.txt

hd.dll + hd.dll.imageinfo.txt

bmui.nb0 + bmui.nb0.imageinfo.txt

Process

:

Prepare OEMXip base

Dump your original XIP.bin (from 19965 build) with XIPPort.exe, and click “write maps” to get MAP.txt in the OUT folder

Open the MAP.txt and go through what you will need to achieve for a full port. I advice to keep this MAP.txt as a backup, just in case

Click “make pkgs” to get “OEMXipKernel” and “MSXipKernel” folders inside \Files and \Modules

Delete MSXipKernel folders from \Files and \Modules both

Now our base OUT folder is ready with OEMXipKernel

Prepare MSXip donor

Dump your donor XIP.bin (from 20758 build) with XIPPort.exe, and click “make pkgs” to get “MSXipKernel” folder inside \Files and \Modules

Delete osaxst0.dll + osaxst0.dll.imageinfo.txt, hd.dll + hd.dll.imageinfo.txt and bmui.nb0 + bmui.nb0.imageinfo.txt to get the new XIP within the original RAM size. If you don’t wish to delete these files, then you will need to increase the “physlast” in ROMHDR.txt. Process of which is not covered under this guide

Copy the MSXipKernel folders from \Files and \Modules both to the \Files and \Modules in the base OUT folder

Now our OUT folder is ready to be ported with the OEMXipKernel and MSXipKernel

Now to proceed with the reallocing you need to re open the packages which have been created. Open XIPPort.exe and click "undo" then click “realloc P” to re calculate the reallocation addresses. Then click “write maps” to get the new MAP.txt file

Open this MAP.txt and look in the o32_realaddr and e32_vbase addresses. Busenum.dll must be the last entry in both tables. Here you may find overlaps of the modules in a few or most places (seen as !!!!!!!!!!!!!!!!!!)

These are the overlaps which need to be taken care of by reallocating the modules in Initialized Data and Virtual Base addresses

You need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory

For example:

03f4c000 03fe3000 L00097000 Virtual base address of coredll.dll

03fe2000 03fe3000 L00001000 !!!!!!!!!!!!!!!!!!

03fe2000 03ff0000 L0000e000 Virtual base address of certmod.dll

03ff0000 03ffb000 L0000b000 Virtual base address of cachefilt.dll

03ffa000 03ffb000 L00001000 !!!!!!!!!!!!!!!!!!

03ffa000 04000000 L00006000 Virtual base address of busenum.dll

Meaning, e32_vbase address of cachefilt.dll is overlapping that of busenum.dll by 1000 (L00001000) Similarly e32_vbase address of coredll.dll is overlapping that of certmod.dll by 1000 (L00001000)

I recommend you use M’Reloc.exe for reallocating the addresses in imageinfo.bin and Notepad to reallocate the addresses in the corresponding imageinfo.txt files. Since the binaries (S000, S001...) must actually be relocated using M'Reloc, it is not enough to just adjust the values in the imageinfo.txt files

To calculate the revised addresses (in below example, the e32_vbase) of the overlapping module, open Hex Calculator. To do that you will need to know the e32_vsize of the overlapped module. To find that out open overlapped module (for e.g. cachefilt.dll) in M’Reloc.exe and see the e32_vsize (0000

B000

)

Now to correct the e32_vbase of cachefilt.dll, follow this calculation as a base (e32_vbase busenum.dll - e32_vsize cachefilt.dll = e32_vbase cachefilt.dll)

Meaning, (03FFA000 – B000 = 03FEF000) hence the correct e32_vbase address is 03FEF000

03ff0000 03ffb000 L0000b000 Virtual base address of cachefilt.dll

03ffa000 03ffb000 L00001000 !!!!!!!!!!!!!!!!!!

03ffa000 04000000 L00006000 Virtual base address of busenum.dll

Now since the cachefilt.dll is reallocated using the above calculation, the modules next in line above that will also have to be reallocated. Namely, certmod.dll (although not overlapping yet above the cachefilt.dll). To calculate the e32_vbase of certmod.dll you will need the revised e32_vbase address of cachefilt.dll which you got just now

I recommend writing down the e32_vbase, e32_vsize, o32_realaddr and o32_vsize of each module so it will be easier to calculate the correct addresses for reallocation)

Remember, you need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory

To reallocate the addresses for o32_realaddr, follow the above calculation, only this time replace the e32_vbase busenum.dll with o32_realaddr and e32_vsize with o32_vsize

Now open the corresponding imageinfo.txt file for each module and change the e32_vbase and o32_realaddr address values in the txt file of the values mentioned with V= and D=, seen for e.g. like this

Module name: cachefilt.dll

e32_vbase: V=03FEF000

o32[1].o32_realaddr: D=01FFE000

You will notice that the FLASHDRV.DLL module has the realaddr at 2 regions. Although I have not found a way to calculate the difference between both regions but I change the values as per Abusalza’s MAP.txt

o32[1].o32_realaddr: D=01FCC000

o32[3].o32_realaddr: D=01FD4000

Since the OEMXipKernel modules never change, I only correct values of the ported MSXipKernel modules :)

This is helpful if the MSXipKernel modules ported from donor ROMs are similar in the sizes. If not then you will need to do the calculation and correction of values

Once through with the address reallocation, open XIPPort.exe and click “realloc P” to re calculate the addresses for writing maps. It will show you errors regarding some regions, ignore those and click “write maps”. Open the new MAP.txt and recheck for (!!!!!!!!!!!!!!!!!!) If none found that means the XIP has been ported well

Now click “build xip_out.bin” to create the resulting XIP to be inserted into the ROM .payload file. Use this command for inserting the xip_out.bin into the .payload (presuming you already have the shipped OS.nb.payload file in the same working folder

insert.exe -i xip_out.bin -o OS.nb.payload -d 0x00320000 -s 0x004C0000

Check these values with your device imgfs since in Diamond the XIP starts at 0x00320000 and the imgfs starts at 0x007A0000, but for some reason the imgfs signature in Diamond is at 0x007E0000

Build OS.nb for use in the ROM folder from the .payload you just updated with the new XIP. Please note these commands are for Diamond device. Please check with your device on the same before building

nbmerge.exe –kaiser OS.nb

Now put this OS.nb file in the ROM, put the boot.rgu from 19965 (shipped ROM) into the \ROM\XIP folder and do not include any of the OEMXipKernel or MSXipKernel folders in OEM & SYS folder while cooking. I observed for some reason, WinCeNls_WWE folder cannot be taken out of XIP and included in SYS. Device wont boot, so keep that in XIP (found a working solution by spocky12: Here (last quote)

Please note the insertion of xip_out.bin can also be done through XIPPort.exe directly

Before clicking “write xip_out.bin to:” replace the name “nk.nb” with “OS.nb.payload” and the address to “00320000” all without quotes

IMP

: There may be chances that although the XIP is working fine, but the windows are seen as QVGA versions. The solution to that is either of the below

XIP & SYS of the same builds or

XIP and the OS\Gwes.exe from same build

Cook the new ROM with your favorite kitchen (whichever doesn’t do anything with the XIP) and use this OS.nb file as base template for the ROM with the new XIP

With this note, I hope this guide will serve many as a guiding light and answer many questions on manual full XIP porting. Happy porting ;)