Archive for the ‘android’ Category

Linaro Mobile Group

Posted: July 8, 2014 in aarch64, android, linaro

I’m pleased to say I’ve taken on the responsibility to help get the newly formed Linaro Mobile Group off the ground. Officially I’m the Acting Director of LMG. In many ways the Group is actually old as advancement of the ARM ecosystem for Mobile has always been and continues to be a top goal of Linaro. What is happening is we’ve refined the structure so that LMG will function like the other segment groups in Linaro. Linaro has groups formed for Enterprise (LEG), Networking (LNG), Home Entertainment (LHG), so it makes perfect sense that Mobile was destined to become a group.

I am quite grateful to Kanta Vekaria for getting the LMG’s steering committee up and running. This committee, called MOBSCOM started last fall and will morph to be called LMG-SC, the SC of course being short for Steering Committee. Members of LMG are in the drivers seat, setting LMG direction. It’s my job to run the day to day and deliver on the goals set by the steering committee.

Mobile is our middle name and also a big term. For LMG, our efforts are largely around Android. This is not to say that embedded Linux or other mobile operating systems like ChromeOS aren’t interesting. They are. We have and will continue to perform work that can be applied across more than one ARM based mobile operating system. Our media library optimization work using ARM’s SIMD NEON is a very good example. Android is top priority and the main focus, but it’s not all we do.

It’s a great time to form LMG. June, for a number of years, has brought many gifts for developers in mobile with Apple’s WWDC, and Google I/O. Competition is alive and well between these two environments, which in turn fuels innovation. It challenges us as developers to continue to improve. It also makes the existence of Linaro all the more important. It benefits all our members to collaborate together, accomplish engineering goals together instead of each shouldering the engineering costs to improve Android.

Android 64 is a great example. We were quite excited to make available Android64 for Juno, ARM’s armv8 reference board as well as a version for running in software emulators like qemu. We also did quite a bit of work in qemu so that it could emulate armv8 hardware. The world doesn’t need 20 different Android 64 implementations. The world DOES need one great Android 64 and in this way the collaborative environment in and around Linaro is important. While the 06.14 release of Android64 for Juno by Linaro is just a first release with much to do yet, things are on track for some great products by our member companies in the months ahead.

Stay tuned!

I run OSX on my laptop. (gasp!) I ssh into my various linux boxes to work on various projects. As I’m doing a little work with Renderscript and my sqlite acceleration project I thought it would be handy to build Android on my OS X laptop. Turns out it’s not entirely difficult and required just one fix to the code.


There are several projects to bring various linux/unix tools onto OSX. I use MacPorts. Brew is probably another good option. Either way this gives us a foundation of tools that the android build system is going to need.

The install instructions offer an extra easy pkg option.

Next we need to install some software.

sudo port install coreutils findutils pngcrush gsed gnupg


Xcode is of course Apple’s development environment for OSX and iOS. You need it, and it can be installed directly out of the App Store.


Make sure you have java installed.

java -version
java version "1.6.0_65"

If you don’t, you’ll get a popup dialog that will ask if you want to install it. Do!


Make sure you have python installed. If I recall correctly that’s a default install with OSX Mavericks.  There is an option to install via ports.

sudo port install python


Pull down repo.

curl > ~/bin/repo

Make sure you add your ~/bin to your PATH

export PATH="$PATH:~/bin"

Android SDK tools

You need to download the android sdk tools built for the Mac. Download these from here. Extract. At this point I created an android directory and put the tools inside of it.

mkdir -p ~/android
mv <whereever>/android-sdk  ~/android

Filesystem setup

OSX for all it’s joys doesn’t deal with case differences in it’s file system unless you specifically created the file system to do so. The default doesn’t. It’s not 8.3, but it’s still 1990s lame. So you’ll need to create a file system for the Android source code to live in.

Make sure you have the space in your file system. I created a 100 gig file system. I wouldn’t go below 50. I also put this onto my desktop. Makes it easy to double click later to mount it. Feel free to mount it where it works best for you. However remember this location!

hdiutil create -type SPARSE -fs "Case-sensitive Journaled HFS+" -size 100g -volname "android" -attach ~/Desktop/Android

Android source code

