Simple Guide for porting Android kernel Author: Liu Xuhui colorant@163.com reprint please indicate the source http://blog.csdn.net/colorant/ transplanted Android kernel to the actual hardware platform, many people have done this for a long time, however, there are not many relevant documents and experience. Let me write one. I want to record the general process for myself and continue later.
1. background knowledge about Android kernel porting
1.1 operating platformGoogle Android platform until today (), the application layer is still in the form of binary release, its compiled target platform is the ARM926EJ-S CPU belongs to the armv5t version, therefore, the CPU platform of armv4 architecture cannot use its binary code. For more information, see the following article. Benno has made a detailed theoretical analysis and code test here.
1.2 software environmentDownload SDK: Release
1.2.1 KernelTo M5-r14 release, Android kernel is developed based on the Linux 2.6.23 kernel, mainly added a virtual CPU named goldfish and specific driver code required for Android. You need a kernel that supports Eabi as the starting point of your kernel porting (minimum version? I don't know. As long as Eabi is OK, there should be no essential difference. However, many Android drivers rely on the kernel API 2.6.23. The earlier the version, the more work it will take to transplant and modify kernel-related code)
1.2.2 tools chainThe kernel in the SDK uses GCC 4.2.1, basically, you need a tool chain that supports Eabi, for example you can use the latest tool chain of codesourcery: http://www.codesourcery.com/
1.2.3 other toolsAndroid emulator is a good simulation tool. Its underlying layer is implemented based on qemu. You can use the ADB tool in the SDK to log on to the emulator console and exchange files with the console, used to obtain the information you need.
1.3 related forum ResourcesHttp://benno.id.au/blog/http://groups.google.com/group/android-internalshttp://groups.google.com/group/android-developers
2 Basic Idea of porting
2.1 required resources
2.1.1 hardwareFirst of all, of course, we need a hardware development board that can be used for porting. In addition to the hardware requirements described above, we need armv5 + compatible CPU, the minimum requirement is 64 m + memory, and 64 m-128 M + flash (depending on how you load the file system, if you can use a NFS-ROOT or mmccard to store the file system through the network, it should not matter)
2.1.2 SoftwareIn addition to the preceding kernel and tools chain, it is best to have static compilation tools such as busybox and strace for debugging convenience. You can also download the compiled version from Benno's blog.
2.2 Basic ProcessDownload the android kernel code. Download the official 2.6.23 kernel to create the diff files of Android and 2.6.23 kernel to remove the Code related to goldfish and qemu In the diff file. If your system already supports yaffs2, you can also remove this part of code and patch the diff file to your own kernel. If necessary, modify the kernel-Related File Code so that the patch can be completed smoothly. (This part is probably the main workload, if your kernel version is far behind 8) If necessary, modify the framebuffer driver in your kernel code, make virtual_yres equal to two times of yres, and allocate two times of framebuffer memory. Configure the kernel to make sure that the following content is configured: config_arm_thumb = yconfig_aeabi = y
Config_binder = y
Config_android_log = y
Config_android_power = y
Config_android_power_stat = y get the android file system from the SDK. Basically, you only need these directories/Files: system etc sbin init, the data directory contains content, but the content of this directory can be dynamically created by Android at startup. (You can use the ADB tool to package tar in emulator before copying it. M3 release can also directly get the file system he caught from Benno.) Make sure that your dev directory has enough device nodes started by the system, such as the console, android of other nodes is automatically created during startup. Use nfsroot or chroot to start the android file system. The general external performance of the start-up process is in sequence: Some Android characters are displayed on the LCD, and a red scroll bar appears on the LCD for a short period of time. (if there is a problem, (8) enter the main interface so far my status is: the keyboard can work, the touch screen has a response but is not calibrated, the location is wrong, start the last phase and then start a new program, and the vmalloc memory allocation failed problem occurs. As a result, applications such as Brower cannot be fully started. Other networks and other things are not started yet. 8)
3. Some tipsAndroid uses memory mapped to operate files. jffs2 does not support this operation. Therefore, you must use another file system. Of course, there are also ways to go around, search for it yourself 8) to facilitate testing, you can modify/etc/init. RC, comment out the runtime, kernel-daemon, xzygote, and other related content, and start these processes manually after init is started: /system/bin/app_process-xzygote/system/bin -- zygote &/system/bin/kernel-daemon -- System -- nofork & sleep 1; the init of/system/bin/runtime & ø Android is located in the root directory. If you need to directly start init, you can use init =/init In the Kernel Parameter command line, or specify the chroot directory/init. Of course, you can also manually start/init after/bin/sh is started. Files such as/dev/binder/dev/alarm/dev/log/* are the most important device nodes. Because the Primary and Secondary device numbers of these device node numbers are dynamically allocated, therefore, it is best to check whether the primary and secondary device numbers of these device nodes in your file system are correct. If you do not know how to confirm it, delete it and restart it. (8) if the Flash speed is too slow or the NFS network connection is too poor, you can mount the two data TMP directories to the memory, the premise is that your memory is large enough. 8) if the red scroll bar is too fast during startup (compared with the performance in emulator), the CPU usage of the runtime or system_server process is close to 100%, then you can modify the pan_display function code in your framebuffer Code to ensure that it gets enough frame synchronization latency when calling the returned result. According to Google's swetland, this is usually indicative of lack of vsync/pageflip In the FB driver. the surfaceflinger believes it will be limited by the vsync rate and the startup animation depends on that. the current Android kernel code has two versions: M3-r20 and M5-r14. The two versions of the binder and power drivers have made great changes, the upper-layer file system and kernel must be used together. (In addition, on my board, the M5 version can run, and the M3 version will have a segment error and will not run :(. If a version cannot run, try another version.) Use strace to track problems!
