How to add an I/O Scheduler to your kernel

How to add an I/O Scheduler to your kernel:

Praise God, another succesful addition to the TBLTE kernel was that of adding the FIOPS I/O scheduler to the kernel. What is an I/O scheduler? Well it is the part of the kernel that handles, or schedules, input and output. Particularly, this has to do with writing and reading to and from media, like your hard drive, flash drive, etc.

So, how do we do that? How do we add I/O schedulers to our kernel?

Well, for the TBLTE kernel, I will show you what I did, and you can add to your kernel similarly.

Go to the block folder in your kernel source. The first thing that you need to do is add the fiops-iosched.c file. Whatever I/O scheduler you want to add will be named like this: {NAME-iosched.c} you can search Google or github for them, or take them from my source if you would like.

Once you put your fiops-iosched.c file in your kernel’s ./block/ folder, you can now edit two other files in that folder. You need to add the new scheduler to the make file, so it knows to make it, you can do that like so:

Open ./block/Makefile and add this line after the other *-iosched.o lines:

[CODE]
obj-$(CONFIG_IOSCHED_FIOPS) += fiops-iosched.o
[/CODE]

Notice that it just uses the name of the iosched file, but with an “.o” extension instead of a “.c” extension. The “.c” file you added earlier will create a “.o” (object) file that the Kernel needs to use to “make” the kernel.

Now edit the ./block/Kconfig.iosched file like so:

[CODE]
config IOSCHED_FIOPS
tristate “FIOPS I/O scheduler”
default y
—help—
The FIOPS I/O scheduler. WJH.
[/CODE]

This way, when you are moddifying your configuration, you can select to build it. Notice that it is a “default y”, essentially, I am telling the config file creator to allways assume I want to build this, unless I choose not to. You can also eddit the “—help—” portion to say anything you want. I put my initials in there so I can find it easily with the search tool.

Now open your configuration file. For the stock builds, that would be ./arch/arm/configs/ap88084_sec_defconfig, and add this line:

[CODE]
CONFIG_IOSCHED_FIOPS=y
[/CODE]

Note that you could also do this through

[CODE]$ make menuconfig [/CODE]

.
You may also note, since we gave it a “default y” in the Kconfig.iosched file, we don’t actually need to add this to our configs, as it will be built by default, but I like to declare what I am building in my configs so I remember what I am doing.

There you go! Now when you build your kernel again, the FIOPS I/O scheduler will be added in. It is remarkably simple, just the way I like it. You can read the commit here: [url]https://github.com/alaskalinuxuser/kernel_samsung_tblte/commit/f80320a895612bd1379ca789f88f1d6dfd6e68f9[/url]

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.

 

CONGRATS YOU EARNED A STINKEYE FROM CID!

Well, this certainly is an original code error if I ever saw one.

[CODE]prebuilts/cmsdk/api/6.txt:745: error 8: Removed public class cyanogenmod.platform.R.color
prebuilts/cmsdk/api/6.txt:749: error 8: Removed public class cyanogenmod.platform.R.dimen
prebuilts/cmsdk/api/6.txt:765: error 8: Removed public class cyanogenmod.platform.R.layout

******************************
You have tried to change the API from what has been previously approved.

STOP.
Read this:
https://github.com/CyanogenMod/cm_platform_sdk/wiki/Creating-an-API-for-the-SDK#updating–verifying-the-api

To make these errors go away, you have two choices:
1) You can add “@hide” javadoc comments to the methods, etc. listed in the
errors above.

2) You can update current.txt (locally) by executing the following command:
make update-cm-api

^^^^^^^^^^^^^^^^^^
CONGRATS YOU EARNED A STINKEYE FROM CID!
[/CODE]

It even comes with it’s very own ASCII art, which I did not post here. The above implies that I need to make some changes to my api files. Option #2 sounded really easy, so I gave it a try, here was the output:

[CODE]
$ make update-cm-api
…..edited for space…….
nes/compile/build_aokp7/out/target/common/docs/cm-api-stubs
35 warnings
[100% 5/5] build update-cm-public-api
Copying cm_current.txt
Copying cm_removed.txt

#### make completed successfully (02:47 (mm:ss)) ####
[/CODE]

However, it didn’t solve the problem. Then I tried option #1 by editing the build_aokp7/prebuilts/cmsdk/api/6.txt file. I simply added @hide to the beginning of lines that were flagged, in this case, lines 745, 749, and 769. Once that was done, I stopped getting the stinkeye error. Hopefully that will be useful for you to know as well.

Linux – keep it simple.

Neverallow failures occurred

What does that even mean? Let’s take a look at the code:

[CODE]
libsepol.report_failure: neverallow on line 574 of system/sepolicy/system_server.te (or line 18452 of policy.conf) violated by allow system_server system_server:process { execmem };
libsepol.report_failure: neverallow on line 544 of system/sepolicy/domain.te (or line 9255 of policy.conf) violated by allow mediaserver shell_data_file:dir { search };
libsepol.report_failure: neverallow on line 459 of system/sepolicy/domain.te (or line 9170 of policy.conf) violated by allow mm-qcamerad system_file:file { execmod };
libsepol.report_failure: neverallow on line 459 of system/sepolicy/domain.te (or line 9170 of policy.conf) violated by allow mediaserver system_file:file { execmod };
libsepol.report_failure: neverallow on line 459 of system/sepolicy/domain.te (or line 9170 of policy.conf) violated by allow system_server system_file:file { execmod };
libsepol.report_failure: neverallow on line 433 of system/sepolicy/domain.te (or line 9159 of policy.conf) violated by allow mm-qcamerad system_file:file { execmod };
libsepol.report_failure: neverallow on line 433 of system/sepolicy/domain.te (or line 9159 of policy.conf) violated by allow mediaserver system_file:file { execmod };
libsepol.report_failure: neverallow on line 433 of system/sepolicy/domain.te (or line 9159 of policy.conf) violated by allow system_server system_file:file { execmod };
libsepol.check_assertions: 8 neverallow failures occurred
Error while expanding policy
[/CODE]

