[KERNEL][DEV-ONLY][SGH-T959V/W] Kernel Cleanup [GingerBread][2013/12/17] - Samsung Galaxy S (4G Model)

[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!
Code:
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:
Code:
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

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.
http://forum.xda-developers.com/showthread.php?t=755265
http://glassechidna.com.au/heimdall/
https://github.com/Benjamin-Dobell/Heimdall
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)
Code:
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:
Code:
heimdall flash --KERNEL path/to/kernel/boot.img

Make sure for now that you only use the 1.3.1 version found here.

checkpatch.log
Attached to this post is the latest checkpatch.pl output of the files different from upstream.
Generated by:
Code:
for i in $(git diff --name-only linux-2.6.35.7..android-samsung-2.6.35-galaxys4g-upgrade); do
echo -e "\nRunning checkpatch.pl on: ${i}\n";
./scripts/checkpatch.pl -f ${i};
done 2>&1 | tee out/checkpatch.log

Related

[DEV TOOL] Acidify 0.4.1

This thread is intended only for developers.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
What is Acidify?
Acidify is a tool for building Android builds. It allows easy switching between build types and setting up everything that is needed to build Android.
That said, it is a tool designed for people that are already building Android but want to be able to switch between CM7, CM9, and AOKP easily. It's primarily a convenience tool for TeamAcid developers.
Can I use Acidify?
Of course you can use Acidify! Be aware that it grabs manifests from us (TeamAcid) so in its unmodified state you'll only be able to build Android the way we build Android. As of 0.2.4, however, there are configurable options that allow building for any device. Simply specify any local manifest URLs and the device name in the script.
What do I need to use Acidify?
Short Answer: A POSIX-compliant machine with bash which is capable of compiling Android.
Long Answer: Currently, you need a machine running version 10.10 of Ubuntu or higher to use every feature available in Acidify. Until people contribute code aimed at other distributions and versions, some features (such as grabbing needed packages) may be unavailable. The core features such as initializing the build environment, switching between build types, or building Android itself should theoretically work on any platform running bash and which has all the packages installed that are required to build Android.
How do I install Acidify?
Download a tarball of acidify or clone the repository. Put it somewhere safe and run
Code:
acidify setup
. That will install all the required packages for building Android (if you're on Ubuntu) and it will create a soft link to acidify in ~/bin so that you can access acidify from any directory (assuming ~/bin is in your PATH).
How do I use Acidify?
Run
Code:
acidify usage
for an explaination on how Acidify may be used.
Can I modify or redistribute Acidify?
Yes, you can! Acidify is licensed under the GNU General Public License version 3 (or greater). You can modify it and redistribute it under the terms of the license. See LICENSE for more information.
I found a bug with Acidify. Will you fix it?
For sure! Make an issue in the issue tracker to tell us about it.
I found a bug with Acidify and I fixed it. Do you want it?
We would love it! Submit a pull request.
I wanted X feature, so I implemented it. Do you want it?
Potentially. Submit a pull request and we can discuss it there.
Get it on Github!
Changelog
ABOUT TIME! I was waiting for this all day yesterday, it took you until today to post it, serioiusly, rabble rabble *gets smacked by m4xm4n* Okay okay I'll stop about the ETA's.
Nice work Max!
Oh boy!
This is gonna make my life better.
Sent from my SGH-T959V using xda premium
Well Max thanks dude this will help with some stuff
Sent from my SGH-T959V using xda app-developers app
I will never forget it.
Oh hey,
um,
If you try to switch between build types right now, it's going to mess a lot of stuff up. So don't do it until I push 0.2.0. hehe. whoops.
Changelog
Version 0.2.0 is up on the githubs.
schedtool will now be installed as a required package. (ubuntu only)
Fixed acidify init. Switch between build types cleanly and correctly.
Fixed acidify deploy. I had it deploying all builds as CM9 and not removing the correct builds. Blame it on late night programming.
Minor things you won't notice.
Version 0.2.1 is up on the githubs
Fixed a derp that made goo upload not work for CM7 and CM9
Version 0.2.2 is up on the githubs
Fix uploading to goo
Fix make clobber call in cleanenv()
Fix for acidify init in a clean directory
Add symlink to ~/bin/acidify (thanks fbis251)
Version 0.2.3 is up on the githubs
Add colorized output and timer (thanks fbis251)
Add error checking to checkenv() (thanks fbis251)
Version 0.2.4 is up on the githubs
Simplify configuration and increase acidify device agnosticism. You should be able to compile for any device now by configuring correctly for it. Simply change the local manifest variables and the device variable.
Version 0.2.5 is up on the githubs
Added temporary workaround for building AOKP (thanks fbis251!)
Version 0.2.6 is up on the githubs
Don't run timer on 'acidify version' or in the absence of a command.
Colorize error output
Version 0.2.7 is up on the githubs
Add automatic kernel building and cleaning to CM7.
Apply the AOKP build workaround only if the device is galaxys4gmtd.
Version 0.2.8 is up on the githubs
Make kernel cleaning device agnostic and clean before switching build types. Left over kernel build stuff from CM7 will break AOKP and CM9 builds.
Version 0.2.9 is up on the githubs
Install pngcrush as a required package in setup()
Fix Goo.im upload
curl isn't installed on ubuntu by default. Install the required packages before trying to grab repo using curl (thanks fbis251)
Update deploy() for AOKP milestone 6 (thanks fbis251)
Update deploy() to reuse code (thanks fbis251)
Update upload() (thanks fbis251)
Version 0.3.0 is up on the githubs
Added a check for lsb-release and made the error a little more readable (thanks xaocon)
Changed check for /etc/lsb-release to look for a readable regular file and changed the logic for defaulting the DISTRIB_ID value. (thanks xaocon)
Add Gummy support (thanks fbis251)
Version 0.3.1 is up on the githubs
Updated upload() to use rsync with resume support (thanks fbis251)
Add Linux Mint support to setup()
Version 0.3.2 is up on the githubs
Gummy: get-prebuilts added (thanks fbis251)
Version 0.3.3 is up on the githubs
Update constants and add ~/bin/acidify check (thanks fbis251)
Version 0.3.4 is up on the githubs
Add boot image flashing function
Version 0.4.0 is up on the githubs
Massive changes to how configuration works. Please update and read this.
For anyone wondering, the AOKP repo is set up and you can grab and compile Team Acid's version of AOKP using Acidify. .
There's still one minor hitch with bml_over_mtd but I'm assuming no one's really gonna go ahead and grab the source anyway. Boo!
Looks great! Certainly saves me a huge amount of time figuring out how to maintain and switch git/repo between CM9 and AOKP, as well as bugging you guys to find the right local manifests!
Forgive me, but where is the bug tracker?
$ acidify
$ acidify init cm9
Acidify version 0.2.1
Attempting to initialize environment to build type cm9
This WILL REMOVE ALL LOCAL CHANGES
/home/jeff/bin/acidify: line 126: [: !=: unary operator expected
if [ ${ANDROID_BUILD_TOP} != $resdir ] # Apparently fails with empty ${ANDROID_BUILD_TOP}
+ '[' '!=' /home/jeff/Documents/android-build/test ']'
../acidify/acidify: line 126: [: !=: unary operator expected
Looks like it needs a check for an empty string there
jeffsf said:
Looks great! Certainly saves me a huge amount of time figuring out how to maintain and switch git/repo between CM9 and AOKP, as well as bugging you guys to find the right local manifests!
Forgive me, but where is the bug tracker?
$ acidify
$ acidify init cm9
Acidify version 0.2.1
Attempting to initialize environment to build type cm9
This WILL REMOVE ALL LOCAL CHANGES
/home/jeff/bin/acidify: line 126: [: !=: unary operator expected
if [ ${ANDROID_BUILD_TOP} != $resdir ] # Apparently fails with empty ${ANDROID_BUILD_TOP}
+ '[' '!=' /home/jeff/Documents/android-build/test ']'
../acidify/acidify: line 126: [: !=: unary operator expected
Looks like it needs a check for an empty string there
Click to expand...
Click to collapse
You're using an old version. That error has been fixed.
FBis251 said:
For anyone wondering, the AOKP repo is set up and you can grab and compile Team Acid's version of AOKP using Acidify. .
There's still one minor hitch with bml_over_mtd but I'm assuming no one's really gonna go ahead and grab the source anyway. Boo!
Click to expand...
Click to collapse
I left my laptop syncing before I left the house
Sent from my SGH-T989 using xda app-developers app
Awesome. We'll finally have some more people messing with the AOKP source. I've been hoarding it all to myself, but if I had tried to share it without the local_manifest.xml it would've gotten messy quick. Good thing Max made this script .
Tell me when you try building, I wanna see if all the problems I had aren't there anymore.
EDIT
You should hop onto IRC for a bit.
I just pushed a few updates to Acidify which brings us to 0.2.9
It was updates to upload() and deploy() if you're using goo.im for uploads or pushing the builds to your sdcard via ADB. It'll be easier to add new devices. Once I get the repo issues sorted with AcidGummy I'll also add it to the list of available roms that you can download and build.
Acidify version 0.4.0
This is the last bash release. I will be rewriting acidify in Python after this.
This release introduces a global configuration file so script modifications are no
longer required or encouraged. Additionally, all config options can be overridden by
the environment. This makes way for acidifies use in automated build scripts and
when building for multiple devices. Further more, if a build environment is
configured, you can invoke acidify from anywhere.
See config.sample to create a config for yourself. Save it as ~/.acidify/config
e.g. for running with environmental variables:
DEVICE=vibrantmtd MANUFACTURER=samsung acidify config
will run acidify config for the device vibrantmtd instead of whatever the script's
defaults are, or the options set in the config file (if present).
Options priority ENV(highest), config file, script defaults (lowest)
m4xm4n said:
Acidify version 0.4.0
Click to expand...
Click to collapse
I am trying to run latest script, and no go. What am I doing wrong?
[email protected]:~/src/aokp$ acidify setup
....
....
Your machine is ready to setup the Android build environment
Please see http://source.android.com/source/initializing.html for
instructions on setting up ADB and the udev rules required.
Elapsed Time: 10 sec(s)
[email protected]:~/src/aokp$ acidify init aokp
Acidify version 0.4.1
Attempting to initialize environment to build type aokp
This WILL REMOVE ALL LOCAL CHANGES
/home/galets/bin/acidify: line 54: /.acidify/buildtype: No such file or directory
Error: Could not write to /.acidify/buildtype !
do I need some env variables configured?..
**EDIT:** My bad... I guess I was supposed to create ~/.acidify/config
It's not listed anywhere, but... First run setup.
git clone https://github.com/teamacid/acidify.git
cd acidify
mkdir ~/.acidify
cp config.sample ~/.acidify/config
./acidify setenv
./acidify setup
./acidify init <yourtype>
./acidify init <yourtype>
Click to expand...
Click to collapse
Need to run it twice... or mkdir .repo manually once. Either way. First time it creates the folder too late for it to succeed, so easiest thing to do is just run it twice. And we copy the config.sample, which will build for our phone but doesn't have a working directory set, and then force it to use the current directory as the build folder, so we keep everything nice and neat.
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Also, depending on how much you care about things, might want to sudo -s. Or not.
Theraze said:
It's not listed anywhere, but... First run setup.Need to run it twice... or mkdir .repo manually once. Either way. First time it creates the folder too late for it to succeed, so easiest thing to do is just run it twice. And we copy the config.sample, which will build for our phone but doesn't have a working directory set, and then force it to use the current directory as the build folder, so we keep everything nice and neat.
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Also, depending on how much you care about things, might want to sudo -s. Or not.
Click to expand...
Click to collapse
I am stuck at the acidify init successfully downloading all but 3 projects. When I try to re-run "acidify init" or "acifidy sync", I'm geting this:
Fetching projects: 99% (311/314) Username for 'https://github.com': Username for 'https://github.com': Username for 'https://github.com':
I can enter user name, but it won't accept my password
I will clean my work folder and try to re-fetch all...
Edit: I think following 3 commands will never complete:
galets 21984 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 21986 21984 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_libhardware
galets 21996 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 21997 21996 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_msm7k
galets 22024 20516 0 17:11 pts/1 00:00:00 git fetch gh --tags +refs/heads/*:refs/remotes/gh/*
galets 22025 22024 0 17:11 pts/1 00:00:00 git-remote-https gh https://github.com/AOKP/android_hardware_qcom_media[/QUOTE]
I verified that my password is 8 characters (there's apparently a bug in git)
That's an issue with AOKP, not Acidify. You'll have to wait until they fix all the things they have tendency to break.
Sent from my super fancy SGH-T959V with Magic Debugging Powers
On AOKP build failures, you might want to follow [REF] Building AOKP -- Transient Issues -- 2012/09/18
Though until someone uploads the ics framework files, you're stuck. So... like I said...
Just be aware... can't actually build AOKP without already having the ics framework files, because the AOKP team is mucking about with their repos and haven't updated everything properly quite yet. CM7 and CM9 build okay though.
Click to expand...
Click to collapse
Watch that thread jeffsf pointed to and when FBis251 or someone actually uploads a working copy of the files, THEN you can build AOKP. Or you can build CM7 or CM9 right now.

How do I get Ezekeel's patches of BLN, ...?

I want to get Ezekeel's patches of BLN, live oc to build my first jellybean kernel.
I have currently applied _thalamus' work.
I tried this http://ariejan.net/2009/10/26/how-to-create-and-apply-a-patch-with-git/
On https://github.com/Ezekeel/GLaDOS-nexus-s/tree/bln
But I get
git remote add remoterepo https://github.com/Ezekeel/GLaDOS-nexus-s.git -b bln
fatal: Not a git repository (or any of the parent directories): .git
[email protected]:~/patch/bln$ git remote add remoterepo https://github.com/Ezekeel/GLaDOS-nexus-s.git
fatal: Not a git repository (or any of the parent directories): .git
[email protected]:~/patch/bln$
Click to expand...
Click to collapse
Am I doing something wrong?
you have to git merge the branch of Ezekeel's repo that has the feature you want
git remote add remoterepo http://.....
git remote update
git checkout your working branch
git merge remoterepo/BLN (e. g.)
:highfive:
Hmm thanks. I am trying it out now.
I hope it's compatible with Jellybean.
I tried to update the kernel to 3.0.38 but it prompts me every time if I am sure. And sometimes I have errors patching.
djjonastybe,
Thanks for your "How to compile a kernel" tutorial in the developers section. Using that I was able to 'roll my own' kernel the way I wanted it (stock JB kernel merged to latest linux version + voodoo.)
Although I didn't use it, I experimented with Ezekeel's BLX. I was unable to 'git merge' it into the aforementioned kernel from the BLX branch. (Every file had a conflit, and although git has a steep learning curve I am guessing the reason is it was merged into ICS.) I was able to get it to work using 'git cherry-pick', and I am guessing BLD is the same.
Once I had compiled my kernel I used 'dsixda-Android-Kitchen' as a frontend to unpack boot.img. I replaced zImage and repacked boot.img.
I registered with this forum to ask a question, but through trial and error I found that that it was important to use the ramdisk associated with the target ROM, rather than the stock ramdisk. Many CWM updater-scripts do this 'on the fly'...
(I was surprised to see that several kernel installers also copy a few .ko modules into /system/modules. One was for BLN, but I did not research the reason for the others...)
...
I have been reading [and reading] and 'crackflashing' for around a year, but this is my first post. I would like to thank everyone who shared up-to and including the following: CM team, koush, ezeekel, thalamus, adamg, kibmcz, legolas93, Steven676, AOKP team and mathkid. (I couldn't think of everyone, but if you have contributed then thank you!.)
--== HurryNwait ==--
Nexus S + CM10 v1.10 + my custom kernel

Requesting Repository Forks

If you wish to request omni forks a repository from AOSP, in order to implement a patch into omni, please post this request here. Eventually this will be carried out via jira (http://jira.omnirom.org)
When posting, please give the path to the repository, and a link to what you want to merge, or a description.
For example if you wish to cherry pick a patch into it, a link to the patch and brief description of the reason for the patch.
We'll then have that repository forked and made available on github and gerrit, permitting you to submit your change.
Before you request, please check on github to ensure it isn't already forked!
For example :
frameworks/base - Needing forked so I can introduce multi window functionality (link here to information)
hardware/broadcom/libbt - Mainly for board-specific configurations (link), but newer CM commits also look promising.
If new device bringups aren't planned yet, ignore the followings:
device/lge/p880 and kernel/lge/p880 - Device bringup (kernel has a non-standard naming at CM repo, it should be android_kernel_lge_x3 (x3 is the board name))
vendor/lge (maybe Omni should create one from scratch)
Adam77Root said:
hardware/broadcom/libbt - Mainly for board-specific configurations (link), but newer CM commits also look promising.
If new device bringups aren't planned yet, ignore the followings:
device/lge/p880 and kernel/lge/p880 - Device bringup (kernel has a non-standard naming at CM repo, it should be android_kernel_lge_x3 (x3 is the board name))
vendor/lge (maybe Omni should create one from scratch)
Click to expand...
Click to collapse
We do have a vendor/lge with just mako, although I'm not sure if its current location.
Vendor blob repos are a legal mess, which is why CM kept them at TheMuppets. We'll likely do something similar if we haven't already (I haven't synced since coming home.) Among other reasons to keep them separate is in the case of a DMCA takedown - usually that happens only to a single repo (see the HTC vendor repos earlier this year) but there's always the risk that damage might be more widespread.
android_external_clang
http://review.cyanogenmod.org/#/c/29799/2
Needed for building my msm8960 device (Motorola Photon Q, xt897c).
arrrghhh said:
android_external_clang
http://review.cyanogenmod.org/#/c/29799/2
Needed for building my msm8960 device (Motorola Photon Q, xt897c).
Click to expand...
Click to collapse
CM bootable recovery and some commits over system core
Black_Prince said:
CM bootable recovery and some commits over system core
Click to expand...
Click to collapse
No for CWM - We're working on forking TWRP in, but some fixes still need to be made to allow it to work on devices with unified recovery/boot image. (Probably one of the biggest holdups for the exynos 4210 family - Sonys with unified boot/recovery can at least use Dees_Troy's FOTAKernel trick).
Getting CWM to build in a tree requires hacks all over the tree in multiple repositories. TWRP is much more self-contained, but needs some tweaks to the build system in order to get it to build properly on a userdebug (as opposed to eng) build.
Entropy512 said:
No for CWM - We're working on forking TWRP in, but some fixes still need to be made to allow it to work on devices with unified recovery/boot image. (Probably one of the biggest holdups for the exynos 4210 family - Sonys with unified boot/recovery can at least use Dees_Troy's FOTAKernel trick).
Getting CWM to build in a tree requires hacks all over the tree in multiple repositories. TWRP is much more self-contained, but needs some tweaks to the build system in order to get it to build properly on a userdebug (as opposed to eng) build.
Click to expand...
Click to collapse
Hmm but until the twrp is ported should i test build for some galaxy devices like SG S2 note 1 with cwm ?
It will make me to push changes to git in device tree ... and will be easy to add support
Black_Prince said:
Hmm but until the twrp is ported should i test build for some galaxy devices like SG S2 note 1 with cwm ?
It will make me to push changes to git in device tree ... and will be easy to add support
Click to expand...
Click to collapse
I'll pull up a remote to use for bootable/recovery until we fork (unless plodey already forked it) from TWRP, won't be able to provide it until tonight.
However, right now, it will only build a working recovery if you do an eng build instead of userdebug. If Dees_Troy's talk at BABBQ is ever posted, that's what I was talking about when I trolled him at the end.
Something like:
Code:
. build/envsetup.sh && brunch custom_n7000-eng
or something like that.
Old
def WriteRawImage(self, mount_point, fn):
"""Write the given package file into the partition for the given
mount point."""
fstab = self.info["fstab"]
if fstab:
p = fstab[mount_point]
partition_type = common.PARTITION_TYPES[p.fs_type]
args = {'device': p.device, 'fn': fn}
if partition_type == "MTD":
self.script.append(
'write_raw_image(package_extract_file("%(fn)s"), "%(device)s");'
% args)
elif partition_type == "EMMC":
self.script.append(
'package_extract_file("%(fn)s", "%(device)s");' % args)
Requested
def WriteRawImage(self, mount_point, fn):
"""Write the given package file into the partition for the given
mount point."""
fstab = self.info["fstab"]
if fstab:
p = fstab[mount_point]
partition_type = common.PARTITION_TYPES[p.fs_type]
args = {'device': p.device, 'fn': fn}
if partition_type == "MTD":
self.script.append(
'package_extract_file("%(fn)s", "/tmp/boot.img");'
'write_raw_image("/tmp/boot.img", "%(device)s");' % args
% args)
elif partition_type == "EMMC":
self.script.append(
'package_extract_file("%(fn)s", "%(device)s");' % args)
elif partition_type == "BML":
self.script.append(
('assert(package_extract_file("%(fn)s", "/tmp/%(device)s.img"),\n'
' write_raw_image("/tmp/%(device)s.img", "%(device)s"),\n'
' delete("/tmp/%(device)s.img"));') % args)
else:
raise ValueError("don't know how to write \"%s\" partitions" % (p.fs_type,))
Flash error in write raw image ...
Also can u cherry pick these commits https://github.com/CyanogenMod/android_system_core/commits/cm-10.2/mkbootimg/unpackbootimg.c
My internal SD card isnt got recognsied , there must be some commits missing in vold ...
I dont even know it got formatted or what in flashing ...
All things working WIFI BLUTOOTH TETHERING CALL DATA MSG MMS OMNITORCH
Also u may have look over https://github.com/CyanogenMod/andr...mmit/f22626cdbecfe27c96f205710173458eab14e1a1
and https://github.com/CyanogenMod/andr...mmit/aee5f78ddec238cec016849acaf1d3007b8b1507
https://android.googlesource.com/platform/hardware/broadcom/libbt
Must haz patch:
https://github.com/CyanogenMod/andr...mmit/4028192a4fe8289bf9b7fb202a2bb2c0d85d98c3
//edit: xplod sorted it out already.
android_packages_apps_PackageInstaller
For
HALO and a feat which enables us to see version of the installed and gonna install app
I need this to make it work with my Samsung galaxy s4
I'm not sure if this is the correct thread, but the following two would be great for i9305 support
smdk4412-qcom-common -> needed for i9305 and t0lte (EDIT: I see this one has now been added)
Thanks!
Hey @pulser_g2,
wondering if i could have the following repositories added in for jf devices,
all features are fully functional with these repositories : branch: cm-10.2 for all
device_samsung_jf-common
android_device_samsung_jflteatt
android_kernel_samsung_jf
CyanogenMod/android_hardware_samsung
CyanogenMod/android_device_samsung_msm8960-common
CyanogenMod/android_device_samsung_qcom-common
@pulser_g2
I just talked to @maxwen and he told me i should post here the needed stuff:
I managed to fix the radio issues today on m7, but i need additionally these commits:
https://github.com/TheMuppets/proprietary_vendor_htc/commit/7bbbe83823525090e7d94c47b439c09a254b380f
https://github.com/TheMuppets/proprietary_vendor_htc/commit/19ed957678d13b489da78d704b27811030688078
https://github.com/TheMuppets/proprietary_vendor_htc/commit/51b006bc8f05757c7dd82361ce6d985e996af360
and please DO NOT merge this: https://github.com/TheMuppets/proprietary_vendor_htc/commit/2b86687a460030199fa42d49207957ce285c1a53
as its not needed and breaks build (I allready have everything in m7-common so no need for vendor)
Thanks in advance
@pulser_g2
we dont need to update anything, please forget my post above, i managed to get it working without all these commits and the right vendor
hardware/qcom/gps - Needing forked so I can build the needed GPS module into my Omnirom build.
The link to this repository is: https://github.com/CyanogenMod/android_hardware_qcom_gps/tree/cm-10.2
I hope it gets included, this saves me a ton of time pulling stuff from other repositories.
Greetings PsychoGame
Galaxy S I9000 (galaxysmtd)
@pulser_g2 Device repos are already forked. Kernel is missing: https://github.com/OmniGalaxyS/android_kernel_samsung_aries
It has android-4.3 and android-4.4 branches up.
Device rocking with Omni!
See you!
Fail
PsychoGame said:
hardware/qcom/gps - Needing forked so I can build the needed GPS module into my Omnirom build.
The link to this repository is: https://github.com/CyanogenMod/android_hardware_qcom_gps/tree/cm-10.2
I hope it gets included, this saves me a ton of time pulling stuff from other repositories.
Greetings PsychoGame
Click to expand...
Click to collapse
I also need android_hardware_qcom_gps (probably best from https://github.com/markcs/android_hardware_qcom_gps/tree/cm-11.0)

[FAQ/HOWTO] An introduction to how-to-build a kernel for MT6589

Hi guys,
I was working on this since some time and here it is
Please read FAQ first
FAQ :
Can I compile a MT6589 kernel for every phone ?
As you know, a MT6589 kernel won't fit in every MT6589 smartphone because of specific configs/files in the kernel source tree.
So, if you compile my kernel which is expected to work on a Faea F2S don't expect it to work on a Acer Liquid E3 for example.
Conclusion : You have to get the kernel source for your phone​
How can I check my kernel source ?
Of course, this is not enough to see "source code for ZTE N986", you have to check if it's full or not and if it works.
Most people don't know what is working kernel source. You just have to read the GPL guidelines that every manufacturer have to complain with :
“ The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. ”
The part which has not to be included is the toolchain but there should reference to it (which toolchain to use)
For MT6589 kernel, the toolchains arm-eabi-4.6 and arm-linux-androideabi-4.6 should be used. (mtk used arm-linux-androideabi-4.6 for kernel but it should be arm-eabi-4.6)
So now you know which toolchain to grab and then for kernel source you have to check this minimal structure :
bionic
kernel
mediatek
build
config
custom
kernel
platform​README​
If I have kernel source, can I build it for my device ?
Erm... Sometimes the structure is here but the kernel source is messy... Why ?
Because you were not provided the matching source of the kernel used on your smartphone and the reasons are multiple (I won't give details).
So, the idea is to run a first build. If you get errors, then check the step above about toolchain and structure.
The next step for fixing errors is to play with source. Good luck for that.​
What are the benefits of a custom kernel for MT6589 ?
First big benefit is to introduce kitkat compatibility because there was an issue on android binder driver in mtk kernel source.
Next benefit is to be able to remove some stuff from mtk which is useless on user side and waste ressources (a lot of debug for example).
Others benefits will be in optimizations or new features (see frandom for example)​
HOWTO :
Build from my repo (specific devices supported) - It's not for compiling your kernel source but to understand how kernel build works​I explain how to build from my repo first because it can help you to understand how you should build kernel source
Prerequisites : A build environment (actually Ubuntu Saucy x64 with build-essentials, ccache, repo, java, perl v5.14+ and openssl) and I won't explain how to get one as there is multiple howto on the net.
For repo, the idea is to create a bin directory in your $HOME (usually /home/accountname/), copy repo binary inside it and then add this bin to $PATH var.
BE CAREFULL TO WHAT YOU DO WITH $PATH VAR ! I always see people doing :
Code:
export PATH=/home/foo/bin
this is erasing $PATH var, just check before and after with echo $PATH
So the idea is to introduce your path AFTER the actual $PATH var
This is easy...
Code:
export PATH=[COLOR="red"]$PATH:[/COLOR]/home/foo/bin
And of course, $PATH is reset once you close terminal and I won't explain how to set $PATH automatically.
Once you got this, everything should be working and it will be easy
Code:
mkdir workdir
cd workdir
repo init -u https://github.com/Dr-Shadow/android_kernel_mt6589_manifest.git -b master
repo sync
Then you should get this in your workdir :
kernel
manifest
mtk-tools
out
ramdisk
scripts
toolchain​Just do :
Code:
cd kernel
./certificates.sh
./build.sh
./certificates.sh is needed only once (it's for signing flashable zip and it will setup some keys for it, just reply to questions and don't add passphrase)
And of course, the build.sh contains most things you need to know on steps for building kernel (which commands to use) and you need to know how it works ​Build from your own kernel source​
I'm building the doc... I have to remind which vars need to be overriden
Reserved
Reserved #2
Thanks for making this thread brother it will help us to learn... Subscribed
Looking forward to the how-to to build with your own kernel source.
Dr-Shadow said:
Hi guys,
I was working on this since some time and here it is
Click to expand...
Click to collapse
Thank you Dr-Shadow! This is very cool. I'm going to try it out!
Great
It's always nice to see further development on MTK Based Devices.
Regards
I'll chip in and say thanks too. Finally getting around to trying to compile Alcatel's OneTouch Hero (aka TCL Y910) provided sources.
I might be in as well with A820, but I'm relatively new to Android and have only done porting of 4.1 and 4.2 so far.
Haven't built anything although I have some knowledge about the source code and SDK, which I've only used for reference purposes and the tools from it.
Will try to compile the stock kernel this weekend, but I'm not quite sure if something else is needed, even if the kernel source seems complete to me.
I'm a quick learner and have a lot of programming experience in other technologies, even thought I'm more of a front-end developer these days.

[SCRIPT] Cherry-pick script for automatically patching Android platforms

Those of you maintaining unofficial ROMs that need some device specific patches to the android platform that are not (yet) merged into the official sources often face the same problem: When syncing with upstream you either have to cherry-pick your patches again manually, or for those changes that are not committed there may be merge errors.
Additionally, when there are many patches in various repos it can get hard to keep track of them.
I faced the same situation while working on my phone, which needs changes not merges into any official sources except for NamelessROM. And those of you who know me, know that I like scripts doing the work for me.
So I decided to write a tiny script to do all that for me.
Sure, I could have written a script like
Code:
cd frameworks/base
git cherry-pick <blah>
git cherry-pick <blah2>
cd ../../system/core
git cherry-pick <blah3>
But I just don't like hardcoding, and maintaining the script would also be way, way harder.
So I came up with this solution:
Storing the fetch URLs as well as the commit IDs in arrays. Then I can call one after another fully automatic via for-loops.
One issue remained, though: if a cherry-pick fails the next commits would also fail. Which is why the repo gets automatically reset if a cherry-pick doesn't apply properly.
An example script can be found HERE or in the attachments.
Now, the most important part for you: How do you make the script compatible with your ROMs sources?
There are just a few values you have to take care of:
Code:
##### Definable values
remote_name="p880-dev_autofetch"
paths="frameworks/native frameworks/base frameworks/opt/telephony"
commit_id[frameworks_native]='8465cdba74a038bb29598cfb4f48754b83124f48 208b1fcc0df405dc15582798c4e5406ba16201a9 49beaf826eb1c4eae3fe3202ef682a5973213c2d c83b9661c0fca41a5f43473def58379c7d7ae7d7 0c880a230ef4331cc071d45b6b06a8b0572c5a8f'
commit_id[frameworks_base]='45b92f41db68285e87980fafaa263511a6568705'
commit_id[frameworks_opt_telephony]='e7490c2c565d388212d84f627fb59c2bcccf8d61'
repo_url[frameworks_native]='[email protected]:laufersteppenwolf/android_frameworks_native.git'
repo_url[frameworks_base]='[email protected]:laufersteppenwolf/android_frameworks_base-1.git'
repo_url[frameworks_opt_telephony]='[email protected]:laufersteppenwolf/android_frameworks_opt_telephony.git'
#####
remote_name specifies the name that should be used for fetching (doesn't really matter, it just helps keeping track of what this remote is)
paths specifies the paths to the repos the script is gonna cycle through.
commit_id[name] specifies the commit IDs of the repo "name". While "name" is the path to the repo, but with underscores instead of slashes. Example: if your path is "system/core", the name you have to specify would be "system_core".
repo_url[name] specifies the URL of the repo to fetch. The naming is the same as in commit_id with underscores.
That's it. You can specify as many repos as you need, the script will cycle one after the other.
For an example on how to update the script with more repos, you may want to take a look at THIS commit
Now, how to use the script?
It's as simple as it could be:
Set up the build environment (. build/envsetup.sh)
Execute the script from whereever you want (. cherry-pick.sh)
If you're running the script for the first time or the fetched repo needs an update, you have to add the --fetch argument to (re-)fetch the repo again. (. cherry-pick.sh --fetch)
If you happen to have questions or suggestions, please feel free to let me know!
Mine!
@laufersteppenwolf Nice bro!
Interesting idea.
Will test it soon.
Does it also work for revert commits ?
(They usually take me to nano and I have to ctrl+x to apply them)
Thank you
m0d said:
Interesting idea.
Will test it soon.
Does it also work for revert commits ?
(They usually take me to nano and I have to ctrl+x to apply them)
Thank you
Click to expand...
Click to collapse
Yeah, sure, with a few modifications the script should also be able to revert commits
EDIT: Feel free to test with THIS script after you specified your commits you want to revert. But please note that I did not yet test it.
laufersteppenwolf said:
Yeah, sure, with a few modifications the script should also be able to revert commits
EDIT: Feel free to test with THIS script after you specified your commits you want to revert. But please note that I did not yet test it.
Click to expand...
Click to collapse
I am trying to set up the script,
How must one go setting up repo url for:
https://android-review.googlesource.com/#/c/104728/
5a6037f1c8b5ff0cf263c9e63777444ba239a056
git fetch https://android.googlesource.com/platform/hardware/qcom/bt refs/changes/28/104728/1 && git cherry-pick FETCH_HEAD​
I tried checking for the following,
commit_id[hardware_qcom_bt]='5a6037f1c8b5ff0cf263c9e63777444ba239a056'
repo_url[hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'
repo_url[hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'
commit_id[platform_hardware_qcom_bt]='5a6037f1c8b5ff0cf263c9e63777444ba239a056'
repo_url[platform_hardware_qcom_bt]='[email protected]latform_hardware_qcom_bt.git'​They all gave me:
Code:
*************************************************************
* Entering hardware/qcom/bt
*************************************************************
*************************************************************
* All commits applied successfully!
*************************************************************
There seems to be an error as it always says - * All commits applied successfully!
But, when I check for the commit changes they are not present.
Also,
Is it possible to have a revert in the cherry-pick script? As in before a particular cherry-pick I need to revert a commit,
so I need to check if the commit is a cherry pick or a revert,
Where as now it is sort of hard-coded:
for commit in ${commit_id[${commit_path}]}; do
sleep 1
cherry-pick "$commit"
done​and
for commit in ${commit_id[${commit_path}]}; do
sleep 1
revert "$commit"
done​An if else needs to be added somehow,
will try to test once I get the script to start working
Hi there!
I know this thread hasn't had activity for years but it is the only possible resource I find for minimally automating security patching our rom sources... I am new to building and have a couple of viable nougat builds almost ready for Xiaomi Mi Mix, and a third one with more problems. One of the last things I am working on is security patching my working directories and as I have no background in programming or linux or any technical stuff in general, I get quite lost about git cherry-picking, git fetching, patching, merging, etc.
From what I see here this script could make the whole thing easier but I do not know if it works. Anybody out there willing to give me a hand here?
Thanks in advance

Categories

Resources