[Samsung Galaxy S (4G Model)] bhundven:
[INTRO]

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.

[GOALS]

Clean out any code that is different from v2.6.35.7 that has nothing to do with SGS4G.

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...)

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:

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.

Every commit must be tested. Make sure it boots, and area's you've affected work properly. No new build warnings or section mismatches.

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.

make it awesome, I think this device can keep working for a while and be up to date!

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.

Either use 'git format-patch' to send me patches or fork the repo, make changes to your local fork, and open a pull request.

[PROGRESS]

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

I tried to merge 2.6.35.14, 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?

[BUILDING]

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

./build.sh

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

[BRANCHES]

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-2.6.35.7' 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:

cm-aries_android-samsung-2.6.35
aosp_android-samsung-2.6.35-gingerbread

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-2.6.35.7 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-2.6.35.7..android-samsung-2.6.35-galaxys4g-upgrade' 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.

[RELEASES]

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.

[SOURCE]

Source

Wiki

Issue Tracker