OK, even mods need guidance on using the search function. Is there a comprehensive ROM porting tutorial out there which uses the latest tools? I've seen some for the Atom as well as the Trinity and Kaiser, but I'm working on porting a ROM for my Wizard, and I'm getting nowhere when it comes to the XIP section. It would take a full day to write down what all I've tried, so I'll try to give the short version and ask for help from there.
Anon. said:
Now, are you looking to port only the core OS? If so, it's fairly easy. The hardest part is the work to the XIP. Porting the XIP will require that you use RomMaster to extract the XIP.bin of the source ROM and the destination ROM, and then use XIPPORT to dump the XIP of both, then click "Write Maps" on both. Use the Make Packages button to separate the XIP into its packages, and in both the Files and Modules of the dump, replace MSXIPKERNEL of the destination with the source. Then use M'Reloc.exe to relocate the modules to the same as the original (if they differ) and also manually make the same changes to imageinfo.txt of each module. Click Undo to take the files out of packages, and Realloc P. If all goes well, there will be no errors. Look in Map.txt and see if there are no !!!!!.
Click to expand...
Click to collapse
When I do this using the CE OS 5.2.308 (Build 15342) as the donor ROM and CE OS 5.2.1413 (Build 17745) as the new ROM, I'm getting !!!!! due to a strange address issue with hd.dll in that m'reloc reports that the physical address is wrong and will not relocate the module. I dumped both xip.bin's using 0x00310000 as the address so this may be wrong but right now I'm pretty lost.
I hope this isn't gibberish. Any help is welcome.
OM
I have been looking for a tutorial on Rom porting..could you please list the Tools required and where is the whole Tutorial
jwzg said:
OK, even mods need guidance on using the search function. Is there a comprehensive ROM porting tutorial out there which uses the latest tools? I've seen some for the Atom as well as the Trinity and Kaiser, but I'm working on porting a ROM for my Wizard, and I'm getting nowhere when it comes to the XIP section. It would take a full day to write down what all I've tried, so I'll try to give the short version and ask for help from there.
When I do this using the CE OS 5.2.308 (Build 15342) as the donor ROM and CE OS 5.2.1413 (Build 17745) as the new ROM, I'm getting !!!!! due to a strange address issue with hd.dll in that m'reloc reports that the physical address is wrong and will not relocate the module. I dumped both xip.bin's using 0x00310000 as the address so this may be wrong but right now I'm pretty lost.
I hope this isn't gibberish. Any help is welcome.
Click to expand...
Click to collapse
If you can translate from polish - there are:
http://www.mobione.pl/index.php?page=porting_ROM_porting
http://forum.mobione.pl/index.php/topic,3319.0.html
I don't read Polish. Anyway, my test device was dropped today, and I may have to put my only good one on the line.
Hi from EugeniaDevelopment chef,
This project is intended for porting the Windows Embedded CE 6.0 Kernel to Windows Mobile devices, based on Qualcomm MSM chipsets.
As you know, the MSM7 series chipsets are based on ARM11 CPUs.
Or more detailed... they're based on ARM1136EJ-S CPU!
Then... WHY this post?!?
I'd like to share with all the community my hard work for compiling the CE6 kernel for ARM11 devices, supporting ARMv6 instruction set.
The CE6 kernel is based on another kernel architecture, making the devices running it SO FAST...
I would like to say that this kernel IS compatible with current Windows Mobile builds, at least 6.5/6.5.x builds, as 6.5.x builds are alphas of Windows Mobile 7, based on CE6 kernel.
Infact, WM7 will be based on CE6 instead of current WM6.1/6.5/6.5.x that are all based on CE5.2 kernel codebase.
Now, I need some help to cook it in our ROMs because the MSXIPKernel i've generated remoduling all dlls is larger than old 5.2 XIP.
There are even some differencies from 5.2 XIP!
NK.exe is differently used: the base modules of MSXIPKernel are different and device.exe and filesys.exe now are both .dll due to the different architecture of the kernel that now integrates all in an unique process, both files in kernel mode and not in userspace anymore!
So, I've tried myself to port it to my ROMs before posting it there but with no luck.
I'm using the last ErviusVisualKitchen that includes bepe's platformrebuilder.exe... that CRASHES everytime I try to build the ROM with ALL dlls and modules of CE6 kernel.
If I integrate only coredll.dll module the kitchen goes on and builds the XIP and the ROM, but it won't boot because the new coredll looks for device and filesys dlls that in 5.2 are executables.
If I try to integrate new dll modules (device and filesys), the platformrebuilder will crash.
So, I'm asking for your help to making this fabulous project to continue and to make it working for having the FASTEST devices ever!
Here are the dlls, not remoduled with ErviusKitchen.
I decided to give you the original binaries because maybe ErviusKitchen won't remodule them correctly, making platformrebuilder to crash.
Ouh, and.. this kernel will work on all devices that has got Qualcomm MSM7xxx series chipsets..
For example: HTC Touch Diamond, TouchHD, TouchPro, Kaiser, Diamond2, TouchPro2... and more, more devices....
I hope I can get all of your help.
Anyway, you can download it here:
CE 6.0R2 Kernel
...If you want, I can post the entire ROM built with Platform Builder (not working on our HTC devices, as it's build for generic ARM1136EJ-S CPU).
NOTE: As for the device-specific drivers, we have OEMXIPKernel
Thank you all
How to use ?
Try sending a private msg to bepe, see if he can adjust his PRB to account for your kernel.
Okay, thank you
...if anyone has other ideas, write
this is probably the most impotant project on this forum.
Mods please make a sticky.
Converting to module didn't help.
Imageinfo.bin manipulation didn't work also.
Did you try porting it the old way? (XIPPORT)
If THAT doesn't work, try PMing bepe.
Tried to integrate this kernel into my ROM...
I copyed all the .dll's into MSXIPKERNEL
ROM - created without any ERRORS
Now i gonna try it...
Whoops... My mistake - i builded 21054 kernel without errors... 23049 - Platformbuilder error...
OMG stick this NOW, this is ground breaking stuff, da_g,nue2chem,bepe you should all take a look at this thread OMG!!!!
I think you may be a little confused?
It appears you have posted the MSXIPKernel package compiled from Embedded CE 6.0, compiled for ARM.
These CE 6.0 Binaries are not compatbile with CE 5.2, so attempting to use them in a Windows Mobile 6.x ROM as-is will not work. You state that "NOTE: As for the device-specific drivers, we have OEMXIPKernel" - do you mean the existing OEMXIPKernel, compiled against WM 6/CE5.2, if so this will not work at all with CE 6. I assume when you say "Ouh, and.. this kernel will work on all devices that has got Qualcomm MSM7xxx series chipsets.." you mean because it is compiled against ARMv6?
Also, you have posted several incorrect informations,
WM 7 is not based on CE6, but CE7.
WM 6.5.x is not in any way an alpha build of WM7. They are seperate code bases.
In short, to sum it up I don't think this project will be going very far unless you have access to whitepapers documenting the full hardware and are willing to code the OEM bits yourself using this info. I don't think it's worth doing though as you would be using the CE interface, and it would all need to be done over again when WM7 comes around...
Well, PRB doesn't crash for me in my visual kitchen when you add all other files from any other MSXIPKernel (dsm, rgu's etc).
Da_G said:
I think you may be a little confused?
It appears you have posted the MSXIPKernel package compiled from Embedded CE 6.0, compiled for ARM.
These CE 6.0 Binaries are not compatbile with CE 5.2, so attempting to use them in a Windows Mobile 6.x ROM as-is will not work. You state that "NOTE: As for the device-specific drivers, we have OEMXIPKernel" - do you mean the existing OEMXIPKernel, compiled against WM 6/CE5.2, if so this will not work at all with CE 6. I assume when you say "Ouh, and.. this kernel will work on all devices that has got Qualcomm MSM7xxx series chipsets.." you mean because it is compiled against ARMv6?
Also, you have posted several incorrect informations,
WM 7 is not based on CE6, but CE7.
WM 6.5.x is not in any way an alpha build of WM7. They are seperate code bases.
In short, to sum it up I don't think this project will be going very far unless you have access to whitepapers documenting the full hardware and are willing to code the OEM bits yourself using this info. I don't think it's worth doing though as you would be using the CE interface, and it would all need to be done over again when WM7 comes around...
Click to expand...
Click to collapse
I think they are all compatible with CE6.
CE6 has a different kernel architecture, but for drivers it all remains the same.
You're right, I'm not too updated, WM7 (Photon) is NOW based on CE7 Kernel, but if you search further, it initially was based on CE6 kernel Pre-Alphas of WM7 was CE6 based!
...and WM7 won't be usable with our devices, because it NEEDS a multitouch touchscreen, as you can see from minimum requirements by Microsoft.
Yes, for "it will work on all MSM7xxx" I mean that this is compiled against ARMv6.
All MSM7xxx chipsets has got a CPU that supports ARMv6 instructions set.
For example, MSM7201A (Diamond and other devices) has in its core an ARM1136EJ-S (yeah, the "J" was changed by Qualcomm, but it's an 1136EJ-S)!
And... the 5.2 kernel that we have now on our devices is compiled from Embedded CE 5.0 (updated) so it's compatible.
I didn't try porting with XIPPORT as the addresses with the CE6.0 Kernel are changed: it's larger than 5.2!
Well, it wouldnt hurt to TRY, right? I mean, the devices are pretty damn slow compared to android devices running on the same hardware, so if this COULD improve it, why not try it?
I'm sorry,
NK is very device specific, you cannot just take CE 6 NK and hope it'll magically work. We've been able to build CE6 ARM11 and Cortex for a long time, just press a few buttons in PB. But NK consists of OAL (OEM Adapation Layer) stuff, which is pretty device specific. More specifically, when NK gets to OEMInit, it'll simply fail, because this is where most of the initialization occurs, such as GPIO, MDDI client, NAND flash -etc. Even if you did get CE6 NK working, which would require you recompile CE6 with the OAL, which only HTC has, you would have to rewrite all the drivers since CE6 driver model changed a lot, (i.e., no more SetKMode(BOOL); - which HTC uses a lot).
Anyway, this project has been on the table for a while, and through a new (maybe old, well new for me) technique of disassemble-reassemble, we can maybe build an "Assembly" BSP that would let us run CE6. But its a lot of work, since again, ce6 driver model changed
Again, this topic has been repeated several times, so I will say what others have said in the past. If you have no clue about ARM assembly, please save your time, give up, and move on with other projects. A simple search will tell you about many people who got over-excited when they played with CE6 PB.
Da_ag. Why not give it a shot. This could open up the door to future developments beyond our wildest dreams for Windows Mobile. We, XDA as a community if we pull this off, might be able to create our own fully customized versions of Windows Mobile from the Kernel up. Also it would improve speed and usability of our current devices.
Please do not discount this project just because it looks hard. Isn't this the reason XDA was formed in the first place?
no2chem said:
I'm sorry,
NK is very device specific, you cannot just take CE 6 NK and hope it'll magically work.
Click to expand...
Click to collapse
CE6 doesn't even have NK(.exe) anymore say hello to kernel.dll and oal.exe! =)
kholk said:
I think they are all compatible with CE6.
CE6 has a different kernel architecture, but for drivers it all remains the same.
You're right, I'm not too updated, WM7 (Photon) is NOW based on CE7 Kernel, but if you search further, it initially was based on CE6 kernel Pre-Alphas of WM7 was CE6 based!
...and WM7 won't be usable with our devices, because it NEEDS a multitouch touchscreen, as you can see from minimum requirements by Microsoft.
Yes, for "it will work on all MSM7xxx" I mean that this is compiled against ARMv6.
All MSM7xxx chipsets has got a CPU that supports ARMv6 instructions set.
For example, MSM7201A (Diamond and other devices) has in its core an ARM1136EJ-S (yeah, the "J" was changed by Qualcomm, but it's an 1136EJ-S)!
And... the 5.2 kernel that we have now on our devices is compiled from Embedded CE 5.0 (updated) so it's compatible.
I didn't try porting with XIPPORT as the addresses with the CE6.0 Kernel are changed: it's larger than 5.2!
Click to expand...
Click to collapse
alright believe what you like but the facts will not change. no2chem told about it all already so I won't repeat him
Da_G said:
In short, to sum it up I don't think this project will be going very far unless you have access to whitepapers documenting the full hardware and are willing to code the OEM bits yourself using this info. I don't think it's worth doing though as you would be using the CE interface, and it would all need to be done over again when WM7 comes around...
Click to expand...
Click to collapse
you don't need access to so many papers. but they do ease the workload for you
again see what no2chem said... we're going to have lots of fun with this i guess.
I don't understand a thing, with this, you should be able to get CE 6 kernel without the BSP ?
cmonex said:
CE6 doesn't even have NK(.exe) anymore say hello to kernel.dll and oal.exe! =)
Click to expand...
Click to collapse
Right cmonex. I wanted to say that but you written before me
But.. now I've got a question.
IF CE6 doesn't have NK.exe anymore (and from what I see it doesn't have any NK.dll) and it's all based on OEM Adaptation Layer (OAL), THEN we won't use nk.exe anymore, right?
So.. CE5 uses PQOAL, monolithic kernel.
CE6 uses OAL, and it's all modular.
From THIS site, that explains the CE6 Kernel Architecture, I read the following:
"The OAL is linked with the generic kernel code to form the full kernel module."
Click to expand...
Click to collapse
"By splitting up the OAL from the generic parts two interesting things happen. First, the foundation for a well defined interface between the OAL and the kernel module is laid. It is no longer possible to just "extern" some kernel specific function in the OAL, as in the old monolithic architecture where the OEM sometimes use undocumented kernel functions to "backdoor" its way around some OAL "quirks" -something that may affect stability and compatibility of the kernel. In CE 6, the kernel functions are exported to the "oal.exe" as a function table (NKGLOBAL) as part of an initial handshake procedure. In the same way, OAL functions that are needed to support the core kernel are exported to "kern.dll" in a similar function table (OEMGLOBAL). "
Click to expand...
Click to collapse
And from MSDN I read the following:
So what did change? In CE6 we split up three components that previously linked together to make the kernel executable, nk.exe. CE5 the kernel, OAL and the Kernel Independent Transport Layer (KITL) all linked into nk.exe. In CE6 these are broken into kernel.dll, oal.exe and kitl.dll.
The primary reason for this change was updateability. In the past, if Microsoft released a kernel update, the OEM would have to take the updated kernel and link it again with their OAL to produce a new nk.exe. Now the OEM only has to distribute Microsoft’s new kernel.dll.
Click to expand...
Click to collapse
We CAN DO IT if we know how to split NK.exe into OAL and Kernel.
OR.. if we don't want to do never-used work, we need only to extract the OEM Adaptation Layer (OAL) from our current NK.exe.
Then we can link the OAL extracted from 5.2 Kernel to the NEW CE6 kernel.dll
Note that CE5 kernel does support the splitted modules, infact there are some BSPs that are built with OAL.exe/kernel.dll and NOT with NK.exe.
Read that on instructions for how to port a BSP from CE5 to CE6.
If someone can "extract" OAL from a Diamond NK.exe, I'll be happy to try if all works on MY device!
no, you can't just extract OAL from CE5 kernel, its linked at compile time into the fun monolithic kernel we know as NK. The architects of CE6 (in a smart move) seperated the OAL from kernel libs, much like the MDD-PDD model you see in many drivers since CE5.
So in ce6 you can just update the kernel by updating kernel.dll ideally. anyway like cmonex and i have said, just wait, we're working on reversing a bsp for rhod_w soon