Need files to trace OpenGl
 

I'm trying to get some files needed to trace the opengl on the Rhodium. Can anyone help me?

COREDLL.DLL
MMMAP.DLL
WCE_REX.DLL
DIAG_LSM.DLL
REMOTE_APIS_CLNT.DLL
AHI2DATI.DLL
CLKREGIM.DLL
MSM_CLK.DLL
WCE_PMEM.DLL

please dont ask me to rip these off myself. I just need someone to do me the favor. Thanks a bunch.

Re: Need files to trace OpenGl
 

how do we get these... couldnt copy them with total commander

Re: Need files to trace OpenGl
 

i have no clue. im sure someone with cooking experience might know

Re: Need files to trace OpenGl
 

http://forum.xda-developers.com/show....php?p=1571715 sorry i don't have the time

Re: Need files to trace OpenGl
 

Lets hope someone has the time. I want to spend every free minute i have tracing those rpc calls to activate the gpu instead of dumping roms.. yuck !!

Re: Need files to trace OpenGl
 

I'll work on dumping the files late tonight/early tmrw morning.

Re: Need files to trace OpenGl
 

Here they all are.

Pulled from OEMDrivers and the XIP of a 6.5 build (21897) from Calk's 1.6 R3 for the TP2.

Oh and send me a message if you need anything else.

Re: Need files to trace OpenGl
 

beat me to it. good get.

Re: Need files to trace OpenGl
 

Thanks for the help. I took a look at the dependencies to see what functions called but i'm afraid nothing really useful came out.

I don't think any other developer is looking into this so its hard to even compare notes with anyone.

Re: Need files to trace OpenGl
 

Looks like 3d may be plagued by the same issue we are having with sound.

On linux if you do cat /proc/interrupts. You will see hw3d has 0 which is the same as adsp.

So this means more time tracing stuff on haret.

Re: Need files to trace OpenGl
 

maybe this is a dumb question, but is there anywhere exactly we can see exactly what haret does? perhaps there isnt a problem with the builds per-say, but something haret does that the TP2 doesnt like. such as with sound, since its calling the asdp and its replaying already functioning, or already operating, i forget which, maybe haret needs to be modified. does hw3d give an error or does it just show that it doesnt exist to call?

Re: Need files to trace OpenGl
 

Hw3d at this point just doesnt respond. We have the drivers and code that works on other devices but something about the tp2 that we dont have working 100%.

On wince the gpu runs when we tell it to. It doesnt run all the time. So the wince kernel or maybe one of the dlls makes a call that activate the gpu. Once its all done, the gpu goes down again. So we are missing that call to activate.

I do know that harent isnt the issue.

Re: Need files to trace OpenGl
 

post one has all of the files that make a call to the gpu, or just the ones you think? feel free to ignore me if i am making you lower your brain capacity at any rate, but what exactly are you trying to factor out? the exact call to the gpu? or the location of that call? or what chip(s) activate the gpu?

Re: Need files to trace OpenGl
 

Hmm. All of the above?

ahi2dati uses all of those dlls. a while back i made a small app to load ahi dll directly to display stuff on screen. It worked and i also noticed all these other dlls loading. So i wanted them to see what kinda calls ahi makes.

Since we dont know whats missing, i kinda have to look all over the place. I was busy for father's day so i didnt get a chance to do anything. Hopefully this week i can dive back in.

Re: Need files to trace OpenGl
 

If anyone wants to help figuring this out. Feel free to jump in.

So thanks to fathers day i didn't get a chance to dig deep. But i did dump some information before and during 3d operation.

http://pastebin.com/btqgbBgH

Both top chunks are made with the command below on haret console. I'm looking for "..000030 " or all rpc related info.

od -A x -t x4 -w16 mysmem | grep "..000030 "

One of them is with no 3d, the other is with 3d running. There are few differences.

The last part is the wince dmesg right after 3d is activated again. Note there are some rpc calls as well. Anyone want to help there?

Re: Need files to trace OpenGl
 

Don't know if this helps, but I was looking through DDI.dll in IDA, and it has

It also has:
being imported from ahi2dati
May be helpful as well.

A lot of things seem to be printing to the NKDebugconsole (my interpretation of ASM,which I know very little about).

Hope this helps a little, if not ignore please.

Edit: I'm looking through the nk.exe and there's a SPYapi and a GuardDog. Could this effect how haret boots at all?

