some notes if it helps any
you can always remove osaxst0.dll, osaxst1.dll, hd.dll, kd.dll, and also bmui.nb0 - the latter is just a splashscreen saying your OS can't boot and reflash or something (I forget the exact text). I never saw it invoked
the other files are kernel debuggers and similar, best to remove them, because it just takes up space and can also cause problems if you somehow manage to use the wrong versions of them - they are mapped directly to the kernel memory space, and if your device uses a different range (i.e. you didn't keep your original debugger dlls), it will prevent the rom from booting.
also I found it's ok to remove (m)encfilt.dll and cachefilt (put them in IMGFS if you want them).
physlast can be changed up to ulramstart value without problems (of course not if you don't have enough space in the flash, but that's not really a real life possibility). of course that also assumes we are not talking about some older devices that have the xip mapped to a different memory range than ulramstart.
you can move ulramstart/ulramfree too if you relocate nk.exe data section (usually S002) with mreloc-nk. also relocation is needed for any other modules (such as giisr.dll, on some non HTC devices) that have mappings similar to nk.exe (so they have a data section in the map that points into ulramstart/ulramfree range). on HTC devices I didn't really see such modules so not a real problem usually
One way of correcting these values is as posted by Ervius somewhere that since XIPPort.exe will read only the imageinfo.txt files for rebuilding the xip_out.bin, go ahead and delete all the imageinfo.bin files and work only on the txt
I'm not sure what this was meant to say, but you definitely need more than this to fix the overlaps. the binaries (S000, S001...) must actually be relocated using m'reloc, it is not enough to just adjust the values in the txt files.
Although I have not found a way to calculate the difference between both regions
if you post the imageinfo txt for this dll then we can see, but most probably determined by the o32_xx_rva values.
i'm reminded of xipaddrtools at this point - nice idea but sometimes buggy
Busenum.dll must be the last entry in both tables
actually the values are arbitary, even though microsoft decided to place coredll.dll as the last entry, i.e. at the highest memory address, it doesn't really matter. so, the values are arbitrary, but of course only within limits: the addresses must be divisible by 0x1000 (pagesize of the platform), and they must be inside the memory range reserved for XIP. part of that is the dllfirst and dlllast values in romhdr.txt. the other part (the higher addresses, 0x03xxxxxx) are determined by the following way: IMGFS .VM tells you the limits for IMGFS memory range, and XIP is beyond that range. so, if your OS doesn't want to boot, you can check if IMGFS .VM is overlapping with XIP memory range as per your maps.txt for xip and dump_memorymap.txt (or .VM folder, etc) for imgfs.
for example if imgfs ends at 0x03DE0000, then the higher part of your XIP must start later than 0x03DE0000. you can of course modify this to make more space for XIP
btw if xipport crashes on writing maps it means you definitely have some overlaps left in.. so yes, best to work with the maps from the original xips and only use the final xip map to verify you got everything right.
BTW, xipport's insertion function was found buggy on one device once, but cannot remember the details... it wasn't my device, so just posting this as a possible warning..
oh, same applies to rommaster, it's buggy when you try to use that to extract the xip some roms.
Few mention of using the 723*.dsm for the build number, few others mention of using the coredll.dll module to have the latest build numbers
lol.
btw coredll replacement only works for that pre-WM6.1
and a last tip for debugging if your OS doesn't want to boot: if you already checked that the maps are all ok and imgfs doesn't overlap, etc., etc... then if you have a new enough HTC device (for example HTC Athena and later is new enough), then go to SPL using mtty or putty or qmat and there the "task 37" command (without the quotes) will show KITL log, with lots of debug messages, that can be very helpful. (first you must issue "task 32", for "task 37" to work) - this doesn't appear to work on some raphaels.
