Android System porting: Driver Chapter

"Lead" in the Android system porting, there is a very important part of the work is to migrate the driver for the hardware device on the new platform. Because Android is built based on the Linux kernel kernel, the porting driver is actually based on the Android platform to develop a Linux kernel driver that adapts to mobile devices.

I. Linux kernel and device driver in Android system

The Linux kernel is used as its own operating system in Android, with the exception of Linux's generic code, which contains three main things:

• Architecture and processor
  Architecture processors and standard device drivers these two aspects are hardware-related, but for the same hardware, the Android system and the standard Linux system are basically the same.

• Android-specific drivers
  Android's dedicated drivers, usually hardware-independent drivers, are used only on Android systems.

• Standard Linux device drivers

The Linux kernel and device drivers in the Android system are shown in the following structure:

Android systems are typically used for mobile devices and other embedded devices, and therefore are based on the ARM architecture, with multiple processors in the ARM architecture. Therefore, for different pairs of processors, depending on the same peripheral device, the driver may not be the same.

The goldfish that need to be explained are:

The Android emulator runs a goldfish virtual CPU, goldfish is used to run the arm926t instruction set (arm926t belongs to the ARMV5 architecture) and simulates input/output, such as keyboard input and LCD output. This simulator is actually developed on the QEMU, and the input/output is based on libsdl. Since goldfish is a virtual CPU run by the simulator, we need to remove it when Android is running on a real hardware device.

Two. Device drivers on the Android system

• Basic graphical user Interface (GUI) section: Includes display sections, user input sections, and hardware-related acceleration sections, including media codec and OpenGL.
• Audio and video input and output parts: including the sound, video output and camera.
• Connection part: Including wireless LAN, Bluetooth, GPS and so on.
• Phone part: including call, GSM and so on.
• Accessory parts: including sensor, backlight, vibrator, etc.

Specifically, there are the following:

• [x] Display part: Includes framebuffer driver and Gralloc module.
• [x] Input User Entry section: Includes event driver and Eventhub.
• [x] Codec multimedia codec: Includes hardware codec drivers and codec plugins, such as OpenMAX.
• [x] 3DAccelerator (3D Accelerator) Section: Includes hardware OpenGL drivers and OpenGL plugins.
• [x] Audio part: Includes audio driver and audio hardware abstraction layer.
• [x] videoout Video output section: Includes video display driver and overlay hardware abstraction layer.
• [x] Camera camera part: Includes camera driver (usually V4L2) and camera hardware abstraction layer.
• [x] Phone part: Includes modem driver and Ril library.
• [x] GPS part: includes GPS driver (e.g. serial port) and GPS hardware abstraction layer.
• [x] Wi-Fi Wireless LAN section: Includes WLAN driver and protocol and Wi-Fi adaptation layer.
• [x] Bluetooth part: Includes BT drivers and protocols and BT's adaptation layer.
• [x] Sensor part: Includes both the sensor driver and the sensor hardware abstraction layer.
• [X] Vibrator Vibrator part: Includes vibrator drive and vibrator hardware abstraction layer.
• [X] Light backlight part: Includes light drive and light hardware abstraction layer.
• [X] Alarm warning part: Includes alarm driver and RTC system and user space call.
• [x] Battery battery part: Includes the battery part drive and the battery's hardware abstraction layer.

In the actual application, through the following figure, feel the next production of the tablet in the use of what hardware, the experience of the drive involved:

Three. Android System-specific driver

Take a look at the Android-specific drivers that Google has customized for Linux kernel:

(1) Android Binder

Android Binder is a driver based on the Openbinder framework for interprocess communication on the Android platform (interprocess
COMMUNICATION,IPC). The original Linux system upper-level application of inter-process communication is mainly D-bus (Desktop bus), the use of a message bus approach to IPC.
The source code is located in Drivers/staging/android/binder.c.

(2) Android Power Management

Android Power Management is a lightweight Android power management driver based on standard Linux power management systems, for embedded devices
A lot of optimizations. The use of locks and timers to switch the state of the system, control the power consumption in different states, has achieved energy-saving purposes.
The source code is located at:
-[] Kernel/power/earlysuspend.c
-[] Kernel/power/consoleearlysuspend.c
-[] Kernel/power/fbearlysuspend.c
-[] Kernel/power/wakelock.c
-[] Kernel/power/userwakelock.c

The Android5.0 version references the JobSchedule scheduler in order to increase the device's battery life.

(3) Low memory Manager (Killer)

More flexible than the standard oom (out of Memory) mechanism of Linux, it can be
Kill the process to free up the required memory. The source code is located in Drivers/staging/android/lowmemorykiller.c.

(4) Anonymous shared memory (ASHMEM)

Provides a large chunk of shared memory between processes, while providing the kernel with a mechanism to reclaim and manage this memory. Source code is located in
Mm/ashmem.c.

(5) Android Pmem (physical)

The PMEM is used to provide contiguous physical memory areas to the user space, and the DSP and some devices can only work on continuous objects
The memory.
The source code is located in Drivers/misc/pmem.c.

(6) Android Logger

A lightweight log device that captures a variety of logs from the Android system that Linux does not have.
The source code is located in Drivers/staging/android/logger.c.

