Category: Android

在Linux上开启Core dump来调试

这是一篇原来使用Core dump的记录，整理资料的时候看到的，没有深入的分析，只是用法

基本知识不清楚的话，请在网络上搜寻查阅
http://en.wikipedia.org/wiki/Core_dump
http://en.wikipedia.org/wiki/GNU_Debugger

guohai@KNIGHT:~$ ulimit -c
0
guohai@KNIGHT:~$ ulimit -c unlimited
guohai@KNIGHT:~$ ulimit -c
unlimited
guohai@KNIGHT:~$ ./a.out 
Floating point exception (core dumped)

a.out是需要分析的程序，以上命令就是Linux上使用方法，很简单

更多情况请参考
http://www.cppblog.com/kongque/archive/2011/03/07/141262.aspx

那么在Android上怎么开启呢(首先得有root权限)？

$ adb remount
$ adb shell
root@android:/ # ulimit -c                                                     
unlimited

更改Core dump档案存储的路径(这个存储的路径可以根据需要定制)

root@android:/ # echo "/data/coredump/%p_%e" > /proc/sys/kernel/core_pattern

这样当有native crash存在的时候就会出现对应的Core dump档案了
(有时候执行没有生成Core dump，因为没有/data/coredump文件夹也可能导致无法生成Core dump，大概是没有权限创建)

然后就把档案拷贝到宿主机上，用GDB去载入档案，分析出错的原因

———–EOF———–

Dalvik标记贴

https://android.googlesource.com/platform/dalvik.git
Dalvik

https://android.googlesource.com/platform/dalvik.git/+/master/docs/
Dalvik Docs

http://elinux.org/Android_Dalvik_VM

http://en.wikipedia.org/wiki/Dalvik_(software)

Dalvik, Android’s virtual machine, generates significant debate

DEX文件格式分析

http://hi.baidu.com/seucrcr/item/2b988c570cb63c9208be1778
【翻译】Dalvik——如何控制vm

http://hllvm.group.iteye.com/group/topic/17798
[资料] Dalvik VM的JIT编译器的资料堆积(dumping…work in progress)

开发高响应的Android应用

网络上从来没有间断过对Android为什么这么慢的质疑，硬件配置高，但用起来就是不顺，顿卡，等等各种现象。
https://plus.google.com/100838276097451809262/posts/VDkV9XaJRGS
http://mobile.163.com/12/1123/05/8GVKOL7D0011309K_all.html
http://www.evolife.cn/html/2011/62866.html
可以参阅以上一些文章

除了Android的framework本身的设计因素外，那还有哪些地方值得我们注意的呢？
1、控制好APP的thread，UI响应的事情放到UI thread(也就是默认的main thread)，其他比较耗时或者
跟UI不紧密的操作放到worker thread(这个需要开发者自己设计实现的一个thread，多半是执行和UI没有
什么关系的操作，并最终把需要显示的数据post回给UI thread)，一般它需要快速响应来自UI thread的事
件请求，比如添加一个action(action就是UI thread接收到用户的事件之后需要做的动作)进来，删除某个
action，调整action的优先级。

2、不要让APP的thread爆掉，Java语言当中thread的使用很是简单和方便，正是因为好用所以不要滥用。

3、用户离开APP的时候，不需要再执行的操作就不必要再执行了。因为Android kernal支持完全的多进程，
所以用户离开了可能一些操作还是会占用CPU在执行，这是应当避免的。虽然会增加程序开发的复杂度，但是谁让
你做Android开发呢？

4、适当降低worker thread的优先级，这点很容易被人忽视，默认创建出来的thread的优先级和
main thread是一样，如果不降低它也会跟main thread抢CPU

5、友好的loading提示，这一招是心理战，但是也管用。

当然还有你的程序要写的高效率啦，现在很多人都能抱着能运行就好的心态，bug能不解就不解的心态，
这样怎么可能出高质量的APP的呢？高品质的东西是细细打磨出来的。

