BLOX2: Overclocking the GPU on a 64 bit kernel!

gpuoc

Another update to the BLOX2 (BLU Life One X2) kernel, I just overclocked the GPU from 450 MHz to 500 MHz! You can check out the commit on my GitLab. It’s all part of my video series for modifying 64 bit kernels, which you can check out on my YouTube channel: https://www.youtube.com/channel/UCnGqG_jyyXmTzdamBpKfeHA

Linux – keep it simple.

Overclocked the Verizon Galaxy S5

Actually, I’m not the first one to do this. It’s been done dozens of times before, and quite frankly, to higher levels. So, why do I make my own kernel overclocked? Well, I do think there is one difference in my kernel overclocking than the others. I don’t increase the voltage while adding faster processing power.

Typically, in my kernels I try to focus on battery over performance. However, I like getting the most bang for the buck, too. So, in my kernel, I increased the frequency by 3%, but did not increase the voltage any. This allows the maximum benefit for the same amount of voltage, which equals an increase in performance, without an extra drain on the battery.

Okay, at least not a noticeable drain on the battery. Ohms law is still true, so the Resistance will drop slightly as the frequency went up, because of slightly higher heat, microscopically decreasing the resistance and changing the formula. However, when you increase the voltage, the Power formula changes dramatically.

For example, some fictitious numbers for conceptualization:

Power = Current x Voltage Let’s say, (P) 12 = (I) 2 x (E) 6.

If we increase the Voltage, the change is drastic: (P) 14 = (I) 2 x (E) 7.

If we don’t increase the voltage, the change is microscopic, only because the change in frequency will ultimately increase the heat (very slightly). In ohm’s law, that is I=E/R, so our formula looks like this: Power = Voltage/Resistance x Voltage, or (P) 12 = ([E] 6 / [R] 3) x (E) 6. So if the heat rises microscopically, then the semiconductor resistance lowers microscopically*, then the power will only change microscopically. So, our new fictitious formula looks like this: (P) 12.04 = ([E] 6 / [R] 2.99) x (E) 6.

Either way, you can check out the commit here:

https://github.com/alaskalinuxuser/android_kernel_samsung_klte/commit/dd3e95708f0f4166486fc4341691826ea303d993

Linux – keep it simple.

*Normally, in wire, heat increases cause the resistance to increase. However:

“In a semi-conductor, there is an energy gap between the (filled) valence and the (empty) conduction band. At zero temperature, no charges are in the conduction band and the resistance should be infinite as the system behaves basically like an insulator. If you turn on the temperature, some electrons will start to occupy the conduction band and thus contribute to conduction, lowering the [resistance].”  https://physics.stackexchange.com/users/661/lagerbaer

 

Overclock an apq8084 Samsung Galaxy Note Edge!

In my continuing quest to make a better kernel for the Samsung Galaxy Note Edge (TBLTE, N915T), I decided to tackle overclocking the kernel. There are already some overclocked kernels out there, but I decided to do something slightly different with mine. The distinguishing feature of my overclocked kernel is that it doesn’t use any more power than it did before, and to God be the glory, it worked!

I also feel that when you overclock a chip, you are increasing the rate of failure, and the induced heat load. So I like to keep my overclocking light, less than 10% of the overall capacity that the chip was designed for. It is my hope that this will reduce wear and tear on the device while still providing superior performance.

Editing the tables for this chip was a lot simpler than for other chips I have worked on.

It all took place within the kernel/samsung/tblte/arch/arm/boot/dts/qcom/apq8084.dtsi file. Here is how it used to look:

[CODE]
………….EDITED FOR SPACE…………….
/* 2.7GHz RC1 */
qcom,speed2-pvs0-bin-v1 =
< 0 0 0 >,
< 300000000 810000 76 >,
< 345600000 820000 88 >,
………….EDITED FOR SPACE…………….
< 2496000000 1120000 813 >,
< 2572800000 1135000 849 >,
< 2649600000 1150000 886 >;
[/CODE]

And here was my change:

[CODE]
………….EDITED FOR SPACE…………….
/* 2.7GHz RC1 */
qcom,speed2-pvs0-bin-v1 =
< 0 0 0 >,
< 300000000 810000 76 >,
< 345600000 820000 88 >,
………….EDITED FOR SPACE…………….
< 2496000000 1120000 813 >,
< 2572800000 1135000 849 >,
< 2688000000 1150000 886 >;
[/CODE]

That’s right, I only made a 39MHz change. I feel this was appropriate to keep the device cool and continue to use the same voltages. So it is essentially a 39MHz boost with no noticable consequences. Of course, I had to do the above to each speed and pvs table in that file.

Then, I needed to edit this portion:

