Android Deep Exploration (3)

The eighth chapter makes the Development Board sound: Buzzer driver

There are many ways to reuse Linux-driven code. The standard C program can be used in the way. Put the code you want to reuse in a different file (declared in the header file). If you want to use some features, include the corresponding header file (this.) is called static reuse. You can also use another way of dynamic reuse, where a Linux driver can use resources from another Linux driver (functions, variables, macros, and so on). If there is not much code in the Linux driver, it is not a good thing to put all the code in a file, but for a complex Linux driver, it is necessary to use multiple source code files to store different function codes, which facilitates code categorization and management. Of course, if the Linux driver is going to use a third-party source code, it will have to compile multiple source code files and eventually become. ko files or compiled into the Linux kernel. When compiling multiple source code files in the C or C + + language, if A.C uses the functions in the B.C file, you need to use extern to pre-define the functions in B.C in the A.c file, and extern is to tell the compiler the function name, the number of arguments, the parameter type, and the return value type. This information is sufficient for compiling A.C into A.O. When you link A.O and b.o to an executable file or library, the compiler then looks for the function in the B.C. That is, extern only works in the compile phase. In addition, you can use the B.h file to define functions in B.C, and then include B.h files in A.C. You can omit the extern keyword for some c/+ + compilers. However, in order to be more general, it is recommended to add extern.

Code reuse can be divided into two types: static and dynamic. Another way of sharing code: module dependencies, also known as export symbols. If you can only use a sentence to explain how to use the export symbols to achieve code sharing, this sentence is "in a driver module using another driver module in the exported symbols (constants, variables, functions, etc.)." 1. The initialization function of the Linux drive module crashes due to some operation, which causes the initialization function to not return normally. The performance of this situation is that the current Linux driver module is not used by any other Linux driver, but the display has been quoted once. 2. When uninstalling the Linux driver using the Rmmod command, the system calls the Unload function, and only the Unload function returns the elbow successfully, the Linux driver is not loaded. If the Unload function is blocked (possibly due to a dead loop, concurrency, etc.), the Rmmod command is also blocked. In other words, the code to unload the Linux driver module will never be executed. The performance of this situation is that an execution of the RMMOD command will stop there and never return to the operating prompt of the system.

First of all, look at the 1th situation. The key to this situation is that the value of the reference counter is inconsistent with the reference. In fact, the reference does not exist, so you only need to clear the current Linux Driver module reference counter 0. The following two functions can be used to modify a reference counter.

The reference counter of the Linu x driver that the module points to is added L, successfully returned 1, and the failure returns 0.

static INL vertical NE int try_m. Dule_get (struct module *module)

Subtract 1 from the reference counter of the Linux driver that the module points to.

extern void Modul e_put (struct module *module);

The problem with the 2nd case is the Unload function, so just replace the original unload function with an empty unload function.

Nineth Hardware Abstraction Layer: HAL

HAL (Hardware abstraction Layer, Hardware abstraction cavity) is a set of turn-up fonts built on Linux drivers. This library is not part of the Linux kernel, but rather belongs to the application layer on top of the Linux kernel layer. Google adds Hal's main target to Android

In addition to trying to avoid direct access to the Linux driver, there is another important reason, that is to protect "private property." It's the gospel for businesses or individuals who want to publish Android-based Linux drivers without exposing their core business logic.

Linux drivers typically have two types of code in a traditional Linux system: the code that accesses the hardware register and the business logic code. There is no secret to the code that accesses the hardware registers, as this is a standard operation for calling the standard functions of the Linux kernel (ioread32, iowrite32, and so on). Some enterprises or individuals do not want to expose the source code, while the Linux-driven business logic is part of the strike. Although these Linux drivers are free for users, the implementation of these Linux drivers involves some technical patents or trade secrets, which can be a big hassle if the source code is exposed. But as a Linux. Driver, you have to expose the source code. This is because the Linux kernel uses the GPL protocol, and the GPL requires that all programs that use the GPL-based source code must be open source (since Linux drivers are part of the Linux kernel, Linux drivers must be open source).

All in all, Google for Android to join HAL mainly has the following purposes:

1. The calling interface of the unified hardware. Because HAL has a standard call-to-lie, Hal can be used to shield Linux from complex, non-uniform interfaces.

2. Fixed the GPL copyright issue. Because the Linux kernel is based on the GPL protocol, Android is based on the Apache Licence 2.0 protocol. So Google played a "cross-over" to move the sensitive code that was originally in the Linux drive up one level. That way, these sensitive code is freed from the restrictions of the GPL. Linux-driven authors who don't want to open up will have no need to open up.

3. For a number of special requirements. For some hardware, you may need access to some user-space resources, or work that is inconvenient in kernel space, and special needs. In this case, the HAL code located in the user space can be used to assist the Linux driver to do some work.

