FORUMS
Remove All Ads from XDA

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

3,072 posts
Thanks Meter: 3,058
 
By skeevydude, Recognized Contributor on 8th June 2014, 10:57 PM
Post Reply Email Thread
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("");
HIGHLIGHT THIS LINE AND PASTE YOUR PERMISSIONS HERE
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
Attached Files
File Type: zip tools.zip - [Click for QR Code] (583.3 KB, 82 views)
File Type: zip META-INF.zip - [Click for QR Code] (275.9 KB, 43 views)
The Following 17 Users Say Thank You to skeevydude For This Useful Post: [ View ] Gift skeevydude Ad-Free
8th June 2014, 10:57 PM |#2  
skeevydude's Avatar
OP Recognized Contributor
Flag Hot Springs
Thanks Meter: 3,058
 
More
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:
sudo apt-get install meld git-cola
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 -- cd vendor/pac
Add your remote -- git remote add skeevy https://github.com/skeevy420/android_vendor_pac.git
fetch remotes -- git fetch --all  (or git fetch name_of_remote to only fetch a single remote)
Add a new branch and switch to it -- git checkout -b pac-4.4 ***BRANCH NOTE***
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 -- git commit -a -m "Change moto_msm8960 kernel to arrrghhh's kernel"
Push and set remote as upstream -- git push --set-upstream skeevy pac-4.4
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="skeevy420/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.
The Following 5 Users Say Thank You to skeevydude For This Useful Post: [ View ] Gift skeevydude Ad-Free
8th June 2014, 10:57 PM |#3  
skeevydude's Avatar
OP Recognized Contributor
Flag Hot Springs
Thanks Meter: 3,058
 
More
reserved for other things
The Following 2 Users Say Thank You to skeevydude For This Useful Post: [ View ] Gift skeevydude Ad-Free
8th June 2014, 10:58 PM |#4  
skeevydude's Avatar
OP Recognized Contributor
Flag Hot Springs
Thanks Meter: 3,058
 
More
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.
The Following 3 Users Say Thank You to skeevydude For This Useful Post: [ View ] Gift skeevydude Ad-Free
9th June 2014, 06:12 PM |#5  
CWGSM3VO's Avatar
Senior Member
Thanks Meter: 1,294
 
More
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.
The Following 3 Users Say Thank You to CWGSM3VO For This Useful Post: [ View ] Gift CWGSM3VO Ad-Free
9th June 2014, 06:22 PM |#6  
Zeljko1234's Avatar
Senior Member
Flag Stockholm
Thanks Meter: 2,778
 
Donate to Me
More
So great to follow this thread! Looking forward to test optimized build, especially with the new kernel.

Huge thanks!
10th June 2014, 04:11 AM |#7  
skeevydude's Avatar
OP Recognized Contributor
Flag Hot Springs
Thanks Meter: 3,058
 
More
Quote:
Originally Posted by CWGSM3VO

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 bitchin scores...benchmarks are too easy to cheat, and due to caching, memory management, etc, lower numbers don't necessarily mean crappier performance
10th June 2014, 04:58 AM |#8  
CWGSM3VO's Avatar
Senior Member
Thanks Meter: 1,294
 
More
Quote:
Originally Posted by skeevydude

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 bitchin 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-201...-motomsm8960a9
A15: http://www.filedropper.com/cm-11-201...otomsm8960-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.
Attached Thumbnails
Click image for larger version

Name:	Screenshot_2014-06-09-17-55-08.png
Views:	128
Size:	154.0 KB
ID:	2790150   Click image for larger version

Name:	Screenshot_2014-06-09-18-18-07.png
Views:	123
Size:	154.0 KB
ID:	2790151  
10th June 2014, 06:11 AM |#9  
skeevydude's Avatar
OP Recognized Contributor
Flag Hot Springs
Thanks Meter: 3,058
 
More
Quote:
Originally Posted by CWGSM3VO

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-201...-motomsm8960a9
A15: http://www.filedropper.com/cm-11-201...otomsm8960-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 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 )

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....
The Following User Says Thank You to skeevydude For This Useful Post: [ View ] Gift skeevydude Ad-Free
10th June 2014, 08:41 AM |#10  
CWGSM3VO's Avatar
Senior Member
Thanks Meter: 1,294
 
More
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
The Following User Says Thank You to CWGSM3VO For This Useful Post: [ View ] Gift CWGSM3VO Ad-Free
10th June 2014, 03:48 PM |#11  
skeevydude's Avatar
OP Recognized Contributor
Flag Hot Springs
Thanks Meter: 3,058
 
More
Quote:
Originally Posted by CWGSM3VO

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.
The Following User Says Thank You to skeevydude For This Useful Post: [ View ] Gift skeevydude Ad-Free
Post Reply Subscribe to Thread

Guest Quick Reply (no urls or BBcode)
Message:
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes