Change your TWRP theme!

Until recently, I was completely oblivious to the fact that you can change the way TWRP looks. Actually, to be quite honest, I thought that it looked great the way it was. However, it was pointed out to me that you can now download new themes and even make your own! I haven’t made any themes myself, but for now, I thought I would share how you can change your theme by downloading new ones.

It may seem daunting, but truth be told, it was actually really simple. Once TWRP is installed, all you have to do is download one that is appropriate for your device. Since I am on TWRP 3+, I downloaded mine from a user named fichl on XDA, you can find it here: http://forum.xda-developers.com/android/themes/theme-twrp-3-0-0-0-dark-stock-colors-t3310235

Be sure to slap his thanks button!

In particular, I downloaded the fichls_twrp3_theme_pack_portrait_v2_marshmallow_flashable.zip

After rebooting my phone into recovery mode, I simply pressed install, navigated to the directory with the zip file, and chose to install it. After installing it, you either need to reboot into recovery, or press:

home -> advanced -> reload theme.

Now I can change the theme by going to: home -> advanced -> change theme!

That was the coolest TWRP modification I have ever done, with instant gratification for minimal effort! So, I thought I’d share. Enjoy!

Linux – keep it simple.

 

Insert an explicit cast to silence issue…

In the continuing saga of compiling AOSP 7 for the Samsung Galaxy S4, T-Mobile variant (SGH-M919, JFLTETMO) I ran into an interesting problem. While this used to be a non-issue for building Marshmallow and earlier, libcopybit seems to now have a problem in Nougat. Let’s take a look:

[CODE]
hardware/qcom/display/msm8960/libcopybit/copybit_c2d.cpp:1390:40: note: insert an explicit cast to silence this issue
struct copybit_rect_t dr = { 0, 0, dst->w, dst->h };
^~~~~~
static_cast<int>( )
hardware/qcom/display/msm8960/libcopybit/copybit_c2d.cpp:1390:48: error: non-constant-expression cannot be narrowed from type ‘uint32_t’ (aka ‘unsigned int’) to ‘int’ in initializer list [-Wc++11-narrowing]
struct copybit_rect_t dr = { 0, 0, dst->w, dst->h };
^~~~~~
hardware/qcom/display/msm8960/libcopybit/copybit_c2d.cpp:1390:48: note: insert an explicit cast to silence this issue
struct copybit_rect_t dr = { 0, 0, dst->w, dst->h };
^~~~~~
static_cast<int>( )
hardware/qcom/display/msm8960/libcopybit/copybit_c2d.cpp:1391:40: error: non-constant-expression cannot be narrowed from type ‘uint32_t’ (aka ‘unsigned int’) to ‘int’ in initializer list [-Wc++11-narrowing]
struct copybit_rect_t sr = { 0, 0, src->w, src->h };
^~~~~~
hardware/qcom/display/msm8960/libcopybit/copybit_c2d.cpp:1391:40: note: insert an explicit cast to silence this issue
struct copybit_rect_t sr = { 0, 0, src->w, src->h };
^~~~~~
static_cast<int>( )
hardware/qcom/display/msm8960/libcopybit/copybit_c2d.cpp:1391:48: error: non-constant-expression cannot be narrowed from type ‘uint32_t’ (aka ‘unsigned int’) to ‘int’ in initializer list [-Wc++11-narrowing]
struct copybit_rect_t sr = { 0, 0, src->w, src->h };
^~~~~~
hardware/qcom/display/msm8960/libcopybit/copybit_c2d.cpp:1391:48: note: insert an explicit cast to silence this issue
struct copybit_rect_t sr = { 0, 0, src->w, src->h };
^~~~~~
static_cast<int>( )
4 errors generated.
ninja: build stopped: subcommand failed.
make: *** [ninja_wrapper] Error 1
[/CODE]

So, I changed hardware/qcom/display/msm8960/libcopybit/copybit_c2d.cpp from this:

[CODE]
struct copybit_rect_t dr = { 0, 0, dst->w, dst->h };
struct copybit_rect_t sr = { 0, 0, src->w, src->h };
[/CODE]

To this:

