Database Develop

[Q][Sprint] Kernel compile

I'm having a problem compiling a kernel for a
Sprint CDMA 7" GT.
I use unpack-initramfs to grab the rootfs from
the original EF17 kernel.
I put that dir location in CONFIG_INITRAMFS_SOURCE=""
in the p1_defconfig file in Kernel/arch/arm/configs
In the kernel directory I issue the commands:
make clean
make p1_defconfig
make
The kernel compiles fine, but there's a 3Mb
difference between the original EF17 kernel
and the one I compile.
If I extract the rootfs from my kernel it's
the exact same as the one extracted from the
original. Have I missed a step? I've done this in the past for my Epic 4G.

i have similar issues that i've been battling with..the kernel coming out smaller isn't 100% indicative of a bad compile...i bet your kernel will boot but 3g (and possibly sound and more) don't work
i emailed samsung open source explaining what i did to compile and this was their response.
my query:
I downloaded the source code for the SPH-P100. I followed the directions in the README_kernel.txt to compile. As well as setting up the unmodified initramfs from the stock kernel. I can boot the kernel on the device however the resulting zImage size is 4.2MB compared to the 5.7MB zImage pulled from the device. I've not made any extra changes to the config or anything else other than what is needed to compile. Despite the size difference using the unmodified p1_defconfig (except setting the initramfs path), the problem that I have is the 3G radio will not start. I get a circle with the slash in the status bar and any dialer codes that pertain to the radio just force close. dmesg and logcats do not turn up any useful information or errors. Flashing the stock kernel back to the device alleviates the issue. So my questions are as follows: Is the source code complete? If so what could I be missing that would cause the radio to not start? Thank you in advance for any input on the issue.
Click to expand...
Click to collapse
and their response:
[SAMSUNG OSRC COMMENTS DELIVERY NOTIFICATION]
Dear customer,
Thank you for your continuous interest on our product.
We received your request on OSRC.
We reviewed your inquiry but unfortunately we couldnt publish the source code for some modules, because it is loadable kernel module and contains samsung proprietary code.
We published open source codes that are covered licenses which have obligation of publishing source code. (ex. GPL, LGPL, MPL...etc)
But we do not guarantee that open source code is excutable in target device. We are sorry for not giving you an correct anwser upto your satisfaction.
We are sorry for not giving you an correct anwser upto your satisfaction.
Thank you!
Sincerely yours
Click to expand...
Click to collapse
so for now until we can figure out what is missing we are out of luck as they are no help
when i have time i'll gladly work with you, oldmacnut, and any one else that can contribute into making a working base kernel from source

Thanks. This truly sucks and will impact my future choice of product purchases.

[development]-kernel 3.4-freexperia

hy all
this is an project starter for android 3.4 kernel development for all msm7x30 mogami devices
sources are hosted on
https://github.com/freexperia/android_kernel_semc_msm7x30
br
J

Project Status
- we got initial branch after diffing lost of branches
M7630AABBQMLZA203029A
https://www.codeaurora.org/gitweb/q...it;h=4b2b84c6a0b6d29864e982a7aecc223acfd2eaa1
forked to our git and with mogami patches aplied
https://github.com/freexperia/android_kernel_semc_msm7x30/tree/M7630AABBQMLZA203029A
latest CAF tag for 7630 not usefull for now
https://www.codeaurora.org/xwiki/bin/QAEP/release
"November 16, 2012 M7630AABBQMLZA40701070 - msm7630 - M7630AABBQMLZA40701070.xml - 04.01.02" android 4.1

ETA
depending on problems and developers that will join
from 6 months to NEVER

This is a bold task. Perhaps you could look at the developments of irii-soft (and some others), they have replaced some crap Sony-specific code with generic wrappers. Main obstacle if I remember is memory maps now, there was an issue with partition maps but ATAG can be easily over-ridden via kernel command-line.
Getting it to boot should be trivial, sound and video will be difficult, and RIL may be never working due to lack of sources. Regardless, all the best. When I have more time I plan to help irii with his work on a "generic" 2.x kernel newer than what we have (because 3.x seems outrageous at this point).

Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)

Boudin said:
Is there a wiki, a forum or something like that lists all the non-standard things that have already been found ? (some base of work to do)
Click to expand...
Click to collapse
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.

