之前在 Linux 上为了测试 Intel 核显安装了 Intel 官方闭源的 OpenCL Drivers 库，也解决了 CentOS 6 系统下 C++ 程序的问题，不过换了一台设备之后发现该 OpenCL 库却与 i3-3220 CPU 自带的 HD Graphics 2500 核显不兼容，OpenCL 不能正确加载核显设备。

由于 Intel 闭源的 OpenCL Drivers 现在基本上不再更新了，因此我想着可以试试 Intel 官方的开源 Beignet OpenCL 实现，其 GitHub 项目主页：

https://github.com/intel/beignet/

当然如果你用的是 Intel Gen8、Gen9 等比较新的核显，大可以试试最新开源的 Intel NEO Compute Driver。

Beignet OpenCL 主页介绍编译该项目需要安装 libdrm、libdrm_intel 以及最低 3.6 版本的 LLVM，在 CentOS 6 系统下前面两个倒好解决，直接从 Freedesktop 网站上下载最新版本 libdrm 源代码编译安装即可；LLVM 略显麻烦，本文主要记录 CentOS 6 下 LLVM 升级方法。

Fedora Copr 升级 LLVM

虽然 CentOS 6 这种老系统 EPEL 自带的 LLVM 也只是 3.4.2 版本无法编译 Beignet OpenCL，不过还好 Fedora Copr 库里有人提供了编译好了的新版本 LLVM 包。

例如我找到的一个用的人比较多而且符合 Beignet OpenCL 需求的 LLVM 5.0.0 版本：

https://copr.fedorainfracloud.org/coprs/alonid/llvm-5.0.0/

作者提供了 CentOS 6、CentOS 7 及 Fedora 26 系统下的安装包，我们可以在 CentOS 6 下通过 yum 安装，依赖的包也会自动安装：

[root@cenntos ~]# curl -o /etc/yum.repos.d/alonid-llvm-5.0.0-epel-6.repo https://copr.fedorainfracloud.org/coprs/alonid/llvm-5.0.0/repo/epel-6/alonid-llvm-5.0.0-epel-6.repo
[root@cenntos ~]# yum makecache
[root@cenntos ~]# yum install llvm-5.0.0-devel llvm-5.0.0-static clang-5.0.0-devel

安装完成之后最好修改对应用户的 .bash_profile 文件将 /opt/llvm-5.0.0/bin 目录附加到 PATH 系统环境变量中。

不过可惜的是通过 Copr 安装的 LLVM 5.0.0 版本在 Beignet OpenCL 的链接阶段会报错退出，无法正常编译。

手工编译新版本 LLVM

看来对于 CentOS 6 这种老系统只能手工编译新版本的 LLVM 了，安装官网介绍的步骤来编译的话比较繁琐，不过还好 Linux 下相当流行的 Mesa 3D 图形库默认就是用 CentOS 6 容器来编译的，可以参考 mesa-builds 的提交记录：

Move to using a CentOS6 container

为了省事我就根据 mesa-builds 的 Dockerfile 改了一个自动编译 LLVM 3.9.1 版本的脚本，此脚本会安装 Software Collections 并使用新版本 gcc、g++ 和 Python 编译 LLVM：

yum install -y tar xz bzip2 wget git libtool automake libX11-devel libXext-devel libxcb-devel bison flex centos-release-scl
yum install -y devtoolset-4-gcc devtoolset-4-gcc-c++ python27

mkdir -p /opt

cd /opt && \
  wget https://cmake.org/files/v3.5/cmake-3.5.2-Linux-x86_64.tar.gz && \
  tar -xvf cmake-3.5.2-Linux-x86_64.tar.gz && \
  rm -f cmake-3.5.2-Linux-x86_64.tar.gz

cd /opt && \
  wget http://llvm.org/releases/3.9.1/llvm-3.9.1.src.tar.xz && \
  tar -xvf llvm-3.9.1.src.tar.xz && \
  mkdir llvm-3.9.1.bld && \
  cd llvm-3.9.1.bld && \
  /usr/bin/scl enable devtoolset-4 python27 -- \
    /opt/cmake-3.5.2-Linux-x86_64/bin/cmake \
      -DCMAKE_BUILD_TYPE=Release \
      -DCMAKE_INSTALL_PREFIX=/opt/llvm-3.9.1 \
      -DLLVM_BUILD_LLVM_DYLIB=ON \
      -DLLVM_ENABLE_RTTI=ON \
      -DLLVM_TARGETS_TO_BUILD=X86 \
      -DLLVM_INSTALL_UTILS=ON \
      /opt/llvm-3.9.1.src && \
  /usr/bin/scl enable devtoolset-4 python27 -- make -j16 install

需要注意最后一行的 make 命令的线程数请根据实际硬件配置指定，我用的编译服务器配了 16GB 内存才敢指定 16 个线程。

新版本 LLVM 默认安装在 /opt 目录下，为了方便使用我先修改当前用户的 .bash_profile 文件中的 PATH 环境变量：

[root@cenntos ~]# PATH=$PATH:$HOME/bin:/opt/llvm-3.9.1/bin
[root@cenntos ~]# export PATH

同时增加 LLVM 库文件目录，然后运行 ldconfig 刷新：

[root@cenntos ~]# cat /etc/ld.so.conf.d/llvm-3.9.1.conf
/opt/llvm-3.9.1/lib

编译 Beignet OpenCL

安装并配置好新版本 LLVM 之后，我们就可以按照 GitHub 项目主页上的说明编译 Beignet OpenCL 了，首先安装需要的开发包：

[root@cenntos ~]# yum -y install epel-release
[root@cenntos ~]# yum install -y libdrm-devel libXfixes-devel opencl-headers ocl-icd-devel
[root@cenntos ~]# yum install -y zlib-devel elfutils-libelf-devel gettext ncurses-devel

检出 Beignet 源代码并使用 cmake3 编译：

[root@cenntos ~]# git clone https://github.com/intel/beignet.git
[root@cenntos ~]# cd beignet && mkdir build && cd build
[root@cenntos build]# /opt/cmake-3.5.2-Linux-x86_64/bin/cmake ..
[root@cenntos build]# make -j8

