1 2 Previous Next

Android Community

18 posts

This blog has been written before but quite a few things have improved in the ease of use and breadth of support of Streamline use on Android in the past few years. For starters, Mac OS X is well supported. Now all three major development platforms (Linux, Windows and Mac) have the ability to run DS-5 Community Edition debugger (gdb) and Streamline with the ADT Eclipse tools from Google as an add-on or pre-packaged as DS-5 CE for Windows and Linux from ARM with ADT as an add-on. Also, and most welcome, is the new Gator driver. The component of Streamline that runs in Android to collect OS and processor counters used to require both a kernel module and a driver daemon. Compiling and flashing any module could be complicated depending on the availability of your Android platform kernel headers. That requirement has been removed and now the Gator driver will run as root on many devices. This July (7/2014), an updated version of gatord in the DS-5 CE 5.19 will be released that greatly expands the kernel versions supported (beyond the 3.12 kernel version supported in the current DS-5 5.18 release). Finally, I’ve found some erroneous and dated info in some blogs that claim to be up to date to DS-5 5.18 and even the yet to be released 5.19. I’ll try to correct that here and support this blog entry.

 

Streamline is a powerful system analysis tool that will help you speed up your code, reduce energy footprint and balance system resources. The free version in the Community Edition of DS-5 lets you view CPU and OS counters in a powerful graphical view; CPU and GPU activity, cache hits and misses and visibility down in to individual threads and modules. You can find code that is blocking or could be optimized by multithreading or refactoring in NEON or the GPU. Check out more features on the optimize site.

 

 

Getting Started:

 

As of this writing the Android SDK Manager is Revision 22.6.4 bundled in the latest SDK for Mac, adt-bundle-mac-x86_64-20140321. The SDK is available at the Android Developer Site. The Native Development Kit (NDK) is revision 9d. Download both of these for your appropriate platform. I’m downloading the Mac OS X 64-bit versions for this guide but these instructions should work for Windows and Linux just as easily.

 

Once you unpack these tools, you should add some executable paths to your platform if you plan on using the terminal for anything like the Android Debug tool (adb). It is now possible to use all of the tools from within Eclipse without adjusting your executable paths but for some of us old-schoolers who are wedded to the CLI, I drop my NDK folder in to the SDK folder and put that folder in my Mac’s /Applications directory. You can place them wherever you like on most platforms though. I then added these to my ~/.bashrc

 

export PATH=$PATH:/Applications/adt-bundle-mac-x86_64-20140321/sdk/platform-tools

export PATH=$PATH:/Applications/adt-bundle-mac-x86_64-20140321/sdk/tools

export PATH=$PATH:/Applications/adt-bundle-mac-x86_64-20140321/android-ndk-r9d

 

You should now be able to launch common Android tools from your command line:

> which ndk-build

/Applications/adt-bundle-mac-x86_64-20140321/android-ndk-r9d/ndk-build

> which fastboot

/Applications/adt-bundle-mac-x86_64-20140321/sdk/platform-tools/fastboot

> which adb

/Applications/adt-bundle-mac-x86_64-20140321/sdk/platform-tools/adb

> which android

/Applications/adt-bundle-mac-x86_64-20140321/sdk/tools/android

 

You can Launch the Android SDK Manager from Eclipse in the “Window” menu or via the command line by typing:

> android

 

From there, you can update your current SDK, install older APIs, build-tools, platform tools and in “Extras”, the Android Support Library for compatibility with older APIs.

Pasted Graphic 4.jpeg

When you run Eclipse (ADT) for the first time or change versions, you may have to tell it where to find the SDK. The Preferences dialog box is found on Macs via the ADT->Preferences menu, sub heading Android.

Pasted Graphic 3.jpeg

Setting up a demo app to analyze (if you don’t have your own app):

 

You probably have your own library or application you want to perform system analysis on but just in case you’re checking out the tool, I’ll step through setting up an app that is near and dear to me, ProjectNe10. You can grab the master branch archive from GitHub. For this tool demo, I’ve created a directory /workspace and unzipped the Ne10 archive inside that folder. ProjectNe10 requires the cmake utility. Fortunately, there is a Homebrew solution to install cmake from the command line:

 

brew install cmake

 

If you don’t have brew installed, install it. You’ll use it in the future, I promise. You can also just download the binary for any platform from cmake.

Now we can build the Ne10 library from the command line:

 

Set these to your particular paths:

 

export NE10PATH=/workspace/projectNe10

export ANDROID_NDK=/Applications/adt-bundle-mac-x86_64-20140321/android-ndk-r9d

 

Then:

 

cd $NE10PATH

mkdir build && cd build

cmake -DCMAKE_TOOLCHAIN_FILE=../android/android_config.cmake ..

make

make install

 

That make install line will copy libNE10_test_demo.so to your /workspace/projectNe10/android/NE10Demo equivalent. Now you can go to the File->Import menu in Eclipse and import an existing Android code base in to your workspace.

 

Pasted Graphic 6.jpeg

Pasted Graphic 7.jpeg

 

If all goes well, you should be able to connect your ARM based Android Device (in my case, a Nexus 5 running Android 4.4.4 to match the current SDK at the time of this writing) and run this app from the Run menu as an Android app. As a sanity check, you should run adb devices from the command line to verify you can see your device. This app will iterate through every function in the ProjectNe10 library with both C and NEON implementations. One of the implementations should be faster. I’ll give you a hint. It is the NEON implementation.

 

 

Installing DS-5 Community Edition (Free Eclipse Plugin with enhanced ARM debug and system analysis):

 

Start Eclipse and go to the menu Help->Install New Software.... Click on “Add...”, and paste http://tools.arm.com/eclipse in the location text box, then click OK. Select ARM DS-5 Community Edition, as shown on the screenshot below, and click Next. Eclipse will compute the dependencies of the DS-5 CE plug-ins.

Pasted Graphic 8.jpeg

 

Click Next again. Read the license agreements and if you accept, hit Finish. After the install is complete, ADT will ask you to reload.

A license dialog should popup if this is a fresh install. Select "Install Community edition license" and click "Continue".

 

If there was no popup license message go to Help->Generate community edition license, and click "Finish".

 

Congratulations, you now have ARM DS-5 CE installed with its enhanced and easy to use debugger which you can use to debug Android NDK apps and libraries with the steps in this guide. You also have Streamline; a powerful system analysis tool which we’ll cover in the next section.

 

Using Streamline and gator to analyze Android apps and the entire system

 

Before you can gather data for system analysis, you have to install a data collecting driver (daemon) in Android. Gatord will gather processor and kernel counters on the Android device and stream them over to your host machine. It must run as root to do this. Any device with an unlocked boot loader is very simple to root, you usually just flash a custom recovery tool like TWRP and install SuperSU. If you have a locked bootloader, you’ll have to use a device exploit so I can’t recommend this or help you but your favorite search engine might… This is a minor inconvenience now as older versions required a kernel module (gator.ko) which needed to be compiled against your particular device’s kernel headers. Now that Android security terms to pass Android CTS disallow kernel modules, you’d have to compile in to the kernel and flash it. Fortunately the new gatord will expand its kernel version support significantly in July.

 

First, build gatord. Go to the menu Help->ARM Extras… this will open up a folder with several goodies in it.

Pasted Graphic 9.jpg

 

I’m going to build this from the command line so fire up your favorite terminal and cd in to this directory. The easiest way in the Mac terminal app is to type “cd ” and dragging the gator folder in to the terminal window. OS X will fill in the path, then:

 

cd daemon-src

tar zxf gator-daemon.tar.gz

mv gator-daemon jni

cd jni

ndk-build

 

These steps should unzip the gatord source, and build it for Android (dynamically linked) with the output in ../libs/armeabi/gatord. Copy this binary to your Android device with your favorite method, AirDroid, scp, Droid NAS or very simply:

 

adb push ../libs/armeabi/gatord /sdcard/gatord

 

This, of course, assumes you’ve enabled developer options and debugging on your device. “On Android 4.2 and newer, Developer options is hidden by default. To make it available, go to Settings > About phone and tap Build number seven times. Return to the previous screen to find Developer options. In Developer options click USB debugging. If this is a new device, you may have to approve the debug link security the first time you try to use adb. You can also do this with an ARM based Android Virtual Device (AVD) in the emulator if your physical device is too ‘locked down’ but Streamline system data won’t be as useful. You may have to use “mount -o rw,remount rootfs /“ and “chmod 777 /mnt/sdcard” in your AVD to push gatord.

 

Now, the tricky part, you have to move this binary to an executable location in the filesystem and set executable permissions. The most reliable method I’ve used is ES File Explorer. Go in to the menu, turn on Root Explorer and go to the Mount R/W option, set root “/“ as RW (read/writeable) rather than RO. Then copy and paste gatord in to /system/bin in your Android filesystem. You can also set the permissions to executable in ES File Browser by long pressing on the gatord file, then more->Properties->Permissions->Change. Give the owner any group Execute permission and press Ok.

 

Back in your host machine terminal you need to set up a pipe for gator to communicate over USB and then get a shell on the device to start it:

 

adb forward tcp:8080 tcp:8080

adb shell

 

Now you’ve got a shell on your android device, you can su to root and start gatord. Type:

 

su

/system/bin/gatord&

 

The rest is pretty straight forward. Go to the Window->Show View->Other…->DS-5->ARM Streamline Data

Click on the gear button

Pasted Graphic 13.jpeg

 

 

In the address section, enter “localhost” if you’re streaming the capture data over USB using adb to forward the TCP port. In the Program Images box select the shared library that you want to profile (add ELF image from workspace).

Pasted Graphic 10.jpg

 

 

 

You can now use the red “Start Capture” button at any time.

Pasted Graphic 14.jpeg

