[REF] Cooking info, kitchen, tools, etc ....

[Guest wes58]

Hey Wes, i was looking at your .VM comparison..

If i am correct , this values correspodn to memory slots. 6.1 has 2 addresses that correspond to Slot 0 and Slot 1 , which are where you can map modules to .

6.5 added the ability to map modules to two additional memory slots , 61 and 62, which have much higher address values. GRELOC is not 6.5 compatible and hence hasnt got the ability to map slots 61 and 62. actually , because of this two additional memory addresses in .VM, might be that it fails with 'overflow' (slots 61 62 have so much high address that exceedes int32 max size)...

Yes, I know what you mean. But G'reloc won't work because the structure of imageinfo.bin in .VM is different - it looks at different offsets as well.

But what I noticed on my WMReloc log that I don't have addresses at 03E0 0000 or higher. So what is WMReloc doing? Could you check on your logs.

Edit:

I've just created full log files (information from imageinfo.bin files) from the dump folder before and after running WMreloc. The data is for e32_vbase and all o32[x].o32_realaddr addresses. Hopefully I didn't make mistakes. You can have a look at what WMreloc does with the addresses, it doesn't change all addresses - if you have some spare time. I also attached addresses used by XIP modules.

dump_log_org.txt

dump_log_reloc.txt

XIP_log.txt

Edited December 4, 2009 by wes58

[Guest Khuanchai]

Yes, I know what you mean. But G'reloc won't work because the structure of imageinfo.bin in .VM is different - it looks at different offsets as well.

But what I noticed on my WMReloc log that I don't have addresses at 03E0 0000 or higher. So what is WMReloc doing? Could you check on your logs.

Edit:

I've just created full log files (information from imageinfo.bin files) from the dump folder before and after running WMreloc. The data is for e32_vbase and all o32[x].o32_realaddr addresses. Hopefully I didn't make mistakes. You can have a look at what WMreloc does with the addresses, it doesn't change all addresses - if you have some spare time. I also attached addresses used by XIP modules.

I'm confused now. If RFD can buildos from packages and make a flashable ROM, why we still have to do the relocation thing?

I still have a difficult time to finish the cooking. After we modify SYS and OEM, just run the buildos and it will pack modules/files from SYS, OEM, and ROM\XIP folders, right? It will give us the imgfs.bin the same way we run the command imgfsfromdump, is this correct? We then run osnbtool to inject the new imgfs to the original os.nb and add the header to make the nb0 file. Please correct if my steps are wrong.

If we have a proper relocate tool, where in the steps that we have to run it?

[Guest rodrigofd]

I'm confused now. If RFD can buildos from packages and make a flashable ROM, why we still have to do the relocation thing?

I still have a difficult time to finish the cooking. After we modify SYS and OEM, just run the buildos and it will pack modules/files from SYS, OEM, and ROM\XIP folders, right? It will give us the imgfs.bin the same way we run the command imgfsfromdump, is this correct? We then run osnbtool to inject the new imgfs to the original os.nb and add the header to make the nb0 file. Please correct if my steps are wrong.

If we have a proper relocate tool, where in the steps that we have to run it?

BuildOS just merges all packages from SYS and OEM into one whole 'dump' directory, with all files and modules ... it also combines all initflashfiles files into a single initflashfiles.dat..., and more importantly, rebuilds registry from RGU files, into one single registry (hive)... thats why it needs XIP files, because xip files include some registry settings, that you need for buildos to rebuild registry. Buildos doesnt' construct imgfs.bin, just builds the dump dir.... then you have to run imgfsfromdump.exe (the version that Gigges uses from Weisun) .. that takes all dump dir contents, to rebuild an IMGFS.BIN using another IMGFS.BIN as template.... which in turn you inject into os.nb using osnbtool, then sum up header to form NB0 and flash :D

If you include modules taken from other places (for example another WM build kitchen) and specially if you change XIP , then rellocation is necessary ... because new modules might overlap with existing ones....

[Guest wes58]

I'm confused now. If RFD can buildos from packages and make a flashable ROM, why we still have to do the relocation thing?

I still have a difficult time to finish the cooking. After we modify SYS and OEM, just run the buildos and it will pack modules/files from SYS, OEM, and ROM\XIP folders, right? It will give us the imgfs.bin the same way we run the command imgfsfromdump, is this correct? We then run osnbtool to inject the new imgfs to the original os.nb and add the header to make the nb0 file. Please correct if my steps are wrong.

If we have a proper relocate tool, where in the steps that we have to run it?