From the error output, I can only discern that these should never be allowed to happen in a sepolicy configuration. So, to make ammends with the compiler, I edited build_aokp7/device/samsung/jf-common/sepolicy/system_server.te, build_aokp7/device/samsung/jf-common/sepolicy/mm-qcamerad.te, and build_aokp7/device/samsung/jf-common/sepolicy/media_server.te, simply removing the sepolicy rule that was causing the issue, namely

[CODE]system_file:file { execmod };[/CODE]

It is worth noting that they do appear twice in the list of errors, but only once in the file itself. Hopefully that will help me as I compile AOKP 7.0 for the jfltetmo Samsung Galaxy S4, T-Mobile edition.

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.

Enabling the old Camera api and apps in Android 5 and up

While trying to figure out the problems with video recordings (which were resolved – Praise God!) on the SGH-M919 AOKP Marshmallow ROM, I learned a lot of great things about Android’s camera systems. Not the least of which was how to enable or disable camera and camera2 api’s.

Android has a built in api that handles camera requests. To be more accurate, Android currently has 2. Originally, Android used the camera api, which had a handler that was built into Android, under the source code, and controlled by camera, nested in “packages/apps/camera”. Later, Android phones stated to come with better cameras with more functions, so the camera2 api was built, and controlled from camera2, nested in “packages/apps/camera2”. What exactly is different between the two, I am not sure. Needless to say camera2 has more functionality with modern cameras.

However, despite having more functionality, what I did find is that Android, all the way up to Marshmallow, still has the old built in camera api. What I also found, though, is that it isn’t used anymore. That’s right, if your rom/source/etc. comes with Camera2, that is what the system calls on to handle the camera for things like photos, video recording, skype, etc.

In my travels and trial, though, I also learned that you can “turn on” the old camera api, and “turn off” the new camera2 api, but building and not building the appropriate packages. Most of the roms I deal with still have “packages/apps/camera” there, but the contents are edited or missing so it will not build. I successfully built the old camera api controller by downloading this and putting it in the “packages/apps/camera” folder.

https://github.com/AOKP/packages_apps_Camera/tree/ics

After unzipping it and placing those files in that folder, I then had to edit the “packages/apps/camera2/Android.mk” file like so:

[CODE]
LOCAL_PATH := $(call my-dir)

# leaving the makefile emtpy to prevent the build
# system from traversing the project
[/CODE]

Another option is to delete the camera2 folder entirely, but you may need it later. You can also rename the Android.mk files in the camera2 folder to Android.bak instead. Any of these options will work. In either event, after compiling my ROM, the camera2 app did not get built, so, using OpenCamera, it then worked as before, but with the old camera api! To be honest, I didn’t take too much time for comparisons, but I couldn’t tell the difference in the photo quality. Then again, my phone is a bit older, and perhaps only brand new phones will have cameras that this would actually make a difference.

Linux – keep it simple.

Gitkraken!

As I continue to be blessed in the work of compiling roms and kernels, I have had to take a few new steps for me. One of those steps was Github. I am not very Github savvy, and I really struggled with how to push/pull/commit, etc. In fact, it was so daunting that I didn’t start posting source code and the like for my kernels or device trees, because I was unable to figure out how to make it work! Then I found a tool that actually made sense to me, Gitkraken.

Gitkraken is a program for your computer which allows you to easily work with Github repositories and files. Originally, I had forked an ArcTeam kernel repository for my personal edits, but I was strugling with the Github web interface. It was extreamly teadious to delete 30+ files, one at a time, online. Finally, I couldn’t take the web gui any more, and I began searching for computer programs that would make the interface easier. That’s when I found Gitkraken.

All I had to do was download the program from Gitkraken’s website: https://www.gitkraken.com/download , and intall it like any other Linux program from the command line:

[CODE]sudo dpkg -i gitkraken-amd64.deb [/CODE]

Note that they do not maintain a 32 bit version for Linux. They do have older versions of Gitkraken that are 32 bit, but those versions I tried do not look or work anything like the current version. Fortunately, my computer is 64 bit, so this was not a problem. Gitkraken is available for Windows and Macintosh also.

In either event, opening the program brought me to a somewhat straight forward setup screen, to which I filled in all of my Github account information. After getting set up, I wanted to open my repo. Gitkraken works with local repositories, and can push/pull them to the online Github, so the first thing I needed was my kernel repository. So I downloaded the zip file from Github for my repository (you don’t need to download each branch, just the master worked for me). I put it in a folder I appropriately named “github”, and unzipped it. I then realized I could simply choose to clone repo, and download it in one fell swoop!

Once that was done, I then opened that repository with Gitkraken, and that’s where things got a whole lot easier! Things that confused me before were now made so simple to comprehend, as I could visually see what was going on. Want to make a pull request? Sure, there’s a button for that. Want to compare each commit and see the code that changed? No problem, just click on one. It was that simple! Need to create a new branch? Absolutely, just click the button!

What really made a difference, though, was how easy it was to edit my files. Essentially, I just used a regular browser, made edits in my “github/kernelsource” folder directly to the files. Then, when I opened Gitkraken, it automatically parsed the files and found all of the new changes! All I needed to do was click the “stage”, “commit”, and “push” buttons, in that order, and presto, my online Github repository was up to date with my new changes!

Finally, a Github tool that is made the way it should be! Sleek, smooth, easy, with lots of functionality, but none of the technical heartburn!

Linux – keep it simple.