Site Notice - We are currently investigating an issue with missing download links. Apologies for any inconvenience caused. PaulOBrien

  • Announcements

    • Reminder - MoDaCo position on illegal content   07/30/15

      ILLEGAL CONTENT I'd like to just reaffirm MoDaCo's position regarding piracy and illegal content in the light of some recent questions / postings. Posts will be censored by myself or my moderation team if the contain or link to: Illegal / pirated / cracked software or sites that host such softwareNintendo emulators / ROMs or sites hosting them (in light of Nintendo's legal stance)CUSTOM ROMS You may discuss and post links to custom device ROMs on MoDaCo, provided the following rules are adhered to: ROMs must not contain any illegal 3rd party software (this includes trial versions included without permission)ROMs must give full credit to the original authorISSUES If you have any issues with this policy, please contact PaulOBrien directly via PM.
    • Reminder: Selling items on the forum directly is not allowed   07/30/15

      Please note that selling items on the forum directly is not allowed by the forum rules. There is a forum for eBay auctions whereby you can list the items on eBay and link to them there. This is the ONLY forum for this type of activity. You may also advertise links to the eBay forum in your signature. Please note that selling directly in contravention of these rules will result in a warning / suspension / ban.

TMC

156 posts in this topic

Posted · Report post

Tonight I'll be off-duty :lol: , but yesterday I wrote the code for the new driver and embedded the original one in the project. Will test it tomorrow ... then, if everithing will work as expected, I'll move to the virtual com port driver (for which I already have a skeleton).

WoW.

Have nice evening/night!! :D

0

Share this post


Link to post
Share on other sites

Posted · Report post

Tonight I'll be off-duty :lol: , but yesterday I wrote the code for the new driver and embedded the original one in the project. Will test it tomorrow ... then, if everithing will work as expected, I'll move to the virtual com port driver (for which I already have a skeleton).

Hi BeamRider,

I'm just adding myself to the list of people hoping you manage this. What a great project! This will be an amazing addition to my Omnia.

Thanks,

Paul

0

Share this post


Link to post
Share on other sites

Posted · Report post

Dear BeamRider,

Do you have any news? :lol:

0

Share this post


Link to post
Share on other sites

Posted · Report post

Yes, I'm a litte bit behind my schedule due to some workplace commitments, but I succeded in compiling the driver: since I have not so much experience in ARM assembler I had some syntactical issues to face.

The solution adopted was to wrap the old one, modify the code and export the symbols needed.

It's quite intrusive in respect what I had planned (hoped) but cleaner and more scalable than an hex hack. I think that a complete rewrite of the driver will be a very good thing, but not my target atm.

The driver loads and initializes correctly, but ... at 3:15 I was sleeping in front of the monitor and wan't able to go further.

It's raining outside, so I have plenty of time today <_< :lol:

0

Share this post


Link to post
Share on other sites

Posted · Report post

Yes, I'm a litte bit behind my schedule due to some workplace commitments, but I succeded in compiling the driver: since I have not so much experience in ARM assembler I had some syntactical issues to face.

The solution adopted was to wrap the old one, modify the code and export the symbols needed.

It's quite intrusive in respect what I had planned (hoped) but cleaner and more scalable than an hex hack. I think that a complete rewrite of the driver will be a very good thing, but not my target atm.

The driver loads and initializes correctly, but ... at 3:15 I was sleeping in front of the monitor and wan't able to go further.

It's raining outside, so I have plenty of time today <_< :lol:

There is sun in our sky... I can send you some sunshine :D virtually...

Have a nice day!

Keep up the work, as your timescedule allowing. ;)

0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

After a couple of device hard resets (buggy code :lol: :D ) the driver is installed inside my Omnia ... still having problems, but the worst part is now gone. As you can see from the log below, the driver is loaded initialised and started. and I just having problems on tune (the bold part is quite explicit).

FM Radio - resource allocation, success

FM Radio - InitializeFMRadioThread, success

FM Radio - Init, done v001J1

FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00032180]

FM Radio - IOControl, hOpenContext[0x00032180] dwCode[0x00321000]

FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00032BC0]

FM Radio - Close, hOpenContext[0x00032BC0]

FM Radio - si470x_tune, intr failed

FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00817B30]

FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x0038B0E0]

FM Radio - IOControl, hOpenContext[0x0038B0E0] dwCode[0x00220004]

FM Radio - IOCTL_FMRADIO_TURN_ON, region[1]

FM Radio - IOControl, failed

FM Radio - IOControl, hOpenContext[0x0038B0E0] dwCode[0x010303FF]

FM Radio - IOControl failed, already turned off