To FXP team,
I don't know if you know or not or even got this far in the development stage but I just wanted to point out a couple of things which may or may not help you...
So with the 3.4 kernel brings newer WiFi drivers which will give a better connection signal on wpa2 security but you might find that devices won't be able to connect to open security networks and WiFi hotspot will probably be broken. I'm posting this as on my gnex using custom kernel (FrancoFransico) he incorporated the 3.4 WiFi drivers a few times and broken hotspot and not being able to use open security WiFi networks were repeatedly reported problems.
I think it may be something hardware specific which allows these features to work on the 3.4 WiFi drivers specific to the nexus 4? You may have more luck trying the 3.0.xx WiFi drivers and getting those to work fully.
Best of luck to you guys!
Sent from my Galaxy Nexus

I'm pretty sure wifi is way down on the priority list, not to be rude but really - who cares about that now. Priority list would be like this:
(1) Get it to boot
(2) Fix primary/critical hardware-specific code for msm7k and qcom platform (display, audio)
(3) Fix RIL
(4) Fix secondary hardware (sensors, bluetooth, wifi)
One step at a time. Getting wifi will probably be trivial because bcm sources are part of the mainline kernel.
With that said, I'm unsubscribing from this thread now. There is massive work to be done and I can see this thread is just going to be filled with posts that have nothing to do with actual development.

All non-dev related posts, and especially "Thank You" posts, will be deleted without further notice. If I have to delete 5 pages of useless posts again, this thread will be locked.
Thank you!​

We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.

adridu59 said:
We have tried for a long time already (as you may already know).
https://github.com/adridu59/semc-msm-3.4/commits/master
https://github.com/adridu59/semc-msm-2.6.35
https://github.com/adridu59/android-msm-2.6.35
https://github.com/ExPeacer/CAF_android-msm-3.0/commits/master
https://github.com/ExPeacer/CAF_android-msm-2.6.32
Have fun with it anyways.
Click to expand...
Click to collapse
Whats the progress so far on this? Bootable already?