[CODE]
struct copybit_rect_t dr = { 0, 0, (int)dst->w, (int)dst->h };
struct copybit_rect_t sr = { 0, 0, (int)src->w, (int)src->h };
[/CODE]

And it compiled sucessfully. Unfortunately, I don’t know how well that fixed the problem (or, if at all), since the AOSP 7 will currently not boot on my S4. But I’ll keep at it!

Linux – keep it simple.

Compiling: Problems with Jack

Sometimes, Jack just doesn’t want to play. Here is the error I got while trying to compile AOSP 7.0 for the Samsung SGH-M919, T-Mobile S4:

[CODE]
[ 1% 73/5641] Ensure Jack server is installed and started
Jack server already installed in “/home/alaskalinuxuser/.jack-server”
Launching Jack server java -XX:MaxJavaStackTraceDepth=-1 -Djava.io.tmpdir=/tmp -Dfile.encoding=UTF-8 -XX:+TieredCompilation -cp /home/alaskalinuxuser/.jack-server/launcher.jar com.android.jack.launcher.ServerLauncher
[ 1% 74/5641] Building with Jack: out…k_intermediates/with-local/classes.dex
FAILED: /bin/bash out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/with-local/classes.dex.rsp
Communication error with Jack server (52). Try ‘jack-diagnose’
ninja: build stopped: subcommand failed.
make: *** [ninja_wrapper] Error 1
[/CODE]

And here is how I solved it:

[CODE]
$ export JACK_SERVER_VM_ARGUMENTS=”-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4g”
$ ./prebuilts/sdk/tools/jack-admin kill-server
$ ./prebuilts/sdk/tools/jack-admin start-server
[/CODE]

Essentially, Jack has an issue with regards to memory. What I have done here is give it more heap size to buffer the work that it is doing. I’ve done this by passing an argument to Jack through an environment variable. This variable will go away as soon as I close the terminal I am working in. I then stop and restart the Jack server.

This trick also works well if Jack tells you that you don’t have enough memory to compile something. You may get an error like this:

[CODE]
FAILED: ….
Try increasing heap size with ‘-Xmx<size>’
[/CODE]

You can set the heap size to anything you want, but 4 GB worked pretty well for me.

Linux – keep it simple.

Device configurations are no longer allowed to change the global flags… error bailing…

Sometimes Android does stuff that is probably a good idea, but is really annoying to the compiler. By compiler, I mean guys or gals like you and I who really want to compile AOSP 7.0, but can’t because all of our old device trees have cflags set. Without warning, AOSP institues the ninja build system, and then declares all cflags to be illegal. Bummer.

Bummer that is, unless we disable the bailout.

Open up ./build/core/config.mk, and scroll down to line 630, where you should see the below.

[CODE]
# ###############################################################
# Set up final options.
# ###############################################################

ifneq ($(COMMON_GLOBAL_CFLAGS)$(COMMON_GLOBAL_CPPFLAGS),)
$(warning COMMON_GLOBAL_C(PP)FLAGS changed)
$(info *** Device configurations are no longer allowed to change the global flags.)
$(info *** COMMON_GLOBAL_CFLAGS: $(COMMON_GLOBAL_CFLAGS))
$(info *** COMMON_GLOBAL_CPPFLAGS: $(COMMON_GLOBAL_CPPFLAGS))
$(error bailing…)
endif
[/CODE]

Which I changed to this:

[CODE]
# ###############################################################
# Set up final options.
# ###############################################################
#I disagree with your cflags policy. So there. (Go ahead and tell AOSP how you really feel.)
#ifneq ($(COMMON_GLOBAL_CFLAGS)$(COMMON_GLOBAL_CPPFLAGS),)
#$(warning COMMON_GLOBAL_C(PP)FLAGS changed)
#$(info *** Device configurations are no longer allowed to change the global flags.)
#$(info *** COMMON_GLOBAL_CFLAGS: $(COMMON_GLOBAL_CFLAGS))
#$(info *** COMMON_GLOBAL_CPPFLAGS: $(COMMON_GLOBAL_CPPFLAGS))
#$(error bailing…)
#endif
[/CODE]

Problem solved. you may now use your good ol’ cflags. Carry on.

Linux – keep it simple.

