Jump to content

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


Guest rodrigofd

Recommended Posts

Guest rodrigofd
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...

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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. :)

Link to comment
Share on other sites

 

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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
Link to comment
Share on other sites

Guest rodrigofd
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...

Link to comment
Share on other sites

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. 

new_dump_MemoryMap.txt

org_dump_MemoryMap.txt

Link to comment
Share on other sites

Guest akirita
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
Link to comment
Share on other sites

Guest rodrigofd
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....

Link to comment
Share on other sites

Guest akirita
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

Link to comment
Share on other sites

Guest Khuanchai
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.

:)

Link to comment
Share on other sites

Guest Khuanchai
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?

Link to comment
Share on other sites

Guest Khuanchai
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?

Link to comment
Share on other sites

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

Some comments:

- What KSTAN says about checksum, im 100% sure its because he's not calculating the checksum value in the same algorythm as flasher program..

- The only thing i actually need for a full basic kitchen now, is a working module relocation tool.

I wrote a NB0 utility, that does all the unpacking of NB0 file, resizing to support osnbtool, repack of nb0, nb0 headers update (checksum etc).

I also rewrote pkgtool and buildOS, they seem to work fine, i just reflashed from a packeted- dump, and it goes up to the 'calibrate' initial screen... when i pinch in touchscreen, it reboots.... so i'm just almost there...

Link to comment
Share on other sites

Guest Khuanchai
Some comments:

- What KSTAN says about checksum, im 100% sure its because he's not calculating the checksum value in the same algorythm as flasher program..

- The only thing i actually need for a full basic kitchen now, is a working module relocation tool.

I wrote a NB0 utility, that does all the unpacking of NB0 file, resizing to support osnbtool, repack of nb0, nb0 headers update (checksum etc).

I also rewrote pkgtool and buildOS, they seem to work fine, i just reflashed from a packeted- dump, and it goes up to the 'calibrate' initial screen... when i pinch in touchscreen, it reboots.... so i'm just almost there...

You mean that you can now buildOS from sys, oem, xip and flash without lang setup error? Did you also change the 1EA value? Could you give me a try with your new buildOS?

Link to comment
Share on other sites

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?

Something is strange with this language pack setup in multilanguage roms.

I did another test today to see relocation is going to work without buildos. Here is what I did:

1. Dump files from IJ9 nb0

2. Run WMReloc.exe on the dump folder. I didn't make any changes to the dump folder, just had to fix two files with some sections equal to 0 for WMReloc.exe to work (they were R2VS_ARM_WM6_PRO_Driver.dll and VoiceBooster.dll)

3. Pack Rom

So I didn't dump to packages or use buildos. I just wanted to see what WMReloc.exe will do.

When I flashed the phone, It went through the language setup screen OK - the progress bar worked fine and the phone started. But that's where it finished, I got stuck on the splash screen again. The other thing I noticed is that I didn't have startup sound.  

Then I dumped this modified rom to compare dump_MemoryMap.txt files for original dump and the relocated dump.

I have noticed that WMReloc.exe creates some extra data. Memory is divided into 2 slots (2 halves). Most of file sections are mapped to both slots (Some are only in one). After running WMReloc, it maps all the files to both slots. The other thing what WMReloc did for the modules that it added, is to swap around the slots (the part with bigger size is in different slot now). For example there was only 1 memory allocation in first slot for bta2dp.dll (size 65535) in original dump. WMReloc added another one so now we have in first slot bta2dp.dll (size 4095) and in second slot bta2dp.dll (size 65535). Not sure if it matters though. 

If you have a look at the attached spreadsheet you will see what I mean. Maybe it will be usefull for rodrigofd. I had to rar it, It doesn't like xlsx attachment. 

Edit:

You haven't tried by any chance using buildos and/or WMReloc on the Chinese rom that we started with? I wonder if it worked on the 1-language rom.

test_dump_MemoryMap.rar

Edited by wes58
Link to comment
Share on other sites

You mean that you can now buildOS from sys, oem, xip and flash without lang setup error? Did you also change the 1EA value? Could you give me a try with your new buildOS?

I am looking forward to that as well. That would be great.

Link to comment
Share on other sites

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

I think it is R&D issue as I suspect it could be some RMA workaround like engineering fix with some jumper wires or some SMD component (like resistor or capacitor replacement). I used to work in manufacturing environment. :)

I don't think they replace the chip or motherboard cos the repair took only 1hr unless they do have the parts available in the service centre.

Link to comment
Share on other sites

I started to have a look at language pack - maybe it will be useful later on. 

At offset 04 there is a size of language pack (which starts at offset 100)

At offset 08 - not sure what it is!

At offset 0C is the checksum for language pack (calculated from offset 100 to the end of the file)

At offset 900 MSFLSH50

At offset 20100 you will find boot record MSWIN4.1 (it is similar what you get on hard drive, floppies etc).  

Rodrigofd:

I found for you source code (old one though) for mamaich imgfs tools (viewimgfs, buildimgfs, recmod). Maybe you will find some info how it works.

imgfs_tools_src.rar

post-420700-1258690858_thumb.jpg

post-420700-1258690899_thumb.jpg

Link to comment
Share on other sites

Sad :)

You guys read about the problems there are with modification of the rom. Rodrigo is working on some tools that would help us, Khuanchai is probably working on the rom as well. Until there is some progress or questions to ask, you just have to wait.

And one more thing, after working for a few days on something, it is good to take a break so you can have a fresh look at things. Maybe there was something that we missed and we didn't realized?

Edited by wes58
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.