675 replies to this topic

[Pako777]

rodrigofd, on Nov 21 2009, 23:44, said:

You're wrong pako, octans do check if checksum is correct, i wrongly calculated in my first attemps, and 'checksum failed' error was displayed both in octans and in phone screen...
Nb0 is a multi-section file, with adjacent header-section-header-section.... parts..... with each header being of 0x100 bytes, that include section size (excluding the 0x100 header) , .. a block count (section size divided by 1F800) and a checksum of the section data.... up to now we know 2 sections: the first OS.NB file, and an optional the langpack section, that can be mounted as a virtual disk drive...

this all i know..
For example, with the help EXEcutor I have created nb0 only from pda_partition (without langpack), in the field checksum (in nb0) have written down $00000000 and have palmed off this nb0 to OCTAN_DL 2.11 - it has accepted it and anything about the checksum has not told. Or he should tell something directly at an flashing?

[rodrigofd]

Pako777, on Nov 21 2009, 16:04, said:

this all i know..
For example, with the help EXEcutor I have created nb0 only from pda_partition (without langpack), in the field checksum (in nb0) have written down $00000000 and have palmed off this nb0 to OCTAN_DL 2.11 - it has accepted it and anything about the checksum has not told. Or he should tell something directly at an flashing?

If checksum is invalid, it prompts an error message at THE END of the image download to phone...

[Pako777]

rodrigofd, on Nov 22 2009, 00:59, said:

...it prompts an error message at THE END of the image download to phone...

thanks.. now will be search algoritm "Checksum-32".. algo CRC-32 does not approach..

[rodrigofd]

Well, some good news, firstly i successfully have a kitchen that unpacks a nb0, dumps imgfs and xip, reorders in packages, repackages to a dump, and reassembles a flashable, working NB0 .. all this using as base, I8000NIJC WM 6.5 english...

What's more, i THINK i figured out WHY WMRELOC tool fails to relocate all modules correctly... modules in XIP part also use fixed memory location, but they are not included in the dump, to which we apply WMRELOC... so the tool doesn't get them in consideration when remapping addresess.. and , i believe, new relocated modules from IMGFS get into conflict with originally-mapped modules in XIP....

SO , according to my theory, we should rellocate all modules at one time, both from imgfs and xip, and then everything will work...
I'm about to start building a WM 6.5.3 28002 build, and i'll have it ready in a couple hours...

[wes58]

rodrigofd, on Nov 21 2009, 22:41, said:

Well, some good news, firstly i successfully have a kitchen that unpacks a nb0, dumps imgfs and xip, reorders in packages, repackages to a dump, and reassembles a flashable, working NB0 .. all this using as base, I8000NIJC WM 6.5 english...

What's more, i THINK i figured out WHY WMRELOC tool fails to relocate all modules correctly... modules in XIP part also use fixed memory location, but they are not included in the dump, to which we apply WMRELOC... so the tool doesn't get them in consideration when remapping addresess.. and , i believe, new relocated modules from IMGFS get into conflict with originally-mapped modules in XIP....

SO , according to my theory, we should rellocate all modules at one time, both from imgfs and xip, and then everything will work...
I'm about to start building a WM 6.5.3 28002 build, and i'll have it ready in a couple hours...

I thought that will be a case, with XIP needed to be included in the dump. But how did it work with OMNIA (and I guess other phones) before? Unless WMReloc would look at SYS, OEM and XIP (which is in ROM folder) packages if they are all put in one 'dump' folder, and then you would do relocation of dump folder? Just a thought. If you relocate XIP dump you would have to build and pack into nb0 XIP as well.

I am curious how will you manage to port WM6.5.3 since WM language resources that are in SYS folder are located in the language pack? 

Edited by wes58, 21 November 2009 - 11:10 PM.

[rodrigofd]

I've just asked admin PAUL if he could pin this thread... i think we are going in a good direction now !

[Baveto]

Michael Pang, on Nov 21 2009, 23:55, said:

btw, wm6.5.3 build 28002 is out, is it a good candidate? thanks for your update.
http://wmpoweruser.com/?p=10450

WM 6.5.3 build 28002
Here is the XIP & SYS, tutorials & more : http://forum.xda-dev...ad.php?t=544445

Attached Files

•  yar2.png   357.97K   81 downloads

[powser]

rodrigofd, on Nov 22 2009, 06:41, said:

Well, some good news, firstly i successfully have a kitchen that unpacks a nb0, dumps imgfs and xip, reorders in packages, repackages to a dump, and reassembles a flashable, working NB0 .. all this using as base, I8000NIJC WM 6.5 english...