Other blogs and tutorials are accurate from this point forward on the features and use of Streamline so I’ll drop a few and let you get to it!

The “CAPTURING DATA AND VIEWING THE ARM STREAMLINE REPORT” section of this blog is accurate.

Events based sampling video, analyzing CPU and GPU performance and customizing charts on YouTube.

 

At VIA we are aiming to provide more software support for our products. Most ARM based boards have both Linux and Android images that potential partners can try. On our product line we have two Freescale boards, the VAB-800 (single core Cortex-A8) and newer VAB-820 (quad core Cortex-A9). The latter just have a brand new Android Evaluation Package fresh up on our website, ready for testing.

 

The Android image is based on Jelly Bean 4.2.2 (which puts this package ahead of even our other boards). Among the available features is the CAN bus driver, resistive touch screen, HDMI video and audio output, dual display and mini PCI-E support. On the developer timeline for future releases we have ADV-7180 Capture, WatchDog/GPIO, VIA Smart ETK support for embedded solutions.

 

Android for Freescale is still a quite new combination with a lot of potential. We are hoping that it will make device developers lives easier both on the software and hardware side. This evaluation package is just the beginning of this conversation.

vab-820_1.jpg

What do you think, what would make you choose an Android system over others for your next embedded solution?

 

The Android Evaluation Package (as well as the Linux Evaluation Package) is available on the VIA Embedded website.

There is a very active overclocking community called HWBot, with quite a few organizers here in Taiwan. For a very long time they were doing desktop (and laptop?) overclocking, challenging the hardware, and pushing the boundaries. When they were giving a presentation about their past, and future plans, they were really proud of making the desktop computer industry care more about hardware quality.

 

Now they want to do the same thing for smartphone hardware. Just recently released the beta version of their Android benchmarking app HWBot Prime, an started to gather data for different devices. My HTC Butterfly (running a Quad Snapdragon C4, I guess) did pretty well on that (whenever I could kill enough apps not to interfere with the benchmark).

 

