Why sound isn't working on the TP2.

[daddymikey1975]

Originally Posted by [ACL]

If we have gone as far as disassembling the windows dlls, i can assure you we have examined every kernel you can get your hands on.

(Just brainstorming Thank you again for all the work that you and the others have done )

[xboxp]

hi all, I would like to help on this problem. Is there a schematic for the touch pro 2 hardware some where?

[[ACL]]

not that i can think of.

Most of the info we have is on the wiki

htc-linux.org/wiki

[jonpry]

Originally Posted by [ACL]

How far did you get on making rpc calls related to audio? I know you were successful with the gps obviously but i haven't been able to make any calls. One example was trying to enable grp rail via rpc (A9 would crash).

RPC really isn't a problem anymore since we have a more or less complete implementation of oncrpc.dll and are able to load the native remoteapisvc.dll and remoteapiclient.dll. But after doing all of that, all it really did is verify that the reversed engineered RPC calls for sound were good enough.

wavedev.dll eventually makes a kernel io control that i believe returns the AMSS version to the drivers, but I don't know how this number is represented or what it should be. Perhaps that is making some part of the driver not work correctly, but it doesn't error.

There are also some strange calls to DEX, SPM, and KLM. In theory DEX an SPM are working, but I didn't verify it very well. There is some question as to what it is for. Maybe cycling power on the DSP?

I have no idea what KLM is. Captnoord said it is MicroP, but I couldn't find a dll that exports a KLM driver. Some massive amount of data is transfered to it, whatever it is. Maybe microcode? Maybe something on the i2c bus.

I don't know what GRP rail is. Audio doesn't crash A9. A9 seems to be happy with what we are doing, AUDPP starts up and says it is ready to play, but DSP never consumes the buffer.

[[ACL]]

Originally Posted by jonpry

RPC really isn't a problem anymore since we have a more or less complete implementation of oncrpc.dll and are able to load the native remoteapisvc.dll and remoteapiclient.dll. But after doing all of that, all it really did is verify that the reversed engineered RPC calls for sound were good enough.

wavedev.dll eventually makes a kernel io control that i believe returns the AMSS version to the drivers, but I don't know how this number is represented or what it should be. Perhaps that is making some part of the driver not work correctly, but it doesn't error.

There are also some strange calls to DEX, SPM, and KLM. In theory DEX an SPM are working, but I didn't verify it very well. There is some question as to what it is for. Maybe cycling power on the DSP?

I have no idea what KLM is. Captnoord said it is MicroP, but I couldn't find a dll that exports a KLM driver. Some massive amount of data is transfered to it, whatever it is. Maybe microcode? Maybe something on the i2c bus.

I don't know what GRP rail is. Audio doesn't crash A9. A9 seems to be happy with what we are doing, AUDPP starts up and says it is ready to play, but DSP never consumes the buffer.

Sending anything to 0x3000000F 0x2C is for grp rail. But not to worry about that since i verified its actually on. The only reason i mentioned it is because it would bomb out if i tried to enable it that way.

On wavedrv.dll, did you get this info through disassembly? Cotulla has been very cool in verifying some ASM for me. Maybe he can do the same as long as we provide him the dll.

There is some dood about to sell this tp2. Lets get it so you can jtag that beotch ..lol.

[jonpry]

I disassembled some of it. Mostly it is that I have a working implementation of windows ce under linux. Just one step at a time looking at the asm and seeing what it expects from windows ce, and getting it to work. Now I have logs of every function the driver makes, what memory it accesses, what parameters it uses, etc.

And as usual, it appears to work, but no interrupt.

[xboxp]

hello all, does this android use ALSA for the sound library? I haven't look at the code yet or know where to find them, can someone point me in the right direction?

[docnas]

http://htc-linux.org/wiki/index.php?..._based_devices

try here

[[ACL]]

Originally Posted by jonpry

I disassembled some of it. Mostly it is that I have a working implementation of windows ce under linux. Just one step at a time looking at the asm and seeing what it expects from windows ce, and getting it to work. Now I have logs of every function the driver makes, what memory it accesses, what parameters it uses, etc.

And as usual, it appears to work, but no interrupt.

Haha .. its as if you and i are on the same boat. I did the same for 3d, but no interrupt.

Recently ive actually looked into the irq.c code to compare dumps of 0xC0000000. I realize that wince has alot of irqs enabled while linux doesnt. I'm wondering if its because the drivers themselves are actually supposed to enable the irq. I know for 3d for example that is the case. Hw3d is supposed to enable the irq, but im gonna try to see if i should have it enabled before like wince. Have you tried this for sound ?

For example this is a dump of wince irqs MSM_VIC_BASE

c0000000 | 00000000 00000000 00000000 00000000 | ................
c0000010 | 55fd0161 00008003 00000000 00000000 | a..U............
c0000020 | 00000000 00000000 00000000 00000000 | ................
c0000030 | 00000000 00000000 00000000 00000000 | ................
c0000040 | f5e401ff 0000003c 00000000 00000000 | ....<...........
c0000050 | 00000000 00000000 00000000 00000000 | ................
c0000060 | ffffffff 00000001 00000000 00000000 | ................
c0000070 | 00000000 00000000 00000000 00000000 | ................
c0000080 | 00000000 00000000 00000000 00000000 | ................
c0000090 | 00000000 00000000 00000000 00000000 | ................
c00000a0 | 80000080 00000034 00000000 00000000 | ....4...........
c00000b0 | 00000000 00000000 00000000 00000000 | ................
c00000c0 | 00000000 00000000 00000000 00000000 | ................
c00000d0 | ffffffff ffffffff 00000000 00000000 | ................
c00000e0 | 00000000 00000000 00000000 00000000 | ................
c00000f0 | 00000000 00000000 00000000 00000000 | ................

Notice c0000010 has 55fd0161 in winmo and under linux we only have 4f0100a1. Thats alot of disabled interrupts.

[jonpry]

When wavedev.dll boots up, it makes 3 calls to InterruptInitialize() with strange parameters. I couldn't figure out the mapping between the interrupts in wince and hardware interrupts. Unfortunately the code that does the mapping is somehow built into nk.exe, which has no entry points and therefore is difficult to reverse.

I tried enabling more interrupts to see if it was happening somewhere else. I only got to 5 more or so. None seemed to be it. They have to be enabled one at a time because some of them cannot be cleared and hang the kernel.

Phh assured me that the interrupt numbers were correct and that they were checked in multiple ways multiple times. But I never was able to check them myself.