Android deep exploration and HAL-driven development (Volume 1)-Chapter 7, android-driven development

Android deep exploration and HAL-driven development (Volume 1)-Chapter 7, android-driven development
Relationship between applications, libraries, kernels, and drivers

From top to bottom, a software system can be divided into applications, libraries, operating systems (kernels), and drivers. Developers can focus on what they are familiar with. For adjacent layers, they only need to understand their interfaces, without paying attention to its implementation details. Taking the LED lighting as an example, the collaboration between the four-layer software is as follows:

 

1. The application uses the open function provided by the Library to open the device file representing the LED.

2. Execute the "swi" command for the parameters passed in by the open function of the database data. This command causes CPU exceptions and enters the kernel.

3. the kernel exception handling function finds the corresponding Driver Based on these parameters, returns a file handle to the database, and then returns it to the application.

4. After the application obtains the file handle, it uses the write or ioclt function provided by the database to issue the control command.

5. The database executes the "swi" command based on the parameters passed in by the write or ioclt function. This command causes an exception and enters the kernel.

6. the kernel exception handling function calls the relevant functions of the Driver Based on these parameters to light up the LED.

7. The open, read, write, ioctl, mmap, and other interface functions provided by libraries (such as glibc) to applications are called system calls, an exception occurs when a command is executed to enter the kernel. For the CPU Of the ARM architecture, this command is swi. In addition to System Call interfaces, the Library also provides other functions, such as string processing functions (strepy, strcmp, etc.), input/output functions (scanf, printf, etc.), and databases, and the startup code of the application. In exception handling functions, the Kernel performs various operations based on input parameters, such as finding the corresponding Driver Based on the device file name and calling the relevant functions of the driver.

 

Implementation principle of LED Driver

Although the Linux driver directly deals with hardware, it is not the Linux driver that writes data directly to the Memory in the hardware, but the local I/O Memory (I/O Memory, located in the kernel space). The so-called I/O memory is the hardware (NIC, sound card, camera, etc.) connected to the host (PC, mobile phone) through various excuses (PCI, USB, Bluetooth, Ethernet port, etc)

Ing in host memory. For example, a driver running on Ubuntu Linux only needs to access the I/O memory of the host running Ubuntu Linux. Then, the Linux kernel uses the data hardware in the I/O memory for interaction.

The Linux Kernel provides multiple I/O memory interaction functions, such as ioread16, ioread32, iowrite16, and iowrite32. The memory management module of Linux kernel is responsible for synchronizing data in I/O memory and hardware. Principle

 

Each hardware connected to Linux has a mapped first address in I/O memory. When using functions such as ioread32 and iowrite32 to read and write I/O memory, you need to specify these first addresses. The LEDs on the Development Board also have their first mapped address.