Re: Need files to trace OpenGl
 

I dumped the whole wince dmesg for the rhodium. Is this what you mean by NKDebugconsole ?

http://pastebin.com/M1Ad4YMv

I'm no asm dev, so its hard for me to make out that output. How well do you understand it? can you at least help me reverse engineer some of the functions? I've been able to call gles_oem_eglInitialize before assuming it just takes an int as a parameter, but i havent done gles_init yet because i dont know what parameters it takes.

Re: Need files to trace OpenGl
 

ive been decompiling all of the .dll files you referenced. im not an asm dev, but I have been noticing that almost all of them all refer back to the clkregim. the clkregim makes several calls that register usb, uart, etc, but there are a few calls im not sure what they do. it seems like the clkregim does alot of clk switching, registering for cpu recources, and switch adsp_clk, etc.

what i dont understand is this dll references another resource, remote_apis_cInt. using that remote_ it makes a call clk_regime_sec_sel_icodec_clk.

dont know if this is any help, but im going to keep looking for anything suspicious. keep us posted on anything you find!

Re: Need files to trace OpenGl
 

i see the same thing. However i only see ahi2dati use 3 functions on clkregim.

clk_regime_deregister_for_cpu_resource
clk_regime_msm_disable
clk_regime_msm_enable

Do you see others?

Check this out. may help you understand those calls

http://htc-linux.org/wiki/index.php?title=MSM_RPC

Re: Need files to trace OpenGl
 

im not sure. there might have been more. id have to look when i get off of work.

Re: Need files to trace OpenGl
 

Can you dismember the android version as well? I have a rough idea of what ahi calls are implemented but it would be nice to get an official list.

libgles_qcom.so is the android version.

Re: Need files to trace OpenGl
 

One thing I had noticed when looking at IDA, is that it was using Virtual address to set and retrieve stuff for 3d. I know you were trying to enable it directly through mem, I don't know if you were trying to change physical or virtual address.

Re: Need files to trace OpenGl
 

Doesnt matter. We have the virtual to phys mem table available. So i can access it through physical.

Re: Need files to trace OpenGl
 

I was looking through ahi2dati again, have you tried using the AsicSetProperty to set 3d? I know the GetProperty uses cases (Case0 calls GLESConfig), Set Property may have similar calls. I'll try to do some research to see if I can figure out how to find out what different functions take as parms.

You can also try setting AsicInit first.

Re: Need files to trace OpenGl
 

i can. might be an interesting find. i need a fresh boot anyways. is there a particular build you want me to use?

Re: Need files to trace OpenGl
 

they are all the same file. Pretty much every 7x00 android device uses that driver.

The list of exported functions i have is longer. Way longer than the wince version. So far both drivers return the same information when you call an ahi functions. I'm trying to find one that actually returns something different.

The good news is that the gpu responds to the calls. But that's old news. Do you guys have your android dev environs ready? i can share my test code if everyone wants to start compiling test apps.

Re: Need files to trace OpenGl
 

ill have mine finished by tonight, so no worries there. do you still want that list of functions?

Re: Need files to trace OpenGl
 

sure. Maybe someone else is reading this and wants to jump in.

Re: Need files to trace OpenGl
 

thats the exports i get from libgles_qcom.so

Re: Need files to trace OpenGl
 

This is good. The function grp_enable_interrupt might help. Right now there are no interrupts, so if we can just figure out what to pass to this function we might move a step forward. Thanks for the list, i'm actually missing some of these so im glad we got this done.

Re: Need files to trace OpenGl
 

thats good. im working on going through a unix to linux shell programing book so im not all that savvy on linux just yet, but once i get a small step in the right direction im usually pretty quick on the uptake.

something i did notice is libgles imports alot of info from libm.so. what particular function does libm usually handle?

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.

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
 

Tried.. BOOM crash.. lol.

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.

Re: Need files to trace OpenGl
 

Maybe some other things have to be properly initialized before that call is made... are you sure that it even takes parms?

Re: Need files to trace OpenGl
 

ill try with no params tonight.

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.

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

Re: Need files to trace OpenGl
 

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
 

Right now the glemson kernel has ramconsole disabled, so if you do want to have it enabled you will need to modify the kernel. Or you can do a "dmesg" on the shell when android boots.

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.

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.