编译成功之后，按照 Beignet 项目说明将库文件和 ICD 等相关文件安装到目标 CentOS 6 系统，然后再运行 clinfo 命令应该就能看到 i3-3220 自带核显设备了。

最近想在 Linux 环境下使用 Intel 核显测试我们的某个程序，该程序是用 C++ 写的，主要调用 OpenCL 库使用 GPU 进行运算。之前我用 AMD 和 NVIDIA 的显卡都测试过没有问题，还以为会比较顺利，结果在程序刚开始调用 clGetPlatformIDs 检测 OpenCL platform 的时候就直接报错退出了。

我的测试环境使用的是 Intel i3-6100 CPU，该处理器自带 Intel HD Graphics 530 核显，操作系统则是 CentOS 6.9 64 位（比较老，为了和使用环境一致），安装的也是 Intel 官方网站上提供的 Intel OpenCL 2.0 Driver（SRB 5.0 版本），具体可以参考 Intel 官网的 OpenCL™ Drivers and Runtimes for Intel® Architecture 介绍。

值得一提的是 Intel OpenCL Driver 安装完成之后，运行 clinfo 命令是可以正常识别到核显的，而且我使用另外一个通过 OpenCL 进行计算的 C 程序来测试又是完全没问题的。

调试分析

初步考虑可能 Intel OpenCL 在此系统和 C++ 程序存在兼容性问题，为此我先写了一个最简单的 C++ 程序来检测 OpenCL platform：

#include <iostream>
#include <string>
#include <CL/cl.h>

void init_cl()
{
	cl_uint plats = 0;
	std::cout << "Begin get OpenCL platform." << std::endl;
	clGetPlatformIDs(0, NULL, &plats);
	std::cout << "OpenCL platforms: " << plats << std::endl;
}

int main(int argc, char **argv)
{
	std::string str = "cl";
	init_cl();
	return 0;
}

使用 g++ 编译该测试程序，编译时启用优化：

[root@localhost ~]# g++ -O2 -o cl cl.cpp -lOpenCL -lstdc++

测试程序使用 AMD 和 NVIDIA 显卡的 OpenCL 库都可以正常检测到 platform，使用 Intel 核显则会遇到下面的错误：

