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
Attn : Jeff summer
First thks for your effort for creating the cook rom page.
Just lock in the page and found out you have the Tmobile 4.00.10 rom cooking rom included in your web page http://cuba.calyx.nl/~jsummers/ROMkitchen/, But after downloaded and flash, the additional software is not included in the files in the selected windows.
thks again :wink:
OCMAX said:
Just lock in the page and found out you have the Tmobile 4.00.10 rom cooking rom included in your web page http://cuba.calyx.nl/~jsummers/ROMkitchen/, But after downloaded and flash, the additional software is not included in the files in the selected windows.quote]
Ohoh. Small mistake on my part. Fixed...
Click to expand...
Click to collapse
Hi Jeff,
Thanks for providing a wonderful site, but I would like to find from you is that, the T-Mobile v4.00.10 ROM does it come clean in terms of no customization like the today plug-in just like the 4.00.05?
In the Asia 02 XDA, it seems to have some problem with the T-Mobile v4.00.10 probably due to the customization of the setup.
I have tried the one located here, just thinking that if yours would be the PLAIN v4.00.10?
Thanks again for the wonderful setup and site.
I just tried to cook a rom and I got this error:
Warning: fopen(../../download/jaqpailv/log.html): failed to open stream: Not a directory in /home/jsummers/public_html/ROMkitchen/processor.php on line 104
Warning: fputs(): supplied argument is not a valid stream resource in /home/jsummers/public_html/ROMkitchen/processor.php on line 105
Warning: fclose(): supplied argument is not a valid stream resource in /home/jsummers/public_html/ROMkitchen/processor.php on line 106
Warning: rename(rom.exe,../../download/jaqpailv/rom.exe): Not a directory in /home/jsummers/public_html/ROMkitchen/processor.php on line 110
Thanks!
No working at all
Just tested: works for me... Maybe a glitch...
Worked for me yesterday evening too!
Many thanks Jeff!
Geoff
Wasn't working for me this morning, but seems to work fine right now...
Jeff-Kitchen is OK now :lol:
Thanks
Not working again?
Not for 3.17?
Warning: OS type not detected, you may need to set tounicode variable manuallywrite xip block starting at 81800000, with 24 fileswrite xip block starting at 81940000, with 0 filesheader : No such file or directoryError creating new rom.
Hope somebody will fix this. :wink:
Re: Not working again?
OCMAX said:
Not for 3.17?
Warning: OS type not detected, you may need to set tounicode variable manuallywrite xip block starting at 81800000, with 24 fileswrite xip block starting at 81940000, with 0 filesheader : No such file or directoryError creating new rom.
Hope somebody will fix this. :wink:
Click to expand...
Click to collapse
Works fine for me...:
Code:
Warning: OS type not detected, you may need to set tounicode variable manually
no files for configid 26220739
write xip block starting at 81800000, with 3 files
write xip block starting at 81980000, with 190 files
this rom seems to be 3.17.03 ENG 2003-05-15 o2euro
this bootloader seems to be V5.22 2003-05-15 17:46:55
80000000 - 80040000 -- bootloader 0 files 1 modules
80040000 - 8026a804 -- kernel 13 files 11 modules
802c2000 - 8057d330 9 OS 15 files 32 modules
80580000 - 8075a69c 8 SHELL 79 files 27 modules
80780000 - 80a13b04 7 BROWSING 9 files 14 modules
80a40000 - 80d8a33c 6 COREAPPS 46 files 30 modules
80dc0000 - 80ebd150 5 SYNC 12 files 22 modules
80ec0000 - 810388e0 4 24MAPPS 13 files 13 modules
81080000 - 81348248 3 24MCONSUMER 69 files 1 modules
81400000 - 814019a4 -- xip chain 10 xip entries
81440000 -817f6f14 1 MISC 209 files 40 modules
81800000 - 818ffff0 10 XDA_DEVELOPERS1 3 files 0 modules
81900000 - 81925800 -- bitmap : f9fff9ff .. f9fff9ff
81940000 - 81960278 -- operator rom 10 files81980000 -
81e205c8 11 XDA_DEVELOPERS2 190 files 0 modules
../rom.exe: found a preamble of 31232 bytes adding: English/NK.nbf (deflated 51%)
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.
Hi,
I want to get out via a MortScript-routine the folder name of the internal flashdrive, e.x. \My Flash Drive. I wrote a routine that looks for all installed drives that are FAT/EXFAT formatted, but that down't help:
Code:
#TestDrivesFATFS.mscr
###########################################################################
#Searches all installed FATFS/exFAT drives except the one this script resides,
#because only those drives MioPocket can be installed on
###########################################################################
#
#Each filesystem is described in registry as
# [HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\<MyProfileName>]
# "DefaultFileSystem"="<MyFileSystem>"
# "Folder"="<MyFolderName>"
Local()
#Obligatory coding as to be found in some MioPocket's scripts
Drive = "\" & Part(SystemPath("ScriptPath"), "\", 2)
#Test starts here
ExcludeDrive = Substr(Drive, 2)
DrivesFATFS = Array()
RegKey = "System\StorageManager\Profiles"
Idx = 0
#Walk the chain of profiles
ForEach variable In RegSubkeys("HKLM", RegKey)
ForEach value, contents In Regvalues("HKLM", RegKey & "\" & variable)
#Some newer CE devices know of exFAT format
If((value eq "DefaultFileSystem") AND (contents ne "FATFS") AND (contents ne "EXFAT"))
Break
EndIf
If((value eq "Folder") AND (contents ne ExcludeDrive))
Idx += 1
DrivesFATFS[Idx] = "\" & contents
EndIf
EndForEach
EndForEach
If(Debug)
ForEach drv in Array(DrivesFATFS)
Message(drv)
EndForeach
EndIf
Any help appriciated. TIA
It can be found in the Registry (at least in my WinMo 6.1... don't know if it's the same way in CE releases or other brands). Look in "HKLM\System\StorageManager\INAND" (or MMC instead of INAND...). The drive name is the "folder" string value).
Thanks for your reply. What I'm searching for is a hint how I can determine per software (MortScript), already having got ( with a piece of code as postet above ) a list of drive-names, which of those is the Storage Card and which is the Flash Drive, not by default knowing of the drive-names, because those differ from device to device.
Running the code above on my device (Medion PNA with CE 5) returns among others the names \Storage Card and/or \My Flash Disk, but this doesn't really help me a lot.
Thanks to all for your interest.
=> SOLVED IT BY MYSELF!
If you are interested in how I did it, here the code to detect the name of SD(HC), MMC, etc card:
Code:
ErrorLevel("warn")
sd = @FindSDDrives()
ForEach drv in Array(sd)
Message(drv)
EndForEach
Sub FindSDDrives()
Local()
SDProfiles = Array()
SDDrives = Array()
SDDrives2 = Array()
#All CE filesystem profiles related to Storage Cards are listet under
#[HKEY_LOCAL_MACHINE\Drivers\SDCARD\ClientDrivers\Class\******]
#E.x. MMC_Class, SDMemory_Class
idx = 0
RegKey = "Drivers\SDCARD\ClientDrivers\Class"
ForEach sdcard In RegSubkeys("HKLM", RegKey)
ForEach value, contents In RegValues("HKLM", RegKey & "\" & sdcard)
If(value eq "Profile")
idx += 1
SDProfiles[idx] = contents
EndIf
EndForEach
EndForEach
#Each CE filesystem is described in registry as
# [HKEY_LOCAL_MACHINE\System\StorageManager\Profiles\<MyProfileName>]
# "DefaultFileSystem"="<MyFileSystem>"
# "Folder"="<MyFolderName>"
# "Name"="<MyName>
idx = 0
RegKey = "System\StorageManager\Profiles"
ForEach profile in Array(SDProfiles)
ForEach value, contents In RegValues("HKLM", RegKey & "\" & profile)
If(value eq "Folder")
idx += 1
SDDrives[idx] = "\" & contents
EndIf
EndForeach
EndForEach
Clear(SDProfiles)
#Remove duplicates
idx = 0
idx2 = 0
prevdrv = ""
ForEach drv in Array(SDDrives)
idx += 1
If(SDDrives[idx] ne prevdrv)
idx2 += 1
prevdrv = SDDrives[idx]
SDDrives2[idx2] = prevdrv
EndIf
EndForEach
Clear(SDDrives)
Return(SDDrives2)
EndSub
Thanks
jwoegerbauer said:
Thanks to all for your interest.
=> SOLVED IT BY MYSELF!
If you are interested in how I did it, here the code to detect the name of SD(HC), MMC, etc card:
Click to expand...
Click to collapse
Usefull for XDA_UC build in like EnergyROMs. Don't try the German ROMs because of copying files from "Storage Crad" vs. "Speicherkarte" . Now thats solved.
Thanks.