Android Deep Exploration with Hal Drive Development (Vol. 1)--seventh chapter essay

application, library, kernel, driver relationships

From top to bottom, a software system can be divided into: applications, libraries, operating systems (kernels), drivers. Developers can focus on their familiar parts, and for adjacent layers, they only need to know its interface, without needing to focus on its implementation details. To highlight LEDs, the 4-tier software collaboration is as follows:

1. The application uses the Open function provided by the library to open the device file that represents the LED.

2, the Library data open function passed the parameter to execute "SWI" instruction, this instruction will cause CPU abnormal, into the kernel.

3. The kernel's exception handling function finds the appropriate driver based on these parameters, returns a file handle to the library, and returns it to the application.

4. After the application obtains the file handle, it uses the control command issued by the write or IOCLT function provided by the library.

5. The library executes the "SWI" instruction according to the parameters passed in by the write or IOCLT function, which causes an exception and enters the kernel.

6. The kernel's exception handling function calls the driver's correlation function according to these parameters, and lights the LEDs.

7, libraries (such as GLIBC) to the application to provide open, read, write, IOCTL, mmap and other interface functions are called system calls, they are set up the relevant registers, execute an instruction to throw an exception into the kernel. For the CPU of the ARM architecture, this directive is SWI. In addition to the system call interface, the library provides other functions such as string processing functions (strepy, strcmp, etc.), input/output functions (scanf, printf, etc.), databases, and application startup code. In the exception handler, the kernel performs various actions based on the parameters passed in, such as locating the corresponding driver according to the device filename, invoking the driver's correlation function, and so on.

The realization principle of LED drive

Although the Linux driver deals directly with hardware, it is not the Linux driver that writes data directly to the memory in the hardware, but interacts with the native I/O memory (I/O memories, which are located in the kernel space). So-called I/O memory is a variety of excuses (PCI, USB, Bluetooth, Ethernet port, etc.) connected to the host (PC, mobile phone) hardware (network card, sound card, camera, etc.)

The mappings in host memory. For example, a driver running on Ubuntu Linux only needs to access I/O memory in a host running Ubuntu Linux, and then the Linux kernel interacts with the data hardware in I/O memory.

The Linux kernel provides several functions that interact with I/O memory, such as IOREAD16,IOREAD32,IOWRITE16,IOWRITE32. The memory management module of the Linux kernel is responsible for synchronizing the data in I/O memory and hardware. Principle

Every hardware that connects to Linux has a map header address in I/O memory. You need to specify these first addresses when reading and writing I/O memory using functions such as IOREAD32, Iowrite32, and so on. The LEDs on the Development Board also have their mapping first address.

Android Deep Exploration with Hal Drive Development (Vol. 1)--seventh chapter essay