[root@localhost tmp]# ./cl
Begin get OpenCL platform.
*** glibc detected *** ./cl: free(): invalid pointer: 0x0000003de60f32c0 ***
======= Backtrace: =========
/lib64/libc.so.6[0x328cc75716]
/usr/lib64/libstdc++.so.6(_ZNSs6assignERKSs+0x85)[0x3de5e9d565]
/opt/intel/opencl/libigdmcl.so(+0x2040ba)[0x7f75360a00ba]
/opt/intel/opencl/libigdmcl.so(+0x1e6cc2)[0x7f7536082cc2]
/lib64/ld-linux-x86-64.so.2[0x328c40e4ef]
/lib64/ld-linux-x86-64.so.2[0x328c412bf2]
/lib64/ld-linux-x86-64.so.2[0x328c40e106]
/lib64/ld-linux-x86-64.so.2[0x328c41245a]
/lib64/libdl.so.2[0x328c800f66]
/lib64/ld-linux-x86-64.so.2[0x328c40e106]
/lib64/libdl.so.2[0x328c80129c]
/lib64/libdl.so.2(dlopen+0x31)[0x328c800ee1]
/opt/intel/opencl/libigdrcl.so(+0x124bd3)[0x7f7538082bd3]
/opt/intel/opencl/libigdrcl.so(+0xf4890)[0x7f7538052890]
/opt/intel/opencl/libigdrcl.so(+0xf4e26)[0x7f7538052e26]
/opt/intel/opencl/libigdrcl.so(+0xe8982)[0x7f7538046982]
/opt/intel/opencl/libigdrcl.so(+0xd0f3c)[0x7f753802ef3c]
/opt/intel/opencl/libigdrcl.so(clIcdGetPlatformIDsKHR+0x2b)[0x7f753801a0ab]
/opt/intel/opencl/libIntelOpenCL.so(+0x234e4)[0x7f75388c34e4]
/opt/intel/opencl/libIntelOpenCL.so(+0x3f20)[0x7f75388a3f20]
/usr/lib64/libOpenCL.so.1(+0x298b)[0x7f7538f0b98b]
/usr/lib64/libOpenCL.so.1(+0x4907)[0x7f7538f0d907]
/lib64/libpthread.so.0(pthread_once+0x53)[0x7f7538adfe03]
/usr/lib64/libOpenCL.so.1(clGetPlatformIDs+0x11)[0x7f7538f0bf21]
./cl[0x400c6e]
./cl[0x400d31]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x328cc1ec9d]
./cl[0x400b09]
======= Memory map: ========
00400000-00402000 r-xp 00000000 00:11 10291                              /tmp/cl
00601000-00602000 rw-p 00001000 00:11 10291                              /tmp/cl
0179d000-017be000 rw-p 00000000 00:00 0                                  [heap]
328c400000-328c420000 r-xp 00000000 fd:00 7124                           /lib64/ld-2.12.so
328c61f000-328c620000 r--p 0001f000 fd:00 7124                           /lib64/ld-2.12.so
328c620000-328c621000 rw-p 00020000 fd:00 7124                           /lib64/ld-2.12.so
328c621000-328c622000 rw-p 00000000 00:00 0
328c800000-328c802000 r-xp 00000000 fd:00 7116                           /lib64/libdl-2.12.so
328c802000-328ca02000 ---p 00002000 fd:00 7116                           /lib64/libdl-2.12.so
328ca02000-328ca03000 r--p 00002000 fd:00 7116                           /lib64/libdl-2.12.so
328ca03000-328ca04000 rw-p 00003000 fd:00 7116                           /lib64/libdl-2.12.so
328cc00000-328cd87000 r-xp 00000000 fd:00 6933                           /lib64/libc-2.12.so
328cd87000-328cf87000 ---p 00187000 fd:00 6933                           /lib64/libc-2.12.so
328cf87000-328cf8b000 r--p 00187000 fd:00 6933                           /lib64/libc-2.12.so
328cf8b000-328cf8c000 rw-p 0018b000 fd:00 6933                           /lib64/libc-2.12.so
328cf8c000-328cf91000 rw-p 00000000 00:00 0
328d400000-328d483000 r-xp 00000000 fd:00 6818                           /lib64/libm-2.12.so
328d483000-328d682000 ---p 00083000 fd:00 6818                           /lib64/libm-2.12.so
328d682000-328d683000 r--p 00082000 fd:00 6818                           /lib64/libm-2.12.so
328d683000-328d684000 rw-p 00083000 fd:00 6818                           /lib64/libm-2.12.so
328d800000-328d807000 r-xp 00000000 fd:00 7077                           /lib64/librt-2.12.so
328d807000-328da06000 ---p 00007000 fd:00 7077                           /lib64/librt-2.12.so
328da06000-328da07000 r--p 00006000 fd:00 7077                           /lib64/librt-2.12.so
328da07000-328da08000 rw-p 00007000 fd:00 7077                           /lib64/librt-2.12.so
3de5e00000-3de5ee8000 r-xp 00000000 00:11 9623                           /usr/lib64/libstdc++.so.6.0.13
3de5ee8000-3de60e8000 ---p 000e8000 00:11 9623                           /usr/lib64/libstdc++.so.6.0.13
3de60e8000-3de60ef000 r--p 000e8000 00:11 9623                           /usr/lib64/libstdc++.so.6.0.13
3de60ef000-3de60f1000 rw-p 000ef000 00:11 9623                           /usr/lib64/libstdc++.so.6.0.13
3de60f1000-3de6106000 rw-p 00000000 00:00 0
7f7535c86000-7f7535c9b000 r-xp 00000000 fd:00 7143                       /lib64/libz.so.1.2.3
7f7535c9b000-7f7535e9a000 ---p 00015000 fd:00 7143                       /lib64/libz.so.1.2.3
7f7535e9a000-7f7535e9b000 r--p 00014000 fd:00 7143                       /lib64/libz.so.1.2.3
7f7535e9b000-7f7535e9c000 rw-p 00015000 fd:00 7143                       /lib64/libz.so.1.2.3
7f7535e9c000-7f7536b3a000 r-xp 00000000 07:05 10                         /opt/intel/opencl/libigdmcl.so
7f7536b3a000-7f7536d3a000 ---p 00c9e000 07:05 10                         /opt/intel/opencl/libigdmcl.so
7f7536d3a000-7f7536d91000 r--p 00c9e000 07:05 10                         /opt/intel/opencl/libigdmcl.so
7f7536d91000-7f7536d93000 rw-p 00cf5000 07:05 10                         /opt/intel/opencl/libigdmcl.so
7f7536d93000-7f7536d9f000 rw-p 00000000 00:00 0
7f7536d9f000-7f7536da7000 r-xp 00000000 fd:00 13144                      /usr/lib64/libpciaccess.so.0.11.1
7f7536da7000-7f7536fa7000 ---p 00008000 fd:00 13144                      /usr/lib64/libpciaccess.so.0.11.1
7f7536fa7000-7f7536fa8000 rw-p 00008000 fd:00 13144                      /usr/lib64/libpciaccess.so.0.11.1
7f7536fa8000-7f7537351000 r-xp 00000000 07:05 12                         /opt/intel/opencl/libmd.so
7f7537351000-7f7537550000 ---p 003a9000 07:05 12                         /opt/intel/opencl/libmd.so
7f7537550000-7f7537554000 r--p 003a8000 07:05 12                         /opt/intel/opencl/libmd.so
7f7537554000-7f7537556000 rw-p 003ac000 07:05 12                         /opt/intel/opencl/libmd.so
7f7537556000-7f753755d000 rw-p 00000000 00:00 0
7f753755d000-7f753755e000 ---p 00000000 00:00 0
7f753755e000-7f7537f5e000 rw-p 00000000 00:00 0
7f7537f5e000-7f7538152000 r-xp 00000000 07:05 11                         /opt/intel/opencl/libigdrcl.so
7f7538152000-7f7538351000 ---p 001f4000 07:05 11                         /opt/intel/opencl/libigdrcl.so
7f7538351000-7f7538357000 r--p 001f3000 07:05 11                         /opt/intel/opencl/libigdrcl.so
7f7538357000-7f7538894000 rw-p 001f9000 07:05 11                         /opt/intel/opencl/libigdrcl.so
7f7538894000-7f75388a0000 rw-p 00000000 00:00 0
7f75388a0000-7f75388cb000 r-xp 00000000 07:05 2                          /opt/intel/opencl/libIntelOpenCL.so
7f75388cb000-7f7538acb000 ---p 0002b000 07:05 2                          /opt/intel/opencl/libIntelOpenCL.so
7f7538acb000-7f7538acc000 r--p 0002b000 07:05 2                          /opt/intel/opencl/libIntelOpenCL.so
7f7538acc000-7f7538acd000 rw-p 0002c000 07:05 2                          /opt/intel/opencl/libIntelOpenCL.so
7f7538acd000-7f7538ad3000 rw-p 00000000 00:00 0
7f7538ad3000-7f7538aea000 r-xp 00000000 fd:00 7139                       /lib64/libpthread-2.12.so
7f7538aea000-7f7538cea000 ---p 00017000 fd:00 7139                       /lib64/libpthread-2.12.so
7f7538cea000-7f7538ceb000 r--p 00017000 fd:00 7139                       /lib64/libpthread-2.12.so
7f7538ceb000-7f7538cec000 rw-p 00018000 fd:00 7139                       /lib64/libpthread-2.12.so
7f7538cec000-7f7538cf2000 rw-p 00000000 00:00 0
7f7538cf2000-7f7538d08000 r-xp 00000000 fd:00 7140                       /lib64/libgcc_s-4.4.7-20120601.so.1
7f7538d08000-7f7538f07000 ---p 00016000 fd:00 7140                       /lib64/libgcc_s-4.4.7-20120601.so.1
7f7538f07000-7f7538f08000 rw-p 00015000 fd:00 7140                       /lib64/libgcc_s-4.4.7-20120601.so.1
7f7538f08000-7f7538f09000 rw-p 00000000 00:00 0
7f7538f09000-7f7538f10000 r-xp 00000000 fd:00 12875                      /usr/lib64/libOpenCL.so.1
7f7538f10000-7f753910f000 ---p 00007000 fd:00 12875                      /usr/lib64/libOpenCL.so.1
7f753910f000-7f7539110000 rw-p 00006000 fd:00 12875                      /usr/lib64/libOpenCL.so.1
7f7539110000-7f7539111000 rw-p 00000000 00:00 0
7ffe17048000-7ffe17069000 rw-p 00000000 00:00 0                          [stack]
7ffe170de000-7ffe170e1000 r--p 00000000 00:00 0                          [vvar]
7ffe170e1000-7ffe170e3000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Aborted