Download as you normally would. (note the cd to the location of where you just attached the new HFS case sensitive file system.

cd ~/Desktop/Android
git clone
git branch -r   // this will show you all the branch options. I was after the latest.
repo init -u git://  -b android-4.4_r1.2
repo sync

Environment Setup

We need to setup a few environment variables. First add the android sdk tools to your path

export PATH=~/android/android-sdk/sdk/platform-tools:$PATH
export LC_CTYPE=C
export LANG=C

The One Fix

So in there is a slight issue where it doesn’t handle that situation where one of the tool parameters isn’t available. So we need to defensively work around it. (yeah yeah I should just post the patch)

In external/chromium_org/base/android/jni_generator/

At the top of the file (around line 20) add

import platform

Then lower down add the following if to check for Darwin so that -fpreprocessed isn’t passed:

531   def _RemoveComments(self, contents):
532     # We need to support both inline and block comments, and we need to handle
533     # strings that contain '//' or '/*'. Rather than trying to do all that with
534     # regexps, we just pipe the contents through the C preprocessor. We tell cpp
535     # the file has already been preprocessed, so it just removes comments and
536     # doesn't try to parse #include, #pragma etc.
537     #
538     # TODO(husky): This is a bit hacky. It would be cleaner to use a real Java
539     # parser. Maybe we could ditch JNIFromJavaSource and just always use
540     # JNIFromJavaP; or maybe we could rewrite this script in Java and use APT.
541     #
542     system = platform.system()
543     if system == 'Darwin':
544       cpp_args = ['cpp']
545     else:
546       cpp_args = ['cpp', '-fpreprocessed']
547     p = subprocess.Popen(args=cpp_args,
548                          stdin=subprocess.PIPE,
549                          stdout=subprocess.PIPE,
550                          stderr=subprocess.PIPE)
551     stdout, _ = p.communicate(contents)

Ready To Build

That’s it. Least I hope I captured everything I had to do. Build away.

Here’s another useful example with the Android build system.

How do you install a number of files in the build system without actually specifying the files?

In this case, it makes a single test case that uses lots and lots of data files. Who wants to name each and every data file? I don’t!  I have better things to do! Let’s look at an example:

LOCAL_PATH:= $(call my-dir)
piglit_shared_libs := libGLESv2 \
 libwaffle-1 \
 libpiglitutil_gles2 \
piglit_c_includes := $(piglit_top)/tests/util \
 bionic \
 $(piglit_top)/src \
 external/waffle/include/waffle \
 external/mesa3d/include \
include $(CLEAR_VARS)
LOCAL_SHARED_LIBRARIES := libGLESv2 libwaffle-1 libpiglitutil_gles2
LOCAL_C_INCLUDES := $(piglit_c_includes)
LOCAL_MODULE := glslparsertest_gles2
systemtarball: glslparsertest_gles2
LOCAL_SRC_FILES := glslparsertest.c
define all-vert-frag-files-under
$(patsubst ./%,%, \
 $(shell cd $(1) ; \
 find $(2) -name "*.vert" -or -name "*.frag" -and -not -name ".*" -printf "%P\n" ) \
define glsl2_add_test_data
include $(CLEAR_VARS)
LOCAL_SRC_FILES := glsl2/$1
$(warning $(LOCAL_SRC_FILES)) 
datatarball: $1
glsl2_files := $(call all-vert-frag-files-under, external/piglit/tests/glslparsertest/glsl2)
$(foreach item,$(glsl2_files),$(eval $(call glsl2_add_test_data,$(item))))

Walking you through. all-vert-frag-files-under contains the find which looks for those files.  The next define glsl2_add_test_data creates a BUILD_PREBUILT block for each one of the data files.  After the define, we call the find naming the directory where to look. The line after goes through the contents of glsl2_files which has the list of data files that the find found. It iterates through each entry, passing each $item as a param in the BUILD_PREBUILT block.

Simple as that, but given I couldn’t find any documentation or examples, I thought I’d save you the trouble. Enjoy!

Or how to do some fairly useful things with the Android build system that were not intuitively obvious to me.

I’ve been working with Android a fair amount this week, both the upstream Android Open Source Project sources and the Linaro sources. For both I’ve been getting piglit to build which has required me to construct a number of files. In this case, piglit and waffle are the two packages that need to build. Waffle for it’s library and piglit for it’s library, testcases and test case data.

How do you build a number of binaries in a loop using Android’s

I wondered the same. As the google examples go, for each binary you want to build, you need to specify several LOCAL_* values. If you had to do this for each and every test binary in piglit, it’d be quite quite tedious.  Here’s example how to it the easy way:

include $(call all-subdir-makefiles)

LOCAL_PATH:= $(call my-dir)

piglit_top := $(LOCAL_PATH)/../../..
piglit_shared_libs := libGLESv2 libwaffle-1 libpiglitutil_gles2
piglit_c_includes := $(piglit_top)/tests/util \
bionic \
$(piglit_top)/src \
external/waffle/include/waffle \
external/mesa3d/include \


module_name = piglit-spec-gles2

define $(module_name)_etc_add_executable
include $(CLEAR_VARS)
LOCAL_SHARED_LIBRARIES := $(piglit_shared_libs)
LOCAL_C_INCLUDES := $(piglit_c_includes)
LOCAL_CFLAGS := $(piglit_c_flags)
LOCAL_MODULE := $1_gles2
systemtarball: $1_gles2

test_names := invalid-es3-queries minmax
$(foreach item,$(test_names),$(eval $(call $(module_name)_etc_add_executable, $(item))))

It’s fairly straightforward once you have the solution but getting there isn’t exactly documented in the google docs from what I could see. So let me talk you through it.

At the top, I have the list of shared libs that will be linked in and the directories that should be searched.

Within define $(module_name)_etc_add_executable are the set of values  we need to specify for each testcase. Observe that $1 is a parameter passed in. We have to keep to a pattern of test_case.c  will end up as name of the test_case binary, but who cares, this is quite acceptable.

Last test_names is the list of all the test cases we’re going to build. Followed last but not least by the loop that iterates over the test case list.

Next. Data!

How do you copy test case user data to the data partition in an file?

Again this was something I scratched my head about, looking through the docs, googled often and came up empty. It’s not hard but it’s not necessarily intuitive.

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE:= sanity.shader_test
LOCAL_SRC_FILES := sanity.shader_test
userdatatarball: $(LOCAL_MODULE)

In this example there is but one data file. But I think you can see where it’s going. Combine with the loop example above and things get quite useful.

Some things to point out.  We need BUILD_PREBUILT since we’re not building anything. The LOCAL_SRC_FILES is our list of data. LOCAL_MODULE_PATH is where to install to.  TARGET_OUT_DATA is /data. It will create the directories for you if they don’t exist.

userdatatarball: is rule to make sure that the datafile ends up in the tarball. I couldn’t figure out a way to not have this but perhaps there is a way. I didn’t run across it.

So there you have it. There might be bugs yet. There might be a better more official way. Based on what I figured out this is what works for me.

1047, to be exact.

Hmm? 1047 Piglit tests running on ARM Linux.

What’s piglit?  Piglit is a test suite for OpenGL. For the most part it’s used for testing Mesa which is the open source implementation of OpenGL and OpenGL ES. It’s used on Android and Linux. If you’re writing a GL or GLES driver Piglit is a way to run graphical tests to check your implementation.

Just 60 days ago, there were basically zero OpenGL ES 2.0 tests that ran. None. I’ve been working to fix,  largely concentrating on the glslparser and shader_runner tests both stressing glsl es 1.00 which is an important component in Open GL ES 2.0. To put it into perspective a full piglit test run of all tests on my intel box for OpenGL  is about 6,900 tests.

Also, the piglit team is in the midst of doing something rather fun and that’s converting over to the use of waffle. What’s waffle?  Waffle is a way to defer to runtime which variation of GL api you’re going to use (GL, GLES) as well as what windowing system you’re going to use (X11, Wayland, etc).  So one could for instance do a complete set of test runs for say GLES 1.1, 2.0 and 3.0 in time without a recompile.

Thus far the code in question is not yet all upstream and things are still under rapid development but via my git tree you’re able to follow along and run. I’m not running on Android quite yet but that is being worked on by myself and others.


Then you’ll want the gles2-all branch.

git checkout -b my-copy origin/gles2-all

(Be warned, the gles2-all branch is fairly dynamic)

Before you build piglit you’ll need to obtain, build and install waffle. Grab it from git://

See the README.txt for instructions as to how to build and install.

Turning our attention back to piglit. Make sure you read the README.txt and that the software prereqs are installed. Then:

ccmake .

Turn on just the gles2 tests. Hit ‘c’ to configure.  Then hit ‘g’ to generate and last to build



./ tests/all_es2.tests results/es2

and format the results.

./ sum/es2 results/es2

After that point your web browser to the sum directory that you’ve created to see the results.

What’s next? Getting this all running on android, getting it integrated into our  lava automated test system and of course more tests.

1Q12 Linaro Connect Afterglow

Posted: February 20, 2012 in android, linaro, open_source

A week has gone by since 1Q12 Linaro Connect wrapped up in the bay area. Speaking for myself it was a good connect with the outcomes in line with my expectations.

In the Linaro Multimedia group we hosted 4 sessions about audio on the various member company boards. These included, STE, TI, Freescale, and Samsung. It was a great opportunity to meet with the landing teams who work to keep the kernel updated, push patches upstream in the kernel and in some cases enable the multimedia stack. I say some cases as not all drivers are open from board to board. We were able to talk about common problems, how we can help each other and most importantly keep multimedia working on Linux and Android.

Some themes emerged from the meetings for which we are able to take acti. First the teams all need some sort of easy to use command line tests to validate things are functional. Second the sound configuration system needs to change to be less brittle.

Over the course of the week the STE team is to be commended as audio was made to be working on snowball. They were running xbmc by the end of the week which is great accomplishment.

On Tuesday morning I gave one of the 15 minute plenary talks. Hope the talk makes it up to youtube where the other talks are starting to appear. In short the talk was about audio and accelerated video aren’t nice to have anymore, they are requirements and if they aren’t working, we need to consider the build broken.

Beyond Audio sessions there was a meeting about codecs and NEON optimizations. VP8 is high on the wish list as many would like to have good demo capabilities using Google+ hangouts which of course utilizes VP8. WebP the newer still image format also appeared on the list. Libav is still a popular item however since it is not on Android this was an item for discussion as far as how to maximize benefits to Android besides just Linux.

There was also a gstreamer session. The discussion largely centered on the release of gstreamer 1.0 and the efforts and issues that will need to be considered as part of the upgrade.

dma_buf was also a discussion point in it’s own set of sessions. From what’s next to Android discussions and related. I didn’t make it to most of those sessions unfortunately. With Jesse Barker and Rob Clark driving those efforts it continues to move forward. With the acceptance into the 3.3 kernel, it’s exciting times. Further Rob had a demo at the Friday demo session of a camera using dma_buf. Exciting stuff.

During the hacking sessions, I upgraded libjpeg-turbo to 1.2. BenjiG was able to get even more test cases running in LAVA. Feng was working furiously to make the 12.02 release with stability updates for alsa and pulse audio for Panda and imx53. Kurt while not in attendance was working on UCM for Android.

Another high point of LC was the use of Google+ hangouts over the air. It worked and allowed remote participants to be part of the sessions.

Why go to a Linaro Connect? Linaro Connect is part planning the future of ARM and part hacking sessions. For an engineer it’s a high bandwidth, high productivity environment. You can watch world cup soccer on TV, you can watch the super bowl on TV, but being there is an entirely and more rewarding experience not only for the individual but for the ARM community. Sure one can attend a session or Google+ hangouts but you can’t sit next to someone at a hacking session, you can’t grab someone in the hallway, you miss the shared experience and likewise the community misses the shared experience of having you there. Ideas, designs, conversations go in far more interesting directions with you in the audience.

Hope to see you in Hong Kong!

12.01 was the first monthly cycle of the year 2012 for the Linaro Multimedia Work Group. It was a short cycle as it included both the Christmas/New Years celebrations as well as the Chinese New Year celebration which is of no surprise many take vacation to spend with their friends and family.

Even with the short cycle work was accomplished and I’d like to share some of the highlights with you.


One of our major goals for this cycle was the return of working audio. This is a fairly difficult area especially on Linux as the between the kernel, alsa and pulse audio, there’s plenty of room for regressions to occur. In past months we’ve been bit strongly by those regressions such that when it comes to audio on the Linaro LEB, I’ve taken a very inbox zero approach. It’s all broke unless proven otherwise. Let’s fix it!

So as a team we focused on audio on Panda, Panda ES and imx53. All of these boards have output via an audio jack as well as out HDMI when HDMI is used for video out. Wei Feng along with the respective ti and freescale landing teams worked hard to address the kernel drivers, ucm configs which are packaged with alsa and updates to pulse audio to support ucm.

With Panda there is an existing bug where DVI video is busted. Because of this if you are validating the audio jack you have to set amixer settings appropriately so when using speaker-test or aplay you’ll get output.

Here we are on release day and audio is working for our aplay and speaker-test tests. It’s a start but not quite a whole perfect user experience. We do see bugs with GUI tools that sit above. Are the bugs in the tools or in lower portions of the audio stack, that’s a good question. We know we have a start. A line in the sand which we will not back from but clearly more work ahead.

Kurt is working on the audio stack for panda on Android. On Jan 6th the Android kernel team delivered the needed support for audio. It’s a start, we look forward to enabling ucm as well as other audio stack elements in the days and weeks ahead.


Mans started implementing optimizations for libav involving vp8.He’s a master coder and we look forward to his upstream submissions sometime in February but probably after LC since Linaro Connect and ELC are the first part of February.

Rony worked on the NEON optimized version of speex. It is part of the Linaro Android release now. Good job Rony! Rony has also worked to become on of our Lava experts.

I worked on libjpeg-turbo for android. I pull in some upstream updates fixing up the android specific patches. I then pulled in some existing qualcomm optimizations of 565 and 8888 encode and decode. I had to rework the patches a bit to get them to fit into libjpeg-turbo but in the end it appeared to be well worth it yielding about a 100% performance improvement in skia-bench.  There are some STE patches that accomplish the same that were recently given to me. I am going update the STE implementation so it fits with libjpeg-turbo and hold a bake off. Winner goes upstream.


Rob added eglImage rendering support to qtmobility. This dramatically improved HW video decode so for the linaro-tv xmbc image and Ubuntu TV efforts on panda, it looks spectacular. Ricardo Salveti wrote about this in his blog, including demos. Be sure to check it out at :

Kan worked on xbmc. Specifically he’s looking at a way to improve the way video is played on xbmc using gstreamer as well as general improvements for xbmc that make it really shine on arm hardware. We’ll have a demo at Linaro Connect in February.

Benjamin worked the the continuous memory allocator debug blueprint. This is part of the larger UMM (unified memory manager) effort that Linaro is leading. A special shout out to Benjamin for becoming and helping out others with getting testcases into Lava. Lava is our automated test system. It new to Linaro and having someone take the time to education and help others is really valuable.


I hope you’ll agree it’s a good set of accomplishments for a significantly shortened cycle. I can’t thank the team enough for their efforts. Look for more accomplishments in 12.02.

The wiki page that holds all this information but in a much more raw form can be found here:

Our 12.02 plan is starting to take form here :

skia_bench on android measures a number of things. One portion of the benchmark measures libjpeg performance, specifically for 565 and 8888 image types that are specific to android.

Android (including the latest ice cream sandwich release) uses the old and quite crusty libjpeg library. This library while functional is missing a great deal of optimization. The libjpeg-turbo project ( is a souped up and more importantly drop in replacement API compatible version of libjpeg. It is compatible with both versions 6.x and 8 that are in wide use across many a distro. However because libjpeg doesn’t have simd (Single instruction, multiple data) optimizations using NEON on ARM for instance, distributions have been pitching libjpeg for libjpeg-turbo.

At Linaro our Android Ice Cream Sandwich for instance replaces libjpeg with libjpeg-turbo. Likewise we recently worked with Ubuntu and as a result Precise (version 12.04) now includes libjpeg-turbo.

So what kind of performance bump can one see by switching from libjpeg to libjpeg-turbo?  includes lots of raw numbers on intel and ARM machines. In short performance improvements measured by tjbench  are on the order of 200% to 300%.

libjpeg-turbo doesn’t include support for Android. So earlier this year, we ported libjpeg-turbo so it would include Android dependency on the aforementioned  nonstandard 8888 and 565 formats. This was a good first step however, no work had been done to optimize for 565 or 8888. Thus the performance for 565 and 8888 was about the same for libjpeg and libjpeg-turbo.

I’d like to see Android switch to use libjpeg-turbo so this week it was time to do some optimization that would give credence to that desire. Optimizations that can be measure with skia_bench would be the way to go.

Hack. Hack. Hack.

The results? A comparison of android’s libjpeg,  libjpeg-turbo without 565 or 8888 optimizations and libjpeg-turbo with 565 and 8888 optimizations can be found at : . Smaller numbers are better.

Half the time not bad or put another way, the newly improved libjpeg-turbo is 2 times faster than the old libjpeg! I’m sure you’d like that improvement on your Android phone or tablet!  I would!

Now we get to another part of the story that is important also reflects another aspect of what makes Linaro an important leader in ARM for Linux and Android.  You see the optimization code for 565 and 8888 already sort of existed. It was sitting out in a git archive more or less gathering dust. The essential step of putting it together with the already optimized libjpeg-turbo hadn’t been done. The code also hadn’t been pushing upstream to the communities that would most benefit. In Linaro we want Linux and Android on ARM to shine.

While it’s all put together and it works, that’s great. Now comes the most important steps, getting google’s Android engineers (and perhaps cyanogen mod too!) to accept it so that all might benefit. That’s the bar for success we aim for at Linaro and we will succeed.

Code : git://

Pull from the android branch.   git checkout -b android origin/android

Have fun!