如何制作android nexus one的内核

动手自己制作android device的内核! 主要是参考一些别人的经验. 有助于理解android中的image的format. !!!很厚颜的标注为原创!!!

经过自己的验证,完全可行. 有问题的朋友,可以互相交流下:)

原文地址：http://android-dls.com/wiki/index.php?title=HOWTO:_Unpack%2C_Edit%2C_and_Re-Pack_Boot_Images

Building Kernel from source

Install CyanogenMod on the device

First, you will need to get a working install on the device: Installing CyanogenMod on the device.

Install development support packages

Install the following packages using your favorite package manager:

Debian based Linux distributions

32bit and 64bit systems:

git-core gnupg sun-java6-jdk flex bison gperf libsdl-dev libesd0-dev libwxgtk2.6-dev build-essential zip curl libncurses5-dev zlib1g-dev

64bit only:

ia32-libs lib32z1-dev lib32ncurses5-dev gcc-multilib g++-multilib

Red Hat based Linux distributions

32bit and 64bit systems:

git gnupg java-1.6.0-openjdk-devel flex bison gperf SDL-devel esound-devel wxGTK-devel zip curl ncurses-devel zlib-devel gcc-c++

64bit only:

glibc-devel.i686 libstdc++.i686 zlib-devel.i686 ncurses-devel.i686

Setup Repo

Make sure you have a ~/bin directory, and setup repo.

mkdir -p ~/bin

curl https://dl-ssl.google.com/dl/googlesource/git-repo/repo > ~/bin/repo

chmod a+x ~/bin/repo

echo $PATH|grep ~/bin>/dev/null||export PATH="${PATH}":~/bin

To validate the repo command is in your path, type 'which repo'.

To add ~/bin to your $PATH edit ~/.bashrc and add:

export PATH = ~/bin:$PATH

Download ROM Source Code

mkdir -p ~/android/system

cd ~/android/system

repo init -u git://github.com/CyanogenMod/android.git -b gingerbread

repo sync -j32

This may take 1.5 hours, more or less, depending on your connection.

Create an environment variable denoting the location of the android toolchain as follows:

export CCOMPILER=${HOME}/android/system/prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

Download ARM EABI Toolchain (Optional)

If you're just building the kernel and don't need the whole ROM source try using the Code Sourcery ARM EABI Toolchain.

Download and extract then, create an environment variable denoting the location of the toolchain as follows:

export CCOMPILER=[extraction directory]/bin/arm-eabi-

最新的CodeSourcery的bin文件变为：
export CCOMPILER=[extraction directory]/bin/arm-none-linux-gnueabi-

Download Kernel Source Code

mkdir -p ~/android/kernel

cd ~/android/kernel

git clone git://github.com/CyanogenMod/cm-kernel.git

cd cm-kernel

Configure the Build

Retrieve a working kernel config from the device, and unzip it:

adb pull /proc/config.gz /home/user_name/android/kernel/cm-kernel/config.gz

cat config.gz | gunzip > .config

Alternatively, you can pull the .config from the newest boot.img

scripts/extract-ikconfig boot.img > .config

Configure the build. Just enter to accept defaults, or customize as needed:

make ARCH=arm CROSS_COMPILE=$CCOMPILER oldconfig

make ARCH=arm CROSS_COMPILE=$CCOMPILER menuconfig

Make the build

make ARCH=arm CROSS_COMPILE=$CCOMPILER -j`grep 'processor' /proc/cpuinfo | wc -l`

This step may take a while, depending on your computer.

At this point you should have a kernel stored in ~/android/kernel/cm-kernel/arch/arm/boot/zImage and kernel modules, if any were built, in the module sub-directories.

Merge the build

You will need to merge this file with a working cyanogen ramdisk in order to create a boot image suitable for flashing. Follow these instructions here.

If all goes well, you should now be running your own custom CyanogenMod kernel on the device.

Note: If you are building for Nexus One, you should use --base 0x20000000 when running mkbootimg.

An alternate method is to use an existing kernel update zip for your device. Unzip the update, replace the kernel zImage andkernel modules with your new ones, rezip, and flash on your device.

