yashsingh1/xdaforums huggingface dataset:
[Windows Mobile Software Development] ervius:
this xip.bin is builded with paltformrebuilder by bepe, is unrelocable, so you cannot use it in any case with other thevice, you can use it only (maybe!) without touch it and only on device that is builded for.....

bye!!!
[Windows Mobile Software Development] inertiax3:
Thanks for the info.. I didn't know..I will look for another version then. Sorry for any trouble caused ;)
[Windows Mobile Software Development] FormerPalmOS:
I'm not sure this makes sense. Unless PlatformRebuilder is making significant changes to the code itself (vs. just the offsets), the modules should still be relocatable as needed. Using XIPPort.exe to dump XIP.BIN will generate the necessary information about the current module addresses and data locations, which you should be able to modify as needed (using m"reloc.exe or XIPAddrToolse.exe), then reallocate the physical structure of XIP.bin and re-build it. Even if PlatformRebuilder removes the manifests (.DSM files), you can re-generate them if needed (so the make packages function works properly) - or just do it the hard way - replace the MSXIPKernel modules in your working XIP (which should work with XIPPort.exe make packages) - just see what files and modules are in the MSXIPKernel directory in your working XIP and replace those with the same name files / modules from the dumped donor XIP.

I have yet to find an XIP - even from a "protected" ROM that can't be ported this way.
[Windows Mobile Software Development] anryl:
i dont know if its unrelocable but his porting problem is the ported xip is tooo big so he schould remove cachefilt and move lsomacore and lsomaclient from xip to imgfs then xipport working fine :cool:

other 21109xip source here
[Windows Mobile Software Development] ervius:
did you check that into all modules last s00x is deleted??? inside all information are about module relockation.....

I didn't try the mreloc with xipport, too long the process, and also if it could work, I prefer an original xip and platformrebuilder, no problem of overlapping, no problem of first-last dll offsets, no problem, nothing to delete to obtain more free space into....

but you can post your own ported xip.bin.....
[Windows Mobile Software Development] FormerPalmOS:
I have a thread here on PPCGeeks with a number of XIPs ported to the CDMA Touch Pro. All should be dumpable and portable to any other device. I've removed some unused items and compressed out the free space and relocated nk.exe to recover ~1MB of program memory. All have booted successfully on a number of folks' CDMA Touch Pros.

I also shrunk the MSFlash partition sizes, but all that does is recover storage memory.
[Windows Mobile Software Development] ervius:
azz, you are true, the xips builded with platformrebuilder are reallocable and no !!! see if port it from a device to another, but only if I use my oldxipporterex, with the support of greloc and xipport.exe by bepe....

now I have to check if is possible to obtain same with all IMGFS part modules into rom ;)

bye!!!
[Windows Mobile Software Development] stevenh78:
XIP porting tools for Samsung i90x, Omnia?

Hi, just wondering about the guide in post #1, can that also be used to apply to the Samsung Omnia? The kitchen I am using contains some of the files listed, when I tried, things didn't really work so thinking might need new tools versions?

I tried the following and ended with a non-booting system, can anyone spot anything?

1. Extract xip.bin from os.nb using osnbtool.exe

2. dump xip.bin with xipport, wrote maps.

3. looked at map.txt and seems already to be an overlap with 2 modules, don't know if this was intentional or not, one of them is nk.exe

4. wrote xip_out.bin

5 re-inserted into os.nb using osnbtool.exe

6 built rom with kitchen and flash

As you can see from above, I didn't actually change anything in the xip, just extract, dump, rebuild etc just to prove the flow but that failed...

Please help.

Thanks

Steven
[Windows Mobile Software Development] Ameet:
Did you try any Omnia kitchen or tried Bepe's new kitchen?
[Windows Mobile Software Development] stevenh78:
I'm currently using an Omnia kitchen, from here:

http://winmo.sztupy.hu/syok.html

I will have a search for Bepe's kitchen, can it be used for any device or is it specific to HTC?

Thanks

Steven
[Windows Mobile Software Development] FormerPalmOS:
If Write Maps on the stock XIP shows an overlap, but the stock XIP was booting, this implies either a bug in the XIP.bin extraction, a bug in xipport.exe, or some other strangeness. For sure, if there is an overlap, xipport.exe will either fail to build a new one, or the new one won't boot. Definitely have to fix the overlap first.
[Windows Mobile Software Development] Ameet:
Try using Mreloc_nk for reallocing the nk.exe and correct the overlap. You may have to play around with the ulRamStart & Physlast in the ROMHDR.txt file :) Post your MAP.txt & ROMHDR.txt files so we can also check from here ;)
[Windows Mobile Software Development] stevenh78:
Thanks guys, will try tonight, going to try find newer version of xipport to see if it still says overlap in the stock rom cause it's quite strange....