PS. 以下一些命令或者工具可能是有帮助的
$ adb shell top -m MAX_PROCESS_COUNT
$ adb shell top -m MAX_THREAD_COUNT -t

例如
$ adb shell top -m 20

Systrace参见
http://developer.android.com/tools/help/systrace.html

Traceview参见
http://developer.android.com/tools/help/traceview.html

Android ExpandableListView放置不同类型的视图

通常的ExpandableListView的group item是一种视图，child item是另外一种视图，同一种item不会出现多种类型的视图，这是默认的设计。但是我们有时候为了实现更为复杂的界面，就需要ExpandableListView支援同一类型的item放置不同类型的视图。其实做法也很简单，就是Adapter需要实现HeterogeneousExpandableList接口的getChildType，getChildTypeCount，getGroupType和getGroupTypeCount这四个方法。因为ExpandableListView为了效率的因素，它的item的视图是reuse的，如果不指定各个item所用视图的类型，ExpandableListView就会默认采用第一个视图，所以如果不实现这四个方法，呈现出来的界面就是错误的，或者程序直接会crash。详细例子可以参见https://github.com/guohai/and-expandable-listview 。效果如下图：
and-expandable-listview
注意点：getChildTypeCount是用到所有不同类型的child item的总数，不管是同一group item下的不同类型，还是不同group item下的不同类型，只要重复就只算一次。getGroupTypeCount也是如此。
getChildType或者getGroupType是返回位置，所以都是从0开始的，不超过最后一个不重复的child或者group item的位置。

Building and Flashing ROM for PandaBoard ES(详细记录版)

之前有写过一篇http://guoh.org/lifelog/2012/06/building-and-flashing-rom-for-pandaboard-es/
那篇只是记录主要的问题，没有把详细过程记录下来，因为我当初也是参考别人的出来了，所以就觉得没有必要把详细的东西记录下来。
很多同学看了那边文章还是弄不出来，于是我答应周末有空的时候再完整做一个这个过程供大家参考。
因为这个板子是裸板，没有什么窗口可以显示当前板子的状态，所以可能这个难住了一些同学。买一个板子配套的扩展板又太贵了，不划算。
所以我建议如果大家实在搞不出来，也不知道原因的话，可以买根Linux下可用的串口线(如果你用Mac OS的话自己酌情处理)，结合PuTTY用着包你瞬间明白烧录ROM其实也不难。
下面开始正文：
一，Build ROM
编译需要X64的操作系统，官方也是这么说的
X32位机器出现如下错误
/lib64/ld-linux-x86-64.so.2: No such file or directory

关于所用源码
官方也说了，pandaboard只支持master的code，所以源码需要是master的

我这里是目前最新的代码，2012-09-08这天的代码

repo init -u https://android.googlesource.com/platform/manifest
repo sync
repo forall -c 'git checkout -b master aosp/master'

安装一个patch(源码不同这个patch就不同哦)
https://developers.google.com/android/nexus/drivers#panda
PandaBoard binaries for Android 4.0.4 (IMM76I to IMM76L)

在X64上开始编译

guohai@KNIGHT:~/dev/src/android/git/panda$ source build/envsetup.sh

including device/asus/grouper/vendorsetup.sh
including device/generic/armv7-a-neon/vendorsetup.sh
including device/generic/armv7-a/vendorsetup.sh
including device/moto/wingray/vendorsetup.sh
including device/samsung/crespo4g/vendorsetup.sh
including device/samsung/crespo/vendorsetup.sh
including device/samsung/maguro/vendorsetup.sh
including device/samsung/toro/vendorsetup.sh
including device/sony/lt26/vendorsetup.sh
including device/ti/panda/vendorsetup.sh
including sdk/bash_completion/adb.bash

guohai@KNIGHT:~/dev/src/android/git/panda$ lunch

You’re building on Linux