Compiling wifi kernel module

After installing a custom kernel, the wifi module may be unstable or unusable. The solution is to recompile the module, linking it to the new kernel build.

cd ~/android/system/system/wlan/ti/sta_dk_4_0_4_32

KERNEL_DIR=~/android/kernel/cm-kernel CROSS_COMPILE=$CCOMPILER ARCH=arm make -j`grep 'processor' /proc/cpuinfo | wc -l`

A file named wlan.ko will be produced in the current directory. You must install the new module to the device.

adb shell mount -o remount,rw /system

adb shell cp /system/lib/modules/wlan.ko /system/lib/modules/wlan.ko.backup  在我的Nexus one中没有该wlan.ko


adb push wlan.ko /system/lib/modules/wlan.ko

Reboot the device. If all goes well, you should be using the newly compiled 'wlan.ko'.

For devices which may be utilizing wifi module from vendors other than TI, you may choose other appropriate drivers.

Installing kernel modules for debian chroot installation

If you have a debian chroot install on the device, you will want to add to it the loadable modules that were built along with thekernel. This is necessary to use things like fuse, cifs, etc.

First tar up and transfer over the modules

cd ~/android/kernel

tar -czf modules.tgz `find . | grep ko$`

adb push modules.tgz /sdcard/

Then, Copy the modules to your debian install (Replace <debian_root> with the root of your debian installation)

adb shell

mkdir <debian_root>/lib/modules/`uname -r`

cd <debian_root/lib/modules/`uname -r`

tar -zxf /sdcard/modules.tgz

Last, Install the modules from debian (must be done as root). Log in to your debian installation using your method of choice, then:

depmod -a

If all goes well, depmod should produce no output. At this point you may load a kernel module from within debian by typing (as root):

modprobe <module_name>

where <module_name> is the name of the kernel module without the .ko extension.

You may remove a module by typing:

modprobe -r <module_name>

Sources

More information can be found at android.git.kernel.org and source.android.com.

HOWTO: Unpack, Edit, and Re-Pack Boot Images

Several people have already figured out the details on their own, but I have gotten requests to do a more comprehensive tutorial on how the boot and recovery images are structured, and how you can edit them.

Background

Your phone has several devices which hold different parts of the filesystem:

#cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00040000 00020000 "misc"
mtd1: 00500000 00020000 "recovery"
mtd2: 00280000 00020000 "boot"
mtd3: 04380000 00020000 "system"
mtd4: 04380000 00020000 "cache"
mtd5: 04ac0000 00020000 "userdata"

我的Nexus one上的结果如下：

#cat /proc/mtd
dev:    size   erasesize  name
mtd0: 000e0000 00020000 "misc"
mtd1: 00400000 00020000 "recovery"
mtd2: 00380000 00020000 "boot"
mtd3: 09100000 00020000 "system"
mtd4: 05f00000 00020000 "cache"
mtd5: 0c440000 00020000 "userdata"

Note that the order is different for different phones! Check yours to make sure you use the right device.

