5,598,820 Members 32,861 Now Online
XDA Developers Android and Mobile Development Forum

[KERNEL][DEV-ONLY][SGH-T959V/W] Kernel Cleanup [GingerBread][2013/12/17]

Tip us?
(Last edited by bhundven; 18th December 2013 at 09:56 AM.) Reason: s/trfs/tfsr/g
bhundven's Avatar
Recognized Developer - OP
Thanks Meter 4455
Posts: 2,001
Join Date: Aug 2009
Location: Seattle, WA
Default [KERNEL][DEV-ONLY][SGH-T959V/W] Kernel Cleanup [GingerBread][2013/12/17]


Well, hello there stranger.

This is a development only thread. If you are having a problem building, installing, using the kernel or it's source code, please turn to the Q&A Thread.

If you found a bug and have a log from dmesg or logcat, or have a patch, this is where to comment on development activities.

I'm trying to keep this a short OP, because you all know the problems we've had in the past with this kernel, so @jeffsf and myself are going through the stock drop and cleaning out any unused code so we can easily port forward and possibly figure out aries kernel issues.

Currently, as you can see in the OP title, this is for GingerBread. I know, nothing terribly new. But that tag will change. Right now, it's in the cleanup phase. This OP will probably change a lot to keep up to date with the development conversations that will follow in this thread.

I've already started a bunch of work, but I'm always open to help.

  1. Clean out any code that is different from v2.6.35.7 that has nothing to do with SGS4G.
  2. Clean up code that is different (inline) to use "#if defined" so that this platform could be disabled, and another platform could be enabled cleanly with Kconfig. (think about multiple phones in one source tree...)
  3. Once code is cleaned up (section mismatches removed, warnings caused by code we've added, etc..) and tested, porting to newer kernel versions like 3.0.x and 3.4.x becomes much easier.

If you plan on helping out, I have a few rules:
  1. This is a long term project. I'm looking at 3.4.x and 3.10.x android kernels. You won't find fancy bells and whistles here. As this project progresses, releases will be cut. At release points, other developers are welcome to fork and add features. I will start different branches for 'porting' and for 'features' to keep track of the two activities so we can keep moving forward.
  2. Every commit must be tested. Make sure it boots, and area's you've affected work properly. No new build warnings or section mismatches.
  3. Try to keep your commits targeted... An example of a non targeted commit was the v2.6.35.7 merge I made. I also cleaned up a few things that should have been done in separate commits. Oh well. The rest of the commits I made were exactly what I mean.
  4. make it awesome, I think this device can keep working for a while and be up to date!
  5. Try to use ./scripts/checkpatch.pl to check the changes you made to a file. Fix the errors and warnings, only on code you have changed. If it is a lint error/warning in code that is upstream code, leave it alone. We are not maintaining the kernel, we are only maintaining the changes we are making to it.
  6. Either use 'git format-patch' to send me patches or fork the repo, make changes to your local fork, and open a pull request.

I've cleaned out a ton of other platform cruft that has nothing to do with SGS4G, as seen here.

I tried to merge, but tfsr broke. So moving to MTD.
It would be nice to not have to rebuild a ROM over and over. Anyone feel up for making a GB MTD rom?


I use linux to build. Other platforms: Your Mileage May Vary!

sudo mkdir -p /build/galaxys4gmtd /opt

sudo chown -R $(id -un):$(id -gn) /build /opt

curl -O ~/Downloads/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2 http://sourceforge.net/projects/bhundven.u/files/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2/download

cd /opt

tar jxf ~/Downloads/arm-2009q3-67-arm-none-linux-gnueabi-i686-pc-linux-gnu.tar.bz2

cd /build/galaxys4gmtd

git clone https://github.com/bhundven/android_kernel_samsung_galaxys4gmtd

git clone https://github.com/bhundven/android_initramfs_samsung_galaxys4g

cd android_kernel_samsung_galaxys4gmtd

git checkout -b android-samsung-2.6.35-galaxys4g-scrub-deux origin/android-samsung-2.6.35-galaxys4g-scrub-deux

the file in 'out/galaxys4g/arch/arm/boot/zImage' is the kernel image you'd flash to the kernel partition.


I have a few guidelines for branching and branch names.

Name them what they are. Long branch names allow everyone to read it and know what it is.

A few of them are upstream like 'linux-' is a branch of the tag 'v2.6.35.7'.

Ones that are named too similarly, like the aosp and cyanogen(aries) 2.6.35 samsung kernels get the name prepended for clarity:

As for working branches, I name it:

android-samsung-<version>-<board>-<branch topic>

Where version would be the full minor version, like 2.6.35 or 3.0. Not the full version including the stable version number.

Board is the board name. 'galaxys4g' is what we've always used for BML kernels, and 'galaxys4gmtd' for MTD kernels.
This kernel will eventually be MTD, hence the repository name.

The branch topic is something you could describe in <= 3 words.

Current branch topics:
scrub: no numbers, so the original addition of the sgs4g code.

upgrade: merged in the linux- branch (technically, the v2.6.35.7 tag in this case)

scrub-deux: After merging v2.6.35.7, there are a few rather large commits with the initial source drop and file permission fixes that make it hard to diff through commits. This branch was branched from tag v2.6.35.7 and had the difference of 'linux-' applied to HEAD. This allows us to start chopping up that one large patch into smaller commits that are more easily merged/rebased to other branches (for porting).

Future branches coming up will have to do with the results of cutting up the one patch. One for drivers (each driver), one for sound, one for architecture specific, etc.

Once things are broken down this way, a lot of code will have been cleaned up and as I said in the scrub-deux branch description, it will make merging, rebasing, and cherry-picking these changes for porting purpouses.

There are currently no planed releases.
Since it looks like I'll have to start moving to MTD sooner rather then later, I'm also looking at skipping ICS and JB, and going to KK.

As for testing the build, I'm using the Stock_KJ6_+_root-One-Click.jar
Let the rom settle after it boots up, and power it off. Heimdall flash the built zImage. TADA.
If you don't understand what I just said, don't forget to ask in the the Q&A Thread.

Issue Tracker
The Following 11 Users Say Thank You to bhundven For This Useful Post: [ Click to Expand ]
(Last edited by jeffsf; 21st December 2013 at 06:36 PM.)
jeffsf's Avatar
Recognized Contributor
Thanks Meter 960
Posts: 1,076
Join Date: Mar 2011
Location: San Francisco

If you're interested in helping out, or just got here because you searched "flash kernel" or the like, I prefer heimdall to manage "raw" flashing. I find it to be very robust and also runs on Linux and Mac OS.


This is not a one-click kind of thing (though you could use one of the one-click installers to get back to GB).

I'm a command-line guy for simple tasks, so I use (v1.3.x)
heimdall flash --kernel path/to/kernel/boot.img
Edit -- When I tried to flash on my Mac using v1.4.0 (ignoring @bhundven warnings in the next post), I found that I needed to match the returned PIT partition name to get it to work:
heimdall flash --KERNEL path/to/kernel/boot.img
Nexus 5, custom OmniROM builds (don't panic, it means I can brick my SGS4G without fear)
Samsung Galaxy S 4G -- Development version of OmniROM
Fromerly: Development version of Team Acid's CM9 source, Hefe Kernel of Darkness, KG4 modem.
Working on: Cleaning up the build tree for OmniROM and Samsung kernel sources

WiFi Performance, GB vs. ICS, and how to measure it yourself.

FreeBSD, Ubuntu, MacOS X, OpenWRT
Motorola Micro-TAC ("Micro" ) Nokia 2160, 8260, 6681, E70, N900, then had to move on
The Following 4 Users Say Thank You to jeffsf For This Useful Post: [ Click to Expand ]
bhundven's Avatar
Recognized Developer - OP
Thanks Meter 4455
Posts: 2,001
Join Date: Aug 2009
Location: Seattle, WA
Make sure for now that you only use the 1.3.1 version found here.
The Following 2 Users Say Thank You to bhundven For This Useful Post: [ Click to Expand ]
bhundven's Avatar
Recognized Developer - OP
Thanks Meter 4455
Posts: 2,001
Join Date: Aug 2009
Location: Seattle, WA
Default checkpatch.log

Attached to this post is the latest checkpatch.pl output of the files different from upstream.

Generated by:

for i in $(git diff --name-only linux-; do
  echo -e "\nRunning checkpatch.pl on: ${i}\n";
  ./scripts/checkpatch.pl -f ${i};
done 2>&1 | tee out/checkpatch.log
Attached Files
File Type: bz2 checkpatch.log.bz2 - [Click for QR Code] (411.9 KB, 10 views)
The Following 5 Users Say Thank You to bhundven For This Useful Post: [ Click to Expand ]
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes