Android porting guide - MIPS

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.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.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.

      ?

      //android.googlesource.com/kernel/common.git

      • Fetch the Google kernel repositories.

        ?

        /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.
        ?
        //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
        //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.
        -u git://github.com/MIPS/manifests.git -b <branch>
        where <branch> corresponds to one of mips-ics-mr1,?mips-gingerbread-r2,?mips-froyo, etc.
        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?
        Floating point support
        mips32 or mips32r2
        DSP rev1 or DSP rev2
        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.
        @srv6:/dev-mips-froyo$ cat env.bshexport TARGET_PRODUCT=genericexport TARGET_ARCH=mipsexport TARGET_ARCH_VARIANT=mips32r2dspr2source build/envsetup.shsetpathssettitle
        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:
        (USER) load tftp://192.168.65.86/raghu/kernel.srecnfs (USER) go . root=/dev/nfs rw nfsroot=192.168.65.86:/srv/rootfs.?android.malta2 init=/init video=matroxfb:init,vesa:0x111nfs1 (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
        -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
        @swsrv6:/opt/data/raghu/public$ cat env.shexport TARGET_ARCH=mipsexport TARGET_PRODUCT=genericexport TARGET_ARCH_VARIANT=mips32r2-fpsource build/envsetup.shsetpathssettitle
        $ 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.
        -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.
        -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
        > start --plan CTS
        Running Specific Test Package
        > start --plan CTS -p package_name
        For example :
        > start --plan CTS -p android.webkit.cts.WebChromeClientTest
        Running Specific Test Within a Test Package
        > start --plan CTS -p package_name#test_name
        For example:
        > start --plan CTS -p android.webkit.cts.WebChromeClientTest#testOnReceivedIcon
        Running only failed test cases from previous run
        > add --derivedplan new_plan_name -s session_to_extract_results_from -rfail/?pass/timeout
        For example:
        > add --derivedplan only_fails_plan -s 1 -r failcts> 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:
        /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:
        Malta board with the core running at least at 100 MHz.
        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:
        -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
        (USER) load tftp://192.168.65.86/raghu/kernel.srecnfs (USER) go .root=/dev/nfs rw nfsroot=192.168.65.86:/srv/rootfs.android.malta2 init=/init video=matroxfb:init,vesa:0x111nfs1 (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.