yashsingh1/xdaforums huggingface dataset:
[Nexus One Android Development] Geniusdog254:
So basically, if we get these new Qualcomm drivers fully functional, we should get ~20fps (giving a 25% boost over the ~16 the E gets, because it is clocked 25% slower). I know that increase is optimistic, since the GPU clock will also have a lot more of an effect, but boosting the CPU clock will give an increase.

Anyway. We could use the binary part of the driver, it's just getting ahold of the damn thing :p
[Nexus One Android Development] :
Doubt it i get 16.3fps at 1075ghz or 768mhz...the clock speed doesn't affect my benchmark results, but i could be wrong.
[Nexus One Android Development] Geniusdog254:
Hmm thats strange. I've noticed an improvement in my scores between 998mhz & 1.267ghz on my Evo. It's a boost from an average of 24.1 in Neocore to a 27.6.

In NenaMark I get a jump from 11.3 to 13.9.
[Nexus One Android Development] irus:
Sorry if im double posting but does this not look promising??

http://www.androidcentral.com/qualcomm-releases-open-source-3d-snapdragon-driver
[Nexus One Android Development] babijoee:
yes it has been posted. Please try doing a search or looking through a thread next time.
[Nexus One Android Development] babijoee:
How about scores on your n1?

As i just ran necore and got a score of 28.6 w/ sound off running cyanogen 6 alpha 1 no OC

Now 28.9 :p
[Nexus One Android Development] Dany0:
whaat!? I get max 10.8(EDIT: Got 11,5) on nenamark with desire on froyo at 1,1Ghz!!

!!VERY USEFUL INFROMATION!!

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒

P.S.: To the acer liqiud, IMHO the adreno in our snapdragon devices is heavily underclocked. I've seen a demo of adreno(the same in snapdragon) running an arcade game for Xbox 360, I mean come on it's just a rip-off of the ATI Evergreen GPU Core. It is probably clocked @ 500Mhz naturally, so we can go up to 6XXMhz. The question is power consumption of course. But this is already about 180mil. poly/s ^^ we can run debian and wolfenstein enemy territorry on it :)

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒

▒^^^^^^^^^^^^^^^^^^^▒

▒!!VERY USEFUL INFROMATION!!▒

▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒▒
[Nexus One Android Development] fstluxe:
You must use set CPU on the performance.. with 1.27 ghz I get all the time 14.8 FPS and setcpu on ondermand I get 11 fps
[Nexus One Android Development] Dany0:
thanks

EDIT:

So did you guys progress with the project?
[Nexus One Android Development] fstluxe:
anny news ?
[Nexus One Android Development] jlevy73:
The problem with Neocore is that it is a benchmark for Open GL 1.1. The N1 is running 2.0 so how accurate Neocore really is, is a bit debatable. That being said I get 28.6 FPS
[Nexus One Android Development] mtw4991:
FYI, CM6-A1 and using Wildmonks 0705_925_BFS kernel oc'd to 1113 min/max on performance, I got 30.6 Neocore and 1808 Quadrant with 43-44 Linpack. Very fast kernel.
[Nexus One Android Development] Dany0:
Has anyone compiled successfully OC'd drivers? Did you try the 500Mhz I suggested!?
[Nexus One Android Development] Geniusdog254:
The problem is that we can't. We haven't gotten to the point yet that we can arbitrarily change the clock and have it stick. I'm looking at it now.

Sorry for the lack of progress on this. I've been busy with family and friends since last weekend. I can devote time to this today and tomorrow but then Friday I'll be busy and then I should be back at it on the weekend if things go according to plan.

EDIT: By the way, I do all my graphics benchmarking in NenaMark and Neocore. Neocore gives good OpenGL1.1 benchmarks and Nenamark is a great OpenGL2.0 benchmark. If the score is 20+, it's Neocore, if it's <20 then it's Nenamark (unless I get an epic overclock going ;))
[Nexus One Android Development] storm99999:
The only problem with 500Mhz is that when that happened, I'm sure that the graphics chip was actively cooled. The chip in our N1s isn't even passively cooled. The chip is just bare. I can see up to a 50% overclock in the best of circumstances, but any past that and it'll be extraordinarily dangerous to the life of the chip.

Anyways, I got meself up a build environment finally. I'll first monitor all calls to clk_set_max_rate() to find out what the GPU clock's max is and first do an underclock then an overclock, if it works. I for one won't be pushing my chip too hard, I rather enjoy my phone, but I'll at least try.
[Nexus One Android Development] Geniusdog254:
Thats actually what I'm working on right now, it won't be too difficult I don't think.

