Wframe-larger-than error!

It’s been a while since I’ve seen this happen, and although I’ve mentioned it before, it just goes to show that it is an ongoing issue. Let’s take a look at the output of the compiler:

[CODE]
/home/alaskalinuxuser/compile/build_cm14/kernel/samsung/tblte/drivers/input/touchscreen/wacom/wacom_i2c_flash.c: In function ‘wacom_i2c_flash’:
/home/alaskalinuxuser/compile/build_cm14/kernel/samsung/tblte/drivers/input/touchscreen/wacom/wacom_i2c_flash.c:622:1: warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
error, forbidden warning: wacom_i2c_flash.c:622
make[5]: *** [drivers/input/touchscreen/wacom/wacom_i2c_flash.o] Error 1
make[4]: *** [drivers/input/touchscreen/wacom] Error 2
make[3]: *** [drivers/input/touchscreen] Error 2
make[2]: *** [drivers/input] Error 2
make[1]: *** [drivers] Error 2
make[1]: *** Waiting for unfinished jobs….
[/CODE]

The key part being here:

warning: the frame size of 1152 bytes is larger than 1024 bytes [-Wframe-larger-than=]
error, forbidden warning: wacom_i2c_flash.c:622

Typically, a warning is not going to stop your build process, but in some cases, the warning is so severe that it is flagged by predetermined settings that this type of warning would be an error. Errors, of course, stop the build.

In the case of frames being too large, I have usually found that (if it built sucessfully for someone else) the toolchain you are using is not sufficient for the task. So I headed over to UBERTC to download a newer toolchain.

https://bitbucket.org/UBERTC/

And, after downloading it, extracting it, and placing it in the build_cm14/prebuilts/gcc/linux-x86/arm folder, I then edited my device/samsung/tblte-common/BoardConfigCommon.mk file, like so:

[CODE]
KERNEL_TOOLCHAIN := /home/alaskalinuxuser/compile/build_cm14/prebuilts/gcc/linux-x86/arm/UBERTC-5.3/bin
KERNEL_TOOLCHAIN_PREFIX := arm-eabi-
[/CODE]

And away we go, there turned out to be some other errors as well, but this did solve the “too large” problem, as the new toolset built it in a way that was within tolerance.

Linux – keep it simple.

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.

 

Adding a kernel governor can be a Nightmare!

Okay, so a little play on words, especially since I am adding the Nightmare governor to the tblte (Samsung Galaxy Note Edge) kernel, but it did turn out to be a bit of a problem child, fortunately, it was quickly corrected. As you can see, I did the standard additions, as well as adding the cpufreq_nightmare.c file:

Added to Makefile:

[CODE]
………….EDITED FOR SPACE…………………..
obj-$(CONFIG_CPU_FREQ_GOV_NIGHTMARE) += cpufreq_nightmare.o
………….EDITED FOR SPACE…………………..
[/CODE]

Added to Kconfig:

[CODE]
………….EDITED FOR SPACE…………………..
config CPU_FREQ_DEFAULT_GOV_NIGHTMARE
bool “nightmare”
select CPU_FREQ_GOV_NIGHTMARE
help
Use the CPUFreq governor ‘nightmare’ as default. -WJH
………….EDITED FOR SPACE…………………..
config CPU_FREQ_GOV_NIGHTMARE
tristate “‘nightmare’ cpufreq policy governor”
help
‘nightmare’ – This driver is a modified PegasusQ.

To compile this driver as a module, choose M here: the
module will be called cpufreq_nightmare.

For details, take a look at linux/Documentation/cpu-freq.

If in doubt, say N. -WJH
………….EDITED FOR SPACE…………………..
[/CODE]

Added to cpufreq.h:

[CODE]
………….EDITED FOR SPACE…………………..
#elif defined(CONFIG_CPU_FREQ_DEFAULT_GOV_NIGHTMARE)
extern struct cpufreq_governor cpufreq_gov_nightmare;
#define CPUFREQ_DEFAULT_GOVERNOR (&cpufreq_gov_nightmare)
………….EDITED FOR SPACE…………………..
[/CODE]

Added to config:

[CODE]
………….EDITED FOR SPACE…………………..
CONFIG_CPU_FREQ_GOV_NIGHTMARE=y
………….EDITED FOR SPACE…………………..
[/CODE]

But, when I ran the compiler, I got this output:

[CODE]
/home/alaskalinuxuser/Documents/projects/phones/compile/build_slim6/kernel/samsung/tblte/drivers/cpufreq/cpufreq_nightmare.c: In function ‘nightmare_check_cpu’:
/home/alaskalinuxuser/Documents/projects/phones/compile/build_slim6/kernel/samsung/tblte/drivers/cpufreq/cpufreq_nightmare.c:540:2: error: implicit declaration of function ‘cpufreq_notify_utilization’ [-Werror=implicit-function-declaration]
cpufreq_notify_utilization(policy, max_load);
[/CODE]

So I edited that line out in build_slim6/kernel/samsung/tblte/drivers/cpufreq/cpufreq_nightmare.c:

[CODE]
// WJH cpufreq_notify_utilization(policy, max_load);
[/CODE]

And viola! By God’s grace it even worked! That usually doesn’t get fixed so easily, so I guess that wasn’t so bad.

Linux – keep it simple.