从错误输出来看是 clGetPlatformIDs 调用过程中 Intel OpenCL Driver 内部就出现问题了，释放了无效的指针导致程序异常退出。

几番修改测试之后我发现两个现象：

1. 如果 g++ 编译时不使用优化选项（-O2 参数去掉或者改为 -O0），则程序可以正常运行；
2. 如果去掉第 15 行的 std::string 变量定义代码，即使保持优化选项开启并链接 libstdc++ 库，程序也可以正常运行。

看起来只要 libstdc++ 库确实被使用了，优化过的 C++ 程序调用 Intel OpenCL 就会出现异常，而由于我们的程序需要开启编译器优化，因此要找到其它解决办法。

解决方法

局部关闭编译器优化

我们可以在整个程序开启编译器优化的情况下，只关闭对调用 OpenCL 库那部分代码的优化。下面是两种局部关闭编译器优化的方法，通过这两种方法修改的测试程序编译之后都可以正常运行。

pragma 指令

把测试程序的代码改成这样：

#pragma GCC push_options
#pragma GCC optimize ("O0")
void init_cl()
{
	...
}
#pragma GCC pop_options

使用 pragma 指令指定 #pragma GCC push_options 和 #pragma GCC pop_options 包起来的这部分代码的编译选项，好处是可以包含多个函数。

__attribute__ 属性

我们也可以直接通过 GNU 编译器的 __attribute__ 编译器属性指定某个函数的优化选项：

void __attribute__((optimize("O0"))) init_cl()

升级 libstdc++ 库

不过有点悲剧的是我们的 C++ 程序通过上面两种方法关闭 OpenCL 调用部分代码的编译器优化之后，运行之后仍然异常退出。另外我把程序挪到 CentOS 7.1 64 位系统上运行则没有任何问题，最终考虑要通过升级 libstdc++ 库（CentOS 6.9 上的是 4.4.7-18 版本）来解决此问题。

本来打算通过手工编译新版本 GCC 来生成新版本的 libstdc++ 库，不过还好搜索之后发现网上已经有现成的 CentOS 6 上的新版本 libstdc++ 了，具体可以参考 SAP 公司提供的 compat-sap-c++ for RedHat 6.7+。

按照 SAP 网站上的说明安装 compat-sap-c++ 包，我们也可以直接替换系统链接：

[root@localhost ~]# curl -O ftp://ftp.pbone.net/mirror/ftp.scientificlinux.org/linux/scientific/6.7/x86_64/updates/fastbugs/compat-sap-c++-4.8.2-16.el6.x86_64.rpm
[root@localhost ~]# rpm -ivh compat-sap-c++-4.8.2-16.el6.x86_64.rpm
[root@localhost ~]# ln -sfn /opt/rh/SAP/lib64/compat-sap-c++.so /usr/lib64/libstdc++.so.6

替换 libstdc++ 为 4.8.2-16 版本之后再运行 OpenCL 测试程序就会发现即使开启编译器优化也没有问题了：

[root@localhost tmp]# ./cl
Begin get OpenCL platform.
OpenCL platforms: 1

看来 Intel 官网上介绍的 Intel OpenCL Driver 只验证了 CentOS 7.2、7.3 及 Ubuntu 16.04 系统下的兼容性还算靠谱的，如果要在老一点的 Linux 系统上使用 Intel OpenCL 还是需要尽量避免碰坑，最后祝大家玩的开心。

由于 Lava XOLO X900 使用的 Intel Atom Z2460 这一 x86 的 CPU，我们就可以做一些改动，让其实现初步的 Ubuntu for Android 效果，而且运行的是 x86 版本的 Ubuntu，相对于 ARM 版本（不能运行私有软件，没有源代码的话啥都干不了）来说实用性要好很多的。

先看看实际的效果图：

现在我在这个 Android 手机里的 Ubuntu 上已经开始正常运行 Skype、Ubuntu One、sopcast 等应用，而且 Ubuntu 和 Android 系统是共存同时运行的，Ubuntu 是运行在外部屏幕上的，对 Android 完全没有影响，不需要 VNC 登录之类的。

Canonical 公司提出的 Ubuntu for Android 请参考这里：

http://www.ubuntu.com/devices/android

这里提到的 Canonical 的 Ubuntu for Android 的要求有：

• 双核手机，内存最少 512MB；
• 支持 secondary frame buffer；
• 支持 USB OTG

对于 XOLO X900 来说，第二点要求 secondary frame buffer 暂时无法满足，因为官方的 kernel 只注册了 /dev/graphics/fb0 一个 frame buffer 设备。但由于支持 USB OTG，我们这里暂时用支持 Linux frame buffer 的外置 USB 显卡来实现。

需要的设备及配件：

• Motorola LapDock 100（做显示器及键盘鼠标输入，同时接 USB 外置显卡，你完全可以用自己的显示器）
• DisplayLink USB 显卡
• USB OTG 线
• HDMI 线

1、准备 x86 Ubuntu 环境：