How to put TWRP and Custom Roms on the Samsung Galaxy S4

I have been getting quite a few requests on XDA from members who need to know how to put TWRP and custom roms on their Samsung Galaxy S4. So, I thought I would post it here as well. Keep in mind, this does not work for Verizon, Sprint, or AT&T models, but will work for the International and T-Mobile models, as well as the Canadian models.

You can download any of the custom roms from my site at the title bar links.

If you use Windows instructions

[CODE]
If your phone is a JFLTEXX (i9505)
Go to: https://dl.twrp.me/jfltexx/
and download 3.0.2-0 tar

If your phone is a JFLTETMO (M919)
Go to: https://dl.twrp.me/jfltetmo/
and download 3.0.2-0 tar

If your phone is a JFLTEAIO (i337z)
Go to: https://dl.twrp.me/jflteatt/
and download 3.0.2-0 tar

Then, download this:
http://www.mediafire.com/download/7us5q44aab1xl9d/Odin304.zip

-Unzip Odin.
-Turn on your phone (normal turn on) boot up into the stock system.
-plug in your phone, let Windows find the drivers.
-Once Windows found your drivers, unplug the phone, turn your phone off.
-open Odin.exe
-Click on PDA, and choose the TWRP file you downloaded.
-With your phone unplugged and off, Now press and hold the DOWN volume button and the power button.
-When the phone vibrates, you can release the power button, but keep holding the down button.
-You will see a warning screen. Release the down button, and press the volume up button to enter “download” mode.
-Plug your phone into the computer.
-Press start/ok button on Odin.

You should see a blue bar on your phone screen that fills up from left to right. Odin should say “pass” or “success”. Your phone should automatically reboot itself. If this did not happen, seek help. Seriously. 😀

-Plug your phone into the computer again, and copy the Gapps and Rom from post #1 to your external sdcard of your phone.
-Now, turn off the phone again.
-Hold the UP volume button, and the power button.
-When the phone vibrates, you can release the power button, but keep holding the UP volume button.
-You will enter TWRP. Now you can release the UP volume button.
-You should now MAKE A BACKUP TO YOUR EXTERNAL SDCARD. -With this, you can always go back!
-After making a backup, you should wipe your phone. Select wipe, slide the slider to wipe your phone. This will not wipe your external sdcard.
-Install Rom.
-Wipe Cache and Davlik.
-Install Gapps. – Optional
-Reboot to system and enjoy!
[/CODE]

If you use Linux instructions

[CODE]
If your phone is a JFLTEXX (i9505)
Go to: https://dl.twrp.me/jfltexx/
and download 3.0.2-0 tar

If your phone is a JFLTETMO (M919)
Go to: https://dl.twrp.me/jfltetmo/
and download 3.0.2-0 tar

If your phone is a JFLTEAIO (i337z)
Go to: https://dl.twrp.me/jflteatt/
and download 3.0.2-0 tar

Then,
$ sudo apt-get heimdall heimdall-frontend -y

$ sudo heimdall-frontend

-This will open up heimdall.
-Click on the tab called Utilities
-With your phone unplugged and off, press and hold the DOWN volume button and the power button.
-When the phone vibrates, you can release the power button, but keep holding the down button.
-You will see a warning screen. Release the down button, and press the volume up button to enter “download” mode.
-Plug your phone into the computer.
-Under Detect Device, click “detect” – the Output box will say something like, detected.
-Under Download PIT -> destination file -> click save as.
-Choose a name for your pit, like jfltexx.pit
-Click Download.
-Exit heimdall-frontend and power off your phone by holding the power button.
-Open heimdall again with the command: $ sudo heimdall-frontend
-Click the tab called “Flash”
-Under “pit” click browse.
-Choose the pit file you downloaded.
-Under partitions(files), click “add”
-Under Partition Details, click partition name, and click recovery.
-Under File (recovery.img), click browse.
-Choose the 3.0.2-0 img you downloaded.
-Click on the “Utilities” tab.
-With your phone unplugged and off, Now press and hold the DOWN volume button and the power button.
-When the phone vibrates, you can release the power button, but keep holding the down button.
-You will see a warning screen. Release the down button, and press the volume up button to enter “download” mode.
-Plug your phone into the computer.
-Under Detect Device, click “detect” – the Output box will say something like, detected.
-Click on the Flash tab.
-Under Session, click “start”

