yashsingh1/xdaforums huggingface dataset:
[Windows Mobile Software Development] Ameet:
If you asking about these, e.g.

80131fb4 - 80131ffc L00000048 o32 struct device.exe
[COLOR=red]80131ffc - 80132000 L00000004 NUL[/COLOR]
80132000 - 8019aa99 L00068a99 o32 region_0 rva=00001000 vsize=00068a99 real=03ee4000 psize=00068a9c f=60000020 for crypt32.dll

My guess is since the addresses needs to be divisible by 1000, thats the reason why the NUL spaces. If you see the lengths of these NUL, you will see some are 4, some are 10 and smaller. I could be wrong :)

I have actually been asking questions regarding limits of changing the below values of dllfirst, dlllast, VM, physfirst or how to determine those values to get more free RAM :D But till date no kind sould has been able to answer those :(

00000000 - 01f801fc L01f801fc NUL
[COLOR=blue]01f801fc - 01f801fc L00000000 Start: first DLL address
[/COLOR][COLOR=red]01f801fc - 01fc7000 L00046e04 NUL[/COLOR]
[COLOR=blue]02000000 - 02000000 L00000000 End: last DLL address[/COLOR]
[COLOR=red]02000000 - 03dcb000 L01dcb000 NUL[/COLOR]
[COLOR=red]04000000 - 80000000 L7c000000 NUL[/COLOR]
80000000 - 80000000 L00000000 Start: first physical address
8030c7b3 - 8030c7b3 L00000000 End: highest physical address
8030c7b3 - 8030d000 L0000084d NUL
8030d000 - 8030d000 L00000000 Start: start of RAM
80394000 - 80394000 L00000000 ------ start of RAM free space
80394000 - 83000000 L02c6c000 NUL
83000000 - 83000000 L00000000 End: end of RAM
[Windows Mobile Software Development] Ameet:
Thats a thought we can work on ;) Even then I think the region_0 or the first rva is needed to be divisible by 1000
[Windows Mobile Software Development] Ameet:
That why is still unanswered :( But here's my MAP.txt

8019e9a4 - 8019e9f8 L00000054 rom_00 header: dlls=01f801fc-[COLOR=red]02000000[/COLOR] phys=[COLOR=red]80000000[/COLOR]-[COLOR=blue]8030c7b3[/COLOR], 28 modules, 10 files, 1 copyentries ext=80002b4c ram=8030d000-83000000 cputype=000001c2
[COLOR=blue]8030c7b3 [/COLOR]- 8030c7b3 L00000000 End: highest physical address
8030c7b3 - 8030d000 L0000084d NUL
8030d000 - 8030d000 L00000000 Start: start of RAM
80394000 - 80394000 L00000000 [COLOR=darkorchid]------ start of RAM free space[/COLOR]
[COLOR=darkorchid]80394000 - 83000000 L02c6c000 NUL
[/COLOR]83000000 - 83000000 L00000000 End: end of RAM

The blue value that you mentioned is the physlast value ;) I'm actually wanting to know where to determine the red values from and till what extent we can change those (which is actually the dlllast & physfirst values) But below those, I have never had problems in getting my maps to use the NUL into free RAM area

If you see my dump_memoryMaps, you will find:

01F7F000 - 01F7FFFF (4095 bytes): bthasplugin.dll

after which the dllfirst starts with a difference of 1FD length and

03D66000 - 03D6FFFF (40959 bytes): bthasplugin.dll

after which the vbase starts with a difference of 5B001 length. I will try and defrag these by using these lengths in the xip, but not for now. As far as the physfirst is concerned, I have no idea where to look for the stuff that is there between the below values and till what limit I can pull up the 80000000 value and push down the 83000000 (End of RAM) value to make more space for free RAM area

03ffa000 - 04000000 L00006000 Virtual base address of busenum.dll
[B][COLOR=red]04000000 - 80000000 [/COLOR][/B]L7c000000 NUL
80000000 - 80000000 L00000000 Start: first physical address
[Windows Mobile Software Development] hellonasty:
All credits to Ameet Babrekar is a Master of the XIP!!!!

Xip20924 working in Diamond!!!!!

ABabrekar have a good pacince!!!!

Sorry my english!!!
[Windows Mobile Software Development] stevenh78:
Thanks, I will have another look tonight. What tool do you use to extract the xip.bin and imgfs from os.nb?

How can I edit the values in romhdr.bin to match romhdr.txt, are there any tools to generate romhdr.bin from txt?

