Why sound isn't working on the TP2.

[[ACL]]

Originally Posted by 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.

I just spoke to phh about it. I'm going to try to enable some irqs by hand to see if it helps.

We did disassembled nk.exe. I'll look for those functions calls and see what they do.

[Reefermattness]

Originally Posted by [ACL]

I just spoke to phh about it. I'm going to try to enable some irqs by hand to see if it helps.

We did disassembled nk.exe. I'll look for those functions calls and see what they do.

Hi guys! Great work in here by the way! I watch this thread all the time.

One quick question for ya. I see you guys working with these .dlls, and I need both htcservices.dll and wavedev.dll. I was hoping you guys would be kind enough and could direct me on how to acquire them. Plz?

[[ACL]]

Originally Posted by Reefermattness

Hi guys! Great work in here by the way! I watch this thread all the time.

One quick question for ya. I see you guys working with these .dlls, and I need both htcservices.dll and wavedev.dll. I was hoping you guys would be kind enough and could direct me on how to acquire them. Plz?

Sup Reef.. try this link out. It should have all the oem dlls

http://www.4shared.com/file/39sLIx_Z/OEMDrivers.html

[jonpry]

ACL, i have my kernel setup with the DSP interrupt always enabled, and when it goes off it just writes to console that the mysterious event has happened, but it still does not work.

I have disassemblies of NK as well, but they don't seem to do any good. I can't figure out what code handles a particular sys call.

All implementatations are required to implement this http://msdn.microsoft.com/en-us/library/ms904913.aspx, which does the interrupt mapping from user to hardware. I couldn't find this in NK.

Maybe writing some windows ce code that hooks all of the interrupts and then checks for changes in VIC memory would work to figure out what the mapping is.

[ahuynh]

this is exciting, thanks guys

[kaos]

keep up the good work guys. you give us all hope.

[hyperfire21]

this thread is so important to me i check it multiple times daily..

[[ACL]]

Originally Posted by jonpry

ACL, i have my kernel setup with the DSP interrupt always enabled, and when it goes off it just writes to console that the mysterious event has happened, but it still does not work.

I have disassemblies of NK as well, but they don't seem to do any good. I can't figure out what code handles a particular sys call.

All implementatations are required to implement this http://msdn.microsoft.com/en-us/library/ms904913.aspx, which does the interrupt mapping from user to hardware. I couldn't find this in NK.

Maybe writing some windows ce code that hooks all of the interrupts and then checks for changes in VIC memory would work to figure out what the mapping is.

That looks really familiar. Check this out.

.text:80067BC0 sub_80067BC0 ; CODE XREF: sub_80056E84+64p
.text:80067BC0 ; sub_80056E84+8Cp ...
.text:80067BC0 STMFD SP!, {R4,R5,LR}
.text:80067BC4 MOV R4, R0
.text:80067BC8 MOV R5, #1
.text:80067BCC CMP R4, #0x1B
.text:80067BD0 BEQ loc_80067BF0
.text:80067BD4 MOV R1, #0x84000000
.text:80067BD8 MOV R0, #0x800
.text:80067BDC BL sub_8006B6C0
.text:80067BE0 CMP R0, #0
.text:80067BE4 LDRNE R0, =aOeminterrupten
.text:80067BE8 SUBNE R1, R4, #0x10
.text:80067BEC BLNE sub_8005364C

Eventually this gets called

sub_800275AC
MRS R1, CPSR
CMP R0, #0
ORREQ R2, R1, #0x80
BICNE R2, R1, #0x80
MSR CPSR_cf, R2
ANDS R1, R1, #0x80
MOVEQ R0, #1
MOVNE R0, #0
RET

Ahh, now that looks very similar to this below. So i'm pretty sure thats what's actually enabling the interrupts. We might wanna check with Cotulla or Phh. Either way i think we already do this in our code.

/* NewState=1 will enable IRQ, NewState=0 will disable IRQ */
/* ARM core must be in a privileged mode, e.g. supervisor */
void ChangeIRQ(unsigned int NewState)
{
int my_cpsr;
__asm
{
MRS my_cpsr, CPSR /* get current program status */
ORR my_cpsr, my_cpsr, #0x80 /* set IRQ disable bit flag */
BIC my_cpsr, my_cpsr, NewState, LSL #7 /* reset IRQ bit with new value */
MSR CPSR_c, my_cpsr /* store updated program status */
}
}
http://infocenter.arm.com/help/index...qs/ka3540.html

I have reason to believe that the VIC mapping is similar to the 7200. But i wouldnt mind testing with some wince code. Just disabling via api calls and reading bit changes should suffice.

Bits Name Description
31 tChscrn2 Touchscreen controller interrupt 1 of 2 (includes pendown (penirq_n)
30 TChscrn1 Touchscreen controller interrupt 1 of 2 (includes pendown (penirq_n)
29 tchscrn_ssbi Touchscreen controller interrupt 1 of 2 (includes pendown (penirq_n
28 Keysense Keypad key press detected
27 sdc2_1 Secure digital controller 2, source 1
26 sdc2_0 Secure digital controller 2, source 0
25 sdc1_1 Secure digital controller 1, source 1
24 sdc1_0 Secure digital controller 1, source 0
23 adsp_a9a11 ADSP source to both ARM9 and ARM11
22 adsp_a11 ADSP source to ARM11
21 adm_aarm Applications data mover
20 graphics Graphics engine source
19 mdp Mobile display processor source
18 mddi_client MDDI client (camera) source
17 mddi_ext MDDI external display source
16 mddi_pri MDDI primary display source
15 usb_otg USB on-the-go
14 uart3_rx Activity start on UART3 interface
13 UART2_RX Activity start on UART2 interface
12 uart1_Rx Activity start on UART1 interface
11 uart3 UART3 controller source
10 uart2 UART2 controller source
9 uart1 UART1 controller source
8 dEBUg_timer_exp Debug GP timer has expired
7 gp_timer_exp RTOS GP timer has expired
6 a9_m2a_6 Interprocessor interrupt source from modem ARM
5 a9_m2a_5 Interprocessor interrupt source from modem ARM
4 a9_m2a_4 Interprocessor interrupt source from modem ARM
3 a9_m2a_3 Interprocessor interrupt source from modem ARM
2 a9_m2a_2 Interprocessor interrupt source from modem ARM
1 a9_m2a_1 Interprocessor interrupt source from modem ARM
0 a9_m2a_0 Interprocessor interrupt source from modem ARM

I tried enabling irqs on linux today by changing those bits and no luck with 3d. However i do notice sometime the device freezes when enabling 3d app. This can be good or bad, i just cant get any info since the phone crashes.

[deechte]

Just wanted to let you know I appreciate your work and effort! Keep going guys!

[jonpry]

So the interrupt indentifiers in WinCE for audio are 0x3d, 0x3e, 0x3d, 0x40 and 0x33. Not sure what they do individually. I could figure it out if need be. But even if we could just find out what VIC entries those are for it would narrow it down quite a bit.

Again, I have no way to compile code for WinCE. I wouldn't mind writing the code if somebody wants to get it running. Disabling the already enabled interrupts will likely crash the phone sooner or later. In particular if it tries to play a sound. It seems as though we can disable another processes interrupt handler, but without getting its event id, there is no way to restore it.