Due to work relationships, attention to Android will shift from FWK (Framework) to BSP, that is, Linux Kernel. In the five years at work, I have studied kernel several times, but I have never had the right opportunity or motivation to study it in depth. How can I leave this opportunity? In the past, we used to work with kernel and always felt that there were no suitable devices. After several days, I plan to start with the android Virtual Device goldfish. (Sorry, I have bought a board before, and it will be boring after 2 days ). This document includes the following parts:
- First, we will introduce how to download and compile Android kernel.
- Configure the simulator to use the compiled kernel.
- This section describes the input system content. My goal is to repeat the Android driver in the shortest time. In this process, the relationship between processes and modules is the most important. Further research will be conducted when the problem details are met in the future.
Android GoldFish kernel download and compilationThe old method is to use git to download. The kernel and non-kernel code are not in the git library. The Android code is downloaded by the repo, and the kernel must be downloaded by git separately. The download method of goldfish code is as follows:
- First, create the kernel directory under the root directory of Android JB source code.
- Cd kernel, and then git clone http://android.googlesource.com/kernel/goldfish.git (you can also download Qualcomm's msm, common and omap branch kernel)
- After the download is complete, get the kernel/goldfish directory. Cd kernel/goldfish
- Git branch-a to view all branches. There are 2.6.29 and 3.4
- Git checkout-B 2.6.29 remotes/origin/android-goldfish-2.6.29 create a local branch 2.6.29 to track remote android-goldfish-2.6.29 branches. The goldfish directory contains files.
Next we will compile. Suppose we have downloaded the source code JB.
- Or in the kernel/goldfish directory. Before executing the make ARCH = arm goldfish_armv7_defconfig command, make reads the goldfish_armv7_defconfig file from the arch/arm/config file to obtain the card (well, there is no real card, there is a virtual card) related compilation configuration files (nothing more than defining some macros to enable some function modules and drivers of kernel ). After the command is executed, A. config file is generated.
- Set the environment variable export CROSS_COMPILE = Anroid-JB/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-this is to set the location and prefix of the Cross-compilation toolchain. In this way, This prefix + gcc-related tools will be used to compile the kernel.
- Then make ARCH = arm. After compilation, the final output is Kernel: arch/arm/boot/zImage is ready zImage, which is the final kernel image of the Kernel. For the composition of the kernel image, refer to my previous blog http://blog.csdn.net/innost/article/details/6693731
OK. Now we have to compile our own kernel. Find a machine to burn it in and start it. Because we don't have a real machine, find the simulator.
2. Use the Android simulator to load goldFish kernelI have created an android emulator script in the source code directory of JB. Let's take a look at its content :#! /Bin/sh
/Disk/android/android-sdk-linux_86/tools/emulator# This is the file location of the android emulator.
-Avd4.1 # start the machine 4.1. I used AVD tool to create a machine named 4.1.
-System/Android-4.1/out/target/product/generic/system. new. image # I have customized an extremely simple system. there are only five APK in the image, so the startup speed is faster. This parameter is used to specify the system image file running on the machine.
-Kernel/Android-4.1/kernel/goldfish/arch/arm/boot/zImage # this parameter is used to specify the kernel image file. Now we have pointed to the self-compiled kernel.
-Ramdisk/Thunderst/work-branches/Android-4.1/out/target/product/generic/ramdisk. new. img # I also customized ramdisk and modified the init program. This parameter specifies the ramdisk Image File
-Partition-size512 # specify the partition size of system and data to 512 MB
&# With this script running in the background, I will be happy. It feels better and faster than simply starting a real machine. Explain ramdisk. Ramdisk: a compressed expression file in the android root directory. The procedure is as follows:
- Suppose there is already an x folder, and you want to package it into a ramdisk file.
- First, read the directory information in file x and write it to the result file ramdisk. temp. Then traverse all the files in the x Directory (open them directly, read them, whether you are a binary file or a text file ). All read data is written to a final file. Assume ramdisk. temp. This is actually an archive process.
- Use gzip to compress ramdisk. temp and get ramdisk. image (the suffix is your own ).
If you already have a ramdisk. image, how can you restore it?
- You can use file ramdisk. image to check the file information and find that it is a gzip compressed file (as mentioned above ). Gunzip ramdisk. image.
- Create a folder, mkdir test, and cd test
- Cpio-I-F ../ramdisk. In this way, the ramdisk. image is reversed to the test directory. In the past, the content in directory x was returned to the directory test.
Ramdisk is basically the content of the android root directory, such as init and init. rc. Therefore, if you modify these files on the simulator, it is useless to restart the machine. Because the root directory is obtained after extracting ramdisk, the original ramdisk is not modified. Therefore, if you want to modify the content in the root directory, you can only re-create ramdisk. The method is described above, which is very simple. [Read Embed Liux Primer]
3. Android goldFish Input Device
3.1/dev/input/event0To be honest, the only thing I know at the beginning is that the getEvents file in FWK reads the input event. The/dev/input/event0 device is enabled in the getEvents file of EventHub. From now on. Event0 is automatically generated by ueventd. There is a ueventd in the system, which is under sbin. Unfortunately, this is a link, pointing to the init under/system. Can init process ueventd events? I don't think this is the case in 2.2. It may be a later version. Check the init Code. There is an if branch in it that will go to ueventd_main. Here we open the ueventd. xxx. rc file. This file is different from what I used to understand. It creates a device file under/dev/According to the configuration file and sets permissions. According to the Ueventd. c code, after receiving the event reported by the kernel that belongs to the input device, a file will be created under/dev/input based on the path name passed in by the uevent. [This part of the Code needs a good look, it is not difficult. However, if you need to modify it later, you can understand the process in advance]
3.2 who sent the input uevent event?This... I was the first to come into contact with the relevant code, and I had to rely on brutal searches.
- The input_init function in driver/input. c establishes a framework for the input system.
- This file defines an input_register_handler function, which is used to register the input event processing handler. No way. Search cgrep input_register_handler. This event will be registered in many places. But I focus on evdev and keyboard. Use source insight to open these two files and add some printk output. Example:
Figure 1 where input_register_handler is used in a brutal search. Focus on evdev and keyboard
- Add a little output to the two files. (Do you still need to know some basic APIs of kernel? We recommend that you read the third edition of linux driver develop .)
- Goldfish also has a common driver called driver/input/keyboard/goldfish_events.c, where it registers a platform_driver. Platform_driver has some basic APIs, so you can check them online. And embedded systems. This driver has an events_probe function to determine which devices can be handed over to the goldfish_event driver for processing. This should be a dedicated driver for goldfish. It should be different from the input mentioned above. (I currently think that input is a common framework of the input System, while goldfish_events is a driver. It will detect some devices and then register these devices into the input framework. This should be the case. I will not study it for the moment ).
- You can see the events_probe function of this driver. It will detect a qwerty2 device and then register it in the input framework. The figure is as follows:
Figure 2 detects a device, keymap is qwerty2, and then registered to the input framework
- Continue to trace the events_probe function, which has a lot of interaction with the input framework. The more important thing is to set some handler for the qwerty2 device. As shown in figure 1, two important handler types are evdev and keyboard.
- Add a little output to the two files respectively. It is found that evdev has a poll function, and EventHub also calls the poll function to obtain the input event. We can see that the handler evdev transmits data to EventHub.
Conclusion 3.3
This goal has been achieved, and the process for generating input events has been clarified. The following is a summary:
- Goldfish_events registers a platform_driver. When it detects the input device, it registers it in the input system.
- The kernel registers some handler in the input device. A device can have multiple serial handler
- Goldfish_events sets an input event interrupt function events_interrupt. when an event occurs, the function delivers the information to the input framework for processing (call the input_event function)
- The input_event function calls handler for processing. For goldfish, the most important handler is evdev, which sorts the information and reports it to EventHub.
Iv. SummaryObjectives of this essay:
- Build a virtual device environment and compile and run goldfish kernel.
- The input-related process in BSP is simplified.
Once again, this series of essays is a quick way to streamline the various drivers in the Android BSP.