Steven

ps. Anyone else keep getting HTTP 500 internal errors when accessing this site?
[Windows Mobile Software Development] FormerPalmOS:
Note - you have to be careful re-locating nk.exe. You can only relocate it to page boundaries. This means the o32_realaddr field must be something like 802D8000, 802DC000, 802E000, 802E4000, etc (fourth least significant hex digit must be 0, 4, 8 or C and the three least must be zero). THen you have to make sure that the physlast, ulRAMStart and ulRAMFree line up with wherever you are moving the nk.exe RAM contents.

Definitely post your map.txt.
[Windows Mobile Software Development] stevenh78:
Hi, I think I've finally got the flow kind of working, problem was I was using a program called buildxip that was recreating the xip.bin from a dump that used dump.exe and the map from this seems to be all wrong with nk.exe overlapping etc.

Anyway, I extracted the xip.bin using osnbtool and dumped it using xipport and played around a bit and managed to re-insert and get a booting system.

Next step is to try and swap out more of the modules and do a port to a newer xip... but that's for another day ;)

Thanks

Steven
[Windows Mobile Software Development] FormerPalmOS:
"that's for another day" - famos last words of a soon-to-be addict...
[Windows Mobile Software Development] Ameet:
Normally buildxip doesnt work for Diamond ROMs, I dont know about Omnia :D Maybe that was creating the overlap in RAM area. Do work afresh and let us know ;)

Very true.. Am sure these are going to be his last words :D
[Windows Mobile Software Development] stevenh78:
Addict? Never! Just got my phone a few weeks ago, started flashing the day after and been messing with new builds and cooking new ROMs 5 times a week... I'm no addict :p

Got a small question... when building the ROM, are any of the XIP modules actually required, I mean is it sufficient to insert the xip.bin or does the modules have to exist as well for when running buildos etc?

Also, are there any other files I need to modify if i'm modifying stuff in the XIP, such as the files in .ROM and .VM? Not sure what's in these directories...

Would also be nice if someone could point me to some kind of guide which shows how the whole boot process hangs together and the memory map of WM so I can have a clearer picture of what I can mess around with... Still trying to get to grips with the relocation stuff... I assume that only applies to XIP? Is there anything in SYS that would reference modules in XIP that I would have to update addresses for?

Thanks

Steven
[Windows Mobile Software Development] dirtytwo:
Good stuff, thanks.

dirtytwo
[Windows Mobile Software Development] Ameet:
Cool find brother :D This is surely going to the 1st page of this thread :)

here: http://xdaforums.com/showpost.php?p=2812740&postcount=4
[Windows Mobile Software Development] stevenh78:
Wow, thanks man that's loads of useful info! My brain a bit fried from working today so will take a little time to digest all that...

I tried porting SYS but after booting and before reaching welcome screen it goes blank and hangs, not sure if it's cause I haven't ported XIP. Do they have to hang together?

You say that after nk.exe has finished doing its stuff and loaded imgfs, it hands control over to the OS... is it then safe to say that the XIP and SYS can be completely independent apart from the OS having to have the correct entry address? Where is this

address stored?

Anyway, I tried XIP port and now I'm stuck at what to do with relocating some of the modules... I did the easy bits, but now I have:

80126000 - 80126158 L00000158 o32 region_2 rva=00005000 vsize=00000158 real=03ecb000 psize=00000158 f=40000040 for diskcache.dll

80126158 - 80127000 L00000ea8 NUL

80127000 - 8013642a L0000f42a o32 region_0 rva=00001000 vsize=0000f42a real=03eb4000 psize=0000f42c f=60000020 for fatfsd.dll

80129f98 - 8013642a L0000c492 !!!!!!!!!!!!!!!!!!

80129f98 - 80129fec L00000054 o32 region_3 rva=00006000 vsize=00001000 real=00000000 psize=00000054 f=42000042 for ceddk.dll

80129fec - 80137000 L0000d014 NUL

How do I relocate these sections? Is it just case of editing the txt file? I also don't see an obvious place to relocate them to as in the module relocations I did before this, there was also sufficient free space nearby to relocate...

Thanks

Steven
[Windows Mobile Software Development] Nokser:
You reloc to move up fatfsd.dll.....
[Windows Mobile Software Development] Nokser:
Look, red line are identical
[Windows Mobile Software Development] FormerPalmOS:
In general it's good for the MSXIPKernel version to match the SYS version, but there are plenty of combinations that don't match but boot fine.