Lunch menu… pick a combo:
1. full-eng
2. full_x86-eng
3. vbox_x86-eng
4. full_mips-eng
5. full_grouper-userdebug
6. mini_armv7a_neon-userdebug
7. mini_armv7a-userdebug
8. full_wingray-userdebug
9. full_crespo4g-userdebug
10. full_crespo-userdebug
11. full_maguro-userdebug
12. full_toro-userdebug
13. full_lt26-userdebug
14. full_panda-userdebug

在此我选择
full_panda-userdebug

Which would you like? [full-eng] full_panda-userdebug

============================================
PLATFORM_VERSION_CODENAME=AOSP
PLATFORM_VERSION=4.0.9.99.999.9999.99999
TARGET_PRODUCT=full_panda
TARGET_BUILD_VARIANT=userdebug
TARGET_BUILD_TYPE=release
TARGET_BUILD_APPS=
TARGET_ARCH=arm
TARGET_ARCH_VARIANT=armv7-a-neon
HOST_ARCH=x86
HOST_OS=linux
HOST_OS_EXTRA=Linux-3.0.0-25-generic-x86_64-with-Ubuntu-11.10-oneiric
HOST_BUILD_TYPE=release
BUILD_ID=OPENMASTER
OUT_DIR=out
============================================

我用

guohai@KNIGHT:~/dev/src/android/git/panda$ make -j16

编译花了2个多钟头，偶中途去了趟超市，做了顿饭，整个ROM才编译完成，千万不要傻傻的等哦，找点别的事情干干(当然啦，偶尔过来看看有没有什么意外情况出现build failure是可以的，我已经build很多遍了，所以机器上的编译环境一般没有什么问题，比较放心)

直到build完成，出现
Creating filesystem with parameters:
Size: 268435456
Block size: 4096
Blocks per group: 32768
Inodes per group: 8192
Inode size: 256
Journal blocks: 1024
Label:
Blocks: 65536
Block groups: 2
Reserved block group size: 15
Created filesystem with 970/16384 inodes and 41312/65536 blocks
+ ‘[‘ 0 -ne 0 ‘]’
Install system fs image: out/target/product/panda/system.img
out/target/product/panda/system.img+out/target/product/panda/obj/PACKAGING/recovery_patch_intermediates/recovery_from_boot.p maxsize=274053120 blocksize=4224 total=167387526 reserve=2770944
DroidDoc took 1181 sec. to write docs to out/target/common/docs/doc-comment-check

这样我们需要的ROM就准备好了

二，Flash ROM
1、未插入电源的状态下，拔掉SD卡

插入USB线，串口线(可选)

连接电源

2、执行

guohai@KNIGHT:~/dev/src/android/git/panda/device/ti/panda$ ./usbboot2 ./bootloader.bin

using built-in 2ndstage.bin
waiting for OMAP44xx device…
reading ASIC ID
CHIP: 4440
IDEN: 0000000000000000000000000000000000000000
MPKH: 0000000000000000000000000000000000000000000000000000000000000000
CRC0: 229e85ba
CRC1: 00000000
sending 2ndstage to target… f0030002
waiting for 2ndstage response…
sending image to target…
looks everything is ok…

注：最后这一句”look everything is ok…”是我自己加在omap4boot源码里的，这里使用的usbboot2就是omap4boot编译出来的

Putty会给出如下反馈
见图01-usbboot.png
01-usbboot

最后一句是Fastboot entered…
就表明板子已经进入了fastboot mode

3、插入SD Card

执行

guohai@KNIGHT:~/dev/src/android/git/panda/device/ti/panda$ fastboot oem format

…
OKAY [ 0.656s]
finished. total time: 0.656s

Putty会给出如下反馈
见图02-fastboot-oem-format.png
02-fastboot-oem-format

guohai@KNIGHT:~/dev/src/android/git/panda/device/ti/panda$ fastboot flash xloader ./xloader.bin

sending ‘xloader’ (23 KB)…
OKAY [ 0.007s]
writing ‘xloader’…
OKAY [ 0.321s]
finished. total time: 0.328s

见图03-fastboot-flash-xloader.png
03-fastboot-flash-xloader

guohai@KNIGHT:~/dev/src/android/git/panda/device/ti/panda$ fastboot flash bootloader ./bootloader.bin

