Jump to content

TMC


Guest osuijk

Recommended Posts

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Guest BeamRider

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:

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Guest BeamRider

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

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

Link to comment
Share on other sites

Guest BeamRider

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)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

Guest Stacker007

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

Guest BeamRider
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)

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

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.