Once the XIP has loaded and initialized the filesystem, the handing-off of the boot process to the OS is more conventional (i.e. execute this .exe or execute this function in this .dll). The only hard-coded address is the entry point in the XIP - this address is hard coded in the IPL and you shouldn't change it, nor should you ever need to under any circumstances.

The conflict you are showing above is in the physical storage of the XIP in the flash. Assuming the following are all true:

a) You have no conflicts in the first section of MAP.txt (series of initialized data for xxx.dll)

b) You have no conflicts in the second section of MAP.txt (series of Virtual base address of xxx.dll)

c) The order of dlls in the above two sections is identical

d) busenum.dll is the last one in both cases

Then portxip.exe will re-map the physical XIP layout for you. Once you have a MAP.txt with no conflicts in the first two sections, click the realloc P button in xipport.exe then click write maps again and check - you shouldn't have a single exclamation point anywhere in map.txt. If you do, something is still wrong. If you don't, then click build XIP.bin and cook away!
[Windows Mobile Software Development] FormerPalmOS:
The not enough space error means there isn't enough physical room between 0x80010000 and the physlast in your ROMHDR.txt to fit the physical XIP. You need to grow the XIP space (change physlast but that will potentially require moving nk.exe which must be done carefully) or find something to remove.
[Windows Mobile Software Development] stevenh78:
Any suggestions on what to remove? What's the problem with moving nk.exe? I've seen there's a special relocation tool for it, but what should I be careful of?

Thanks

Steven
[Windows Mobile Software Development] FormerPalmOS:
Not knowing your device, I can't tell you for sure, but you can probably move lsomaclient.dll and lsomacore.dll - those are the LockStream Digital Rights Management dlls - they can be safely moved to IMGFS (just make sure they are in your OEM pack and add them if not already - they can stay as modules but will need to be relocated - g'reloc.exe will take care of that for you. You may also be able to move lsfilter.dll to IMGFS - though doing so could cause problems for some DRM-enabled things - if so move it back. Start with lsomaclient and lsomacore.

As for nk.exe yes you must use the special tool, and you must pay attention to the address offsets where you relocate the RAM - lower 14 bits must be zero - see earlier post.
[Windows Mobile Software Development] stevenh78:
Hi, thanks for all the help, I have another few more questions:

1. Since the IPL executes a jump to busenum.dll, then does that mean that the address of busenum.dll has to be fixed, so I can't move it anywhere? In my map, it looks as if there is free space after busenum.dll....

2. If I remove Isomaclient.dll and Isomacore.dll from the XIP, how do I incorporate into the OS, do I have to add any registry settings, or is it sufficient to just have a copy in SYS or OEM?

3. I am using a tool called osnbtool.exe to dump and compress sections into and out of os.nb, so here I have part 0 = IPL, 1 = XIP and 2 = imgfs. If I want to put a bigger XIP in than what was there originally, how would

I go about moving imgfs, or does it really matter?

4. Similarly, does the imgfs have to fit into same size as original within os.nb or would it grow to fit (assuming system has enough real space to store it).

5. I assume romhdr.bin is used when writing out new xip, so if I adjust memory sizes there, xipport should pick it up? Where else do I need to update if I change memory sizes etc?

6. If the XIP is only used for initial loading of imgfs, then what is the point of updating the XIP, or are parts of it used by the OS when it is running? This bit I'm still confused with...

Ah, one more thing, in the original, pocketfs.dll has an overlap with one of it's own data regions in the first section, not sure if it matters but I relocated it anyway, not sure if that is normal? I built an XIP before with this still there and it seemed to work but just in case... so basically in the first section, the "unknown data of region_0 PocketFS.dll" overlapped by a large amount with "Virtual base address of PocketFS.dll"...

Thanks, I really appreciate all the help, once I get this going, I'll write a small guide and will give credit to you guys for all your help.

Steven
[Windows Mobile Software Development] FormerPalmOS:
Correct - busenum.dll data segment MUST end at 0x01FFFFFF and the code must end at 0x03FFFFFF. The space between 0x02000000 and the start of the XIP code is virtual memory space that will be used by the OS. It isn't wasted.

Just copy the module directory(ies) to an OEM folder - it may already be there in OEMDrivers or OEMApps or OEMMisc, depending on who did your split. If so, just delete it from the XIP.

I have never used this tool so I'm not sure. But in theory, provided you update the XIP ROMHDR with a bigger value for physlast and have appropriately moved the RAM for NK.exe and appropriately set ulRAMStart and ulRAMFree then the tool may re-size it for you - don't know. You definitely need to have a big enough partition to hold your XIP though - so yes it does matter.