由于 XOLO X900 只有 16GB 的 ROM 空间，为了速度和扩展考虑，最好可以将 Ubuntu 安装在隐藏未启用的 microSD 插槽上，最好使用 Class 10 的 microSD，这样不会对 Ubuntu 的性能造成影响。

你可以参考这个视频（只有 Youtube 哈）查看如果启用隐藏的 microSD 插槽：

http://www.youtube.com/watch?v=6-FkK7Htohs

下面是找一个合适的 Ubuntu 系统，如果你有时间的话，完全可以用 VMware 安装一个虚拟机到 SD 卡上。如果你像我一样不想浪费时间安装，可以到网上下载现成的 VMware vmdk 映像并直接拷贝到 SD 卡上。

我选择的是下面这个 Lubuntu 12.04 系统，因为使用 LXDE 桌面，速度比较快，这个网站也有完整的 Unity 桌面环境的 Ubuntu 12.04 系统哦：

http://www.trendsigma.net/vmware/lubuntu1204.html

你可能需要另一个 Linux 虚拟机来将 Lubuntu 映像里的所有文件拷贝到 SD 卡里（最好能对 SD 卡进行分区，我是建立了一个 ext4 的分区）。

2、准备需要的 DisplayLink USB 显卡驱动：

由于 XOLO X900 官方 kernel 对 frame buffer 支持并不完整（缺少 defio 等支持），官方 3.0.8 kernel 源代码里的 DisplayLink USB 显卡驱动 udlfb 无法正常编译。

我基于下面的 udlfb 项目的 0.4 版本修改了一个新的可直接用于 XOLO X900 官方 kernel 的 udlfb 驱动（默认代码加载之后无法正常显示图像）：

http://git.plugable.com/gitphp/index.php?p=udlfb

我修改过的 udlfb 0.4 驱动的下载地址：

http://miseal.googlecode.com/files/udlfb-v0.4.tar.bz2

相对默认 0.4 版本的主要改进为：

• 解决在 Linux 3.0.8 中无法正常编译的问题；
• 解决 kzalloc 分配内存失败的问题，以 vmalloc 替代；
• 增加卸载驱动时的释放内存处理；
• 自动根据 EDID 判断显示器分辨率，默认使用 EDID 得到的分辨率；
• 如果 EDID 无法得到合适的分辨率，使用默认 1280x1024 分辨率；
• 增加模块参数，加载模块时可以指定初始分辨率

编译方法请参考之前写的编译 XOLO X900 自定义 kernel 的文章：

https://zohead.com/archives/xolo-x900-kernel/

如果你想直接用我编译好的，请访问此链接下载：

http://miseal.googlecode.com/files/x900-kernel-config-modules.7z

编译好的 udlfb.ko 在解压缩出来的 modules 目录中，建议将 modules 目录拷贝到 /system/lib 目录中。

3、测试 udlfb 驱动是否可用：

通过外置带电源的 USB HUB 接上 DisplayLink USB 显卡（Motorola Lapdock 就是一个带电源的 USB HUB 哈），并将显卡接到外置显示器上，root 过之后，在 shell 中运行 su 然后运行：

insmod /system/lib/modules/udlfb.ko

如果一切正常的话，驱动将自动判断你的显示器分辨率，并在显示器中显示绿屏。

然后运行下面的命令检查 frame buffer 设备是否正常，一般应有正常的设备节点信息输出：

ls -l /dev/graphics/fb1

如果你的显示器不支持 EDID 或者默认的 1280x1024 分辨率不支持，也可以加载驱动时手工指定分辨率，例如：

insmod /system/lib/modules/udlfb.ko init_xres=1024 init_yres=768

上面的命令即将初始分辨率设置为 1024x768。

4、屏蔽 Android 本身对 USB 键盘鼠标的支持：

由于 XOLO X900 默认支持 USB OTG，通过 OTG 接上 USB 键盘鼠标之后，可以直接对 Android 进行操作，而且任何对键盘和鼠标的操作都会解锁手机，这对于我们运行 Ubuntu for Android 是毫无益处的，而且会导致重复的 input event 发到 Android 界面上。因此我们需要屏蔽 Android 本身对 USB 输入设备的支持。

首先接上 USB 键盘和鼠标（通过 USB HUB），并确定是哪个 input 设备，同样在 root 中 su 运行：

ls /dev/input/event*

你会看到很多个 event 设备，一一用下面的命令（把 X 换为具体的设备名）确定到底哪个是你所插上的 USB 键盘和鼠标，cat 之后在键盘上敲键或者移动鼠标，正确的设备将会有输出：

cat /dev/input/eventX

假设确定好鼠标和键盘分别为：/dev/input/event10 和 /dev/input/event11。

然后运行 dmesg 确定 USB 键盘和鼠标的设备名，你可以看到类似这样的输出：

usb 1-1: new high speed USB device number 2 using penwell_otg
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 7 ports detected
usb 1-1.1: new full speed USB device number 3 using penwell_otg
input: Motorola Mobility Motorola HD Dock as /devices/pci0000:00/0000:00:02.3/usb1/1-1/1-1.1/1-1.1:1.0/input/input11
generic-usb 0003:22B8:0938.0003: input,hidraw0: USB HID v1.01 Keyboard [Motorola Mobility Motorola HD Dock] on usb-0000:00:02.3-1.1/input0
usb 1-1.3: new low speed USB device number 4 using penwell_otg
input: BTC USB Cordless Mouse as /devices/pci0000:00/0000:00:02.3/usb1/1-1/1-1.3/1-1.3:1.0/input/input12
generic-usb 0003:1241:0003.0004: input,hidraw1: USB HID v1.10 Keyboard [BTC USB Cordless Mouse] on usb-0000:00:02.3-1.3/input0
input: BTC USB Cordless Mouse as /devices/pci0000:00/0000:00:02.3/usb1/1-1/1-1.3/1-1.3:1.1/input/input13
generic-usb 0003:1241:0003.0005: input,hidraw2: USB HID v1.10 Mouse [BTC USB Cordless Mouse] on usb-0000:00:02.3-1.3/input1
usb 1-1.6: new high speed USB device number 5 using penwell_otg