I will first try moving modules out of original XIP to see if it works... is there a manifest file that would list what files is being used at boot time?

Thanks

Steven
[Windows Mobile Software Development] FormerPalmOS:
Once you have xip.bin, xipport.exe will generate ROMHDR.txt. I use a tool called dumpxip.exe to generate xip.bin - it also generates the dump file IIRC and romhdr.bin - but I don't use those - I use xipport.exe on the xip.bin. imgfsfromnb.exe will generate imgfs.bin from an os.nb.payload. You can generate that from os.nb with nbsplit.exe. Once you have imgfs.bin, use imgfstodump.exe.

There isn't any such file that lists what must be in the XIP (i.e. what is required at boot phase 1) vs. what can be moved to imgfs (i.e. required at boot phase 2).
[Windows Mobile Software Development] stevenh78:
I see in a lot of threads about HTC ROMs, there is mention of os.nb.payload, how does this differ from os.nb? From what I can tell, my os.nb contains IPL, XIP and imgfs...
[Windows Mobile Software Development] FormerPalmOS:
You may want to search for a tutorial on dumping a ROM. But working from the outside in, here's what you have:

RUU_Signed.nbh is the ROM file - contains everything in a block based format that's easy to transfer across the USB connection. It's signed so the device knows it's legit, and it includes keys to lock it to the right device and language.

There are tools (I use NBHUtil.exe) to extract the pieces from the .nbh. The pieces can be splash screens, radio firmware, and the OS. When you do this you will get an os.nb - this contains the os portion without the block info but with some extra stuff that you need to get rid of.

Next use nbsplit -<device> on os.nb - the <device> flag will depend on your device - for Touch Pro and Diamond and Kaiser use -Kaiser. I don't know what to use for other devices. nbsplit will generate os.nb.payload and os.nb.extra.

From there (os.nb.payload) you can dump the xip.bin and the imgfs.bin.
[Windows Mobile Software Development] stevenh78:
So it sounds like the os.nb.payload is just the same as my os.nb but without the extra bytes.

I'll stick with my current tools to get up to the imgfs and xip part at least and may change the other parts of my kitchen if I'm not successful.

Trying to get the latest version of osnbtool just now, but seems that I need to get some posts going at pdaclan before I can even access that page >.<
[Windows Mobile Software Development] stevenh78:
Right, I've managed to move modules out of XIP to imgfs (I think... how do I check??) and it seems to boot and work fine with the original firmware.

Is there anything I can do or put into the XIP so I can look when the system is up and running to determine that it really did work, e.g. a custom version number somewhere or something that only applies to the XIP part?

I will try porting a new XIP tomorrow.
[Windows Mobile Software Development] FormerPalmOS:
Hexedit the S000 file in the nk.exe module folder and search for the revision string. You can find it by doing a search for the unicode string "Kernel Built" (hex string 4B 00 65 00 72 00 6E 00 65 00 6C 00 20 00 42 00 75 00 69 00 6C 00 74 00). Shortly after that will be the revision that is displayed on the phase 1 boot screen (small red letters in the lower right corner of the device on CDMA Touch Pro). Change that (make sure to overwrite, not to insert, and limit it to 12 characters in unicode format.

When you rebuild your xip.bin and cook with it, you should see this value on the screen during phase 1 boot. The only other way would be to insert a marker into the boot registry.
[Windows Mobile Software Development] DaveShaw:
Thanks mate, I'd been meaning to find out where this string was in NK.exe. Saved me a job :D :D

Dave
[Windows Mobile Software Development] stevenh78:
Hmm... i think that's different with my Omnia as I don't see any version displayed during booting...

I could edit the rgu files, but these are copied in some way into imgfs by buildos aren't they?

Can I actually get rid of all the rgu and dsm files or must they reside in the xip as well?
[Windows Mobile Software Development] FormerPalmOS:
You should keep the .dsm and .rgu files. If you change boot.rgu depending on your tools flow, you may have to convert it to the .hv format using MS rgucomp tool (output file boot.hv). Easiest way is to go ahead and edit the revision string in the nk.exe S000 file, build your ROM then search for the edited string in the completed ROM. If you find it then you know your new XIP was cooked in. If it's cooked in the .nbh file you flash to your device then you can be assured that this is what your device is booting with.
[Windows Mobile Software Development] stevenh78:
I'm definitely flashing the right image cause it's stopped booting after I removed wince.nls from the XIP. I copied the WinCENLS_Lang_0804 directory from the 'FILES' directory and put that into SYS. BuildOS picked it up and packed it into my imgfs.bin, but when I flash my phone it doesn't boot. If I move the directory back into the XIP, then it boots fine... Any ideas what I'm missing here?

Not sure about the 0804 though since system is 0409, this is proper ROM direct from Samsung site...

Should I also copy LangDB and MSXIPKernelLTK directories to SYS? I see these only contain dsm files...

Thanks

Steven
[Windows Mobile Software Development] FormerPalmOS:
0804 is Chinese. Here's a WWE version. There could be a dependency in your XIP on this - in the CDMA Touch Pro there is not so its safe to remove it. Note - make sure you create/edit the corresponding wince.nls.imageinfo.txt file. The correct size for this is 0x42C6A. So your wince.nls.imageinfo.txt should look something like this (the ulLoadOffset and lpszFileName values aren't important - xipport.exe will re-calculate those when you click the realloc P button):