sending ‘bootloader’ (161 KB)…
OKAY [ 0.015s]
writing ‘bootloader’…
OKAY [ 0.384s]
finished. total time: 0.399s

见图04-fastboot-flash-bootloader.png
04-fastboot-flash-bootloader

验证板子目前是否处于fastboot mode

guohai@KNIGHT:~/dev/src/android/git/panda/device/ti/panda$ fastboot devices

7024000200000001 fastboot

guohai@KNIGHT:~/dev/src/android/git/panda/device/ti/panda$ fastboot erase cache

erasing ‘cache’…
OKAY [103.063s]
finished. total time: 103.063s

guohai@KNIGHT:~/dev/src/android/git/panda/device/ti/panda$ fastboot flash userdata

sending ‘userdata’ (10428 KB)…
OKAY [ 0.585s]
writing ‘userdata’…
OKAY [ 4.786s]
finished. total time: 5.372s

见图05fastboot-erase-cache_flash-userdata.png
05-fastboot-erase-cache_flash-userdata

guohai@KNIGHT:~/dev/src/android/git/panda/device/ti/panda$ fastboot flashall

——————————————–
Bootloader Version…: U-Boot 1.1.4-gedeced79
Baseband Version…..:
Serial Number……..: 7024000200000001
——————————————–
checking product…
OKAY [ 0.001s]
sending ‘boot’ (3750 KB)…
OKAY [ 0.224s]
writing ‘boot’…
OKAY [ 1.993s]
sending ‘recovery’ (4096 KB)…
OKAY [ 0.237s]
writing ‘recovery’…
OKAY [ 2.113s]
sending ‘system’ (163150 KB)…
OKAY [ 9.107s]
writing ‘system’…
OKAY [ 58.941s]
rebooting…

finished. total time: 72.623s

见图06-flash-all.png 07-flash-all-done.png
06-flash-all
07-flash-all-done

到此完成，板子自动重启
稍等一会儿就出现ANDROID的Logo啦

另外据说PLATFORM_VERSION=4.0.9.99.999.9999.99999
就是Jelly Bean，进去之后发现真的就是Jelly Bean

以前编译ICS也是这一样的步骤，只是代码不同，打的patch不同
要参观多图(非高清)，请移步http://www.flickr.com/photos/46848122@N08/sets/72157631476114706/

读AOSP的Camera源码之录影中拍摄

写Camera这一系列之前，先把Camera主要的概况介绍下(上一篇没有写，这基本都会是一些比较简单而简短的文字记录)

参照 http://developer.android.com/reference/android/hardware/Camera.html

整个拍照的过程Docs上也有写的很清楚
1. open camera
2. get/set parameters
3. set display orientation
4. set surface
5. start preview
6. take picture
7. 拍照之后preview display会自动停止，如果还想继续拍摄就需要再次执行step 5
8. stop preview
9. release camera

这当中有些是必须的，有些不是

学习Camera最好熟悉几块重要的部分代码，这样比较容易理解，因为这是一个硬件和软件结合比较紧密的话题。
大多数时候我们只需要熟悉各个参数，然后将他们通过set parameter传递给hardware层就能完成我们需要的大部分功能。

$ANDROID_SRC_HOME/frameworks/base/core/java/android/hardware/Camera.java

$ANDROID_SRC_HOME/frameworks/base/core/jni/android_hardware_Camera.cpp

$ANDROID_SRC_HOME/frameworks/base/include/camera/Camera.h
$ANDROID_SRC_HOME/frameworks/base/libs/camera/Camera.cpp

这几个文件已经基本可以让我们从APP的层面了解Camera了

Camera最重要的任务就是拍摄出最好的照片，APP的parameter设置下去，发现出来的片子不是我们想要的，这时就要分析是我们参数下错了，还是底层出错了。
这都是我们APP这层需要考虑的。