[CODE]
………….EDITED FOR SPACE…………….
qcom,msm-cpufreq@0 {
reg = <0 4>;
compatible = “qcom,msm-cpufreq”;
qcom,cpu-mem-ports = <1 512>;

qcom,cpufreq-table =
< 300000 300000 1144 800 >,
< 422400 422400 2288 800 >,
………….EDITED FOR SPACE…………….
< 2572800 1728000 16250 10101 >,
< 2649600 1728000 16250 10101 >;
………….EDITED FOR SPACE…………….
[/CODE]

To this:

[CODE]
………….EDITED FOR SPACE…………….
qcom,msm-cpufreq@0 {
reg = <0 4>;
compatible = “qcom,msm-cpufreq”;
qcom,cpu-mem-ports = <1 512>;

qcom,cpufreq-table =
< 300000 300000 1144 800 >,
< 422400 422400 2288 800 >,
………….EDITED FOR SPACE…………….
< 2572800 1728000 16250 10101 >,
< 2688000 1728000 16250 10101 >;
………….EDITED FOR SPACE…………….
[/CODE]

It actually was the only time I have overclocked a kernel on the second try. Don’t think too highly of me, though, I spent hours reviewing kernel edits for overclocking by various other kernel developers on GitHub. If you are looking to do the same, you should spend some time looking at working code for others, and then make your own tables.

If you were to compare my tables with everyone elses, you would see that I have done it differently than my contemporaries, even though we reached similar, or in some cases, identical results. I like to keep the code clean, short, and sweet. Often when overclocking, most kernel developers will add more lines to the tables. I have found that while that may be the best to maximize use, my method is much simpler and easy to implement, as well as follow, and that is what Linux should be all about, keeping it simple.

Linux – keep it simple.

 

Overclocking the GPU on a Samsung Galaxy S4

We talked about overclocking the CPU of the S4 (SGH-M919) before, but today I wanted to point out some great work by Faux123 that showed me exactly what to do to overclock the Graphics Processor Unit (GPU) of my S4. Faux123’s work was far more impressive then my own, with if/then statements and options to compile with and without it. However, for a simpleton like myself, I just put it straight in, without all the options. I put it in without options because I want it to be in there! Here is a link to Faux123’s commit:

https://github.com/f1vefour/mako/commit/ce53045d110088dca52bcad6ffa6f94bd06f0a70

I am including it here so that you can review it and see a true master at work, as well as to give credit where it is due. Below is my adaptation of that work.

Faux123 started by making some edits and changes to the kconfig file. This allowed the option of compiling a kernel with, or without the GPU overclocking. However, as I stated earlier, I want to compile it with the GPU overclocked every time, so I didn’t add that in. Because of this, I didn’t need all of the if/then statements that were seen in the rest of the work. Also, Faux123 was working with a board-mako, but I am working with an S4, so I used differnt files. Here is what I did change, though:

kernel_samsung_jf/arch/arm/mach-msm/board-8064-gpu.c

[CODE]
static struct msm_bus_vectors grp3d_max_vectors[] = {
{
.src = MSM_BUS_MASTER_GRAPHICS_3D,
.dst = MSM_BUS_SLAVE_EBI_CH0,
.ab = 0,
.ib = KGSL_CONVERT_TO_MBPS(5920),
},
{
.src = MSM_BUS_MASTER_GRAPHICS_3D_PORT1,
.dst = MSM_BUS_SLAVE_EBI_CH0,
.ab = 0,
.ib = KGSL_CONVERT_TO_MBPS(5920),
},
};
…………EDITED FOR SPACE………….
static struct kgsl_device_platform_data kgsl_3d0_pdata = {
.pwrlevel = {
{
.gpu_freq = 487500000,
.bus_freq = 4,
.io_fraction = 0,
},
{
.gpu_freq = 320000000,
.bus_freq = 3,
.io_fraction = 33,
},
[/CODE]

That line:

[CODE].ib = KGSL_CONVERT_TO_MBPS(5920),[/CODE]

used to say a lower number:

[CODE].ib = KGSL_CONVERT_TO_MBPS(4264),[/CODE]

, and the

[CODE].gpu_freq = 487500000,[/CODE]

used to say

[CODE].gpu_freq = 450000000,[/CODE]

.

Then I simply added a line to kernel_samsung_jf/arch/arm/mach-msm/clock-8960.c:

[CODE]
/*Shared by 8064, 8930, and 8960ab*/
static struct clk_freq_tbl clk_tbl_gfx3d[] = {
F_GFX3D( 0, gnd, 0, 0),
F_GFX3D( 1800000, pxo, 1, 15),
F_GFX3D( 27000000, pxo, 0, 0),
F_GFX3D( 48000000, pll8, 1, 8),
F_GFX3D( 54857000, pll8, 1, 7),
F_GFX3D( 64000000, pll8, 1, 6),
F_GFX3D( 76800000, pll8, 1, 5),
F_GFX3D( 96000000, pll8, 1, 4),
F_GFX3D(128000000, pll8, 1, 3),
F_GFX3D(145455000, pll2, 2, 11),
F_GFX3D(160000000, pll2, 1, 5),
F_GFX3D(177778000, pll2, 2, 9),
F_GFX3D(192000000, pll8, 1, 2),
F_GFX3D(200000000, pll2, 1, 4),
F_GFX3D(228571000, pll2, 2, 7),
F_GFX3D(266667000, pll2, 1, 3),
F_GFX3D(320000000, pll2, 2, 5),
F_GFX3D(400000000, pll2, 1, 2),
F_GFX3D(450000000, pll15, 1, 2),
F_GFX3D(487500000, pll15, 1, 2),
F_END
};
[/CODE]

This line added the 487MHz frequency as an option in the GPU table. Then I changed the old “high” from 450000000 to 487500000, like so:

[CODE]
static unsigned long fmax_gfx3d_8064[VDD_DIG_NUM] = {
[VDD_DIG_LOW] = 128000000,
[VDD_DIG_NOMINAL] = 325000000,
[VDD_DIG_HIGH] = 487500000
};
[/CODE]

That was all there was to it! Faux123 has several more additions/subtractions, but I didn’t need to specify different tables and such, because I just edited the original table, rather than make new tables specific for overclocking the GPU. Praise God! After compiling, it worked!

Linux – keep it simple.

Overclocking the CPU on a Samsung Galaxy S4

I have been trying to follow every guide out there to overclock my Samsung Galaxy S4 (SGH-M919), and until now I have had absolutely no luck! It wasn’t until I saw some work on a kernel by Faux123 that I realized the difference in kernel setups. Once I tried it, by God’s grace, it worked! Granted, I couldn’t straight up implement Faux123’s work, because that was for a slightly different kernel and setup, but the overall ideas and information helped tremendously! Knowing that I had so much trouble makes me want to share it here, so others can use this information.

The reason I was having so much trouble, is the guides I was reviewing had a different structure for thier chips controls that that of the S4. Overall it works the same, but the syntax and setup were different, causing me to create never ending bootloop kernels that couldn’t do anything, let alone be faster versions of thier predecessor!

Ultimately, overclocking your cpu, for the S4 at least, comes down to these 2 files:

kernel_samsung_jf/arch/arm/mach-msm/acpuclock-8064.c
kernel_samsung_jf/arch/arm/mach-msm/cpufreq.c

Granted, I am still new at this, and there are probably better and fine tune ways to do this, but here is how I did it. In the acpuclock-8064.c file, there were many tables of cpu frequencies for different levels and conditions. Here is the pre-overclocked version:

[CODE]
static struct acpu_level tbl_PVS6_2000MHz[] __initdata = {
{ 1, { 384000, PLL_8, 0, 0x00 }, L2(0), 875000 },
{ 1, { 486000, HFPLL, 2, 0x24 }, L2(5), 875000 },
{ 1, { 594000, HFPLL, 1, 0x16 }, L2(5), 875000 },
{ 1, { 702000, HFPLL, 1, 0x1A }, L2(5), 875000 },
{ 1, { 810000, HFPLL, 1, 0x1E }, L2(5), 887500 },
{ 1, { 918000, HFPLL, 1, 0x22 }, L2(5), 900000 },
{ 1, { 1026000, HFPLL, 1, 0x26 }, L2(5), 925000 },
{ 1, { 1134000, HFPLL, 1, 0x2A }, L2(14), 937500 },
{ 1, { 1242000, HFPLL, 1, 0x2E }, L2(14), 950000 },
{ 1, { 1350000, HFPLL, 1, 0x32 }, L2(14), 962500 },
{ 1, { 1458000, HFPLL, 1, 0x36 }, L2(14), 975000 },
{ 1, { 1566000, HFPLL, 1, 0x3A }, L2(14), 1000000 },
{ 1, { 1674000, HFPLL, 1, 0x3E }, L2(14), 1025000 },
{ 1, { 1782000, HFPLL, 1, 0x42 }, L2(14), 1062500 },
{ 1, { 1890000, HFPLL, 1, 0x46 }, L2(14), 1100000 },
[/CODE]

The second column lists the frequency that is available, and the last column tells the cpu how much voltage to use to make it work. Here is where I did some basic math. I wanted to overclock the last variable to be more than 1890000, but how much was too much, and what numbers were appropriate? Faux123’s work didn’t tell me that, but looking over the work that Faux123 did showed me where to make the edits. Essentially, I decided that these must be based on some sort of mathmatical principle. Turns out that I must be right.

1890000-1789000=108000
1789000-1674000=108000
1674000-1566000=108000
etc….

So, I concluded that the frequency changes *should* be made in 108MHz jumps. So, by extrapolation:

1890000+108000=1998000

This then, gave me the new target frequency of 1998000!

Then there was a question of voltage. Maximum and minimum voltage is set at the beginning of the file, like so:

[CODE]
[CPU0] = {
.hfpll_phys_base = 0x00903200,
.aux_clk_sel_phys = 0x02088014,
.aux_clk_sel = 3,
.sec_clk_sel = 2,
.l2cpmr_iaddr = 0x4501,
.vreg[VREG_CORE] = { “krait0”, 1300000 },
.vreg[VREG_MEM] = { “krait0_mem”, 1150000 },
.vreg[VREG_DIG] = { “krait0_dig”, 1150000 },
.vreg[VREG_HFPLL_A] = { “krait0_hfpll”, 1800000 },
},
[/CODE]

I am not going to lie to you and tell you that I understand what all of that means, but what I can tell you is that VREG_CORE seems to be the maximum voltage you can apply to that core. In the case of my overclocking expirement, I twiddled with several variations, but eventually decided to leave the max where it was.

Back to our example, I decided to go with this:

[CODE]
static struct acpu_level tbl_PVS6_2000MHz[] __initdata = {
{ 1, { 384000, PLL_8, 0, 0x00 }, L2(0), 875000 },
{ 1, { 486000, HFPLL, 2, 0x24 }, L2(5), 875000 },
{ 1, { 594000, HFPLL, 1, 0x16 }, L2(5), 875000 },
{ 1, { 702000, HFPLL, 1, 0x1A }, L2(5), 875000 },
{ 1, { 810000, HFPLL, 1, 0x1E }, L2(5), 887500 },
{ 1, { 918000, HFPLL, 1, 0x22 }, L2(5), 900000 },
{ 1, { 1026000, HFPLL, 1, 0x26 }, L2(5), 925000 },
{ 1, { 1134000, HFPLL, 1, 0x2A }, L2(14), 937500 },
{ 1, { 1242000, HFPLL, 1, 0x2E }, L2(14), 950000 },
{ 1, { 1350000, HFPLL, 1, 0x32 }, L2(14), 962500 },
{ 1, { 1458000, HFPLL, 1, 0x36 }, L2(14), 975000 },
{ 1, { 1566000, HFPLL, 1, 0x3A }, L2(14), 1000000 },
{ 1, { 1674000, HFPLL, 1, 0x3E }, L2(14), 1025000 },
{ 1, { 1782000, HFPLL, 1, 0x42 }, L2(14), 1062500 },
{ 1, { 1998000, HFPLL, 1, 0x46 }, L2(14), 1100000 },
{ 0, { 0 } }
[/CODE]

Notice that I didn’t increase the voltage at all. Actually, after several tests, I found that I could do more with less! In this case (probably not every case), I could increase the frequency, and esentially undervolt it to use the same voltage to do more work. Before finding this, however, I had worked out a voltage system:

1100000-1062500=37500
1062500-1025000=37500
1025000-1000000=25000
1000000-975000=25000
975000-962500=12500
etc….

It would appear that the voltages increment upwards as the frequency increases. Using this theory and table, I presumed that the next voltage would be +50000. It seems to go 2 steps at the same increase, and then incrementally increase by 12500. So, either the next step was a continuation of +37500, or an additional +37500+12500, which would be +50000. If I was increasing the voltage, these would be some safe steps, provided that the accumulative answer did not progress above my max limit of 1300000, defined earlier. If it does need to exceed that, then I need to also increase max voltages. In either event, I must be wrong about something, or this is a great undervoltage example, because without increasing the voltage, the kernel did overclock by 108MHz.

Now there is another step to do. We still have to edit the cpufreq.c file. Fortunately, Faux123’s work pointed me right to this, and it was a simple change. All one has to do, is write in the new upper_limit_freq, which is the new maximum frequency:

[CODE]
static unsigned int upper_limit_freq = 1566000;
#else
static unsigned int upper_limit_freq = 1998000;
#endif
[/CODE]

Pretty slick, huh! I am really glad people like Faux123 and Github exist, so people who need help (like me) can review their code and find where one has to make changes to do things like overclocking. All I did after editing these two files was compile the new kernel. Granted, I did play around a bit with some other voltages/frequencies, but this was realitively simple and worked great compared to the other failed attempts to follow the overclocking guides on the web!

Linux – keep it simple.