155 replies to this topic

[dezmo]

BeamRider, on Nov 12 2008, 14:50, said:

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

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

[balles]

balles, on Nov 12 2008, 16:33, said:

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

PXA320 Summary : http://embedded-seo....controller.html
XScale debug manual (emulator manual, maybe there is some useful info for you): http://www.abatron.c...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/...-.2006.v3ar.pdf


Let me know if it helps.

Two more additions:

Intel XScale page (lots of low-level manuals): http://www.intel.com...gn/intelxscale/
Marvell PXA320 page (maybe registering to the site there is useful information, even if I don't really think so): http://www.marvell.c...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.c...es/default.aspx

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

[Stacker007]

hm, sorry, duplicate

Edited by Stacker007, 14 November 2008 - 03:35 PM.

[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, 14 November 2008 - 03:33 PM.

[BeamRider]

balles, on Nov 13 2008, 10:17, said:

Two more additions:

Intel XScale page (lots of low-level manuals): http://www.intel.com...gn/intelxscale/
Marvell PXA320 page (maybe registering to the site there is useful information, even if I don't really think so): http://www.marvell.c...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.c...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)

[nok6280a]

Hello BeamRider,

Is there nobody from Samsung who can help you?

[balles]

BeamRider, on Nov 16 2008, 09:56, said:

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?

[BeamRider]

Quote

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

Quote

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

[balles]

BeamRider, on Nov 17 2008, 16:20, said:

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?

  

BeamRider, on Nov 17 2008, 16:20, said:

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?

[BeamRider]

Quote

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   (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.

[minhgi]

Hey there....

How the progress on the TMC driver....I hope that you can achieve on what you doing...

I would definitely by you a drink later..

Talking about drink...I need to do it for someone on this forum!

[balles]

BeamRider, on Nov 18 2008, 00:12, said:

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.

I hope it is just a trivial bug...

For the moment I have not found any useful doc/source code related to FM receiver from the development point of view.

Concerning the whole project, are you still wanting to implement the Royaltek interface, or I have not well understood what you are doing? Maybe you don't need to touch the FM driver.

Now, with your explanations, and if you want to implement this Royaltek protocol, it is maybe possible to create a software (a kind of GPSGate but in the case of TMC), use the FM driver as FM radio does, just taking the RDS group that concerns TMC if it must be done (I don't know if this filter is implemented at this level or if it is at the application level that the filter is needed) and the implementation of the Royaltek protocol itself.

I don't have enough information to know if what I said is feasible or not.

[BeamRider]

Right, you are vey close to the point ... implementing a virtual com port like GPS gate or them mux GPS com port given with WM is very easy. If you google around you'll easily find ready to use code, but to make it operate RDS data coming from FM tuner is mandatory.

Unless I missed something very big, original driver does not leave access to its RDS data buffers, that's why I'm wrapping it. The driver processes RDS data to extract what the tuner software needs to operate (basically station name/ID and AF list), puts this data into registry (!!!) and that's all. Once I have a function that returns raw RDS data, I could easly write I very simple virtual COM driver that can emulate GNS and Royaltek (add what you like ) devices.

Secondary objective is to remove the check for the hearphone cable inside the driver, this will not make tuner work without an antenna but opens the possibility to plug an home made antenna  (ie something embedded in the charging cable) leaving the audio path as is.

I'm sure that is a trivial bug or just a wrong toolchain configuration ... but I have no indicators on where the problems is and I need to try and check every possibility that comes up. Now it's time to go back to VS

[BeamRider]

BINGO!!! I found the problem ... it was due to a regular expression i used to convert ASM syntax!! One line out of 11000!!

The NEW driver is now working with original software, logging operations and givings RDS buffers to a test application I wrote in about 5 minutes I think that's enough for today, I'm excited to see the code working but I'm a little bit tired and bed is calling

A little bonus ... the log of the radio driver operations:

FM Radio - resource	allocation, success
FM Radio - InitializeFMRadioThread,	success
FM Radio - Init, done v001J1 
FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00032F80]
FM Radio - IOControl, hOpenContext[0x00032F80] dwCode[0x00321000]
FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x000335D0]
FM Radio - Close, hOpenContext[0x000335D0]
FM Radio - si470x_tune, intr failed
FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00825230]
FM Radio - Open, hDeviceContext[0x00000001] hOpenContext[0x00054100]
FM Radio - IOControl, hOpenContext[0x00054100] dwCode[0x00220004]
FM Radio - IOCTL_FMRADIO_TURN_ON, region[1]
FM Radio - EnableFMRadioChipInterface success
FM Radio - addr[0x00] data[0x1242]
FM Radio - addr[0x01] data[0x1200]
FM Radio - addr[0x07] data[0x0100]
FM Radio - si470x_reg_read fail reset, addr[0x120E40E1]
FM Radio - addr[0x00] data[0x1242]
FM Radio - addr[0x01] data[0x1253]
FM Radio - addr[0x07] data[0x3C04]
FM Radio - si470x_InterruptThread start
FM Radio - si470x_reg_write	fail reset, addr[0x00]
FM Radio - si470x_deinitRdsVars, success
FM Radio - si470x_trackRdsAfList Freq[1] Rssi[1296]
FM Radio - addr[0x02] data[0x0801]
FM Radio - addr[0x04] data[0xD814]
FM Radio - addr[0x05] data[0x0510]
FM Radio - addr[0x06] data[0x0012]
FM Radio - si470x_trackRdsAfList afList[FM Radio - si470x_seek, intr failed
FM Radio - si470x_initRdsVars, success
FM Radio - addr[0x06] data[0x0112]
FM Radio - si470x_powerdown, ENABLE	bit not	cleared
FM Radio - si470x_powerdown, Firmware Rev[1]
DrvLib : SendMessageToAudio	- NumDevs[2]
DrvLib : SendMessageToAudio	- Index[0] Pname[Audio Output]
DrvLib : SendMessageToAudio	- Send Msg[1037] Param[0x00000000:0x00000000]
FM Radio - set volume[0x00], done
FM Radio - turn on,	done
FM Radio - IOControl, hOpenContext[0x00054100] dwCode[0x0022002C]
FM Radio - IOCTL_FMRADIO_ENABLE_STEREO
FM Radio - si470x_configure, done
FM Radio - IOControl, hOpenContext[0x00054100] dwCode[0x00220030]
FM Radio - IOCTL_FMRADIO_ENABLE_AF
FM Radio - IOControl, hOpenContext[0x00054100] dwCode[0x00220028]
FM Radio - IOCTL_FMRADIO_FORCE_SPEAKER
DrvLib : SendMessageToAudio	- NumDevs[2]
DrvLib : SendMessageToAudio	- Index[0] Pname[Audio Output]
DrvLib : SendMessageToAudio	- Send Msg[1037] Param[0x00000000:0x00000000]
FM Radio - IOControl, hOpenContext[0x00054100] dwCode[0x0022000C]
FM Radio - IOCTL_FMRADIO_TUNE_TO
FM Radio - addr[0x0B] data[0x0075]
FM Radio - si470x_regional_cfg[9920],	done
DrvLib : SendMessageToAudio	- NumDevs[2]
DrvLib : SendMessageToAudio	- Index[0] Pname[Audio Output]
DrvLib : SendMessageToAudio	- Send Msg[1037] Param[0x00000000:0x00000000]
FM Radio - tune to [9920], done
FM Radio - IOControl, hOpenContext[0x00054100] dwCode[0x00220020]
FM Radio - IOCTL_FMRADIO_SET_VOLUME
FM Radio - addr[0x06] data[0x0112]
FM Radio - si470x_powerdown, ENABLE	bit not	cleared
DrvLib : SendMessageToAudio	- NumDevs[2]
DrvLib : SendMessageToAudio	- Index[0] Pname[Audio Output]
DrvLib : SendMessageToAudio	- Send Msg[1037] Param[0x00000000:0x00000000]
FM Radio - set volume[0x08], done
FM Radio - si470x_seek, intr failed
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - IOControl, hOpenContext[0x00054100] dwCode[0x00220028]
FM Radio - IOCTL_FMRADIO_FORCE_SPEAKER
DrvLib : SendMessageToAudio	- NumDevs[2]
DrvLib : SendMessageToAudio	- Index[0] Pname[Audio Output]
DrvLib : SendMessageToAudio	- Send Msg[1037] Param[0x00000000:0x00000000]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - IOControl, hOpenContext[0x00054100] dwCode[0x0022000C]
FM Radio - IOCTL_FMRADIO_TUNE_TO
FM Radio - si470x_seek, STC	bit not	cleared
FM Radio - addr[0x0B] data[0x0075]
FM Radio - si470x_regional_cfg[9920],	done
FM Radio - tune to [9920], done
FM Radio - si470x_seek, intr failed
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
FM Radio - update_clock[22:34 0_54788 2]
...

As you can see, sometimes the intr is still failing, I think it's physiological because the behaviour is the same as before! Maybe logging is interfering with interrupt handling, but I don't care because I will disable logs ASAP.

[jonboyuk]

You are amazing!

[nok6280a]

Man you are really great!!!

[balles]

For your previous post, I fully understand now why you need to modify the driver. Obviously, you are right. I wonder how much time have you taken to discover that RDS data is not sent as raw data outside the driver!

BeamRider, on Nov 19 2008, 01:02, said:

BINGO!!! I found the problem ... it was due to a regular expression i used to convert ASM syntax!! One line out of 11000!!

You see? a trivial bug

Anyway, congratulations! you have performed a good work of investigation (or should I say "hacking"?). I must also thank you for the explanations you gave me about WM programming and in general about your project.

[BeamRider]

Quote

For your previous post, I fully understand now why you need to modify the driver. Obviously, you are right. I wonder how much time have you taken to discover that RDS data is not sent as raw data outside the driver!

It's more using the right tool ... at the right time Before starting this project I known nothing about ARM assembler (but I know x86 and some others micros) and nothing about WM kernel. It's fun and easy to learn (to the extent I need) thanks to people sharing knowledge, ideas, opinions and sample code. You see, sharing knowledge always pay back: I solved the issue!

Quote

Anyway, congratulations! you have performed a good work of investigation (or should I say "hacking"?). I must also thank you for the explanations you gave me about WM programming and in general about your project.

It's only reverse-engineering, I think that the real meaning of hacking is more related to break/bypass something made to not be broken and I do not pretend to be an hacker.

Thank you all for the support, but it's not yet time to party ... at least until we see TMC working with TT/iGo!

[zemrwhite2]

That is really great work !

BeamRider, on Nov 19 2008, 11:08, said:

... and I do not pretend to be an hacker.

IMHO what you did is hacking into that driver

[jonboyuk]

How's this coming on?