(7) Android Alarm

A timer is provided to wake the device from sleep, and it also provides a device that even when it sleeps
The clock base to run. The source code is located in Drivers/rtc/alarm.c.

(8) USB Gadget Driver

A device driver based on the standard Linux USB gadget drive framework, the Android USB driver is based on the Gaeget framework.
Source code is located in
-[] Drivers/usb/gadget/android.c
-[] Drivers/usb/gadget/f_adb.c
-[] drivers/usb/gadget/f_mass_storage.c

(9) Android Ram Console

To provide debugging functionality, Android allows debugging log information to be written to a device called RAM console
, it is a ram-based buffer. The source code is located in Drivers/staging/android/ram_console.c.

(10) Android timed Device

It provides the function of timing control of the equipment, currently supports vibrator and LED equipment. Source code is located in
DRIVERS/STAGING/ANDROID/TIMED_OUTPUT.C (TIMED_GPIO.C).

(11) YAFFS2 File System

Android uses YAFFS2 as the MTD NAND Flash file system, and the source code is located in the fs/yaffs2/directory.
The YAFFS2 is a fast and stable, cross-platform embedded device file system for NAND and NOR flash, compared to other Flash file systems
YAFFS2 can use smaller memory to save its running state, so it consumes less memory. YAFFS2 's garbage collection is very simple and fast, so you can watch
Better performance. The YAFFS2 performance on large-capacity NAND flash is particularly well-suited for large-capacity flash storage.

Four. The main work of Android driver development

The Linux system divides device drivers into the following three categories:

• (1) Character device

  Refers to a device that can read and write only one byte at a byte, and not a random reading of a data in the device memory, reading the data needs to follow the data. The character device is a stream-oriented device, and the common character devices are mouse, keyboard, serial port, console and led device.

• (2) Block equipment

  Refers to a device that can read a certain length of data from any location on the device. Block devices include hard disks, disks, USB sticks, and SD cards.

• (3) Network equipment

  To support the processing of network connections through the file interface, Linux uses a BSD-based socket abstraction, Socket Keil as an agent between the application, the file interface, and the kernel's network.

The driver is a bridge between the system and the hardware, and realizing the interaction between the hardware and the system is the main task of our bottom development. In the Android system, we generally need to write kernel-level and user-level programs to accomplish specific tasks.

4.1 Ways to achieve interaction between systems and hardware

• (1). Write your own system call
  System calls are the most basic method of user-level program access to the kernel, and Linux provides a number of standard system calls (see Include/asm-i386/unistd.h and arch/i386/kernel/entry in the kernel code tree). s file), and allows us to add our own system calls to implement the information exchange with the kernel;

• (2). Writing drivers
  One of the important concepts of Linux is "all Files" (everything is a file).

  The user-space application accesses a file in the/dev/directory in the file system through the system-provided unified interface open ()--read ()--write ()--ioctl ()--close () method to access the driver running in kernel space. Access to the hardware is achieved through the functions implemented in the driver.

• (3). Using the proc file system

  Proc is a special file system provided by Linux, and its purpose is to provide a convenient way to interact between users and the kernel. Proc File system is relatively simple, but proc file read and write is not uniform, reading data buf pointer directly to the address of the user state, you can write with sprintf, and the writing method is the kernel State address, need to use Get_user or copy_from_ Methods such as user.

• (4). Using the virtual file system

  Some kernel developers think that using the IOCTL () system calls often makes system calls ambiguous and difficult to control. Putting information into the proc file system can confuse the information and therefore does not favor excessive use. They recommend implementing an isolated virtual file system instead of the IOCTL () and/proc, because the file system interface is clear and user-friendly, and the use of virtual file systems makes it easier and more efficient to perform system administration tasks with scripts.

• (5). Using a memory image

  Linux provides the ability of a user program to access memory directly through a memory-imaging mechanism. The memory image means that the memory space of a specific part of the kernel is mapped to the memory space of the user-level program. That is, the user space and the kernel space share a piece of the same memory.

4.2 Interaction between the kernel space and the user space

There are several ways in which the system interacts with the hardware, which refers to the concept of a kernel space and a user-space interaction in a specific interaction where the driver drives the specific hardware module to work.

In modern computer architecture, storage management usually includes a protection mechanism. The purpose of protection is to avoid a task in the system that accesses a storage area belonging to another or an operating system. As in the IntelX86 system, the privilege level is provided as a protection mechanism that restricts access to the storage area through the distinction of privilege levels.

Based on this architecture, the Linux operating system divides itself: part of the core software is independent of the normal application and runs at a higher level of privilege (Linux uses the Intel system's privileged level to run the kernel. They reside on a protected memory space and have all the permissions to access the hardware device, which Linux calls kernel space .

In contrast, other parts are executed as applications in user space . They can only see some of the system resources that they are allowed to use, and cannot use certain system features, direct access to the hardware, no direct access to kernel space, and, of course, other specific usage restrictions. (Linux runs the user program with the privileged level of Intel system.) ）

Take a look at the interaction between the kernel space and the user space through the following diagram:

Copyright NOTICE: This article for Bo Master "limin13215" original article, welcome reprint, reprint please indicate the link address! 72676518

Android System porting: Driver Chapter