[REF] Manual XIP Porting Guide (For Diamond and Other Devices) [ONLINE]

[ameetb]

With a lot of help from Cmonex, Abusalza and Htctouchp, I finally managed to manually “Full Port” a new XIP for my newly bought Diamond. Credits of this guide goes to them more than me

In the interest of benefit of the community and for many unanswered questions, I am posting this guide on Manual XIP Porting

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

1. HEX Calculator (recommended – HEX workshop (Not Free)), suggested Windows Calculator
2. XIPPort.exe
3. M’Reloc.exe
4. NBMerge.exe
5. Insert.exe
6. OS.nb.payload from 19965 build (shipped ROM)
7. Cup of nice strong Coffee (A Must)

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 Htctouchp 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):

1. osaxst0.dll + osaxst0.dll.imageinfo.txt
2. hd.dll + hd.dll.imageinfo.txt
3. bmui.nb0 + bmui.nb0.imageinfo.txt

Haven’t tried removing any other file, or to play around with the “physlast” to test increasing the memory address so we don’t have to delete the above files

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 play around with the “physlast” which is not covered in 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

Open XIPPort.exe and 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)

One way of correcting these values is as posted by Ervius somewhere that since XIPPort.exe will read only the imageinfo.txt files for rebuilding the xip_out.bin, go ahead and delete all the imageinfo.bin files and work only on the txt. This method is not tested by me yet, so I recommend you go ahead with using M’Reloc.exe for reallocating the addresses in imageinfo.bin and Notepad to reallocate the addresses in the corresponding 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 (0000B000)
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

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: For the ROM to function properly after boot, you need to either have
XIP & SYS of the same builds or
XIP and the OS\Gwes.exe and \Base_Lang_0XXX\Gwes.exe.0xxx.mui files 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

This guide is also available as downloadable in .pdf format for easy offline reference

[tobeychris]

Omg I Have The Same Problem

[CFay]

Why didnt you insert the new xip into the os.nb.payload by just using xipport.exe? then merge them with nbmerge? Thats how i do it as i dont trust those tools as many are picky as to which device they work with.

[tobeychris]

the tools aren't the problem, I've inserted the XIP with insert, xipport and done it manually, and all get the same result.

[CFay]

hmm idk then. I never had that problem. Ask DCD or VET on XDA....

[ameetb]

I just posted a detailed manual xip porting guide here on xda: http://forum.xda-developers.com/showthread.php?t=438676

Found a way out to how to do it. The solution to the above problem I posted is to:

1. Either use XIP & SYS of the same build

or

2. Use Gwes.exe and Gwes*.mui from the same build as the XIP

[TweetyBear]

this is nice! i was having problems porting xip so now i'll try your method heh

[Mr. X]

Im really glad that we are seeing technical info posted here now. rather then telling every one go to xda. we can do what they can do

[gguruusa]

Originally Posted by ameetb

I just posted a detailed manual xip porting guide here on xda: http://forum.xda-developers.com/showthread.php?t=438676

Found a way out to how to do it. The solution to the above problem I posted is to:

1. Either use XIP & SYS of the same build

or

2. Use Gwes.exe and Gwes*.mui from the same build as the XIP

The important thing is not that they be from the same build, but that they be for the proper resolution device. If you port 96dpi files to your 192dpi device, you're going to get the effect you observed whenever those files are accessed.

BTW, I can't figure out why you suggest processing the list in reverse order during the m'reloc phase of porting. You'll make more errors going that direction and it's unneccesary to do so.

[tobeychris]

Actually talked to cmonex last night, she suggested the gwes, and it works. Should be fun!