In this tutorial, we will deal with "recovery" and "boot". "system" holds everything that gets mounted in your system/ directory, and userdata/ is everything that shows up in data/ (this is all the apps you've installed, your preferences, etc).

The recovery and boot partitions are at /dev/mtd/mtd1 and /dev/mtd/mtd2, and before you do anything else you should back these up:

# cat /dev/mtd/mtd1 > /sdcard/mtd1.img
# cat /dev/mtd/mtd2 > /sdcard/mtd2.img

(Note added by lxrose: These commands don't work if your phone is not rooted and the permissions are not set.)

The other thing you should do is put your favorite update.zip file into the root directory of your sd card so that if you screw up your boot partition you can boot into recovery mode and re-apply the update. You probably want one of the pre-rooted recovery images found elsewhere on the forums.

There is also another important file you should know about. In /system/recovery.img there is a full copy of everything that is loaded on mtd1. This file is automatically flashed onto mtd1 every time you shut down. That means two things: 1. Any changes you make directly to /dev/mtd/mtd1 get blown away on reboot and 2. If you want to change /dev/mtd/mtd1 you're probably better off just sticking the image in /system/recovery.img and rebooting. When creating your own custom update.zip files (especially when adapting the stock images), you can get tripped up if you forget to replace /system/recovery.img and it ends up overwriting /dev/mtd/mtd1 unbeknownst to you. Watch out.

Structure of boot and recovery images

The boot and recovery images are not proper filesystems. Instead, they are a custom android format consisting of a 2k header, followed by a gzipped kernel, followed by a ramdisk, followed by a second stage loader (optional, we have not seen these in the wild yet - except on Sanyo Zio). This structure is outlined in mkbootimg.h:

+-----------------+ 
| boot header     | 1 page
+-----------------+
| kernel          | n pages  
+-----------------+
| ramdisk         | m pages  
+-----------------+
| second stage    | o pages
+-----------------+

n = (kernel_size + page_size - 1) / page_size
m = (ramdisk_size + page_size - 1) / page_size
o = (second_size + page_size - 1) / page_size

0. all entities are page_size aligned in flash
1. kernel and ramdisk are required (size != 0)
2. second is optional (second_size == 0 -> no second)

A ramdisk is basically a small filesystem containing the core files needed to initialize the system. It includes the critical init process, as well as init.rc, which is where you can set many system-wide properties. If you really want to know more about it, here is the documentation. Here's a list of files on a typical ramdisk:

./init.trout.rc
./default.prop
./proc
./devbase 0x20000000
./init.rc
./init
./sys
./init.goldfish.rc
./sbin
./sbin/adbd
./system
./data

The recovery image typically has a few extra files, which constitute the recovery binary and supporting files (the application that gets run if you hold down home+power when rebooting). These files are:

./res
./res/images
./res/images/progress_bar_empty_left_round.bmp
./res/images/icon_firmware_install.bmp
./res/images/indeterminate3.bmp
./res/images/progress_bar_fill.bmp
./res/images/progress_bar_left_round.bmp
./res/images/icon_error.bmp
./res/images/indeterminate1.bmp
./res/images/progress_bar_empty_right_round.bmp
./res/images/icon_firmware_error.bmp
./res/images/progress_bar_right_round.bmp
./res/images/indeterminate4.bmp
./res/images/indeterminate5.bmp
./res/images/indeterminate6.bmp
./res/images/progress_bar_empty.bmp
./res/images/indeterminate2.bmp
./res/images/icon_unpacking.bmp
./res/images/icon_installing.bmp
./sbin/recovery

Unpacking, Editing, and Re-Packing the images

Note: below I give you the details for unpacking and repacking manually, but I created two perl scripts that do most of this for you (unpack-bootimg.pl, repack-bootimg.pl).这两个脚本在原文已经失效，请参照另外一位国人对这篇文章中的翻译。

If you are good with a hex editor, you can open up any of these images and strip off the first 2k of data. Then, look for a bunch of zeroes followed by the hex 1F 8B (which is the magic number of a gzip file). Copy everything from the first line of the file, through the zeroes, and stopping at the 1F 8B. That is the kernel. Everything from the 1F 8B through the end is the ramdisk. You could save each of these files separately. In order to see the contents of the ramdisk, you need to un-gzip it and then un-cpio it. You could use a command like this (ideally after creating a new directory and cd'ing into it):

gunzip -c ../your-ramdisk-file | cpio -i

That will place all of the files from the ramdisk in your working directory. You can now edit them.

In order to re-create the ramdisk, you need to re-cpio them and re-gzip those files, with a command like the following (remember, cpio will include everything in the current working directory, so you probably want to remove any other cruft you might have in there):

find . | cpio -o -H newc | gzip > ../newramdisk.cpio.gz

The final step is to combine the kernel and your new ramdisk into the full image, using the mkbootimg program (which you should download and compile from the git repository):

mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel your-kernel-file --ramdisk newramdisk.cpio.gz -o mynewimage.img

Now, there's a lot of hassle in pulling apart files in hex editors and remembering all of these commands, so I wrote unpack and repack perl scripts for you. Hooray.

Alternative Method

Download split_bootimg.zip . This Zip file contains one Perl file, split_bootimg.pl, which reads the boot.img header (according to the bootimg.h of the Android source code) to extract the kernel and ramdisk. The script also outputs the kernel command line and board name (if specified).

(Note: Do not use a boot.img image extracted directly from /dev/mtd/mtd2. This image may become corrupted during the read process.)

The following example uses the boot.img from the full TC4-RC28 update:

% ./split_bootimg.pl boot.img 
Page size: 2048 (0x00000800)
Kernel size: 1388548 (0x00153004)
Ramdisk size: 141518 (0x000228ce)
Second size: 0 (0x00000000)
Board name: 
Command line: no_console_suspend=1
Writing boot.img-kernel ... complete.
Writing boot.img-ramdisk.gz ... complete.

Extract the ramdisk.

% mkdir ramdisk
% cd ramdisk
% gzip -dc ../boot.img-ramdisk.gz | cpio -i
% cd ..

Make any changes necessary (e.g., set ro.secure=0 in default.prop).

Recreate the cpio archive using the mkbootfs binary produced from building the Android source code (The cpio utility in OS X does not recognize the newc format, therefore mkbootfs is the best option for OS X users).

% mkbootfs ./ramdisk | gzip > ramdisk-new.gz

Recreate the image file using the mkbootimg binary produced from building the Android source code.

% mkbootimg --cmdline 'no_console_suspend=1 console=null' --kernel boot.img-kernel --ramdisk ramdisk-new.gz -o boot-new.img

For Nexus One : Add --base 0x20000000 to mkbootimg command-line.

(Note: the console=null command line option was introduced in the TC4-RC30 boot images to remove the root shell (TODO: add link))

Flashing your new image back onto the phone

You will probably only ever be flashing boot images directly to the phone, given the fact that /system/recovery.img automatically flashes the recovery device for you (as noted above). If you have created a new recovery image, just stick it in /system/recovery.img and reboot. If you are flashing a boot image, stick it on your phone via adb (a tool included in theAndroid SDK):

adb push ./mynewimage.img /sdcard

Then, open a shell to your phone via 'adb shell', get root, and do the following two commands to flash your new boot image:

# cat /dev/zero > /dev/mtd/mtd2
   write: No space left on device [this is ok, you can ignore]
# flash_image boot /sdcard/mynewimage.img

Reboot.

If your phone starts all the way up, congratulations. If not, you did something wrong and you'll need to boot into recovery mode and apply your update.zip file (reboot while holding down home+power, when you get the recovery screen press alt+L and then alt+S).

Something fun to do with your new found power

If you place a file titled initlogo.rle in the root directory of your boot image, the phone will display this image upon boot (after the "G1" image and before the Android animation). In order to create this file, you need to create a 320x480 image in Photoshop or Gimp and save it as a "raw image" file. You then need to compress that image with the program to565. More details on that here.

This is not the same thing as applying an update.zip

You will see other places on the forums that describe how to create customized update.zip files, as well as update.zip files that people are sharing. For example, there is a recent update.zip which is a modified version of rc30 (with the anti-root aspects disabled). The update.zip files include new boot images, recovery images, and typically replacements for the entire system/ directory as well as other updates. If you are creating a custom boot or recovery image, it is typically a good idea to start with the image distributed with the most recent update you have applied (flashing an image from an older release could have unintended consequences).

这时,内核和对应的boot.img已经准备好了,接下来就是编译自己的ROM, 这里我还是使用的是CyanogenMod的src来编译自己的ROM. 按照CyanogenMod的操作步骤,把ROM烧好之后,就可以自己玩了.

有一点,需要注意,通常是先烧录已经带boot.img的自制CyanogenMod的ROM, 然后再烧自己的kernel。重启后，会发现wifi模块error。这是因为，一开是烧录的CyanogenMod中的/system/lib/modules/bcm4329.ko与后来烧制的kernel不匹配。所以，最后还要把kernel中的bcm4329.ko替换掉device中的bcm4329.ko。