Process analysis of two load modes of Linux driver

First, the concept of a brief

There are two ways to load drivers under Linux: Static loading and dynamic loading.

Static loading is the driver directly compiled into the kernel, the system can be called directly after booting. The disadvantage of static loading is that debugging is cumbersome, and each time you modify a place to recompile and download the kernel, the efficiency is low. If the driver with static loading is more, it will result in large kernel capacity and waste storage space.

Dynamic loading takes advantage of the Linux module feature, You can add the module (. ko) with the insmod command after the system starts, unload the module with the Rmmod command when it is not needed, use this dynamic loading method to facilitate the debugging of the driver, and can cut the kernel for the function demand of the product, remove the unwanted driver, and greatly reduce the storage capacity of the kernel.

On the desktop, the dynamic loading method is generally used, in the embedded product, the dynamic loading method can be used to debug, and then compile into the kernel after the debugging is successful.

Second, the case analysis

The following is an example of an audio-driven load in Linux, which analyzes the loading process in two ways.

1. Static loading

1) Unzip the kernel, modify the hardware architecture and compiler;

Extract the kernel compressed file linux-2.6.8.1-zzm.tar.bz2 to the/home/sxy/directory, the command is, After extracting the kernel source directory file Linux-2.6.8.1-zzm, enter the directory, edit the makefile file, change Arch to Arm,cross_cpmpile to arm-linux-, as shown:

Exit after saving.

2) Configure the kernel;

In the kernel source tree directory, enter the make Menuconfig command, enter the kernel configuration interface, enter the "load an Alternate configuration file" option, load the profile kernel_2410.cfg, save the exit, as shown in the procedure:

Enter the make Menuconfig command again, edit the sound option, compile it into the kernel (*), and, as shown, save the configuration and exit.

3) compile the kernel;

Enter the make Zimage command in the source tree directory to generate the Zimage image file in the/arch/arm/boot/directory after the compilation is complete.

4) Download kernel

Download the kernel image file Zimage to the Development Board, when the serial terminal displays the following information, it indicates that the driver was loaded successfully.

2. Dynamic loading

1) Unzip the kernel, the process is the same as the static compilation, slightly;

2) Configure the kernel, the previous procedure is the same as the static compile time, re-enter the command make menuconfig, configure the sound option, compile it into a module (M), as shown in the results, Finally save the configuration, exit;

This will compile the sound card driver into a module and dynamically choose whether to load into the kernel.

3) Download kernel

Download the kernel image file Zimage to the board to verify that you can drive the sound card as follows:

Description: First, attach the/home/directory under the virtual machine to the/tmp/directory on the Development Board, and then load the Soundcore.ko and S3c2410-oss.ko Two modules , finally through the lsmod command to see if the driver is loaded, the results show that the load is successful, so that you can program in the application space, audio playback and other operations.

PS : ① Adopt Make menuconfig command, the options * Representative Y , which means the driver is compiled into the kernel; M indicates that the driver is compiled into a module; NULL represents N , which means not compiling;

② kernel files and modules have a lot of things to match, compiler version, source version, compile-time configuration, etc., so when the kernel files are modified, such as modified the driver's compilation options ( Y , M , N ), you must recompile and download the kernel, or you will get an error.

Third, the problems encountered

Issue: During dynamic loading, the following error occurred:

Error: The symbol for registering and unregistering the device is unknown.

Workaround: Look for dependencies, view the definitions of several symbols, find the above functions defined in the Soundcore.c file, and export the symbols, taking REGISTER_SOUND_DSP as an example, as shown in:

So you should load Soundcore.ko first, then load S3c2410-oss.ko.

Note: Dependencies are defined in the Kconfig and makefile files, and the cause of the problem can be found.

June 21, 2014 Saturday 11:25