File name: wince.nls

dwFileAttributes: 00000007

ftTime: 01C86E4254395700

nRealFileSize: 00042C6A

nCompFileSize: 00042C6A

lpszFileName: P+001D4FDC

ulLoadOffset: P+0036EA30

Note - don't copy/paste this as the forum compresses out whitespace - copy some other imageinfo.txt file and just fill in the right File name and sizes.

You can and should leave out the LangDB and MSXIPKernelLTK directories (and associated DSMs). That should get you a little bit of space.
[Windows Mobile Software Development] Ameet:
It is widely found that especially for Diamond ROMs the wince folder cannot be included in IMGFS. The ROM doesnt boot. For the working ROM that module has to be in the XIP folder :( Not found a way to include that out of XIP, coz that will surely save around 260kb space in the memory :(

Maybe your device is suffering from that syndrome :D
[Windows Mobile Software Development] Ameet:
Thanks brother :D Added your post to the 1st page since we all have been searching to change this ;)
[Windows Mobile Software Development] stevenh78:
Thanks for the file, however I'm a little confused... since we are moving it out of the XIP, what does xipport have to do with it? Can I not just put the new module into SYS like the others?

Well I've replaced the XIP version of wince.nls with your version and all seems fine :) Still couldn't get it to work from SYS though...

I've also deleted LangDB and MSXIPKernelLTK with no noticeable side effects.

My next step now is to see if I can use the i908 XIP, though looking at the map, doesn't seem like I can use it as is since the location of busenum.dll is different? With my i900 the busenum.dll ends at 0x02000000 but in the i908 it ends at 0x04000000 even though should be same hardware etc. Think I'll have to do a lot of relocating.... is there a 'mass relocator' available to quickly subtract 0x02000000 from everything?

One of the reasons why I am doing this is that we have been trying to fix a bluetooth voice command routing issue with the i900 which is fixed in the i908, we managed to replace the audio drivers and a few other things to make it work, but can't solve the wakeup issue where we can't wake the phone up with any button other than the power button. I've tried replacing just about every file in the drivers and applications so only one that's left now is the XIP... Can you guys think of any other reasons for this wakeup issue?

Once I have that ironed out, I'll be trying to port to new XIP versions :)

Steven
[Windows Mobile Software Development] FormerPalmOS:
The change is only visible though if the pase 1 boot kernel actually displays something during phase 1 boot. The CDMA Touch Pro does - but according to stevehnh78 the Omnia does not.
[Windows Mobile Software Development] FormerPalmOS:
I was saying that if you replace the wince.nls file in your XIP with mine, you have to manually edit the wince.nls.imageinfo.txt file so xipport.exe knows how big the file is when it figures out where to put it in the physical allocation of things into the XIP. If you are removing it from the XIP, you don't need the imageinfo.txt file - just the file itself into SYS. But as Ameet said, your kernel may need it in the XIP.

busenum.dll is part of the OEMXIPKernel package. Typically the stuff in there is hardware-specific. Even with "similar" hardware, combining things will usually fail. But you could do it one at a time until it doesn't boot - replace an i900 OEMXIPKernel module with the same module from the i908 OEMXIPKernel, relocate the module, relocate the physical layout (xipport.exe), check for overlaps, build it, insert it, cook it, boot it, curse it, repeat (sound fun yet?)

There is a tool called XIPAddrTools.exe that will sort-of do what you are asking - but it has some bugs. Basically you combine the files you want to make an XIP out of (including the imageinfo.txt files) into an OUT directory, run the tool, select your OUT directory for your new XIP as your work directory, and select the dump directory where your original XIP was dumped as a reference directory. Then go one by one down the list of modules and press spacebar. This will relocate the module in the OUT directory to the same address as the REF directory. WOrks great unless the modules are of different sizes then you are back to manual reallocation.

The audio issue you are seeing is most likely a registry setting and not a function of the XIP. Look at the list of OEM drivers you have then look for registry settings in HKCU\Control Panel (especially Power), HKLM\Control Panel (again, especially Power), and HKLM\System. Only someone else with your hardware will be able to give you any better guidance. Another thought is to capture your registry and the registry of a machine that does not have the problem and compare the two. Neither is fun. BTW - that discussion should also be moved to a different thread as this thread is XIP.
[Windows Mobile Software Development] stevenh78:
Thanks, I've ported just about everything over, the only thing that's left now are nk.exe and giisr.dll.

I've managed to relocate nk.exe to match my original start location to avoid conflicts with ram start, but m'reloc refuses to touch giisr.dll, I always get "wrong value in o32_realaddr". Any idea how to relocate this module, is it safe to use m'reloc_nk or does that change other things as well?

Thanks

Steven
[Windows Mobile Software Development] FormerPalmOS:
Can you post your ORIGINAL giisr.dll.imageinfo.txt file and the ORIGINAL map.txt when you dumped your XIP? It might be that m'reloc_nk.exe will be required if giisr.dll has a hard-coded RAM address instead of having a virtual offset.
[Windows Mobile Software Development] stevenh78:
Hi, I've attached the map.txt and the imageinfo.txt. Note that I actually used winrar as I don't have winzip installed on this machine...

I tried to put the original giisr.dll back in but it doesn't boot, I guess it probably ties in together with nk.exe....
[Windows Mobile Software Development] stevenh78:
I replaced nk.exe with original and used ported giisr.dll relocated using m'reloc_nk and it seems to work, but as soon as I put the new nk.exe in and relocate it, it falls over and doesn't boot.

This is strange as in the past I had used the i908 firmware before and I even pretty much replaced everything in imgfs and it still booted, so don't know what's wrong now...

Oh well, just as I almost finished typing this message, the phone booted with the new nk.exe! In this latest attempt I switched to using the i908 bootloader and IPL...
[Windows Mobile Software Development] FormerPalmOS:
OK - giisr.dll does indeed have a fixed RAM address so you would need to use m'reloc_nk.exe on it. The original XIP has some wasted space - was that from a stock ROM or a custom?
[Windows Mobile Software Development] stevenh78:
It was originally stock ROM but I then deleted some files to make room for porting later...

Does anyone ever touch the section before XIP, i.e. the IPL?

I tried extracting it and it looks quite similar to the XIP....
[Windows Mobile Software Development] stevenh78:
Seems that nk.exe is tied in closely with the bootloader so if changing one then the other might need to change to match...
[Windows Mobile Software Development] stevenh78:
Problems with sys now...

Hi, I have managed to port XIP from one version of the device to another and fixed the wakeup issue we were having :) Thanks for all the help on that.

