Hi all,
I'm an owner of FSC T830 Loox...
With the great help of bepe and mamaich I'm trying to cook my own rom... (thx guys, really!)
At the moment replacing even one module makes the device not to boot.
The problem is now upgrading the rom from aku 2.x to 3.x
As mamaich says newer AKUs have added new functions to coredll, therefore I need to port the XIP section...
I need help on this case:
I succesfully dump the XIP of my ROM
dump -o 0x00250000 myrom.rom xip.bin
dumprom -5 xip.bin -d xip
The question is: how can I port the XIP section from a newer AKU?
Thanks for all your valuable helps!
hi turchino,
do you find a solution for flash a loox t to a newer os version?
bg joy
Hi!
I'm also trying to port the xip section from a newer AKU to the T830.
It seems that none of the current tools is working correctly with that rom. Rommaster isn't working at all. Dumpromx can extract files, but not replace any (e.g. replacing a bigger file with a smaller ->not enough space...)
I've tried to manually replace coredll.dll in the t830 xip section with the newer one but it didn't want to boot. The strange thing is that t830's coredll.dll is much bigger than one from AKU 3.5.2. Any ideas about that? (maybe compression?)
I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?
Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting.
Any ideas how to get that running?
hey. bepe's xipport is designed for dealing with WM5/WM6 xip's.
with dumpromx you would need to increase the image file size by adding 00 bytes at its end before attempting to add anything. be careful, if the xip section grows too large then it may not fit in the partition in your nand flash....
also i'm not sure if it supports wm5/wm6 xip editing or just ce 4.x/wm2003/ce3.
rommaster is too buggy dont even try that one i think...
manual replacing isn't too tricky if you know what you're doing.... you need to know about PE header stuff. how did you try to replace it?
also, the new coredll should have the same base address as the original one or one that isn't conflicting with anything else.
did you make sure about that?
did you also edit romheader properly - because if this new coredll was larger than the original one the image is larger for sure and romheader needs editing.
don't forget about compression issues either. maybe that's why the original one is much bigger. but i would need to see the coredll's in question
anyway it is possible to do a coredll replace manually (did that before), no worries. but bepe's tool might make it easier
you say: "I've also noticed one realaddr of a .pdata section from nk.exe is pointing out of the xip section?! (psize:00000000, dataptr:00000000)?"
if psize is 0, then the .pdata section isn't really initialized data. it's a zero sized section and will only be existing when the loader loads the executable into ram.
but it sounds kind of strange to have a .pdata with 0 size, which file had this section?
edit: ok i see you meant nk.exe heheh. that's fine. it usually does have a zero sized section
you say: "Also relocating a completely AKU 3.5.2 xip section to t830's base address and changing boot.hv isn't booting."
how did you do the relocating?
xipport was the exactly the tool I was looking for. After a few modifications "realloc P" of the unmodified xip gave me exactly the same map.txt as the original t830 xip map.txt. After exchanging all kernel files (except hd.dll and osaxst0.dll which were needed to keep another oem file in the same location as it was before), reallocing and changing the header address in nk.exe it still isn't booting (it runs nk.exe but gets stuck somewhere in there). Maybe you can have a look at the whole thing (download here, with modified xipport)
As for the coredll, it turned out that dumprom missed a section.
I did the relocation by writing a little app which runs through all pointers and changes them, but this is also possible by editing romheader.txt from xipport.
ok I've changed the other dlls too (had the same size), but it still wont boot. Is there a kernelflag which I can set to get debug messages on the screen? Or do you know if the nandflash driver trueffs.dll from AKU2 is compatible with AKU3?
hey. sorry for the delay.
did you solve the problem yet?
if not, i'm going to check it for you soon.
about coredll. OK but how do you mean dumprom missed a section? i've never heard that before about it.
relocation: yeah, romheader.txt is the trick there. but, must be a nice app. i'll check it out (i see it's in the zip)
edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot).
p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?
"edit: OK i took a very quick look (i need to go now). the xips you uploaded have completely different romheaders and rom mappings (0x88xxxxx vs 0x80xxxxxx). what you said about relocation sounded like you already fixed that, but why did you upload this old version then? or did you upload original T830 and original AKU 3.5 from another device? i'd like to see your xip (that doesn't boot)."
The xip in "xipport" is the modified t830 xip that doesn't boot. (btw. xip.bin in that folder is the original t830 xip). And the xip in "xipport aku3.5.2" is the xip I want to port to the t830.
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
"p.s.: did you make sure the hard coded romheader pointer in the kernel matches the romheader pointer/location in your xip ?"
yep, the kernel always gives a me message when it has found the romheader and continues booting. Therefore I always know when I missed something
hey.
OK that sounds more clear now about which xip is which!
i'll look at it again soon.
until then: did you verify the copyentries are all OK? xipport sometimes has a silly bug regarding them.
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
also pay attention to map.txt see if the base addresses overlap or not (usually not but worth checking), also if .data base addresses (the 0x01Fxxxxx ones) have not been changed. they should not be changed. another xipport bug sometimes.
new--->
update: i looked at your xip now.. none of the above seem to apply. i'll leave that stuff there though.
last thing i can think of is try editing physlast in romheader to point to last actually used byte in xip.. that shouldn't matter but who knows
can you tell me how far does your system boot. maybe the xip is fine and your IMGFS part is wrong. check for module overlaps.
what is last message you get from your kernel?
and, to answer your question about kernel wanting to have files at specified addresses. well, the kernel regions have to stay at the original addresses in the xip, except for the region that is copied out and for the discardable last region (same for the debug crap dlls)
Core_Z said:
"
The only success I had to now was getting the original wm5 aku 2.3 rom to run with the aku 3.5.2 coredll.dll. Is there anything else I have to do after I have replaced the t830 sys folder with an aku3.5.2 folder and building the reg/imgfs? Or does the kernel want to have some files at a specified address?
Click to expand...
Click to collapse
Hi Core_Z,
I'm trying to accomplish the same thing for our XDA Atom. I was wondering if you could describe how you achieve above. I, too, would like to replace the coredll.dll in our old AKU2.2 from the AKU3.X
These are the steps, I made using the modified XIPport (with realloc function):
1. coredll.dll comes from XIP of Atom Life which has same base address
2. replaced the modules and corresponding txt file into ATOM AKU2.2
3. new core is larger than the old one; so, I increase the ROMHDR.txt physlast to accommodate it.
4. realloc / write new maps.
5. move the rom header pointer in the nk.exe S000 module to the new one
6. built xip_out.bin
7. wrote the new bin to ROM image file
8. flash the device.
It won't boot. Did I miss anything?
cmonex said:
easiest is to just delete hd.dll and osaxstxxxxx.dll - they are the ones that require copyentries apart from kernel. (kernel copyentry isnt screwed up by xipport anyway.)
but, they are not needed for a booting kernel, just debug stuff afaik. so deleting is easy..
btw, even if the copyentries are OK, using the wrong hd.dll/osaxstxxxx.dll will make the xip unbootable.
Click to expand...
Click to collapse
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
check this out Jiggs,
http://www.pxdxa.com/read.php?tid=40125&fpage=1&toread=&page=1
jiggs said:
Hello cmonex / core_z,
I followed this by removing the files you mentioned above. So, my current AKU2.2 XIP has the new coredll.dll from AKU3.X boots now. This means, that hd.dll / osaxstxxxx.dll is preventing my revised XIP to boot.
Question is: How do we restore this modules correctly?
Jiggs
Click to expand...
Click to collapse
hey! i'm back if you still need help: you dont need these dlls, they just take up space. if you really want them then you can do one of two things:
1) use the original dlls from the device's original xip
OR
2) rebase them but this can be more difficult than with ordinary dlls.
(i did not try either, because those dlls are just for debugging anyway.)
jiggs said:
I have another concern...
I have utilized the new XIP with new AKU3.X \SYS files, and rebuilt the ROM using the Scoter Kitchen. In the IMGFS section there is .ROM module wherein the ROM header is also described. However, there is one entry which is not clear to me... which is the e32_imageflags
The old AKU2.2 uses 0x00001e01, the new AKU3.3 uses 0x00002801. If I use the new values, the SDCard driver will not be loaded. If I use the old value, it will be loaded. What does this mean?
Now, because of this, after I build the ROM each time, I have to manually hex edit these values from 28 to 1e. Why? because not all entries of 28 has to be converted to 1e.
Click to expand...
Click to collapse
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
cmonex said:
those values arent really e32_imageflags... i dunno why the imageinfo txt is created in that way for .ROM and .VM
thats to do with the imgfs memory space. probably the SD driver's image base is lower than the new imgfs memory space start address (which is what you were seeing)
to confirm that check the base address (e32 vbase) in imageinfo.txt for the sd dll.
Click to expand...
Click to collapse
Thanks for the info! I'll look at this later.
Here goes nothing: I've been trying to understand the whole porting process but no one ever posts on my threads, so I figured I'd post on this one since it's about the same thing. I'm reading the thread and I'm following... most... ok, half of it. I thought the process of porting the XIP and the SYS was as simple as well... this. If someone wants to correct me, by all means, please do so.
Related
Hello.
History:
My Qtek9090 running WM5 has good CPU, fast graphics and very, very slow filesystem. I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
There exists very handy utility WM5 Files Dumper [thanks buzz_lightyear ]
I think it is a good idea to upload dumps of all files from our PDA's. It would be a good source of information and source of code bricks to cook patches and updates.
Such a dump should contains all files and modules [extracted both from bootloader and OS] and full dump of registry. It should be as clean as possible - just after hard reset, before entering PIN, before adding any contacts and any patches.
Tommorow I will try to upload WM_5_03_02_WWE_built_1337_42_BlueAngel_by_mamaich.zip.
And again - thanks to our master hackers
I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And even if you'll find it - it would not work on your device. It is always XIP.
And it would not speedup your device - it has a slow ROM.
mamaich said:
/me said:
]I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And even if you'll find it - it would not work on your device. It is always XIP.
Click to expand...
Click to collapse
Probably you are right I'm a lame, but I afraid, that it is true.
But: as I understand: XIP means "eXecute In Place". Dll's as modules are executed from slow ROM [and there is no shadow RAM] [and there is no way to cache them]. Dll's as files are loaded into RAM, and then executed. Correct me, if its not true.
We have plenty of RAM, so [probably] it is possible to load a lot of dll's into RAM instead executing them from [slow] ROM.
Dlls created with "WM5 Files Dumper" - looks good. I would have to analyze them several times, I would have to ask master hackers is it true, but I would try to load them into RAM.
mamaich said:
/me said:
I'm looking for something, may be for fatfsd.dll extracted from another PDA. And I cann't find it
Click to expand...
Click to collapse
And it would not speedup your device - it has a slow ROM.
Click to expand...
Click to collapse
Yes, of course.
But SPB benchmark told me:
Reading files from \somewhere is 4 times slower then WM2003. It is a good value.
Write files into \somewhere is 6 times slower then WM2003. It is also a good value.
But:
Copy files [OS level] is two times faster than read them and write back. It is not good value.
Retrieve filenames from huge directory is 10-12 times slower, than WM2003. It is also not a good value [it should be comparable to reading files, ie. 4 time slower]
There are two ways:
1. there is something wrong within fatfsd.dll,
2. overhead of executing fatfsd in place is not acceptable,
3. my benchmarks are wrong [I have not enough time to benchmark filesystem without cache
/me said:
Tommorow I will try to upload WM_5_03_02_WWE_built_1337_42_BlueAngel_by_mamaich.zip.
Click to expand...
Click to collapse
It is here: ftp://xda:[email protected]_WWE_built_1337_42_BlueAngel_by_mamaich.zip
If you think it is a good idea to share WM5 code bricks, upload your your clean dump into
ftp://xda:[email protected]/Uploads/RomFiles_dumps
UserName and Password is here: http://wiki.xda-developers.com/index.php?pagename=BA_FTP_Site search for "xdaupload".
baniaczek said:
But: as I understand: XIP means "eXecute In Place". Dll's as modules are executed from slow ROM [and there is no shadow RAM] [and there is no way to cache them]. Dll's as files are loaded into RAM, and then executed. Correct me, if its not true.
Click to expand...
Click to collapse
There are 3 types of DLLs used on WM5. First type - normal files, they are loaded into RAM, fixups are processed, etc. They are slow to load (due to fixup processing), but would execute from RAM. Second type - XIP, which are executed directly from ROM and would work slowly. In BA this set of files is executed directly from ROM:
Code:
device.exe
filesys.exe
nk.exe
busenum.dll
cecompr.dll
ceddk.dll
certmod.dll
coredll.dll
crypt32.dll
devmgr.dll
diskcache.dll
fatfsd.dll
fatutil.dll
fsdmgr.dll
fsreplxfilt.dll
hd.dll
imgfs.dll
msflash.dll
mspart.dll
osaxst0.dll
pm.dll
regenum.dll
relfsd.dll
It is much less than was in WM2003.
And WM5 added a new filesystem - IMGFS. It contains compressed modules split to sections, but they are fixed to specific addresses in RAM, they are decompressed to these constant areas and executed from RAM. They are similar to XIP as they also don't contain relocations, but would work fast. I don;t know the correct termin for this type of files.
To replace files in XIP section you'll need this tool - http://forum.xda-developers.com/viewtopic.php?t=33321
if you overwrite any of files I've wrote here by a CAB file or other method without modifying ROM - their old versions would be used instead because they are loaded much earlier than all filesystem drivers.
Thanks mamaich
Registry Question
thanks for the files baniaczek!
does anyone know which file or how the other OS registry entries (the ones not in the boot.hv) get created? There are so many more in a full registry.
thanks!
P.S. thanks mamaich for the great tools!
Re: Registry Question
OS imports *.RGU files on hard reset, and it also reads mxip_*_*.provxml files that also can setup registry items. On Universal and similar devices registry can be set by CAB files in extended ROM.
If you add a new RGU file to OS image it would not be processed. Maybe they should have DSM file with the same name, or be mentioned in [HKEY_LOCAL_MACHINE\System\ObjectStore\RegistryUpdate] key or in packages.sof. I don't know. I always add keys to default.hv/user.hv or edit existing RGU files.
Hi there,
I'm pretty experienced with rom cooking, but need a bit of direction from the pros here in a project I'm working on.
I have a working WM6 rom that I'm looking to make a kitchen for in order to more efficiently customize the rom.
I've decoded the rom to nba/fat format (my device uses nba/nbf format) and dumped the imgfs to a dump folder without any issues and can edit the rom that way, but I'm looking to make a kitchen.
I've used bepe's package tool to convert my dump into OEM & SYS folders without any problems. I now just need to be pointed in the right direction on how to rebuild these packages back into a working nba/fat file.
I've tried putting the OS & SYS directories in an existing kitchen like the bepe/helmi/scoter kitchens and using the imgfs tools there building the packages back into a rom. The rom builds successfully but then won't boot past the initial splash screen after flashing it.
Is there something else I need to do? Is it possible Bepe's package tool isn't properly building the packages?
Any help is appreciated. Thanks for everything each of you does to help the community
anyone?
I'm no expert, but everytime I've tried to dump a rom then rebuild it and flash it, it freezes at the 2nd splash screen. I never could get it to work, then I read somewhere that if the RGU files are missing then it would fail to boot, and sure enough on every rom I tried to dump, the RGUs were gone
My advice would be to build your rom with an existing kitchen. Collect all the packages you can find, build the ones you can't. Save all your custom graphics, themes, sounds, ringtones. Export all the registry keys for the programs you have on your phone now and use them to tweak your packages. It really won't take you much longer than if you were able to use the one you dumped. Before you know it, the kitchen you put together will be so much better than the ROM you dumped that you'll forget all about it!
My kitchen is a work in progress, but right now it's SO close to the way I want it that I can do Hard Resets without a thought as the only thing that needs to be done afterwards is restore my contacts!
All my connection settings are there, all of the buttons are set the way I like, all the colors, graphics, themes...everything! I've even set up an extrended rom with custom cabs I put together with all my commerical software with the Registration keys built-in.
I can't recommend a kitchen since I haven't used them all, but I started with Octaivio's with a 1437 build rom, now I've replaced that base rom with the 1908 build one from his latest kitchen and it's worked fine. The reason I used Octaivio is because he used Pbar as a taskmanager instead of that awful useless HTC x button (remnants of it still pop up when switching from portrait to landscape and vice versa).
joemanb said:
I'm no expert, but everytime I've tried to dump a rom then rebuild it and flash it, it freezes at the 2nd splash screen. I never could get it to work, then I read somewhere that if the RGU files are missing then it would fail to boot, and sure enough on every rom I tried to dump, the RGUs were gone
Click to expand...
Click to collapse
I can easily dump a rom, change it, rebuild it and use it successfully. That's not my issue. And, by the way, you were given misinformation about the rgu's. The rgu files are supplementary registry files that are merged into the main hives for each specific package, to make the registry entries modular. Even if you were to delete some rgu files, your device would still boot but wouldn't have the desired behavior for the packages you installed as some registry entries would be missing
My advice would be to build your rom with an existing kitchen. Collect all the packages you can find, build the ones you can't. Save all your custom graphics, themes, sounds, ringtones.
Click to expand...
Click to collapse
There are still a number of devices where no kitchen exists--mine is one of them, and honestly I'm not looking to use someone else's--I'd prefer to make my own
I just need someone to tell me what needs to be done to convert the OEM & SYS directories generated by bepe's package tool back to a working rom.
Steps I'm attempting now:
1) Dump original rom to dump folder
2) Run Bepe's package tool to make SYS & OEM folders.
3) Add modules
4) Run G'Reloc to fix overlapping modules.
5) I run BuildOS which makes the dump in the temp folder from the SYS & OEM folders.
6) I copy the original rom's fat(nba) to a temp folder
7) I dump imgfs from fat(nba) to imgfs bin file in temp folder with prepare_imgfs.exe
8) I merge the dump back into imgfs bin file with buildimgfs.exe
9) I put imgfs back into the fat(nba) with make_imgfs.exe
10) I convert nba back to nbf to flash
11) I flash the rom successfully.
12) Doesn't get past splash screen
Can anyone tell me what I'm missing or what could be making this non-bootable?
Thanks.
So its not the RGUs..
Please, if you figure this out, post the solution. When I ran into this, I searched all over the forum for a solution and found at least 2 or 3 other posts with this problem, but never a response.
Good Luck
have you modified the Iniflashfile.txt? thats the step most leave out and then it wont boot past the second splash screen
austinsnyc said:
have you modified the Iniflashfile.txt? thats the step most leave out and then it wont boot past the second splash screen
Click to expand...
Click to collapse
No, at this point I'm not trying to change the initflash so I haven't modified it. I know that when the time comes to change it I'll need to do the hex edit thing for the first 2 bytes, the unicode and the last line empty,. etc.
Also I'm not even getting to the 2nd splash. I'm not getting off the initial splash screen.
I'm thinking at this point the imgfs isn't getting put back together properly.
There have got to be some old pros who can tell me what I'm doing wrong.
I think I found part of the problem. In step 5, CreateOS.exe is doing something wrong with the hives. After running it, default.hv which is 770K+ in sys/metadata goes down to like 42K.
Anyone know why this is happening?
source said:
I can easily dump a rom, change it, rebuild it and use it successfully. That's not my issue. And, by the way, you were given misinformation about the rgu's. The rgu files are supplementary registry files that are merged into the main hives for each specific package, to make the registry entries modular. Even if you were to delete some rgu files, your device would still boot but wouldn't have the desired behavior for the packages you installed as some registry entries would be missing
There are still a number of devices where no kitchen exists--mine is one of them, and honestly I'm not looking to use someone else's--I'd prefer to make my own
I just need someone to tell me what needs to be done to convert the OEM & SYS directories generated by bepe's package tool back to a working rom.
Steps I'm attempting now:
1) Dump original rom to dump folder
2) Run Bepe's package tool to make SYS & OEM folders.
3) Add modules
4) Run G'Reloc to fix overlapping modules.
5) I run BuildOS which makes the dump in the temp folder from the SYS & OEM folders.
Click to expand...
Click to collapse
At this point I think that you have the XIP extracted already, in order to create valid boot.rgu
6) I copy the original rom's fat(nba) to a temp folder
7) I dump imgfs from fat(nba) to imgfs bin file in temp folder with prepare_imgfs.exe
8) I merge the dump back into imgfs bin file with buildimgfs.exe
9) I put imgfs back into the fat(nba) with make_imgfs.exe
10) I convert nba back to nbf to flash
11) I flash the rom successfully.
12) Doesn't get past splash screen
Can anyone tell me what I'm missing or what could be making this non-bootable?
Thanks.
Click to expand...
Click to collapse
It's a suggestion, but i think you're missing the .rgu files.
Of course, those are not needed when flashing, but when BuildOS creates the default.hv and user.hv...these 2 being invalid, the OS can't boot.
Probably Bepe can clear you better on that one.
Cheers !
source said:
And, by the way, you were given misinformation about the rgu's.
Click to expand...
Click to collapse
Apparently not, after reading Anichillus' response (which agreed with mine) I converted the HVs to RGUs and it WORKS finally!
It's probably not a good idea to reject info out of hand like that..You almost had me convinced. Thankfully I always try to verify information before I accept it, or tell someone they're wrong, mistaken, or misinformed.
Thanks Anichillus!
This is a release for my ROM porting kitchen. It ports both XIP's and SYS folders. It currently supports the following:
Herald
Wizard
Prophet
Kaiser
Elf/Elfin
Hermes
Zinc
Athena
http://www.darthnet40.com/xda/ivanmmj/Kitchens/
(You will need 7-Zip to open the file.)
This is compatible with Bepe's extended kitchen, but I don't believe he ever released one for every device out there. It requires a ROM folder with an extracted XIP folder within it. Just download the Herald's and you'll see what I mean. The ONLY tested section has been the Herald section as that's the only device that I have.
If your device is compatible with Bepe's kitchen or my kitchen, it will automatically launch the kitchen right after.
Instructions:
Delete your old SYS folder
Place the SYS file you wish to port into Working_Folder
Place your xip.bin that you wish to port into the Prepare folder
*Note: Close the XIPPort program after pressing "Make Packages." The script will take over after that.
You should not have a Working_Folder with an OEM, SYS and XIP folder (and a Tools folder if you have Bepe's kitchen, even more if you have my kitchen.)
Double click on the RunMe file and choose your device.
For those who have a kitchen:
Place bepe's kitchen in the Working_Folder (so that OEM/SYS/ROM and other folders are right within Working_Folder.) Alternatively, you can place also place all the files into EasyBakeOven's folder. Allow the Working_Folder to override EasyBakeOven's Working_Folder. You will not loose any data but will bypass a few "info" scripts. This will not cause any problems.
Obligatory Warning Label:
Use this at your own RISK. I cannot be held liable for any damage caused to your device by your own mistakes or by my mistakes in the instructions.
If you wish to know how to do this manually, head over to my HowTo thread.
Thank you's go to:
Bepe for his Extended kitchen and Herald/Atlas files
ababrekar for the elfin files
l3v5y and xvx45 for the Prophet files
character and ginminded for the Wizard files
Script for the Kaiser files
tjkhattak61 for the Atom Exec files
cruzzmz for the Zinc files
caxio for the Hermes files
irus for the Athena files
Changelog
V2.2
Added Athena Compatibility
V2.1
Added Prophet Compatibility
Added Elfin/Elf Compatibility
Added Hermes Compatibility
Added Kaiser Compatibility
Added Zinc Compatibility
Added Atom Compatibility
V2
Added Wizard Compatibility
Rewrote script to add expandability
V1.5
XIP porting complete
V1
SYS porting complete
Woo! I've failed to find a link for this up till now, but now I can cook some new ROMS!!
One thing, the read me doesn't include some of the more reason compatibility improvements...
Welcome to EasyBakeOven!
Devices supported:
Herald/Atlas
Wizard
Note: Make sure that the XIP in your recieving folder has been extracted already (You should have a ROM folder with a XIP folder inside it.) This is not an issue if you're using Bepe's Extended 6.1 kitchen or my own JustClean EasyBakeOven.
Thank you's go to:
Bepe for his Extended kitchen and Herald/Atlas files
ababrekar for the elfin files
l3v5y and xvx45 for the Prophet files
character and ginminded for the Wizard files
Script for the Kaiser files
tjkhattak61 for the Atom Exec files
cruzzmz for the Zinc files
caxio for the Hermes files
irus for the Athena files
Click to expand...
Click to collapse
l3v5y said:
Woo! I've failed to find a link for this up till now, but now I can cook some new ROMS!!
One thing, the read me doesn't include some of the more reason compatibility improvements...
Click to expand...
Click to collapse
Noted. Thank you!
Has anyone found this even remotely useful? If not, I will not pursue adding more devices.
Has anyone found this even remotely useful? If not, I will not pursue adding more devices.
Click to expand...
Click to collapse
I have! I've ported a Kaiser XIP and a Touch one to the Prophet! Problem is I couldn't find the latest builds so they where slightly out of date...
l3v5y said:
I have! I've ported a Kaiser XIP and a Touch one to the Prophet! Problem is I couldn't find the latest builds so they where slightly out of date...
Click to expand...
Click to collapse
Just for being nice to me, here you go!
That's the newest official build. Be careful of anything "newer," they're fakes.
It's the one labeled 19213.7z
You'll need 7Zip to open the file. In it as the xip.bin and the SYS folders.
Yay!!!
Porting time!
I have one feature request!
Would it be possible to build a feature in that cleans out the folders before porting?
I think I'll test later cause actually I'm in exam but I think it work, I'm on the same device as l3v5y so I'll make my test and maybe take to you Artemis files (my other phone)
Thank for your hard work
Great tool ivanmmj.... I have a few questions. I guess I don't fully understand the process.
I've been able to get the XIP folder, os.nb.payload and romhdr.bin files from a KAISER rom... plus I used the .VM and WinCENLS_WWE folders from a working HERMES rom, but I can't seem to get past the second boot screen. A question I had is... do we use the os.nb.payload and romhdr.bin we got from the KAISER? or do we use those from a working hermes rom? and the XIP directory, do we need to change anything in there? or is just extracting it out, enough to work?
Thanks in advance.
Awesome tool, looks like a dummy can me even port ROM's will try it out sometime. Thanks bunches!
l3v5y said:
I have one feature request!
Would it be possible to build a feature in that cleans out the folders before porting?
Click to expand...
Click to collapse
Already ahead of you. Today I noticed that I tend to leave a mess behind. lol I'll have it remove the files before replacing them, then I'll have it delete the extra files created during the process when it's done. (This part is already ready but I just haven't uploaded it. The removing the files before replacing them, I haven't done so, yet. Although this might not really be needed. Only the cleaning after part.)
...Maybe I don't know what you're talking about. lol
Explain it to me.
AssassinsLament said:
Great tool ivanmmj.... I have a few questions. I guess I don't fully understand the process.
I've been able to get the XIP folder, os.nb.payload and romhdr.bin files from a KAISER rom... plus I used the .VM and WinCENLS_WWE folders from a working HERMES rom, but I can't seem to get past the second boot screen. A question I had is... do we use the os.nb.payload and romhdr.bin we got from the KAISER? or do we use those from a working hermes rom? and the XIP directory, do we need to change anything in there? or is just extracting it out, enough to work?
Thanks in advance.
Click to expand...
Click to collapse
You need the XIP folder, os.nb.payload and romhdr.bin of YOUR device and the xip.bin and SYS folder of the rom you want to port INTO your device. Which device do you have? Tell me and I'll "draw" a map of what goes where.
xvx45 said:
I think I'll test later cause actually I'm in exam but I think it work, I'm on the same device as l3v5y so I'll make my test and maybe take to you Artemis files (my other phone)
Thank for your hard work
Click to expand...
Click to collapse
That would be more than welcomed especially since I'm gonna use my Herald cooking class and modify it to teach Artemis users, also.
ai6908 said:
Awesome tool, looks like a dummy can me even port ROM's will try it out sometime. Thanks bunches!
Click to expand...
Click to collapse
My hope is that it will allow just about anyone to port a ROM. ^_^
ivanmmj said:
You need the XIP folder, os.nb.payload and romhdr.bin of YOUR device and the xip.bin and SYS folder of the rom you want to port INTO your device. Which device do you have? Tell me and I'll "draw" a map of what goes where.
Click to expand...
Click to collapse
Thanks for replying ivanmmj... I have a hermes, and I've been doing exactly that... my problem is when I go to build it, I get "An unhandled win32 exception occurred in buildxip.exe [2276]"
If I put in my older XIP build, buildxip works fine... so I'm lost now. Oh, and I'm trying to port the 19213 official att kaiser rom XIP.
AssassinsLament said:
Thanks for replying ivanmmj... I have a hermes, and I've been doing exactly that... my problem is when I go to build it, I get "An unhandled win32 exception occurred in buildxip.exe [2276]"
If I put in my older XIP build, buildxip works fine... so I'm lost now. Oh, and I'm trying to port the 19213 official att kaiser rom XIP.
Click to expand...
Click to collapse
You'll need:
OEM: hermes
ROM folder: Hermes (uncluding the XIP folder and all the other files)
SYS folder from kaiser (look for and remove MSkernel from this folder... I'm not 100% on that folder yet and future versions may handle that folder automatically)
Place the xip.bin from the kaiser into the prepare folder.
Now run the RunMe
ivanmmj said:
You'll need:
OEM: hermes
ROM folder: Hermes (uncluding the XIP folder and all the other files)
SYS folder from kaiser (look for and remove MSkernel from this folder... I'm not 100% on that folder yet and future versions may handle that folder automatically)
Place the xip.bin from the kaiser into the prepare folder.
Now run the RunMe
Click to expand...
Click to collapse
I really appreciate your help ivanmmj, same thing again. It chokes up on BuildXIP.exe ...I have BuildXIP version 0.53 if that makes any difference. I tried with two XIP versions... 19209 and 19900. I'm about to give up.
Oh and I have Visual Studio 2008 installed, so I don't think it would be the runtimes... would it?
AssassinsLament said:
I really appreciate your help ivanmmj, same thing again. It chokes up on BuildXIP.exe ...I have BuildXIP version 0.53 if that makes any difference. I tried with two XIP versions... 19209 and 19900. I'm about to give up.
Oh and I have Visual Studio 2008 installed, so I don't think it would be the runtimes... would it?
Click to expand...
Click to collapse
It might be.... I'll have to do some research...
Ok, I even installed the vs2008 runtimes, same thing.. I found buildxip v.54, same thing... then i moved the whole ROM folder (new XIP) out and put in the old 19209 one and it ran... so maybe there's something wrong with 19213 with hermes? ok, I give up. Thanks for your help!!
19213 porting to elfin
i'm trying to port the 19213 to my elfin, and after porting when i use bepe's kitchen, it gets stuck at this screenshot. anybody help!!!
I'm trying to get an "old-style" 6.5 ROM built using EVK, and while using wmreloc builds the ROM successfully, it never boots. I've read about Extreloc in a few places, and apparently it's supposed to a better job of relocating modules. So does anyone know how to integrate Extreloc into EVK to cook a bootable, dumpable (possibly even Image Update-Ready) ROM?
Bepe specifically designed platformrebuilder to delete dsm files and the final s00x file in modules more or less to save space (he compared it to removing the ULDR in XIP) and improve module loading speed so unless you can make prb NOT do that then I doubt it. Although it sounds really interesting, I too wish we could try another reloc.
Psyki said:
Bepe specifically designed platformrebuilder to delete dsm files and the final s00x file in modules more or less to save space (he compared it to removing the ULDR in XIP) and improve module loading speed so unless you can make prb NOT do that then I doubt it. Although it sounds really interesting, I too wish we could try another reloc.
Click to expand...
Click to collapse
But I think the "old-style" option in Visual Kitchen actually adds the DSMs back in (or re-creates them) - have you tried it?
Extreloc
Speaking of Extreloc - does anyone know where I can find it (along with, perhaps, some instructions on the parameters to use with it)?
Captain_Throwback said:
Speaking of Extreloc - does anyone know where I can find it (along with, perhaps, some instructions on the parameters to use with it)?
Click to expand...
Click to collapse
Here are some links but not in English!!!
http://4pda.ru/forum/index.php?showtopic=137276
http://3ppc.net/forum/showpost.php?p=282398&postcount=45
Good luck!
kokotas said:
Here are some links but not in English!!!
http://4pda.ru/forum/index.php?showtopic=137276
http://3ppc.net/forum/showpost.php?p=282398&postcount=45
Good luck!
Click to expand...
Click to collapse
Thanks for these links!!
I did find a downloadable Extreloc, and the one link had a good manual (thanks to Google Translate). Of course, I still can't cook an old style ROM with EVK, because, even though the OEM & SYS work okay, DSM Editor doesn't have the information to create DSMs for the EXT packages, apparently, which is where the issue lies. I wonder if I can create DSMs for all of the EXT packages, put them in the packages, and see if I can dump the ROM?
Captain_Throwback said:
Thanks for these links!!
I did find a downloadable Extreloc, and the one link had a good manual (thanks to Google Translate). Of course, I still can't cook an old style ROM with EVK, because, even though the OEM & SYS work okay, DSM Editor doesn't have the information to create DSMs for the EXT packages, apparently, which is where the issue lies. I wonder if I can create DSMs for all of the EXT packages, put them in the packages, and see if I can dump the ROM?
Click to expand...
Click to collapse
i havent tried cooking old style rom in a long time, but doesnt evk place dsm/rgu in ext pkgs when you dump a stock rom? thats one reason i stopped using evk to dump stock roms and rebuild, now i use extrebuild its so much cleaner
twopumpchump said:
i havent tried cooking old style rom in a long time, but doesnt evk place dsm/rgu in ext pkgs when you dump a stock rom? thats one reason i stopped using evk to dump stock roms and rebuild, now i use extrebuild its so much cleaner
Click to expand...
Click to collapse
It puts them in the folder with the EXT packages, yes, but not in a place where they get cooked into the ROM (if cooking a new-style ROM, that is). It also creates a package.ini file that details the dependency information for each package, based on the info in the DSM. It only keeps them there for cooking an "old-style" ROM, which is what would make this work as I would like it; except it doesn't work properly, and for user-made packages that don't include DSMs, DSM Editor doesn't seem to create them properly when cooking an old style ROM.
i cooked an image update rom for kaiser back last year, and i just used build OS old style kitchen to cook the rom and it worked i cant wait to be able to start using image updater, but its a real pita to cook a rom that it will work on now...and like you said its really hard to put in custom pkgs, with kaiser i basically re-cooked a stripped down stock rom. Da_G is getting closer to having his new kitchen tools done, then we should be able to build roms easily that will work with the updater
@captain
I am also looking for the exactly the same. I too want to cook in old style. But, not able to find any rebasing tool equivalent of the one in platformrebuilder.exe. Extreloc, though, is claimed to work well but for me it does not give very dependable results.
I am also interested in this kind of solution Pl update us here in case you manage to find any...
Maybe this helps?
I don't know where I have it from anymore, if I remember good it was Conflipper who shared that maybe at Mobile Underground , haha I'm realy not sure.
LoL
But I think it's something you can use.
Laurentius26 said:
Maybe this helps?
I don't know where I have it from anymore, if I remember good it was Conflipper who shared that maybe at Mobile Underground , haha I'm realy not sure.
LoL
But I think it's something you can use.
Click to expand...
Click to collapse
Thanks Leo, but EVK comes with this version of WMReloc. I've tried using it to cook a 6.5 "old-style" ROM, and while the ROM compiles successfully, it won't boot. I'm thinking it could be related to module overlaps due to WMReloc's not handling the 6.5 modules properly (even though I know it's supposed to). In fact that may not be the case, but I thought EXTReloc was supposed to a better job of this. I think the real issue (and I may have already stated this) is that the DSMs from the EXT packages aren't being properly re-created during the build process by DSM Editor (perhaps that's outside the realm of what it can do?). In most cases, my EXT packages have been dumped from official ROMs, and as such have the DSM/RGU's outside of the "files" folder. They should be easily re-integrated during cooking, but I don't think that step is taking place. Perhaps it's as simple as adding a command into the batch file to copy those files into the "dump" folder for each package (I'm not really sure the best way to do that, though)? And what about packages that happen to be missing that information? Is there a way to re-create those on the fly, or would that need to be done manually? I assume for custom packages (like graphics, etc.), dependency information isn't really needed, but when dumping the ROM, those files won't have a home, I suppose .
Here's a quote from Da_G, maybe you need to use Misar's G'Reloc?
Btw I'm just a nOOb with all these tools and batch files, I know a little but just trying to help you.
Maybe a little about batches... and I read a lot.
Da_G said:
WinMo 6.5 improves on this by opening up Slots 60 and 61 to Modules - yielding an extra 64mb of potential Virtual Memory space. (the allocation order is now 1, 61, 60, 0 for modules, 60, 61, 0 for files) - In order for the Kernel to recognize these new Slots as being mappable for Modules, it must be updated to the 6.5 codebase. This is where the 6.5 nk.exe comes in, and why it's so important.
Profiling Virtual Memory is an important job for an OEM - the less available in Slot 0, the sooner a device will kick back out of memory errors (even if it's not truly out of memory) - and the worse the user experience will be. Some ROM's I have seen have less than 20MB available in slot 0 (and the user experience is as bad as you might imagine) - There are many more intricacies to the whole process - like balancing the load between services.exe and device.exe to best utilize the 32mb VM space available to each, and storing all resource-only dlls as modules so they can be allocated to Slot 63, etc.
This is also why it's important that the re-alloc tools be updated to support the new slots - g'reloc will not ever try to allocate modules to slot 60/61 because as far as it's aware, this is not possible. For the moment I know of 2 tools that will realloc to slot 60/61, wmreloc 2.0, and bepe's Platform Rebuilder (used by ervius vk)
What's the take-home message about VM?
Keep Slot 0 as free as possible. WM 6.5 NK allows you to use more modules without taking up SLOT 0 space, so allows more flexibility to use modules (which are faster to load)
Click to expand...
Click to collapse
Captain_Throwback said:
Thanks Leo, but EVK comes with this version of WMReloc. I've tried using it to cook a 6.5 "old-style" ROM, and while the ROM compiles successfully, it won't boot. I'm thinking it could be related to module overlaps due to WMReloc's not handling the 6.5 modules properly (even though I know it's supposed to). In fact that may not be the case, but I thought EXTReloc was supposed to a better job of this. I think the real issue (and I may have already stated this) is that the DSMs from the EXT packages aren't being properly re-created during the build process by DSM Editor (perhaps that's outside the realm of what it can do?). In most cases, my EXT packages have been dumped from official ROMs, and as such have the DSM/RGU's outside of the "files" folder. They should be easily re-integrated during cooking, but I don't think that step is taking place. Perhaps it's as simple as adding a command into the batch file to copy those files into the "dump" folder for each package (I'm not really sure the best way to do that, though)? And what about packages that happen to be missing that information? Is there a way to re-create those on the fly, or would that need to be done manually? I assume for custom packages (like graphics, etc.), dependency information isn't really needed, but when dumping the ROM, those files won't have a home, I suppose .
Click to expand...
Click to collapse
Just as an aside info..... the evk dont uses DSMs i mean they are useless at this point for the kitchen... maybe next generation kitchens will tell you... "Hey if you need to cook this Module for this App you need to add this and this and this due to dependencies"
Hi All
How to apply All_packages_to_one after Extreloc?
Any ideas?
Dear developers,
can somebody answer which kitchen we can use for HD mini?????
Yup...EVK will be a good one for that...
Get the EVK kichen... find a stock HD MIni ROM... dump it using the EVK and get cooking!
Interesting.... i just want to say that you need to be carefull cause the HQVGA is an unussual size in new builds hopefully the rollup comes more often
+ Que PPC said:
Interesting.... i just want to say that you need to be carefull cause the HQVGA is an unussual size in new builds hopefully the rollup comes more often
Click to expand...
Click to collapse
com3.2 aka 231xx should come HVGA since thats the normal branch for the phone.
Johan Kraczmar said:
Dear developers,
can somebody answer which kitchen we can use for HD mini?????
Click to expand...
Click to collapse
OSKitchen should be able to dump and rebuild the ROM for that phone without any issue even if it's not in the list as long as you know how to rename the EXT packages to give them the right order (that's an issue you will also have with EVK but on EVK you'll probably have many more unless you use an adapted version for your phone with the right packages already recmodded inside).
BTW I'm working right now on a way to finally apply the DSM building order that all other kitchens seem to ignore to rebuild the latest phone ROMs 100% correctly.
airxtreme said:
OSKitchen should be able to dump and rebuild the ROM for that phone without any issue even if it's not in the list as long as you know how to rename the EXT packages to give them the right order (that's an issue you will also have with EVK but on EVK you'll probably have many more unless you use an adapted version for your phone with the right packages already recmodded inside).
BTW I'm working right now on a way to finally apply the DSM building order that all other kitchens seem to ignore to rebuild the latest phone ROMs 100% correctly.
Click to expand...
Click to collapse
Thank you for answer.
Can you help me with setting in htcrt_devices.ini ????
Johan Kraczmar said:
Thank you for answer.
Can you help me with setting in htcrt_devices.ini ????
Click to expand...
Click to collapse
osKitchen doesn't need that file because it automatically detects the NBH structure trough libNB; that's why I told you it should work even if the device is not on the supported list. As long as platformrebuilder doesn't cause some trouble (EVK is platformrebuilder-based too) oskitchen can work with any ROM as long as it can import and build the format (and NBH of course is supported).
Everything is clear.THX
airxtreme said:
BTW I'm working right now on a way to finally apply the DSM building order that all other kitchens seem to ignore to rebuild the latest phone ROMs 100% correctly.
Click to expand...
Click to collapse
Just a small correction here: Barin's OSBuilder does not ignore that issue. In fact there in a tool in his kitchen to modify packages.sof, so that you can even modify the build order. This is important when adding new packages which have .dsm not in stock roms, to ensure that they are build in the preferred order (ie: tweaks last).
@ OP, if you do use EVK to dump and build, be sure to clean the dump of duplicate files inside modules after dump, which is an issue with EVK's dump process. Also, with EVK (and likely OSKithcne) you need to recmod NTFConfig.dll to get a bootable rom. This is also not an issue with Barin's OSBuilder, which I highly recommend to every chef. I find this kitchen to be a superb tool compared to any kitchen to date.
mmmm interesting kitchen... lets try something new... cause the winmo times are getting bored this days
indagroove said:
Just a small correction here: Barin's OSBuilder does not ignore that issue. In fact there in a tool in his kitchen to modify packages.sof, so that you can even modify the build order. This is important when adding new packages which have .dsm not in stock roms, to ensure that they are build in the preferred order (ie: tweaks last).
Click to expand...
Click to collapse
I've never tried that kitchen however I can tell you that how I've implemented shadow ordering support is pure bliss. For example as you probably know HTC ROMs rely on many virtual packages (Project Default and others) to guarantee the building order and if you delete one of them (some of these packages are completely empty) everything breaks and that the shadow dependencies are often done on localized packages so changing language could also cause havoc.
In my kitchen I normalize all the packages dependencies during import so that all the dependencies on LCID folders and on those virtual folders are gone (so those can be safely deleted), I have a package property tab to set the shadow order of any package (if the DSM is not there it will be created), it has detailed checks for short circuits (infinite dependencies loop), etc. It's really, really well done.
indagroove said:
@ OP, if you do use EVK to dump and build, be sure to clean the dump of duplicate files inside modules after dump, which is an issue with EVK's dump process. Also, with EVK (and likely OSKithcne) you need to recmod NTFConfig.dll to get a bootable rom. This is also not an issue with Barin's OSBuilder, which I highly recommend to every chef. I find this kitchen to be a superb tool compared to any kitchen to date.
Click to expand...
Click to collapse
Well the two kitchens are in two completely different leagues: OSBuilder seems to be aimed to rebuild the ROM as best as possible following the microsoft standards (for example only flat packages, no EXT) while mine is aimed at offering the most complete and easy solution indeed the autoimport, (there is no informations associated to the device names in the import list, the kitchen finds everything out by itself to rebuild the NBH/BIN/TSW for that device), batch multi-language ROMs generation, easily structured UI and also all the warnings to limit user mistakes to minimum, from an easy automatically recmodding of packages that prb dislikes to much crazier extents like checking the Radio/splash files signatures are OK or making sure the user doesn't try to import packages from the wrong folder (like C:\) destroying his filesystem. Just because my kitchen is (sadly) still platformrebuilder-based it doesn't mean it has to be trashed though: as you may know Da_G is rewriting all the tools properly (100% compliant to the original standards) and I'm adapting his LibNB functions to the kitchen as soon as those became available hence the actual ability of dump/rebuild any NBH correctly without even knowing what device it is and hopefully soon internal XIP porting so that the kitchen will be already able (with extreloc for the IMGFS) to build its own ROMs for any device without any of the platformrebuilder limitations.