HPH overclocked kernels by Burs

[sawbones999]

Damn, I just remembered you were asking about GPU not RAM. Lol. Sorry, I'm really tired. Been a long day.

[sawbones999]

Defconf on that kernel is definitely chromium. Other Rockchip defconf's appear to be for platform other than RK3288. One has Mali t6xx defined, other maybe for rk3066?

Kernel does have kvm/ARM as a target platform but not as a host. Weird.

Also, last commit for Mali chromium drivers 8 months ago. Lame. Don't see any VPU code at all.
Cheers,
-SB

[Guest]

I've spent hours looking into Firefly's source, and couldn't find anything related to gpu lock. There are bits and pieces here and there hinting it could be it, but in the end it either gets confusing and complicated, or have to do with something else. It's not 625mhz is not enough, it's me who can't look at wasted potential

[sawbones999]

Possibly something in the binary only blob which forces that as the max? Have you tried decompiling it? I've done stuff like that before with ida pro and hex-rays but I'm not so good at reading assembly. Even the pseudo-code comes out pretty cryptic. Dunno if there are any ARM assembly to C converters around(much easier to find the other way around).

I've tried to do that with MIPS code before. I learned a fair amount about the hardware but didn't end up learning much about the firmware I was trying to decompile.

Maybe if you can find the code for the pll which controls the clock speed, and study how that pll works, it could be possible to force a higher speed through direct manipulation of the pll instead of through the clock source settings?

Sounds likes lot of work for something that might not be so necessary

Now I feel like I need to take a look at it myself, lol. Thanks a lot Burs!
Cheers,
-SB

[Guest]

Sounds likes lot of work for something that might not be so necessary

Yes, indeed it does seem to be much of work.
And it would be a complete waste of time finding the lock on the HW level in the end

[sawbones999]

Here is the clock config source https://bitbucket.org/T-Firefly/fire...hip/?at=master

I did find the CPU "define safety clock speed" here in an include file.

There are also a few references to GPU in one or two of these files. I don't really feel like chasing down the variables and doing the necessary math involved right now.

Maybe you can make some sense of it. I will applaud you if you do!

Also, it appears that I was wrong in other threads when I posted that kvm/ARM host was not supported in this kernel(firefly source, I have no idea about the chromium source). I found some files indicating that it is supported. I just wish that I knew how to build it properly with Android support.

I really hate that the manufacturers won't even cough up a freaking defconf for their systems. I want to compile a kernel which will work on my box and it's so tedious trying to make sure that everything is enabled that I need(like A/V port) and things I don't are disabled(like firefly VGA).

It's enough to get my spirits down and feel like indefinitely postponing these type of endeavors. These Rockchip sources are a whole lot more cryptic than the Qualcomm krait sources I've been working with. And ZTE is nice enough to release their source with defconfs included for their platforms, even well documented in comments (even if their sources are pretty outdated by the time they get around to making them public). There is a whole lot of this Rockchip code which isn't documented in comments much at all.

Cheers,
-SB

[Guest]

Here is the clock config source https://bitbucket.org/T-Firefly/fire...hip/?at=master

I did find the CPU "define safety clock speed" here in an include file.

There are also a few references to GPU in one or two of these files. I don't really feel like chasing down the variables and doing the necessary math involved right now.

Maybe you can make some sense of it. I will applaud you if you do!

I did search these clock config files before, but couldn't find anything useful. GPU frequencies are indeed mentioned, but I don't see a "safety lock" or something similar anywhere. If I lock GPU@700Mhz in device tree blob file, dmseg still says GPU is set to 625Mhz. So there must be some part of (kernel?) code which is evaluting the frequency I've set and deciding to fall back to default 625Mhz if it's set to anything higher than that. Even if I find "if-condition" in the code, I would still have to pinpoint its offset in compiled kernel, because I want everything to be "clean" - just like patching the CPU safety frequency, so all kernel features and tweaks stay intact. But again, the work involved could really be an overkill, just as you said before. Who knows what outcome could we get out of it? 5% performance? 15%? Or a fried GPU Maybe it's set to 625Mhz for a very good reason...

[sawbones999]

I was just thinking that it's possible that one of the clk divide if's could possibly block the maximum speed on the GPU pretty quietly without making it obvious that it was doing so.

Who knows. If you can find a way to patch a compiled kernel that'd be better.

