Android Deep Explore HAL Reading notes 8

After reading the eighth chapter of this book, I Learned:

1. A buzzer is a hardware device that comes with a development board that controls the sound of a buzzer by writing a specific value to the register. The PWM driver differs from the LED driver, which consists of multiple files that are compiled at compile time.
2. The buzzer is also called PWM (pulse width modulation), and the basic principle is to control the buzzer's opening and stopping by means of pulses.

The PWM is connected to the TOUT1 port and is controlled using port F's Gpfcon register. The macro S3c64xx_gpfcon represents the virtual address of the Register Gpfcon. PWM is controlled with up to two bits (30, 31 bits) only. Up to two Bits

10 o'clock, turn on PWM and stop PWM for 00 o'clock. Use the IOWRITE32 function to set different values for Gpfcon.

1. Implement buzzer driver: PWM Drive consists of PWM.C, PWM_FUN.C and Pwm_fun.h.

Compiled PWM driver makefile:obj-m: =pwm_driver.o pwm_driver-objs: =PWM.O pwm_file

Link two. c files into PWM_DRIVER.O, and finally generate the. ko file. Perform build.sh script file installation PWM

Drive, and then test the PWM drive to make it sound.

1. Linux-driven code reuse: The Linux driver is divided into several files, the data structure, the function code can be used by multiple drivers.

Static reuse: Use C language, include files can be. Dynamic reuse: One Linux driver uses functions, variables, macros, and so on in another driver.

1. Compiling is a Linux driver that consists of multiple files. C + + language when compiling multiple source files, if 1.c uses 2.c function, need to use extern pre-defined 1.c function in 1.c, extern only in the compilation phase, can be omitted, or use 2.h to define 2.C function, and then include "1.c" in 2.h. If the Linux driver has only one source code file, the value of obj-m in the makefile file can be the same as the source file.
2. Code sharing: module dependencies (export symbols), which are exported in one drive module using the derived symbols (constants, variables, functions) in another drive module.

The Depmod command is used to analyze dependencies between Linux modules, you need to specify all relevant Linux module filenames (absolute paths), use ":" In the Modules.dep file to determine the dependencies of each module, and then load the Linux module with the modprobe command.

1. Force Unload Drive:

① initialization function crashes: The value of the reference counter is inconsistent with the referrer, simply zeroing the reference counter of the current Linux driver module. Use of two functions: Try_module_get (struct module *module), module_put (struct module *module)

② unload function is blocked: The problem is the Unload function, just replace the original unload function with an empty unload function.

In both cases, you need to get the module struct pointer, which represents information about the Linux driver.

Executive Cat/proc/kallsysms | grep _this_module | grep Bad_driver1 Gets the first address of the drive structure.

Since the address of the module struct is in kernel space, only the Linux driver (force_kill_driver) can be written to unload the other driver.

To automate the work, write a build.sh script file to automatically find, intercept, and automate other work on the module structure's first address. Writes the unload-driven command to the script file. Executes the #sh build.sh uninstall the specified Linux driver module.

The Force_kill_driver/bad_driver directory provides two faulty Linux drivers: bad_driver1 (Condition one), Bad_driver2 (condition two). The Bad_driver directory also provides a build.sh script file. Executing the script file will automatically compile and install the two error drivers.

When installing the Force_kill_driver driver to uninstall these two error drivers, you must first install, and then perform two build.sh script files to complete the uninstallation work.

Android Deep Explore HAL Reading notes 8