I also tried directly calling msm_proc_comm and it just causes the kernel to freeze when it loads up.

msm_proc_comm(PCOM_CLKCTL_RPC_SET_RATE, GRP_CLK, 256000000);

The first arguement is what you want it to do, the second is the ID of the clock, in this case I used the grp_clk as defined in clock.h, and the 3rd is the value you want the clock at (the 3rd arg is dependent on the first one, in this case it's the rate).

Anyway either setting it to 384mhz (the next step up from 256 on the acpu table, figured it was logical here too) or the stock 256mhz causes the kernel to freeze. Go figure. Why it freezes is beyond me.
[Nexus One Android Development] storm99999:
That's the thing, I do not think there is a "stock clock". The Adreno under and overclocks within a bound in response to load kernel interrupts. In addition, there's a bunch of layers of spinlock mutexes between kernel and hardware access. I'll start modifying code once I verify successful kernel building in a few minutes here.
[Nexus One Android Development] Geniusdog254:
Nah there is a stock clock. That I'm sure of. I have actually never seen the grp or imem clocks set at anything other than 256000000hz or 256mhz. My debug code I put up in the first post runs everytime kgsl is called and prints the clock to the kernel log and EVERY time it prints the ebi1 clock is 128mhz & the grp & imem are at 256mhz.
[Nexus One Android Development] Geniusdog254:
@storm99999 Can you get with me on Google Wave or GTalk? That'll be an easy way to do real time collaboration, geniusdog254@gmail.com
[Nexus One Android Development] storm99999:
I fired off an email.

So far, I've added code successfully, I also successfully got EXPORT_SYMBOL to work, and it's compiled. Underclocking has no response. Trying overclocking now.

EDIT:

Overclocking is not successful yet. There's two more tests I have to go through.

Edit2:

Overclocking test two failed. Last reasonable test is very complicated.
[Nexus One Android Development] Geniusdog254:
Invited you to chat. Check your GMail.

How exactly are you trying to overclock, are you using clk_set_rate or msm_proc_comm, or something else?
[Nexus One Android Development] Dany0:
Do not worry about the temp. The gpu chip is integrated within the snapdragon, which can stand some extreme conditions for so long it is needed.

BTW can you show some benchmarks of underclock? thanks in advance.
[Nexus One Android Development] Geniusdog254:
Its not that simple man...

Like I said earlier, we have no apparent way to arbitralily change the clock. It either crashes if we change it in a way that I'm pretty sure actually changes it or it has no effect if we just call clk_set_rate.
[Nexus One Android Development] dogiedogie:
Here's a really crazy idea, do you think if someone called qualcomm and got through to someone with enough technical knowledge, theyd point you in the right direction?
[Nexus One Android Development] Geniusdog254:
Wishful thinking I'm pretty sure.

I'm all for trying it, but I really doubt they'll give us anything. I mean the docs are NDA'd for a reason. They would have no reason at all to give us the docs.

I was actually just telling storm how we needed an inside man at Qualcomm/HTC lol.

If anyone who works at either company is reading this, feel free to email me any docs at geniusdog254@gmail.com ;)
[Nexus One Android Development] Geniusdog254:
Updated the first post with some more info. Check it.
[Nexus One Android Development] storm99999:
Alrighty, now that I have a build environment, I've done some tests with GeniusDog254, and here's my conclusions:

I forcibly changed all second level clock setters to only set the gpu clock at 384Mhz, to no avail. The only way to change it without going this route was using msm_proc_comm, which was analyzed next. I forced it to change any GPU clock to 384Mhz, which caused a system lockup. I then set it to what I knew it was supposed to be, and it locked up.

This made me think there was something secretive going on here. If it crashed even when set right on the first run, maybe it's not sending what I think it's sending. My thought was it could be something like a password to unlock the clock for our use.

I tried to log the value, but this is one of the most time sensitive bits of code. If I added a variable definition, it was fine, if I compared one value to another, it was fine, but if I compared two, tried to write to logs, or whatever, the system would crash. Now, I don't think the crash happened during this process, but a bit later when something went wrong with the GPU due to a delayed clock setting.

What we need to do is to either find a way to log this on a separate thread, write to unused memory to be collected later, without transferring a pointer in or out, or write to a log that does not get destroyed immediately before the radio crashes. These three ways are the only way to properly analyze what happens when the clock is first set, and only then can we hope to overclock, and I have no idea how to do any of them.

In the newer driver, it appears that the clock is set much later in the process, which means we may have easier access. However, I doubt we'll be able to use that driver until the Liquid E gets rooted and we can harvest the binary driver. Now, if the driver is in the radio, we're screwed. Can anyone chime in on where the binary driver is (exactly) on the N1?