You would need to relocate modules if you want to port newer version of operating system. The files (file sections) of the new OS won't be located at the same virtual memory addresses as existing ones. Also the size of the files may be different so they may have take more memory space. They may also (will) conflict with the current VM addresses occupied by Samsung drivers etc. You would also have to relocate some modules in XIP because of the same reason - there are some Samsung module there as well.

If you are using the same version of OS and only remove and add packages you don't really have to worry about it, because added packages are not allocated permanently to specific address in virtual memory. If you look inside the folders of those packages you won't find (I hope I am right) any file sections (like S000, S001 etc.) 

Edit:

Rodrigo, It looks like we were writing an answer at the same time. I don't know if you find those logs that I posted useful. You can import the files to excel and write simple macro that would only show you the lines that are different. I can add another line in the logs with vsizes for each file section this would probably make more sense to understand.

Edited December 5, 2009 by wes58

[Guest Khuanchai]

BuildOS just merges all packages from SYS and OEM into one whole 'dump' directory, with all files and modules ... it also combines all initflashfiles files into a single initflashfiles.dat..., and more importantly, rebuilds registry from RGU files, into one single registry (hive)... thats why it needs XIP files, because xip files include some registry settings, that you need for buildos to rebuild registry. Buildos doesnt' construct imgfs.bin, just builds the dump dir.... then you have to run imgfsfromdump.exe (the version that Gigges uses from Weisun) .. that takes all dump dir contents, to rebuild an IMGFS.BIN using another IMGFS.BIN as template.... which in turn you inject into os.nb using osnbtool, then sum up header to form NB0 and flash :D

If you include modules taken from other places (for example another WM build kitchen) and specially if you change XIP , then rellocation is necessary ... because new modules might overlap with existing ones....

Thanks, will try that. Looking at your ultralite ROM, some modules (for ex, those flash modules) were replaced with files. Why relocation is not needed?

[Guest touchprogeek]

Hey all,

I don't want to distract from your cooking, just want to ask the general forum if anyone knows how to dump the CSC and PHONE sections of the ROM, especially for the I8000L. Anyone have a mini program like Sorg used earlier in the thread to help dump the PDA portion of the ROM or even basic instructions would be welcome. Thanks again!

[Guest rodrigofd]

Hey all,

I don't want to distract from your cooking, just want to ask the general forum if anyone knows how to dump the CSC and PHONE sections of the ROM, especially for the I8000L. Anyone have a mini program like Sorg used earlier in the thread to help dump the PDA portion of the ROM or even basic instructions would be welcome. Thanks again!

Hi, no one knows how to do that for the time being... not even Sorg, i asked him already...

[Guest frankcilo]

Where can I download the latest ROM (L1)? I will try it (if multiple languages)! Or should wait for that kitchen? Does anyone know when it comes out? thanks

[Guest Khuanchai]

You would need to relocate modules if you want to port newer version of operating system. The files (file sections) of the new OS won't be located at the same virtual memory addresses as existing ones. Also the size of the files may be different so they may have take more memory space. They may also (will) conflict with the current VM addresses occupied by Samsung drivers etc. You would also have to relocate some modules in XIP because of the same reason - there are some Samsung module there as well.

If you are using the same version of OS and only remove and add packages you don't really have to worry about it, because added packages are not allocated permanently to specific address in virtual memory. If you look inside the folders of those packages you won't find (I hope I am right) any file sections (like S000, S001 etc.) 

Edit:

Rodrigo, It looks like we were writing an answer at the same time. I don't know if you find those logs that I posted useful. You can import the files to excel and write simple macro that would only show you the lines that are different. I can add another line in the logs with vsizes for each file section this would probably make more sense to understand.

Hi wes and RFD,

Finally I can buildos and pack a flashable ROM. Thanks to both for help. Next step is how to relocate the ROM. I have no idea at all just leave to you guys. :D

[Guest wes58]

Rodrigo,

Just in case you are still looking at relocation problem, here is some info I found out looking at imageinfo.bin files in .ROM and .VM folders:

Content of imageinfo.bin in .ROM an .VM folders in Original dump from K5 Rom

offset .ROM ------- .VM

@00 01740000 01F70000

@04 02021000 03DA0000

@08 7A000000 7A000000

@0C 7B281000 7C000000

@10 00000003 88000000

@14 01740000 00000001

@18 01750000

@1C 01D00000

@20 01F70000

@24 01FE0000

@28 02000000

values at offset 04

.ROM 01740000 last address used in imgfs - msim.dll 01740000

.VM   01F70000 address below this value (-1000hex, -4096) used in imgfs - AccelSensor.dll 01F6F000

values at offset 08

.ROM 02021000  last address used in imgfs - voicedll.dll 02021000

