Archive for the ‘aarch64’ 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!

Updated June 3rd.

Here are the instructions for building your own Open Embedded based aarch64 image which is able to run an xfce based graphical environment. Consider this a draft that will evolve as there are some hacking bits and some steps that over time I want to make disappear.

mkdir openembedded

cd openembedded

git clone git://

cd jenkins-setup

sudo bash

edit and delete the very last line which is a call to bitbake. bitbake starts a build, we want to delay that for a bit.


  • pull from my xfce brance

cd meta-linaro
git remote add linaro git://
git fetch linaro
git checkout -b xfce linaro/xfce

cd ../meta-openembedded

git remote add linaro git://
git fetch linaro
git checkout -b aarch64 linaro/aarch64

cd ../openembedded-core

git remote add linaro git://
git fetch linaro
git checkout -b aarch64 linaro/aarch64

cd ..

  • Next we need to expand the set of recipes the build will use.

cd build

edit conf/bblayers.conf and add

BBLAYERS += ‘/your-full-path/jenkins-setup/meta-linaro/meta-browser’
BBLAYERS += ‘/your-full-path/jenkins-setup/meta-openembedded/meta-xfce’
BBLAYERS += ‘/your-full-path/jenkins-setup/meta-openembedded/meta-gnome’

  • Now it’s time to build

cd openembedded-core
. oe-init-build-env ../build
cd ../build
bitbake linaro-image-xfce

  • The output of the build is in the build directory in tmp-eglibc/deploy/images
  • Package the resulting rootfs into an img. using linaro-media-create. This implies you have a current copy from bzr of linaro-image-tools (bzr clone lp:linaro-image-tools. Also you need the hwpack from the first step.

~/bzr/linaro-image-tools/linaro-media-create –dev fastmodel
–image_size 2000M –output-directory gfx   –binary
linaro-image-xfce-genericarmv8-20130524144429.rootfs.tar.gz –hwpack

We’ll do some work to smooth this out and get rid of this step and use the OE built kernel.

  • Boot the rtsm model

I use a script for running with either the Foundation model or the RTSM model. Note I keep the Foundation model and the RTSM models inside of ~/aarch64.




if [ ! -z $3 ]; then

if [ -z $1 ]; then
echo “Usage: aarch64-sim KERNEL ROOTFS foundation|rtsm”
kernel=`realpath $1`

if [ ! -z $2 ]; then
rootfs=`realpath $2`

case $model in
if [ ! -z $rootfs ];then
rootfs=” –block-device $rootfs”
# sudo ip tuntap add tap0 mode tap
# sudo ifconfig tap0
~/aarch64/Foundation/Foundation_v8pkg/Foundation_v8 –image $kernel  –network nat $rootfs
if [ ! -z $rootfs ];then
rootfs=” -C motherboard.mmc.p_mmc_file=$rootfs ”
~/aarch64/RTSM_AEMv8_VE/bin/model_shell64 \
-a $kernel \
$rootfs \


I put this in  (Don’t forget to chmod +x) gfx/img.axf  gfx/sd.img rtsm

  • After the linux system has booted you need the run the following by hand.

fc-cache -f -v

pango-querymodules > /etc/pango/pango.modules

  • and now finally run:


That it for now!

Wouldn’t it be great to have an Open Embedded linaro image with a graphical environment for aarch64? We thought so too.

So in the Linaro Graphics Working Group we’ve been creating one. In our case we picked xfce as our environment. It’s reasonably lightweight, fairly simple, has reasonable package dependencies and already supported in OE.

The environment for running aarch64 these days that I have access to is the simulator. There are two, one called the Foundation and the other the RTSM commercial model. I’ve been using the later but the results should work with the Foundation model as well. Emphasis on should, I haven’t tried yet.

So let’s retrace the journey a bit so you can enjoy the adventure. With framebuffer on in the kernel and the usual suspects, X of course is the first stop along the way.


xclock, xterm in all their early 1990s lack of any bells and whistles glory. While the output looks reasonable, at this stage I didn’t have the mouse working and couldn’t enter any keyboard input.

Pressing ahead I starting adding in xfce packages to my image. That got me to here.


Ew! Obvious font problems and still no ability to get keyboard or mouse input. I quickly discovered from the Xorg log I didn’t have xf86-input-evdev. Once installed both keyboard and mouse worked.

Fonts were a bit more tricky. fc-cache -f -v alone wasn’t fixing it. Given the squares that doesn’t look like a rendering problem. Pango!  Ah yes.  /etc/pango/pango.modules was empty. One pango-querymodules > /etc/pango/pango.modules later and things were much better.


Ahhh much better!  Still you can see in the window titlebars something is amiss and our xfce environment is still missing things. So fleshing things out even more brings us to this current point.


That certainly looks much more like a normal xfce setup. Still have some rendering issues to address, between the mouse pointer and something with the windows but otherwise, this is something usable and moving in the right direction.

In my next post, I’ll point you at images and the early instructions as to how you can build and use this yourself!