Google has added a HAL to the System runtime layer in the Android hierarchy to meet the requirements of these linux-driven authors who do not want open source. HAL is not part of the Linux kernel, but is located at the Android System Runtime layer, and Android is published using the Apache Licence2.0 protocol, and the Apache Licence2.0 protocol does not require the use of Apache-based The software for the source code of the LICENCE2.0 protocol must also be open source. Since HAL is part of Android, it doesn't have to be open source.

The next step is to use the LED driver porting to demonstrate the Linux driver that supports HAL, so let's get an initial look at its steps.

* Write a service called Hal Die Missing

1. Because JNI uses a lot of C + + code, LedHalService.cpp cannot be changed to LEDHALSERVICE.C.

The leds_hat.h header file is referenced in the 2.ledhalservice.cpp file. The file belongs to the HAL module source code file, in the Android.mk file, the Leds__hat.h file is located in the path (Hardware/leds_hal), the ANDROID.MK is specified in the system path, so in the include The document is to be used with angle brackets (< 〉)。

The 3.JNI method has a certain naming convention (java_packagename_classname_methodname) by default, but the JNI method can be customized by registernatives. The last parameter of the method requires specifying the number of JNI functions to register.

4. Use Slieof (methods)/sizeof (Methods[0] To calculate the methods array length, because the number of bytes occupied by each element of the array is equal

(Jninativemethod type, consisting of 3 pointers, 32-bit system and 64-bit system each array element occupies 12 and 24 bytes respectively). So the entire array is occupied by the

The number of bytes divided by the number of bytes consumed by each array element (which is bound to be divisible) is the length of the array.

The element type of the 5.methods array is jninativemethod.

Note: 1. There are two storage paths for HAL module library files:/SYSTEM/LIB/HW and/VENDOR/LIB/HW. The hw_get_ module function looks for the library file from the/SYSTEM/LIB/HW directory based on the library file naming rules. If the library file is not found in the/SYSTEM/LIB/HW directory, the hw_get_ module will look in the/VENDOR/LIB/HW directory as the same rule.

The naming convention for 2.HAL Module library files is ID.suffix.so. Where TD is specified by the ID parameter of the hw_get_ module function. suffix (suffix) is specified through the properties file.

3.HW _get_module will find suffix in the properties file of the Android system according to the 4 keys defined in the Variant_keys array. If suffix is not found, the default suffix is used.

There are 4 properties files for the Android system:

/default.prop;

/system/build.prop;

/system/default.prop;

/data/local.prop.

Android will automatically load these properties files at startup. If the same key and value are defined in multiple property files, only the first key is obtained. For example, the value of Ro.product.board is defined in the/default.prop file as ABC, and the value of Ro.product.board is defined in the/system/build.prop file as XYZ. The Hw_get_ module function then takes ABC from the/default.prop file as a suffix to the HAL Module library file, and no longer reads XYZ from the/system/build.prop file.

There are two ways to use Linux drivers in an Android system. One is to interact directly with Linux drivers in a traditional way. For example, directly read and write data from a device file. The other is Android-specific, which is through the HAL module. The HAL module essentially interacts with the Linux driver through a Linux shared library (. So) and then the application accesses the Linux shared library. Early HAL modules were called by the application directly by accessing the Linux common font. The higher version of the Android system adds a stub to HAL. In other words, for each HAL shared library to specify an ID, and then use this ID with a certain rule to find the Linux common font, so that the Linux common font Exchange file name, moving location is very convenient (because the HAL Shared library path and file name are not dead), Google also recommends using stubs to write HAL modules.

The tenth chapter of embedded Linux call technology

The PRINTK function displays the message in the console (also known as a terminal) through a/dev/console device file, which functions only under the console of the character interface p so the PRINTK function is only used on the console of the character interface to output messages normally. The PRINTK function has been used many times in the previous chapters. The function is similar to the printf function, except that the PRINTK function runs in kernel space and the printf function operates itself in user space. In other words, Linux kernel programs like Linux drivers can only use the PRINTK function to output invocation information.

In Linux file systems,/proc is often used as a tool for data interaction between kernel space and user space. The/proc file system behaves in a similar manner to the device file system (/dev). /proc is a virtual file system, which means that/proc does not

is a real file system, but a memory map. All read-write/PROC operations are read-write to memory. Therefore, reading and writing the/proc file system is much faster than reading/writing the/dev file system. As a result, the/proc file system can also serve as a tool for Linux to interact with user-space programs. There is a lot of system information that is provided to the outside world through the/proc file system by the kernel space program.

* Provides a class of tools in Linux systems. With these tools, you can trace the code of the program line-by-row, just as if the visual development tool is step into and step over.

These tools contain the GDB, Gdbserver, and debug kernel space programs that are used to debug the user-space program kgdb.

Android Deep Exploration (3)