.VM 03DA0000   address below this value (-1000hex, -4096) used in imgfs - AccelSensor.dll 03D9F000

values at offset 0C

.ROM 7B281000  last address used in imgfs - msim.dll 7B281000 - msim.dll 7B281000

.VM 7C000000   address below this value (- 1000hex, 4096) used in imgfs - riched20.dll 7BFFF000

content of imageinfo.bin in .ROM an .VM folders in Relocated dump from K5 Rom

offset .ROM ------- .VM

@00 006E0000 01F70000

@04 02021000 03DA0000

@08 7A000000 7A000000

@0C 01DC0000 7C000000

@10 01F70000 88000000

@14 01FB0000 00000001

@18 01750000

@1C 01D00000

@20 01F70000

@24 01FE0000

@28 02000000

Address ranges used by XIP files - 01FB0000-01FFF000, 03DEE000-03FFF000, 80300000-80756000

After relocation with WMReloc:

I am not sure how those values are used in the rom but:

At offset 10 in .ROM imageinfo.bin, in relocated rom the value is 01F70000 - before was 00000003. I am not sure what this value represents but the value after relocation doesn't seem right.

At offset 0C in .ROM imageinfo.bin (in relocated rom) the value is 01DC0000 - before was 7B281000. Note that value 01DC0000 is in between values used at offest 04 03DA0000-02021000. I think something may be not right here as well.

All files from original rom were relocated from range 7C000000-7B281000 to lower memory addresses.

So the questions are:

1. Is value at offset 10 in relocated rom correct? We could try to change it back to 00000003 as in original rom.

2. Values at offset 0C. How to fix them? Could it be the same as .VM at offset 0C - if it means the last address used it may work. I may try to change those values and see what happens.

3. Why does WMreloc relocate all files from addresses 7xxxxxxx?

Edited December 6, 2009 by wes58

[Guest jermx]

@RFD :

Mind releasing your kitchen since you released custom ROM already ? Thanks

[Guest Ganhiru]

@RFD :

Mind releasing your kitchen since you released custom ROM already ? Thanks

I was thinking of asking the same thing. I'm intending to build a custom Dutch rom.

After looking trough all the attachments of all the posts, I'm not quite sure i have a complete kitchen, so 1 archive with all the files would be appreciated.

Edited December 7, 2009 by Ganhiru

[Guest rodrigofd]

I was thinking of asking the same thing. I'm intending to build a custom Dutch rom.

After looking trough all the attachments of all the posts, I'm not quite sure i have a complete kitchen, so 1 archive with all the files would be appreciated.

Hi,

currently i use a set of tools and files i made in the rush, and are all kind of tied to my pc :D... didnt have time to pack it properly because of being dedicated to cooking..

when i can , ill do it promise

[Guest Ganhiru]

Hi,

currently i use a set of tools and files i made in the rush, and are all kind of tied to my pc :D... didnt have time to pack it properly because of being dedicated to cooking..

when i can , ill do it promise

That is more than enough for me, just remember to make backups ;-) in case Murphy strikes.

[Guest anryl]

Hi,

currently i use a set of tools and files i made in the rush, and are all kind of tied to my pc :( ... didnt have time to pack it properly because of being dedicated to cooking..

when i can , ill do it promise

thanx for the promise :D it might actualy be usefull for imate rom coocking as we have there a crc check problem with osnbtools it is packed in mbn and by repacking it wont flash as per some checks made by bootloader so hope to see u tools soon .

Keep up the good work.

[Guest Ganhiru]

I've wrote tiny utility to dump ROM (in attachment)

Insert microSD card, copy dskdump to device and run it.

It will dump whole ROM (need several minutes) to \storage card\rom_dump.bin file.

It will show message box as it finished.

I would Like to have the application dump to \Geheugenkaart\rom_dump.bin , how can I adapt the progam to do that? I'd like the source or a modified version of the app.

what you could do is read the destination from a file, though that might add a lot of code. I think that if people can go and build a rom in their language they would be eager to do so.

Ok, Started Hex editor, should have got it. Made it \Mijn Opslag\Rrom_dump.bin ( :D )

Seems to work, got the file :( . So other languages are simple enough.

dskdump_mijnopslag.exe

Edited December 8, 2009 by Ganhiru

[Guest tacchan23]

I was reading some guides about cooking in the i900 forum just to have a vague idea what the cooking process involves^^

Anybody could link me any info or noob-guide about SYS and OEM? (tips/rules for removing/adding applications/registry, etc)

Thanks

[Guest Tylwith]

I was reading some guides about cooking in the i900 forum just to have a vague idea what the cooking process involves^^

Anybody could link me any info or noob-guide about SYS and OEM? (tips/rules for removing/adding applications/registry, etc)

Thanks

cooking really depends on your kitchen.

but you can use this link it's for xperia but the chief explain a lot of detailled things

http://forum.xda-developers.com/showthread.php?t=508293

[Guest Ganhiru]

I managed to get making a NB0 file from my Dumped Rom Right. And Flashed it back to my device, unaltered of course and everything seems allright, language is Dutch like I dumped it. I had to add EE EE EE EE at the end of the Header, and I made it 256 Bytes Long, like the image Wes58 posted.

Now ;) I'll need to do now, is expand my kitchen ;-) just a Hex Editor is a bit empty.

If some one wants the nb0 file, I'll be able to upload it.

In the time until a complete i8000 Kitchen is released I'll poke my nose in that XPERIA X1 cooking guide.

I don't mind tackling an as is release of whatever you guy's call a kitchen right now ;) , If you don't want a public release I'll be happy to accept a PM or something.