FM Radio - Close, hOpenContext[0x0038B0E0]

Note that these are the logs from the original code (the original log is done trough NKDbgPrintfW) that I'm writing to a log file (kernel debug is not available on our devices). RDS functionality is already present in my driver, but I can't tune...

Now it's time to look at what's going wrong!!!

Edited by BeamRider
0

Share this post


Link to post
Share on other sites

Posted · Report post

BeamRider - fingers crossed..

0

Share this post


Link to post
Share on other sites

Posted · Report post

Men you are really good!

0

Share this post


Link to post
Share on other sites

Posted · Report post

After a couple of device hard resets (buggy code B) B) ) the driver is installed inside my Omnia ... still having problems, but the worst part is now gone. As you can see from the log below, the driver is loaded initialised and started. and I just having problems on tune (the bold part is quite explicit).

FM Radio - resource allocation, success

FM Radio - InitializeFMRadioThread, success

FM Radio - Init, done v001J1

FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00032180]

FM Radio - IOControl, hOpenContext[0x00032180] dwCode[0x00321000]

FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00032BC0]

FM Radio - Close, hOpenContext[0x00032BC0]

FM Radio - si470x_tune, intr failed

FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00817B30]

FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x0038B0E0]

FM Radio - IOControl, hOpenContext[0x0038B0E0] dwCode[0x00220004]

FM Radio - IOCTL_FMRADIO_TURN_ON, region[1]

FM Radio - IOControl, failed

FM Radio - IOControl, hOpenContext[0x0038B0E0] dwCode[0x010303FF]

FM Radio - IOControl failed, already turned off

FM Radio - Close, hOpenContext[0x0038B0E0]

Note that these are the logs from the original code (the original log is done trough NKDbgPrintfW) that I'm writing to a log file (kernel debug is not available on our devices). RDS functionality is already present in my driver, but I can't tune...

Now it's time to look at what's going wrong!!!

I'm so impressed! This is great work BeamRider, this will be an amazing use of the Omnia's h/w. Why can't they make this easier for us all in the first place?

Can't wait to see what happens here!

Paul

0

Share this post


Link to post
Share on other sites

Posted · Report post

very nice indeed...I be watching your project progress from now on...damn..I wish I could help you out =)

0

Share this post


Link to post
Share on other sites

Posted · Report post

What ROM version are you developing on?

0

Share this post


Link to post
Share on other sites

Posted · Report post

What ROM version are you developing on?

XIHH5/HH9 (the one that came with my device)

0

Share this post


Link to post
Share on other sites

Posted · Report post

BeamRider, did you resolve the tuning problems? All your "tifosi" are waiting! B)

0

Share this post


Link to post
Share on other sites

Posted · Report post

Not yet, but closing ... It's a tuner init problem, apperars that the tuner chip is not communicating after initialisation. It's funny because I'm using the same code of the original (when I say same I really mean same). That's the knid of problem I tried to avoid just because I don't know much about Omnia hardware.

I'm not posting detailed updates beacuse it's time to better look at the hardware layer (that's a lot of fun but not of a much interest to this thread) ... maybe some low leve guru can help me in sorting out things: are there any documentation about the buses and memory mapped registers?

Don't worry, I spent too much time in this project to leave it now B)

0

Share this post


Link to post
Share on other sites

Posted · Report post

Not yet, but closing ... It's a tuner init problem, apperars that the tuner chip is not communicating after initialisation. It's funny because I'm using the same code of the original (when I say same I really mean same). That's the knid of problem I tried to avoid just because I don't know much about Omnia hardware.

I'm not posting detailed updates beacuse it's time to better look at the hardware layer (that's a lot of fun but not of a much interest to this thread) ... maybe some low leve guru can help me in sorting out things: are there any documentation about the buses and memory mapped registers?

Don't worry, I spent too much time in this project to leave it now B)

I don't know if this is what you need (intel XScale info)...

PXA320 Summary : http://embedded-seo.blogspot.com/2008/06/p...controller.html

XScale debug manual (emulator manual, maybe there is some useful info for you): http://www.abatron.ch/fileadmin/user_uploa...DBXSC-2000C.pdf

Intel's XScale datasheet : ftp://download.intel.com/design/intelxsca...eDatasheet4.pdf

PXA270 Architecture info (in French but I can translate it to you if you need it) : http://www.oraux.be/files/Intel.Xscale.PXA...-.2006.v3ar.pdf

Let me know if it helps.

0

Share this post


Link to post
Share on other sites

Posted · Report post

Don't worry, I spent too much time in this project to leave it now B)

Don't give up! Hope I'll manage to find a way to state diner.... B) B)