对于用户来说，最理想的状态就是什么都不用设置，按下拍摄，就能出来最好的片子，这就是为什么卡片机被发明出来，而且还这么受到欢迎，虽然卡片机还是无法做到什么都不设置，就能出来最佳效果的片子。

概况介绍就到这里，很简单。
下面接着说今天的主题，录影中拍摄

如今Samsung和HTC都打出边录边拍的功能，对于APP来说实现这种功能不难，只要机器的芯片支持这个功能，对于APP来说就比较简单了。

这个功能的学名叫做Video Snapshot

Android有这么一个API

    /**
     * Returns true if video snapshot is supported. That is, applications
     * can call {@link #takePicture(Camera.ShutterCallback,
     * Camera.PictureCallback, Camera.PictureCallback, Camera.PictureCallback)}
     * during recording. Applications do not need to call {@link
     * #startPreview()} after taking a picture. The preview will be still
     * active. Other than that, taking a picture during recording is
     * identical to taking a picture normally. All settings and methods
     * related to takePicture work identically. Ex: {@link
     * #getPictureSize()}, {@link #getSupportedPictureSizes()}, {@link
     * #setJpegQuality(int)}, {@link #setRotation(int)}, and etc. The
     * picture will have an EXIF header. {@link #FLASH_MODE_AUTO} and {@link
     * #FLASH_MODE_ON} also still work, but the video will record the flash.
     *
     * Applications can set shutter callback as null to avoid the shutter
     * sound. It is also recommended to set raw picture and post view
     * callbacks to null to avoid the interrupt of preview display.
     *
     * Field-of-view of the recorded video may be different from that of the
     * captured pictures.
     *
     * @return true if video snapshot is supported.
     */
android.hardware.Camera.Parameters.isVideoSnapshotSupported()

这个API的注释把使用过程都说的很清楚，跟普通拍摄没什么两样，需要注意的就是在做Video Snapshot的时候不需要start preview就可以拍摄，因为录影的过程中，整个preview一直是活跃的。不会像普通的拍摄一样，每拍摄一次preview就会停止，需要我们再次start preview。

这项功能的关键在于厂商的芯片的好坏，比如能否在录影过程中的拍摄也支持full resolution等等。

AOSP的Camera当中就通过这行代码来实现这个功能

Log.v(TAG, "Video snapshot start");
mCameraDevice.takePicture(null, null, null, new JpegPictureCallback(loc));

更多可以参见

$ANDROID_SRC_HOME/framework/packages/apps/Camera/src/com/android/camera/VideoCamera.java

很简单不是？

读AOSP的Camera源码之Camera Button启动Camera APP

打算把平时阅读AOSP Camera源码的过程记录下，有些地方没有很精确的去揣摩，所以如果理解有误，烦请大家指出！

Camera Button启动APP，这个比较简单。原理就是当你长按Camera Button的时候，系统会发出一个Broadcast，所以APP只需要注册一个Receiver来接收这个broadcast message就好，当收到这个消息后就去启动APP。

直接用代码说明

Manifest当中有这段配置

<receiver android:name="com.android.camera.CameraButtonIntentReceiver">
    <intent-filter>
        <action android:name="android.intent.action.CAMERA_BUTTON"/>
    </intent-filter>
</receiver>

这个CameraButtonIntentReceiver中会去启动APP，但是它里面有个判断，先判断Hardware可不可以用，如果可以用，就去启动APP，不可以用就什么都不做，直接return掉。好处大概就是防止当你系统运行了很多指令之后，发现HW不可以用，尽早的把错误告诉用户，这是一个良好的程序设计思路。

这里需要关注的就是CameraHolder，它的作用级是保持一个android.hardware.Camera实例，并且记录有多少“用户”打开了android.hardware.Camera这个资源，从它的mUsers属性可以看出。
CameraHolder这个有个小小的特殊的地方，就是如果你有call它的keep方法，它会在你call它的release方法的时候短暂的保持android.hardware.Camera不被释放掉(这里是3秒)，这时如果你再次调用open方法，就会节省一些不必要的开销。

这里开启的过程就不说了，比较简单明了。Receiver中一个startActivity就完成了。

