Related
Ok, so I've done my research and am perplexed by two significant things. I applied the update 1.12.188.11210 since I'm on Rogers in Canada and need the 850 band support. No problems applying that and things looked good so far.
I've tried following two methods to do this and am running into 2 problems.
According to Ampda's walkthrough, I should see a ROM dump that looks similar to the BigStorage ROM that you open up with the hex editor. My first indication something might be wrong was that my dump did not have MAGICIAN in the first line of the ASCII translation of the HEX. Still I tried to follow the instructions and copied and pasted the 416 bytes into the new file and it did not apply.
Afterwards, I tried drchair's method of manually editing the hex values and reapplying that. Interestingly enough I only found 1 sequence of hex values that matched, and tried applying that and that also failed. I'm not certain why I only found one matching set of hex values and not the 2.
So I'm a little stumped and at a bit of a crossroads since it seems that my Jam's ROM dump for some reason or other doesn't look like what it should according to what other people have posted.
Has anyone else run into this problem, or possibly does anyone have some suggestions I can try?
Don't flash your magician with your dump, probably it will NOT work. Your story seems like my first attempt & that was no success.
I guess 1.12.188.11210 is a shipped-rom in .exe format, so try this:
get nbfdec.rar
http://forum.xda-developers.com/download.php?id=7603
get maupgradeut_noid
http://forum.xda-developers.com/download.php?id=7508
If the link is broken go to this thread & get both files: http://forum.xda-developers.com/viewtopic.php?t=32274
1. Unzip the shipped-rom to get all the .nbf & enterbl.exe etc.
2. Put NBFDEC in the same directory as the unzipped shipped rom files
3. Copy the getdevicedata.exe to your Magician and execute to write DeviceData.txt to \Windows and view with notepad
5. Decode nk.nbf -> nk.nb1:
nbfdec -d nk.nbf nk.nb1
6. Hexedit header in nk.nb1 to correct ID from DeviceData.txt
(probably only if using a rom from other provider, you can skip this step as you already installed the same rom as you're patching now)
7. Replace pattern for bigstorage in hexeditor (still in fike nk.nb1):
locate the 02 00 00 80 00 20 and change 80 00 to b8 01 in the nk.nb1
(use binary search for this!!)
7. Encode nk.nb1->nk.nbf
nbfdec -e nk.nb1 nk.nbf
8. connect your magician with usb
9. run maupgradeut_noid.exe to upgrade CE image
Also, this way you will save the contents of increased \Storage folder if previous rom was bigstorage one
Usage sample (must be run from the same folder as nbf files or specify full path):
nbfdec -d nk.nbf nk.nb1
nbfdec -e nk.nb1 nk.nbf
This method is the most simple I belief & works great.
Refards, M
Thanks, I will give your instructions a shot and let everyone know how it went!
Should be going fine, many took this road & succeeded. Including myself.
M
Actually, I feel a little sheepish...
After you had posted your instructions, I started to see you had posted this in a few other threads and realized I should have been reading a little more carefully and tried this as another method.
Sorry to everyone for being a bit of a newb and thank you for being patient oltp and reposting this information for me in a place where I could not miss it.
No harm done, after loosing my patience about posting this info over & over again & helping some Dutch guys in native Dutch I just have this info in a file. So I can copy/paste the required text & everybody's happy.
I know the board is growing fast & it's sometimes ally hard to find the required info, mostly finding the correct keywords helps but then again you're probably overwhelmed by hits.
& most of all I guess that's everybody has the right of his/her own noob time. Mine is still going on as I'm still finding handy small apps (like from VJ always patient too) & loads of other info on the board.
Cheers, M
I don't know if I'm the exception and most people just don't look, but I did find the wiki helpful. If I might make a suggestion for the board, I think perhaps adding your method to the wiki would be a very useful and alternative method to ampda's instructions that are already in there. Ideally, I would direct people to your method first as it seems more reliable since you're dealing with the original install files.
Also, if it's in the wiki, it might get more newbies to give it a shot without askiing.
Problem with the wiki is that I never tried changing it on a magician. I don't use the PC very often @ home, but I can always try. Thanks for the reminder.
& have you achieved BS?
Updating the wiki was dead-simple. Please do me favor & judge whether it's easy to find & correct.
Regards, M
Ps if you can't find it, it's in the howto section
Looks good to me. And yes, your method worked great and I now have BigStorage enabled on my Jam. Thanks for the help!
*Edit* Just noticed one thing that some might get confused about. When you copy over the GetDeviceData.exe file over, it will not provide any gui displays. Not to mention the fact that most newer users won't be expecting an exe to run anyways on a ppc. If you mentioned that, it might avoid some potential questions about it if a user is too lazy to look in the windows dir or look up in the forum about the file.
Thnx, I totally forgot about that fact of running GetDeviceData.exe. Probably I'm too curious I even executed enterbl.exe on my ppc. Works great it goes straight into bootloader.
I'll give the wiki another edit.
M
I have ROM files in NBF format. I want to convert it to BIN format in order to edit it. I tried using some tools (prepare_imgfs.bat and NBFtools) method with no success. Can anyone tell me how to do it?
However I'm using Vista. Maybe Vista won't allow to convert it?
i have the same problem, but not with vista, with xp. :-(
helppppppppppppppp
Here, extract nbf with typhoonnbftools.exe (dump as decrypted)
and pack with nb2nbf - read wiki for htc wizard
I've been able to convert the NBF to BIN using prepare_imgfs command after reinstalling Vista. Now no matter how hard I try the viewimgfs command can't dump the BIN file. Maybe the possibility of cooking a ROM in Vista is minimum.
how can i edit BIN files?any softwares?
editing .nbf can be done(contact chinese, they made iphone and vista rom), ive tried the metods mentioned before,but did not work for me. the problem is if u make an unstable rom who can stop in upgrading utility you can get not a custom mobile rom, but a custom brick.
WOW, I thought we've got all those cool tools from you guys.
It's simple, just with a bunch of tools you can do a lot with your nbf. The pack is too big I don't think I can have it upload, but I have file names you can google.
rem If your nbf is only an OS rom, just rename it to have your nbf converted to nb Because nbf is made up of bin(sometimes known as .nb), and a OS only nbf is simply a bin file.
rem to have your os.nb splitted.
tttt\prepare_imgfs.exe os.nb -nosplit
rem extract files to dump\
tttt\viewimgfs imgfs_raw_data.bin
rem extract regisrty to edible rgu files
set _FLATRELEASEDIR=.
tttt\rgucomp.exe -o dump\default.hv -nologo > default.rgu
tttt\rgucomp.exe -o dump\user.hv -nologo > user.rgu
pause
rem below is a batch file I've to have my registy packed to hv files.
rem rgucomp.exe only convert a boot.rgu to default.hv, so you have to rename your rgu first. don't forget -b parameters
set _FLATRELEASEDIR=.
del boot.hv
ren .\default.rgu boot.rgu
tools\rgucomp.exe -b
copy boot.hv default.hv /y
ren .\boot.rgu default.rgu
ren .\user.rgu boot.rgu
tools\rgucomp.exe -b
copy boot.hv user.hv /y
ren .\boot.rgu user.rgu
del boot.hv
Pause
rem pack your dump\ to nb. If your ROM over sized the program buildimgfs.exe will crash.
tttt\buildimgfs.exe
tttt\make_imgfs.exe os.nb -nosplit
OK that's it. I only do these with my Typhoon so I don't have to convert my os.nb to nbf for RUU. But i guess you can get enough help with google. All those .exe tools mentioned above can be found through google, too. I've tried. Just search and download.
My English is not so good, please read with imagination, sorry for any inconvenience.
Ok heres the simple way.
nk.nbf -> OS.nb using typhoonnbftool (right click the OS section and dump decrypted, however under the file type, you must select 'All files' and call the file your about to dump OS.nb)
imgfsfromnb OS.nb imgfs.bin
imgfstodump imgfs.bin
Your OS has now been dumped to the 'dump floder'. Edit as you like, then recontruct using the following:
imgfsfromdump imgfs.bin imgfs.new.bin
imgfstonb imgfs.new.bin OS.nb OS.new.nb
then use nb2nbf to compile OS.new.nb back into an nbf
Easy enough
Phil
Thanks Phil ! I was pulling my hair all weekend trying to figure out how to convert nbf->nb and come monday, you answer the question. Great ! Thanks much !
PS: How much more do we have to wait for Crossbow alpha ?
It's all uploaded and ready to go on my private FTP (no waiting times or download limits ) so as soon as vlodeck unlocks the thread, i'll be posting it
Phil
jm012a9749 said:
It's all uploaded and ready to go on my private FTP (no waiting times or download limits ) so as soon as vlodeck unlocks the thread, i'll be posting it
Phil
Click to expand...
Click to collapse
think you could post it here since the thread is not unlocked yet?
vlodecks last activity was 10 minutes ago
I've PM'd him asking him to unlock the thread, PATIENCE people!
Phil
he's gone offline now
Ok, I'm back now but i dont see any link in the first post?
EDIT: I just wanted Phil to edit the first post in order to provide the link, I get it know. Thread reopened.
Go ! Go ! Go !!
Unfortunately i couldnt edit my post until you unlocked the thread vlodeck
Phil
Ohh, I see. The forum must've changed something
Ok, today is my official "I am dumb" day. I just got home and tried to load up the Imate SP5m AKU2 ROM nbf in typhoonnbftool and tried to decode it to a nb file. I do not see any area where I can 'right click on the OS and select dump selected'. I do recall that I saw it sometime on saturday night....just that I dont remember now. Can you please guide me a bit with this ? Thanks much !
Use typhoonnbftool 0.41 (attached), looks like the version you are using is 0.3, which can't read tornado nbf's properly
Phil
Hello,
Im working on my first rom. I wanted to start with a clean slate so I got the latest vanilla wm6 rom i could find "HTC_Wizard_WM6_15342.rar" and downloaded core pro from the thread in here. After changing the hex equiv of D.e.v.A.u.th to A.u.t.h.D.e.v in "80040000-OS.nb" I was able to boot the extracted and rebuilt clean rom with no device id authentication failure errors
My problem is that any packages I add to OEM/SYS in the kitchen don't seem to do anything, that is, they don't show up in the final product even though i see them rollin by in BuildOS, also only the second splash screen is installing . When I get everything moved to "C:\Core\Kitchen", i add some of the premade packages from
"C:\Core\PACKS\OEM" and "C:\Core\PACKS\OEMAddonsForKitchenV2" to the rom folder at "C:\Core\Kitchen\OEM". At this point I run "1. Splash1.bat" and "2. Splash2.bat" to produce my splash screens. I then run "C:\Core\Panel\Build\BuildOS" and "nb2nbf_wizard". in nb2nbf, I add details and then add files in this order
File 1: 9d000000-HTC.nb 92000000 "Splash Screen" 65536
File 2: 92000000-Splash.nb 92000000 "Splash Screen" 196608
File 3: 80040000-OS.nb 80040000 "OS" 59768832
From there its "3. Move nk.nbf to RUU" and "RUU Folder" etc..
Rom installs clean, but my HTC splash screen is always the one from a previous rom install whether i do Faria or xdar2 or any others. the second splash screen goes in fine. When it boots though, none of the applications are in programs or in windows dir or anywhere else. From the looks of it the packages are done correctly they just dont seem to be making it to the final rom? Is there a step im missing? Ive tried going the options.xml route but it seems to be doing the same thing. I cant even add a package to Farias rom and have it show up, so i feel like im maybe missing a vital step here.
Im a newber at this so id appreciate any experience or insight, (Ive been burning way too much time on this as it is)
Thanks
*EDIT*
Fixed first splash screen
File 1: 9d000000-HTC.nb 92000000 "Splash Screen" 65536
-->
File 1: 9d000000-HTC.nb 9d000000 "Splash Screen" 65536
Not sure why your packages aren't installing, but I can tell you why your first splash screen isn't. When your running the nbtonbf tool and you choose the htclogo, don't choose splashscreen from the drop down menu. Type HTC Logo in to that one in the empty space and in the address space just to the left of it type in 9D000000. After that your first splash screen will get added to the ROM.
THANKS, Ok I got the first splash screen going, and I think i may have figured out what my problem is with the packages.. but im a little stumped on how to solve it,
I was choosing my OS("80040000-OS.nb") from nb2nbf out of the folder "C:\Core\Kitchen\ROM" rather than
"C:\Core\Kitchen\ROM\temp".. but now when i install i get first and second splash screen but i get a big ol Device auth failure!... When I open 80040000-OS.nb in the hex editor I cant find the string from before as Authdev or devauth?!. Has anyone seen this? im a little lost
hmm, is this normal?...I tried running it without the initial hex edit (i waited till right after i ran build OS). Using winhex, I open up "C:\Core\Kitchen\temp\80040000-OS.nb". I search for "devauth" nothing... "dev" returns 1 result from the word "Device" but there is nothing else, hex editor isn't showing anything. Is BuildOS or any other tool trying to remove security or do anything besides compress that would mke the hex view of ...-OS.nb so different in temp folder?
original .nb size = 57.0 MB
BuildOS generated .nb size = 48.5 MB
any thoughts.. questions.. pointers?
Hi guys....
I've been a member of this comunity for 2 years now, but posted very litle, because I would be mostly spamming, re-interating what others have said, with" wow, this is fast...nice job"...and such..so i only post when I realy have to.
I downloaded the hypercore kitchen, and after some reading of the contained links and txt files, decided to have a go at it...
I would like to target Tomal's v8 but although very fast, it seems to have a significant number of com bugs...So maybe I'll go with v7.7...
I copied the nk.nbf file to the correct directory, and ran the decoder, but it errors on the next step saying that there is no OS.nb file...
Should this file be extrated from the nk.nbf?
Is this a problem with the nk.nbf file I'm using?
I would apreciate some help on this, as I'm looking for a full flavored cake, but to my taste...see I'm "diabetic" so I have to be extremly caution with what I cook...
When you decoding nk.nbf, decode it to OS.nb (change second line) instead nk.nba.
Something else to be aware of with Tomal's ROMs is that he ships all his RGUs in a single RGU.cab file.
You'll need to extract the contents of this file into the dump directory AFTER the imgfstodump and BEFORE the pkgtool step.
-PJC
Thanks for the quick answers, guys...
Something pop-up as a doubt...can I cook from an usb stick?(installing the kitchen, and workind directly trought the usb stick)???
I'm getting starved.....I can't even turn on the oven...
I have nstaledthekitchen over and ove again.
Changed the settings so it reads "Universal", copied the nk.nbf of my choice to the Extract/source folder, and whent to the Panel/extract and runned "DumpRom"...So far so good....
The DOS windows warns me that the file must be in the correct folder, so I double check....I press return...HTC Extender Rom Tool starts and prmpts me what I want to do and were is the extended rom...I thought it was embeeded in the nk file, but since Tomal provided with and empty extenden Rom, I downloade it and poited to it...Hit decode...
A big window opens with some file paths, so I check them to know were the files are going to...and using the above tip, change the name of the fat file to OS.nb, Hit decode...I'm happy, the window says "Decode sucessfull", so I hit "OK"...
I am agin at the Htc Extended Rom tool, so I hit exit(? done it right ?)...
The Dos window now tells me that it cannot find the ON.nb(? Didnt I just created it?)....
So I'm stuck....
The constructions workers haven't yet finished furnishing my kitchen, so I have no ingredients to work with....
Any chef willing to help me make a simple meal?????
psapg said:
I'm getting starved.....I can't even turn on the oven...
I have nstaledthekitchen over and ove again.
Changed the settings so it reads "Universal", copied the nk.nbf of my choice to the Extract/source folder, and whent to the Panel/extract and runned "DumpRom"...So far so good....
The DOS windows warns me that the file must be in the correct folder, so I double check....I press return...HTC Extender Rom Tool starts and prmpts me what I want to do and were is the extended rom...I thought it was embeeded in the nk file, but since Tomal provided with and empty extenden Rom, I downloade it and poited to it...Hit decode...
A big window opens with some file paths, so I check them to know were the files are going to...and using the above tip, change the name of the fat file to OS.nb, Hit decode...I'm happy, the window says "Decode sucessfull", so I hit "OK"...
I am agin at the Htc Extended Rom tool, so I hit exit(? done it right ?)...
The Dos window now tells me that it cannot find the ON.nb(? Didnt I just created it?)....
So I'm stuck....
The constructions workers haven't yet finished furnishing my kitchen, so I have no ingredients to work with....
Any chef willing to help me make a simple meal?????
Click to expand...
Click to collapse
With HTC Extender Rom Tool you must extract nk.nbf not ext_rom, and when extracting name it OS.nb (i thing it is 2nd line in tool)
Perhaps the would-be chef should read a cookery book?
There's a very, very good guide in this forum, which is what I started off with and had no problems whatsoever, but I can't for the life of me remember if it was beasty or thingonaspring who wrote it (apologies to the real author if I missed them out!). It also includes some fixes for the batch files.
Remember - the wiki and search are your best friends...
PJC
Hi Again...
The construction workers finaly had done some real work, so now my kitchen is properly furnished with all the CABinets i need...so now to try to cook me a simple meal, and try to learn from it....
Can't rebuild Ranju 7.7
Hi all.
I gave it a go and tried to rebuild Ranju 7.7.
I could decode it, dump it (yes, I extracted the contents of RGU.CAB to the dump directory), convert the dump to packages etc. So far, so good.
But when I tried to rebuild it, the ImgfsToNb tool gave this error message:
"Partition with file system 0x01 found after IMGFS partition. It's safer to abort here, sorry."
What should I do now?
jandevries12 said:
Hi all.
I gave it a go and tried to rebuild Ranju 7.7.
I could decode it, dump it (yes, I extracted the contents of RGU.CAB to the dump directory), convert the dump to packages etc. So far, so good.
But when I tried to rebuild it, the ImgfsToNb tool gave this error message:
"Partition with file system 0x01 found after IMGFS partition. It's safer to abort here, sorry."
What should I do now?
Click to expand...
Click to collapse
imgfstonb doesn't seem to support the FLASH disk that's in Tomal's ROMs. I don't know what he uses, but when I've based things on his work, I use a different 'donor' OS.nb for the imgfstonb stage. Obviously, I lose the FLASH disk, but as I don't use it anyway, that's not an issue for me.
^^ yup, exactly, it is due flash disk.
Ok, I understand.
But what is the "donor" os.nb used for?
I've extracted the OEM, SYS en XIP parts. Isn't that enough to compose a new ROM?
What parts are re-used from the original os.nb? And must an alternative donor os.nb be of the same version/build?
jandevries12 said:
Ok, I understand.
But what is the "donor" os.nb used for?
I've extracted the OEM, SYS en XIP parts. Isn't that enough to compose a new ROM?
What parts are re-used from the original os.nb? And must an alternative donor os.nb be of the same version/build?
Click to expand...
Click to collapse
As I understand it (and I'm sure someone can correct me if I'm wrong), the donor OS.nb is used as a 'template' for storing the IMGFS into an NB structure. As far as I've been able to tell, pretty much *any* OS.nb from *any* ROM can be used as the template.
Basically, imgfstonb takes 3 arguments - the imgfs file itself, a 'donor' OS.nb, and the 'target' OS.nb final output. This is all hidden by the scripting, but is what I've found by playing with the underlying utilities.
The only restriction I've found is that ROMs that contain Flash disk can't be used as the donor OS.nb.
PJC
Could one of the senior members of this forum please comment on pjc007's statements above?
Is it correct that the donor os.nb is only used to determine the right structure for the ROM?
(I'm asking because I got the impression from other posts on this excellent site that the donor os.nb is used as source for the XIP part, but I don't know for sure)
Well, I have the same matter now, I really want to cook sth to use the way I want a rom to be and share with others as I feel really bad just to download, I hope to upload my own rom and share but I read the instructions again and again , look for sth on the internet, download all the things to my PC that will be used to cook, still not certain what I'm going to do.
My question is if I cook a bad rom, then I up it to my EXEC, Is there any chances for it to die ? Or simply just install another well-known rom to rescue it if my rom jail to boot?
Hey guys,
Well, as some of you might have known, I struggled for a very, very long time
in correctly porting the XIP (the CE OS number), and the SYS (the Build
number) for quite some time. Thankfully, I figured it out using some other
tutorials that were not for the Kaiser. After a few people have asked me how
to do it, I decided to share this knowledge with this community. Please take
note that this tutorial works on KaiserKitchen and KaiserChef, and is written
specifically for Kaiser chefs who want to learn how to do this. So, without further ado,
How to Port the SYS (Build number) of a ROM:
So, what exactly is all this SYS stuff? Well, the SYS folder in your Kitchen stores all
kinds of Applications that are standard in Windows Mobile. For example, the
Transcriber and Microsoft Office, along with Windows Media Player and Internet Explorer.
It also includes many .dll files that are necessary for the ROM to survive.
So what does it mean to port it? Porting the SYS can result in many different things:
First, if ported correctly, it changes the Build number (found in Start > System > About) of the
ROM. Also, it updates many different applications in the ROM. A bigger number suggests a newer build.
For example: if you ported the 20755 build, then the version of Pocket Internet Explorer will be
a newer version than in the 19212 build. Also, ported builds are often much, much speedier than
stock builds, for some reason that is unknown to me.
So, here is how you port a build:
First, you need the ROM you want to port the build from. For example: for the
sake of this tutorial we are going to be porting the 19965 ROM, taken from the Diamond.
So, the first thing we're going to need to do is to download that ROM, which you can do
here: http://rapidshare.com/files/131846783/RUU_Diamond_hTC_Asia_HK_WWE_1.93.831.1.exe
Second, you need to dump the ROM. Now, I know that many new chefs
(including myself) tend to panic when they hear these words, but there really is
nothing to worry about. For this tutorial, we are only interested in the SYS. I
have found that the most consistent way to do this is to use HTC ROM Image
Editor, because sometimes IMGFS tools fail when trying to port from a device
like the Opal/Jade, for example. So, download this, then run the Application, then open th
.nbh we just downloaded from the Diamond. Now select all the files, and choose
to save them in a folder named "dump" (no quote) in My Documents.
Once you have all your files in a directory, we need to organize them. The easiest
way to do this by far is to download the PackageTool, which you can do so by going
here: http://myunspace.com/?d=B4BE8DA81. Download it, and extract it to
My Documents. Now, drag your "dump" folder on top of the packagebuilder.exe file.
Wait a few seconds, then look at your dump directory. In it should be two
folders: OEM and SYS, and some .dsm files. For this tutorial, we have no use for
the OEM folder, so you can feel free to delete that. Now all that should be left is the SYS folder and the .dsm files, which you can delete too. Now, we should just have the SYS folder.
Now, let's get on to the porting, now that we already have the SYS folder.
To get started, download G'Reloc to your Kitchen folder (the one that should contain
your OEM, SYS, and ROM folders). You can download it from here: http://myunspace.com/?d=0D2CE5741
Extract the .zip file to your Kitchen, be it KaiserChef or KaiserKitchen. Now
double-click on G'Reloc.exe, and keep it open. Do not close it until instructed to
do so. Now go into your Kitchen's SYS folder and delete all the files/folders in it
except the directory named ".VM" (no quotes). Now, copy all the files from your
dumped SYS except the folder ".VM" (no quotes) to your Kitchen's SYS.
Now, go into G'Reloc and click "Doit!" until it is finished. Congratulations, you
have just succesfully ported the SYS folder of the 19965 build!
Tips/Advice:
For this specific tutorial, we ported the SYS from the Diamond, which has
VGA resolution. Therefore, to put this on our QVGA display, we will need to take
all of the files/folders that are named *.192.dll and replace them with *.96.dll
folders/files in the Kaiser's SYS. To do this, you will need to replace those files
before deleting all the files in your Kitchen's SYS
How to Port the XIP (CE OS number) of a ROM: (all credit goes to Ameet and KMFM$!)
What you'll need:
A Hex Calculator
Insert.exe (used to insert the xip_out.bin into the OS.nb.payload)
XIPPort.exe
M'Reloc.exe
Kaiser's OS.nb.payload
XIP.bin from the build you want to port
NBMerge.exe (Needed to build OS.nb)
To keep it easy, I zipped all of these tools up (you'll need to get the XIP.bin
you want to port and the shipped ROM's OS.nb.payload, I'll tell you how
later). Just download the attachment at the bottom of this post. Just
download it and unzip it to a folder on your desktop.
Getting the Necessary Files
=====================
Now, we'll need to extract the OS.nb.payload and the XIP.bin from the Kaiser
Base ROM that you are using. For instance, I am using the newest HTC
Shipped Kaiser ROM (3.34), so I put NEWKAISERROM.nbh into the Extract
folder. If you are using the Kaiser 3.29 ROM as your base, you would put
that .nbh file in the Extract folder. Once you have the .nbh in the
Extract the Payload folder, double-click on RunMe.bat. Viola, the
OS.nb.payload and XIP.bin are now in your main folder, along with a new
ROM folder that I'll explain later. Don't delete anything yet
Now, enter back into your main folder and double-click on XIPPort.exe. Then
click on (in order): dump xip.bin, write maps, make pkgs. You should
now have an OUT folder in your main folder. Double-click it and you should
see some .txt files and Files and Modules folders. Enter the Files folder and
delete the MSXIPKernel and MSXIPKernelLTK folders. Delete the same folders
in the Modules directory.
Then, go back into your main folder, rename the OUT folder to OUT_original,
and the xip.bin file to xip_original.bin. Then, place the XIP.bin file from the
build you want to port in this main folder. Once it's there, double-click on
XIPPort.exe and click (in order): dump xip.bin, make pkgs. Now you
should have: an OUT folder, an OUT_original folder, a ROM folder, xip.bin, and
xip_original.bin. Go into your OUT folder, then your Modules folder, then your
MSXIPKernel folder and delete the following directories/files:
hd.dll (folder), hd.dll.txt (file), osaxst0.dll (folder), osaxst0.dll.txt (file).
Also, if you can find bmui.nb0 in one of your
MSXIPKernel folders in your OUT directory, delete it along with
bmui.nb0.imageinfo.txt. Don't worry if you can't find
it, though, because sometimes I can't myself .
Now, copy the folders MSXIPKernel and MSXIPKernelLTK from Files and
Modules folder in your OUT folder and paste them in their corresponding
folders in the OUT_original directory. Now, go back to your main folder,
rename OUT to OUT_port, and OUT_original to OUT. Now, double-click
XIPPort.exe and click (in order): undo, realloc p.
*Ignore any errors it might give you about unknown regions!.
Then click write maps.
Fixing the Addresses
================
Now, here's the tricky part. Open your MAP.txt file in the OUT folder. Look for !!!!!!!!!. If you don't find them (very rare), just skip to the end, called "Putting it All Together". If you do, we'll have to take care of that. Here's an example of the bottom part of MAP.txt:
[e32_vbase] addresses
02000000 - 03e16000 L01e16000 NUL
03e16000 - 03e1f000 L00009000 Virtual base address of wce_rex.DLL
03e1f000 - 03e24000 L00005000 Virtual base address of MMMAP.dll
03e24000 - 03e2b000 L00007000 Virtual base address of htcfsfilter.DLL
03e2b000 - 03e4c000 L00021000 Virtual base address of FLASHDRV.DLL
03e4c000 - 03e52000 L00006000 Virtual base address of ceddk.dll
03e52000 - 03e56000 L00004000 Virtual base address of cecompr.dll
03e55000 - 03e56000 L00001000 !!!!!!!!!!!!!!!!!!
03e55000 - 03e59000 L00004000 Virtual base address of regenum.dll
03e59000 - 03e68000 L0000f000 Virtual base address of pm.dll
03e68000 - 03e70000 L00008000 Virtual base address of mspart.dll
03e70000 - 03e80000 L00010000 Virtual base address of mencfilt.dll
03e80000 - 03e8c000 L0000c000 Virtual base address of imgfs.dll
03e8c000 - 03e96000 L0000a000 Virtual base address of fsreplxfilt.dll
03e96000 - 03eac000 L00016000 Virtual base address of fsdmgr.dll
03eac000 - 03eb5000 L00009000 Virtual base address of fatutil.dll
03eb5000 - 03ec8000 L00013000 Virtual base address of fatfsd.dll
03ec8000 - 03ece000 L00006000 Virtual base address of diskcache.dll
03ece000 - 03eda000 L0000c000 Virtual base address of devmgr.dll
03eda000 - 03f4c000 L00072000 Virtual base address of crypt32.dll
03f4c000 - 03fe2000 L00096000 Virtual base address of coredll.dll
03fe2000 - 03ff0000 L0000e000 Virtual base address of certmod.dll
03ff0000 - 03ffa000 L0000a000 Virtual base address of cachefilt.dll
03ffa000 - 04000000 L00006000 Virtual base address of busenum.dll
04000000 - 80000000 L7c000000 NUL
]]
<< The trick to reading the o32 and e32 table is this:
* the first column is the modules starting address (o32_realaddr or e32_vbase).
* the second column is it's ending address (which should be the same as the realaddr/vbase for the next module).
* the third column (The one that starts with 'L') is the file's "vsize".
>>
These are the overlaps which need to be taken care of by reallocating the modules in Initialized Data and Virtual Base addresses
You need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory.
For example:
03e4c000 - 03e52000 L00006000 Virtual base address of ceddk.dll
03e52000 - 03e56000 L00004000 Virtual base address of cecompr.dll
03e55000 - 03e56000 L00001000 !!!!!!!!!!!!!!!!!!
03e55000 - 03e59000 L00004000 Virtual base address of regenum.dll
Meaning, e32_vbase address of cecompr.dll is overlapping the reserved space of regenum.dll by 1000 (L00001000).
I recommend you use M’Reloc.exe for reallocating the addresses in imageinfo.bin and Notepad to reallocate the addresses in the corresponding imageinfo.txt files.
Since the binaries (S000, S001...) must actually be relocated using M'Reloc, it is not enough to just adjust the values in the imageinfo.txt files.
To calculate the new addresses of the overlapping modules, open the hex calculator.
* You can use windows calculator for this. Open the calculator, click "view" and select "scientific". Now, press "F6" or click "HEX" to put the calculator into hexidecimal mode.
Now to correct the e32_vbase of cecompr.dll, follow this calculation as a base (e32_vbase regenum.dll - e32_vsize cecompr.dll = correct e32_vbase cecompr.dll)
Meaning, (03e55000 – 4000 = 03e51000) hence the correct e32_vbase address for cecompr.dll is 03e51000
Now since the cecompr.dll is reallocated using the above calculation, the modules next in line above that will also have to be reallocated. Namely, ceddk.dll (although not overlapping cecompr.dll yet since we have not "realloc P").
To calculate the e32_vbase of ceddk.dll you will need the new e32_vbase address of cecompr.dll which you got just now (03e51000).
I recommend writing down the e32_vbase, e32_vsize, o32_realaddr and o32_vsize of each module so it will be easier to calculate the correct addresses for reallocation).
Remember, you need to work our way up from the bottom of the list since the busenum.dll is reallocated at the last address of the memory.
To reallocate the addresses for o32_realaddr, follow the above calculation. Only this time, replace the e32_vbase with o32_realaddr and e32_vsize with o32_vsize.
Now open the corresponding imageinfo.txt file for each module and change the e32_vbase and o32_realaddr address values in the txt file of the values mentioned with V= and D=, seen for e.g. like this:
Module name: cecompr.dll
e32_vbase: V=03E52000
...
o32[1].o32_realaddr: D=01FEE000
You will notice that the 'FLASHDRV.DLL' module has the realaddr at 2 regions. Although I have not found a way to calculate the difference between both regions but I change the values as per Abusalza’s MAP.txt
o32[1].o32_realaddr: D=01FCC000
o32[3].o32_realaddr: D=01FD4000
Since the OEMXipKernel modules never change, I only correct values of the ported MSXipKernel modules
This is helpful if the MSXipKernel modules ported from donor ROMs are similar in the sizes. If not then you will need to do the calculation and correction of values
Once completed the address reallocation, open XIPPort.exe and click “realloc P” to re calculate the addresses for writing maps. It will show you errors regarding some regions, ignore those and click “write maps”.
Open the new MAP.txt and recheck for (!!!!!!!!!!!!!!!!!!). If there are no errors that means the XIP has been sucessfully ported.
Putting it All Back Together
=====================
Now open XIPPort.exe and click “build xip_out.bin” to create the resulting XIP to be inserted into the ROM .payload file (xip_out.bin).
Now, double-click RunMe.bat in the MAIN folder. Congratulations chef, your ROM folder is ready! Now just move the ROM folder and replace the one in your kitchen with it!
You rock man!! Thanks for the contribution.
Thanks, mbarvian! I had been going through other forums putting pieces together for the kaiser as well. Seems that you figured it out a little more quickly than I.
Oh that one day I will get time to do what Sambartle did in the Hermes forums and combine this allong with instructions for Kaiserchef into one handy guide for how to cook.
Thanks for giving back to the newbie cooks mate. Much appreciated.
your are the best m8 great tutorial
for G reloc the VM numbers is already for the kaiser?
thanks!!
b16b said:
your are the best m8 great tutorial
for G reloc the VM numbers is already for the kaiser?
thanks!!
Click to expand...
Click to collapse
yes, but I always just click "Doit" just to make sure
Great tutorial, many new chefs will be very happy to see this!
really nice thing m8 but it was working on hermes exatly this way i ported always full sys port but on kaiser wont boot the full SYS port if i get the new SYS from HERMES no BOOTing
Waiting for the XIP guide
anryl said:
really nice thing m8 but it was working on hermes exatly this way i ported always full sys port but on kaiser wont boot the full SYS port if i get the new SYS from HERMES no BOOTing
Waiting for the XIP guide
Click to expand...
Click to collapse
i think you need vm numbers for HERMES is deferent from kaiser
Do you know how to get your initials in the sys build number, like the pro chef's do??
mbarvian, i have tested your method but, when I input the cmd pgktool dump from dos shell i had win error. Someone have tried this method!?
indagroove said:
Do you know how to get your initials in the sys build number, like the pro chef's do??
Click to expand...
Click to collapse
if you do this correctly, the build numbers will change
@furb3t: what errors did you get?
I have understood my error. I haven't put pkgcommon.dll into the same dir of pkgtool.exe . Now cmd goes, but into dir \dump I haven't a dir \Sys but only all files (.Vm and .Rom after cmd there aren't)
Gee, not many people wanted to share their secret recipes nowadays. My utmost salute for you mb... i always appreciate that kind of spirit highly.
Now,what i need is time to cook, oh well...
furb3t said:
I have understood my error. I haven't put pkgcommon.dll into the same dir of pkgtool.exe . Now cmd goes, but into dir \dump I haven't a dir \Sys but only all files (.Vm and .Rom after cmd there aren't)
Click to expand...
Click to collapse
thank you for bringing that to my attention. I just updated the instructions with the newer, easier PackageTool
indagroove said:
Do you know how to get your initials in the sys build number, like the pro chef's do??
Click to expand...
Click to collapse
You'll need to manually edit the d0b41563-b345-4444-aa15-986e7c7fff99.dsm file in SYS\OS.
That is, if I am reading your post correctly. You want the about screen to show something similar to the following, correct?
Code:
CE OS 5.2.20755 (Build 20755.1.4.0 Groove Edition)
as opposed to the standard
Code:
CE OS 5.2.20755 (Build 20755.1.4.0)
Are you sure about that?
How do you manual edit a .dsm?
KMFM$ said:
You'll need to manually edit the d0b41563-b345-4444-aa15-986e7c7fff99.dsm file in SYS\OS.
That is, if I am reading your post correctly. You want the about screen to show something similar to the following, correct?
Code:
CE OS 5.2.20755 (Build 20755.1.4.0 Groove Edition)
as opposed to the standard
Code:
CE OS 5.2.20755 (Build 20755.1.4.0)
Click to expand...
Click to collapse
Sorry about that, Laurentius26. I meant "hex edit" opposed to "manually edit". I can see where that would cause confusion.
There is another discussion that deals more with this:
http://forum.xda-developers.com/showthread.php?t=409845&page=3
(As you probably already know, Laurentius26. )
Haha... that's exactly what I needed and didn't know yet.
Thank you!
Grtz,
Leo
Edit: and this is not to fake CE OS version because I ported whole Opal OEM.
KMFM$ said:
Sorry about that, Laurentius26. I meant "hex edit" opposed to "manually edit". I can see where that would cause confusion.
There is another discussion that deals more with this:
http://forum.xda-developers.com/showthread.php?t=409845&page=3
(As you probably already know, Laurentius26. )
Click to expand...
Click to collapse