0

Share this post


Link to post
Share on other sites

Posted · Report post

I don't know if this is what you need (intel XScale info)...

PXA320 Summary : http://embedded-seo.blogspot.com/2008/06/p...controller.html

XScale debug manual (emulator manual, maybe there is some useful info for you): http://www.abatron.ch/fileadmin/user_uploa...DBXSC-2000C.pdf

Intel's XScale datasheet : ftp://download.intel.com/design/intelxsca...eDatasheet4.pdf

PXA270 Architecture info (in French but I can translate it to you if you need it) : http://www.oraux.be/files/Intel.Xscale.PXA...-.2006.v3ar.pdf

Let me know if it helps.

Two more additions:

Intel XScale page (lots of low-level manuals): http://www.intel.com/design/intelxscale/

Marvell PXA320 page (maybe registering to the site there is useful information, even if I don't really think so): http://www.marvell.com/products/cellular/a...tion/pxa320.jsp

Silicon Labs FM Receivers page (again, maybe registering there is info that can help you, but I guess you are already registered): https://www.silabs.com/products/audiovideo/...es/default.aspx

BeamRider, how did you get the source code you are using and what tools do you use to develop?

0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

hm, sorry, duplicate

Edited by Stacker007
0

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

Hi @all,

do I understand right if this driver in the end MIGHT also work for tmc-iGo on a htc touch pro? My tuner is also stuck at 0.0MHz but found by iGo :S

Great work! and I will follow for sure

Edited by Stacker007
0

Share this post


Link to post
Share on other sites

Posted · Report post

Two more additions:

Intel XScale page (lots of low-level manuals): http://www.intel.com/design/intelxscale/

Marvell PXA320 page (maybe registering to the site there is useful information, even if I don't really think so): http://www.marvell.com/products/cellular/a...tion/pxa320.jsp

Silicon Labs FM Receivers page (again, maybe registering there is info that can help you, but I guess you are already registered): https://www.silabs.com/products/audiovideo/...es/default.aspx

BeamRider, how did you get the source code you are using and what tools do you use to develop?

Thanks for the references ... I'm looking to XScale docs to see if something may help.

Regarding source code and toolchain, I have no original source code (if I had, I probably had driver ready from weeks). I disassembled, then re-assembled with slightly modified interface to the kernel (changed debug routines and added IOCTL to access RDS). I'm using IDA and VS 2008, but except for different syntax, I see no problems to use GNU toolchain.

@Stacker007: this driver is for Omnia only, I don't have a touchpro to chack at (but I'm pretty sure they are using different HW)

0

Share this post


Link to post
Share on other sites

Posted · Report post

Hello BeamRider,

Is there nobody from Samsung who can help you?

0

Share this post


Link to post
Share on other sites

Posted · Report post

Thanks for the references ... I'm looking to XScale docs to see if something may help.

Regarding source code and toolchain, I have no original source code (if I had, I probably had driver ready from weeks). I disassembled, then re-assembled with slightly modified interface to the kernel (changed debug routines and added IOCTL to access RDS). I'm using IDA and VS 2008, but except for different syntax, I see no problems to use GNU toolchain.

@Stacker007: this driver is for Omnia only, I don't have a touchpro to chack at (but I'm pretty sure they are using different HW)

BeamRider, let’s brainstorm. I’ve been thinking on what you said (that you have init problems and that you used the same code).

I will give you some ideas. I don’t know if they are applicable and maybe you have already taken them into account, or maybe I’m wrong, but who knows.

- You use the same code, but have you installed a second FM driver or you have just replaced the original? If you have installed a second one, maybe you are facing hardware access conflicts, don’t you think so? If it is the case, maybe you can disable the original one (with SKTools for example)?

- I have found the source code of SI470x for linux. The key principles are inside: ftp://200.17.202.17/kernel/pub/scm/linux/.../radio-si470x.c

Hope this help. Otherwise, have you advanced?

0

Share this post


Link to post
Share on other sites

Posted · Report post

- You use the same code, but have you installed a second FM driver or you have just replaced the original? If you have installed a second one, maybe you are facing hardware access conflicts, don’t you think so? If it is the case, maybe you can disable the original one (with SKTools for example)?

I don't know how deeply you know driver architecture of WM and I'll start from the beginning. Each (kernel) driver is a simple DLL with a DllMain (or whatever else is called the entry point) and 5 fixed name exported functions:

XXX_Init, XXX_Deinit, XXX_Open, XXX_Close, XXX_IOControl