上面的 Motorola Mobility Motorola HD Dock 和 BTC USB Cordless Mouse 即为 USB 键盘和鼠标设备的设备名，记下这些。

编译 /system/etc/excluded-input-devices.xml 配置文件，将上面的 USB 键盘和鼠标设备名加入进来，然后重启手机，在 USB 输入设备上的操作就不会影响 Android 系统。

例如我的配置文件内容如下：

<?xml version="1.0" encoding="utf-8"?>
<devices>
<device name="Unipoint HID"/>
<device name="RMI4 Unipoint"/>
<device name="Motorola Mobility Motorola HD Dock"/>
<device name="BTC USB Cordless Mouse"/>
</devices>

5、在 Android 中切换到 Ubuntu 环境：

首先 su 运行 shell 创建一个目录作为 Ubuntu 分区的挂载点（这里假设为 /system/sd）：

mount -o remount,rw /dev/block/mmcblk0p2 /system
busybox mkdir -m 777 /system/sd
mount -o remount,ro /dev/block/mmcblk0p2 /system

你可以使用我写好的这个切换到 Ubuntu 的脚本 startubuntu（我这里是挂载了 SD 卡第一个 ext4 分区，请根据需要自行修改）：

http://pastebin.com/raw.php?i=9r21dR7L

我在脚本中将 Android 中的 /mnt/sdcard 目录挂载到了 Ubuntu 里的 /sdcard 目录，Android 系统的 /system 目录挂载到了 /android/system 目录，这样可以很方便的在 Ubuntu 中访问 Android 系统中的数据。

6、准备运行 X 的环境：

假设你已经切换到 Ubuntu，首先安装 DisplayLink 的 X 驱动：

apt-get install xserver-xorg-video-displaylink

然后安装输入模块：

apt-get install xserver-xorg-input-evdev

安装成功之后，修改 /etc/X11/xorg.conf X11 配置文件（Ubuntu 12.04 中没有这个配置文件，需要在 /usr/share/X11/xorg.conf.d 目录中自己增加新的配置文件，我的为：52-displaylink.conf），内容为下面的链接：

http://pastebin.com/raw.php?i=WjcfFWc2

注意请将其中的 input 设备和分辨率改为自己需要的。

7、运行 X - 最终的 Ubuntu for Android：

产生 X 的初始配置文件 /root/.xinitrc：

#!/bin/sh
xrandr -o 0
startlubuntu

第二行的 xrandr 命令是专门为 DisplayLink udlfb 驱动修改的，没有这个的话可能会导致 X 环境中的菜单项不能正确显示。第三行的 startlubuntu 你可以替换成你需要的 X 命令（例如：xinit lxsession）。

然后运行 startx 就可以启动 X 桌面环境了。

某些情况下如果这样运行 startx 还是有问题，可以在 startx 时增加参数：

startx -- :0 vt1

如果这样可以的话表示 X 使用的 VT 不正确，这时你可能需要将 /etc/X11/xinit/xserverrc 改为下面这样以强制指定 X 使用的 VT：

#!/bin/sh
exec /usr/bin/X -nolisten tcp vt1 "$@"

8、总结：

这样实现的 Ubuntu for Android 实际还是有一些不足的：

• 必须要有外置的 USB 显卡太不方便，而且热插拔 USB 显卡会导致 X server 直接挂掉，最好的解决方案是启用 HDMI frame buffer；
• 暂时没有声音输出，可能可以用 USB 声卡，或者将声音输出至手机（能想象的到的丑陋）；
• 不支持通过 USB HUB 进行充电，应该是要修改 kernel 才能支持

本文的内容均为我根据实际使用所写，没有考虑到通用的情况，其中有任何问题欢迎提出指正哦 ^_^

本文目标为 Lava XOLO X900 这一印度咖喱味手机，同样 Intel Atom Z2460 的芯，移植 kernel 的方法和之前的联想 K800 手机基本一致，具体请移步下面的链接：

https://zohead.com/archives/k800-kernel-otg-udisk/

经过确认 XOLO X900 默认也是 Android 4.0.4 ROM，同样 3.0.8 kernel，当然硬件会有所不同，不过 OTG U盘所需要使用的 usb-storage 模块也是和 K800 一样默认没有开启的。

基于基本相同的 kernel source，先使用 Medfield 默认的配置 i386_mfld_defconfig，发现与现有的 kernel 差距比较多，然后用 Moto 的 i386_mfld_moto_defconfig 编译出的模块加载依然 panic。没办法，硬着头皮与实际运行中 kernel 情况进行对比，发现基于默认配置 i386_mfld_defconfig 进行修改是比较好的方法，而且看得出 XOLO 相对联想还是做了一定的优化，去掉了像 CONFIG_DEBUG_KERNEL 之类的很多调试选项，默认允许了 tun 驱动等。另外声卡相关的配置不同的地方也比较多，经过最终改动和确认，编译之后，先已能成功加载并使用之前在 K800 上编译的那些模块。

XOLO X900 的内核模块和配置文件的下载地址：

http://miseal.googlecode.com/files/x900-kernel-config-modules.7z

使用方法和 K800 的基本一致，只是 CIFS 文件系统的使用上有变动：

insmod des_generic.ko
insmod md4.ko
insmod cifs.ko

ASIX Electronics 的 USB 以太网卡的驱动 asix.ko 也已经更新到官方最新的版本（kernel 自带的版本无法使用）。

现已基本可以确认我改动之后的 kernel 和 X900 现有 kernel 的相似性已有 90% 或以上了，不过由于 X900 手机悲剧滴将 bootloader 给锁了，无法刷未签名的 kernel，暂时还没有太好的办法来直接替换 kernel 进行测试哦。

另外有一些需要说明的地方：