The ROM building tools will dynamically size the IMGFS partition when the ROM is built - so you don't need to worry about that.

ROMHDR.bin and ROMHDR.txt contain the same info but in different formats. xipport.exe uses the .txt format - I don't think it will read a .bin format. Other tools use the .bin format and may not read the .txt format. You have to be careful using a tools mix - you may have to manually edit one or the other file.

Only reasons to muck with XIP are to a) eliminate unneeded stuff to recover RAM, b) change file system registry settings and c) update the MSXIPKernel portion to match a different OS SYS version. The modules in the XIP remain loaded after OS boot and are for sure used by the OS.

This could be a problem with the tool that dumped the XIP not properly describing the code and data portions of the dll. If it works (boots) then I would say this is OK.
[Windows Mobile Software Development] Ameet:
MAP.txt looks ok for booting up. No proeblem. Just 1 question and 1 suggestion

Q: After editing the imageinfo.txt files, are you sure you ran M'Reloc and realloced all the edited modules?

Suggestion: Insert command in XIPPort tool is found buggy at least in my ROMs, so can you try the bat files (are you cooking for Diamond?) posted by me or the command in the insert.exe tool and flash again?
[Windows Mobile Software Development] !Aman!:
don't use xipport.exe to insert, either use insert.exe or XIPTools.exe (xip2 section) to insert the xip_out.bin
[Windows Mobile Software Development] cruzzmz:
make sure u reloc all the modules frm the !!!! modules all the way up. Also u can insert ur xip_out.bin by using msflshtool.exe wz command

msflshtool.exe os.nb -r xip_out.bin -p 1

-r = replace wz file

-p 1 = part one of the os.nb
[Windows Mobile Software Development] hellonasty:
02000000 - 03dae000 L01dae000 NUL
03dae000 - 03db7000 L00009000 Virtual base address of wce_rex.DLL
03db7000 - 03dbe000 L00007000 Virtual base address of smem.dll
03dbe000 - 03dc2000 L00004000 Virtual base address of regenum.dll
03dc2000 - 03dc9000 L00007000 Virtual base address of relfsd.dll
03dc9000 - 03dce000 L00005000 Virtual base address of MMMAP.dll
03dce000 - 03dd5000 L00007000 Virtual base address of htcfsfilter.DLL
03dd5000 - 03dda000 L00005000 Virtual base address of GXDMA.dll
03dda000 - 03dfa000 L00020000 Virtual base address of FLASHDRV.DLL
03dfa000 - 03e4a000 L00050000 Virtual base address of DDI.dll
03e4a000 - 03e51000 L00007000 Virtual base address of ceddk.dll
[COLOR="Magenta"]03e51000[/COLOR] - 03e55000 [COLOR="Blue"]L00004000[/COLOR] Virtual base address of cecompr.dll
03e55000 - 03e57000 L00002000 NUL
[COLOR="Red"]03e57000[/COLOR] - 03e66000 L0000f000 Virtual base address of pm.dll
03e66000 - 03e6e000 L00008000 Virtual base address of mspart.dll
03e6e000 - 03e7e000 L00010000 Virtual base address of mencfilt.dll
03e7e000 - 03e8a000 L0000c000 Virtual base address of imgfs.dll
03e8a000 - 03e94000 L0000a000 Virtual base address of fsreplxfilt.dll
03e94000 - 03eaa000 L00016000 Virtual base address of fsdmgr.dll
03eaa000 - 03eb3000 L00009000 Virtual base address of fatutil.dll
03eb3000 - 03ec6000 L00013000 Virtual base address of fatfsd.dll
03ec6000 - 03ecc000 L00006000 Virtual base address of diskcache.dll
03ecc000 - 03ed8000 L0000c000 Virtual base address of devmgr.dll
03ed8000 - 03f4a000 L00072000 Virtual base address of crypt32.dll
03f4a000 - 03fe1000 L00097000 Virtual base address of coredll.dll
03fe1000 - 03fef000 L0000e000 Virtual base address of certmod.dll
03fef000 - 03ffa000 L0000b000 Virtual base address of cachefilt.dll
03ffa000 - 04000000 L00006000 Virtual base address of busenum.dll
04000000 - 80000000 L7c000000 NUL

I have this.

Next i have the value

Red - blue = magenta

Now i need change the value to cecompr.dll and recalculate to all others?

Thanks
[Windows Mobile Software Development] !Aman!:
ok... i would advice u to test a working xip_out.bin or the original xip.bin first by inserting with either xiptools.exe or insert.exe, so that we can narrow down the problematic area.
[Windows Mobile Software Development] KMFM$:
Also, make sure that you have WINCENLS_WWE in your SYS folder if it's not already a module in your base XIP folder. That has been known to cause issues with getting past the splash screen.
[Windows Mobile Software Development] Ameet:
If you have the boot.rgu from the dumped ROM already then you dont need to replace ;)