where XXX is the legacy name of the driver (FMR in our case). My work was to disassemble the original FMRadio.dll, change the name of FMR_IOControl to FMX_IOControl and to create my own FMR_IOControl to incercept and serve a specific call. Obiviously I'm calling old function to serve original driver requests. I kept remaining functions as they were to minimze impact.

I tried also to keep same code/data segments but the point is that I'm not interfeing with the code that initialises the driver.

Obiviously I'm signing the dll with a development certificate from WM SDK, otherwise I will not be able to load the driver during startup. Kernel patching will help but it's not needed now.

- I have found the source code of SI470x for linux. The key principles are inside: ftp://200.17.202.17/kernel/pub/scm/linux/.../radio-si470x.c

I found the code but it is at an higer level in respect to what I need. I have problems to communicate with the tuner using the Omnia architecture (that is still a black box to me) and need to understand what kind of "port" is used from OMNIA talk with 470x. In PCs usually the chip is accessed trough PCI or USB bridges (ie the implementation given from SI labs). I know kernel calls and phisical memory locations where the driver writes while initialising the hardware, now I need to know what is doing when writing to what I think is memory mapped IO. This will lead to the capacity of understanding what is doing and what is going wrong during the whole process. Remeber that I can't debug at a kernel level without additional hardware and opening the Omnia.

Actually I tried to strip stack checking calls to see if ther's something related with it, but with no luck.

0

Share this post


Link to post
Share on other sites

Posted · Report post

I don't know how deeply you know driver architecture of WM and I'll start from the beginning. Each (kernel) driver is a simple DLL with a DllMain (or whatever else is called the entry point) and 5 fixed name exported functions:

XXX_Init, XXX_Deinit, XXX_Open, XXX_Close, XXX_IOControl

where XXX is the legacy name of the driver (FMR in our case). My work was to disassemble the original FMRadio.dll, change the name of FMR_IOControl to FMX_IOControl and to create my own FMR_IOControl to incercept and serve a specific call. Obiviously I'm calling old function to serve original driver requests. I kept remaining functions as they were to minimze impact.

I tried also to keep same code/data segments but the point is that I'm not interfeing with the code that initialises the driver.

Obiviously I'm signing the dll with a development certificate from WM SDK, otherwise I will not be able to load the driver during startup. Kernel patching will help but it's not needed now.

Thanks for the tutorial. I was not so aware about WM, but your method of call interception seems good to me. So if I have well understood, you are expanding the original driver to trap IO accesses and to add some additional exploitation.

What is exactly additional treatment that you are implementing in your new FMR_IOControl? Is it highly consuming in terms of CPU?

I found the code but it is at an higer level in respect to what I need. I have problems to communicate with the tuner using the Omnia architecture (that is still a black box to me) and need to understand what kind of "port" is used from OMNIA talk with 470x. In PCs usually the chip is accessed trough PCI or USB bridges (ie the implementation given from SI labs). I know kernel calls and phisical memory locations where the driver writes while initialising the hardware, now I need to know what is doing when writing to what I think is memory mapped IO. This will lead to the capacity of understanding what is doing and what is going wrong during the whole process. Remeber that I can't debug at a kernel level without additional hardware and opening the Omnia.

Actually I tried to strip stack checking calls to see if ther's something related with it, but with no luck.

I will try to find information on this, but there is not much info I'm afraid.

Is there any guru out there that knows how to make it work?

0

Share this post


Link to post
Share on other sites

Posted · Report post

What is exactly additional treatment that you are implementing in your new FMR_IOControl? Is it highly consuming in terms of CPU?

There are several ways to give RDS data to applications (or a virtual COM driver): the easiest and the one actually implemented is a simple copy of the last RDS group taht the original drivers stores in a buffer. It's not CPU intesive (8 byte memory copy) and considering that it is application driven and there's no application that sends the specific command to the driver ... it has no impact on performance except an "if" that checks for the new IOCTL code before calling the original routine.

The development per se was easy, what took me a long time was to understand some functions inside the original code and to identify buffers used (IDA rocks on rev-enginnering!!!). Some hours to adapt ASM for MS assembler, some C programming for the wrapper ... here we are! An average developer with original source code may need 5 to 10 minutes to implement the RDS get function (at this level) and 10 lines of code ... too bad that I'm not an average Samsung developer B) B) (just kidding!!)

My plan is to implement a multiple group buffering with update counter (that is parrtially implemented in the original driver), but first of all I need to get the driver up and running again.

Next attempt is to recomplile the unmodified version then binary compare with the original dll, maybe i missed something there.

0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

MoDaCo is part of the MoDaCo.network, © Paul O'Brien 2002-2015. MoDaCo uses IntelliTxt technology.