The VIA Springboard (that I'm taking care of) is a single-board computer that can also run Android (4.0.3) besides Linux. It has a WM8950 single core 800MHz CPU, so it is not a match for the Butterfly, but the per-core-per-MHz results are better.

android_benchmark_2.jpg

So far it's benchmarking only without any overclocking yet, and I'm running on the stock Android image, but it's a good baseline to start improving on the result. Cannot manage something that I cannot measure, right?

 

The submitted result for the Springboard is on the HWBot leaderboard. I wonder if anyone else wants to benchmark, tune, and overclock their ARM devices?

 

The whole experience is written up in the VIA Springboard Blog.

As a result of the rapid proliferation of Android smart phones and tablets, embedded developers worldwide are increasingly adopting the operating system for a growing number of embedded systems and connected devices that leverage its rich application framework, native multimedia capabilities, massive app ecosystem, familiar user interface, and faster time to market.

 

However, although the benefits of adopting Android for embedded systems and devices can be great, particularly for touch-based multimedia applications, utilizing the OS also presents a number of critical challenges, including selecting the right ARM SoC platform for the target system application, porting and customizing the operating system and applications, and ensuring tight integration between the hardware and software to deliver a compelling end-user experience.

 

viaspring.jpg

 

In addition to exploring the benefits and challenges of adopting Android for embedded applications, the attached white paper provides an overview of the holistic approach that VIA Embedded has established in order to enable developers to reduce product development times and speed up time to market for innovative new embedded Android systems and devices.

 

Holistic Approach

VIA is committed to support the entire product development life cycle, from defining product requirements, all the way through development.

  • Best of Breed application specific ARM SoC platforms, with a comprehensive range of Freescale and VIA ARM SoCs
  • Small form factor ARM boards and systems, using VIA's expertise in creating practical form factor standards
  • Android software packages and customization services (see below)
  • Longevity, by supporting specific boards and systems up to 5 years

 

Android Customization

 

Via Embedded provides  a wide range of software solution packages and customization services to facilitate the development of Android embedded systems and devices:

  • Customized applications, including system apps
  • Kernel & Framework including security and special devices
  • System management including watchdog, remote monitoring, remote power on/off, silencing app and system upgrades
  • Embedded I/O including legacy I/O

 

VIA Android Smart Embedded Tool Kit (ETK)

 

The VIA Embedded Android Smart ETK includes a set of APIs that enable the Android application to access I/O and manageability services provided by the system hardware that are not supported in the Android framework.

 

APIs include:

  • Watchdog to help applications and the system to recover from failures and breakdowns
  • Scheduled power on/off, and periodic reboots
  • RTC Wake-up to auto power on at a specific time of the day, of the week, or of the month.
  • Legacy I/O Support making RS232, GPIO, I2C, and CAN bus available for apps

 

 

More details, and a case study is presented in the attached whitepaper.

We would like to share with you an Android-based application that enables Intel software on ARM-based devices. To demo you this approach we took Intel version of DOOM and run it on Android-based device. Application is freely available on Google Play:

Original DOOM - Android Apps on Google Play


This application is a mixture of virtualization and binary translation technology that translates in run-time Intel x86 code to ARM one. Along with translation this engine applies sophisticated optimization algorithms to bring high performance experience to end-users.


By the end of the day we can bring desktop applications to mobile devices at no costs. In this particular case we took original Intel x86 version of DOOM and launched it with no alterations or modifications on ARM-based Android device. In nearest future this approach could be extended to other applications.


For more details visit http://eltechs.com/exagear-mobile/


 


yangzhang

Ne10 FFT feature

Posted by yangzhang Dec 18, 2013

Ne10 FFT feature

 

1 Introduction

You might have heard of the ProjectNe10 before. If not, please get started with Ne10 here.

Recently, new FFT features have been integrated into the Ne10 library. This article will introduce the difference between old FFT and new FFT and how to use these new features.

 

2 Comparison between old FFT and new FFT

The previous FFT implementation did not fully meet user needs. The new FFT was developed to expand functionality to cover more user requirements. The differences between old FFT and new FFT are listed as follows:

feature

Old FFT

New FFT

Length

16, 64, 256, 1024

2^N (N is 1, 2, 3….)

Data type

float

float/int32/int16

Old FFT and New FFT also have different performance. The following figure illustrates the performance comparison between old and new FFT with NEON accelerating. The results have been normalized; shorter bars are better. The test environment is panda board with ubuntu 12.04.

Overall, old FFT has better performance than new FFT, but new FFT supports more features, such as int32/int16 FFT and more FFT length. Users could make a choice based on the actual application.

3 Usage

3.1 APIs

The new FFT contains the following features:

feature

Data type

Length

c2c FFT/IFFT

float/int32/int16

2^N (N is 1, 2, 3….)

r2c FFT

float/int32/int16

2^N (N is 2, 3, 4….)

c2r IFFT

float/int32/int16

2^N (N is 2, 3, 4….)

 

3.2 Example

Take the float c2c FFT/IFFT as an example to describe how to use the FFT APIs.

#include "NE10.h"

……

{

    fftSize = 2^N; //N is 1, 2, 3, 4, 5, 6....

    in = (ne10_fft_cpx_float32_t*) NE10_MALLOC (fftSize * sizeof (ne10_fft_cpx_float32_t));

    out = (ne10_fft_cpx_float32_t*) NE10_MALLOC (fftSize * sizeof (ne10_fft_cpx_float32_t));

    ne10_fft_cfg_float32_t cfg;

    cfg = ne10_fft_alloc_c2c_float32 (fftSize);

    ……

    //FFT

    ne10_fft_c2c_1d_float32_neon (out, in, cfg->twiddles, cfg->factors, fftSize, 0);

    ……

    //IFFT

    ne10_fft_c2c_1d_float32_neon (out, in, cfg->twiddles, cfg->factors, fftSize, 1);

    ……

    NE10_FREE (in);

NE10_FREE (out);

    NE10_FREE (cfg);

}

4 Performance

The following figures describe the performance boost between C versions and NEON versions. The results have been normalized; shorter bars are better. The test environment is panda board with ubuntu 12.04.

For more details, please access http://projectne10.github.com/Ne10/

In the early days if multicore design, Intel claimed that Android devices did not benefit from multiple cores as the apps often lacked threading. A lot has changed and since then they have, of course, released dual-core ATOM for Android.   Today It’s hard to find a CPU in a widespread mobile device that isn’t multicore anymore because most apps need to be multi-threaded.

 

Most ARM partners are producing dual and quad core devices, more than what Intel produce so we maintain an advantage as Android becomes more and more multicore friendly.  So app developers need consider threading in their designs as Android becomes more intelligent about its power and thread management (i.e. ARM big.LITTLE in 64-bit SoCs)

 

With that in mind I teamed up with Matthew Du Puy to develop a couple of articles about Android software design and the tools ARM offers developers.  The first article, Android software design for multicore systems in Dalvik, we look at the Dalvik runtime environment so that many apps are developed in. Dalvik applications are developed using the Android SDK, usually in the GUI environment provided by the Android Development Tools (ADT) plugin for Eclipse.  In the second we take a look at Android multicore design options in C/C++ or assembly language development.

 

Let us know what you think.

Introduction

I think the Samsung Chromebook (model XE303C12) is definitely an interesting product. It is very portable, rather inexpensive and comes with the ARM-based Samsung Exynos 5 Dual CPU. There are several posts on the web explaining how to install different linux distributions on it, but I could not find any successful attempt to port Android to it. In this blog post I give details of how I ported Android to the Samsung Chromebook model XE303C12. I try to be quite pedantic in giving details of the procedure I followed. I do this in the hope of generating documentation which can be useful in other similar ports.

 

Prerequisites

Hardware:

  • The Samsung Chromebook model XE303C12, with the Samsung Exynos 5 Dual CPU,
  • An SD card, 8 GB in this guide,
  • A desktop PC, used to compile the kernel and the Android filesystem, with a card reader,
  • A good internet connection: the source download for Android is approximately 8.5 GB in size,
  • An USB-to-ethernet dongle (optional),

Software:

  • 64-bit Ubuntu 12.04 installed on the desktop PC. Other operating systems may work as well, but have not been tested.

 

Getting ready

Below I describe how to setup the Chromebook and the machine to be used for building the software. This knowledge will be useful in the following sections.

     

Install additional software

Install some required packages on the desktop PC with:

 

        desktop-pc$ sudo apt-get install \
                      u-boot-tools device-tree-compiler \
                      gcc-4.6-arm-linux-gnueabi g++-arm-linux-gnueabi

 

This will allow you to generate u-Boot images and use dtc to add the required Flattened Device Tree to your kernel image.

 

Putting the Chromebook in developer mode

There are various blogs explaining how to do this. I recommend following Daniel P. Berrangé's instructions, which are copied below for your convenience:

 

  1. Booting into Recovery Mode is the first thing to do. This requires holding down the Esc and Refresh keys, while pressing the Power key.
  2. It should now display a nice scary message that the installation is broken. This is of course a lie, so ignore it.
  3. Pressing Ctrl-D now will start the switch into Developer Mode.
  4. It should now display a less scary message asking if you want to turn off verification. We do indeed want to do this, so press ENTER.
  5. The ChromeBook will reboot and tell you that verification is disabled.
  6. Wait a short while, or press Ctrl-D, and it'll display another message that it is transitioning to Developer Mode.
  7. Erasing local data can take a while, so be patient here. Strangely, there’s a crude ascii art progress bar along the top of the screen here, while everything else remains pretty & graphical.

 

When the Chromebook is in developer mode it behaves like this: immediately after the device is turned on, it shows a white screen, with the text "OS verification is OFF/Press SPACE to re-enable". At this point you can do various things:

 

  • You can just ignore the message and wait: after about 30 seconds the Chromebook boots normally,
  • You can press CTRL+D and induce the Chromebook to boot normally,
  • You can press CTRL+U and induce the bootloader to boot from the SD card. The SD card, however, needs to be prepared appropriately and the system does also need to be instructed not to ignore it (I explain below how to do it),
  • You can press SPACE to leave the developer mode and return to normal (verified) mode.

     

Opening a root shell

Turn on the Chromebook and allow it to boot Chrome-OS. If you have just bought the device, you do not need to accept the Chrome-OS license. Wait until you get the first screen where you are asked to choose and setup the network.  Setting up the network is not required in this guide, but you can easily do it, if required: just follow the instructions on the screen and proceed until you are shown the license agreement.  You can now press CTRL+ALT+→ where is the third key starting from the left at the top of your keyboard, where the keys F1, F2, ... would normally be. The Chromebook displays a console. Login as root; there is no password. The cursor may not be visible.  A not-so-nice way of showing the cursor is starting vi. Launch vi, by typing vi + ENTER and immediately quit it typing :q! + ENTER.

 

Via the root console you can do things like inspect the configuration (e.g. find the modules currently loaded in the kernel with lsmod or see how the network is configured with ifconfig), which may be useful to solve issues later with Android. The machine can be rebooted with the command reboot or powered off with the command poweroff.

 

Installing a Linux distribution to use as a support system

In this guide I explain how to install a GNU/Linux distribution to allow testing your own compiled kernel before using it with Android.  While installing a GNU/Linux distribution is not strictly necessary to get Android running on your Chromebook, having such a system may prove useful for debugging purposes. Unlike Android, a GNU/Linux distribution comes with many useful tools for inspecting the system and interacting with it directly.

 

In this guide we will prepare the SD card to allow a dual boot setup with both Android and another regular GNU+Linux distribution. There are different distributions which can be used for the purpose: Fedora, Bodhi Linux, Debian, Ubuntu.

In this guide I choose Fedora, as the instructions are written down with particular clarity.

 

Follow the instructions given for Fedora, but do partition the SD card differently. Create four partitions: two 16 MB partitions for the kernel, followed by two ext4 partitions: one for Fedora — give it ~4 GB — and one for Android, give it the remaining ~4 GB:

 

  • Partition 1: 16 MB, unformatted, Fedora kernel,
  • Partition 2: 16 MB, unformatted, Android kernel,
  • Partition 3: 4 GB, ext4, Fedora file system,
  • Partition 4: 4 GB, ext4, Android file system,

 

At this point you should be able to boot Fedora. You should have taken the kernel and modules from Chrome-OS and Fedora should be able to use graphics, the wireless and the USB-to-ethernet dongle, if you have one. Next step is compiling the kernel ourselves and making sure Fedora can use our own kernel with our own modules.

 

Getting the sources and compiling the kernel

In order to run Android, you need a kernel which supports some Android specific features (e.g. the binder kernel driver). You then need to compile a kernel which has these features enabled (unlike the kernel which comes with the Chromebook). In this section we explain how to do this.

 

Download the Chromium Linux Kernel:

 

         desktop-pc$ mkdir chromebook
         desktop-pc$ cd chromebook
         desktop-pc$ git clone http://git.chromium.org/chromiumos/third_party/kernel.git \
                       -b chromeos-3.4

 

Where chromebook is a name for the directory where you want to download the sources. Here I use the branch chromeos-3.4.

 

A directory with name kernel should have been created by git. In what follows, I assume:

 

        CHROMEOS=chromebook/kernel

 

If you want to use exactly the same kernel which is used in this guide do as follows (I suggest to do this, unless you know what you are doing):

 

        desktop-pc$ cd $CHROMEOS
        desktop-pc$ git checkout 70301d5c21ee9d422e2621b76239f51f0e008362

 

Now, configure the Kernel:

 

        desktop-pc$ ./chromeos/scripts/prepareconfig chromeos-exynos5

 

This script creates the .config file in the kernel top directory for you. Note that there is a file /boot/config-3.4.0 in the chromebook native filesystem which contains the configuration used to build the native chromebook kernel.

 

Now tweak the configuration and add some features needed for Android. Make sure .config contains the following lines (uncommented):

 

        CONFIG_ANDROID=y
        CONFIG_ANDROID_BINDER_IPC=y
        CONFIG_ANDROID_LOGGER=y
        CONFIG_ANDROID_LOW_MEMORY_KILLER=y
        CONFIG_ASHMEM=y
        CONFIG_FB_TILEBLITTING=y

 

Start compiling the configured kernel:

 

        desktop-pc$ make -j8 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- uImage

 

Notice that you need to have the "arm-linux-gnueabi" version of gcc installed, as explained in the section Install additional software. If you do, then

 

        desktop-pc$ arm-linux-gnueabi-gcc --version

 

Shows something like:

 

        arm-linux-gnueabi-gcc (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3
        Copyright (C) 2011 Free Software Foundation, Inc.
        This is free software; see the source for copying conditions.  There is NO
        warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

 

Let's return to the compilation of the kernel. After giving the make command, you may get messages like,

 

        Android RAM buffer console (ANDROID_RAM_CONSOLE) [N/y] (NEW)

 

Just type ENTER to all of them to use the default values.  Compilation will then take a while.

 

The compilation creates the files Image, zImage and uImage in the directory $CHROMEOS/arch/arm/boot. Run the command below to create the dtb files for your device in the directory $CHROMEOS/arch/arm/boot:

 

        desktop-pc$ make -j8 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- dtbs

 

Next, create a file in $CHROMEOS/arch/kernel.its with the following content:

 

        /dts-v1/;

        / {
            description = "Chrome OS kernel image with one or more FDT blobs";
            #address-cells = <1>;
            images {
           kernel@1{
           description = "kernel";
               data = /incbin/("arm/boot/zImage");
               type = "kernel_noload";
               arch = "arm";
               os = "linux";
               compression = "none";
               load = <0>;
               entry = <0>;
           };
           fdt@1{
               description = "exynos5250-snow.dtb";
               data = /incbin/("arm/boot/exynos5250-snow.dtb");
               type = "flat_dt";
               arch = "arm";
               compression = "none";
               hash@1{
              algo = "sha1";
               };
           };
            };
            configurations {
           default = "conf@1";
           conf@1{
               kernel = "kernel@1";
               fdt = "fdt@1";
           };
            };
        };

 

See also Olof Johansson's post and Siarhei Siamashka's mkimage script.

 

Note that the paths arm/boot/zImage and arm/boot/exynos5250-snow.dtb are pointing to files which — by now — should exist in your filesystem.  Then, do as follows:

 

        desktop-pc$ cd $CHROMEOS/arch
        desktop-pc$ mkimage -f kernel.its kernel.itb

 

A file kernel.itb is produced which contains the kernel in the right form: a FIT kernel image. It should be possible to use kernel.itb as a replacement for what — in the original device — is stored as /boot/vmlinuz-3.4.0.

 

Compiling the kernel modules

Do as follows:

 

        desktop-pc$ cd $CHROMEOS
        desktop-pc$ mkdir $CHROMEOS/../modules
        desktop-pc$ make -j8 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules
        desktop-pc$ make -j8 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- modules_install \
                      INSTALL_MOD_PATH=$CHROMEOS/../modules

 

The directory $CHROMEOS/../modules should be populated with the kernel modules.

     

Using the compiled kernel and modules with Fedora

Insert the SD card on your PC. Here I assume that the partition containing the Fedora filesystem is mounted in /mnt/Fedora. I also assume that you created a user named guest in Fedora. While installing Fedora, if you have followed the instruction correctly, you will have copied the modules from Chrome-OS inside /mnt/Fedora/lib/modules/ and the firmware files inside /mnt/Fedora/lib/firmware/. Do as follows:

 

        desktop-pc$ mv /mnt/Fedora/lib/modules/3.4.0 /mnt/Fedora/lib/modules/original-3.4.0
        desktop-pc$ cp -a $CHROMEOS/../modules/lib/modules/3.4.0 /mnt/Fedora/lib/modules/

 

It is also a good idea to check the permissions for the module files: the kernel may refuse to load a module if it has loose permissions!

 

        desktop-pc$ cd /mnt/Fedora/lib/modules/
        desktop-pc$ find . -type f -print0 | xargs -0 chmod 0644

 

Copy the kernel onto the SD card:

 

        desktop-pc$ cp $CHROMEOS/arch/kernel.itb /mnt/Fedora/home/guest/kernel.itb

 

Create a file in /mnt/Fedora/home/guest/fedora-install-kernel.sh with the following content:

 

        echo "console=tty1 debug verbose root=/dev/mmcblk1p3 lsm.module_locking=0 rootwait rw" > /tmp/config

        vbutil_kernel \
          --pack=/tmp/outkernel \
          --keyblock=/usr/share/vboot/devkeys/kernel.keyblock \
          --version=1 \
          --signprivate=/usr/share/vboot/devkeys/kernel_data_key.vbprivk \
          --config=/tmp/config \
          --vmlinuz=/tmp/inkernel \
          --arch=arm
        dd if=/tmp/outkernel of=/dev/mmcblk1p1
        cgpt add -i 1 -S 1 -T 5 -P 10 -l kern-fedora /dev/mmcblk1
        rm /tmp/outkernel /tmp/inkernel /tmp/config

 

A few things to notice:

 

  • /dev/mmcblk1p3 is the partition in the SD card containing the Fedora filesystem. This will be the case if you followed the instructions above,
  • The kernel option lsm.module_locking=0 tells the kernel to disable the module-locking restrictions when loading the modules,
  • The kernel is installed in the first (dedicated) partition, /dev/mmcblk1p1,

 

Now boot the Chromebook and open a root shell, as explained in the subsection Opening a root shell.  Once you enter the root shell, insert the SD card inside the Chromebook and do as follows:

 

        chromebook$ cd /tmp
        chromebook$ mount /dev/mmcblk1p3 /mnt
        chromebook$ cp /mnt/home/guest/kernel.itb inkernel
        chromebook$ cp /mnt/home/guest/fedora-install-kernel.sh .
        chromebook$ bash fedora-install-kernel.sh

 

The script installs the kernel inside the first partition of the SD card. If you have not done it already while installing Fedora, you will have to run the command below:

 

        chromebook$ crossystem dev_boot_usb=1

 

Now reboot:

 

        chromebook$ reboot

 

When the system comes up, open a shell and try the following:

 

        chromebook$ dmesg | head

 

You should get something like:

 

        dmesg | head
        [    0.000000] Booting Linux on physical CPU 0
        [    0.000000] Initializing cgroup subsys cpu
        [    0.000000] Linux version 3.4.0 (username@hostname) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #3 SMP Fri Mar 22 14:26:00 GMT 2013
        [    0.000000] CPU: ARMv7 Processor [410fc0f4] revision 4 (ARMv7), cr=10c5387d
        [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, PIPT instruction cache
        [    0.000000] Machine: SAMSUNG EXYNOS5 (Flattened Device Tree), model: Google Snow
        [    0.000000] Ramoops: 41f00000 - 41ffffff
        [    0.000000] Memory policy: ECC disabled, Data cache writealloc
        [    0.000000] CPU EXYNOS5250 (id 0x43520010)
        [    0.000000] exynos5_init_clocks: initializing clocks

 

Where username@hostname is replaced with your username and hostname. This proves that you are using your own kernel. Now do check that some modules are being used:

 

        chromebook$ lsmod
        Module                  Size  Used by
        rfcomm                 24189  4 
        uvcvideo               62616  0 
        videobuf2_vmalloc       2941  1 uvcvideo
        mcs7830                 5683  0 
        usbnet                 14225  1 mcs7830
        isl29018                7782  0 
        joydev                  8791  0 
        industrialio           15248  1 isl29018
        btmrvl_sdio             8602  0 
        mwifiex_sdio           14642  0 
        sbs_battery             7117  0 
        mwifiex               109577  1 mwifiex_sdio
        cfg80211              167815  1 mwifiex
        btmrvl                 12715  1 btmrvl_sdio
        bluetooth             178735  22 btmrvl,rfcomm,btmrvl_sdio
        lib80211                3707  1 mwifiex
        uinput                  6922  0

 

Note that the modules usbnet and mcs7830 are the modules loaded to handle the USB-to-ethernet dongle. It is likely that you will not see these modules if your dongle is of a different type (different vendor or model). You should then try to identify which modules are needed for your specific hardware, as this will be useful later.

 

Notice also that in the dmesg log you should get a number of lines like:

 

        [   14.840425] Chromium OS LSM: init_module old-api-locking-ignored module= pid=1 cmdline="/init"

 

These indicate that the kernel module loading restriction is disabled.

 

Downloading and patching the Android filesystem

Get familiar with the Android build mechanisms by reading instructions at http://source.android.com/source/initializing.html, which explains how to setup your desktop machine correctly.  Also, have a look at http://source.android.com/source/downloading.html, which contains instructions explaining how to retrieve the sources (e.g. how to install the repo utility and how to use it). Once you are familiar with these instructions, checkout the Android filesystem with the following:

 

        desktop-pc$ mkdir -p $ANDROID && cd $ANDROID
        desktop-pc$ repo init -u https://android.googlesource.com/platform/manifest -b jb-mr1.1-dev
        desktop-pc$ repo sync

 

Here and in what follows I assume that $ANDROID is the directory where you want to download the Android sources.

 

The sync will take a while. Now apply the patches listed at http://linux-arm.org/LinuxKernel/LinuxAndroidPlatform for the "Jelly Bean MR1" release. Only apply the patches. Do not decompress the tarball given in that page, but instead use the tarball given here. After decompressing this tarball inside the device directory, the new target samsung_xe303c12 is added to the Android build system.

 

Next, you should patch some of the files in the Android filesystem.  Details about how to do this are given in the next sections: Adjusting the screen set up, Getting wpa_supplicant to compile and Adjusting init.rc to load extra modules and use the network.

     

Adjusting the screen set up

You may have to modify the Android sources in order to have Android render graphics properly. The problem is that the hardware in the Samsung Chromebook expects pixels to be in the format BGR, while Android expects to use the RGB pixel format. If this is the case, logcat will report the following in the output (log.txt) of adb logcat -d -f log.txt:

 

        [...]
        W/SurfaceFlinger(  101): no suitable EGLConfig found, trying without EGL_FRAMEBUFFER_TARGET_ANDROID
        W/SurfaceFlinger(  101): no suitable EGLConfig found, trying without EGL_RECORDABLE_ANDROID
        W/SurfaceFlinger(  101): no suitable EGLConfig found, trying with 16-bit color allowed
        E/SurfaceFlinger(  101): no suitable EGLConfig found, giving up
        [...]
      

 

Android can be hacked to use a BGR format. In the file frameworks/native/opengl/libagl/egl.cpp, locate the following code:

 

        static configs_t const gConfigs[] = {
           { config_0_attribute_list, NELEM(config_0_attribute_list) },
           { config_1_attribute_list, NELEM(config_1_attribute_list) },
           { config_2_attribute_list, NELEM(config_2_attribute_list) },
           { config_3_attribute_list, NELEM(config_3_attribute_list) },
           { config_4_attribute_list, NELEM(config_4_attribute_list) },
           { config_5_attribute_list, NELEM(config_5_attribute_list) },
           { config_6_attribute_list, NELEM(config_6_attribute_list) },
           { config_7_attribute_list, NELEM(config_7_attribute_list) },
        };

 

Add a new entry at the end of the table:

 

          { config_8_attribute_list, NELEM(config_8_attribute_list) },

 

Place the code below just before the definition of the gConfigs[] table to define the new pixel format:

 

          /* 32-bit BGRA */
          static config_pair_t const config_8_attribute_list[] = {
             { EGL_BUFFER_SIZE,     32 },
             { EGL_ALPHA_SIZE,       8 },
             { EGL_BLUE_SIZE,        8 },
             { EGL_GREEN_SIZE,       8 },
             { EGL_RED_SIZE,         8 },
             { EGL_DEPTH_SIZE,       0 },
             { EGL_CONFIG_ID,        2 },
             { EGL_NATIVE_VISUAL_ID, GGL_PIXEL_FORMAT_BGRA_8888 },
             { EGL_SURFACE_TYPE,     EGL_WINDOW_BIT|EGL_PBUFFER_BIT|EGL_PIXMAP_BIT },
          };

 

This entry was basically copied from config_4_attribute_list, with the difference that GGL_PIXEL_FORMAT_RGBA_8888 is replaced with GGL_PIXEL_FORMAT_BGRA_8888 (EGL_NATIVE_VISUAL_ID attribute). With this changes, logcat should give:

 

        [...]
        W/SurfaceFlinger(   99): no suitable EGLConfig found, trying without EGL_FRAMEBUFFER_TARGET_ANDROID
        W/SurfaceFlinger(   99): no suitable EGLConfig found, trying without EGL_RECORDABLE_ANDROID
        W/SurfaceFlinger(   99): EGL_SLOW_CONFIG selected!
        [...]

 

This fix was inspired by http://comments.gmane.org/gmane.comp.handhelds.android.porting/521 and https://groups.google.com/forum/?fromgroups=#!topic/android-porting/rSttzZE9SBo.

     

Getting wpa_supplicant to compile

You should patch the file $ANDROID/external/wpa_supplicant_8/wpa_supplicant/src/drivers/driver_nl80211.c, or otherwise you may get a link error while building the Android filesystem. You should comment the line which sets the field driver_cmd, as shown below:

        //.driver_cmd = wpa_driver_nl80211_driver_cmd,

 

This change will disable some features of wpa_supplicant, but should not prevent the wireless from working.

     

Adjusting init.rc to load extra modules and use the network

The Samsung Chromebook does not have an ethernet port. If you need to connect to the internet you can use the built-in wireless. If wireless is not available, however, you may want to use an USB-to-ethernet dongle. In this section, I explain how to set this up.

Android boot can be customised through the init.rc file placed at the top of the Android filesystem. You can find information about the syntax of rc files following the link https://android.googlesource.com/platform/system/core/+/master/init/readme.txt.

 

The init.rc produced for PRODUCT-samsung_xe303c12-eng has been partially tailored for the Samsung Chromebook. In particular, there are a number of modules which are loaded in the kernel using the insmod command. You should add some additional lines for your USB-to-ethernet dongle. The required modules can be determined by inspecting the output of lsmod in Fedora or ChromeOS: boot without the dongle, type lsmod, connect the dongle, wait 5 seconds, retype lsmod and take note of which additional modules were loaded after the dongle was inserted.

 

In my case I had to add two insmod commands:

 

          [...]
              insmod /system/lib/modules/kernel/net/ipv6/netfilter/nf_conntrack_ipv6.ko
              insmod /system/lib/modules/kernel/net/netfilter/xt_mark.ko

          # The two lines below are the ones I had to add for my dongle:
              insmod /system/lib/modules/kernel/drivers/net/usb/usbnet.ko
              insmod /system/lib/modules/kernel/drivers/net/usb/mcs7830.ko
              #wait /nonexistentfile 60

 

The last line is commented, but you may want to uncomment it in order to pause Android for 60 seconds while it loads the modules. This may give you a possibility of seeing if the modules are loaded correctly. Note that getting the network setup right is rather important, as it allows using adb (the Android Debugging Bridge) which — in turn — allows debugging other issues the system may have.

 

To enable the wired ethernet, define a service by adding the following lines to the end of init.rc:

 

        service wired-ethernet /system/bin/netcfg eth0 dhcp
            oneshot

 

Next, tell Android to start the service on boot by adding the following to the end of the "on boot" section:

        start wired-ethernet

 

This line should follow the lines:

 

        class_start core
        class_start main

     

Building the Android filesystem

Build the sources as follows:

 

        desktop-pc$ cd $ANDROID
        desktop-pc$ source build/envsetup.sh
        desktop-pc$ make -j8 PRODUCT-samsung_xe303c12-eng

 

The output of the compilation is placed inside the directory $ANDROID/out/target/product/samsung_xe303c12/.  In particular, this directory contains two directories: root and system. These contain the files which — in the Android device — will be seen at the locations / and /system respectively.

 

Transferring the Android filesystem to the SD card

I here assume the partition of the SD card which is going to contain the Android filesystem has been mounted in /mnt/Android. Copy the Android filesystem you obtained in the section Building the Android filesystem onto the SD card:

 

        desktop-pc$ cp -a $ANDROID/out/target/product/samsung_xe303c12/root/* /mnt/Android
        desktop-pc$ cp -a $ANDROID/out/target/product/samsung_xe303c12/system/* /mnt/Android/system

 

Copy the firmware and modules directory from the Fedora partition:

 

        desktop-pc$ mkdir -p /mnt/Android/system/lib/modules
        desktop-pc$ cp -a /mnt/Fedora/lib/modules/3.4.0/* /mnt/Android/system/lib/modules/
        desktop-pc$ mkdir -p /mnt/Android/system/etc/firmware/
        desktop-pc$ cp -a /mnt/Fedora/lib/firmware/* /mnt/Android/system/etc/firmware/

 

Remember that the firmware directory was taken directly from the Chromebook.

 

You may also have to change the permission of the prop and rc files so that they can be written only by the owner:

 

        desktop-pc$ find /mnt/Android \( -name "*.prop" -o -name "*.rc" \) -print0 | xargs -0 chmod 0644

 

Check that the permissions of the module files are right; they should be, if you followed the instructions. If not:

 

        desktop-pc$ cd /mnt/Android/system/lib/modules
        desktop-pc$ find . -type f -print0 | xargs -0 chmod 0644

 

Now we need to setup the SD card so that Android is booted. Similarly to what was done in section Using the compiled kernel and modules with Fedora, create a file in /mnt/Fedora/home/guest/android-install-kernel.sh with the following content:

 

        echo "console=tty1 debug verbose root=/dev/mmcblk1p4 lsm.module_locking=0 init=/init rootwait rw" > /tmp/config

        vbutil_kernel \
          --pack=/tmp/outkernel \
          --keyblock=/usr/share/vboot/devkeys/kernel.keyblock \
          --version=1 \
          --signprivate=/usr/share/vboot/devkeys/kernel_data_key.vbprivk \
          --config=/tmp/config \
          --vmlinuz=/tmp/inkernel \
          --arch=arm
        dd if=/tmp/outkernel of=/dev/mmcblk1p2
        cgpt add -i 2 -S 1 -T 5 -P 15 -l kern-android /dev/mmcblk1
        rm /tmp/outkernel /tmp/inkernel /tmp/config

 

Make sure that the file kernel.itb is present in the directory /mnt/Fedora/home/guest/; it should be the case if you followed the instructions in section Using the compiled kernel and modules with Fedora.

 

Notice the init=/init option which tells the kernel to pass control to the init executable at the top directory in the Android filesystem. Similarly to what done for Fedora, boot the Chromebook and open a root shell. Once you enter the root shell, insert the SD card inside the Chromebook and do as follows:

 

        chromebook$ cd /tmp
        chromebook$ mount /dev/mmcblk1p3 /mnt
        chromebook$ cp /mnt/home/guest/kernel.itb inkernel
        chromebook$ cp /mnt/home/guest/android-install-kernel.sh .
        chromebook$ bash android-install-kernel.sh

 

The script installs the kernel inside the second partition of the SD card. It gives to this kernel priority 15, which is higher than the priority currently assigned to the Fedora kernel in partition /dev/mmcblk1p3 and is hence selected by the bootloader at boot. This means that, from now on, Android is booted rather than Fedora. In section Switching back to Fedora I explain how to change the priorities so that Fedora is booted again.

 

Next, type reboot to reboot the system and press CTRL+U at the white boot screen to trigger boot from SD card.

 

        chromebook$ reboot

 

Android should come up. It may take several minutes.  Graphics, keyboard, touchpad and wireless should all work.

 

Tips and tricks

I recommend to go to "Settings" and on the left menu scroll down (you can use the down arrow) and select "{} Developer options". On the right there is a checkbox "Stay awake" that you can tick in order to stop the device to go to standby.

 

Keep in mind that to turn off Android you can just press the power button and keep it pressed for a couple of seconds.

 

The wireless can be activated by clicking on the wireless symbol on the toolbox, which also contains other buttons for bluetooth, etc.  Wait a minute and Android should automatically detect the wireless and give you the chance of setting it up. Settings should be remembered in future boots.

 

Logging

Debugging Android can be a nightmare when adb is not available; you cannot easily open a shell or configure the system easily. The first thing to do is then to get the network to work, so that adb can be used. If the network is not working, then you may want to add the following two lines to your init.rc file:

 

        service logstuff /system/bin/logcat -f /mylogstuff
            oneshot

 

You can then start the service with

 

        start logstuff

 

This line starts the Android logging service and redirects its output to the file mylogstuff at the top of the Android filesystem. You can then boot your system, turn it off, take the SD card from the Chromebook and insert it in your PC to inspect the content of the file mylogstuff.

 

Using lines like:

 

        wait /filethatdoesnotexist {number of seconds}

 

Can also be handy to slow down the system while loading the modules so that you can see the output of these commands. Certainly not orthodox nor beautiful, but handy...

 

Checking that ADB works

In order to start the Android Debug Bridge, you can use the command below:

 

        desktop-pc$ adb kill-server
        desktop-pc$ ADBHOST=AAA.BBB.CCC.DDD adb devices

 

Where AAA.BBB.CCC.DDD is the IP address of the Android device. One way of getting the IP of your device (which works well if the device is connected to the same switch/router as your desktop PC) is to do as follows:

 

        desktop-pc$ sudo tcpdump -n -i eth0 'tcp port 54321'

 

This shows on the screen of your PC all the packets arriving-to/departing-from port 54321 on your desktop PC. You can then open the browser in the Android device and use as URL the IP address of your computer. For example, if your desktop PC has IP address (try ifconfig) XXX.YYY.ZZZ.WWW then enter as URL in the Android browser "XXX.YYY.ZZZ.WWW:54321" and press ENTER. tcpdump should show a line like:

 

        15:42:04.188811 IP AAA.BBB.CCC.DDD.51734 > XXX.YYY.ZZZ.WWW.54321: Flags
         [S], seq 3681918437, win 14600, options [mss 1460,sackOK,TS val 290000
         ecr 0,nop,wscale 7], length 0

 

Where AAA.BBB.CCC.DDD is the IP address of your device. You can now use this address as a value for ADBHOSTadb devices should then find your Android device:

 

        desktop-pc$ ADBHOST=... adb devices
        * daemon not running. starting it now on port 5037 *
        * daemon started successfully *
        List of devices attached
        emulator-5554   device

 

You can now use adb. For example,

 

  • adb shell allows to login inside the device,
  • adb shell logcat -d allows to see the log messages,
  • adb help explains how to use adb.

 

Opening a root terminal in Android

Download a terminal emulator app. For example, Jack Palevich's terminal emulator app.  Install it remotely from your host using adb:

 

        desktop-pc$ adb install Term.apk
        desktop-pc$ adb shell # this opens a remote root shell
        adb-shell# cd /system/bin
        adb-shell# cp mksh mysh
        adb-shell# chown root:root mysh
        adb-shell# chmod 4775 mysh
        adb-shell# exit

 

Now open the terminal emulator app from the Chromebook and type /system/bin/mysh. You should now have root priviledges.

 

mysh is a copy of the default shell mksh which belongs to root, can be executed by everybody and has the setuid flag set.  The latter permission setting, in particular, means that whoever executes this executable will be treated as the root user. Remember to delete this file once you do not need it anymore, as it clearly represents a serious security hole (unauthenticated root access).

     

Switching back to Fedora

To switch back to Fedora you can use the cgpt utility.  From the ChromeOS shell, try cgpt show /dev/mmcblk1. This command should show a list of partitions with details about which kernel is installed in which partition, including the boot priorities.  To induce the bootloader to select the Fedora kernel, just type cgpt add -i 2 -P 5 /dev/mmcblk1. This command should reduce the priority of the Android kernel to 5, which is lower than the priority of the Fedora kernel (previously set to 10). On the next reboot, Fedora should come up.

 

Conclusions

This guide should allow you to boot Android on your Chromebook. You should be able to use it for browsing the web and run some apps. There are a number improvements that could be done to the system to provide a better user experience: audio, codecs for playing videos (e.g. YouTube), bluetooth support, tailored menus and configuration, security, etc.  All these improvements, including the release and maintainance of binary images, are outside the scope of this guide and are left to the good will of generous volunteers in the open source community.

 

Further reading

This content was initially posted 14 February 2013 on blogs.arm.com

 

Indoo.rs recently entered into a partnership with ARM, the awesome producer of processor intellectual property (IP). Why is this significant? Let me start from the beginning:

 

We have explained some of the technical challenges in providing real-time, accurate indoor localization in a previous post. Most good indoor localization solutions these days use a hybridized approach (WiFi fingerprinting + inertial navigation seem to be a popular option) to achieve the required accuracy and speed; and a good solution must deal with lots of entropy, but remain fast and accurate. The best way is to use any and all available sensor data, and an inertial navigation model, and then add predictive filtering while conserving device resources, such as battery power. Device manufacturers’ battery allocation for indoor location services is challengingly small.

 

In order to deal with all the entropy our application uses an improved variant of something called a Kalman filter, an algorithm that has been very useful over the past couple of decades in bleeding edge navigation and robotics applications (such as the Mars Rover), where a lot of noisy input is combined with a system’s dynamic models (e.g. an inertial navigation algorithm) to produce an increasingly accurate predictive model of movement and location. The Kalman filter is a set of recursive equations, and, in our case, involves a lot of tricky vector and matrix operations: a typical example has our applying a probability or confidence vector to a set of sensor inputs. This can be taxing on system resources, especially when the key requirement is real-time, accurate location using multi-sensor inputs.

 

This is where ARM comes to the rescue. We really like ARM’s NEON™ SIMD engine (SIMD – Single Instruction, Multiple Data - means a single instruction applied to multiple data points. Imagine a probabilistic operation applied to a large set of sensor input). We really, really like NEON. But this became full blown obsessive love when we started using ARM’s Project Ne10 library, which optimizes matrix and vector operations. Our predictions now go much faster. And our app consumes far less power. There is no trade-off (…no extra RAM requirements, nothing. I swear: we checked the fine print). It’s just amazingly wonderful. And it’s free from this Github repository!

 

Ne10 works like a ‘convenience wrapper’, and handles really useful things like vectorization residuals. It makes much more efficient use of CPU cycles. We see a 5x speed gain on common operations, and over the long run (we are still tuning, but initial results are awesome), we’ll see significant improvement in power consumption at the same time.

 

Previously, we benchmarked the performance of our indoor localization solution against competitors, (and so have Google). We were ~20% better across the board in terms of speed and accuracy before optimizing with Ne10. Now, thanks to ARM, we are significantly extending that lead.

 

Guest Blogger:

erikbovee.jpgErik Bovee, VP Business Development, indoo.rs, Erik has held senior operational and strategic roles since 1999 in a number of telecoms and internet companies, both startups & publicly listed companies. Erik was responsible for VeriSign Mobile Enterprise Services (VMES), a global, mobile messaging aggregation service, in addition to Enterprise Paging, a multi-protocol mediation service for wireless carriers. Prior to joining VMES, Erik was European Managing Director of eMeta Corporation, a provider of access control and digital licensing software for online publishers and financial services.

Are you working on Android and looking for information about Android Partners, Developers, Android Market, and more? If so, welcome to ARM® TechConTM 2011 where members of the ARM ecosystem and the ARM Connected Community® come together to share their vision for the future of technology and discuss the opportunities and challenges associated with today’s connected devices including several of the 175+ members of the Solution Center for Android program. The event will take place on Oct. 25-27 and there are lots of Android activities going on! Here are some more specifics:

 

Android sessions @Software & Systems Design Conference

 

  • When: Wednesday, October 26 & & Thursday, October 27

Where: Santa Clara Convention Center

What:


ARM TechCon Expo Floor Theater

 

  • When: Wednesday, October 26,2:30 PM – 3:15 PM

Where: Santa Clara Convention Center

What: Embedded Android? The next platform, or the next problem? Design teams are looking to Android to slash development effort. But the Android platform comes from a world where all smartphone and tablet hardware looks similar, no deadlines are hard, and best-effort is just fine. Can Android really help in the embedded world of myriad hardware configurations, hard real-time requirements, and mission-critical tasks?

Who: (Moderator) Chris Ciufo, Director of Content, UBM Electronics. (Panelists) Bill Gatliff, Independent Consultant and Contributing Editor ESD Magazine; Dave Kleidermacher, CTO, Green Hills Software; Stephen Olsen, Technical Marketing Engineer, Mentor Embedded

 

  • When: Wednesday, October 26, 3:30 pm – 4:15 pm

Where: Santa Clara Convention Center

What: Teardown & Giveaway: ViewSonic gTablet The Android 2.2-based ViewSonic gTablet emerged last Fall, bringing with it a much-needed 10-inch screen to the rapidly evolving tablet space. In this special teardown, EDN and EETimes Designline editorial director Patrick Mannion will go ‘inside’ the gTablet to expose its hardware underpinnings and design choices, while also examining the pros and cons of the system itself and how it stacks up in the burgeoning Android market.

Who: (Moderator) Patrick Mannion, Director of Content, EDN & Designlines






  • When: Wednesday, October 26, 10:30 am – 6:30 pm; Thursday, October 27, 10:30 am – 4:00 pm

Where: Santa Clara Convention Center

What: ARM TechCon Software and Systems Design Show Floor

Who: Several of the 175+ members of the Solution Center for Android program are exhibiting

How: To attend these events, please register here

Android Anniversary Meeting & Boot camp at TechCon

  • When: Wednesday, October 26, 2pm – 9pm

Where: Santa Clara Convention Center, 2nd Floor Theater

What: The place to be for Google Android developers, users, entrepreneurs, involved in planning and implementing applications as well as those wishing to learn more about the development knowledge or the business opportunities related the technology. During this meeting the group shares projects, opportunities, and how-to’s related to developing for the Android Platform. Experienced developers, newcomers, and people with ideas are all welcome. ARM will be discussing the latest technology and tools for Android developers. Below is a preliminary agenda, which will change as we further develop our strategy.       

How: To attend this event, please register http://www.svandroid...vents/27703211/

 

Schedule: 1:00pm – 3:45 pm

  • Introductory Sessions:
    • Beginning Android Instructions
    • General HTML5 Intro for Android
    • Android Development for Tablet
  • Advanced Sessions by ARM experts
    • Lightening up your App with NEON™
    • Advanced NDK Debug/Profiling with DS-5

 

5:30pm – 6:30pm Break for reception on show floor
6:30 – 8:30pm Celebration and recognition

 

 

Not enough for you? More information about Android activities at ARM TechCon is available here. We look forward to see you in Santa Clara.

 

Are we missing any Android activities that you’d like to see?

 

Jenny Su, Digital Media Manager (APAC), is based in Cambridge. She joined ARM in 2007 with years of experience in the Consumer Electronic Industry. Her primary goal is to work with the local team to drive the reach and engagement across different social media channels.

I was travelling in Japan a few weeks ago attending the Embedded Technology Trade Show. There were two things that impressed me - what little the girls wear in winter and how many partners support Android…And I was pleased to find out that within these Android partners, many of them have ARM solutions too. So I invited them to join the ARM Solution Center for Android (SCA) which is a resource for designers and developers of ARM technology-based products running on Android. Today we have more than 45 Partners of the ARM Connected Community that have joined this initiative since it was launched in November. More than 10 Partners have already posted their Android resources such as whitepapers, videos and solutions slides on our SCA homepage. Below, I’ve highlighted some of my favorites.

 

Below is an Android videos from VisualOn which highlights the performance difference between the default multimedia framework shipped with the Android software stack and VisualOn’s Android solution known as VOME (VisualOn Media Engine) based on an HTC G2 with a Qualcomm ARM11 processor. It shows the user the playback of a music video with default Android multimedia solution highlighting some of the known performance issues. The same music video clip is then playback for the end user with VisualOn’s Android solution (VOME) which results in significant performance improvements while maintaining all the standard JAVA APIs.

 

VisualOn

 

Following is another video from Mistral Solutions that features a demo of Android on Mistral’s new OMAP3 EVM Rev-G Board. This is based on TI’s OMAP3530 Processor with ARM’s Cortex-A8 processor. The demo showcases some of the interesting features of Android and their performance on the OMAP3 EVM:

 

  • Booting Android on the OMAP3 EVM out of an SD/MMC card
  • Android’s support for OpenGL ES 1.0 Demonstrates how the powerful ARM Cortex core on the OMAP3530 enhances the rendering of 3D graphics
  • Web browsing capability on the Android enabled EVM
  • Media Player demo shows a movie encoded in H.263 format; decoded and played using Android’s native codecs, executing on the ARM processor


Mistral

 

 

These Videos are not enough for you? Find more resources on the SCA page at http://www.arm.com/solution-center-android/. We look forward to providing more updates on Android on ARM. Please contact us to promote your Android on ARM solution at connected@arm.com.

 

Jenny Su, Partnership Marketing Specialist, ARM Connected Community, is based in Cambridge. One of her favourite things to do is to work with hundreds of partners around the world and find ways to better help designers have a premium experience on designing with ARM architecture.

This content was initially posted 20 December 2010 on blogs.arm.com


With the recent release of Gingerbread and the number of daily Android on ARM activations up to 300,000 (see James Bruce’s blog), the opportunity for developers has never been better. The tools developers have to work with have also never been better. The Gingerbread update brings a strong focus on enabling the developer to create premium content for a rapidly growing consumer market.

 

Android has long since included a Native Development Kit (NDK) alongside their Software Development Kit (SDK). The NDK enables the creation of native functions in C and/or ARM assembly code. These functions can then be called by Java applications via the Java Native Interface (JNI). A principle software engineer at ARM, under the pen name Dave Butcher, has written a great blog article on the NDK.

 

While the working model of the NDK was intended to enable specialized tasks, what we found from speaking with many Android application developers, is that they would embed their entire application in a native library. They would create only a very small Java wrapper to handle application lifecycle management and to access API’s not available from native code. Two good examples of applications that do this are, the insanely popular Angry Birds franchise from Rovio, and the ever popular Firefox browser from Mozilla.

 

blogentry-0-044751800 1292603726_thumb.jpg

Figure 1 - Mozilla Foundation Firefox for Android


Enhanced native API categories in new NDK

With the recent Android 2.3 (Gingerbread) SDKr8 and NDKr5 releases from Google, a lot has changed! For those experienced developers already off and running with the NDK, Google has introduced a host of API additions available to native code. This will dramatically improve performance and increase the versatility of native code. The enhanced native API categories includes,

 

  • Input and sensor events
  • Audio API based on the Khronos OpenSL ES standard
  • EGL interface, based on Khronos EGL standard
  • Asset manager API for graphics assets


NativeActivity class shifts working model of NDK

However, one of the most dramatic changes is the introduction of the NativeActivity class. This new feature represents a monumental shift in the working model of the NDK. The addition of the NativeActivity class for native code allows application lifecycle management and window management to be performed outside Java. It effectively moves “main()” from Java to C. It means an application can be written entirely in C/C++/ARM assembly code without need to develop Java or JNI bindings. It provides real freedom for developers to choose between Java and C, opening application development on Android to a further superset of the developer community.

 

The new NativeActivity class works not unlike the code that current aggressive users of the NDK have written to move the bulk of their applications into native libraries. It provides a native helper class to bind callbacks to native code. Not only do the methods in NativeActivity derive from the standard Activity class in Java, providing the flexibility inherent in a Java based application, but the class adds a number of unique methods to handle additional tasks, like surfacedChanged(…) and surfaceRedrawNeeded(…). By taking this approach, the application still runs as a Dalvik thread, subject to the same security protections and benefits of the Android application framework model.

 

New helper library simplifies NativeActivity functionality

Going one step further, Google has created a helper library as part of the new NDK. The helper library simplifies exploitation of the NativeActivity functionality, making it even easier for new developers to quickly deploy native only applications in Android. The library is defined in the android_native_app_glue.[h|c] files in the sources directory of the NDK. This helper library defines an android_main(…) function that is to be implemented by the developer. This android_main(…) function is intended to hold the developers main application flow control and is called by the helper library in a unique thread. In this way, the library helps the developer avoid any blocking issues associated with running callback code in the main NativeActivity thread. An instance of an android_app structure, also defined by the helper library, is passed to the android_main(…) function. This structure includes an instance of a nested ALooper structure and enables the app to listen for activity lifecycle events, like “pause” or “resume”, as well as device input events.

 

blogentry-0-090135300 1292603733_thumb.jpg

Figure 2 - Example android_mail function written in native code using NDKr5


NDK will accelerate premium content for tablets

After having played with the new features and the supplied NativeActivity example, I am quite impressed with the new stylings of the revamped NDK. As we can expect the vast majority of Android tablet devices in the New Year to run 2.3 (Gingerbread) or better, I believe the new NDK will play a critical role in accelerating the creation of premium application content targeted at these larger screen devices by simplifying exploitation of the underlying ARM architecture.

 

Check it out yourself. The NDKr5 bundle along with documentations and examples is available from Google here, and additional information on the NativeActivity can be found here. You may also want to checkout many of the other great enhancements in Android 2.3 from the Android developer pages.

 

Seth Bernsen, Strategic Software Alliances Manager, ARM, has recently relocated to Shanghai, China to help regional partners realize the value of the ARM software ecosystem for a range of products from automobiles to set-top-boxes. There is explosive growth of device innovation in China and the AsiaPac region lead by revolutionary ARM based platforms like Android, Chromium OS and Windows Phone, and Seth has a front row seat to the show.

This content was initially posted 28 March 2012 on blogs.arm.com

 

The past three years we have seen explosive growth in the use of the NEON™ SIMD engine by many of our software partners in the open-source community. The engine itself, defined as part of the ARM® Architecture, Version 7 (ARMv7), has shown itself to be extremely flexible and able to accelerate everything from Video Codecs such as VP8 to elements of the emerging HTML5 standard including <svg> and <canvas> filters. From an applications developer viewpoint, all of this acceleration takes place behind the scenes in upstream open source projects that are harvested to build the latest and greatest open source operating systems and frameworks such as Android™ and QT. While it is good to know that the latest version of Android contains lots of goodness that makes it fast and power efficient on ARM, that sometimes isn’t enough when you want to write high performance applications yourself, such as games or augmented reality apps. So back in 2009 we set out to inform developers how to use what we felt were some of the coolest features of ARMv7 through a series of blog posts and seminars. This activity is still ongoing. We received a strong interest in our technical articles on programming NEON but we still didn’t feel we were making things sufficiently straightforward. At the end of the day, while programming an algorithm to make use of NEON can be rewarding in terms of a significant performance improvement or power saving, it isn’t likely to be the primary purpose of your application. As one of my colleagues put it, “I want to write a video game, not a FIR filter!”

 

At the end of 2010, it became clear that what we should do was to create a library of common “useful” functions accelerated by NEON that applications developers could just pick up and use. We had already had success with the creation of OpenMAX DL a library of low-level multimedia kernels or media processing building blocks to accelerate media codecs, but with this new library we wanted to focus our efforts on a broader applications domain. Our goal was to allow applications developers to freely make use of some or all of the functions in the library and if it didn’t meet their specific needs they could at least learn by example from the library and share that knowledge with their peers. We also wanted to give developers the opportunity to contribute their code back into the library. To attain these goals it was clear we needed to release the project as source code under a suitable open source license and so we chose Apache 2. The library’s design also needed to be modular with a minimum of interdependencies so that developers could pick out individual functions if they wanted rather than be required to use the entire library as part of their application. In addition we decided to create non-NEON optimized versions of the functions to ensure API-level portability for the few remaining ARM SoC’s that don’t have NEON today.

 

Early in 2011 we set up an internal project codenamed Snappy to develop the library and initially picked a small set of floating-point, vector arithmetic, and matrix manipulation functions. Our goal was to make the library available as soon as possible and then add more functions as time went by. The first set of functions for the Ne10 library (as it is now officially called) has now been completed and we have made it publicly available on GitHub at https://github.com/projectNe10/Ne10 . The code has been developed natively on Linaro (Ubuntu on ARM) and we have also included a Makefile to build it as an Android OS library under the Android Open Source Project. We hope developers will not only make use of the Ne10 library as is, but also contribute to ProjectNe10 providing:

 

* New functions

* Patches that make use of Ne10 in other Open Source Packages

* Ports of Ne10 to other OS environments

 

Ne10 is just starting out and we hope that you find it a useful grab bag of functionality to improve the performance and power consumption of your applications. We see Project Ne10 as that start of something that can become really useful across a broad applications space. Over the next few months you’ll see more functions being added by ARM and also examples of where it can accelerate applications libraries too. If you would like to contribute to this effort please feel free join the community at www.ProjectNe10.org

 

This blog was originally posted on 22 July 2013 on blogs.arm.com

 

Ne10 is a library created for developers to get most out of ARM/NEON without requiring architecture specific knowledge. Refer to Ne10 Library Getting Started for more details. Ne10 can be compiled for use on many platforms. This article will show how it can be demonstrated on Android and iOS.


Using Ne10 on Android

Library Build

 

After getting Ne10 source code from https://github.com/projectNe10/Ne10, you need specify your configuration to generate library for Android. You need to have cmake the Android NDK installed as noted in the aforementioned guide on getting started. If your development platform is Linux and your Ne10 source directory called $NE10_PATH, then you can configure Ne10 by running following commands:


$cd $NE10PATH
$export ANDROID_NDK=/absolute/path/of/android-ndk
$mkdir build && cd build
$cmake -DCMAKE_TOOLCHAIN_FILE=/path/of/android_config.cmake ..
$make

 

The path of android_config.cmake file is:

$NE10PATH/android/android_config.cmake

There are also two environment variables that need to be specified:

 

  • ANDROID_API_LEVEL: used to specify android api level, default value is: 14
  • ARM_ANDROID_TOOLCHAIN_VERSION: used to specify gcc version, default is: 4.6, gcc version must be >=4.6

 

After the “make” command finishes the NE10 library will be built. You can find the library file in: build/modules/. A static version of NE10 is built by default. You can add the option:

-DNE10_BUILD_SHARED=ON

to cmake to generate a dynamically linked version.

 

Android Demo

 

Once the Ne10 library is build, you can use it in your application development just like other native libraries in Android development. Project Ne10 now provides the source for an Android demo app in the $NE10PATH/android/demo directory. To run it on your Android devices you must build Ne10 library first and then run the command:

 

$make install

 

To install the library in the demo's libs/armeabi directory. The Ne10 demo app uses the Java Native (JNI) interface to call performance test functions built in the dynamic library. Open the Android demo project in your Android app development environment as you would with any other app, i.e. Eclipse with the Android SDK and ADT installed. This demo will compare the performance tests results of both the C and NEON implementations for every functions provided by Ne10. A note about building if you use the NDK build system; JNI components in the Ne10 demo are not built by the Android NDK default build system but by Ne10's build system (cmake). If you choose to build with the NDK build system, you may have to add or generate the JNI code yourself. Also, this demo requires Internet access because of its portable HTML5 interface.


Using Ne10 on iOS

Library Build

 

Before building Ne10 for iOS, you need to install Xcode. At the time of this writing, we use and recommend Version 4.6.3. Ne10 is dependent on the LLVM tool chain version 3.2 or later. Please note that llvm-gcc wouldn't work here. We are assuming that your development platform is Mac OSX and your Ne10 source directory is $NE10PATH. Otherwise, the work is similar to the Android platform. First, configure Ne10 with the following commands:

 

$cd $NE10PATH
$export IOS_DEVELOPER_PATH=/absolute/path/of/ios/developer/path
$mkdir build && cd build
$cmake -DCMAKE_TOOLCHAIN_FILE=/path/of/ios_config.cmake ..
$make

 

If you haven't changed the default install path of Xcode, the IOS_DEVELOPER_PATH should be "/Applications/Xcode.app/Contents/Developer". The default path of ios_config.cmake is $NE10PATH/ios/ios_config.cmake. In other words, if you haven't moved anything the cmake command should be:

 

$cmake -DCMAKE_TOOLCHAIN_FILE=../ios/ios_config.cmake ..

 

iOS Demo

An iOS demo is also provided in Ne10 library under $NE10PATH/ios/NE10Demo. To run the iOS demo on your device, you should run the following command in the build directory where the Nel0 library is built.

 

$make install

Then necessary libraries, including the Ne10 library and the performance test library for Ne10 used by this demo, will be installed into $NE10PATH/ios/NE10Demo/libs/. You can use the Ne10 library just like other C libraries. Open the iOS demo project in Xcode to build and run as any other iOS projects. This demo executes the same performance test library that is run on the Linux and Android platforms and displays the C and NEON execution results on the iOS platform. As with the Android demo, this demo app requires internet connectivity.

yangzhang

Ne10 Library Getting Started

Posted by yangzhang Sep 26, 2013
  • This blog was originally posted on 9 January 2013

 

1 Introduction

ARM® NEON™ technology is a SIMD (single instruction multiple data) architecture extension for the ARM Cortex™-A series processors. It can accelerate multimedia and signal processing algorithms such as video encode/decode, 2D/3D graphics, gaming, audio and speech processing, and image processing. In the past three years, there have been many multimedia applications that have used NEON and are delivering a significantly enhanced user experience. Some application developers may be not familiar with NEON assembly coding so Ne10 library was created to let developers get the most out of ARMv7/NEON without arduous assembly coding.

 

blogentry-107443-068232700 1357756252_thumb.png

 

 

The Ne10 library provides a set of the most commonly used functions that have been heavily optimized. It was first announced in March 2012. The initial set of functionality in the library focuses on matrix/vector algebra and signal processing. Ne10 will evolve over time to encompass more of the compute heavy tasks in a variety of domains such as image processing.

 

This article will introduce how to compile and use Ne10 library

 

2 Ne10 Overview

When you checkout Ne10 source code from https://github.com/projectNe10/Ne10, you will notice a number of directories. The following figure illustrates the use of each directory.

 

blogentry-107443-041563200 1357756263_thumb.png

 

 

3 Environment

First, let’s prepare the whole development environment.

 

3.1 Hardware environment

You need to prepare an ARM Cortex-A series development platform. If no hardware development platform, you can also use emulated environments like Google’s Android Emulator. I’m using the Panda Board (http://pandaboard.org/) with Ubuntu 11.10.

 

Alternatively you can use a traditional desktop environment for cross compiling:

 

3.2 Software environment

For the desktop environment you will also need the following tools:

 

  • CMake (http://www.cmake.org/): the cross-platform, open-source build system
  • Toolchain: I’m using Ubuntu/Linaro gcc 4.6.1. It is also possible to use AOSP tools or Google’s Android NDK Tools.


4 Compiling and using Ne10 library

Now, we can start to download Ne10 source code and compile it.

 

4.1 Compiling Ne10

Ne10 uses CMake to implement the whole build system. The benefit of using CMake is that we could implement cross-platform easily.

 

1) Native compiling (compiling on an ARM platform).

 

For UNIX platforms, use the following commands in a terminal: (Replace $NE10PATH with the directory where the source code is located)

$cd $NE10PATH  $mkdir build  $cd build    $cmake ..  $make 

$cd $NE10PATH 
$mkdir build
$cd build  
$cmake
..
$make 

 

libNE10.a is placed in $NE10PATH /build/modules/ and a test program "NE10_test_static" is placed in $NE10PATH /build/samples/. You can run it. Consider adding -

DNE10_BUILD_SHARED=ON to the cmake call to generate the dynamic library and test program "NE10_test_dynamic".

 

2) Cross compiling (compiling on a non-ARM platform for ARM powered devices)

 

The process of cross-compiling is similar with native compiling. You just need to configure the correct toolchain by creating the config.cmake and placing this file in $NE10PATH/.

set( CMAKE_C_COMPILER arm-linux-gnueabi-gcc )  
set( CMAKE_CXX_COMPILER arm-linux-gnueabi-g++ )
set( CMAKE_ASM_COMPILER arm-linux-gnueabi-as )

find_program
(CMAKE_AR NAMES "arm-linux-gnueabi-ar") 
mark_as_advanced
(CMAKE_AR)  
find_program
(CMAKE_RANLIB NAMES "arm-linux-gnueabi-ranlib")
mark_as_advanced(CMAKE_RANLIB)

 

Then you can use the following commands to compile.

$mkdir build 
$cd build
$cmake
-DCMAKE_TOOLCHAIN_FILE=../config.cmake ..
$make

 

The Ne10 library and test sample are placed in the same directory as native compiling above. You can copy these to the target and run them.

 

Note:

When you run NE10_test_dynamic on the target, you might receive the error: "NE10_test_dynamic: error while loading shared libraries: libNE10_shared.so.10: cannot open shared object file: No such file or directory"

You can run the following command:

$export LD_LIBRARY_PATH=$NE10PATH/build/modules

 

4.2 Using Ne10

After the process above, Ne10 library is ready. I will introduce how to use Ne10 library by a sample.

 

1) Source code

 

You can call Ne10 functions directly as following.

 

     #include <stdio.h>
     #include <stdlib.h>
     #include "NE10.h"   


main
(void)  
{    
      ne10_int32_t i
;    
      ne10_float32_t thesrc
[5];    
      ne10_float32_t thecst
;    
      ne10_float32_t thedst1
[5];     
      ne10_float32_t thedst2
[5];     
     
for (i=0; i<5; i++)    
     
{    
      thesrc
[i] = (ne10_float32_t) rand()/RAND_MAX*5.0f;    
     
}    
      thecst
= (ne10_float32_t) rand()/RAND_MAX*5.0f; 
     
      ne10_addc_float_c
( thedst1 , thesrc, thecst, 5 );    
      ne10_addc_float_neon
( thedst2 , thesrc, thecst, 5 );    
      printf
("==========end=========\n");  
}

 

 

Ne10 also provides the feature of auto detecting NEON hardware. After initialization, the function pointer will point the correct version (C or NEON).

ne10_init( );  
ne10_addc_float
( thedst , thesrc, thecst, 5 );

 

2) Compiling the program

 

Replace $NE10_INC_PATH and $NE10_LIB_PATH with the directories where these files are located

 

 

  • Using static library
$gcc O2 -o sample sample.-I$NE10_INC_PATH -l:$NE10_LIB_PATH/libNE10.a

 

 

  • Using dynamic library
$gcc O2 -o sample sample.c -I$NE10_INC_PATH -l:$NE10_LIB_PATH/libNE10.so -lm

 

Note: When you use dynamic library, and you don't add option "-lm", there will be error "undefined reference to `sqrtf'".

 

Then you can run this sample.

 

5 Conclusion

Ne10 is useful library for applications developers. You can get the most out of NEON without arduous assembly coding. I hope this article could help you know how to use Ne10 to accelerate your applications. If you want to learn more about Ne10, please access http://projectne10.github.com/Ne10/

 

Yang Zhang, Home Software engineer - Home Software Enabling team, ARM, Yang has several years of experience working on projects related to video codec, including H.264/AVC, H.263, MPEG4, MPEG2, VC-1 and AVS. She has a deep understanding of video codec algorithm. Being Home Software Engineer , she specializes in the digital multimedia system for ARM Home. Yang graduated from Zhejiang University with the degree of Master. She is currently based in Shanghai, China.