Android porting guide -- MIPS

引自:http://developer.mips.com/android/android-porting-guide/

Android Porting Guide

 

Before You Get Started!

For building Android, ensure that you have configured your machine as described here.

Hardware Requirements/Assumptions

For a complete description of hardware support in Android, refer to the below URL:

http://source.android.com/porting/index.html

 

Porting Android to a New MIPS SOC

Porting Android to a new MIPS SOC involves:

  1. Building a kernel that has support for the SOC and also contains Android-specific patches.
  2. Building the Android root file system for the MIPS core on the SOC.

The Android root file system has MIPS support and optimizations, and needs to be tuned for the MIPS processor on which it will be run.

Getting the Kernel Ready for Android

There are some kernel patches from Google that are required by the Android framework. There are two approaches to getting a kernel ready for Android: one can port the SOC-specific patches to any of the kernel versions supported by Google, or port the Google patches to the kernel version that has the SOC support.

Here is an example of how we got the Android kernel ready for the MIPS Malta development platform. If you are starting a new porting project we recommend you use Linux kernel version 3.0.8 or later.The simplest way to get a MIPS Android kernel source is by using this GIT repository:

$ git clone git://git.linux-mips.org/pub/scm/linux-mti.git -b dev-android-linux-mti-3.0.8 dev-android-linux-mti-3.0.8

This kernel has an example of configuration (arch/mips/configs/android_example_config) which can be used as a base configuration for Android devices. It gives an idea which platform independent configuration options can be used by Android system.

Instructions for using older versions of the kernel

This section explains how to use older kernels with Android, you should only use this method if your project has very special reasons that it must use an older kernel.

Stable Linux kernels for Malta are available at http://www.linuxmips.org/wiki/Malta_Linux_Repository. Google patches are merged with this generic kernel.

  • Download the GIT repository for MTI linux. This is a Malta-specific kernel and does not contain Android-related patches.
 $ git clone git://git.linux-mips.org/pub/scm/linux-mti.git
  • Checkout the 2.6.29 kernel as shown below.

 

$ cd linux-mti
$ git checkout remotes/origin/linux-mti-2.6.29.4 -b mips-android-2.6.29
  • Add the Google kernel repository to your GIT config. This repository contains kernels which have Android-spe­cific patches.

 

$ git remote add google https://android.googlesource.com/kernel/common.git
  • Fetch the Google kernel repositories.

 

$ git fetch google
  • Merge the Google branch android-2.6.29 with the current branch.

 

$ git merge remotes/google/archive/android-2.6.29
  • Resolve any conflicts and commit your changes.
  • Port an additional patch for the Alarm driver. You could get this patch by downloading the Malta kernel for Android from the GIT URL below. The branch of interest is mips-android-2.6.29 and the commit Id is 6493dbb9d379f067fa0dbe65f10415f15c3ebb0d.

 

git://github.com/MIPS/kernel-linux-mti.git
  • Copy the Malta config (malta-android-el-smvp_defconfig) in arch/mips/configs/ from the above URL to .config. Run make menuconfig and save the config.
  • Set the compiler to be in the path and run.
$ make CROSS_COMPILE=mips-linux-gnu- ARCH=mips

The same procedure can be followed to create a 2.6.32 kernel for Malta. goldfish is the name of the target for the emulator. The kernel for goldfish can be downloaded from the following

URL: git://github.com/MIPS/kernel-common.git

Android Build Process for a New SOC

The Android source ported to MIPS is available through public GIT repositories. To download the Android sources use the below commands.

$ repo init -u git://github.com/MIPS/manifests.git -b <branch>

where <branch> corresponds to one of mips-ics-mr1, mips-gingerbread-r2, mips-froyo, etc.

$ repo sync

The MIPS toolchain for Android is available along with the Android sources in prebuilt/linux-x86/toolchain/ directory.

Before you start building Android for your SOC, you need to know the answer to the following question:

What features does your processor core have?

  1. Floating point support
  2. mips32 or mips32r2
  3. DSP rev1 or DSP rev2
  4. Big-Endian or Little-Endian