The last thing worth doing is to modify the constructor for msm_proc_comm (my idea was to add ,int bees) at the end) so that we can now find out whenever it is called, analyze those individually, and hunt down the first clock set of the GPU. I suspect it's not in the kernel though. This will have to wait until I get some sleep.

For those who have no idea what I'm saying, it's not working yet and it's a long road until it does.
[Nexus One Android Development] dogiedogie:
So you'll have this ported to Froyo soon then? ;)
[Nexus One Android Development] Geniusdog254:
Lol as stressful as this day has been, that actually made me laugh. Thanks!
[Nexus One Android Development] dogiedogie:
My android knowledge extends to toggling my wifis on and off, so any contribution I can make in development is unlikely to be coding xD
[Nexus One Android Development] coolbho3000:
Git commits have emails attached to them. I advise you to check out Code Aurora and take a look at the Qualcomm commits, especially those related to the GPU, there are quite a few emails of Qualcomm engineers. Don't do a mass email bomb, though, that's really annoying, email one or two individually.

I emailed an HTC guy once and he responded! You would be surprised.

The code aurora tree also has a lot of stuff concerning the GPUs for other Scorpion-based SoCs, including ones that are clocked at 192000000 rather than 128000000 (though their axi clocks are at this value too too).

I think the imem clock (internal graphics memory clock) is also connected with the grp clk, if you guys haven't figured that out yet. edit: yeah, it looks like you guys got that too.
[Nexus One Android Development] Geniusdog254:
Thanks for the heads up on that. I'm to the point now I tend to just ignore those comment headers with all the license & email info lol. I'll try and find one and shoot one of them an email. Maybe swetland, I know he did a lot of work on these devices.

-----------------------------------------------------------------------------------------------------------

Also, I looked at these new drivers. I'm pretty sure what is stopping us from using them is that we aren't using a .32 kernel. Has anyone tried building them into a .32 kernel? My work is being done mostly on my Evo now, and it is a .29 kernel, and my Nexus kernel is a clone of IntersectRaven's .34 kernel with some of my changes, so that could be why I couldn't make it work.

Who's gunna build a .32 kernel with these drivers? (or at least try :p)
[Nexus One Android Development] Geniusdog254:
Well I found two guys who seem to do a lot of GPU work at codeaurora and have shot them both and email, and in the process I found this commit.

God I wish it were that easy for us lol. Damned old MSM boards let the clocks be set so easily :(

EDIT: There's also this commit, which is interesting to me. It says that on QSD8650A chips (CDMA version of the 8250A Snapdragon in the Nexus, this one is in the Evo) and some MSM7X30 chips (I think they're also just the CDMA version of another chip) the 3D clock MUST be turned on before it gets power, so this could be our timing issue (storm, you know what I mean). Even though it is only required to be in that order for the CDMA chips, they've also moved to having the GSM ones do the same thing, since it has no adverse effect.
[Nexus One Android Development] Jack_R1:
You should probably know that the docs are watermarked, so I don't suppose anyone would risk that much, yes? ;) but I can try and give you some insight. I believe that the 3D core is initialized in radio image, which means that there is no way to control its clocks, moreover - not all of the memory/register regions are accessible from apps CPU, only those with permission granted by radio. But before I say that something is impossible, let me check it. Might take some time, I'm not a SW guy, and Graphics are not my area, so I'm not sure I can contribute anything besides doubt...
[Nexus One Android Development] storm99999:
That would make sense, but the issue is that for one, the clocks are "controllable" (insofar that we can write to shared memory with the commands) from the kernel and that if we set the clock to a specific number on boot it will crash the radio.

There are a few explanations for this that include having no access from the kernel, but I won't rule it out until we can analyze what the kernel does to the GPU in the first few seconds of booting.

On the note of permission, there is a kernel cmd flag that says something akin to "transfer control of clocks". I wonder what it actually does.
[Nexus One Android Development] Geniusdog254:
I didn't actually expect any docs to be sent lol it was just a joke, but if you do have some info, please share! Don't do anything that'll hurt your career or anything though! It aint worth that lol. Can you share which company you work for? HTC or Qualcomm?

And storm, I agree completely. It may be impossible for us, but I'm not going to give up until im 100% sure that there is no way to do it.

The CodeAurora folks haven't emailed me back yet, but it's only been a few hours, so I haven't given up hope there. I think I may email Swetland at Google, he is active on here and he has a lot of insight into these devices too.
[Nexus One Android Development] storm99999:
I wouldn't worry too much about it, I'd give it a week before you know for sure if your email's been ignored.