I feel like we're getting sloppy seconds with the firefly source. And then on top of it freaking ARM Mali and RK VPU blobs are not available for current mainline kernels which have RK3288 integrated.

Have you looked at the Mali open source drivers to check for clock code?
Cheers,
-SB

[sawbones999]

If there was, it may be possible to compile and search for similarities to the blob we have, and in that way try and find a binary patch.

It's another long shot, lol

[Guest]

I thought about that too. The same way I found the cpu safety frequency. I'm not so good with linux and compiling kernels, but if someone could compile a version with 625 and 700Mhz, I'm pretty sure I could find a byte pattern and offset for the GPU lock frequency in our HPH kernels. Another long shot, but I'm running out of ideas.

[sawbones999]

It would have to be compiled for an Android environment, and should be compiled against the same kernel sources. I guess the firefly sources will work, but I think the driver is still a crippled version.

It might turn out a WHOLE lot different than the current blob.

I'll try to take a look at the sources and see what sort of clock settings it contains, if any. Haven't looked so I don't really know what to expect.

Cheers again,
-SB

[sawbones999]

Oh yeah, it looks like the firefly sources are setup to compile with Linaro? Is that right? Anyone correct me on that if I'm wrong please.

Cheers,
-SB

[Gormar]

There is definetly possibility to limit GPU OC in mali drivers. Strangely in FireFly kernel source this limit is set to 500MHz.
Look there and search for "KBASE_VE_GPU_FREQ_KHZ_MAX" which is later incorporated into "KBASE_CONFIG_ATTR_GPU_FREQ_KHZ_MAX" device config attribute.

[Guest]

It would have to be compiled for an Android environment, and should be compiled against the same kernel sources. I guess the firefly sources will work, but I think the driver is still a crippled version. It might turn out a WHOLE lot different than the current blob.

Yes, you're completely right. Even when Sam from Ugoos was helping me find the cpu safety frequency, he only changed the frequency between two builds, and I found dozens of differences even though only that integer value was different. Compiling against different sources is completely out of the question. I personaly use firefly sources only as a reference to know what I'm looking for.

There is definetly possibility to limit GPU OC in mali drivers. Strangely in FireFly kernel source this limit is set to 500MHz. Look there and search for "KBASE_VE_GPU_FREQ_KHZ_MAX" which is later incorporated into "KBASE_CONFIG_ATTR_GPU_FREQ_KHZ_MAX" device config attribute.

That one is a very useful information. Thank you. If HPH did minimal changes to that part of the kernel, at least we know it's stored somewhere as a KHz value, and it's not in Hz like the cpu safety frequency. I was also searching for 625000 in firefly sources, assuming it has the same safety frequency, but obviously I was wrong. I should search thru both binary and source code once again. Maybe I could find some similarities this time...

[sawbones999]

I downloaded the latest open source mali driver, and I have figured out where the gpu_max and gpu_min are at there. It's in TX041-SW-99002-r5p1-00rel0/driver/product/kernel/drivers/gpu/arm/midgard/platform/{INSERT YOUR PLATFORM NAME HERE}/mali_kbase_config_platform.h

The value of each is definitely in kilohertz. An example of the file would be this:

/**
* Maximum frequency GPU will be clocked at. Given in kHz.
* This must be specified as there is no default value.
*
* Attached value: number in kHz
* Default value: NA
*/
#define GPU_FREQ_KHZ_MAX 600000
/**
* Minimum frequency GPU will be clocked at. Given in kHz.
* This must be specified as there is no default value.
*
* Attached value: number in kHz
* Default value: NA
*/
#define GPU_FREQ_KHZ_MIN 600000

Unfortunately there are no rk3288 platform setups included in the driver. Only Juno_soc and several vexpress setups, one of which clocks the GPU at max and min 5Mhz! lol Bet that's a speed demon.

Anyway, I'm down to try and compile this thing if you think it will help. Only problem is I will either have to create the necessary files for 'platform' or more likely I'd try to find one that already exists because it's pretty specific for a given set of hardware. The frequency scaling and voltages are defined here and are very much dependent on how those things are addressed for a given board (ie:what buses are available, or what structures are used for those things on that specific board).

Does this exist within the firefly source anywhere? Perhaps it's in one of the chromium kernels, but this is the android kernel driver so I'm not really sure how different the platform definitions would be.

Some food for thought, anyway.
Cheers!
-SB