Based on your answer, you can identify the best config (e.g., mips32r2dspfp.mk) which matches your processor in build/core/combo/arch/mips/ directory. If there is none, you can create a config which matches your processor capabilities.

The next step is to set the environment variables. You can use the env.sh below as an example.

lraghu@srv6:/dev-mips-froyo$ cat env.bsh
export TARGET_PRODUCT=generic
export TARGET_ARCH=mips
export TARGET_ARCH_VARIANT=mips32r2dspr2
source build/envsetup.sh
setpaths
settitle

The value assigned to TARGET_ARCH_VARIANT is the config chosen in the previous step without the file extension. The value assigned to TARGET_PRODUCT is the name of the target for which Android is being built. If the value specified is anything other than generic, the corresponding target repository should be present in the vendor directory of the Android source. See Sigma source for reference. The steps to download Sigma source is provided under “Android on Sigma” heading.

Once you source env.sh, you can initiate the build process with a make command. If you have a desktop with four cores, you can speed up the build by calling “make –j8”. The Big-Endian build cannot take parallel builds at this point due to dependency issues.

The build creates YAFFS2 images in out/target/product/generic/. The system and userdata images need to be con­verted to ext2 to have them NFS mounted; you can use the “mkext2img” script for this. The mkext2img script is in the tar file which comes with this document. The “syncrootfs” script mounts the ext2 images to directories which can be exported through NFS. This script is also in the tar file.

Android Boot Process

The booting of kernel requires a few boot parameters to be specified. The boot parameters for the Malta kernel can be looked at for this purpose. Environment variables set on Malta:

ker (USER) load tftp://192.168.65.86/raghu/kernel.srec
nfs (USER) go . root=/dev/nfs rw nfsroot=192.168.65.86:/srv/rootfs. android.malta2 init=/init video=matroxfb:init,vesa:0x111
nfs1 (USER) androidboot.hardware=malta ip=dhcp

The boot command used at the YAMON prompt is $ker; $nfs $nfs1. The kernel here is being loaded through tftp, and the rootfs is being mounted through NFS. The ip address specified after “load” is tftp server, and the ip address assigned to nfsroot is the NFS server. The parameters specific to Android are init=/init and androidboot.hard­ware=malta.

After the kernel boot is complete, the init program in the Android root file system gets started. This program parses and executes the scripts init.rc and init.XYZ.rc, where XYZ is the name given by the hardware vendor. The XYZ has to be specified as a value for the kernel parameter “androidboot.hardware”. The init program uses this parameter to know the name of the script it has to start. On a Sigma platform 8654, XYZ is smp86xx. On the goldfish target, XYZ is goldfish. One could load drivers or start services in these scripts. See scripts from Sigma sources for examples. If the SOC is connected to a monitor, one would initially see the Android Boot image and then Android desktop on successful completion of the boot-up.

Android on Qemu

  • Fetch the sources
$ repo init -u git://github.com/MIPS/manifests.git -b <branch>

where <branch> corresponds to one of mips-froyo, mips-gingerbread-r2

$ repo sync

  • Set environment variables TARGET_ARCH_VARIANT which determines the target variant for the emulator. For building emulator in Little Endian without floating point,  set TARGET_ARCH_VARIANT to mips32r2

For building emulator in Little Endian with floating point: set TARGET_ARCH_VARIANT to mips32r2-fp

For building emulator in Big Endian with floating point: set TARGET_ARCH_VARIANT to mips32r2-fp-eb

For building emulator in Big Endian without floating point: set TARGET_ARCH_VARIANT to mips32r2-eb

TARGET_ARCH needs to be set to mips. TARGET_PRODUCT is set to generic for building the emulator.

Below is an example of using env.sh to build for the target with mips32r2 and floating point

support. lraghu@swsrv6:/opt/data/raghu/public$ cat env.sh
export TARGET_ARCH=mips
export TARGET_PRODUCT=generic
export TARGET_ARCH_VARIANT=mips32r2-fp
source build/envsetup.sh
setpaths
settitle
  • $ make

Note: Building the whole tree may take few hours. If you run the build on a multicore or hyper-threaded machine, you may realize significant gain by using the -j make parameter.

