675 replies to this topic

[wes58]

Khuanchai, on Nov 19 2009, 00:55, said:

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?

Attached Files

•  dump_MemoryMap.txt   31.45K   115 downloads

Edited by wes58, 19 November 2009 - 03:08 AM.

[Khuanchai]

wes58, on Nov 19 2009, 09:47, said:

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.

wes58, on Nov 19 2009, 09:57, said:

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, 19 November 2009 - 04:12 AM.

[wes58]

Khuanchai, on Nov 19 2009, 03:49, said:

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.

[wes58]

 

Khuanchai, on Nov 19 2009, 03:49, said:

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, 19 November 2009 - 04:31 AM.

[Khuanchai]

wes58, on Nov 19 2009, 11:11, said:

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.

[rodrigofd]

Khuanchai, on Nov 19 2009, 00:49, said:

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.


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?

One comment: it doesn't matter for 'langpack' section, if .os.nb file grows or shrinks... sections inside NB0 file are delimited by size indicator in each section header (first 0x100 bytes) ...

so NB0 format is:
| 0x100 byte header 1 | variable size section 1 | 0x100 header 2 | variable size section 2 | ...

Up to now, we only know NB0 files to have one first mandatory section : OS.NB OS image (which includes three partitions: boot, xip and imgfs) , and optional second section, langpack, which is a standard disk image (can be mounted as a disk, e.g. with virtual dvd-rom drive)

And NB0 section headers have standard format :
offset 0x4 has section size;
offset 0x8 has block count (where each block is of 0x1F800 size)
offset 0xC has a 32-bit, simple modular checksum
rest are random strings, but in the case of multilanguage roms, one of those is a multi-string that details included language packs...(we should mess with rest of header anyway..)

So NB0 format is no longer an issue at all, the source of all problems is the OS.NB file, which, apparently , current Weisun' OSNBTOOL has serious trouble both in decompressing (why do we have to resize original file?) .. and more buggy, recompressing (it modifies some OS.NB values that cause unbootable ROMs... E.G. the famous 0x1EA dword pointed out by WES)

----

I have JUST finished writing a simplified tool that unpacks Omnia2 NB0 file, and buils a dump... and the other way round: pack a dump, into a flashable NB0 file, doing all known adjustments, like resizing, checksums, 0x1EA patching and so.

I am also re-coding PKGTOOL and BUILDOS tools, originally created by BEPE, to fit our own needs.
However, the MAJOR remaining issue we have is a proper module rellocation tool....

Wes you're right in your assumptions, removing modules would only create memory holes, but shouldn't affect rom stability, of course leaving less ram.
We can ignore it for this first attemps, but it's definitely not a good option!!! official roms already are awful short on memory.

Without reloc, any module addition will certainly break down ROM... maybe, for testing, converting such module to a standard file would make it work, but again, not in a permanent choice....


Do any of you have precise technical knowledge of how module relocation works? So maybe i can write our own tool...

[wes58]

Khuanchai, on Nov 19 2009, 04:39, said:

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.

Sorry I didn't write it correctly. I meant I reduce the size of the pda.nb0.os.nb.new - the size is based on the size of the original one.


I don't use a specific size, you can double the size of the original one. You know the size of original so you can easily cut the new pda.nb0.os.nb.new back to this size - or cut even more.

But if the size that you are using, based on chinese guide, works ok you don't have to worry about it.

What osnbtool does it creates a new pda.nb0.os.nb.new based on the original one and inserts the new imgfs.bin in this file. If the file size of the new imgfs is larger than pda.nb0.os.nb than it gives you an error. I guess this tool was created for smaller size roms - my theory! The same as G'reloc, because it comes with integer overflow errors etc. Which means that values are limited to a maximum value that integer can hold.

[KSTAN]

Hi,

I have tried with JC ROM, with the cubic37.mli from my phone.

No changes done at the moment.

Funny thing is that I need to subtract FF00 from the checksum, then I can flash successfully. Else I get the PDA checksum failed.

I have check the checksum value in .pre file and the extracted original nb.os file, found the checksum to have a difference of FF00.

[wes58]

 

rodrigofd, on Nov 19 2009, 04:40, said:

So NB0 format is no longer an issue at all, the source of all problems is the OS.NB file, which, apparently , current Weisun' OSNBTOOL has serious trouble both in decompressing (why do we have to resize original file?) .. and more buggy, recompressing (it modifies some OS.NB values that cause unbootable ROMs... E.G. the famous 0x1EA dword pointed out by WES)

----

Wes you're right in your assumptions, removing modules would only create memory holes, but shouldn't affect rom stability, of course leaving less ram.
We can ignore it for this first attemps, but it's definitely not a good option!!! official roms already are awful short on memory.


Do any of you have precise technical knowledge of how module relocation works? So maybe i can write our own tool...

1. I am not sure it the problem is osnbtool because we managed to rebuild Chinese rom with only one language without a problem. I think it may something to do with language pack. You remember how the screen goes blank during language setup. And I think that's why it got stuck on WM splash screen.

We would probably need someone speaking Chinese to contact Weisun on PDAclan forum. Maybe he could help/explain us?