Now I am trying to port the SYS to a newer version. I've found that if I port only the SYS, then after booting, the screen goes blank.

If I port both SYS and XIP, then the system boots up but I have a problem with the finger mouse in that it sometimes disappears or I get funny graphics from it... is there another driver that is maybe located under SYS? I have also tried using the shell32.exe and shellres.dll from the original ROM, but when I do that it boots to the green screen but I don't get the touch screen to continue message and the phone hangs. Any ideas on this one?

Thanks

Steven
[Windows Mobile Software Development] utak3r:
I did follow ULDR shrinking on Hermes. I think all is right, 'cause all the tools show the proper info and files... but I cannot flash my new image, I get 270 (file corrupt) error :mad:

May someone do tell me exactly the way of handling my extra file and putting all of this into new working file? Just right after hexediting?
[Windows Mobile Software Development] Ameet:
Did you check the MBR section correctly. Try using Ervius's kitchen Rev 37 and then cook and see
[Windows Mobile Software Development] ivanmmj:
Do you guys think you can add a section on converting a ROM from XPR to LZX compression to save 10-12mb's?
[Windows Mobile Software Development] Ameet:
I'll speak to u in pm and understand the process and will surely add it up to the tutorials :) that will surely be a great value add :)
[Windows Mobile Software Development] FormerPalmOS:
The decompression speed is what you should care about. Everything in IMGFS is stored compressed. When requested, if not already in the pagepool it has to be read from the flash then decompressed. Thus the access time is the sum of the read time (better with smaller file) and the decompression time (better with faster decompression). Between the two, I suspect the decompression time matters more since the difference in compressed size is like ~10% best case and probably only a few %. So before assuming that LZX is better just because it takes up less space, check which one decompresses faster. I suspect XPR though I have no data to back this up.
[Windows Mobile Software Development] utak3r:
Well, LZX is widely used on all other platforms as compression platform for embedded systems. Back 2 years ago I was making some research on this subject on a relatively slow machine (Wizard) and the speed difference was rather theoretical, in numbers, than in real life using.
[Windows Mobile Software Development] letama:
Hi guys,

