Need files to trace OpenGl

[newkidd]

Originally Posted by [ACL]

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.

what about tricking the 3d chip. if 3d was activated through a program that activated hw3d, then booted haret, tell android that hw3d is already initialized, then give it the call to turn it off.

since im backtracking through the IRC logs and everything else i dont know what you have tried and havent tried.

[[ACL]]

Originally Posted by newkidd

what about tricking the 3d chip. if 3d was activated through a program that activated hw3d, then booted haret, tell android that hw3d is already initialized, then give it the call to turn it off.

since im backtracking through the IRC logs and everything else i dont know what you have tried and havent tried.

That actually has been tried many times in the past by the other devs. I tried it myself just incase, and no results.

I'm going to explain what happens during boot so everyone can understand why this is a pain.

Once haret loads, wince is no longer in-charge of the device. We must enable and disable everything.. kernel starts loading and it loads the appropriate drivers. The kernel also has to re-enable all the clocks needed for regular function. There are tons of clocks, but the ones we were concentrating on are the gpu clocks. Ok, so we set the clocks according to the assembly dump you see. Now once Linux is up (not android since thats just a layer above which we arent worried about yet) we should be able to run basic GL test applications. I have written a few that work on other devices, so they are valid apps. When we run these apps on the tp2, the gpu does not respond.

The gpu has an interrupt assigned to it. So lets say we have an app that uses 3d, the gpu should respond back and do its magic. Right now for us it does not. So all the test applications just loop and loop not actually showing anything on screen.

You can verify this by typing "cat /proc/interrupts" and looking for hw3d and a nice fat 0 next to it. Right now the Rhod and Topaz are the only ones suffering from this.

Hope that makes sense.

Also if you are interested in seeing how that ASM relates to the .c file in the kerne. Take a look at what is being done now. You will notice the values are the same.

REG_OR( MSM_AXI_RESET, 0x20 );
REG_OR( MSM_ROW_RESET, 0x20000 );
REG_SET( MSM_VDD_GRP_GFS_CTL, 0x11f );
REG_OR( MSM_GRP_NS_REG, 0x800 );
REG_OR( MSM_GRP_NS_REG, 0x80 );
REG_OR( MSM_GRP_NS_REG, 0x200 );
REG_OR( MSM_CLK_CTL_BASE, 0x8 ); // grp idx
REG_AND( MSM_RAIL_CLAMP_IO, 0x4 );
REG_AND( MSM_PRPH_WEB_NS_REG, 0x1 ); // Suppress bit 0 of grp MD
REG_AND( MSM_AXI_RESET, 0x20 );
REG_AND( MSM_ROW_RESET, 0x20000 );

[[ACL]]

Got plenty of work to do. Can anyone compare to see if there are binary differences between ddi.dll from rhod to lets say a (kovsky or blackstone)?

[veeeee]

I compared the blackstone ddi.dll to the rhodium ddi.dll and there are differences. I am attaching the .dll's in case you want to inspect them yourself.

[[ACL]]

Originally Posted by veeeee

I compared the blackstone ddi.dll to the rhodium ddi.dll and there are differences. I am attaching the .dll's in case you want to inspect them yourself.

Awesome.. thanks man.

i wont be able to do much tonight.. maybe the other guys here can help disassemble and check out the differences?.

ill definitely take a look tomorrow.

[[ACL]]

how do i see these files ? i see just bunch of s00X stuff.. i need the dlls itself.

[WoZZeR999]

Originally Posted by [ACL]

how do i see these files ? i see just bunch of s00X stuff.. i need the dlls itself.

They need to be recmodded. Here they are.

[[ACL]]

thanks man. I compared them and they are way different. Too different for me to even tell whats going on.

reason i wanted to compare was because the blacstone currently has a working interrupt while we dont. Unfortunately i dont know enough about arm asm to tell whats going on. i'll need to hand this over to some of the asm gurus.

In other news, i got AhiEnableSoftInterrupt to run on both wince and android. Unfortunately after testing it turns out it was already enabled on android. So why dont we have 3d? it boggles the mind i tell you. It looks like that calls is only for the driver itself .. it doesnt make any calls to the system to actually enable interrupts.

[newkidd]

ill pull them both apart and see if there are any major differences worth finding. ive been needing to boot back to windows and reformat a hard drive to use on my Wii, i was just looking for a reason


so the interrupts were already in place? thats a positive, although it confuses me. was it not already running in wince?

i was thinking the other day, probaly going around in circles, but it made me wonder on something you said.

Originally Posted by [ACL

]Once haret loads, wince is no longer in-charge of the device. We must enable and disable everything.. kernel starts loading and it loads the appropriate drivers.

so what happens on other devices, where we had to make a phone call and then boot haret. was it much easier to initiate phone audio with it already "running" or what?

also, can you do me a favor whenever you get the chance? can you send me some logs in wince when you are doing several procedures? initiate a game that uses hw3d, a game that doesnt activate 3d, and when playing back a video recorded by the phone through windows media player.

just looking at a few things, but really anyone can do this. what would really help is to get the boot logs from several native android devices, and maybe some logs using hw3d. it really doesnt matter which device, as essentially initiating the drivers and calling them should correlate.

[[ACL]]

Originally Posted by newkidd

ill pull them both apart and see if there are any major differences worth finding. ive been needing to boot back to windows and reformat a hard drive to use on my Wii, i was just looking for a reason


so the interrupts were already in place? thats a positive, although it confuses me. was it not already running in wince?

i was thinking the other day, probably going around in circles, but it made me wonder on something you said.



so what happens on other devices, where we had to make a phone call and then boot haret. was it much easier to initiate phone audio with it already "running" or what?

also, can you do me a favor whenever you get the chance? can you send me some logs in wince when you are doing several procedures? initiate a game that uses hw3d, a game that doesnt activate 3d, and when playing back a video recorded by the phone through windows media player.

just looking at a few things, but really anyone can do this. what would really help is to get the boot logs from several native android devices, and maybe some logs using hw3d. it really doesnt matter which device, as essentially initiating the drivers and calling them should correlate.

Well, phone call stuff works since its all done by A9. we really dont need ot do anything. Its handled internally. Things like 3d, need calls to be made to enable and disable it.

Android devices are completely different. For example all their clocks are also handled internally not like wince that has to set its own stuff. So once haret boots, no one is there to handle it any-more. I'm interested to see what would happen with a Rhod that has no 3d. We have everything in theory ready to turn on 3d, maybe the fact that its enabled messes it up. Dont know at this stage

Wince logs are useless. But here is a full boot log to show you what happens as soon as the device turns on, to when it begins activating 3d for manila.

http://pastebin.com/M1Ad4YMv

Also i put my own debug lines on the kernel to get more logging. So logs from android devices wont help since they dont tell the whole story.