1. XOLO X900 现有 kernel 中支持 Kineto GAN 虚拟网卡驱动（支持 VOIP 网络电话的），Moto Razr i 公开的 kernel source 中却并没有这个的支持，为此我手工增加了这个的驱动（上面下载的 kernel configuration 中也有的）；
2. 目前还有 apwr3_0、pax、sep3_7 这三个非免费开源的内核模块没有源代码，暂时也没有办法在网上找到，不过从现在来看，似乎 X900 实际运行时也未使用这三个模块。

同样我不对任何导致你的手机 panic 挂掉的后果承担责任，有任何问题欢迎提出指正哦 ^_^

之前入手联想 K800 这款使用 Intel x86 CPU 的手机时考虑过一个问题，就是 Android x86 对于已有的 Android 程序的兼容问题问题，特别是对于一些使用了 native ARM 代码的程序（以游戏居多），因为不可能原来所有的程序都可以及时更新来支持 x86 的 Android 手机（本来就很小众）。在我的想法中，Intel x86 环境下应该不可能直接运行 native 的 ARM 二进制代码（虚拟机那种不考虑），不过考虑到平时玩使用 native ARM 代码的游戏也不多，就没有在意。

我们先来看一个典型的使用了 native ARM library 的 Android 程序：《Bejeweled 2》，也就是大家在电脑上很熟悉的《宝石迷阵2》游戏的 Android 版本，查看 apk 安装文件里的内容，可以明显发现其使用了 ARM EABI 的动态库：

但我在 K800 上安装此游戏，完全可以正常运行并使用，只是似乎没有在 ARM Android 手机上运行的那么顺畅。

这就比较疑惑了，接下来那就进一步验证一下，将之前静态编译的一个 ARM 可执行程序拷到手机，在终端中运行，竟然也可以正常运行，我们看看这个 ARM 可执行程序的格式：

[root@fedora ~]# file /mnt/iptables
/mnt/iptables: ELF 32-bit LSB executable, ARM, version 1 (SYSV), for GNU/Linux 2.6.14, statically linked, for GNU/Linux 2.6.14, stripped

经过一番搜寻之后，发现原来 Android x86 4.0 版本之后已经开始支持对 native ARM 的仿真，这对于之前用处似乎一直不是很大的 Android x86 来说绝对可以算是相当大的进步。

联想 K800 使用的 CPU 是 Intel Atom Z2460，基于 Intel Medfield 平台，尽管 Z2460 是一款使用 x86 指令集的 CPU，但可以兼容运行大部分带有 native ARM 代码的应用，关键就是靠 Intel 并未公开发表的技术 ARM binary code translator，而且 binary translator 对于应用程序来说是透明的，一般不需要做任何特殊的改动。

在 Android x86 上 Google 修改了 dalvik 虚拟机的加载 native code 的函数（修改 libdvm，增加 libdvm_houdini.so），通过 Intel ARM to Atom binary translator 实现 JNI 调用。Android x86 中引入了 libhoudini.so 来做这件事情，通过查看 K800 的根文件系统，我们可以看到除了 /system/lib 下的标准的 x86 的动态库文件之外，新增了 /system/lib/libhoudini.so 库，另外 /system/lib/arm 目录下还有很多 ARM 版本的库文件。

下面是我在 K800 上运行一个 native ARM 程序时的进程输出：

root      9754  1     79064  3888  c136b03f 40060345 S /system/bin/houdini
root      10365 8204  1468   496   00000000 b76dca06 R ps

上面看到的 /system/bin/houdini 进程即为在 Android x86 上运行的 native ARM 程序的表现形式。

从现在在 K800 手机上实际的测试情况来看，在 K800 上运行使用 native ARM 的 Android 似乎都还比较顺畅，像愤怒的小鸟就可以很顺畅的运行，这和现在 K800 用的 Android 4.0.4 ROM 也有关系，相对于不支持 native ARM 的 Android 2.3.7，游戏的兼容性是有相当大的改善的。另外很有可能 Intel Medfield 平台硬件上就有对 ARM binary translator 的加速功能。

当然这种二进制的转换必然会有性能上的损失，无法和 x86 原生程序相比，因此越来越多的 Android 程序也开始集成了 x86 版本的程序和库文件，来看看最新版本的水果忍者 apk 安装程序中的库文件列表，就可以看到 x86 版本：

有关 Android x86 运行 native ARM 程序的介绍：

http://www.anandtech.com/show/5770/lava-xolo-x900-review-the-first-intel-medfield-phone/3

Android x86 下运行环境的搭建：

http://www.buildroid.org/blog/?p=198

这几天专门入了个二手的联想 K800 的 Android 手机，看中的就是它是 x86 的 CPU，其采用 Intel Medfield Atom 平台，具体处理器型号为 Intel Atom Z2460，用的 Android 4.0.4 系统，具体其它配置我就不多说的。

优点：

• 使用 Intel x86 CPU，方便程序的移植（相对 ARM 而言）；
• 4.5 寸的 1280 x 720 的 IPS 高清屏幕，主要分辨率够给力；
• 支持 USB OTG；
• 支持 MHL 视频输出（缺点也在这，下面再说）；
• 耗电没想象中的那么严重；
• 使用的 Intel Atom Z2460 CPU 支持 EM64T 64 位指令；
• 使用的 Intel Atom Z2460 CPU 支持 Intel VT-x 虚拟化技术（不过这个好像在 Android 4.1 中用处才发挥出来，暂时也用不上）；
• 很便宜。

缺点：

• 没有单独的 HDMI 接口，视频输出需要占用 MicroUSB，OTG 与 MHL 无法同时使用；
• OTG 不支持 U 盘（也是本文要解决的）；
• 恶心的乐 Phone，联想没有公开 kernel 源代码。

上面说的缺点里，最后一条不公开 kernel source 是联想一贯悠久的恶劣传统，也是我最忍受不了的一条。

一番努力搜寻之后，我终于找到了曲线救国的神主：Motorola。对，就是他，虽然摩托似乎从来就没有开放的基因，但被 Google 收购之后，摩托在其推出的 Intel 手机 Moto RAZR i 上终于有良心了一把：公布了 Moto RAZR i 的 kernel source。由于 Moto RAZR i 与联想 K800 同样采用 Intel Medfield 平台，因此我就赌了一把其 kernel source 会有很大程度上的相似性，结果很幸运小成功了。

