[GUIDE + HELP]Rom Making, Stock and Compiled, With Emphasis on Moto MSM8960

skeevydude · Jun 8, 2014

Please don't quote this post.
Nobody likes an OPs Wall of Text in the middle of page 3.

One of the best things about Android is the ability to make roms, whether it be from source or stock. A lot of guides go into details about how to get your Linux system set up and running, this one won't. I expect that you already have a running Linux system and have followed one of the many guides around to have all the required software installed.

If you don't have Linux installed, preferably Debian or Debian based (I use Debian Testing) and set up for compiling an Android rom, stop reading this, install Linux, and follow one of the Android guides below Everything in this guide requires Linux, I might add in some Windows tools in the future. Ask for Linux install help in what ever disto you choose's forums, not here.

Required Tools
Attached is a zip containing a lot of tools that I use, and sadly, I've acquired them at different times over the years and I don't remember where I got them all at, so giving proper credit isn't possible. If you developed a tool I used here, please know that you have my thanks and gratitude, and if you let me know, I'll remove it or add proper credit.

Some of the included tools I won't even discuss because they're not relevant to this platfore (like sbf_flash...Linux tool for flashing old school moto firmware to the Bravo, Defy, and other omap3 based moto phones), but they're included because I've added all the things I have installed in my local Android $PATH. They are only 1.9mb extracted, so it's not like they take up a lot of space...anyways...

Just extract all the tools into $HOME/bin, or any other preferred location in your $PATH
Ensure they have the proper permissions; run "chmod 755 +x $HOME/bin/*", change $HOME/bin to where ever you installed the tools at
log out
log back in

and you're done with the tool installation part (there's also a source /blah/blah command that can be used, but log out and log in is universal). I keep all my sources and tools on their own hard drive, located on /android, so nothing is lost if I ever change Linux distros -- All I have to do is add /android/bin to my $PATH and I'm good to go (once I've copy/pasted the commands in one of the above guides

)

Some Linux terms/commands

$HOME -- The current users home directory. I'm logged in as skeevy420, so my $HOME is /home/skeevy420, $HOME/bin is /home/skeevy420/bin
$PATH -- all the directoies your system will look for executable files....Google it or check Arch Linux's guides, they're great
su -- you should really know this one....shame on you if you don't
sudo -i -- similar to sudo, only it opens an interactive sudo shell where every command is done as sudo

Converting a Fastboot into a flashable zip
This is pretty straight forward and only requires dumpperms.pl and simg2img.py (in the zip you should have already installed)
To make things easier all the terminal commands are colored blue

First Step -- Converting system.img into a mountable format

Download and Extract a fastboot zip file
Open a terminal in the folder you extracted the zip to
run "simg2img.py ./system.img ./system.img.raw" (it's system.img.ext4, not system.img, if you're converting an ICS fastboot image)

Second Step -- Mount the converted image

Obtain a root shell, use "sudo -i" or "su" depending on how your system handles regular users accessing superuser privileges ***$PATH HINT***
Every single command in every step done after this will be as su/sudo -i
cd back to the folder with the converted image, if necessary
mkdir -p /mnt/tmp/zip/system
mount -o loop system.img.raw /mnt/tmp/zip/system

Thrid Step -- Get file permissions

dumpperms.pl /mnt/tmp/zip/system > /mnt/tmp/perms

Fourth Step -- Add in META-INF (this is from Gummy Rom June 02, 2014)

Download the attached META-INF.zip
unzip META-INF.zip -d /mnt/tmp/zip

Fifth Step -- Modify Updater Script

Open /mnt/tmp/perms with a text editor
Select everything and copy it
Open /mnt/tmp/zip/META-INF/com/google/android/updater-script with a text editor
Select the marked line, highlighted blue in the template below
Paste in the permissions
Save it as /mnt/tmp/zip/META-INF/com/google/android/updater-script

Sixth Step -- Add in kernel/boot.img

cd into extracted fastboot folder if necessary
cp boot.img /mnt/tmp/zip

Seventh Step -- Pack it all up

zip -r /mnt/tmp/zip/rom.zip /mnt/tmp/zip

Eight Step -- Flash it

You should really know how to get a rom on your phone at this point in the game....
If you don't, we're all gonna laugh at you.

Updater Script Template

Code:

assert(getprop("ro.product.device") == "moto_msm8960" || getprop("ro.build.product") == "moto_msm8960" || 
       getprop("ro.product.device") == "xt901" || getprop("ro.build.product") == "xt901" || 
       getprop("ro.product.device") == "solstice" || getprop("ro.build.product") == "solstice" || 
       getprop("ro.product.device") == "xt905" || getprop("ro.build.product") == "xt905" || 
       getprop("ro.product.device") == "smq_u" || getprop("ro.build.product") == "smq_u" || 
       getprop("ro.product.device") == "scorpion_mini_u" || getprop("ro.build.product") == "scorpion_mini_u" || 
       getprop("ro.product.device") == "xt907" || getprop("ro.build.product") == "xt907" || 
       getprop("ro.product.device") == "scorpion_mini" || getprop("ro.build.product") == "scorpion_mini" || 
       getprop("ro.product.device") == "xt925" || getprop("ro.build.product") == "xt925" || 
       getprop("ro.product.device") == "vanquish_u" || getprop("ro.build.product") == "vanquish_u" || 
       getprop("ro.product.device") == "xt926" || getprop("ro.build.product") == "xt926" || 
       getprop("ro.product.device") == "vanquish" || getprop("ro.build.product") == "vanquish" || 
       getprop("ro.product.device") == "mb886" || getprop("ro.build.product") == "mb886" || 
       getprop("ro.product.device") == "qinara" || getprop("ro.build.product") == "qinara" || 
       getprop("ro.product.device") == "xt897" || getprop("ro.build.product") == "xt897" || 
       getprop("ro.product.device") == "asanti" || getprop("ro.build.product") == "asanti" || 
       getprop("ro.product.device") == "xt897c" || getprop("ro.build.product") == "xt897c" || 
       getprop("ro.product.device") == "asanti_c" || getprop("ro.build.product") == "asanti_c" || abort("This package is for \"moto_msm8960,xt901,solstice,xt905,smq_u,scorpion_mini_u,xt907,scorpion_mini,xt925,vanquish_u,xt926,vanquish,mb886,qinara,xt897,asanti,xt897c,asanti_c\" devices; this is a \"" + getprop("ro.product.device") + "\"."););
show_progress(0.500000, 0);
format("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "0", "/system");
mount("ext4", "EMMC", "/dev/block/platform/msm_sdcc.1/by-name/system", "/system");
show_progress(0.500000, 40);
ui_print("{x}...Installing System...");
ui_print("");
package_extract_dir("system", "/system");
ui_print("{x}...Creating Symlinks...");
ui_print("");
ui_print("{x}...Setting Permissions...");
ui_print("");
[B][COLOR="MediumTurquoise"]HIGHLIGHT THIS LINE AND PASTE YOUR PERMISSIONS HERE[/COLOR][/B]
show_progress(0.200000, 0);
show_progress(0.200000, 10);
ui_print("{x}...Flashing Kernel...");
ui_print("");
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
show_progress(0.100000, 0);
ui_print("{x}...Installation Complete!");
ui_print("");

Amended Hints

***$PATH HINT*** Make sure root/sudo has access to the primary users $HOME/bin or where every you installed the tools to, It's that or you'll have to figure out your own workarounds and do a lot of jumping between user and su.

THIS IS A WIP, I'LL BE ADDING MORE THINGS IN THE FUTURE. I'M HUNGRY AND I WANT A BREAK FROM TYPING

skeevydude · Jun 8, 2014

Please don't quote this post either. Thank you.

Introduction
One of the reasons people download rom sources is to just compile them, but the nostalgia from that wears of pretty fast and you're left thinking -- What Next??? There's plenty of things that can be done, you can add in things like Archidroid's Optimizations, take an AOKP feature and port it to Gummy, you could optimize the build with Linaro or a different GCC version, you might want to try your hand at compiling an optimized toolchain to optimize the rom's compile even further, you could do bug fixes and submit them to CM or your rom of choice's developer..the possibilities are endless, but where to start? How to start?

The example below is based on adding Archidroid's Optimizations to PAC and will be on my GitHub page for anyone to see and use. I'm using Archidroid's Optimizations because they're well documented, they don't cleanly pick with PAC, and they're a neat thing that can be done to nearly any rom -- all that makes it a good candidate for a basic first source based mod tutorial. I'll also be adding in Arrrghhh's kernel because why not.

First thing you need to do is get a Github account.
You're gonna want this. It's free and it gives you a place push your modified sources to; so when you sync, you get your changes. It also serves as a good backup for the projects you're working on. I'll go into remotes and pushing when the time comes.

Now, Archidroid and PAC...where to start?
I'm gonna assume that you've already synced PAC's sources as well as initialized a PAC build to create roomservice.xml and sync the device sources. If you haven't synced yet, but you already have, say, CM or AOSP synced, you can add --reference=/path/to/your/CM/sources and your PAC sync will use your local CM files if they're the same as what PAC needs. --reference is one of my favorite repo commands.

Well, you start by forking all the projects PAC has that are modified by Archidroid's Optimizations, which are android_build, android_art, & for PAC, android_vendor_pac to incorporate it properly into PAC's build script. See, PAC's build script already allows defining the GCC O Level which is a big part of what Archidroid's Optimizations target, but if done right, they can be integrated in a way that allows defining Os, O2, O3, Oa (O Archidroid), and Of (his Ofast commit that he's testing). I might even get around give PAC's build script a way to define GCC version and Google or Linaro GCC...

You're gonna want to open PAC's manifest, located here, and determine from where you fork the 3 projects. You'll see that android_art is from CM, so fork it from Cyanogenmod. To Fork, sign in to Github, go to where the project is located, and click the fork button in the upper right hand corner...simple. android_build and android_vendor_pac are PAC repos, so fork them from PAC.

Thought you were done forking? Nope, you have one more to fork IF you plan on submitting this to PAC's Gerrit like I plan on doing. That fork is PAC-man/pacman because Archidroids GCC repos and (a forked) android_art will have to be added to PAC's manifest.

I'm also going to go into detail and write the guide from the perspective view of using a local manifest, removals, and whatnot -- IMHO, Forking and updating manifests is better if you plan on contributing to a project/submit for Gerrit review, local manifests are better for personal projects, testing, and preparing to do a proper, correct submission to Gerrit review.

Create Local Manifests
Probably the easiest part of AO is adding GCC 4.8. This is done by simply making a file named (pretty much anything except roomservice.xml) linaro.xml. It'll be a standard repo xml file that looks like this

Code:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- Generic Github remote -->
  <remote  name="github"
           fetch="https://github.com" />

  <!-- LINARO TOOLCHAIN -->
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" />
</manifest>

The only problem with that is, for us, Linaro GCC 4.8 built roms seem a bit more error prone, but we can't just add in Linaro GCC 4.7 like above because we'll get sync errors since PAC already has Google GCC 4.7...so we'll add some project removal lines in the xml...sources in local manifests take precedent.

Code:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- AOSP remote -->
  <remote  name="aosp"
           fetch="https://android.googlesource.com" />

  <!-- Generic Github remote -->
  <remote  name="github"
           fetch="https://github.com" />

  <!-- Removals -->
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" />

  <!-- ADDS -->
  <!-- LINARO TOOLCHAIN -->
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" remote="github" revision="4.7-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" />
  <!-- Google 4.8 TOOLCHAIN -->
  <!-- Uncomment the two lines, comment out both Linaro 4.8s, then repo sync to change toolchains -->
  <!-- <project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="aosp" revision="master" />
  <project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="aosp" revision="master" /> -->
</manifest>

NOTE: The remote lines aren't needed here. They're already in PAC's manifest and I only included them above to get you thinking about your remotes when you're setting up a manifest. If you wanna compile PAC following this guides instructions, before you click save after you copy and paste the above xml, delete lines 3 to 11, making the new line the be the Removals line. You should also check the remotes before you use this with other roms, because this is pretty rom independent; the removal lines may not be necessary on some roms.

Now that we have an xml file that handles our toolchain, I'll break it down and explain where the different things come from.

The first thing you'll notice is the remotes. In the xml files, the remote is the website or location you're getting your sources from. They can also be used to use less characters in the xml -- I could have added a remote named Archi with fetch="https://github.com/JustArchi", then I'd change the remote to Archi and the name to just "Linaro". While the 4 repos here isn't that big of a deal, imagine having 300 name="CyanogenMod/blah" projects, name="blah" remote="cm" seems like a better idea doesn't it?.

Below the remotes are the removals, and they're determined by the name= part of a project line of your main manifest.xml or roomservice.xml. Adding in more removals is simply copy/pasting the name= line of a project and having it formatted like you see above.

The Adds....those are just your standard lines of a manifest containing the stuff you want to add to your project or use now that the crap you don't want to use is removed.

Side Project -- Adding in a Arrrghhh's Custom Kernel to the Local Manifest
This part here is generic and geared towards CyanogenMod. I won't be using this with the rest of the Archidroid tutorial.
Simple two line mod

Code:

  <remove-project name="CyanogenMod/android_kernel_motorola_msm8960-common" />
  <project name="arrrghhh/android_kernel_motorola_msm8960-common" path="kernel/motorola/msm8960-common" remote="github" revision="cm-11.0_mod" />

Adding Arrrghhh's Kernel to PAC Vendor
While the Dev Team's kernel is nice and stable, it just doesn't have all that many tweaks. That's where Arrrghh's kernel comes into play. It's the Dev Team's kernel with both higher and lower frequencies to use, more governors and schedulers, adjustable voltage table, and more.

Before I go on, there are two programs I use that help with merge conflicts, and those are Meld and Git-Cola. I'll be using them below, but if you have a preferred way of dealing with merge conflicts, then by all means use that (I like SmartGit HG too). For most Debian/Ubuntu distros, they can be installed with the following terminal command.

Code:

[COLOR="Blue"]sudo apt-get install meld git-cola[/COLOR]

IMPORTANT: I'll be using my own personal repos and directories below. I'll try to point them out, but for general note, /android/pac is my sources' root directory and remotes created named skeevy are mine, you need to create them with a different name and have the URL set to your github account, not mine.

Now that that's out of the way, fire up the terminal and go to your sources root directory, for me it's cd /android/pac, and do a repo sync. Once the sources update, we start.

Code:

Go to vendor/pac -- [COLOR="Blue"]cd vendor/pac[/COLOR]
Add your remote -- [COLOR="blue"]git remote add [/COLOR][COLOR="SeaGreen"]skeevy [/COLOR][COLOR="Blue"]https://github.com/[/COLOR][COLOR="SeaGreen"]skeevy420[/COLOR][COLOR="Blue"]/android_vendor_pac.git[/COLOR]
fetch remotes -- [COLOR="Blue"]git fetch --all[/COLOR]  (or git fetch [I]name_of_remote[/I] to only fetch a single remote)
Add a new branch and switch to it -- [COLOR="Blue"]git checkout -b pac-4.4[/COLOR] [COLOR="green"]***BRANCH NOTE***[/COLOR]

Fire up your text editor, I use gedit, and use that to open up our pac device dependencies file

Code:

/android/pac/vendro/pac/dependencies/moto_msm8960.dependencies

Code:

[
    {
        "remote": "github",
        "account": "PAC-Motorola",
        "repository": "android_device_motorola_moto_msm8960",
        "target_path": "device/motorola/moto_msm8960",
        "revision": "cm-11.0"
    },
    {
        "remote": "github",
        "account": "CyanogenMod",
        "repository": "android_device_motorola_qcom-common",
        "target_path": "device/motorola/qcom-common",
        "revision": "cm-11.0"
    },
    {
        "remote": "github",
        "account": "CyanogenMod",
        "repository": "android_device_qcom_common",
        "target_path": "device/qcom/common",
        "revision": "cm-11.0"
    },
    {
        "remote": "github",
        "account": "CyanogenMod",
        "repository": "android_kernel_motorola_msm8960-common",
        "target_path": "kernel/motorola/msm8960-common",
        "revision": "cm-11.0"
    },
    {
        "remote": "github",
        "account": "Pinky-Inky-and-Clyde",
        "repository": "proprietary_vendor_motorola",
        "target_path": "vendor/motorola",
        "revision": "cm-11.0"
    }
]

And modify the kernel part so it looks like this

Code:

        "remote": "github",
        "account": "arrrghhh",
        "repository": "android_kernel_motorola_msm8960-common",
        "target_path": "kernel/motorola/msm8960-common",
        "revision": "cm-11.0_mod"

Save it. Gedit, by default, saves a backup file in the same directory as the file you saved, make sure you delete that file if it did. And back to the terminal.

Code:

Commit the change -- [COLOR="Blue"]git commit -a -m "Change moto_msm8960 kernel to arrrghhh's kernel"[/COLOR]
Push and set remote as upstream -- [COLOR="blue"]git push --set-upstream [/COLOR][COLOR="SeaGreen"]skeevy[/COLOR][COLOR="Blue"] pac-4.4[/COLOR]

Now that Arrrghhhs kernel has been added to PAC, we'll move on to adding Archidroid to android_art....just kidding, we gotta play with removals and local manifests again...remove PAC's vendor and use your forked one.

Code:

  <remove-project name="android_vendor_pac" />
  <project name="[COLOR="SeaGreen"]skeevy420[/COLOR]/android_vendor_pac" path="vendor/pac" remote="github" revision="pac-4.4" />

Android Art
Finally, actually doing something related to Archidroid's Optimizations. Yay.

JUST A TEMP SAVE. I'M STILL WORKING ON THIS
Art -- Remote
Art -- Branch
Art -- Pick
Art -- Push

Build -- Remote
Build -- Branch
Build -- Pick
Build -- Fix\Build Script Integration
Build -- Push

Vendor -- Almost same as above
Vendor -- Archidroid into Pac Build Script
Vendor -- Add Arrrghhh kernel

Pac Compile 0a
Pac Compile 0f
This part of the guide will take me 5 or 6 hours....but you'll get some cool builds out of it

Submitting to PAC's Gerrit if builds are successful, doesn't actually have to boot or work...I'll explain...

Wait a for anything above's upstream to be updated, and an update my forked stuff with master guide.

***BRANCH NOTE*** pac-4.4 (the branch name) can be whatever you want it to be, but if it's something you'll submit for a gerrit review, use the branch the project you're committing to is using. There's also using a temp branch then cherry-picking in the changes when your done...but we're not going into gerrit strategies here.

skeevydude · Jun 8, 2014

reserved for other things

skeevydude · Jun 8, 2014

and a third just in case

EDIT: Feel free to post rom tweaking and compile questions and advise while I'm finishing the guide up. There's quite a bit of content and I'd like to make sure it's correct and working before posting.

CWGSM3VO · Jun 9, 2014

So I've done some testing with the Linaro toolchain and the HD. General consensus (and source) seems to indicate the S4 Plus in the device is closer to the Cortex-A9 than the Cortex-A15 but has some extra goodies that "kind of make up for it".

Testing against both the A9 and A15 optimized toolchains, the A9 feels "better" but the A15 works just fine too. Main problem is the razrqcom source in CM11 defaults to A15 so there lies a problem. I will probably have to bite the bullet and compile my own optimized A9 toolchain with VFPv4 (vs VFPv3) and see how it turns out.

Either way, the performance benefit is clearly there. Benchmarks somewhat reflect it but "real world use" it shines vs non-optimized. Once I'm happy, I'll post my findings so others can try their hand at it.

EDIT: I'll make two builds available and update this post. Both are identical except for the toolchain + arch related opts applied. One is Cortex-A15 tuned and one is Cortex-A9 tuned. You decide from there. Keep in mind I'm still using the default GCC (4.7) with no special optimizations applied to it other than for ARM (under build/); everything else is stock and I'm not using my own toolchain yet.

Zeljko1234 · Jun 9, 2014

So great to follow this thread! Looking forward to test optimized build, especially with the new kernel.

Huge thanks!

skeevydude · Jun 10, 2014

CWGSM3VO said:
So I've done some testing with the Linaro toolchain and the HD. General consensus (and source) seems to indicate the S4 Plus in the device is closer to the Cortex-A9 than the Cortex-A15 but has some extra goodies that "kind of make up for it".

Testing against both the A9 and A15 optimized toolchains, the A9 feels "better" but the A15 works just fine too. Main problem is the razrqcom source in CM11 defaults to A15 so there lies a problem. I will probably have to bite the bullet and compile my own optimized A9 toolchain with VFPv4 (vs VFPv3) and see how it turns out.

Either way, the performance benefit is clearly there. Benchmarks somewhat reflect it but "real world use" it shines vs non-optimized. Once I'm happy, I'll post my findings so others can try their hand at it.

EDIT: I'll make two builds available and update this post. Both are identical except for the toolchain + arch related opts applied. One is Cortex-A15 tuned and one is Cortex-A9 tuned. You decide from there. Keep in mind I'm still using the default GCC (4.7) with no special optimizations applied to it other than for ARM (under build/); everything else is stock and I'm not using my own toolchain yet.

Did you ever manage to compile the toolchain with VFPv4?

And I never go by benchmarks other than real world performance in apps...like FPS in ProjectM or FPse...run the wrong IO scheduler during a benchmark and get a bad score, cheat and swap io schedulers during the read/write tests and have *****in scores...benchmarks are too easy to cheat, and due to caching, memory management, etc, lower numbers don't necessarily mean crappier performance

CWGSM3VO · Jun 10, 2014

skeevydude said:
Did you ever manage to compile the toolchain with VFPv4?

And I never go by benchmarks other than real world performance in apps...like FPS in ProjectM or FPse...run the wrong IO scheduler during a benchmark and get a bad score, cheat and swap io schedulers during the read/write tests and have *****in scores...benchmarks are too easy to cheat, and due to caching, memory management, etc, lower numbers don't necessarily mean crappier performance

No I haven't gone that far yet. It would only be applicable to Cortex-A9+VFPv4. One thing I've noticed running the A9 optimized build is that while it seems to perform almost as well (In most cases) as A15 optimized builds do but seems to run into some kind of I/O stall. I can mitigate it from changing to deadline (from ROW) but this isn't necessary in the A15 builds.

I did (earlier) a quick grok of the source tree for particular flags and seems armv7-a and A15 is the general assumption. I'm now since eating crow because the A9 build is running into intermittent stalls (I see it in the UI, response time is 0 for a split-second). Given the source assumptions and performance I've seen with the A15 builds, it makes sense for me to pursue that build. Unfortunately one performance gain to be had would be very time consuming because it's scattered throughout the tree would be to change the float abi to hard as the compatibility (at the sake of performance due to overhead) is preferable for something like CM11 versus a personal build.

For benchmarking, I've only been using Quadrant standard. Mainly because it gives me a chance to visually see the differences. Memory I/O scores are in the 11-12K range currently, much higher than I ever got with stock repo. I'm not quite happy with a few things and would like to reduce my footprint into the source. But I do have both an A9 and A15 test build ready, just need to upload them somewhere if anyone wants to play with them (I'll try to get this done soon, done!).

A9: http://www.filedropper.com/cm-11-20140609-unofficial-motomsm8960a9
A15: http://www.filedropper.com/cm-11-20140609-unofficial-motomsm8960-a15

Through work, I might be able to lay my hands on ARMcc and would like to play with that. Their opensource/free offerings of course don't include the compiler.

I think from here, it's worth exploring expanding this to beyond the toolchain.

EDIT: It should be worth noting these screenshots are based in Interactive/Deadline (stock) settings. Didn't bother going into airplane to "get that extra bit"

One is A9 and one is A15, guess which is which

Also, no -O's were hurt during the making of this project, everything is stock (-O2, very safe opts) compiler flag-wise except where A9/15+NEON are applicable.

skeevydude · Jun 10, 2014

CWGSM3VO said:
No I haven't gone that far yet. It would only be applicable to Cortex-A9+VFPv4. One thing I've noticed running the A9 optimized build is that while it seems to perform almost as well (In most cases) as A15 optimized builds do but seems to run into some kind of I/O stall. I can mitigate it from changing to deadline (from ROW) but this isn't necessary in the A15 builds.

I did (earlier) a quick grok of the source tree for particular flags and seems armv7-a and A15 is the general assumption. I'm now since eating crow because the A9 build is running into intermittent stalls (I see it in the UI, response time is 0 for a split-second). Given the source assumptions and performance I've seen with the A15 builds, it makes sense for me to pursue that build. Unfortunately one performance gain to be had would be very time consuming because it's scattered throughout the tree would be to change the float abi to hard as the compatibility (at the sake of performance due to overhead) is preferable for something like CM11 versus a personal build.

For benchmarking, I've only been using Quadrant standard. Mainly because it gives me a chance to visually see the differences. Memory I/O scores are in the 11-12K range currently, much higher than I ever got with stock repo. I'm not quite happy with a few things and would like to reduce my footprint into the source. But I do have both an A9 and A15 test build ready, just need to upload them somewhere if anyone wants to play with them (I'll try to get this done soon, done!).

A9: http://www.filedropper.com/cm-11-20140609-unofficial-motomsm8960a9
A15: http://www.filedropper.com/cm-11-20140609-unofficial-motomsm8960-a15

Through work, I might be able to lay my hands on ARMcc and would like to play with that. Their opensource/free offerings of course don't include the compiler.

I think from here, it's worth exploring expanding this to beyond the toolchain.

EDIT: It should be worth noting these screenshots are based in Interactive/Deadline (stock) settings. Didn't bother going into airplane to "get that extra bit" One is A9 and one is A15, guess which is which Also, no -O's were hurt during the making of this project, everything is stock (-O2, very safe opts) compiler flag-wise except where A9/15+NEON are applicable.

I'm gonna guess the 2nd one is A9 based on the IO readout.

All the optimizations are done, I just have to finish the guide with how I did it all. With the PAC build script in my repos, it's possible to choose between Os, O2, O3, Archidroid O3, and Archidroid Ofast when compiling PAC. Just add in my local manifest after the first, initial, sync completes, then sync again.

The build is using Google GCC 4.8 (and replaces Google GCC 4.7 with Archi/Linaro 4.7, though it's unused by default).

Based on what you posted, I'm gonna tweak android_build to use A15 for Krait over A9 which is currently in place. I'll have two builds posted tomorrow -- one build with Archi O3 and the other with Ofast, only no one will no which is which. Gonna do the A15, update my forks if needed, start the first of two builds without syncing, and call it a night. I'm tired, worked 10 hours today, got home, and I've been doing this, playing with my dogs, and getting things done around the house....I can't believe it's 10 past 11pm already :crying: Today went by way too fast.

local.xml

Code:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- REMOVALS -->
  <remove-project name="android_art" />
  <remove-project name="android_build" />
  <remove-project name="android_vendor_pac" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" />


  <!-- ADDS -->
  <!-- ARCHIDROID LINARO TOOLCHAINS -->
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" remote="github" revision="4.7-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />
  <!-- <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" /> -->

  <!-- Google 4.8 TOOLCHAIN -->
  <!-- Uncomment the two lines, comment out both Linaro 4.8s, then repo sync to change toolchains -->
  <project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="aosp" revision="master" />
  <project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="aosp" revision="master" />

  <!-- MY MODIFIEDS -->
  <project name="skeevy420/android_art" path="art" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_build" path="build" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_vendor_pac" path="vendor/pac" remote="github" revision="pac-4.4" />
</manifest>

EDIT: Kept getting weird build errors with Google GCC 4.8; switched to Archi 4.7; starting again; really calling it a night this time (if the build goes more than 10 minutes :cowboy:

)

EDIT2: I think I screwed up cherry-picking android_build (easy for cm, complicated for PAC).... or could also be a ccache error...Gonna figure it out tomorrow.

And you know you're tired when you do a change to android build, open the terminal, cd to vendor/pac, try to commit and push the change, multiple times over 15 minutes going wtf???, when you finally realize you're in the wrong directory....

CWGSM3VO · Jun 10, 2014

I've since updated my build to use Linaro 4.7.4 for the host compilation. Everything else is the same, see how it goes (letting it compile overnight). I'm definitely sticking with A15 over A9, I'll post more updates in the morning, wiped out

skeevydude · Jun 10, 2014

CWGSM3VO said:
I've since updated my build to use Linaro 4.7.4 for the host compilation. Everything else is the same, see how it goes (letting it compile overnight). I'm definitely sticking with A15 over A9, I'll post more updates in the morning, wiped out

According to this, we're really close to arm A12.

Redoing my android_build picks from last night. Hopefully not being exhausted will make a difference.

CWGSM3VO · Jun 10, 2014

skeevydude said:
According to this, we're really close to arm A12.

Redoing my android_build picks from last night. Hopefully not being exhausted will make a difference.

There are enough differences to make it hard to peg the Krait as an A9, A12 or A15

Curious to see how A12 turns out for you. Everything I've been able to find, it's more "like a" A9 than an A15.

skeevydude · Jun 10, 2014

CWGSM3VO said:
There are enough differences to make it hard to peg the Krait as an A9, A12 or A15 Curious to see how A12 turns out for you. Everything I've been able to find, it's more "like a" A9 than an A15.

I'm not testing A12...at least not right now...wasn't even able to get a standard O2 build to compile last night, getting cc1 errors with .o's

But on that chart, we're really close to 12, more-so than we are A9.
Just thought it curious.

Anyhoo, redid everything, might have missed a single endif last night that was causing my errors, we'll see.

I hope this works, I'd like to move on to finishing that part of the guide then getting a 3.4 kernel build of PAC going...not that I can run it, but some of ya'll can.

skeevydude · Jun 11, 2014

Figured out my build errors....-Werror....that cflag is annoying, but I didn't do the remove that flag fix, instead appended -Wno-error=unused-parameter to the parts failing, and so far the build seems to be running good.

Starting a second build with a different set of tweaks (may not finish, using Ofast...), when done, will start a third build with a different set of tweaks, and I'll upload all three when I'm done. There will not be a repo sync between builds so the only differences will be cflags, o level, and gcc.

Probably won't finish the 2nd post until tomorrow evening, until then, here is my local manifest if you want to compile PAC with Archidroids V2...I could probably update it to V3...reverted to V2 cause that worked flawlessly a week ago...it had the same build errors as V3...damn 4.4.3 update messing with me...

Code:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- REMOVALS -->
  <remove-project name="android_art" />
  <remove-project name="android_bootable_recovery" />
  <remove-project name="android_build" />
  <remove-project name="android_hardware_qcom_display-caf" />
  <remove-project name="android_system_vold" />
  <remove-project name="android_vendor_pac" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" />

  <!-- ADDS -->
  <!-- ARCHIDROID LINARO TOOLCHAINS -->
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" remote="github" revision="4.7-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" />

  <!-- Google 4.8 TOOLCHAIN -->
  <!-- Uncomment the two lines, comment out both Linaro 4.8s, then repo sync to change toolchains -->
  <!-- <project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="aosp" revision="master" />
  <project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="aosp" revision="master" /> -->

  <!-- MY MODIFIEDS -->
  <project name="skeevy420/android_art" path="art" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_bootable_recovery" path="bootable/recovery" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_build" path="build" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_hardware_qcom_display-caf" path="hardware/qcom/display-caf" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_system_vold" path="system/vold" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_vendor_pac" path="vendor/pac" remote="github" revision="pac-4.4" />

</manifest>

EDIT:
Build 2 complete, waiting on apk's to optimize then build 3 starts.

skeevydude · Jun 11, 2014

Two test builds uploaded, third one compiling, poll, links, and description in PAC thread.

EDIT: Third build available in Pac post 13 (same as the others)

That build marks 3 successful builds with various Archidroid & GCC options.

CWGSM3VO · Jun 11, 2014

So as I get more and more into this, I realize I might be missing something. Here's what I got so far:

- Linaro 4.7.4 host compiler under prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7 and this is verified by running prebuilts/gcc/linux-x86/arm/arm-androideabi-4.7/bin/arm-linux-androideabi-gcc --version which reports Linaro GCC 4.7-2014.04-1~dev 4.7.4 20140402 (prerelease)

- Linaro 4.7.4 toolchain under prebuilts/gcc/linux-x86/arm/arm-cortex_a15-linux-gnueabihf-linaro_4.7.4-2014.04 and build/envsetup.sh is hardcoded to use this path. GCC in there reports as arm-cortex_a15-linux-gnueabihf-gcc (crosstools-NG linaro 1.13.1+bzr2651 - Linaro GCC 2014.04 - Cortex-A15) 4.7.4 20140402 (prerelease)

Code:

case $ARCH in
  x86) ..
  arm) toolchaindir=arm/arm-cortex_a15-linux-gnueabihf-linaro_4.7.4-2014.04/bin
  ..

My local_manifests/gcc.xml contains:

Code:

<remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />
<project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />

But I've been reading about NDK and having problems locating the Linaro NDK r8e which I believe will give me a 4.7.x build. The NDK as I understand it is used to optimize APKs, etc. Whereas the toolchain/compiler does Kernel/Libs+ROM.

Is this correct? I'd like to make it Linaro all the way through in my builds. I noticed during a build yesterday that it was using the stock arm-4.7 compiler (as far as I could tell) and I think this is related to the NDK. I don't think I'm compiling everything with Linaro that I could be. I also noticed that S-Tools shows no Linaro tag in the kernel uname string/info.

sources:

https://wiki.linaro.org/Platform/Android/Toolchain
http://xdaforums.com/xperia-z/development/tutorial-compile-xperia-z-rom-linaro-t2330970

Anyone shed some light on this for me?

skeevydude · Jun 12, 2014

CWGSM3VO said:
So as I get more and more into this, I realize I might be missing something. Here's what I got so far:

- Linaro 4.7.4 host compiler under prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7 and this is verified by running prebuilts/gcc/linux-x86/arm/arm-androideabi-4.7/bin/arm-linux-androideabi-gcc --version which reports Linaro GCC 4.7-2014.04-1~dev 4.7.4 20140402 (prerelease)

- Linaro 4.7.4 toolchain under prebuilts/gcc/linux-x86/arm/arm-cortex_a15-linux-gnueabihf-linaro_4.7.4-2014.04 and build/envsetup.sh is hardcoded to use this path. GCC in there reports as arm-cortex_a15-linux-gnueabihf-gcc (crosstools-NG linaro 1.13.1+bzr2651 - Linaro GCC 2014.04 - Cortex-A15) 4.7.4 20140402 (prerelease)

Code:

case $ARCH in x86) .. arm) toolchaindir=arm/arm-cortex_a15-linux-gnueabihf-linaro_4.7.4-2014.04/bin ..

My local_manifests/gcc.xml contains:

Code:

<remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" /> <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />

But I've been reading about NDK and having problems locating the Linaro NDK r8e which I believe will give me a 4.7.x build. The NDK as I understand it is used to optimize APKs, etc. Whereas the toolchain/compiler does Kernel/Libs+ROM.

Is this correct? I'd like to make it Linaro all the way through in my builds. I noticed during a build yesterday that it was using the stock arm-4.7 compiler (as far as I could tell) and I think this is related to the NDK. I don't think I'm compiling everything with Linaro that I could be. I also noticed that S-Tools shows no Linaro tag in the kernel uname string/info.

sources:

https://wiki.linaro.org/Platform/Android/Toolchain
http://xdaforums.com/xperia-z/development/tutorial-compile-xperia-z-rom-linaro-t2330970

Anyone shed some light on this for me?

I checked the Linaro site, then repos, and the first one I found with a 4.7 GCC was kitkat-cts-dev. Everything newer than that doesn't contain 4.7, at all. It doesn't surprise me, 4.8+ is better on paper and 4.7- really needs to be phased out. Seeing as how PAC only needed 3 fixes for 4.8, we're almost there, and it looks like 64bit ARM support was added with GCC 4.8, so I expect that to take the place of 4.6 and 4.7 to be phased out (a guess, but a logical one).

GCC 4.9 is required to use A12 tuning.

Speed wise, most benchmarks show 4.7 and 4.8 to be pretty similar in speeds. Didn't check with 4.9.

Good catch on the Linaro NDK part. Now I gotta update my adds/removes, add a Linaro remote, and add in the NDK from their Android repos.

I'm glad I didn't have to fix as many repos as the Sony dude did back then. I tried this with PAC 6 months to a year ago and around the 20th repo that needed fixing I said screw it. Only 4...sure. Oddly, 4.8 needed 3 fixes, 4.7 needed a 4th -- interpret that however you want.

CWGSM3VO · Jun 12, 2014

skeevydude said:
GCC 4.9 is required to use A12 tuning.

Speed wise, most benchmarks show 4.7 and 4.8 to be pretty similar in speeds. Didn't check with 4.9.

Good catch on the Linaro NDK part. Now I gotta update my adds/removes, add a Linaro remote, and add in the NDK from their Android repos.

Can you provide the necessary XML so I can be on the same page too?

For me the NDK looked like it contained the toolchain and a few other things but wasn't sure how to fit it in other than replacing the NDK folder. I'll switch to 4.8/9 here, there's optimized toolchains I can use for that too.

skeevydude · Jun 12, 2014

CWGSM3VO said:
Can you provide the necessary XML so I can be on the same page too? For me the NDK looked like it contained the toolchain and a few other things but wasn't sure how to fit it in other than replacing the NDK folder. I'll switch to 4.8/9 here, there's optimized toolchains I can use for that too.

Code:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- REMOTES -->
  <remote name="linaro" fetch="git://android.git.linaro.org/" />

  <!-- REMOVALS -->
  <remove-project name="android_art" />
  <remove-project name="android_bootable_recovery" />
  <remove-project name="android_build" />
  <remove-project name="android_dalvik" />
  <remove-project name="android_hardware_qcom_display-caf" />
  <remove-project name="android_system_vold" />
  <remove-project name="android_vendor_pac" />
  <remove-project name="platform/ndk" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" />

  <!-- ADDS -->
  <!-- ARCHIDROID LINARO TOOLCHAINS -->
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" remote="github" revision="4.7-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.9" remote="github" revision="4.9-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9" remote="github" revision="4.9-androideabi" />

  <!-- Google 4.8 TOOLCHAIN -->
  <!-- Uncomment the two lines, comment out both Linaro 4.8s, then repo sync to change toolchains -->
  <!-- <project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="aosp" revision="master" />
  <project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="aosp" revision="master" /> -->

  <!-- LINARO -->
  <project path="ndk" name="platform/ndk" remote="linaro" revision="refs/tags/android-4.4.3_r1.1" />


  <!-- MY MODIFIEDS -->
  <project name="skeevy420/android_art" path="art" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_bootable_recovery" path="bootable/recovery" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_build" path="build" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_hardware_qcom_display-caf" path="hardware/qcom/display-caf" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_system_vold" path="system/vold" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_vendor_pac" path="vendor/pac" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_dalvik" path="dalvik" remote="github" revision="pac-4.4" />
</manifest>

Also, everything in that is CM compatible except for android_build and, obviously, android_vendor_pac. To add Archi to CM, all one has to do is cherry-pick android_build, add cm as a remote to the projects under my modifieds, fetch all and "git merge -m1 cm/cm-11.0 $HEAD" (provided you name the remote "cm"). I'll do that later today when I'm off, but just sayin....also, that's any device, not just us.

Added linaro remote, linaro ndk, and Archidroid GCC 4.9.

EDIT:

Updated all my forks, changed Archi V2 to V3 in android_build, added cortex-a12 as an option, changed to gcc 4.9, pushed and synced, starting build

EDIT: 2 removed cortex-a12...

skeevydude · Jun 14, 2014

If anyone want's to build PAC with a 3.4 kernel, here's my local manifest. Don't use gcc 4.9 yet, has out of memory bugs with android/dalvik (used all of my 8 gigs of ram and crashed).

Code:

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <!-- REMOTES -->
  <remote name="linaro" fetch="git://android.git.linaro.org/" />

  <!-- REMOVALS -->
  <remove-project name="android_art" />
  <remove-project name="android_bootable_recovery" />
  <remove-project name="android_build" />
  <remove-project name="android_dalvik" />
  <remove-project name="android_hardware_qcom_display-caf" />
  <remove-project name="android_system_vold" />
  <remove-project name="android_vendor_pac" />
  <remove-project name="platform/ndk" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" />
  <remove-project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" />

  <!-- ADDS -->
  <!-- ARCHIDROID LINARO TOOLCHAINS -->
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.7" remote="github" revision="4.7-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.7" remote="github" revision="4.7-androideabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="github" revision="4.8-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="github" revision="4.8-androideabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.9" remote="github" revision="4.9-eabi" />
  <project name="JustArchi/Linaro" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.9" remote="github" revision="4.9-androideabi" />

  <!-- Google 4.8 TOOLCHAIN -->
  <!-- Uncomment the two lines, comment out both Linaro 4.8s, then repo sync to change toolchains -->
  <!-- <project name="platform/prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-eabi-4.8" remote="aosp" revision="master" />
  <project name="platform/prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" path="prebuilts/gcc/linux-x86/arm/arm-linux-androideabi-4.8" remote="aosp" revision="master" /> -->

  <!-- LINARO -->
  <project path="ndk" name="platform/ndk" remote="linaro" revision="refs/tags/android-4.4.3_r1.1" />

  <!-- MY MODIFIEDS -->
  <project name="skeevy420/android_art" path="art" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_bootable_recovery" path="bootable/recovery" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_build" path="build" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_dalvik" path="dalvik" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_hardware_qcom_display-caf" path="hardware/qcom/display-caf" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_system_vold" path="system/vold" remote="github" revision="pac-4.4" />
  <project name="skeevy420/android_vendor_pac" path="vendor/pac" remote="github" revision="pac-4.4-HD-test" />
</manifest>

[GUIDE + HELP]Rom Making, Stock and Compiled, With Emphasis on Moto MSM8960

Inactive Recognized Contributor

Attachments

Inactive Recognized Contributor

Inactive Recognized Contributor

Inactive Recognized Contributor

Senior Member

Senior Member

Inactive Recognized Contributor

Senior Member

Attachments

Inactive Recognized Contributor

Senior Member

Inactive Recognized Contributor

Senior Member

Inactive Recognized Contributor

Inactive Recognized Contributor

Inactive Recognized Contributor

Senior Member

Inactive Recognized Contributor

Senior Member

Inactive Recognized Contributor

Inactive Recognized Contributor

Similar threads

Top Liked Posts