$ emulator -shell -show-kernel
  • The above command should boot the emulator and take you to the Android home screen.

Running CTS on Qemu

CTS is a Compatibility Test Suite provided by Google. The CTS runs on a desktop machine and executes test cases directly on attached devices or an emulator. For information on CTS, refer to the following URL:

http://source.android.com/compatibility/overview.html

Building CTS

Run “make cts” at the root of the android tree, to build CTS

Running the Emulator

Before running CTS, the emulator needs to be started. This is the command line needed to start the emulator.

$ mksdcard 256M sdcard.img
$ emulator -shell -show-kernel -sdcard sdcard.img -noaudio

Running CTS

  • Make sure that the android emulator/board is running and ADB is connected to it
  • Only one device or emulator can be connected to the host at a time
  • Run “cts” at the command prompt
  • Type “help” at the command prompt to see a usage styles

Running The Entire Suite

cts> start --plan CTS

Running Specific Test Package

cts> start --plan CTS -p package_name

For example :

cts> start --plan CTS -p android.webkit.cts.WebChromeClientTest

Running Specific Test Within a Test Package

cts> start --plan CTS -p package_name#test_name

For example:

cts> start --plan CTS -p android.webkit.cts.WebChromeClientTest#testOnReceivedIcon

Running only failed test cases from previous run

cts> add --derivedplan new_plan_name -s session_to_extract_results_from -rfail/ pass/timeout

For example:

cts> add --derivedplan only_fails_plan -s 1 -r fail
cts> start --plan only_fails_plan

Extracting/Viewing Results

Inside CTS, results can be viewed using the “ls” command. The Results are stored in out/host/linux-x86/cts/android­cts/repository/results/date_time.zip For example:

out/host/linux-x86/cts/android-cts/repository/results/2010.10.21_11.14.28.zip

Copy & Unzip the results, and open “testResults.xml” in a web browser to view them.

Android on Malta

Hardware requirements:

  1. Malta board with the core running at least at 100 MHz.
  2. PCI graphics card supported by MTI Linux kernel.

To view the Android Desktop on the monitor, Malta requires a PCI graphics card. We have tested and recommend Matrox G450 PCI Graphics card for this purpose. Android is tested with 74Kc daughter card on the Malta board. It is also tested on Malta board with a 1004K on an FPGA with 100 MHz. If the core frequency is less than 100 MHz, we have seen a lot of timeouts preventing the Android to boot properly.

Getting Sources:

$ repo init -u git://github.com/MIPS/manifests.git -b <branch> where <branch> corresponds to one of mips-froyo, mips-gingerbread-r2
$ repo sync
  • Building Froyo: $ source env.bsh (in the tar file)
  • Assuming the core on Malta is 74Kc, TARGET_ARCH_VARIANT is set to mips32r2dspr2:
  • $ make
  • After the build is complete, run mkext2img (Script in the tar .le) from the root of the sources. This script con­verts the system and user images to ext2.
  • Set the ROOTFS value in “syncrootfs” (Script in the tar .le) to a directory where Root File System should be copied. The RFS should be copied to a location exported via nfs mount. Run syncrootfs.
  • Copy init.malta.rc (Script in the tar file) to the root directory of the RFS.
  • Copy init.malta.sh (Script in the tar file) to system/etc/ directory in the RFS.
  • Booting Froyo on Malta
    • Put the kernel (EL kernel is in the tar .le) at a location accessible to tftp from YAMON. Preliminary
    • Set environment on Malta
ker (USER) load tftp://192.168.65.86/raghu/kernel.srec
nfs (USER) go .root=/dev/nfs rw nfsroot=192.168.65.86:/srv/rootfs.
android.malta2 init=/init video=matroxfb:init,vesa:0x111
nfs1 (USER) androidboot.hardware=malta ip=dhcp
  • At the YAMON prompt, run $ker ; $nfs $nfs1. This should take you to Android Screen on Malta.

Caveats: There seem to be Android screen flickering for every move of the mouse.

猜你喜欢

转载自purebel.iteye.com/blog/1667923