1、获取源码：

首先在 SourceForge 上抓取 Moto RAZR i 的 kernel source：

http://sourceforge.net/projects/razr-i.motorola/files/

一共 100 多MB，咱先解压，打开 Makefile，确定 kernel version 是 3.0.8 版本。

给联想 K800 root，装 adb 驱动，用 adb shell 连上看，运行 uname -a 查看 K800 手机的 kernel version 是 3.0.8-g37de913，啊哈，除了后缀版本一致。然后尝试读取 /proc/config.gz，无奈联想又是没有把 kernel configuration 给导出，找不到 /proc/config.gz 文件，没办法，只能自己根据当前手机 kernel 判断 K800 当前的 kernel configuration 了。

运行：egrep '(vmx|svm)' /proc/cpuinfo，确定 CPU 支持 Intel VT-x 虚拟化技术，有点小兴奋。

2、准备编译环境：

接着在手机上查看 /proc/version，确定联想 K800 kernel 使用的 gcc 版本为 4.3.3，刚好与 Moto 介绍的一致。然后使用 git clone 从下面的地址得到编译 kernel 的 android x86 toolchain：

https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/x86/i686-android-linux-4.4.3/

需要注意 git 得到的代码中默认已经把 gcc 4.3.3 给移除了，不过运行 git log 可以看到之前的提交日志里是有的，那好办，运行下面命令回滚到最新可用的版本：

git checkout 286506f01f8ca64d6eb0e33bafb475a5cf10ff37

终于有了编译 kernel 的正确环境了（不是完整开发环境哈）。

3、编译 kernel：

Moto 提供的 kernel source 中有几个适合 Intel Medfield 平台的 config 文件，SourceForge 网站上推荐使用 i386_mfld_moto_defconfig，编译时指定 CROSS_COMPILE，但我实际编译之后的模块加载会 kernel panic。好吧，我来尝试应该是 Intel 原始推荐的 i386_mfld_defconfig 默认配置，无法编译通过，排除原因，发现 i386_mfld_defconfig 中启用的几个选项在 K800 中并没有开启，遂决定去掉，同时去掉了 Moto 特有的加密模块。

修改配置之后，能编译了，但编译到 android USB gadget 代码时又有报错，查看代码，发现 Moto 对 android USB gadget 代码做了特殊改动，好吧，这我暂时不需要修改，根据 Moto 增加的 define 修改 drivers/usb/gadget/android.c，去掉 Moto 特有的改动，尽量使代码默认 Intel 原生（看来联想对 Intel 的代码改动很少，这是个好处，嘿嘿，下面也有悲催的地方），再次开始编译。

这次终于比较顺利了，能编译到链接 kernel image 的地方了，但又有报错，这时就不管了，因为我压根就不指望这个编译出来的 zImage 能直接用在联想 K800 手机上，而且联想也没开放制作其 boot image 的工具和方法，就算 zImage 有了也不知道怎么刷到手机上。

接下来编译 kernel modules，这步比较顺利，我把 CIFS、USB Mass Storage（包括 scsi disk 支持）、usbnet、usb serial converter、tun 等需要的模块都选中，都正确编译出来了。

4、修改调试：

拿到手机上加载 cifs.ko，正常，/proc/filesystems 中已经有了 cifs，但挂载文件系统时发现 dmesg 里有 out of memory 报错，一会就 kernel panic 了。

强制重启手机，这时才发现 cifs.ko 大小有 3MB 多，明显太大，查看 config 发现默认启用了 debug kernel，Moto 的默认配置中未启用，不得不说联想真是够懒的，这个影响性能的东西竟然木有去掉。

本来想禁用 CONFIG_DEBUG_KERNEL，但无意发现手机里有 /proc/sched_debug 调度器调试文件，这个是依赖 CONFIG_DEBUG_KERNEL 的，说明 debug kernel 必须启用了。最后发现 i386_mfld_defconfig 中默认的 SLUB debug 等几个选项在联想 K800 kernel 中是关闭的，保存 config 重新编译。由于启用了 debug kernel，编译出来的模块不可避免的都很大，不得不用 strip --strip-unneeded *.ko 来去除没用的东西。

再次拷贝到手机上，insmod cifs.ko，正常，mount 挂载 Windows 共享目录终于不 panic 了，但用户验证失败，看 dmesg 发现 kernel 缺少 md4 支持，将 md4 模块也编译拷到手机上开始测试：

insmod md4.ko
insmod cifs.ko
mount -t cifs -o username=xxx,password=xxx //192.168.1.xxx/share /mnt

挂载终于正常了。小激动人心，灰常不容易，总不辜负我 panic 了好几次的 K800 手机。话说每次 panic 都得强制抠电池再开机滴啊，555。

下面开始测试外接 U 盘（必须要有 USB OTG 线哦）：

insmod scsi_mod.ko
insmod sd_mod.ko
insmod usb-storage.ko

插上 U 盘，手机没任何反应，不过在 dmesg 里已经能看到上来的 sda 设备，运行 fdisk -l 命令可成功看到分区，看来只是手机系统没有做自动挂载外置 U 盘的处理（也正常，本来就不支持），自动挂载可以考虑装 StickMount 之类的软件哦。

使用 USB 转 串口（和实际芯片有关）：

insmod usbserial.ko
insmod pl2303.ko

使用 USB 有线网卡（和实际芯片有关）：

insmod usbnet.ko
insmod asix.ko

5、总结：

到这地步对我来说已经是颇有进展了，我暂时只看重 U 盘支持这个模块，嘿嘿。其它东西等有关时再来折腾了。

下面是我放出的压缩包下载链接：

http://miseal.googlecode.com/files/k800-kernel-config-modules.7z

里面包含我现在编译 kernel 使用的 config 和编译出来的一些有用的 kernel modules，不想自己编译的哥们就自行使用，由于这根本不是官方 kernel，我不对任何导致你的 K800 手机 panic 挂掉的后果承担责任，哈哈。