You should see a blue bar on your phone screen that fills up from left to right. Heimdall should say “pass” or “success”. Your phone should automatically reboot itself. If this did not happen, seek help. Seriously. 😀

-Plug your phone into the computer again, and copy the Gapps and Rom from post #1 to your external sdcard of your phone.
-Now, turn off the phone again.
-Hold the UP volume button, and the power button.
-When the phone vibrates, you can release the power button, but keep holding the UP volume button.
-You will enter TWRP. Now you can release the UP volume button.
-You should now MAKE A BACKUP TO YOUR EXTERNAL SDCARD. -With this, you can always go back!
-After making a backup, you should wipe your phone. Select wipe, slide the slider to wipe your phone. This will not wipe your external sdcard.
-Install Rom.
-Wipe Cache and Davlik.
-Install Gapps. – Optional
-Reboot to system and enjoy!
[/CODE]

I hope that clears things up a bit. Leave a comment if you have any trouble following this process, I would be glad to help out.

Linux – keep it simple.

 

How to manually update your custom rom source code with security updates

For those of you who compile your own custom roms directly using AOSP source, the latest security updates are always added in as soon as they occure. For those of us using custom roms, such as SlimRoms, AOKP, PAC roms, and others, this is not always the case.

Because the custom rom community downloads AOSP source, and then manipulates it to their needs/tastes, they cannot always directly integrate AOSP security updates. Some of these updates may not apply. Others, if unedited, may cause some features not to function.

For this reason, custom roms can sometimes fall behind, because one of the developers on that team needs to manually apply a lot of the fixes. This can be quite tedious. For instance, the libvpx security issue found in March of 2016 changed over 800 files. For the most part, the custom rom teams do a great job updating the security patches for the current version of their rom. The question is, what do you do to update the security patches of older versions of the roms?

This is actually a problem that I ran into with my build of SlimLP for the SGH-M919, T-Mobile Galaxy S4. I am mainting a current build of SlimLP for that phone, because the Marshmallow builds have some Bluetooth issues on these phones. Thus, users who still want to use Lollipop roms still need up to date security. But how do I fix this problem? The SlimRom’s team has moved on to work on Slim6, and there is almost no activity on SlimLP. Well, by God’s grace, I figured it out, and I thought I would share that here with you, in case you face a similar problem.

First, you could apply these same methods to all levels of security, however, since there are so many security updates, I have decided to only manually update my SlimLP source code with Critical security updates. Yes, that does mean that I am skipping the High, Moderate, and Low security threats. As I mentioned before, some of the updates are over 800 files, and that would be a new full time job for me, which I don’t have time for. So, hopefully, these Critical updates will strike the balance between keeping my rom users safe, and allowing me to still have time for important things like family, work, and sleeping!

The first thing I noticed as I started building SlimLP in May was that the security updates had stopped in February. After syncing in August, I found that the security updates had still not changed. You can verify in your source (if it is Lollipop or later) by looking at /build/core/version_defaults.mk, where you should see this line:

[CODE]
ifeq “” “$(PLATFORM_SECURITY_PATCH)”
# Used to indicate the security patch that has been applied to the device.
# Can be an arbitrary string, but must be a single word.
#
# If there is no $PLATFORM_SECURITY_PATCH set, keep it empty.
PLATFORM_SECURITY_PATCH := 2016-02-01
endif
[/CODE]

Obviously, if it is now August, then the security patches are 6 months out of date. That is pretty old, and there were a lot of big security threats found since then, some of which are specific to Qualcomm phones. This prompted me to start the process of updating my source by hand.

Granted, you could also join the team of your favorite rom and help others by updating thier security patches too, but as I pointed out, I am only updating the Critical security updates, not all of them, so it would not meet all of the official requirements to push my source upstream. If that is something you are interested in doing, that is great!

The next thing I did was look at the current security updates by going here:
https://source.android.com/security/bulletin/index.html