Although last night playing with the XIP I observed one thing, you have to have the WinceNls_WWE folder in the xip_out.bin else the ROM wont boot. I removed that folder from SYS & kept it in the XIP
[Windows Mobile Software Development] DupinBJK:
Good idea ! But... what to do when the log is too big for MTTY's buffer ? I've tried, but I cannot get the beginning of the log...

Is there a way to clear it ?

Thanks !
[Windows Mobile Software Development] DupinBJK:
The fact that the addresses must be divisible by 0x1000 has confused me a bit...

Take for example this:

802e4c08 - 802e85ad L000039a5 filedata sysroots.p7b

802e7fd8 - 802e85ad L000005d5 !!!!!!!!!!!!!!!!!!

802e7fd8 - 802f2fd8 L0000b000 filedata boot.hv

How should it be corrected ?

Should I get a:

802e4633 - 802e7fd8 L000039a5 filedata sysroots.p7b

and then go up ? they would not be divisible by 0x1000 at all...

And then... I really don't know where to take it from. I cannot get it from the Opal rom, but I see it in the Raphael's dump. Should I use it on a Kaiser, too ?
[Windows Mobile Software Development] hellonasty:
Hi

Finnaly i port the xip but...

Have this!!!!

Any idea? all in small windows!!! :eek:
[Windows Mobile Software Development] KMFM$:
For simplicity's sake, don't worry about the divisible by 0x1000 thing. Just take the e32_vbase of boot.hv - e32_vsize of sysroots.p7b = e32_vbase of sysroots.p7b. Then just work your way up from there.

802e7fd8 - 39a5 = 802e4633

802e4633 is the e32_vbase for sysroots.p7b. :D

The problem is that you're using a VGA device and the resources you ported are QVGA. So, everywhere in your SYS folder that you see *_96_*, should be *_192_*. Example, in your SYS folder you will see Base_Lang_96_DPI. What you will need to do is replace all of the folders that have "96_DPI" in the name with the folders from your original ROM that say "192_DPI". So, replace "Base_Lang_96_DPI" with the Base ROM's "Base_Lang_192_DPI". Then do this for all files/folder in SYS that have "96_DPI" in the name. G'reloc and then recook. :D
[Windows Mobile Software Development] Ameet:
Doesnt anyone read my first post in detail? :p

I was actually waiting for this :D. Solution is very simple

IMP

: For the ROM to function properly after boot, you need to either have

XIP & SYS of the same builds or

XIP and the OS\Gwes.exe and \Base_Lang_0XXX\Gwes.exe.0xxx.mui files from same build

Its in first post here :rolleyes:
[Windows Mobile Software Development] Ameet:
Cmonex talked of the address being divisible by 1000 are actually for the vbase and realaddr values and not the higher range 80xxxxxx These values are calculated automatically (if you see the imageinfo.txt, there are rva entries of P+xxxxx) Which means P=Physfirst + length
[Windows Mobile Software Development] DupinBJK:
@KMFM$:

Well, I might be wrong, but from my analysis I get that the addresses on the 80xxxxxx range should be on a WORD boundary - divisible by 4.

In that case, an address 802e4633 should be wrong. It should be 802e4630 instead.

@ababrekar:

I don't get what you mean, when you say that "These values are calculated automatically". Maybe it's because I'm remapping while I'm asleep, maybe because I've slept just two hours this night :D, but I get overlapping errors for them, and the rom doesn't boot...

Anyway, I'm correcting the map right now, and I'll tell you how it goes... The problem with all this remapping is that I *hate* coffee... :D
[Windows Mobile Software Development] KMFM$:
D'oh! Sorry, ababrekar. I remember that part of the tut now that you quoted it. :P

@DupinBJK - The dword value divisible by 4 may be correct. I'm not 100%. Though, it still seems that it would give nul spaces in the addresses. I would love to hear cmonex's thought on this. Not, to say your wrong, of course. Just curious as to why this might be. :)
[Windows Mobile Software Development] DupinBJK:
Necessary for Alignment purposes. It works this way, when you have to alloc memory...

As for the addresses, I'm quite sure. But from that point to be sure that everything will work in the end... I'm beginning to whistle songs of the '80s, and this usually means that I'm losing control of myself... :D

The only thing that I found so strange is that I have all this relocations to make... I didn't get that it was going to be so tough, and this usually means that I'm following a wrong road. Let's hope not ;)