I have a few questions for you. I'm trying to relocate a XIP but it fails miserably :).

First, what are the actions behind xipport buttons? From what I understand, "make packages" does files->packages, "Undo" does packages->files, but what does Realloc P exactly?

Next, My xip rebuilt seems fine, no conflict after redumping and write maps, however it doesn't boot. It seems to do something though, the screen is flickering. Any idea on what could be wrong? I tried to port it with xipportex, it ends the same. The sys seems to be ok and boots with another XIP.

I had to do more than usual with this one, playing with XipAddressTools tabs that I never used before, and relocating files editing txt by hand after. Not sure I did it well.

I attached the maps if someone wants to take a look.
[Windows Mobile Software Development] stevenh78:
What device is that for? I see you don't have wince.nls, some devices require it in XIP...

What does your original map look like? Was there any conflicts in that? Might want to post original...
[Windows Mobile Software Development] FormerPalmOS:
Definitely not Touch Pro based on Rom Header. Agree with previous post - add wince.nls and see if that solves your problem.

Realloc P re-calculates the physical layout of the XIP partition on the FlashDrive. Think of it as defragmenting your hard drive, sort-of. Your description of the other functions is OK.

Assuming you are using xipport.exe build xip_out.bin, how are you then inserting that into your ROM? xipport.exe write to os.nb function is buggy. Better to use a tool called insertxip.exe with a known good donor os.nb.payload.
[Windows Mobile Software Development] letama:
This is for the Elf, I'll try to add the wince.nls.

It's ported from 21038 posted in diamond forum here:

http://xdaforums.com/showthread.php?p=3485644

I attached the maps from it.
[Windows Mobile Software Development] FormerPalmOS:
21038 could be your problem. Rumor has it that's a fake build. Stick with 21028 or 21032 (which is mostly 21028 - only three modules changed - MSPART, PM and REGENUM).

Is there anything else removed in your ported XIP vs. the stock Elf XIP?
[Windows Mobile Software Development] letama:
Yes, I saw the 21038 controversy. I ported 21028 already, it works fine. It's more for fun and learning than anything else, this is the first xip on which I do so much manually.

I don't think so, I'll double check.

Regarding your previous question with xip insertion, I cook with Hybrid kitchen that uses msflshtool, I have also insertxip, I'll give it a shot.
[Windows Mobile Software Development] letama:
So, if I use XipAddressTool to relocate modules / phy address and then fix by hand txt files, do I still have to use it before writing xip ? Or does it try to do the same and therefore breaks XipAddressTool work ?
[Windows Mobile Software Development] FormerPalmOS:
You should not have to edit the .txt files - you can do it all from XIPAddrTools. The ONLY times it doesn't work are a) for the DLL base addresses and b) when a module has two sections that have to be re-located. When you click on a module in the main tab (not the DLL or Virtual Base tab), you will see two of the three boxes in the lower right populated with the current DLL address and virtual memory base address. Then look on the right side of the screen and find the row where the address matches the DLL address and click on it. Now, you can modify the virtual memory base and DLL address. If you modify the VM base, you have to click the Modify box below the left two boxes and you're done. If you modify the DLL address you have to change BOTH boxes and click BOTH modify buttons. This will also update the .txt file for you. This seems like a bug in the program, but doing it this way always works.

Now, if you have a module with two sections that have to be re-located (FLASHDRV and DDI in the Touch Pro are like this) its more difficult. I won't cover that here.

Anyway, once you are done with relocating the modules you still have to re-calculate the physical layout - that's what the Reloc P button is for. Relocating a module just changes the data pointers in the module itself so that it loads to and points to the right memory locations. You still have to physically lay out the module files and other XIP files in the flash partition - that's what the Realloc P button does.