FORUMS

[TUT] Manual Full XIP Porting (& MANY MORE TUTORIALS) [ONLINE]

1,984 posts
Thanks Meter: 9
 
By Ameet, Retired Moderator on 22nd October 2008, 07:27 PM
Post Reply Email Thread
23rd October 2008, 03:58 PM |#21  
Ameet's Avatar
OP Retired Moderator
Flag Mumbai
Thanks Meter: 9
 
More
Quote:
Originally Posted by boggsie

Ouch - too much like work, but it is nice to know how to do it.

Thanks for your effort!

Best regards,
-boggsie

So, how does one get hooked into the flow of new releases?

I know too much work Been on it since last 3 days. I'll test Ervius's method although sometime later. He believes since the XIPPort tool only uses the imageinfo.txt files, we can delete the .bin files all together and build the xip_out.bin directly. That way then you wont have to reloc through Mreloc
23rd October 2008, 04:00 PM |#22  
jcespi2005's Avatar
Senior Member
Flag Madrid
Thanks Meter: 190
 
Donate to Me
More
Quote:
Originally Posted by ababrekar

That is a good idea but I'll do that for posting the unedited XIP.bin files from dumped ROMs since the xip_out.bin I build would be for my device. People wont want to ruin their ROMs with someone else's ported XIP, right?

Of course, i was talking about unported XIPs Much ppl find difficults of finding good XIPs to take as base for porting, this is why i think is a good idea a repository...

Every XIP.Bin file in the list must include the origin (Device extracted from), version, and .... any other interesting info?

Thanks.
23rd October 2008, 04:22 PM |#23  
itje's Avatar
Retired Moderator
Flag Kleppe
Thanks Meter: 193
 
10
Donate to Me
More
impressive work as always my friend(s)

cheers
23rd October 2008, 06:15 PM |#24  
ark666's Avatar
Senior Member
Flag F. C. PORTO
Thanks Meter: 15
 
More
Hi, understood the coffe thing,

Excelent work, thanks for sharing your knowledge.

Cheers
23rd October 2008, 07:17 PM |#25  
abusalza's Avatar
Senior Member
Flag Samarinda
Thanks Meter: 82
 
Donate to Me
More
finally you did it, brother...
but i'm not realy have contribution on it. you as a real contributor coz understanding with my bad English
23rd October 2008, 07:58 PM |#26  
Noonski's Avatar
Inactive Recognized Developer / Moderator Emeritus
Flag Amsterdam
Thanks Meter: 147
 
Donate to Me
More
Quote:
Originally Posted by jcespi2005

Of course, i was talking about unported XIPs Much ppl find difficults of finding good XIPs to take as base for porting, this is why i think is a good idea a repository...

Every XIP.Bin file in the list must include the origin (Device extracted from), version, and .... any other interesting info?

Thanks.


Something like this:
http://forum.xda-developers.com/showthread.php?t=430197

Over at the Wizard Forum

Yeah we can always use a bit of Sharing, a Special Peace Corps wouldn't do, no one, no harm.
23rd October 2008, 08:03 PM |#27  
Ameet's Avatar
OP Retired Moderator
Flag Mumbai
Thanks Meter: 9
 
More
Quote:
Originally Posted by abusalza

finally you did it, brother...
but i'm not realy have contribution on it. you as a real contributor coz understanding with my bad English

Your english is perfect my brother
23rd October 2008, 08:05 PM |#28  
Ameet's Avatar
OP Retired Moderator
Flag Mumbai
Thanks Meter: 9
 
More
Quote:
Originally Posted by Noonski

Something like this:
http://forum.xda-developers.com/showthread.php?t=430197

Over at the Wizard Forum

Yeah we can always use a bit of Sharing, a Special Peace Corps wouldn't do, no one, no harm.

WOW!! Cool catch brothers

I love SPC
23rd October 2008, 08:27 PM |#29  
jcespi2005's Avatar
Senior Member
Flag Madrid
Thanks Meter: 190
 
Donate to Me
More
Quote:
Originally Posted by Noonski

Something like this:
http://forum.xda-developers.com/showthread.php?t=430197

Over at the Wizard Forum

Yeah we can always use a bit of Sharing, a Special Peace Corps wouldn't do, no one, no harm.

Yes, bro, this is a great starting point

I should not have sold my loved Wizard jejeje

Many thanks...
24th October 2008, 03:36 AM |#30  
Retired Recognized Developer
Flag Budapest
Thanks Meter: 49
 
More
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 :P
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

Quote:

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.

Quote:

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

Quote:

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.

Quote:

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. :P 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.
24th October 2008, 03:50 AM |#31  
!Aman!'s Avatar
Retired Moderator
Flag Brampton
Thanks Meter: 14
 
Donate to Me
More
Cmonex, why the imgfs signature in diamond is at different offset than the imgfs starting offset?
Post Reply Subscribe to Thread

Tags
change pagepool, hex, imgfs, increase imgfs, mbr, msflsh50, pagepool, porting, porting guide, remove uldr, uldr, xip, xip porting, xipporter ex

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes