Jump to content

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


Guest rodrigofd

Recommended Posts

Guest rodrigofd

My intention of this thread is to keep a sole, centralized place to drop everything that can be of use to everyone involved, and in the hope of starting to create a little chefs community, as others did with other devices...

This thread isn't for custom ROMs, but to learn and experiment on the cooking technique. There are already various custom roms hanging around now.

Currently the most 'all-in-one' tool to cook ROMs is latest Pako777's i900 EXECUTOR, which can be found around. If not, you have to deal with multiple tools to handle each particular step in the process.

Some handy tutorials/tools to get you started:

Guide to Flashing ROMs ( by TACCHAN23 ) A very complete place to get started in the I8000 ROMs world

http://www.modaco.com/content/i8000-omnia-...g-rom-on-i8000/

RodrigoFD O2UTIL ( multi-purpose utility for I8000/I8000L/B7610 roms)

http://www.modaco.com/content/i8000-omnia-...lity-for-i8000/

Brief tutorial on how to cook a I8000 ROM

1. I8000 accepts flashing two PDA ROM formats: MST and NB0. The first one includes an image of internal memory, the second doesn't. Both can have an optional language pack with multiple languages.

We don't cook MST roms, but NB0 ones, as structure is simpler. If you want use a MST as a base, you can use my utility to extract MST contents (see links above).

2. At the moment, YOU CAN'T COOK MULTILANGUAGE ROMS. So choose one language at a time to cook your roms.

3. NB0 file: is composed of: 256-bytes header, and the rest is a file you can call 'PDA.OS.NB'... This last one is the OS-IMAGE, and corresponds exactly to the .BIN file that Sorg utility dumps.

4. PDA.OS.NB is 'similar' to other devices .NB files, but has some non-standard formats... E.g. the MSFLASH area has an unconventional format..

It has 3 partitions: boot (0), xip (1) and imgfs (2). All can be extracted and reinserted with utility OSNBTOOL.

In the particular case of IMGFS partition, argument '-acwan' must be specified. That is: OSNBTOOL.EXE -d pda.os.nb 2 imgfs.bin -acwan

5. IMGFS.BIN extracted from PDA.OS.NB, can be dumped with IMGFSTODUMP.EXE, recommended is a modified version from WEISUN. For the inverse, to pack dump into IMGFS.BIN, use tool imgfsfromdump.exe, 'big rom' exe version.. it's a special version that allows big IMGFS files, (not the ones in XDA).

6. If you want to add new modules, or port the WM version, you have to do xip-porting and do rellocation. Supposedly Executor 2.5 does it, if not check WES guide on the matter.

7. Before repacking, you have to edit original PDA.OS.NB in an Hex editor, and expand it so it reaches size 0x1B200000 (in hex). You can just add FFFF values. My O2Util has a command for that.

8 Finally, you recompose NB0 file from the original 256 bytes header + PDA.OS.NB.NEW... And you need an additional step: patch the header.

Open such header in WinHEX editor (look for it in internet).... and look the noted positions (offsets).

In position 0x4 goes the PDA.OS.NB file size.... In Position 0x8 : block count.. Position 0xC : Checksum-32 bit.. All three are 32-bit integers, that is, integer numbers represented by 4 bytes.

To get the byte representation:

Use windows calculator (cientific mode).... input number in decimal , then change to hexadecimal, note such number, brake it in digit pairs, and invert the pairs:

ej:

33292800 (decimal) > convert to hex > 01FC0200 (hex): -> brake to pairs -> 01 FC 02 00 -> invert pairs -> 00 02 FC 01

You have to get 8 digits or letters (4 pairs).. if your number is shorter, add zeros to the left..You have to patch bytes in the header, in that way , with pairs inverted. That is called 'little endian' or LSB encoding.

Note: 'Block count' is the real byte-size of PDA.OS.NB, divided by: 0x1F800, and as for checksum, to calculate it, open PDA.OS.NB (don't include header) in WinHEX, go to menu Tools > Compute hash... > Checksum-32... Note that hex number... AGAIN, invert the pairs, and patch with this value.

9. There you have your NB0 ROM image ready to be flashed by OCTANS (in PDA option). :)

Edited by rodrigofd
Link to comment
Share on other sites

Guest Khuanchai

Reserved.

Example of my current dirty ROM.

Removed:

- Online widget

- Most ringtones

- Help files

- Some pictures

Memory settings:

post-201908-1258591465_thumb.png

I'll try further an "UltraLite" ROM with only WM 6.5 backbone.

Lite TouchFlo 3D ROM IK5

This is for testing only. Don't ask me for more customization. I have no time to make screenshots. Help is welcome.

Brief Spec:

- Base ROM IK5 supplied by secany

- TouchWiz, Main Menu, Cube, help files, most ringtones, some images removed

- TouchFlo 3D 1.3 by chainfire added and set to be default

Download here:

- http://rapidshare.com/files/312502257/PDA.IK5.TF3D.zip.001

- http://rapidshare.com/files/312511066/PDA.IK5.TF3D.zip.002

This is a PDA part only. You can flash just the PDA part or with other parts as needed.

Although I have tested that this ROM is safe. However, flashing ROM has a risk to brick your phone, especially if you have no knowledge. I won't take any responsibility on any damage you may have from flashing my ROM.

Edited by Khuanchai
Link to comment
Share on other sites

Guest rodrigofd
reserved too.......lol. just kidding. i wish i could be more helpful.

You can my friend, actually.... your chinese services can be extremely helpful when getting info from guys like Weisun...

Could you try to contact him??

For example we'll like to know 2 things:

1. how to relocate modules in dump

2. if he knows what do the three bytes at 0x1EA in an OS.NB file, actually serve for.. wes58 found that they were changed by Weisun's osnbtool.exe, and if preserved, we can actually make our english custom roms work....

Thx!

Link to comment
Share on other sites

You can my friend, actually.... your chinese services can be extremely helpful when getting info from guys like Weisun...

Could you try to contact him??

For example we'll like to know 2 things:

1. how to relocate modules in dump

2. if he knows what do the three bytes at 0x1EA in an OS.NB file, actually serve for.. wes58 found that they were changed by Weisun's osnbtool.exe, and if preserved, we can actually make our english custom roms work....

Thx!

i will try, anyway, still havent got reply from G yet. but i'll try my best to get info. my respect to u and khuanchai, take it easy, bro

Link to comment
Share on other sites

Guest Pako777

Guys. And the assemblage variant pda.nb0 only from dump_files will not approach you? Necessarily from packages?

.. very soon will be upload new EXEcutor_2.5.. i hope :)

2. if he knows what do the three bytes at 0x1EA in an OS.NB file, actually serve for..

not 3, but 4 bytes... this = ( length_IMGFS_section*$800 ) :D

Edited by Pako777
Link to comment
Share on other sites

(sorry for my intrusion)

I would like to start to do.... but I cannot due to some misundertanding (for me)

  1. clubic.mli !
    As far as I undertand, this is the file in the hidden partition of our "My Storage".
    I can extract the 512Mo RAW files (with the "pdocread " describe there : Chainfire #40 / OpenGL ES 3D drivers, v1 compatibility layer, [2009-11-18] v0.256
    But after that, I don't know how to extrat anythig from this one ?
    (I've tried to remove some octects seam to be a part of fat (or something like that), rename to "mli", then give eating to i900executor, without big success !)
    Where am I wrong ?

  2. I've tried this (very long title) : i8000 custom ROM guide translated in English, A guide on how to repack PDA to a flashable file by Gigges
    With II1 (thanks I900executor to give me) and II3 (because this is the only one I have in nb0 format).
    But I've got an error with "all_packages_to_one.exe"
    I've read that is because I don't have "SYS" and "OEM" !
    So what you do to have those parts ?
Link to comment
Share on other sites

Guest rodrigofd
(sorry for my intrusion)

I would like to start to do.... but I cannot due to some misundertanding (for me)

  1. clubic.mli !
    As far as I undertand, this is the file in the hidden partition of our "My Storage".
    I can extract the 512Mo RAW files (with the "pdocread " describe there : Chainfire #40 / OpenGL ES 3D drivers, v1 compatibility layer, [2009-11-18] v0.256
    But after that, I don't know how to extrat anythig from this one ?
    (I've tried to remove some octects seam to be a part of fat (or something like that), rename to "mli", then give eating to i900executor, without big success !)
    Where am I wrong ?
  2. I've tried this (very long title) : i8000 custom ROM guide translated in English, A guide on how to repack PDA to a flashable file by Gigges
    With II1 (thanks I900executor to give me) and II3 (because this is the only one I have in nb0 format).
    But I've got an error with "all_packages_to_one.exe"
    I've read that is because I don't have "SYS" and "OEM" !
    So what you do to have those parts ?

1. You are getting it wrong. Yo dump your CUBIC37.MLI, do this: first plug your phone in 'USB Mass Storage (My Storage)' mode, NOT ActiveSync. Then open WinHex (http://www.x-ways.net/winhex/index-e.html), select hidden partition, select CUBIC37.MLI, and save it to your desired folder.

2. Ignore all_packages_to_one.exe error... you already have all files dumped in one place, this tool is useful if you did had files organised in packages, but if you follow Giggles, you don't.

Link to comment
Share on other sites

Guest gertitombo

@rodrigofd

Hi, Thanks for adding me. I'm excellent creating rom's. Unfortunatly not creating kitchens. I will come in to create first a mini rom and after that a updated rom. Thus no samsung software in it.

If the kitchen is done, we could share information how to create roms together. Hopefully this will be soon. My fingers are warm :)

Regards,

GT

Link to comment
Share on other sites

Guest Khuanchai
Guys. And the assemblage variant pda.nb0 only from dump_files will not approach you? Necessarily from packages?

.. very soon will be upload new EXEcutor_2.5.. i hope :)

not 3, but 4 bytes... this = ( length_IMGFS_section*$800 ) :D

That is great, Pako. Please make it.

BTW, do we really need a relocation? Can we just build imgfs from dump without relocation?

Edited by Khuanchai
Link to comment
Share on other sites

Guest rodrigofd
That is great, Pako. Please make it.

Kyhuanchai, could you further explain me what did pako mean? i did not understand what he might me including in his new tool, neither the offset explanation :)

Link to comment
Share on other sites

Guest rodrigofd
you believe that the rooms may be installed from the same device as does the htc diamond with diaming files,

Omnia will be possible in 2?

greetings

akirita, your question was not very clear.... write it in spanish and i'll tell you

Link to comment
Share on other sites

Guest Khuanchai
Kyhuanchai, could you further explain me what did pako mean? i did not understand what he might me including in his new tool, neither the offset explanation :)

I think Pako is going to add a new feature to his i900executer. This will make a final pda.nb0 from the dump for flashing. His tool will do everything in 1pack.bat and 2pack.bat including a modification of the 1EA value. Pako please correct me if this is wrong.

For his explanation of 1EA, he meant that it's a 4-byte HEX that is calculated from imgfs size x something. Hope I undertand correctly.

Link to comment
Share on other sites

Guest rodrigofd
I think Pako is going to add a new feature to his i900executer. This will make a final pda.nb0 from the dump for flashing. His tool will do everything in 1pack.bat and 2pack.bat including a modification of the 1EA value. Pako please correct me if this is wrong.

For his explanation of 1EA, he meant that it's a 4-byte HEX that is calculated from imgfs size x something. Hope I undertand correctly.

Ok, but i don't think 1EA thing is as simple as that... think this: we unpack os.nb file, we modify it (add/remove things), so new imgfs has different data and different size.... with WES method, we patch this bytes with ORIGINAL os.nb values, ... and it actually makes it work ¿¿?? its against common sense, ... if it does represent something imgfs related, we should need to CHANGE it to a new value, other than change it to original value... i fear we might doing something blindly...with unexpected results... (maybe leaving files out of package¿?) .. we should further investigate... or ask Pako to clarify the matter..

Link to comment
Share on other sites

Guest Khuanchai
Ok, but i don't think 1EA thing is as simple as that... think this: we unpack os.nb file, we modify it (add/remove things), so new imgfs has different data and different size.... with WES method, we patch this bytes with ORIGINAL os.nb values, ... and it actually makes it work ¿¿?? its against common sense, ... if it does represent something imgfs related, we should need to CHANGE it to a new value, other than change it to original value... i fear we might doing something blindly...with unexpected results... (maybe leaving files out of package¿?) .. we should further investigate... or ask Pako to clarify the matter..

Agree. Pako - please just replace at 1EA the value "00 55 03 00" and it will work for any imgfs size.

Link to comment
Share on other sites

Guest Khuanchai
Master K! Why programm memory is so small?

I don't know. Maybe some programs are running. What is yours? Someone please post your memory setting here.

Edited by Khuanchai
Link to comment
Share on other sites

Ok, but i don't think 1EA thing is as simple as that... think this: we unpack os.nb file, we modify it (add/remove things), so new imgfs has different data and different size.... with WES method, we patch this bytes with ORIGINAL os.nb values, ... and it actually makes it work ¿¿?? its against common sense, ... if it does represent something imgfs related, we should need to CHANGE it to a new value, other than change it to original value... i fear we might doing something blindly...with unexpected results... (maybe leaving files out of package¿?) .. we should further investigate... or ask Pako to clarify the matter..

But one thing that we are doing (or I was doing) is to keep pda.nb0.os.nb (and this means igmsfs.bin) the same size as original - I filled it with FF bytes to ensure the same size. I had a look at some other original roms and found out that at offset 1EA we have values like this:

C0 55 03 - in chinese rom

C0 27 02 - in modified IJ9 nb0

00 55 03 - in original IJ9

00 55 03 - in original .mst file.

The one thing that I am not sure about what Pako was saying about 4 bytes. I would agree with 4 bytes (dWord) if it was at different offset, aligned to dWord boundary, for example 1E8-1EB (1 dWord) and 1EC-1EF (2nd dWord). I guess it all depends on where the first dWord starts and what is the structure of the imgfs (header - if I can call it so). 

We should probably try to reduce the size of pda.nb0.os.nb and modify the values for size as was in the Chineese tutorial. The language pack would end up at different offset but I think it might work. Any one willing to try it?

Link to comment
Share on other sites

That is great, Pako. Please make it.

BTW, do we really need a relocation? Can we just build imgfs from dump without relocation?

As I understand this, you need to relocate modules to ensure that there are no memory overlaps between modules and gaps as well. Though having gaps is probably not an issue, the only thing you are getting is loosing memory, but having memory overlaps would mean that files are (or will use) the same memory space which will lead to things not working.

So (my theory) is that, if you only remove modules you don't need to do relocation because you are not likely to have memory overlaps, but you are going to have memory gaps. So it would be good idea to do relocation to free more memory so you can add more extra modules.

If you start adding your own modules or try to port different WM version you will definitely need to do relocation. 

Have a look at dump_MemoryMap.txt which is created during dump, you will see what I mean. So if you, for exampe delete MyPhoneLauncher.cpl you will end up with a memory gap of 53247 bytes at memory address 018D0000 - 018DCFFF (line 8 in the file).

How can we make this thread pinned?

dump_MemoryMap.txt

Edited by wes58
Link to comment
Share on other sites

Guest Khuanchai
But one thing that we are doing (or I was doing) is to keep pda.nb0.os.nb (and this means igmsfs.bin) the same size as original - I filled it with FF bytes to ensure the same size. I had a look at some other original roms and found out that at offset 1EA we have values like this:

C0 55 03 - in chinese rom

C0 27 02 - in modified IJ9 nb0

00 55 03 - in original IJ9

00 55 03 - in original .mst file.

The one thing that I am not sure about what Pako was saying about 4 bytes. I would agree with 4 bytes (dWord) if it was at different offset, aligned to dWord boundary, for example 1E8-1EB (1 dWord) and 1EC-1EF (2nd dWord). I guess it all depends on where the first dWord starts and what is the structure of the imgfs (header - if I can call it so). 

We should probably try to reduce the size of pda.nb0.os.nb and modify the values for size as was in the Chineese tutorial. The language pack would end up at different offset but I think it might work. Any one willing to try it?

What is the modified IJ9 nb0? Do you mean the one-language nb0? I think it's probably not important for that one-language nb0 since it won't make a request for language setup.

The size of original pda.nb0.os.nb has to be fixed 1B2000000 in order to make it works with osnbtool. However, I have tried to reduce the size of pda.nb0.os.nb.new by cutting off those FFFFFFFF to minimal and it works. This increases our storage space to >120 MB.

As I understand this, you need to relocate modules to ensure that there are no memory overlaps between modules and gaps as well. Though having gaps is probably not an issue, the only thing you are getting is loosing memory, but having memory overlaps would mean that files are (or will use) the same memory space which will lead to things not working.

So (my theory) is that, if you only remove modules you don't need to do relocation because you are not likely to have memory overlaps, but you are going to have memory gaps. So it would be good idea to do relocation to free more memory so you can add more extra modules.

If you start adding your own modules or try to port different WM version you will definitely need to do relocation.

Have a look at dump_MemoryMap.txt which is created during dump, you will see what I mean. So if you, for exampe delete MyPhoneLauncher.cpl you will end up with a memory gap of 53247 bytes at memory address 018D0000 - 018DCFFF (line 8 in the file).

How can we make this thread pinned?

Thank you for your information. Do you have any good news on building ROM and relocation yet?

Rodrigofd - you said you have successfully compiled the new buildos and relocate tools. Are they ready for testing?

Edited by Khuanchai
Link to comment
Share on other sites

What is the modified IJ9 nb0? Do you mean the one-language nb0? I think it's probably not important for that one-language nb0 since it won't make a request for language setup.

The size of original pda.nb0.os.nb has to be fixed 1B2000000 in order to make it works with osnbtool. However, I have tried to reduce the size of pda.nb0.os.nb.new by cutting off those FFFFFFFF to minimal and it works. This increases our storage space to >120 MB.

modified IJ9 nb0 is what I should have called pda.nb0.os.nb.new. So when you reduced the size of it, I assume that you also changed the values in pda.nb0.pre as was in the Chinese guide?

I didn't think of making the size of original pda.nb0.os.nb to 1B2000000. I just added the FF bytes to the end so it doesn't come up with an error "imgsfs wrong size" in osnbtool and then deleted what I didn't need.

Link to comment
Share on other sites

 

Thank you for your information. Do you have any good news on building ROM and relocation yet?

Rodrigofd - you said you have successfully compiled the new buildos and relocate tools. Are they ready for testing?

Unfortunately I didn't manage to get relocation to work. Buildos worked after I created initflashfiles.dat, and of course you have to dump XIP as well. I think XIP will have to be dumped if we have to use relocation tools.

I was thinking of trying to modify language pack (manually), delete a file or two and see if it work afterwards. I will leave it for the weekend probably.

I wonder if Rodrigofd, who managed to use relocation tool and create a new file, could dump it again and have a look at dump_MemoryMap.txt see if there are any overlaps there. At least we would know that this is a problem why it doesn't work.

Edited by wes58
Link to comment
Share on other sites

Guest Khuanchai
modified IJ9 nb0 is what I should have called pda.nb0.os.nb.new. So when you reduced the size of it, I assume that you also changed the values in pda.nb0.pre as was in the Chinese guide?

I didn't think of making the size of original pda.nb0.os.nb to 1B2000000. I just added the FF bytes to the end so it doesn't come up with an error "imgsfs wrong size" in osnbtool and then deleted what I didn't need.

Yes, we have to change file size, sectors, and checksum in pda.nb0.pre.

So what size you suggest without osnbtool error? Anyway, I don't think we have any advantage reducing size of original pda.nb0.os.nb. Modification of pda.nb0.os.nb.new is more critical.

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.