What's more, i THINK i figured out WHY WMRELOC tool fails to relocate all modules correctly... modules in XIP part also use fixed memory location, but they are not included in the dump, to which we apply WMRELOC... so the tool doesn't get them in consideration when remapping addresess.. and , i believe, new relocated modules from IMGFS get into conflict with originally-mapped modules in XIP....

SO , according to my theory, we should rellocate all modules at one time, both from imgfs and xip, and then everything will work...
I'm about to start building a WM 6.5.3 28002 build, and i'll have it ready in a couple hours...

This is so exciting!! Thank you for your hardwork!
Loooking forward to this!

[diverdude]

rodrigofd, on Nov 21 2009, 22:41, said:

Well, some good news, firstly i successfully have a kitchen that unpacks a nb0, dumps imgfs and xip, reorders in packages, repackages to a dump, and reassembles a flashable, working NB0 .. all this using as base, I8000NIJC WM 6.5 english...

What's more, i THINK i figured out WHY WMRELOC tool fails to relocate all modules correctly... modules in XIP part also use fixed memory location, but they are not included in the dump, to which we apply WMRELOC... so the tool doesn't get them in consideration when remapping addresess.. and , i believe, new relocated modules from IMGFS get into conflict with originally-mapped modules in XIP....

SO , according to my theory, we should rellocate all modules at one time, both from imgfs and xip, and then everything will work...
I'm about to start building a WM 6.5.3 28002 build, and i'll have it ready in a couple hours...

Mr. Rodrigofd,

Will you be able to share this with all of us soon?  Or, will this be something you will be giving to just a few testers. I would love to be a tester if you need anyone else.

Thank you soooo much for your hard work and all your dedcation to this project!!

Respect,  Diver

[jermx]

diverdude, on Nov 22 2009, 03:55, said:

Mr. Rodrigofd,

Will you be able to share this with all of us soon?  Or, will this be something you will be giving to just a few testers. I would love to be a tester if you need anyone else.

Thank you soooo much for your hard work and all your dedcation to this project!!

Respect,  Diver

