|
||||
Re: Need files to trace OpenGl
so i tried to run grp_enable_interrupt and BOOM.. crash!!!
i just dont know the parameters to pass to it. |
This post has been thanked 1 times. |
|
||||
Re: Need files to trace OpenGl
I did some searching for a general _enable_interrupt (assuming that a similar function name would take the same or similar parms), and it looks like most enable_interrupts seem to take int's and global as parms. You could try passing global to it.
I know that it's not necessarily the same functions (and probably differ greatly), but it's worth a shot. |
|
||||
Re: Need files to trace OpenGl
Quote:
In any-case, this is already probably called by android so it may not be worth it for us to continue researching. Other devs are jumping on this as well. The Topaz/blackstone and rhod all have 3d issues. Blackstone at least has the gpu responding but not actually working properly. |
This post has been thanked 1 times. |
|
||||
Re: Need files to trace OpenGl
Quote:
__________________
Phone: Sprint HTC EVO 3D ROM: Synergy Nightly with Own Mods |
|
||||
Re: Need files to trace OpenGl
Quote:
Someone needs to read up on clock-wince.c on the kernel. There are a bunch fo vales set there that may not be correct. I think thats the root cause. |
This post has been thanked 1 times. |
|
||||
Re: Need files to trace OpenGl
no params.. BOOM.. still bombs. so i gave up on that and butchered the clocks-wince.c on the kernel and disabled all calls set_grp_clk(). Same results, so im really convinced now that these calls are useless for our devices.
this is the file im referring to http://www.gitorious.org/linux-on-qu.../clock-wince.c Last edited by [ACL]; 06-24-2010 at 03:02 AM. Reason: include link |
This post has been thanked 1 times. |
|
||||
Re: Need files to trace OpenGl
Quote:
if i wanted to pull all the system boot messages windows mobile does, extend it till haret knocks winmo out of the equasion, then record the boot messages up until Android finishes loading, what would be the best way to do that? doesnt have to be the same file, multiple files is ok, i just wanna see what everything says! |
|
||||
Re: Need files to trace OpenGl
Quote:
For the windows boot messages, you need to dump the following address to a file. use the haret command below to do it. pwf wince.txt 0x16a00000 0xFFFF0 0x16a00000 is for the CDMA rhods. The other ones have a different address. Need to look it up in the wiki. Last edited by [ACL]; 06-25-2010 at 11:25 AM. |
This post has been thanked 2 times. |
|
||||
Re: Need files to trace OpenGl
Here is a quick update. I havent solved the puzzle yet, but i have been working with some of the blackstone devs since they have a 3d issue as well. We figured comparing clock values would help. Turns out the dlls values on both black and rhod are identical. This is disappointing since i figured maybe the clocks were wrong and thats why it was not working.
.text:10004CE8 ; =============== S U B R O U T I N E ======================================= .text:10004CE8 .text:10004CE8 .text:10004CE8 sub_10004CE8 ; CODE XREF: sub_10004EC4+430p .text:10004CE8 ; DATA XREF: .pdata:10008348o .text:10004CE8 STMFD SP!, {R4,LR} .text:10004CEC CMP R0, #0 .text:10004CF0 BEQ loc_10004DB8 .text:10004CF4 LDR R4, =unk_100071DC .text:10004CF8 MOVL R1, 0x11F .text:10004D00 LDR R2, [R4,#8] .text:10004D04 MOV R0, #2 .text:10004D08 LDR R3, [R2,#0x208] .text:10004D0C ORR R3, R3, #0x20 .text:10004D10 STR R3, [R2,#0x208] .text:10004D14 LDR R2, [R4,#8] .text:10004D18 LDR R3, [R2,#0x214] .text:10004D1C ORR R3, R3, #0x20000 .text:10004D20 STR R3, [R2,#0x214] .text:10004D24 LDR R3, [R4,#8] .text:10004D28 STR R1, [R3,#0x284] .text:10004D2C BL sub_10004CAC .text:10004D30 LDR R2, [R4,#8] .text:10004D34 LDR R3, [R2,#0x84] .text:10004D38 ORR R3, R3, #0x800 .text:10004D3C STR R3, [R2,#0x84] .text:10004D40 LDR R2, [R4,#8] .text:10004D44 LDR R3, [R2,#0x84] .text:10004D48 ORR R3, R3, #0x80 .text:10004D4C STR R3, [R2,#0x84] .text:10004D50 LDR R2, [R4,#8] .text:10004D54 LDR R3, [R2,#0x84] .text:10004D58 ORR R3, R3, #0x200 .text:10004D5C STR R3, [R2,#0x84] .text:10004D60 LDR R2, [R4,#8] .text:10004D64 LDR R3, [R2] .text:10004D68 ORR R3, R3, #8 .text:10004D6C STR R3, [R2] .text:10004D70 LDR R2, [R4,#8] .text:10004D74 LDR R3, [R2,#0x290]! .text:10004D78 BIC R3, R3, #4 .text:10004D7C STR R3, [R2] .text:10004D80 LDR R2, [R4] .text:10004D84 LDR R3, [R2,#0x80] .text:10004D88 BIC R3, R3, #1 .text:10004D8C STR R3, [R2,#0x80] .text:10004D90 LDR R2, [R4,#8] .text:10004D94 LDR R3, [R2,#0x208] .text:10004D98 BIC R3, R3, #0x20 .text:10004D9C STR R3, [R2,#0x208] .text:10004DA0 LDR R2, [R4,#8] .text:10004DA4 LDR R3, [R2,#0x214] .text:10004DA8 BIC R3, R3, #0x20000 .text:10004DAC STR R3, [R2,#0x214] .text:10004DB0 LDMFD SP!, {R4,LR} .text:10004DB4 BX LR All those values above can be found on our kernel which now makes me think i have to look at something else. The weird thing is that when we dump clocks from haret, it does not match the above values .. lol so we have asm that is lying? or there is another call we are missing and not analysing . Whatever it is, the search continues. |
This post has been thanked 2 times. |
|
|
|