用Eclipse编译AOSP中的App或者把自己的App加入到ROM

正如标题所说，本文分为两个部分。比较熟悉Android工程的同学应该都会，老鸟可以完全略过此文。

一、用Eclipse来编译AOSP(Android Open Source Project)中的某个App
Google好心或者出于商业原因，把一些系统自带的App都开源了，如果我们想研究某个App，但是又不想为此每次去编译整个ROM(因为有些系统自带的App会用到一些Internal或者Hidden的API，无法直接把App的源码导入到Eclipse当中用标准SDK编译通过)，那我们该怎么办呢？
以Camera为例，在Eclipse中直接通过已有源码创建一个工程之后可能会出现如下错误：
android.filterpacks.*中的很多Class找不到
android.hardware.CameraSound这个Class找不到
想想这些找不到的Class应该是存在于某个地方，只是我们通过SDK来编译的时候找不到，否则为什么在整个ROM编译的时候能通过。
所以我们要做的就是把这些“特殊”的Class都引入到Eclipse的编译环境中来。
Google或者动动脑筋在本地机器上搜索搜索缺失的Class的名字，应该能找出来对应的jar包再哪(这些jar包都是我们编译整个ROM的时候生成的，只是没有被添加到发行的SDK里面，所以我们得成功编译整个ROM至少一次，Ubuntu 11.10 X64编译ROM可以参照《在Ubuntu 11.10 X64上编译Android源码》，最好是参照官方说明)，然后引入进来。
在ICS当中，编译Camera需要额外引入的jar包有这么两个：
path/to/aosp/out/target/common/obj/JAVA_LIBRARIES/framework_intermediates/classes.jar
path/to/aosp/out/target/common/obj/JAVA_LIBRARIES/filterfw_intermediates/classes.jar
注意在Order and Export中拉高新加入的这两个Library的顺序，要不然还是会因为某些方法或者属性缺失编译不过。
拉高之后的顺序如下图
aosp-app-eclipse-order-and-export
上图中的Hidden_API就是指的这两个jar包。
这样Camera这个App就应该可以在Eclipse当中编译通过了，当然这里说的只是编译apk，要真正运行可能还需要有so文件，也就是编译native code生成的，可以参考其他的说明，编译native code的方法这里不再赘述。

二、把自己的App加入到ROM build当中
ROM中自带的App都是放在/system/app/当中，so文件是放在/system/lib/当中，那么我们如何把自己的App也加入到系统中呢
很简单，两个步骤
1、把源码放到path/to/aosp/packages/apps当中
比如新加的一个App叫Camera2，即这个路径path/to/aosp/packages/apps/Camera2
2、在path/to/aosp/build/target/product/core.mk中增加自己的App
只需要加到PRODUCT_PACKAGES这个变量中就可以了(名字根据path/to/aosp/packages/apps/Camera2/Android.mk当中的LOCAL_PACKAGE_NAME来定)

完成了这两步之后，再编译整个ROM，就会发现你的App已经增加到系统当中了。

Building and Flashing ROM for PandaBoard ES

按照说明进行烧录自己build的ROM到板子上，具体build的方法参见
http://source.android.com/source/building-kernels.html
http://source.android.com/source/building.html
这个过程比较简单

接着参照
$ANDROID_GIT_HOME/device/ti/panda/README
连接好需要的线缆
RS232串口线不是必须的，但是有了它并通过putty之类的工具很容易的观察板子处于什么状态，如果你特别有经验可以不用这个，一般开始弄的话，有它比较方便
putty操作很简单，选中Serial并设置
line /dev/ttyUSB0/
speed 115200
就可以了

开始烧录的时候就会出现很多的问题了，首先PandaBoard是没有embedded的存储区来存放bootloader这些程序
所以需要把这些基础的程序烧到SD卡上

第一个要用到的工具就是usbboot，从usb载入bootloader，但是不幸的是aosp原生提供的usbboot是X64的，在32位的机器下无法使用

好在有omap4boot

