Porting Android to the PowerPC architecture - Embedded.com

Porting Android to the PowerPC architecture

Android OS is quietly making inroads into embedded industrial applications, moving beyond its ubiquitous presence in mobile communications to the rugged surroundings of heavy industry, which means exposure to water, chemicals, temperature variations, heat and other stress factors. However, a migration to industrial settings is only possible by porting Android to suitably identified hardware components such as PowerPC, which is widely used in embedded and high-performance computing platforms. For technical teams that are working on hardware and embedded engineering projects and would like to port Android on PowerPC, this article offers some basic guidance on porting Android. It is expected that the audience is already familiar with Linux tools and build environment and the Android framework, file system, Linux kernel, and the like.

Although the idea of using touchscreens in industrial settings isn’t new, the porting procedure is far from straightforward when it comes to Android OS. To begin with, there are communication interfaces (I/O) in the PowerPC platform, which has, by and large, no Android support because the OS was primarily designed for smartphones and tablets. In fact, Google has very limited support for this platform.

With one of our recent project successes, eInfochips became the first company in the world to port Android 4.4 to the PowerPC architecture on behalf of an aerospace client that will use it for engine health monitoring (EHM). EHM data is important to aircraft primes and airline companies but usually they don’t have direct access to it. The client, a leading engine manufacturer in aerospace, wanted to democratize this by giving access to engine data through an open platform for them to perform engine health management independently.

This project was implemented on the XPedite 6101 evaluation board from X-ES Inc. which contains the Freescale T1042 processor, 8GB DDR3, 4GB NAND Flash. Since PowerPC-Android conjunction has not been attempted that frequently before, technical information and support on this project is barely available.

The porting was achieved through the following essential steps:

Step-1 : Kernel modifications for XPedite 6101 board and Android platform

Step-2 : Toolchain development for PowerPC platform

Step-3 : Android Open Source Project (AOSP) modifications for PowerPC platform

A more detailed project flow is depicted in Fig.1.

Figure 1: Step-by-step procedure depicting Android porting on PowerPC (Source: eInfochips)  

Generating executables for native codes was done using two primary methods. First, using Android Run Time (ART) and second through Dalvik Virtual Machine (DVM). Both these methods work in two ways: fast interpreter mode and portable mode. Google has developed its own interpreter for ARM, x86 etc for fast interpreter mode, whereas PowerPC interpreter is not readily available.

Now, to support PowerPC architecture, portable mode can be used with open source libffi for interpretation, which was subsequently used in our project. As Google doesn’t provide any technical support for ART portable mode, we chose DVM portable mode. DVM portable mode is available in Android KitKat version 4.4.4 with the support of GCC version 4.7 but for PowerPC, GCC 5.2 was used. Also, Android KitKat uses Linux 3.4 but the XPedite Board BSP patch has been developed for Linux 3.12.19. The final choice was to use Kernel 3.12.19.

Figure 2: A stack overview of applications over Android framework. (Source: eInfochips)  

Step 1: Kernel modifications for XPedite 6101 board and Android platform
The Android platform is based on Linux but with some modifications to standard Linux kernel, along with a few Android-specific drivers. Android kernel has many additional enhancements like alarm driver, Android shared memory driver, binder driver for inter process communication (see Figure 2), power management, low memory killer, kernel debugger and logger. In order to make Android porting a real possibility, all these kernel enhancements have to be essentially added as contributions in the open source community under the GNU Public License. Linux Kernel 3.12.19 was made Android-ready by putting updates at various driver levels.

Figure 3: Some of the changes made to Linux Mainline Kernel to make it Android-ready for mainline community. (Source: eInfochips)  

Initially, mainstream Linux Kernel 3.12.19 was downloaded followed by applying XPedite 6101 Board BSP patch on the Kernel. Further to make it pass as an Android kernel, the Android patch was applied. Later the procedure was followed by installing the toolchain available in the BSP patch package. The uImage was created after building the kernel.

Continue to the next page of this article >>