2. We definitely need relocation tool if we want to replace for example some Samsung files from newer roms (we can dump mst file to get it) or if we want to port newer version of WM 6.5.1, or even adding some other applications.


3. Unfortunately I don't know much how module relocation works. I probably using dump_MemoryMap.txt. You can see in the dump subdirectories files like: imageinfo.bin, imageinfo.txt and S000, S001. That's all I know, I've never needed to look for more information. You could dump again (what I suggested in the previous post) the file that you created with relocation and compare the values in dump_MemoryMap.txt. And if you find any differences from original dump, check the files (imageinfo.bin ... S000, S001) in the subdirectory corresponding to the file name. So for example if you find something different for the file MyPhoneLauncher.cpl in dump_MemoryMap.txt you check subdirectory MyPhoneLauncher.cpl. It's a lot of work.

[wes58]

KSTAN, on Nov 19 2009, 05:21, said:

Hi,

I have tried with JC ROM, with the cubic37.mli from my phone.

No changes done at the moment.

Funny thing is that I need to subtract FF00 from the checksum, then I can flash successfully. Else I get the PDA checksum failed.

I have check the checksum value in .pre file and the extracted original nb.os file, found the checksum to have a difference of FF00.

Do you mean that the checksum value of the original os.nb file is not equal to the checksum value that is in .pre file? That's strange. If that happened, I would say the size of the original os.nb is not correct, but what is more interesting that you have to subtract exactly FF00.

[wes58]

I had a quick look at the relocation. The following are my findings based on three files:


Data from dump_MemoryMap.txt mscoree2_0.dll:

01800000 - 018C3FFF ( 802815 bytes): mscoree2_0.dll -> End memory = Start + size

Data from imageinfo.txt mscoree2_0.dll:

e32_vbase:             01800000 -> start memory. This may change
e32_vsize:             000C4000 -> This won't change. 802815 in hex 3FFFF +1 = C4000 . End memory = e32_vbase + e32_vsize

Start memory for next module MyPhoneLauncher.cpl is 18D000. 

So for some modules next module memory starts at end memory for previous module + 10000 and last 4 digits are zeroed. Why like this? Maybe some other values for size are added as well. For some other module it is a little bit different. I think, the only change that has to be made is e32_vbase value in imageinfo bin and txt. What is interesting for mscoree2_0.dll, that there are two entries for it in dump_memoryMap.txt!

You have to read imageinfo.bin in all directories and check the values. Have a look and see if it makes any sense. That's the first quick look at it, not sure if correct.

[wes58]

I tried to use WMreloc and got errors. When I investigated it I saw that WMreloc fails when one of S000, S001.... has size equal to 0. Those files are created during the dump. For example in directory voicebooster.dll I had S002 size = 0. 

Has anybody had this problem?

To fix it I used Reversmode.exe (found it on xda-developers) which converts the .dll or .exe files into S000, S001.... When I did it on voicebooster.dll file it created all Sxx files with sizes greater than 0. So now, WMreloc should work on this file. Unfortunately I found there are more than just one file with this problem. It looks like it is an issue with imgfstodumpxxx.exe. I know that there are different versions of this file. I used one from the I8000tools. 

Edit:
I managed to fix it with reversmode.exe because there were only 2 files that had size 0.

Edited by wes58, 19 November 2009 - 10:29 AM.

[rodrigofd]

wes58, on Nov 19 2009, 05:42, said:

I tried to use WMreloc and got errors. When I investigated it I saw that WMreloc fails when one of S000, S001.... has size equal to 0. Those files are created during the dump. For example in directory voicebooster.dll I had S002 size = 0.

Has anybody had this problem?

To fix it I used Reversmode.exe (found it on xda-developers) which converts the .dll or .exe files into S000, S001.... When I did it on voicebooster.dll file it created all Sxx files with sizes greater than 0. So now, WMreloc should work on this file. Unfortunately I found there are more than just one file with this problem. It looks like it is an issue with imgfstodumpxxx.exe. I know that there are different versions of this file. I used one from the I8000tools.

Edit:
I managed to fix it with reversmode.exe because there were only 2 files that had size 0.

Hmm.. you used reversmode ? But where did you get the dll file to break into sections from ? all imgfstodump, when they are extracting modules, form them in a way of a folder: imageinfo.bin, imageinto.txt and S000, S001, ... etc...

Btw, why do Giggles used the imgfstodump 'xxx' version ? which is the difference in this one? is this the so called 'imgfs big rom 1024mb' version ?
Maybe you are right inthat dump is wrongly generated...

[wes58]

rodrigofd, on Nov 19 2009, 12:14, said:

Hmm.. you used reversmode ? But where did you get the dll file to break into sections from ? all imgfstodump, when they are extracting modules, form them in a way of a folder: imageinfo.bin, imageinto.txt and S000, S001, ... etc...

Btw, why do Giggles used the imgfstodump 'xxx' version ? which is the difference in this one? is this the so called 'imgfs big rom 1024mb' version ?
Maybe you are right inthat dump is wrongly generated...

You get dll files when you dump files to packages OEM, SYS. Anyway, I tried to flash with modified rom and had the same problem that we had before with the screen going blank on language setup screen (with progress bar).