CosmicDan said:
Easy to do yourself - download official SEMC kernel source and diff it with the same version of the linux baseline kernel. So to port to newer kernel you can isolate or "extract" the specific code that has been added and changed, and merge or "inject" that into a newer kernel. Easier said than done though, there are massive changes even in linux kernel revisions (0.0.x.0) - let alone alone new majors and minors (x.x.0.0).
There wouldn't be a wiki or anything of this research, because documenting it all would take an unrealistic amount of labor. Considering there are only a small handful of developers capable of it, there's no point. Besides, that's what GitHub and commit logs are for.
Click to expand...
Click to collapse
I was asked by some user of this forum to give some kernel porting guidelines in this thread, so let me introduce myself first. I'm the developer of 3.0.x kernel for Samsung Galaxy Spica (also several other projects for Spica and Galaxy Apollo/Galaxy 3) and currently also Linux kernel developer at Samsung Poland R&D Center. Porting the kernel for Spica was a difficult task, because of poor quality of original kernel code, which required rewriting from scratch most of it, but it was very educational.
It's not easy to give advice, but I'd say that taking all the differences from clean kernel and applying all of that on top of newer version is what should be avoided. Of course those differences should be collected to see what was changed by the manufacturer, but this should be only used for further analysis, not as a ready code.
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree. This will elminate Google's changes (that would be already available in your new base - android-3.4 branch of kernel/common) from the diff.
For getting the diff, I would personally also use Git. If you create a branch in your working tree which contains Android kernel in the version corresponding to your device kernel (using the way I described in previous paragraph), then copying your device kernel sources onto your working tree (remember to make distclean both trees to remove any compiled/generated files) will allow you to see the differences using git status and git diff. (See http://gitimmersion.com/ if you want to learn more about Git.)
Now it's important to split the changes into logically separate parts, for example core changes in arch/arm/mach-whatever_suitable_for_your_device, adding of particular drivers in drivers/, sound/ and include/, modifications to core kernel code in any other directories. It's essential to check whether all the changes are really required or not and why, because minimalizing the set of changes required to be replayed on top of your new base kernel sources will simplify your work.
After collecting all the changes, it's the time to apply them on top of your new kernel sources. All the changes should be applied one by one, checking how much the component that is being touched has changed since your old kernel and adjusting the changes properly. After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Some links that might be useful:
- Linux cross reference, for comfortable reading of kernel code - http://lxr.linux.no/+trees
- Linux Device Drivers, a book about kernel programming - http://lwn.net/Kernel/LDD3/
- Git Immersion, a great Git tutorial - http://gitimmersion.com/
- Android kernel/common repository with full archive - https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary
- Linux stable repository, with all version tags - http://git.kernel.org/?p=linux/kernel/git/stable/linux-stable.git;a=summary
Hopefully what I wrote will be helpful in your project. Good luck and best regards.

Hey tom3q,
thanks a lot for leaving some useful statements here!
tom3q said:
Another thing, rather than using the mainline Linux kernel to compare your phone sources with, it should be better to use Android kernel from Google's kernel/common tree (see https://www.codeaurora.org/gitweb/quic/la/?p=kernel/common.git;a=summary for older version archive) bumped to the same minor version using minor patches (found on kernel.org) or, possibly even better way, by pulling appropriate version tag from kernel.org git on top of proper branch of Android kernel tree.
Click to expand...
Click to collapse
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
tom3q said:
After applying each change, it should be verified that the kernel at least compiles, although it would be even better if you could get the kernel without any (or almost any) modification to boot to some state, e.g. showing something on the console (any chance to get access to serial console on your device?), and then check if it still boots after applying each next change.
Click to expand...
Click to collapse
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert

hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
scholbert said:
Hey tom3q,
thanks a lot for leaving some useful statements here!
I digged for some base kernel for a while.
Found a chromium msm kernel 2.6.32.9 at codeaurora (i know this is not Android).
Anyway, the diff against stock was ~30MB... quite too much.
Like i assumed many basic things are missing as well, so too much to start from.
I guess, i'll step through the other projects... might try 2.6.32-rc8 from the msm tree... just for fun of course :angel:
Nice point... i like these hardware hacks and asked about testpoints for UART3 on the Pro mainboard a few days ago.
It's mentioned and so far i got it, initialized in stock kernel as well. Unfortunately no-one seems to know anything about these testpoints.
Anyway i don't want to spam this thread, so thanks for your attention
Regards,
scholbert
Click to expand...
Click to collapse

FXP said:
hy
scuse my ignorance
but
HOW do you compile an kernel ?
and maybe someone can explain what is the difference between bring-up and port
Click to expand...
Click to collapse
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7

voyteckst said:
I would say that porting is moving and correcting sources from 2.6.32 kernel in our case into 3.x. And bring up is writing particular drivers from scratch?
Sent from my Nexus 7
Click to expand...
Click to collapse
ok
nice explanation
look on first page

diff is 5mb on proper tag
pushed on github

nice to see so many developers trying to help

FXP said:
diff is 5mb on proper tag
pushed on github
Click to expand...
Click to collapse
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.

tom3q said:
Sorry to throw my 3 cents again, but seeing the repository on github, I'd recommend you to use some time to go through Git Immersion. Even if it takes some time, it will simplify your further work, as Git used properly can really make many things easier.
Otherwise, the diff itself looks mostly fine as a starting point, although some of the differences can be probably eliminated.
Click to expand...
Click to collapse
sony added too many changes to be usefull
since there are several api changes on 32->3.x diff is no good
we have to start from clean board-7x30 and populate devices porting drivers 1 by 1
we have to try an device bringup based on sony changes

smaller aosp downloads- JBQ

groups for linaro source
current groups for aosp source
a miscellaneous reference
Would anyone have thoughts to add addtional group tags to the default manifest?
The default.xml could be organized and commented to break up
core (bare metal aosp)
omni (omnirom specific)
build (toolchain and things for compiling)
developer tools (I personally think things like eclipse and adt are fluff even for downloading since I'm probably downloading these types of things independently)
chipset (arm, x86, mips)
device (grouper, mako, etc)
host (ex: windows, mac, linux)
I could then repo init with
repo init -u https://github.com/omnirom/android.git -b android-4.3 -g core,omni,build,arm,linux,mako
and pull down 4 GB instead of 10 GB
original announcement from JBQ
AOSP is big, and downloading and storing all of it consumes a fair
amount of bandwidth and space.
We've been investigating ways to make it smaller. One visible part of
that work is that the master tree is "only" 6.5GB, while Jelly Bean is
about 8.5GB.
We're aiming to go further. Today, I'm deploying an experiment that
can help shrink things.
Repo recently added a feature called "manifest groups" that allows to
restrict the list of projects being downloaded.
I've set up the manifest for the AOSP master branch to include a few
groups. Here are the groups I added:
"device": files that are specific to flagship devices but aren't
necessary to build a generic platform.
"darwin": files that are only necessary when building on a darwin host
(i.e. MacOS).
"linux": files that are only necessary when building on a linux host.
"arm": files that are only necessary when building for ARM targets.
"mips": files that are only necessary when building for MIPS targets.
"x86": files that are only necessary when building for IA targets.
Here's an example, which allows to build the ARM emulator on a linux
host. In this case, the download is 3.6GB, which is a significant
improvement over a full tree:
repo init -u [URI] -g default,-darwin,-device,-x86,-mips
The syntax is hopefully self-explanatory. Note that this is only
currently supported in the master branch.
I'm looking at the possible evolutions:
-marking the projects for individual device families (i.e. crespo,
tuna, stingray, panda), so that it's possible to download the files
for one specific device without getting them all.
-marking the projects that are necessary to work on the developer tools.
-marking the projects that are necessary to work on CTS.
There's also a possibility that repo will eventually know to
automatically ignore host-specific projects.
Longer-term, we're investigating the possibility of not downloading
the entire source history for projects where it's both large and
unnecessary.
I'm open to feedback and suggestions. Please let me know whether
that's useful, whether that works, which of the future directions
would be useful... and which future features I've forgotten that'd
make life easier.
Thanks,
JBQ
--
Jean-Baptiste M. "JBQ" Queru
Technical Lead, Android Open Source Project, Google.
Click to expand...
Click to collapse

That would be wonderful, especially for people with bad connections or small SSDs. :good:

I'm going to experiment with the current groups and see if they yield a reasonable savings. It may just be a matter of a how-to on the wiki.

would be awesome for me

update:
Code:
repo init -u https://github.com/omnirom/android.git -b android-4.3 -g default,-darwin,-device,-x86,-mips
gave me a .repo folder of 6.1GB and build works fine
what's the size without those -g switches?

i did the same with AOKP recently
if you want to have a look
http://gerrit.aokp.co/12009
http://gerrit.aokp.co/12146
http://gerrit.aokp.co/12156
http://gerrit.aokp.co/12642
http://gerrit.aokp.co/12749

Porting AOSP from source

ok, i'm trying to port and boot the AOSP source from google for 4.1.2 JB x86, first of all, i follow the next guide to build my own compiling machine http://forum.xda-developers.com/showthread.php?t=2762390 but i download in the step 12 the repo of google AOSP (repo init -u https://android.googlesource.com/platform/manifest -b android-4.1.2_r2.1 & repo sync)
Start the enviroment with: . build/envsetup.sh
and download download the source from motorola to get some propertary files http://sourceforge.net/projects/razr-i.motorola/files/LATAM/9.8.2I-50_SML-29/
now, the git have some instructions like you see in the README file inside the source, this say:
1. Create a workspace containing "vanilla" JB release from Google.
Done
Click to expand...
Click to collapse
ou may need to apply the following change in build repo to prevent the build from aborting when unexpected user tag is found on some modules:
[SOURCE] diff --git a/core/base_rules.mk b/core/base_rules.mk
index 3c11673..ecf611d 100644
--- a/core/base_rules.mk
+++ b/core/base_rules.mk
@@ -99,7 +99,7 @@ ifneq ($(filter $(LOCAL_MODULE_TAGS),user),)
$(warning * PRODUCT_PACKAGES section of)
$(warning * build/target/product/core.mk)
$(warning * )
- $(error user tag detected on new module - user tags are only supported on legacy modules)
+ $(warning user tag detected on new module - user tags are only supported on legacy modules)
endif
endif [/SOURCE]
i'm trying to do this step, but nothings seems happen...
The second step says that all we need is overlaying the Motorola repos on top of the AOSP repos, but in the Terminal i don't know some commands ('cause always i work on Windows ).
i need just a little help in here, i'm tryin to compare both sources, but in windows i've a tool called WINMERGE, in linux i don't know if we have something like that. I don't wanna overlay the repos, i want to compare the files and re-write the AOSP source with some parts of the motosource and get AOSP software with motorola hardware working.
thks to all, sorry for my bad english, i don't use translator

I always used meld. Meld is an 2to3 way comparing tool, that compares folders (date), files (versions) and text. It is almost like winmerge, just a little bit different. U can look it up in the app store of whatever ubuntu/linux version you have.
As for the defferences between aosp and moto. There are a number of differences. The most can be located in the system/core where moto has changed the behavior of how init works and some x86 implementations (especially pixelflinger). The next BIG thing is the bionic (libc). It has many x86 implementations and i am not sure if u can overlay them without trouble into aosp source.
Good luck!

Hazou said:
I always used meld. Meld is an 2to3 way comparing tool, that compares folders (date), files (versions) and text. It is almost like winmerge, just a little bit different. U can look it up in the app store of whatever ubuntu/linux version you have.
Click to expand...
Click to collapse
yeah, i'm using meld, it's amazig 'cause i can copy the files from one to another place, by the way, i'm using Ubuntu 14.04, with JVM 1.70 but 've some errors in the moment to build ...
As for the defferences between aosp and moto. There are a number of differences. The most can be located in the system/core where moto has changed the behavior of how init works and some x86 implementations (especially pixelflinger). The next BIG thing is the bionic (libc). It has many x86 implementations and i am not sure if u can overlay them without trouble into aosp source.
Good luck!
Click to expand...
Click to collapse
yeah, i see the both codes and check the changes, in some lines the works of moto it's amazing, but whe need more dev's to check all the changes to implement for porting ROMS
Lenovo has recently provided a software update which upgrades Android to version 4.3 for the k900, so i'm going to download the repo AOSP from google and later try to port 4.3

CM12 - building, optimising, fixing, having fun

Hi all o/
To celebrate two weeks of my successful CM12 building and hacking, I'm starting this thread. Its purpose is to discuss general CM12 building steps for beginners like myself, bugs and fixes, applying @JustArchi's optimisation flags, solving the resulting build failures.... and all the other CM12/S4Mini-related questions that don't belong to F4k's [ROM] thread but end up there (I was guilty of that).
First of all, my thanks go to:
@arco68 for making it possible to build ROMs for our S4mini
CyanogenMod team for the ROM itself
@F4k for his kernel and all the other excellent contributions to this forum
@JustArchi for finding what he found
In this first post I will outline the steps needed to build a vanilla unofficial CM12 for serranoltexx. serranoltexx is the only device I have so this is what I'll introduce. I suspect building serrano3gxx is just as simple (just replace the device name in all the relevant steps). I don't know what to do to build for i9192, if you do please contribute
Building your own CM12 ROM
Main article: http://wiki.cyanogenmod.org/w/Build_for_serranoltexx
The article above tells you how to build CM11, but CM12 builds just as well with minor modifications I'll outline here. To follow those steps you need a Linux installation. I will write how you can make an example Lubuntu-based virtual machine on your Windows box in a post below.
Modifications to the build steps:
"Install the SDK" -- you can skip that, because in the end we will not use any SDK tools.
"Install the Build Packages" - replace jdk6 with jdk7 everywhere, as Java 7 is needed to build Lollipop.
"Create the directories" - I will assume you've followed those steps and everything is under ~/android/system/
"Initialize the CyanogenMod source repository" replace "cm-11.0" with "cm-12.0" of course
"Extract proprietary blobs" we will do this completely differently. If you try to use extract-files.sh, the script will fail, and when I finally fixed the script my camera didn't work...
So, do this instead (credit to @F4k and @kyrillos13 for answering my question on page 90 of F4k's ROM thread)
* Go to https://github.com/TheMuppets/proprietary_vendor_samsung
* Switch branch to cm-12.0
* Use the "Download ZIP" button to get the copy of the entire thing. The zip is big (500 MB? ish) and 95% of it useless for us, so if you're trying to save some bandwidth you can try to do this trick to get only the "serrano-common" folder. If you do, make a post here with exact steps for others
* Copy the "serrano-common" folder to ~/android/system/vendor/samsung/ (to clarify, final directory structure should include ~/android/system/vendor/samsung/serrano-common/proprietary/app/ folder among others)
"Turn on caching to speed up build" - sounds like a good idea but we're going to be playing with compiler options, which diminishes its usefulness. It also uses a lot of disk space. Only follow it if you want your daily increments to build fast, and you don't expect to be doing global changes such as optimisation flag changes often. I didn't do this step.
This concludes my first post in this thread. I personally have never had problems with building after this part (except when I had not enough space or memory) and the resulting vanilla builds always worked for me fine. Feel encouraged!
Next post: some tricks and useful commands

A random selection of interesting things:
What recovery is good for applying my builds
Well they're all good, and they all work I bet. What I use is Phil's Touch and I'm on version 6.48.4 and it's worked perfectly.
How do I dirty flash my build on top of another CM12 build
I keep doing that since early F4k's builds and have no problems (yet!!). The trick is to only keep /data, while wiping everything else:
* Copy your newly build .zip file to your sdcard (you'll want to have a large enough sd card, I think)
* (if you want to) copy F4k's kernel and/or gapps too.
* Reboot your phone, go to recovery
* Backup your current phone. Seriously, never miss that step.
* Format /system (in Phil's Touch that's under "mounts and storage")
* Format /cache (as above)
* Select "install zip from sd card" and choose your ROM
* (if you want to) repeat "install zip from sd card" for F4k's kernel and/or gapps.
* Reboot your phone. It will take ~5 minutes or so for ART to re-compile all your apps
Soo my build didn't work. Wat do??
* Reboot to Recovery
* What I do is another backup. This gives me a nice archive containing my broken build, which I can later investigate
* Use recovery to restore the backup you've made before applying your build
* Reboot. You're back on a build that worked. Phew~
* (if you want to investigate) copy both backups (one that works and one that doesn't) to your PC. Uncompress the contents of /system for both, see if they obviously differ (such as one having binary blobs and one not lol).
Use F4k's kernel if you want to
Up to you, but here it is: https://s.basketbuild.com/devs/F4k/kernel_f4k-lp
I use it and as a result, I don't bother to optimise/improve CM12 kernel. I also don't care if I ever mis-compile CM12 kernel (not that it ever happens).
Gapps location
I use "mini" from here: https://s.basketbuild.com/devs/TKruzze/Android 5.0.1 GApps and all I can say is that it worked for me so far.
I made some changes and I forgot what I did
Command "repo status" will give you a list of all the files you've modified across all the git repositories.
I made some changes to a file and I forgot how it looked before
Go to that file's directory (or at least its git repository, but it's somewhat hard to figure out what is the repository structure in your workspace) and issue "git diff" command. It will produce a diff file with all your changes.
I made some changes to a file and I want to undo that
Go to that file's directory and issue "git checkout [filename]" command. It will drop your changes and replace the file with original.
My build finished and I want to make a new, fresh, one
You want to say "make clean" before you do "brunch serranoltexx" again.
Coming up: Basic JustArchi-inspired optimisations

Main article: http://forum.xda-developers.com/showthread.php?t=2754997
In the mid of 2014, @JustArchi recognised that all of Android has always been built with -Os option - meaning that the binaries are optimised for small size and not for execution speed. -Os is sometimes necessary (as it was on very early Android devices), but the "usual" build optimisation has always been -O2 meaning optimise for speed. Or -O3, which runs even more optimisations for speed (which might or might not help relative to O2 and will always make compilation slower).
Applying those optimisations has never been easier, because Lollipop is already built with GCC 4.8 (which was very highly recommended, but not in default toolchain, before). So all we need to do is activate -O3 by modifying some makefiles.
Does it do anything
In 0xbenchmark, several graphics-related tests (draw-arc, draw-circle) are up to six times faster. Does it matter? Dunno! But it's fun to see such a thing anyway!
What is THE most important file to modify?
Here: ~/android/system/build/core/combo/TARGET_linux-arm.mk
Line 70 defines "TARGET_arm_CFLAGS", this is the base compiler flags for *kernel* and starts with -O2. You can change that -O2 to -O3 if you want, but if you use F4k's kernel then it will do nothing in practice.
Line 77 defines TARGET_thumb_CFLAGS, this is the base compiler flags for android binaries. It clearly has -Os staring you in the face. Aha!! Change that to -O3 (or -O2) and you've just applied 90% of all compiler optimisations you can make. Build again. Your zip will be larger, this means it worked.
So I did that and it didn't finish building
Heh you're right, I lied. Unfortunately GCC is not as perfect as we'd wish and it will produce new errors or warnings with -O3 flag. Some of them make sense, some baffle me... Here's a list of what I had to change:
Error building android/system/frameworks//media/libstagefright/codecs/amrwbenc/src/isp_az.c, compiler detects array index out of bounds
It doesn't make any sense if you ask me (and I stared at the code a lot). There are two arrays f1 and f2. f1 has size [NC16k + 1] and f2 has size [NC16k], and if f1 is big enough then f2 should be big enough, but GCC disagrees.
For an off chance that GCC is right, I made f2 bigger [NC16k + 1]. Since nobody does sizeof(f2) it causes no change in logic, it marely allocates one extra (unused) word on stack. Made GCC happy.
[edit] this fix is unnecessary on gcc 4.8.5; see "Using SaberMod toolchain to build your CM12" on page 3 for how to use updated gcc[/edit]
Error building android/system/frameworks/av/media/libstagefright/codecs/m4v_h263/dec/src/deringing_[chroma|luma].cpp, cryptic "assuming when assuming" message
Another weird one. It *seems* to me that GCC unrolled a loop, and then looked at the unrolled loop index condition and concluded it's dumb after the unrolling, and complains. Modify:
android/system/frameworks/media/libstagefright/codecs/m4v_h263/dec/Android.mk
Find line: Local_CFLAGS += -Werror
Replace with: Local_CFLAGS += -Werror -Wno-error=strict-overflow
Error linking libhwcomposer, symbols "configRotator", "configMdp" and "updateSource" not found
Those three functions are defined with |inline| in the cpp files, while a compiler option tells gcc that inline implies static (dunno why it works with -Os, it really should never work). Open:
~/android/system/hardware/qcom/display-caf/msm8960/libhwcomposer/hwc_utils.cpp
Line 1238, remove "inline"
Line 1309, remove "inline"
Line 1335, remove "inline"
That is all, should build now!
Anything else uses -Os?
Yes, there's a bunch of Android.mk files that locally override the -O3 flag we just set with -Os (or -O2). You can make a global search, but here's a list of some important ones:
* every makefile under external/chromium_org/. This is the built-in web browser and unfortunately every single makefile does the override, and there's over9000 of them. If you want to change them all, you probably want to write a script of some sort. If you do, share one here lol.
* third_party/android_crazy_linker/src/Android.mk, adds -Os to LOCAL_CFLAGS. I do not know what crazy linker is, but if you want that to be bigger and faster, change that to -O3.
* third_party/zlib/zlib.target.linux-arm.mk, adds -Os to MY_CFLAGS_Release. Zlib sounds like something that should be fast, change that to -O3.
* modules/audio_processing/ lots of .mk files use -Os. How weird. You're only interested in *.target.linux-arm.mk, other targets do not apply to us.
* external/... some of the Android.mk files there use -Os. Some seem to matter.
Phew ~ next up: some more interesting optimisations that worked for me.

Compile for cortex-a15 target
The CPU in our S4mini is called Krait. It's neither Cortex-A9 nor Cortex-A15, but it's supposed to be similar to A15. However, the CM12 build system does not have an appropriate entry for Krait and defaults to generic A7+Neon, a choice that is not VERY bad but presumably not optimal either.
Go to file: ~/android/system/build/core/combo/arch/arm/armv7-a-neon.mk
Find the line that detects a15-compatible architectures (cortex-a15 and denver):
ifneq (,$(filter cortex-a15 denver,$(TARGET_$(combo_2nd_arch_prefix)CPU_VARIANT)))
add krait to the list:
ifneq (,$(filter krait cortex-a15 denver,$(TARGET_$(combo_2nd_arch_prefix)CPU_VARIANT)))
Activate neon vector extensions
[edit] see "Activate neon vector extensions, for real this time" on page 3 for a working, but hacky, solution[/edit]
Activate linker optimisations
In the in file: build/core/combo/select.mk there's room for some linker parameters.
Find the line that says:
$(combo_var_prefix)GLOBAL_LDFLAGS :=
and change it to:
$(combo_var_prefix)GLOBAL_LDFLAGS := -Wl,-O1
(that's: dash whiskey lima comma dash oscar one, no spaces, in case it's not readable)
I do not know what kind of optimisations linker makes, but this parameter asks it to make them.

Thanks a lot for this helpful and informative how-to. This is really appreciated if one likes to build the rom on his own.
Regards!

where can i download YOUR build of cm12?

well done!

This is a great write up. Anybody contributing for necessary mods required for duos will value add

I'm glad you guys like it I'll post some more tomorrow.
Howdareme said:
where can i download YOUR build of cm12?
Click to expand...
Click to collapse
Mine? I don't upload them anywhere because I don't see much point, making a near-identical copy of F4k's rom. Plus I am very lazy ;ppp
Now, to say something useful: if you're building any time soon, you might want to include this patch: http://review.cyanogenmod.org/#/c/82572/
It seems like there's a serious resource leak any time you switch your screen off.

Thanks for sharing this wonderful information!
sysKin said:
* Go to https://github.com/TheMuppets/proprietary_vendor_samsung
* Switch branch to cm-12.0
* Use the "Download ZIP" button to get the copy of the entire thing.
Click to expand...
Click to collapse
You might wanna consider adding that repo to a local manifest instead. See also @k2wls excellent guide: How to make your own CM-11.0 for your S4 mini

you can save the 500mb download by just adding this to .repo/local_manifests/roomservice.xml
Code:
<project name="TheMuppets/proprietary_vendor_samsung" path="vendor/samsung" remote="github" />
although perhaps we should be using arco's repo instead of the muppets?
https://github.com/arco/proprietary_vendor_samsung
also we should make a list of recommend patches from gerrit.
arco doesn't seem to be doing anything s4mini-specific at the moment, tonnes of work on bluetooth it seems:
http://review.cyanogenmod.org/#/q/owner:"Arne+Coucheron"+branch:"cm-12.0",n,z

sej7278 said:
you can save the 500mb download by just adding this to .repo/local_manifests/roomservice.xml
Code:
<project name="TheMuppets/proprietary_vendor_samsung" path="vendor/samsung" remote="github" />
although perhaps we should be using arco's repo instead of the muppets?
https://github.com/arco/proprietary_vendor_samsung
Click to expand...
Click to collapse
Wooo thanks, this is exactly the kind of knowledge I'm hoping we can put in one place, and I'm a noob when it comes to android build system (and |repo| script).
also we should make a list of recommend patches from gerrit.
Click to expand...
Click to collapse
Yup!

sysKin said:
Wooo thanks, this is exactly the kind of knowledge I'm hoping we can put in one place, and I'm a noob when it comes to android build system (and |repo| script).
Click to expand...
Click to collapse
well it won't actually save you a 500mb download, it'll just download it using repo, but at least it'll keep it up-to-date this way (as i recall there is a way to just checkout the directories you want, but i can't remember it, think you have to list every directory you don't want and remove it).
you can also add revision="cm-12.0" to the end of the tag, but cm-12.0 is the default now anyway.
i'd say USE_CCACHE=1 is worth doing, unless you're making major changes for every build, it defaults to only using 1Gb these days.
also if like me you've already checked out the cm-11.0 branch, you can switch to cm12 using:
Code:
repo init -b cm-12.0
repo sync -j16

built ok after a second repo sync (think i was in the middle of a merge window) and it turns out you don't need to get the prebuilts anymore, the terminal app is part of the source now.
oh and the screen off memory leak patch has been merged now.
it did take my 3.2ghz core-i5 with ccache on an ssd and 12gb ram about 2.5 hours to build, so a lot longer than cm7/9/10 (30-45mins) and a bit longer than cm11 (1.5-2 hours)
edit: actually a warm ccache only saved 5-10mins it seems, much more java than c/c++ in android these days i guess.

stop "settings > device > buttons" from crashing: http://review.cyanogenmod.org/#/c/83030/ (merged)
still looking for how to:
1. enable editting quick settings tiles
2. unmount usb mass storage,
3. take a screenshot from reboot menu / edit the reboot menu
4. edit the lockscreen settings

For those of us suffering from network-derived timezone resetting to GMT+0 (not a fun thing to happen overnight when you need your alarm clock!), there is this possible solution:
http://review.cyanogenmod.org/#/c/83219/

Love this thread.......
Thanks @sysKin., have you try diffrenent toolchain ?

happyta5 said:
have you try diffrenent toolchain ?
Click to expand...
Click to collapse
Not yet, not on this build. I did use a different toolchain when I compiled CM 10.2 but without any knowledge about how repo works it was just one huge mess. Many guides here only deepened my misunderstandings by showing me how to replace kernel toolchain (ie what builds the kernel) saying nothing about rest-of-android toolchain (and I don't even remember some details of that anymore...).
Also, I never managed to successfully compile CM 10.2 with contemporary GCC 4.9 - too many weird internal compiler errors and other strangeness. Do you have any information about successes with current tools? There wouldn't be much point using different toolchains if GCC/clang/etc remain the same (well, GCC 4.8.4 was released on 19th of December, might be worth trying).

With some pointers from this thread, I'm able to build CM12 using ArchiDroid linaro 4.8 and 4.9 ToolChain with -O3 Optimized. CM seems run faster. I'm using @F4k kernel for the moment since I like the undervolt alot. May be I'll try SaberMod ToolChain later .....
Cheers ...

happyta5 said:
With some pointers from this thread, I'm able to build CM12 using ArchiDroid linaro 4.8 and 4.9 ToolChain with -O3 Optimized. CM seems run faster.
Click to expand...
Click to collapse
Could you share more about what you did? In particular, did you change the "android-eabi" toolchain or the "arm-eabi" toolchain?
The only instructions I've seen which explain how to use linaro toolchain refer to the "android-eabi" one, and if my understanding is correct, that's used only for building the kernel...