5800 dual boot OFW and C6

[tintinboss]

Hi guys! This is really interesting! I'd love to contribute! I was hearing that you need information about ekern.exe, efile.exe, c32start.exe etc. I can decompile and present you with the pure symbian C++ code if it helps you. For starting a different and awesome project!

[LRajesh555]

Hi guys! This is really interesting! I'd love to contribute! I was hearing that you need information about ekern.exe, efile.exe, c32start.exe etc. I can decompile and present you with the pure symbian C++ code if it helps you. For starting a different and awesome project!

nice to see u here bro

[LRajesh555]

i shared the attached  tools to lamerfall in DM.

Here also i am sharing for GL members  use.

NFE0706 is the tool which is not  published by t0trader will give the partition table while opening the core file  rest is all same as NFE0603

thanx vizhi ...u r a very helpful guy ..+1

[lamerfall]

Hi guys! This is really interesting! I'd love to contribute! I was hearing that you need information about ekern.exe, efile.exe, c32start.exe etc. I can decompile and present you with the pure symbian C++ code if it helps you. For starting a different and awesome project!

This will help a lot especially for efile.exe

Especially if the code is really C++ and not assembler (assembler is also welcome, anyway).

[lamerfall]

i shared the attached  tools to lamerfall in DM.

Here also i am sharing for GL members  use.

NFE0706 is the tool which is not  published by t0trader will give the partition table while opening the core file  rest is all same as NFE0603

Thanks for the tools.

I know at least one person who succeeded with changing C drive size with the last tool, but he is not willing to share his work. I tried many times before, but it wasn't success (jaf don't want to flash my files).

Here is in what I am interested (for RM-356 v60) :

1. There are 2 mb unused in binh repartition (1 mb for rofs1 and 1 mb for rofs3). It will be useful if we merge some of this space in rofs2 like:

rofs1: 40 kb - it holds at least 1 file (not tested if this file is needed)

rofs2: + new fried space (2mb - 80 kb)

rofs3: 40 kb  - it is empty, but left some kb for FS overhead as even empty FS takes space.

For this you don't need to modify RfAll parameter...

2. Altering ROFS and C drive space - for bigger C drive or bigger rofs (in my case bigger C drive is more needed)

This is harder than 1.

If anyone succeeds with either 1 or 2, I'll ask him to make a simple tutorial or at least to share his works...

[lamerfall]

Hey,Guys See this....This wil help newbies to understand Boot Processes and Kernals of S60v5 For newbies.and Experts also :

About Loader

Internal Startup processes part 1

Internal Startup processes part 2

+ 1

I am searching information about the following:

XIP files Header - it is similar to E32Image header, but it is not the same.

How is calculater the CRC32 checksum of the header - a lot of programs do this, but I need to know what exactly data from header is taken and if the checksum is included as it is part of the header, what is its default value used for calculations (I think it is not 000000000 or FFFFFFFFF)... Or I need a program that makes changes in XIP files headers and recalculating checksums by itself...

[shivam94]

Here is the converation at fb on dual boot topic made available for more info.  Click on the image below to expand the image

[tintinboss]

This will help a lot especially for efile.exe

Especially if the code is really C++ and not assembler (assembler is also welcome, anyway).

Hmm So I should show something rather than creating confusion!

I couldn't find sys/bin/efile.exe . Please provide me the file.

Here's an example of decoded startup.exe (Symbian C++ code with block address and Hex codes)

Hope this helps!

8750_.rtf

8751_.rtf

[tintinboss]

Hmm So I should show something rather than creating confusion!

I couldn't find sys/bin/efile.exe . Please provide me the file.

Here's an example of decoded startup.exe (Symbian C++ code with block address and Hex codes)

Hope this helps!

If needed, the ER Diagram of the files can be given! I added the CRC test value Let me know...

[lamerfall]

@tintinboss +1 It is interesting mix between assembler and C code (not exactly what I expected, but it will help) Files we are interested in are in ROM. I'll attach them soon.

[tintinboss]

@tintinboss +1

It is interesting mix between assembler and C code (not exactly what I expected, but it will help)

Files we are interested in are in ROM.

I'll attach them soon.

Yah Thanks mate...

The portion I couldn't decode are still in assembly code. But I think all the import functions are decoded properly...

Okay, attach the files and I'll try decoding them soon! +1 for the brave attempt for poor S60v5!!

[lamerfall]