To check how relocation worked I dumped this modified rom again and had a look at dump_MemoryMap.txt. In there you can see that memory addresses are the way I expected, that is the next module starts at the next address after the previous module. The problem I see is that we have a lot more modules in the new file. I wonder if some of them are from XIP when I had to dump it for buildos to work? I have attached those two files if you want to have a look. I've had enough fun for today. Have fun.

As far as, whether the dump is generated correctly or not. I guess it works ok when we flash without dumping into packages. 

Attached Files

•  new_dump_MemoryMap.txt   33.16K   69 downloads
•  org_dump_MemoryMap.txt   31.45K   75 downloads

[akirita]

rodrigofd, on Nov 19 2009, 02:05, said:

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

Hello, sorry for the bad English, but I translate with google, what I was saying is that if the omnia 2 may be installed in the rooms as diamond, from the device itself without computer.
Thanks for your understanding.
greetings


Hola, perdona por el ingles tan malo, pero lo traduzco con google,lo que decia es que si en el omnia 2 se podran instalar las rooms como en el diamond,desde el propio dispositivo sin necesidad de ordenador.
gracias por tu comprension.
saludos

Edited by akirita, 19 November 2009 - 03:49 PM.

[rodrigofd]

akirita, on Nov 19 2009, 11:28, said:

Hola, perdon por el ingles tan malo, pero lo traduzco con google,lo que decia es que si en el omnia 2 se podran instalar las rooms como en el diamond,desde el propio dispositivo sin necesidad de ordenado.
gracias por tu comprension.
saludos

No, unfortunately there is no known method to fire the ROM flashing directly from device, like with HTC phones, that you could leave ROM image in the memory card, and activate the flashing program by a special procedure... maybe there is an undocumented way of doing it, by only Samsung guys w'd know...


No, lamentablemente no se conoce un metodo para disparar el flasheo directamente en el dispositivo, como enlos HTC que se dejaba el ROM en la tarjeta de memoria, y se disparaba el programa flasheador... tal vez existe una forma oculta de hacerlo, pero habría que preguntarle a Samsung....

[akirita]

rodrigofd, on Nov 19 2009, 16:43, said:

No, unfortunately there is no known method to fire the ROM flashing directly from device, like with HTC phones, that you could leave ROM image in the memory card, and activate the flashing program by a special procedure... maybe there is an undocumented way of doing it, by only Samsung guys w'd know...


No, lamentablemente no se conoce un metodo para disparar el flasheo directamente en el dispositivo, como enlos HTC que se dejaba el ROM en la tarjeta de memoria, y se disparaba el programa flasheador... tal vez existe una forma oculta de hacerlo, pero habría que preguntarle a Samsung....

Ok thank you very much and sorry for the inconvenience

[Khuanchai]

rodrigofd, on Nov 19 2009, 22:43, said:

No, unfortunately there is no known method to fire the ROM flashing directly from device, like with HTC phones, that you could leave ROM image in the memory card, and activate the flashing program by a special procedure... maybe there is an undocumented way of doing it, by only Samsung guys w'd know...
No, lamentablemente no se conoce un metodo para disparar el flasheo directamente en el dispositivo, como enlos HTC que se dejaba el ROM en la tarjeta de memoria, y se disparaba el programa flasheador... tal vez existe una forma oculta de hacerlo, pero habría que preguntarle a Samsung....

In fact, an internal flasher does exist in the i8000 ROM. We can trigger it by language change command and it will flash the device from the hidden cubic37.mli and the language selected. I believe it's possible to do this if you can replace with a new cubic37.mli and trigger the internal flasher. Just my hyposthesis.

[Khuanchai]

wes58, on Nov 19 2009, 19:44, said:

You get dll files when you dump files to packages OEM, SYS. Anyway, I tried to flash with modified rom and had the same problem that we had before with the screen going blank on language setup screen (with progress bar).
To check how relocation worked I dumped this modified rom again and had a look at dump_MemoryMap.txt. In there you can see that memory addresses are the way I expected, that is the next module starts at the next address after the previous module. The problem I see is that we have a lot more modules in the new file. I wonder if some of them are from XIP when I had to dump it for buildos to work? I have attached those two files if you want to have a look. I've had enough fun for today. Have fun.

As far as, whether the dump is generated correctly or not. I guess it works ok when we flash without dumping into packages. 

That's my experience too. I tried to buildos from packages even without modification. After flash, it went error on language setup screen even I had corrected the 1EA value. It doesn't make sense if we are thinking that this value is for multilanguage setup. Do you have any idea why it happens with buildos from packages but not from direct dump?

[Khuanchai]

KSTAN, on Nov 19 2009, 12:21, said:

Hi,

I have tried with JC ROM, with the cubic37.mli from my phone.

No changes done at the moment.

Funny thing is that I need to subtract FF00 from the checksum, then I can flash successfully. Else I get the PDA checksum failed.

I have check the checksum value in .pre file and the extracted original nb.os file, found the checksum to have a difference of FF00.

Off-topic: How is your lost "my storage" now? Did they change the mainboard to correct this?