I decided to work on one month at a time, and compile inbetween to make sure that each update did not break anything that is in my SlimLP rom. So, I clicked on March, 2016. There were 19 CVE’s, or Common Vulnerability and Exposures ID’s for that month, 7 of which were marked Critical. Those are the ones I decided to work on.

There are many different ways to go about this, but here is what worked best for me. I copied the CVE number, in this case, CVE-2016-0818, and punched it into Google. Google brought up several options, but I found a good one to click on is the NVD detail, which is teh National Vulnerability Database. In this case, it took me here:
https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-0818

The website has a poor color scheme, but is very informative. It tells you what type of threat this is, how it can be used, and other great information. There is also a section called “References to Advisories, Solutions, and Tools”, below which I found several hyperlinks, including this one, which contains the fixes:
https://android.googlesource.com/platform/external/conscrypt/+/4c9f9c2201116acf790fca25af43995d29980ee0

This Google Git page shows us where the file is located, and how many, and exactly which file(s) have been changed. For this particular CVE, it is a really small change of just one file:

src/platform/java/org/conscrypt/TrustedCertificateIndex.java [diff]

By clicking on the word [diff], you are brought to the next page, that shows you exactly which lines of code need to change, like so:

[CODE]
@@ -68,6 +68,15 @@
if (anchors == null) {
anchors = new ArrayList<TrustAnchor>(1);
subjectToTrustAnchors.put(subject, anchors);
+ } else {
+ // Avoid indexing the same certificate multiple times
+ if (cert != null) {
+ for (TrustAnchor entry : anchors) {
+ if (cert.equals(entry.getTrustedCert())) {
+ return;
+ }
+ }
+ }
}
anchors.add(anchor);
}
[/CODE]

If you have never read these before, the + signs tell you to add these lines. Any – signs tell you to delete those lines. At the top, the @@ -68,6 +68,15 @@ is used to tell you which line numbers to look for, such as the case here, of line 68. Pretty straightforward. So, in this case, I found that file, and made these changes of adding these new lines. Note, in some of the files I changed, the line numbers were not correct for where to find this portion of code. The easy thing to do is copy a snipit of the code and do a search in the file, corrolating that with the surounding code and approximate line numbers for guidance. This is especially true if that file has been hacked to add some function or feature to your rom.

The next step is to go back to where we started. If you recall, we looked in /build/core/version_defaults.mk, where we saw this line:

[CODE]
PLATFORM_SECURITY_PATCH := 2016-02-01
[/CODE]

Now we can update it if we desire. Granted, if you are not doing all of the updates, you may not wish to change this, as you do not want to intentionally mislead anyone. In my case, I did update it, but was very sure to write in my rom’s long description that the security updates are only the Critical updates that I applied by hand, as of 2016-02-01. How you handle this is up to you.

Obviously, the last step is to go ahead and compile your new code, and see if it still works right! Hopefully, you now have a more secure rom for your phones.

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.

Adding pre-built apps to your build

One of the big things that always comes up is that of adding pre-built apps to your build. Make is so dynamic that you could add these in just about anywhere, provided that you properly add them to your configuration files. For myself, I used to add them into the vendor directory, but this became tedious when I would switch to build something else with the same repository, or when I would update or change to other repositories but wanted the same pre-built apps.

I recently realized that there was an easy way around this, and I wanted to share that with others. Most of you probably already know how to do this, but perhaps someone can benifit from this. Besides, if I ever forget, I can just look here for a reference!

I like to add the Kernel Adiutor app to my JFLTETMO (Samsung Galaxy S4, T-Mobile variant) builds. Like I mentioned above, I used to put it in the vendor directory. What I realized though, is that I can simply add it to my jfltetmo repository under the devices. For my device, I have a jfltetmo repository, which essentially sets a few flags and passes the buck to the jf-common repository for building. So, I actually added the app to my jf-common repository. Now, when I sync, it updates my jf-common directory, and keeps my prebuilt app!

Here is what I did.

Added some folders:

In my jf-common repository (dev/samsung/jf-common) I added a directory called “prebuilt”. In keeping with Android’s common structures, I then created these two folders: “common” and in that folder, one called “app”.
When you are done making directories, it should have a path like this:

[CODE]
jf-common/prebuilt/common/app
[/CODE]

Now, in the “app” folder, I placed my prebuilt app, the Kernel Adiutor app, which I named “ka.apk”. I then made an Android.mk file in the “prebuilt” folder that looks like this:

[CODE]
# Copyright (C) 2012 The Android Open Source Project
#
# Licensed under the Apache License, Version 2.0 (the “License”);
# you may not use this file except in compliance with the License.
# You may obtain a copy of the License at
#
# http://www.apache.org/licenses/LICENSE-2.0
#
# Unless required by applicable law or agreed to in writing, software
# distributed under the License is distributed on an “AS IS” BASIS,
# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
# See the License for the specific language governing permissions and
# limitations under the License.

LOCAL_PATH := $(call my-dir)

#
# Prebuilt APKs
#

include $(CLEAR_VARS)
LOCAL_MODULE := ka
LOCAL_MODULE_OWNER := aokp
LOCAL_SRC_FILES := common/app/$(LOCAL_MODULE).apk
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_SUFFIX := .apk
LOCAL_MODULE_CLASS := APPS
LOCAL_CERTIFICATE := PRESIGNED
include $(BUILD_PREBUILT)
[/CODE]

You can add as many prebuilt apps as you want this way, just make the above block for each app. Then you simply add them to your jf-common.mk file in the jf-common directory. You can substitute your device name here, it should work the same. Notice that the lines which have more than one app have the “\” denoting that there are more files to add. Pretty simple, right?

[CODE]
# WJH adding kernel adiutor apk
PRODUCT_PACKAGES += \
ka \
camera.msm8960
[/CODE]

Linux – keep it simple.

 

Using a fallback branch to overcome poor choice of repository branch names

I know that we have looked at fallback branches before, but this really is worth looking at again. Last time, we saw an instance where there was not a branch available that was new enough for what we were trying to build. E.g., building a Lollipop version of Android, with only KitKat trees available. This time, however, we have a case of “mistaken” identity. Check it out:

[CODE]
Calculated revision: lp5.1-layers
Default revision: android-5.1.1_r24
Default revision android-5.1.1_r24 not found in android_device_samsung_jfltetmo. Bailing.
Branches found:
lollipop
Use the ROOMSERVICE_BRANCHES environment variable to specify a list of fallback branches.
build/core/product_config.mk:234: *** Can not locate config makefile for product “liquid_jfltetmo”. Stop.

** Don’t have a product spec for: ‘liquid_jfltetmo’
** Do you have the right repo manifest?
[/CODE]

Here we are trying to build a Lollipop version of Android, and it is looking for a branch called lp5.1-layers, but will use the default of android-5.1.1_r24 if it is available. It couldn’t find it, however, because in the source I am refering too, the branch is called lollipop instead. Now, you and I know that Lollipop and 5.1.1 are the same thing, but the compiler and repo tools do not. So, here’s how we fix it, by using a fallback branch option, except instead of “falling back” to an old revision, we are “falling back” to the current revision under a different name:

[CODE]
alaskalinuxuser@AlaskaLinuxUser-HP-Compaq-6715b:~/Documents/projects/phones/compile/Liquid5$ export ROOMSERVICE_BRANCHES=lollipop
alaskalinuxuser@AlaskaLinuxUser-HP-Compaq-6715b:~/Documents/projects/phones/compile/Liquid5$ brunch jfltetmo
————Edited for space————-
Device jfltetmo not found. Attempting to retrieve device repository from LiquidSmooth-Devices Github (http://github.com/LiquidSmooth-Devices).
Found repository: android_device_samsung_jfltetmo
Checking branch info
Calculated revision: lp5.1-layers
Default revision: android-5.1.1_r24
Using fallback branch: lollipop
Adding dependency: LiquidSmooth-Devices/android_device_samsung_jfltetmo -> device/samsung/jfltetmo
Syncing repository to retrieve project.
Fetching project LiquidSmooth-Devices/android_device_samsung_jfltetmo
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 –:–:– –:–:– –:–:– 0
[/CODE]

Now it “found” it! Using the fallback branch is a great way to overcome all of the different naming conventions out there.

Linux – keep it simple.