@shivam94 This will be a lot of reading.... So I try to answer some doubts.... First of all: In the case of 5800 (RM-356) it uses the same core both for OFW and C6 port. I don't see any reason at this point for editing the bootloader... What we can do at this stage: We can change files in mass memory - C:, E: We can add virtual drives - O:, P:, Q: as many as we need We can change files in ROFS (ROFS1, ROFS2, ROFS3). We can change files in Rom via RPP. In theory we can change everything that we need to change (ROM + ROFS makes the whole Z drive (or I am wrong ?)) Futhermore we can change things in ROM without flash, and flash is needed only for files in ROFS. This is the reason we need to "externalize" as much files from ROFS as possible and use these files in C or E. Meanwhile if we make a new repartiton of ROFS1/2/3 and C drive, we can enlarge C drive size with free mb from Z... (I know that some people can do that, but they don't want to contribute their work, so we need to make this by ourselves...) The C drive is special as it is the system drive... I am working on the program that can change system drive... Hope that way that we can generate virtual drive and make it system, so that way we will separate files from OFW and C6 i.e. we will have a system C drive for OFW and and a system drive X for C6 port About differences - there are probably more than 5000 files different in C6 and OFW. (anyone can make comparison and see the exact number). What is important is that we need to escape conflicts... We all know that there is a lot of work on this, but if we manage to make a team for this we will have more ideas and probably we will make it real some day... At least I don't see any reasons why it is not possible. Till now when we find something that stops us, we think and find some solutions... That way the project progresses

[lamerfall]

I read the full image Yes, it is a lot of work. See this point for  5800 (RM-356): C6_Rom == OFW_Rom C6_ROFS != OFW_ROFS C6_UDA != OFW_UDA This means that calls in ROM are fine and we make modifications here only for solution of other problems... For example if file in ROM call file in ROFS, we need to redirect it to OFW or C6 file when the differ (this is the common situation). For UDA files: There are two ideas: 1. To use different system drives 2. To use different file name For ROFS: (here is a lot of work) If we externalize as much as possible to RW location we can simply move files when changing os (move is relatively fast operation) i.e changing OFW and C6 files without having to change names Another solution is to change the names for C6 for example so files can coexist on one location.

[shivam94]

@shivam94

This will be a lot of reading....

So I try to answer some doubts....

First of all:

In the case of 5800 (RM-356) it uses the same core both for OFW and C6 port.

I don't see any reason at this point for editing the bootloader...

Totally agree on this

In theory we can change everything that we need to change (ROM + ROFS makes the whole Z drive (or I am wrong ?))

Yes we can. But an important thing which plays a very important role is the timing at which the changes should be made i.e. we need to ensure that the files which are to be patched are not under use while patching . 

2 things play a vital role:

1)timing of the patching duing the phone startup

2)The capabilities of the app which are to be patched

Futhermore we can change things in ROM without flash, and flash is needed only for files in ROFS.

This is the reason we need to "externalize" as much files from ROFS as possible and use these files in C or E.

Again, you need to see my previous answer for this

@2nd point,  yes.

My doubt would be the speed @ which the system would work even if we are successful in dual booting.  I mean that reading from inbuilt rom and reading from mmc , there is a vast difference in speed.  This needs to be looked upon at.

Meanwhile if we make a new repartiton of ROFS1/2/3 and C drive, we can enlarge C drive size with free mb from Z... (I know that some people can do that, but they don't want to contribute their work, so we need to make this by ourselves...)

This is sad.  I think doctorly can do this . Nonetheless, we need to try oursleves first

The C drive is special as it is the system drive... I am working on the program that can change system drive... Hope that way that we can generate virtual drive and make it system, so that way we will separate files from OFW and C6 i.e. we will have a system C drive for OFW and and a system drive X for C6 port

Great idea. Hope you succeed

About differences - there are probably more than 5000 files different in C6 and OFW. (anyone can make comparison and see the exact number).

What is important is that we need to escape conflicts...

And also satisfy the dependencies (which are different).  This is the most cumbersome task which needs to be done with a help of a team. 

[shivam94]

I read the full image

Yes, it is a lot of work.

See this point for  5800 (RM-356):

C6_Rom == OFW_Rom

C6_ROFS != OFW_ROFS

C6_UDA != OFW_UDA

This means that calls in ROM are fine and we make modifications here only for solution of other problems...

For example if file in ROM call file in ROFS, we need to redirect it to OFW or C6 file when the differ (this is the common situation).

editing exe is not like editing text file.  we need to understand how to edit them and what to modify 

For UDA files:

There are two ideas:

1. To use different system drives

2. To use different file name

for both 1st and 2nd idea, we need to modify exe's (for drive allocation, we need to modify efile.exe)

For ROFS: (here is a lot of work)

If we externalize as much as possible to RW location we can simply move files when changing os (move is relatively fast operation) i.e changing OFW and C6 files without having to change names

Another solution is to change the names for C6 for example so files can coexist on one location.

I think the second solution seems more cumbersome as we need to edit all the exe's in the rofs to take in account the change in file name which would take loads of time and effort

First solution seems more realistic.

[tintinboss]

If after observing, you can mark where to change and what to change exactly, I can repack the exe with the changes and submit.

[shivam94]

If after observing, you can mark where to change and what to change exactly, I can repack the exe with the changes and submit.

Please decompile the following exe's attached in the rar

8752_.rar

[lamerfall]

editing exe is not like editing text file.  we need to understand how to edit them and what to modify 

for both 1st and 2nd idea, we need to modify exe's (for drive allocation, we need to modify efile.exe)

Actually for our needs it is not harder than editing text files. Because we will only change file names - it is similar to editing starters. If for example there is a sting like z:\sys\bin\someapp.exe we change it to x:\sys\bin\someapp.exe or to "someapp.exe            ", I hope you get it

It more difficult with dll files, but do you remember what I send you in pm about different dll versions .

All this needs a lot of flashing and testing.

If we make a bigger team of about 10 or more users, things will speed up a lot.

If we find more experienced modders than us and involve them here, this could help even more.

[pavan061994]

Actually for our needs it is not harder than editing text files. Because we will only change file names - it is similar to editing starters. If for example there is a sting like z:\sys\bin\someapp.exe we change it to x:\sys\bin\someapp.exe or to "someapp.exe            ", I hope you get it

It more difficult with dll files, but do you remember what I send you in pm about different dll versions .

All this needs a lot of flashing and testing.

If we make a bigger team of about 10 or more users, things will speed up a lot.

If we find more experienced modders than us and involve them here, this could help even more.

i m in....and will arrange team of beta flashers and also invite modders ...just give names...m

[tintinboss]

Decompiled Efile.exe is huge... Please check and tell if it's alright. Thanks

8756_.zip

[lamerfall]

Anyone who wants to help the project is welcome..

[shivam94]

Decompiled

Efile.exe is huge... Please check and tell if it's alright.

Thanks

@ lamerfall, see the efile.exe dump_sym by tintinboss and search in the file for "SetSystemDrive".   Hope you know what it implies...

[lamerfall]

I see that 10 people voted in the poll that they want to help. It will be good, if everyone of them make a post with information what phone he owns and in what areas he wants to help. For example some people can work on things that require more often flashing and other people don't like flashing frequently (when they have only 1 phone for example - this is my case ) Also take a look at this: List of applications from OFW that work extracted from Z to C or E (modified exe and dll files) List of applications from C6 port that work extracted from Z to C or E (modified exe/dll/rsc files) What I mean here is to move applications from Z to C or E (E is preffered). This includes identifying files of the application (from stub or by intuition, if stub is not very detailed). Removing links to these files from Rom. If in rom files there is something like z:\xxx\somefile this must be changed to new drive letter or if it is exe to someexe.exe (this way I think the system will search for it first in other drives, this is confirmed true for Z_Rom, but it is not confirmed for Z_ROFS - someone can test this).

[pavan061994]

I see that 10 people voted in the poll that they want to help.

It will be good, if everyone of them make a post with information what phone he owns and in what areas he wants to help.

For example some people can work on things that require more often flashing and other people don't like flashing frequently (when they have only 1 phone for example - this is my case )

Also take a look at this:

List of applications from OFW that work extracted from Z to C or E (modified exe and dll files)

List of applications from C6 port that work extracted from Z to C or E (modified exe/dll/rsc files)

What I mean here is to move applications from Z to C or E (E is preffered).

This includes identifying files of the application (from stub or by intuition, if stub is not very detailed).

Removing links to these files from Rom. If in rom files there is something like z:\xxx\somefile this must be changed to new drive letter or if it is exe to someexe.exe (this way I think the system will search for it first in other drives, this is confirmed true for Z_Rom, but it is not confirmed for Z_ROFS - someone can test this).

hmm.let u clear tht....we ...x6 users have e:/ as mass storage...so...cant experiment on it becoz...itzzz built in phn,....and if anything go wrong then  i shud get it to Nokia care again....

[shivam94]

hmm.let u clear tht....we ...x6 users have e:/ as mass storage...so...cant experiment on it becoz...itzzz built in phn,....and if anything go wrong then  i shud get it to Nokia care again....

Ya.  x6 users have built in memory   But nokia care is not required.  Maximum, you can brick your phone, which can be resolved by flashing.  Make sure you don't put any patch on your e drive which patches at startup of your phone.

          yes x6 users are at higher risk than any  other s60v5 users in testing patches.

@lamerfall , see my previous post