Step 2: Toolchain development for PowerPC platform
There were mainly two options to develop cross toolchains for PowerPC architecture: build root and crosstool-NG. Out of them, the crosstool-NG toolchain was selected because it gives more options to configure new compilers that are widely used in embedded systems by the developer community. Compilers like gcc and g++ were highly modified for Android. To build AOSP for PowerPC platform, the cross compiler was not available. The X-ES-supplied PowerPC toolchain was insufficient to build the AOSP, because the Android-related changes in gcc were not enabled in it. So, a PowerPC toolchain was necessary that had the requisite changes for Android enablement.

This toolchain contains compiler, assembler, linker, and loader. There were mainly two options to develop the cross toolchain for the PowerPC architecture: Buildroot/Buildroot-NG and Crosstool-NG. The choice was Crosstool-NG, because it has been based on glibc from the start, whereas Buildroot was initially with ucLibc but only recently has added glibc support. Crosstool-NG also gives more control over building of the toolchain.

Step 3: AOSP modifications for PowerPC platform
Android platform is the source code corresponding to the Android distribution running on top of an Android-compatible kernel, which is widely referred to as AOSP (Android Open Source Project). The most essential task here is to modify the compiler so that AOSP modules like Bionic, DVM and CLang can be made ready for the PowerPC platform. The next significant step is to ensure that AOSP code works well. To accomplish this, AOSP source code was tested on ARM platform. XPedite device was invoked in AOSP after confirming the source code for ARM platform.

The debugging was done using GNU Debugger, gdb, which was built in Crosstool-NG, both as native and cross-debugger. It was used in conjunction with QEMU-based PowerPC simulation, using the target functionality of gdb. To facilitate debugging, the AOSP native code was built with debugging information flags turned on, by modifying the generic compilation and linking commands in Android.mk

Instead of glibc, the Bionic module was used as a runtime library that includes C library, Math Library and Run Time Linker, which were modified for the PowerPC platform. Android runtime linker/loader had some changes to support PowerPC for ensuring relocation for position-independent code. Android uses Dalvik Virtual Machine (DVM) similar to JVM in Java. It converts Java classes to Dalvik Executable (.dex). The Dalvik virtual machine is intended to run on a variety of platforms running on the GNU C compiler.

AOSP supports little-endian mode for ARM, MIPs and X86 but PowerPC native execution mode is big endian. The big-endian support provided in AOSP has never been tested thoroughly, thus, there when we attempted to use it, we found a few bugs while executing DALVIK and the framework. Some examples of those bugs include:

  1) Mismatch in function declaration and definition;

  2) Byte swapping for Big Endian mode could not be handled for some of the parameters.

Also, here we found some build time and run time issues for big-endian mode provided in AOSP. In addition to these, the debugging of those issues could only be achieved by enabling logs and verifying data, the method we used here was to flash new file systems every single time.

By following the methods described above, we were able to modify AOSP to support big-endian mode since it is the native mode for PowerPC.

Test strategies and compatibility test suite for AOSP
AOSP supports CTS (compatibility test suite) – The CTS runs on a desktop machine and executes test cases directly on attached devices or an emulator. CTS Verifier provides tests for APIs and functions that cannot be tested on a stationary device without manual input. For PowerPC, we have tested Bionic and Dalvik modules using CTS. Also we have module level unit tests which can be built as part of a file-system and tested on the device.

Apart from PowerPC, there have been a few attempts made by other companies to similarly port Android across many other SoC embedded platforms such as NXP/Freescale ARM-based hardware, with say, the d2plug board (Marvell Semiconductors). It would be interesting to have a relative performance comparison of this porting with our own implementation of Android on PowerPC over XPedite 6101 evaluation board (X-ES Inc).

Android on PowerPC architecture can offer the following benefits to the world of embedded systems and various industries:

  • Since millennials are already familiar with Android OS and programming, the cost to train industrial apprentices in using Android will be low.

  • Combined with PowerPC architecture, reduced energy requirements and heat management, Android on PowerPC can be an effective way to save energy in the long term.

  • Android design provides better power management capabilities while reducing the consumption of energy. Android imposes a smaller energy footprint as it is designed for smaller power architecture demo systems where an SD card is enough to run the whole device.

Considering all the above given advantages offered, porting Android on PowerPC architecture makes a compelling business case that should be explored further. Owing to its versatility, ease of use and performance, Android will likely be deployed across aerospace, industrial automation and automotive applications.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.