Well, I'll keep following your progress and I hope I can release a nice custom Dutch Rom in the Future.

[Guest serverxeon]

can anyone help me.

i got the rom_dump.bin from sorg's utility.

how do i extract the .nb0 file from the.bin file using i900 extractor? thanks

[Guest rodrigofd]

can anyone help me.

i got the rom_dump.bin from sorg's utility.

how do i extract the .nb0 file from the.bin file using i900 extractor? thanks

Hi, you are doing it wrong. i900 extractor servers to unpack a 'cubic37.mli', which can be obtained from the hidden partition of the 'my storage' flash memory.

If you start off with a binary dump (rom_dump.bin), you don't 'extract the nb0', actually the nb0 will be formed by THAT rom_dump.bin plus a header. Check my first post for more details.

[Guest tacchan23]

Hi, you are doing it wrong. i900 extractor servers to unpack a 'cubic37.mli', which can be obtained from the hidden partition of the 'my storage' flash memory.

If you start off with a binary dump (rom_dump.bin), you don't 'extract the nb0', actually the nb0 will be formed by THAT rom_dump.bin plus a header. Check my first post for more details.

After reading this post from Khuanchai

My steps:

1. Use sorg's utility to dump English ROM.bin from i8000

2. Use i900executor to dump ROM to SYS, OEM, XIP

3. Cook SYS and OEM as needed

4. Use i900executor to assembly PDA from packages

5. After buildos, it got error on G'reloc but I just close it

6. When it created the os.nb.new, I copy it to another place before it's deleted

7. Combine the i8000 header with this os.nb.new to be a new nb0 file.

Anybody can explain or post some link of any info about point number 3? Cook SYS and OEM as needed

I have zero experience but I'm interested in trying to learn at least:)

[Guest serverxeon]

yea, im same as tachaan. got SYS XIP and OEM, not sure what to do next.

can anyone help me on how to remove unwanted apps? so that i can rebuild a cleaner rom myself.

[Guest wes58]

yea, im same as tachaan. got SYS XIP and OEM, not sure what to do next.

can anyone help me on how to remove unwanted apps? so that i can rebuild a cleaner rom myself.

It is just trial and error. You have to find application that you want to delete, and try to find all other files that relate to this application. You have to search for all references in other files, registry etc and try to remove entries in those files as well. 

To start with you need some tools. For me it is hex editor (WinHex) and text editor (I use UltraEdit). One good thing about UltraEdit is that you can search for any references in the whole directory (using 'Find in Files' menu option). This saves you a lot of time. You can also do a Unicode search.

For example if you want to delete Podcast. You have to find podcast.exe which is in the OEM\Oemapps\ folder. Then you look for some other files that relate to this application. In most cases they will have similar name, or part of the name. But not always. So for podcast you will also find a shortcut, podcast.png, PodcastEngine.lib etc. If you don't delete all files it won't hurt but you are not gaining all free space that you might get. 

Then you need to search for podcast entries in some other files. You will find it in, for example, mainmenu.db, some registry files (.rgu) and so on. You have to be careful when you change those files. You have to look at the format, some of them are unicode. You have to ensure that they are saved without changing the format/type of the files.  

After you delete all the files from the folder you have to re-build .dsm file (There is always one in the folder). It will remove all references in .dsm file to the files that you deleted.  To do this you can use BuildDsm.exe. If you don't have it, google it and you will find it.

Keep a track of what you are changing so next time you do it, you know what you can find where.

And that's it. The more you try it (and read on forums) the more you learn. Hope that this will help.

[Guest monyozt]

@wes58

bro will you release your custom ROM for us?