Hi All
I am trying to setup mkrom to handle PPC2003. I have extracted / converted all of the files from a "bare" 4.00.05 rom from Jef's Kitchen and amended the operator files etc and am able to generate new roms. I now need to change the code in the mkrom.sh file to change the xda1.bin and xda2.bin, and so on, addresses to match the 2003 rom layout. I have the relevant details but my question is can I simply substitute the new adresses into the .sh file or is there more to it ?
Thanks for any help
Richard
the latest version of mkrom has all its rom dependent parameters in 'cfg/params' and instead of all the 'dd' stuff, I now changed splitrom to handle all the manipulating of image files.
the offsets you see in mkrom are defaults for 3.17.
the latest mkrom you can find in http://xda-developers.com/DemoKitchen/data/00_Base ROM/4.00.05 ENG ppc2003/_/mkrom.sh
Itsme
Thanks again
Great site, Great team
Richard
Itsme
I have downloaded the 4.00.05 directory of Rom Kitchen and placed the required files in the correct folders and ran mkrom. On the first attempt the program reported "can't find dumprom" so I copied in the entire toolset and ran mkrom again this time I'm getting an overlap error as below:
write xip block starting at 81740000, with 2 files
write xip block starting at 81b00000, with 0 files
!!! your rom is not known to me: md5: dad2e3cad6095282bf1d58ccf12171e8
this bootloader seems to be V5.22 2003-05-15 17:46:55
no operator rom found
80000000 - 80040000 -- bootloader 0 files 1 modules
80040000 - 8015df78 9 XIPKERNEL 5 files 5 modules
80180000 - 80376f10 8 KERNEL 10 files 14 modules
80380000 - 8064306c 7 OS 20 files 36 modules
80670000 - 80be66a8 6 SHELL 107 files 88 modules
80c00000 - 8102ce98 5 BROWSING 11 files 36 modules
81050000 - 813ef114 4 COREAPPS 95 files 44 modules
81400000 - 815d2238 3 EXAPPS 34 files 7 modules
815f0000 - 8171bc7c 2 PHONE 56 files 19 modules
81740000 - 81766e90 10 XDA_DEVELOPERS1 2 files 0 modules
81780000 - 81781c34 -- xip chain 11 xip entries
817c0000 - 81ca1b44 1 MISC 225 files 42 modules
81b00000 - 81b01054 11 XDA_DEVELOPERS2 0 files 0 modules
81ec0000 - 81ee5800 -- bitmap : f9fff9ff .. f9fff9ff
Error creating new rom
Overlap detected
1 MISC 225 files 42 modules
11 XDA_DEVELOPERS2 0 files 0 modules
This output comes from a run with a Tmobile "bare" rom but I get the same with a 4.00.05 rom from Jeffs kitchen.
I had not wanted to install the whole kitchen if I could help it and from the code it doesn't look as if I would need to but something is wrong somewhere. I would be verry grateful if you could offer any thoughts.
Thanks
Richard
All sorted now
Richard
As I've heard some people have problems with working with XIP sections of some ROMs... as for example Asus P525 or other devices, here's a little tiny tutorial about this issue. What's the problem with them? It's their XIP sections are compressed with SRPX algorithm.
In some Asus kitchens in the ROM directory you have a ROM.TPL file. How to use it?
1. Get the OSNBTool from the attachement (it's a fantastic tool from Weisun of PDAclan.com).
2. Do:
Code:
>osnbtool -d rom.tpl 1 xip.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Deompress processing...
Successfully decompressed to xip.bin
3. Run XIPPort and click "dump xip.bin".
4. Do your work with a XIP section.
5. After you're finished, issue "realloc P" and "build xip_out.bin" in XIPPort.
6. Do:
Code:
>osnbtool -c rom.tpl 1 xip_out.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Source OS image:
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Source Part-1 Size: 1AC400
--------------------------------------
Compress processing...
NEW Uncompressed size: 2D5000
NEW Compressed size: 1A6BF6
New Part Size: 1A71E6
Successfully compressed xip_out.bin into rom.tpl.NEW
7. You're done!
It turns out that a dumprom.exe and buildxip.exe tools handle those XIPs really well, too - and even better, as they do better reallocation of modules.
So, it can go as this:
Code:
>dumprom rom.tpl
IMGFS guidBootSignature: F8 AC 2C 9D E3 D4 2B 4D BD 30 91 6E D8 4F 31 DC
dwFSVersion: 00000001
dwSectorsPerHeaderBlock: 00000001
dwRunsPerFileHeader: 00000001
dwBytesPerHeader: 00000034
dwChunksPerSector: 00000008
dwFirstHeaderBlockOffset: 00000200
dwDataBlockSize: 00001000
szCompressionType: LZX
dwFreeSectorCount: 0000001E
dwHiddenSectorCount: 00000100
dwUpdateModeFlag: 00000000
Address: 00000200, dwBlockSignature: 2F5314CE
dwNextHeaderBlock: 00000000 (size: FFFFFE00)
Header type: FFFFFFFF, Addr: 00000208
Empty header
Header type: FFFFFFFF, Addr: 0000023C
Empty header
Header type: FFFFFFFF, Addr: 00000270
Empty header
Header type: FFFFFFFF, Addr: 000002A4
Empty header
Header type: FFFFFFFF, Addr: 000002D8
Empty header
Header type: FFFFFFFF, Addr: 0000030C
Empty header
Header type: FFFFFFFF, Addr: 00000340
Empty header
Header type: FFFFFFFF, Addr: 00000374
Empty header
Header type: FFFFFFFF, Addr: 000003A8
Empty header
Now you have new files: boot.bin, msflsh.bin and romhdr.bin, and a new folder XIP. Edit your XIP folder as you want.
Now, in ..\temp\dump folder put your .VM and .ROM folders and issue:
Code:
>buildxip
BUILDXIP 0.54 Copyright (c) 2007-2008 bepe 30 Jan 2008
Slot 0 Boundary: 0x01fa0000
Slot 1 Boundary: 0x03e18000
RAMStart: 0x88868000
RAMFree: 0x888c6000 - 0x8c000000 L0373a000
KernelFlags: 0x00000000
FSRamPercent: 0x00000004
Done!
In the end put your new created out.bin file into your tpl file:
Code:
>osnbtool -c rom.tpl 1 out.bin
OS ROM Partition Tool V1.48 By Weisun :> PDAclan.com
Sector size : 0x00000200
Extra data bytes : 0x00000000
OS IMAGE found.
Partitions infomation:
**************************************
Part-0 type: BOOT SECTION image
Part-1 type: XIP RAM Image
Part-2 type: IMGFS file system
**************************************
Source OS image:
Signature: SRPX
CompressVersion: 5
Uncompressed size: 2E0000
Source Part-1 Size: 1AC400
--------------------------------------
Compress processing...
New part size larger than old part in source OS image!
Rebuilding partition structure...
NEW Uncompressed size: 2E7000
NEW Compressed size: 1B1664
New Part Size: 1B1C78
Successfully compressed out.bin into rom.tpl.NEW
and you're done!
Hello utak3r.
This info is really important for me as I have an Eten device. Although, I've tried several times to build a XIP using "buildxip" (with or without -b flag - I don't know exactly what it does) but my rom doesn't boot.
I didn't even tried to change anything in XIP folder. Only dumped the XIP using "dumprom" and then build again to test it. Was I supposed to do something in the middle? Any idea?
bgcngm said:
with or without -b flag - I don't know exactly what it does
Click to expand...
Click to collapse
This flag tells if it should take another, external boot.rgu file, or the included one. So, you should do it without this flag.
bgcngm said:
but my rom doesn't boot.
Click to expand...
Click to collapse
The problem may be not in the building it, but in inserting it back. Some devices don't like changing the partition's size, for instance...
Check, what was the original xip.bin size and try to fill your new one with 0xFFs to this size - maybe it will help...
Another thing: give here full outputs from all the steps.
utak3r said:
The problem may be not in the building it, but in inserting it back. Some devices don't like changing the partition's size, for instance...
Click to expand...
Click to collapse
I already thought that the problem was XIP insertion, but then I found XIPKitchen.
With a XIP created by XIPKitchen, I can successfully create a bootable rom, even with a different XIP partition size. I'm happy because those XIP's are working, however XIPKitchen doesn't integrates nicely in a rom kitchen. The user has to manually input the files and select some options in the program and I wanted to build the new XIP silently which is what buildxip does.
Do you know what could be the problem? I might be missing something... like rellocating the modules... But as I said before, I tried to build the XIP without touching it, simply by dumping and then rebuilding it. In that case there was no need to rellocate the modules, right?
utak3r, don't you know what could be the problem?
Hi bro
In some Asus kitchens in the ROM directory you have a ROM.TPL file
Click to expand...
Click to collapse
use tool NB0 KITCHEN mrtoto which extracting&inserting partition xip in file out.bin in to NewROM.tpl
extracting out.bin use XipKitchen or buildrom bepe,ren xip_out_new.bin to out.bin ,move to directory Rom.tpl end push button "Build Template" in NB0 KITCHEN mrtoto
THANKS A LOT !!
Awesome tool, had troubles extracting one of the xip files since a LONG time, this just did the trick and it's nifty features like putting romhdr, o32, e32 headers nicely were also helpful.
Version: 15/06/2009
Intro
Welcome; I wanted to offer a little "something" back to the XDA community in the hopes that will benefit others and to show my appreciation to the folks that make XDA the great community that it is. Hopefully, this guide will help you work your way up the ranks to Chef … let’s begin!
So here you are; in the heat of the kitchen, adding your favourite ROM ingredients ... pinch of this, sprinkle of that. Like all good chefs, you decide to take a taste of your preparation before serving to others – so you try it ... wait! you say, something is not right; you're positive you added the ingredients but it's not right. You carefully review all of the portions; seem right; so you decide to look at the ingredients and you realize … you need to change suppliers.
This guide is intended to help you learn how to port the Execute-In-Place (XIP) region from a new (donor) device for use in your kitchen; it will walk you through the process of extracting the contents of an Official ROM, obtaining the new (donor) device XIP, and porting the new (donor) device XIP into your kitchen.
Obtaining Execute-In-Place (XIP) Files
The Execute-In-Place (XIP) region is an area where an application can execute code directly from ROM rather than loading it from RAM. It is possible to use the xip.bin contents from a newer version of a ROM from a different device or a newer operating system. This is typically done by chefs who are looking for the most recent versions of system files from a specific device or version of an operating system.
The process of porting the Execute-In-Place (XIP) requires that you have a reduced copy of your current os.nb.payload from which the xip.bin will be extracted.
Additionally, the process requires that you obtain the newer xip.bin (extracted from the reduced os.nb.payload) and the corresponding .\SYS folder from the desired device .NBH package. Although it is possible to obtain a pre-extracted xip.bin and corresponding .\SYS folder, it is always preferable to perform the extraction activities yourself when possible – this ensures that you have a complete .\SYS folder, the reduced os.nb.payload file, and the extracted xip.bin to work with.
Outro
The sections are intended to be followed in sequence as the last section should provide you with a final product that can be used in your kitchen – so you may want to read this guide once over before going through the motions … who am I kidding? You’re going to follow along aren’t you?
The guide does not cover the steps required to inject the changes from a new .\SYS folder to your existing kitchen .\SYS folder or the comparison (verification) of the boot.rgu and supporting .RGU files typically found in the new (donor) device.
Now for the disclaimer bit; I take no responsibility and will not be held liable for any problems you encounter with your device before and after following this guide … flashing a ROM is done at your own risk. If you spot mistakes or inaccuracies in the guide however, please let me know so that I may correct them. Now, read on if you still feel it necessary to change suppliers
Oh, one last thing ... special thanks to the following folks for sharing their knowledge with the rest of us ... thank you!
Aruppenthal
Ameet
Bepe
Calkulin
Cmonex
Da_G
Ervius
Olipro
If I missed someone, it's purely accidental – send me a note and I will add your name to the list.
[TUT] Sous-Chef's Guide to Aruppenthal's XIP Porting Kitchen 5.3 ... continued
Preparing Your Facility
Before you can begin to port an Execute-In-Place (XIP) region, you need to equip your facility with some Kitchen utensils. Your Kitchen is going to require a good Unicode & UTF-8 text editor; I personally use ConTEXT & Notepad. Another handy utensil to have is a hexadecimal file/binary editor; I use XVI32. Some other utensils that you're going to require are: cmonex AutoPatcher and om-by Page Pool Changer/Resizer. You will also need an archive extraction utensil; I use IZArc, WinRAR, and WinZIP. You’ll also need a good Hexadecimal calculator; I use Windows Calculator (Scientific Mode).
It's also a good idea to ensure that your Kitchen remains "pest" free; common pest control services include AVG, McAfee, and Symantec anti-Virus. You may need to temporarily disable your Anti-Virus Rootkit scanner while performing binary editing and porting activities.
To assist you in your apprenticeship, I have included a link to Aruppenthal’s XIP Porting Kitchen that I used to prepare this guide – the kitchen also includes a .DOC and .PDF format of this guide. The procedures were tested against a GSM Raphael device. I can’t confirm that these procedures will work on CDMA device ROM’s. Additionally, some device XIP’s may not be compatible with the Raphael device.
XIP Porting Kitchen, 7 MB (mirror)
For the purpose of this guide, I will assume that you have added the C:\XDA\ folder, sub-folder, and files to your anti-virus exclusion list. You will additionally require the Generic Simple Kitchen from the Sous-Chef's Guide to Da_G's Simple ROM Kitchen tutorial (http://forum.xda-developers.com/showthread.php?t=490787) and the XIP Porting Kitchen used in this guide – extracted to the following folder.
C:\XDA\MY_XIP_KITCHEN
The guide is divided into the following sections:
Extracting the RUU_SIGNED.NBH Contents .............. 3
Reducing the .PAYLOAD File .......................... 4
Extracting the Donor XIP.BIN Contents ............... 5
Extracting the Base XIP.BIN Contents ................ 6
Extracting the Donor MSXIPKernel .................... 7
Validating the XIP_OUT.BIN File ..................... 8
Table 1.1: Good ............................... 9
Table 1.2: Fail ............................... 10
Table 1.3: Overlap ............................ 11
Table 1.4: Gap ................................ 12Preparing the New OS.NB.PAYLOAD File ................ 13
Reducing the Update Loader (ULDR) ............. 14
No Update Loader (ULDR) Reduction ............. 15Unlocking and Sizing the Paging Pool ................ 16
Disabling Certificate Checking ...................... 17
I will attempt to provide an overview, the list of tools required, and the process to follow in each section. As you become more comfortable (and familiar) with the activities, you will find that you can consolidate (or skip) certain outlined steps. Incidentally, you'll probably want to keep these web links open in case you need to lookup some of the terms or concepts in the guide.
Acronyms
http://wiki.xda-developers.com/index.php?pagename=Acronyms
Glossary
http://wiki.xda-developers.com/index.php?pagename=Glossary
Development Resources for Windows Mobile
http://forum.xda-developers.com/showthread.php?t=445396
Extracting the RUU_SIGNED.NBH Contents
An .NBH is a signed group of modules or packages; they are typically comprised of .NB files. An .NBH can contain any combination of .NB files. An .NB file is a block of code that can be a Radio ROM, Operating System packages (XIP and IMGFS), Startup Splash Screen (or SPL).
Upon completion of the extraction process, we will be working with is the OS.NB file; it contains the ULDR, XIP, and IMGFS (OEM, SYS). To extract the contents of an .NBH file, copy the .NBH file to the .\BaseROM folder of a new (clean, unused) kitchen.
You will need to extract the Generic Simple Kitchen to two different folders; one folder for the .NBH file currently in use in your current (base) kitchen, and one folder for the new (donor) device .NBH file.
C:\XDA\BASE_NBH_KITCHEN
C:\XDA\DONOR_NBH_KITCHEN
Procedure
The following procedure initiates the ROM Extraction (NBH, IMGFS, and XIP) activity via a script that is included in the Generic Simple Kitchen. You will need to repeat this procedure for each .NBH file. The extraction process can take a significant amount of time to complete.
Copy the RUU_SIGNED.NBH file to the .\BaseROM\ folder.
Navigate to the folder.
Launch RaphaelKitchen.cmd.
Select E, press ENTER.
Select A, press ENTER.
At the Done! message, allow the process to resume – do not close command prompt!
At the Now Start Cooking Your ROM! Press Any Key To Continue message, press ENTER.
Select X, press ENTER.
References
Tutorial: Sous-Chef's Guide to Da_G's Simple ROM Kitchen 5.3
http://forum.xda-developers.com/showthread.php?t=490787
Reducing the .PAYLOAD File
At this point, we need to remove the contents of the IMGFS (OEM, SYS) from the .PAYLOAD file in preparation for our changes to the ULDR and XIP. Removing the IMGFS (OEM, SYS) contents from the .PAYLOAD file will reduce the size of the .PAYLOAD file making it easier to work with.
To reduce the .PAYLOAD file, we essentially need to cook a new version of the .PAYLOAD file with an empty IMGFS partition – one which only contains the .VM and .ROM folder contents. For the purposes of this guide, we will use the Ervius Payload Reducer script to perform this process.
You will need to reduce the os.nb.payload for each extracted .NBH file; once for the .NBH contents currently in use in your (base) kitchen, and once for the new (donor) device .NBH file.
Procedure
The following procedure initiates the .PAYLOAD file reduction activity via a script that is included in the Generic Simple Kitchen. The reduced os.nb.payload file will be required when we update the xip.bin file.
Copy the os.nb.payload file from the kitchen .\Temp\ folder to the kitchen .\Tools\ReducePayload\ folder.
Navigate to the .\Tools\ReducePayload\ folder.
Launch reduce_payload.bat.
At the OS.NB.PAYLOAD Successfully Reduced. Press Any Key To Continue ... message, press ENTER.
References
Tutorial: Sous-Chef's Guide to Da_G's Simple ROM Kitchen 5.3
http://forum.xda-developers.com/showthread.php?t=490787
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Extracting the Donor XIP.BIN Contents
Now that we have two reduced os.nb.payload files; one for the current (base) kitchen and one for the new (donor) device, we must now extract the xip.bin from the reduced os.nb.payload file of the new (donor) device.
We don’t need to extract the xip.bin from the current (base) kitchen os.nb.payload file at this time.
Tools Required
The following tools are required for the xip.bin file extraction activities.
XIPPorterEx
Procedure
The following procedure will extract the contents of the xip.bin from the os.nb.payload file.
Copy the os.nb.payload file from the C:\XDA\DONOR_NBH_Kitchen\Tools\ReducePayload\ folder to the C:\XDA\DONOR_NBH_Kitchen\Tools\XIPPorterEx\MyTools\os_nb.payload\ folder.
Navigate to the C:\XDA\DONOR_NBH_Kitchen\Tools\XIPPorterEx\ folder.
Launch XIPPORTEREX.EXE.
Click the (Extract From .Payload) button.
At the XIP.BIN Successful Extraction From OS.NB.PAYLOAD message, click OK.
At the XIP.BIN Successful Written Into: "\xip.bin_old" Folder message, click OK.
Exit XIPPORTEREX.EXE.
Copy the extracted xip.bin file from the C:\XDA\DONOR_NBH_Kitchen\Tools\XIPPorterEx\MyTools\xip.bin_old\ folder to the C:\XDA\My_XIP_kitchen\MyTools\xip.bin_new\ folder.
References
Kernel Overview
http://msdn.microsoft.com/en-us/library/aa909237.aspx
Extracting the Base XIP.BIN Contents
At this point, we have extracted the xip.bin from the new (donor) device os.nb.payload file and copied it to the XIP Porting Kitchen.
We must now extract the xip.bin from the reduced os.nb.payload for the current (base) kitchen.
Tools Required
The following tools are required for the xip.bin file extraction activities.
XIPPorterEx
Procedure
The following procedure will extract the contents of the xip.bin from the current (base) kitchen os.nb.payload file.
Copy the os.nb.payload file from the C:\XDA\BASE_NBH_Kitchen\Tools\ReducePayload\ folder to the C:\XDA\BASE_NBH_Kitchen\Tools\XIPPorterEx\MyTools\os_nb.payload\ folder.
Navigate to the C:\XDA\BASE_NBH_Kitchen\Tools\XIPPorterEx\ folder.
Launch XIPPORTEREX.EXE.
Click the (Extract From .Payload) button.
At the XIP.BIN Successful Extraction From OS.NB.PAYLOAD message, click OK.
At the XIP.BIN Successful Written Into: "\xip.bin_old" Folder message, click OK.
Exit XIPPORTEREX.EXE.
Copy the extracted xip.bin file from the C:\XDA\DONOR_NBH_Kitchen\Tools\XIPPorterEx\MyTools\xip.bin_old\ folder to the C:\XDA\My_XIP_kitchen\MyTools\xip.bin_new\ folder.
References
Kernel Overview
http://msdn.microsoft.com/en-us/library/aa909237.aspx
Extracting the Donor MSXIPKernel
The Execute-In-Place (XIP) region is comprised of two significant regions – the MSXIPKernel, and the OEMXIPKernel. The OEMXIPKernel typically contains system drivers that are specific to your device. On very rare occasions, these drivers can be changed for newer ones.
The MSXIPKernel however, usually contains drivers that are specific to the version of Windows Mobile that you are using – in our case, Windows Mobile 6.1. There are many different methods for porting the MSXIPKernel drivers; each method may yield different build numbers. For example, some chefs use the 723*.DSM for the build number, others use the COREDLL.DLL module to obtain the latest build numbers.
For the purpose of this guide however, we will leave the OEMXIPKernel drivers as-is and use a simpler method of porting the MSXIPKernel drivers from a new (donor) device for use in your kitchen – and not concern ourselves with the build number.
Once the MSXIPKernel is extracted from the new (donor) device xip.bin, the OEMXIPKernel will be extracted from the current (base) kitchen. Both contents will be merged into a new xip.bin file. Additionally, the certificate store verification will have been disabled.
Tools Required
The following tools are required for the new (donor) device MSXIPKernel extraction activities.
XIPPorterEx
Procedure
The following procedure will extract the contents of the MSXIPKernel from the xip.bin of the new (donor) device, the OEMXIPKernel from the current (base) kitchen, and merge them into a new xip_out.bin file.
Navigate to the C:\XDA\My_XIP_Kitchen\ folder.
Launch XIPPORTEREX.EXE.
Clear the following check boxes:
Execute PP Patcher
Delete CACHEFILT.DLL
Delete MENCFILT.DLL
Delete ENCFILT.DLL
Change PP To MB
Don't Copy Xip Dsm
DEBUG Save Temp .BIN Files
Select the following check boxes:
Execute Cert Patcher
Port Only MSXipkernel
Create OEM Package From Unused Xip Modules/Files
Click the PORT IT! button.
At the Cert Patcher: Successfully Nocert Patched! message, click OK.
At the ALL DONE! Now Write New XIP.BIN Into Payload message, click OK.
Exit XIPPORTEREX.EXE.
References
Kernel Overview
http://msdn.microsoft.com/en-us/library/aa909237.aspx
Validating the XIP_OUT.BIN File
At this stage, we have a new xip.bin – currently named xip_out.bin. To ensure that the porting process occurred correctly, we will perform a quick validation of the xip_out.bin file.
If all is well, we will proceed to inject this new xip_out.bin file into our current (base) kitchen os.nb.payload file. In cases where the validation reveals problems, you will need to perform advanced XIP porting procedures – which are beyond the scope of this guide.
Tools Required
The following tools are required for the xip_out.bin validation activities.
XIPPort
Text Editor
Procedure
The following procedure will extract the contents of the newly formed xip_out.bin for validation purposes.
Copy the xip_out.bin file from the C:\XDA\My_XIP_kitchen\MyTools\XIP_new_ported\ folder to the C:\XDA\My_XIP_kitchen\MyTools\ folder.
Rename C:\XDA\My_XIP_kitchen\MyTools\xip_out.bin to C:\XDA\My_XIP_kitchen\MyTools\xip.bin.
Navigate to the C:\XDA\My_XIP_Kitchen\MyTools\ folder.
Launch XIPPORT.EXE.
Click the Dump XIP.BIN button.
Click the Write Maps button.
Exit XIPPORT.EXE.
Launch a text editor.
Select File, Open.
Navigate to the C:\XDA\My_XIP_Kitchen\MyTools\OUT\ folder.
Select the MAP.TXT file.
Compare the beginning (top) portion of the file to against the following tables.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Table 1.1: Validating the XIP_OUT.BIN File
The example below is of a favourable output, no overlaps or gaps.
Code:
00000000 - 01f801fc L01f801fc NUL
01f801fc - 01f801fc L00000000 Start: first DLL address
01f801fc - 01fc8000 L00047e04 NUL
01fc8000 - 01fca000 L00002000 initialized data of region_1 wce_rex.DLL
01fca000 - 01fcb000 L00001000 initialized data of region_1 smem.dll
01fcb000 - 01fcc000 L00001000 initialized data of region_1 MMMAP.dll
01fcc000 - 01fcd000 L00001000 initialized data of region_1 GxDMA.dll
01fcd000 - 01fd4000 L00007000 initialized data of region_1 FLASHDRV.DLL
01fd4000 - 01fd5000 L00001000 initialized data of region_3 FLASHDRV.DLL
01fd5000 - 01fed000 L00018000 initialized data of region_2 DDI.dll
01fed000 - 01fee000 L00001000 initialized data of region_1 ceddk.dll
01fee000 - 01fef000 L00001000 initialized data of region_1 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 mencfilt.dll
01ff3000 - 01ff4000 L00001000 initialized data of region_1 imgfs.dll
01ff4000 - 01ff5000 L00001000 initialized data of region_1 fsreplxfilt.dll
01ff5000 - 01ff6000 L00001000 initialized data of region_1 fsdmgr.dll
01ff6000 - 01ff7000 L00001000 initialized data of region_1 fatutil.dll
01ff7000 - 01ff8000 L00001000 initialized data of region_1 fatfsd.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
[B]...[/B]
Table 1.2: Validating the XIP_OUT.BIN File
The example below indicates possible problems with the imageinfo.bin or imageinfo.txt files found in the C:\XDA\My_XIP_Kitchen\MyTools\SYS\.VM\ and/or C:\XDA\My_XIP_Kitchen\MyTools\SYS\.ROM\ folders of the XIP Porting Kitchen.
Code:
00000000 - 01f801fc L01f801fc NUL
01f801fc - 01f801fc L00000000 Start: first DLL address
01f801fc - 01fc8000 L00047e04 NUL
02000000 - 02000000 L00000000 End: last DLL address
[B]...[/B]
The following procedure may resolve the issue.
Remove the following files
C:\XDA\My_XIP_Kitchen\MyTools\xip.bin
C:\XDA\My_XIP_Kitchen\MyTools\XIP_new_ported\xip_out.bin
Remove the contents in the following folders – do not remove the folder:
C:\XDA\My_XIP_Kitchen\MyTools\OEMXIP_Package\*.*
C:\XDA\My_XIP_Kitchen\MyTools\Dump\*.*
C:\XDA\My_XIP_Kitchen\MyTools\OUT\*.*
C:\XDA\My_XIP_Kitchen\MyTools\SYS\Dump\*.*
Copy the contents of C:\XDA\My_XIP_Kitchen\Templates\SYS\ folder (sub-folder and files) to the C:\XDA\My_XIP_Kitchen\MyTools\ folder.
Repeat the donor MSXIPKernel extraction and validation procedures.
If the problem presists, you will need to perform advanced XIP porting procedures – which are beyond the scope of this guide.
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Table 1.3: Validating the XIP_OUT.BIN File
The example below indicates an overlap problem; you will need to perform advanced XIP porting procedures – which are beyond the scope of this guide.
Code:
00000000 - 01f801fc L01f801fc NUL
01f801fc - 01f801fc L00000000 Start: first DLL address
01f801fc - 01fc8000 L00047e04 NUL
01fc8000 - 01fca000 L00002000 initialized data of region_1 wce_rex.DLL
01fca000 - 01fcb000 L00001000 initialized data of region_1 smem.dll
01fcb000 - 01fcc000 L00001000 initialized data of region_1 MMMAP.dll
[B]...[/B]
02000000 - 02000000 L00000000 End: last DLL address
02000000 - 03dbe000 L01dbe000 NUL
03dbe000 - 03dc7000 L00009000 Virtual base address of wce_rex.DLL
[COLOR="Blue"]03dc7000 - 03dce000 L00007000 Virtual base address of smem.dll[/COLOR]
[COLOR="Red"]03dc7000 - 03dce000 L00001000 !!!!!!!!!!!!!!!!!![/COLOR]
03dce000 - 03dd3000 L00005000 Virtual base address of MMMAP.dll
[B]...[/B]
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Table 1.4: Validating the XIP_OUT.BIN File
The example below indicates a gap problem; you will need to perform advanced XIP porting procedures – which are beyond the scope of this guide.
Code:
00000000 - 01f801fc L01f801fc NUL
01f801fc - 01f801fc L00000000 Start: first DLL address
01f801fc - 01fc8000 L00047e04 NUL
01fc8000 - 01fca000 L00002000 initialized data of region_1 wce_rex.DLL
01fca000 - 01fcb000 L00001000 initialized data of region_1 smem.dll
01fcb000 - 01fcc000 L00001000 initialized data of region_1 MMMAP.dll
[B]...[/B]
02000000 - 02000000 L00000000 End: last DLL address
02000000 - 03dbe000 L01dbe000 NUL
03dbe000 - 03dc7000 L00009000 Virtual base address of wce_rex.DLL
03dc7000 - [U][COLOR="Blue"]03dce000[/COLOR][/U] L00007000 Virtual base address of smem.dll
[U][COLOR="blue"]03dcf000[/COLOR][/U] - 03dd3100 L00005000 Virtual base address of MMMAP.dll
[B]...[/B]
References
[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS)
http://forum.xda-developers.com/showthread.php?t=438676
Preparing the New OS.NB.PAYLOAD File
As we have already disabled Certificate checking, we will not select Execute Cert Patcher; additionally, we will not apply the Execute PP Patcher and Change PP To MB options. As the Execute-In-Place (XIP) region for the Raphael is sufficient in size, we do not need to remove the cachefilt.dll, mencfilt.dll, and encfilt.dll drivers.
Tools Required
The following tools are required to perform the os.nb.payload file update activities.
XIPPorterEx
Procedure
The following procedure will create a new os.nb.payload file which will be used when cooking our ROM.
Navigate to the C:\XDA\MY_XIP_KITCHEN\ folder.
Launch XIPPORTEREX.EXE.
Clear the following check boxes:
Execute Cert Patcher
Execute PP Patcher
Port Only MSXipkernel
Delete CACHEFILT.DLL
Delete MENCFILT.DLL
Delete ENCFILT.DLL
Change PP To MB
Create OEM Package From Unused Xip Modules/Files
Don't Copy Xip Dsm
DEBUG Save Temp .BIN Files
Click the Find Start XIP Offset button; the offset value should indicate: 00320000.
At this stage, the os.nb.payload file has not been reduced; you can select one of the following procedures:
Reducing the Update Loader (ULDR) Partition and Updating the OS.NB.PAYLOAD File.
Updating the OS.NB.PAYLOAD File with No Update Loader (ULDR) Reduction.
Reducing the Update Loader (ULDR) Partition and Updating the OS.NB.PAYLOAD File
The boot loader can accommodate multiple execute-in-place (XIP) regions where individual modules can be updated after the initial operating system image file has been written to the device – the ULDR is an example of this use. The Update Loader (ULDR) provides Flash-Over-The-Air (FOTA) capabilities permitting your carrier to issue changes such as Hotfixes over the cellular network – generally, most carriers avoid this practice.
We will use the ROM Tools feature of the XIPPorterEx tool to adjust the ULDR and remove the debugging system library files. We will commit our changes which will replace the current (base) kitchen xip.bin contents with the new xip_out.bin contents resulting in a final os.nb.payload file – which we will use when cooking our kitchen.
Procedure
Click the ROM Tools button.
Clear the following check boxes:
Conservative Mode
Write NEW Xip Size Into MBR
Select the DEBUG Delete Temp .BIN Files check box.
Click the Give From Your XIP_OUT.BIN button.
Click the Write button.
At the os.nb.payload Was Successfully Reduced... message, click OK.
Click the Done button.
Move the os.nb.payload from C:\XDA\MY_XIP_KITCHEN\XIPPorterEx\MyTools\os.nb.payload_Reduced\ folder to the C:\XDA\MY_XIP_KITCHEN\XIPPorterEx\MyTools\os_nb.payload\ folder –overwriting the older version of the file.
Click the Find Start XIP Offset button; the offset value should indicate: 00020000.
Click the Write It button.
At the NEW os.nb.payload Was Updated Successfully... message, click OK.
Click the ROM Tools button.
Clear the following check boxes:
Conservative Mode
Write NEW Xip Size Into MBR
Select the DEBUG Delete Temp .BIN Files check box.
Click the Write button.
At the os.nb.payload Was Successfully Reduced... message, click OK.
Click the Done button.
Exit XIPPORTEREX.EXE.
Copy the os.nb.payload file from the C:\XDA\MY_XIP_KITCHEN\MyTools\ os.nb.payload_Reduced\ folder to your kitchen .\ROM\ folder.
Note
New (donor) devices are being released with updated resource strings in the NK.EXE module. As a result, you must not attempt to change the Date and/or ROM Version – doing so will corrupt your xip.bin file.
Updating the OS.NB.PAYLOAD File with No Update Loader (ULDR) Reduction
We will commit our changes which will replace the current (base) kitchen xip.bin contents with the new xip_out,bin contents resulting in a final os.nb.payload file – which we will use when cooking our kitchen.
Procedure
Click the Write button.
At the os.nb.payload Was Successfully Reduced... message, click OK.
Click the Done button.
Exit XIPPORTEREX.EXE.
Copy the os.nb.payload file from the C:\XDA\MY_XIP_KITCHEN\MyTools\os.nb.payload\ folder to your kitchen .\ROM\ folder.
Note
New (donor) devices are being released with updated resource strings in the NK.EXE module. As a result, you must not attempt to change the Date and/or ROM Version – doing so will corrupt your xip.bin file.
Unlocking and Resizing the Paging Pool
The Paging Pool serves as a limit on the amount of memory that can be consumed by pageable data. It includes an algorithm for choosing the order in which to remove pageable data from memory. Pool behaviour is typically determined by the OEM – Microsoft sets a default value for the paging pool, but the OEM can change that value. Applications do not have the ability to set the behaviour for their own executables or memory-mapped files.
For the purposes of this guide, we are going to apply a change to the os.nb.payload file which will permit us to change the Paging Pool size (initially set to 6MB) to other sizes using the PagePool Changer tool.
Tools Required
The following tools are required for the Paging Pool unlock activities.
Hexadecimal Editor
Procedure
The following procedure will change the os.nb.payload file to permit adjustments to the Paging Pool size via the PagePool Changer tool.
Navigate to the C:\XDA\MY_XIP_KITCHEN\Editors\xvi32\ folder.
Launch XVI32.EXE.
Select File, Open.
Navigate to your kitchen .\ROM\ folder.
Select All File (*.*) from the Files Of Type list.
Select the os.nb.payload file.
Select Search, Find.
In the Hex String box, type:
03 15 A0 03 02 15 A0 13
Click OK.
Change the following 4 bytes after the 03 15 A0 03 02 15 A0 13 string;
FROM: 00 10 82 E5
TO: 00 00 A0 E1
Select File, Save.
Select File, Exit.
Tip
Make a backup copy of the os.nb.payload file before editing; delete the backup file when done.
References
Paging Pool
http://msdn.microsoft.com/en-us/library/aa915364.aspx
Paging and the Windows CE Paging Pool
http://blogs.msdn.com/ce_base/archive/2008/01/19/Paging-and-the-Windows-CE-Paging-Pool.aspx
Change PagePool Through Hex Editing (For Diamond & Raphael)
http://forum.xda-developers.com/showpost.php?p=2903704&postcount=5
Disabling Certificate Checking
During the startup process of your device, the operating system verifies that each system file against an internal certificate store to ensure that each file is signed with a trusted certificate; if the system file is not signed, the file is ignored.
To allow execution of non-signed system files, we need to disable the internal certificate store verification. Once disabled, the operating system will trust all code installed regardless of its signature. This provides more control over the code that gets installed on the device – you no longer need to load and manually sign additional certificates such as those from the sdkcerts.cab into the device root certificate store.
If you accidentally forgot to disable the certificate store verification during the XIP porting process, you can use the following procedure to apply a change to the os.nb.payload file.
Tools Required
The following tools are required to disable the internal certificate store verification.
AutoPatcher01
Procedure
The following procedure will disable the internal certificate store verification.
Navigate to the C:\XDA\MY_XIP_KITCHEN\Editors\AutoPatcher\ folder.
Launch AUTOPATCHER01.EXE.
Click the Cert Patch button.
Select All File (*.*) from the Files Of Type list.
Navigate to your kitchen .\ROM\ folder.
Select the os.nb.payload binary file.
At the Successfully Patched... message, click OK.
Exit AUTOPATCHER01.EXE.
Tip
Make a backup copy of the os.nb.payload file before editing; delete the backup file when done.
References
[RES] RILPHONE.DLL And "How To" With A Radio
http://forum.xda-developers.com/showthread.php?t=481026
13/02/2010: Tutorial Statistics
Views: 1,390
Guide Downloads: 45
Kitchen Downloads: 72
Well, great article! No offence, but why do you need 19 reserved posts? Even largest projects have less than half of that
My Disclaimer
I take no credit for the kitchen. I just edited and recompiled several tools provided by many users.
Calkulin at PPCgeeks laid the base idea for the XIP kitchen. Ervius Bepe and several others did the real work creating the tools. I consider my role very minute at best. Hilaireg took the time to write everything down. I think everyone should be appreciative of the extreme amount of time put into this.
Alot of the information was built upon all of Ameets hard work as well as the many contributors to the Manual xip porting thread made much of this possible.
I urge everyone that intends to cook to take the time to learn how to port a xip. There is much to be gained by knowing how things work behind all the fancy tools we have these days.