Same. I would love to be a tester too.
Thanks for all your hard work. It was like a few days of no updates then suddenly a big one. (:

[jermx]

Oh yes rodrigofd please kindly cook EzInput in if possible (:

[Michael Pang]

can't stop me from keep refreshing this page.  

[InvalidCast]

rodrigofd,

just my two cents, maybe you should take your time before releasing anything to be sure not having people complaining they bricked their phone with your ROM. sometimes people forget they've been told it's alpha alpha alpha ROM and that it is dangerous to use it.

about adding some stuff to the ROM, maybe you may consider not putting anything in it, people can install what they want after flashing, and there will always be people saying "i would like this" and as soon as you put it in your ROM, other people will say "hey, why is this thing in the ROM, i don't need it!"

again, this is only my own humble opinion that may be wrong, and you're absolutely free to do what you want.

thanks for your hard work

[jermx]

rodrigofd:

check your inbox. I pm'ed you.

[wes58]

rodrigofd, on Nov 21 2009, 22:41, said:

Well, some good news, firstly i successfully have a kitchen that unpacks a nb0, dumps imgfs and xip, reorders in packages, repackages to a dump, and reassembles a flashable, working NB0 .. all this using as base, I8000NIJC WM 6.5 english...

What's more, i THINK i figured out WHY WMRELOC tool fails to relocate all modules correctly... modules in XIP part also use fixed memory location, but they are not included in the dump, to which we apply WMRELOC... so the tool doesn't get them in consideration when remapping addresess.. and , i believe, new relocated modules from IMGFS get into conflict with originally-mapped modules in XIP....

SO , according to my theory, we should rellocate all modules at one time, both from imgfs and xip, and then everything will work...
I'm about to start building a WM 6.5.3 28002 build, and i'll have it ready in a couple hours...

I found why WMReloc fails if the file section has size 0. WMReloc, after opening the file with function "CreateFileW" is trying to map the file with "CreateFileMappingW". Because the size is 0 it fails.
That's what microsoft is saying about this error "An attempt to map a file with a length of 0 (zero) fails with an error code of ERROR_FILE_INVALID. Applications should test for files with a length of 0 (zero) and reject those files."

Edited by wes58, 22 November 2009 - 10:14 AM.

[monyozt]

refreshing this page all day long

[wes58]

Rodrigo,

If you still have problems with WMReloc I think I know why. We are trying to relocate files that are in the dump folder. I extracted files from language pack and noticed that some of them are not what you would expect to be if you look at file extension. For example file AutoUpdateRes_wpc.exe.0409.mui, if you look in hex you would expect first to bytes to be MZ (like all exe and dll files). But in this file you will find first four bytes to be MNGE. What it turns out to be, is a file consisting of imageinfo.bin and one or more file sections S000, S001 ....

In case of this file, there is only one S000 which starts at offset 8C, and imageinfo.bin that starts at offset 04 to 8B. I think that first byte in imageinfo.bin tells you how many file sections there are, which also means that first S000 will start at different offset.

What all this means that some files from language pack are also placed in virtual memory and may overlap with the relocations created by WMReloc.

[Will.]

Same here

And InvalidCast has a very good point btw, i second that.

[rodrigofd]

wes58, on Nov 22 2009, 18:04, said:

Rodrigo,

If you still have problems with WMReloc I think I know why. We are trying to relocate files that are in the dump folder. I extracted files from language pack and noticed that some of them are not what you would expect to be if you look at file extension. For example file AutoUpdateRes_wpc.exe.0409.mui, if you look in hex you would expect first to bytes to be MZ (like all exe and dll files). But in this file you will find first four bytes to be MNGE. What it turns out to be, is a file consisting of imageinfo.bin and one or more file sections S000, S001 ....

In case of this file, there is only one S000 which starts at offset 8C, and imageinfo.bin that starts at offset 04 to 8B. I think that first byte in imageinfo.bin tells you how many file sections there are, which also means that first S000 will start at different offset.

What all this means that some files from language pack are also placed in virtual memory and may overlap with the relocations created by WMReloc.

It's a very good theory indeed!! SO more reasons we can make great use of supposed english-only ROM that secany has and hope he can provide me with.. I read that tacchan wrote him for this matter, and i also PM'ed him to see if he can give it to me.
If wes theory is correct , which i am totally sure it is, because it corresponds with other hiphotesis i've made in langpack, we now have 2 ways: getting deeper in langpack format, and trying to be able to properly 'cook it', or else, work with an one language-only ROM as a base. Second way is more likely, the first one involves too much work for now... we might leave langpack cooking for the future.

So, in short, if everyone can help me in persuading Secany to offer me his english-only recent official rom, i can finish the first cooked public-rom available within a pair of hours upon downloading it.

In reply to previous posts: first cooked rom i'll publish, will be as ultra-lite as possible.. I'll remove as much samsung-stuff as i can, while preserving all hardware functionality, and leaving as much storage and ram memory as i can. Everyone can then install their own CABs of their choice.
First attemp will remain on official WM 6.5 build, let's go step by step and not rush. Doing just this already is pretty messy, if we try to get too many things at once, we'll find more issues to deal with.

And YES, i am tempted not to realeasing to general public, because of all the support that i 'll have to do then , but giving it to a reduced size of beta testers instead.... all suggestions welcome though.

[wes58]

rodrigofd, on Nov 22 2009, 21:41, said:

It's a very good theory indeed!! SO more reasons we can make great use of supposed english-only ROM that secany has and hope he can provide me with.. I read that tacchan wrote him for this matter, and i also PM'ed him to see if he can give it to me.
If wes theory is correct , which i am totally sure it is, because it corresponds with other hiphotesis i've made in langpack, we now have 2 ways: getting deeper in langpack format, and trying to be able to properly 'cook it', or else, work with an one language-only ROM as a base. Second way is more likely, the first one involves too much work for now... we might leave langpack cooking for the future.

So, in short, if everyone can help me in persuading Secany to offer me his english-only recent official rom, i can finish the first cooked public-rom available within a pair of hours upon downloading it.

In reply to previous posts: first cooked rom i'll publish, will be as ultra-lite as possible.. I'll remove as much samsung-stuff as i can, while preserving all hardware functionality, and leaving as much storage and ram memory as i can. Everyone can then install their own CABs of their choice.
First attemp will remain on official WM 6.5 build, let's go step by step and not rush. Doing just this already is pretty messy, if we try to get too many things at once, we'll find more issues to deal with.

And YES, i am tempted not to realeasing to general public, because of all the support that i 'll have to do then , but giving it to a reduced size of beta testers instead.... all suggestions welcome though.

I am thinking, we get rid of language pack. I will try to do something today, compare files with chinese rom and see if I can convert the files that we need from language pack. If it doesn't work we may have to wait for Secany.