Any ideas on where we go from here? I could investigate kernel thread spawning and writing to the crash dumps, but documentation is sparser than EXPORT_SYMBOL's.
[Nexus One Android Development] Jack_R1:
I don't make it a big secret that I work for Q (otherwise I wouldn't be participating in this thread ;)). But I'm in HW, so my insight in this stuff is coming from another angle (and I'm not in graphics-related team). You're using procedures and macros, I'm looking for clock control registers..

Speaking of which, I'm looking at the damn table right now, and can't make much use of it, having no clock network reference.

In the meantime, if you want to make sure you have the access rights, test reading physical 0xA8600084 and see, what you get.
[Nexus One Android Development] Geniusdog254:
Sounds good. I don't have my Ubuntu box on atm but I'll try that later.
[Nexus One Android Development] Jack_R1:
Oh well.. Luck isn't on our side. I'm missing exactly the settings that are needed, that's why I couldn't figure out what I saw. They aren't there. It means one of 2 things - either the frequency is not controllable, or we'll have to "reverse engineer" HW from SW, if it's possible, because what I have is incomplete.

Could you please show me the source of clk_get_rate function? And if it references some other function, just dive as deep as needed to get to the register reading macro?

The values for grp_clk and imem make me suspicious.

And I can suggest leaving the EBI1 alone ;)
[Nexus One Android Development] Geniusdog254:
Haha thanks for the tip, will do.

And all of the clk_* functions are defined in arch/arm/mach-msm/clock.c if I remember right. It mostly just calls spin lock & unlocks and passes some flags straight to the hardware.

Like I said I'm away from my kernel dev box right now but I'll check it some more later.
[Nexus One Android Development] Jack_R1:
Yes, it's exactly the "flags to the HW" that I'm interested in. If you tell me what register(s) this function reads and how it decodes what it reads, I might be able to tell how to check/change the clock divider rate, if such exists. I can figure it out from the code, but since I'm not SW, I don't have the code readily available in front of me. Plus, it takes me more time to navigate in the code. So I'll wait for you. We're not bound by deadlines, we have time :D
[Nexus One Android Development] storm99999:
Alright, basically, clk_set_rate calls after layers and layers of safety msm_comm_proc(), which is the below code:

int msm_proc_comm(unsigned cmd, unsigned *data1, unsigned *data2)
{
void __iomem *base = MSM_SHARED_RAM_BASE;
unsigned long flags;
int ret;

spin_lock_irqsave(&proc_comm_lock, flags);

for (;;) {
if (proc_comm_wait_for(base + MDM_STATUS, PCOM_READY))
continue;

writel(cmd, base + APP_COMMAND);
writel(data1 ? *data1 : 0, base + APP_DATA1);
writel(data2 ? *data2 : 0, base + APP_DATA2);

notify_other_proc_comm();

if (proc_comm_wait_for(base + APP_COMMAND, PCOM_CMD_DONE))
continue;

if (readl(base + APP_STATUS) != PCOM_CMD_FAIL) {
if (data1)
*data1 = readl(base + APP_DATA1);
if (data2)
*data2 = readl(base + APP_DATA2);
ret = 0;
} else {
ret = -EIO;
}
break;
}

writel(PCOM_CMD_IDLE, base + APP_COMMAND);

spin_unlock_irqrestore(&proc_comm_lock, flags);

return ret;
}

Then there's a definition table:

#define APP_COMMAND 0x00
#define APP_STATUS 0x04
#define APP_DATA1 0x08
#define APP_DATA2 0x0C

The shared memory:

#define MSM_SHARED_RAM_BASE IOMEM(0xF8100000)

Then the CMD tables of use:

PCOM_CLKCTL_RPC_SET_RATE = 0x18
PCOM_CLKCTL_RPC_MIN_RATE = 0x19
PCOM_CLKCTL_RPC_MAX_RATE = 0x1A
PCOM_CLKCTL_RPC_RATE = 0x1B

The clocks:

GRP_CLK = 0x09
IMEM_CLK = 0x0C

Let me know if you need any more info.
[Nexus One Android Development] Jack_R1:
Damn, I should have guessed by the name from the start...

msm_proc_comm = msm processor communicate. Rings a bell? ;)

It's not really an interface to the HW, it's an interface to the point where you can't see anything any more...

Ok, I'll try to trace it beyond that point and get back to you, if it actually can be used for something.

Thanks for making it easier for me.