git clone https://github.com/swetland/omap4boot/
cd omap4boot
export PATH=$(TOOL_CHAIN_HOME)/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin:$PATH
把toolchain加入到当前PATH变量中开始build，但是可能会出现SIGNATURE VERIFICATION FAILED
这个时候就需要按照
https://github.com/swetland/omap4boot/issues/7
来解决这个问题

这样就可以让板子进入fastboot模式，详细可以参考
http://android-yfchung.blogspot.com/2011/11/android-40-ice-cream-sandwich-on.html

但是README当中有说到
hold GPIO_121 and press PWRON_RESET
就可以进入fastboot模式，但是我折腾了很久，表示很难进入，还期望哪位高人指点下。
我最终的办法是按照http://android-yfchung.blogspot.com/2011/11/android-40-ice-cream-sandwich-on.html当中说的usbboot就已经进入fastboot模式
也就可以不需要用GPIO_121 + PWRON_RESET

烧录整个ROM的时间会有点长，只要不出错就表示还在执行，所以还是要耐心等待等待。

UPDATE:
2012-09-06
增加文中所提到网页的本站备份文件供无法打开的同学使用
http://guoh.org/lifelog/wp-content/uploads/2012/09/Android-Developing-Note-Android-4_0-Ice-Cream-Sandwich-on-Pandaboard.zip

2013-07-03
PandaBoard按HW key进入bootloader
前提是必须放一张SD卡(fastboot oem format的或者是在PC上format成FAT或者EXT4都可以)到板子上，然后在板子通电的时候按GPIO_121，就像Eric说的那样，时机很重要，我实验的时候就像在通常PC上面进入BIOS一样，多按几次GPIO_121，应该就可以进入fastboot。
这样就应该可以不需要usbboot了。

在PandaBoard ES上运行Android

托同学从帝国弄了块PandaBoard回来，具体配置参见http://www.digikey.com/product-highlights/us/en/texas-instruments-pandaboard/686#tabs-2，这是一块裸板，所以视频连接线，电源，USB线，SD卡等等都得自己配。淘宝上有卖整套配件的，看了下它卖的配件也一般，所以就自己攒了套。

电源：5V2A LinkSYS
HDMI-DVI线：淘宝淘的一个聲寶的线，店家一直说是台湾品牌，虽然台湾有这个牌子，但是我看手里的不像，可能是深圳某家山寨，不过能用就可以了
USB线：板子的口应该是那种移动硬盘上一样的(T型的)，以前想买mini-usb线的，但是买错了，手机不能用，一直搁着，没想到现在用上了
SDHC：Toshiba 8G，C10，在这个板子上跑跑Android应该够了
串口线：还没到货，调试比较方便，可以看到板子的状态
键盘，鼠标都是自己的旧货

先想测测板子能不能跑起来，其实本来是想把自己build的ROM烧录进去的，但是在通过usbboot无法让板子进入fastboot模式，所以还是无法烧ROM，现在还在摸索怎么让板子进入fastboot模式。
鉴于上述原因，所以就暂时用linaro发布的整个镜像先烧到SD卡中，让板子跑起来看看。
制作Android的SD卡的时候，出现些问题，因为我是X86 Ubuntu 10.10，机器的python比较老，parted的模块支持的不是很好，所以需要升级的python的parted模块，没有按照打patch重新安装python的方式，而是直接采用了新的https://launchpad.net/ubuntu/maverick/i386/python-parted/3.4-2ubuntu1.1模块，重新安装了下，简单方便。
制作SD卡的整体方法就是参照http://www.linaro.org/linaro-blog/2011/05/31/linaro-android-build-service-video/，之前你需要参照https://wiki.linaro.org/Platform/Android/ImageInstallation安装一些工具。

SD卡做好之后就插入到板子上，接好所有线，然后加电，正常来说就可以看见小机器人了。但是我进入Launcher的时候报错，这个以后再研究吧，反正基本是可以跑起来了。

后面会把自己build好的ROM烧录到SD卡中。