It'll most probably take me a couple of days, though.
[Nexus One Android Development] storm99999:
Also, I tried using readl on that memory address, it just crashed my phone. I probably coded it wrong, but if that's an expected result, there you go.
[Nexus One Android Development] Jack_R1:
Yes, that would go hand in hand with the usage of msm_proc_comm for it. It means that the apps processor is not allowed to directly access that region (if you did it right - converting physical to virtual and just doing a memory read instruction). I'm not sure about crashing, though - I'll try to check that too, I think that it shouldn't have crashed.

But having communication interface might allow to command the frequency change, if it's possible and not prohibited by the radio.
[Nexus One Android Development] storm99999:
I did no conversion that I know of, but I'll be honest, I am not too familiar with the low level stuff, this being my first work with it.

void __iomem *address = IOMEM(0xA8600084);
int test = readl(address);
pr_info("memory access: %d", test);

IOMEM just converts a number into a pointer.

Edit: And yes, it is isolated to this code. If I comment it out, it works just fine.
[Nexus One Android Development] Jack_R1:
Running under OSes, you run in virtual memory and all the addresses you use are virtual. There is a way (AFAIK, in Linux it's an easy one), to get a virtual address for a corresponding physical one. What you did is writing to virtual 0xa8600084, which can point anywhere, depending on virtual-to-physical translation table in the CPU. So the reason for the crash can be anything.

I don't remember the best way to do it, but I'll give you something in the meantime that might work. See if phys_to_virt() is implemented:

http://ww2.cs.fsu.edu/~rosentha/linux/2.6.26.5/docs/DocBook/deviceiobook/re02.html

And use it on the address to get the virtual address that you can use in IOMEM.
[HD2 General] jjrpm:
Is there any app that will allow you to take a shortcut and put it in a folder?

Like put Ramcleaner into tools folder or bing into Internet folder?

Thank you
[HD2 General] watcher64:
there are several, and the one on your phone is called file explorer ..

/windows/start menu/programs

move them around how ever you want, via cut and paste ...

Or

connect to your PC via active sync goto the root of your phone then

/windows/start menu/programs , move things around create folders what ever you want ...

(sometimes the windows folder can take a while to load)

Remember any quicklinks may have to be updated if you move the shortcut ...
[HD2 General] jjrpm:
Thank you it was that easy!
[EVO 4G Q&A, Help & Troubleshooting] booyakasha:
I keep getting digest errors when I flash certain roms

The error i just got was:

Verifying update package...
E: Wrong digest:
system/app/VoiceSearch.apk
E: Verification failed

Installation aborted

I've heard this can be caused by the Recovery. Right now I'm using RA-evo-v1.7.0.1
[EVO 4G Q&A, Help & Troubleshooting] booyakasha:
bump

Some ROMs flash fine and I havent had an issue in a while, but trying to flash baked snack v9 results in:

E:Wrong Digest:
system/app/Browser.apk
E:Verification failed

EDIT: Saw someones post that said they fixed it switching to Clockwork recovery. Going to try that.
[Hero, G2 Touch Q&A, Help & Troubleshooting] LooieENG:
At the moment I have RA-Hero 1.6.2, and the rooted stock 1.5 HTC ROM (2.73.405.66) on a GSM Hero

I'm just wondering what the radio actually is, and whether I need to update it? From what I can gather, it's the actual phone part of the phone? At the moment I have 63.18.55.06EU_6.35.06.18 do I need to upgrade to 63.18.55.06JU_6.35.09.26

Also, do I just flash this like a normal ROM in .zip format?

I found the links here: http://xdaforums.com/showthread.php?t=559622

Thanks :)
[Hero, G2 Touch Q&A, Help & Troubleshooting] twiztedvvv:
Yes aradio is the 'phone' part of the phone.

The is no actual need to update a radio but sometimes it can give a better service (better internet connection for example, or maybe better signal)

yes radios are flashed the same way as a rom, jus flash the .zip over the rom, DO NOT WIPE like you do with a rom.

And always do a nandroid backup before flashing.

Also be sure the radio is compatible with your phone. (check is GSM not CDMA)
[Hero, G2 Touch Q&A, Help & Troubleshooting] LooieENG:
Yeah I took a chance and just flashed it (did a Nandroid back up first of course :P)

I was worried as hell at first, because that weird logo came on like the phone coming out of the box, and then it was rebooting for ages

Haven't really noticed any signal increases, but I guess it can't do any worse can it!
[EVO 4G General] roxz:
sorry if this has been asked before, im sure it has but i didnt fint anything under uk but is it true the phone really isnt coming to the UK, i really dont wanna have to buy a ****ty iphone.....

http://mobilenews.omio.com/mobile-p...4g-android-phone-supersonic-not-coming-to-uk/