OpenHarmony uses the multi-kernel (Linux kernel and LiteOS) design and can be deployed on devices with different resource capacities. How to smoothly adapt device drivers to different kernels on the same hardware and minimize the workloads on driver code porting and maintenance is an important issue to address in the OpenHarmony driver subsystem.
The OpenHarmony driver subsystem provides the following features and capabilities to shorten the driver development period and simplify third-party device driver integration:
- Elastic framework capabilities
Based on the traditional driver framework, the OpenHarmony driver subsystem builds elastic framework capabilities to enable deployment on terminal products with memory of hundreds KB to hundreds MB.
- Standardized driver interfaces
The OpenHarmony driver subsystem provides stable driver APIs compatible with the APIs of future-proof smartphones, tablets, smart TVs.
- Component-based driver model
The OpenHarmony driver subsystem provides the component-based driver model to implement more refined driver management. You can add or reduce components as required and focus on the interaction between the hardware and driver. The subsystem also presets some template-based driver model components, such as the network device model.
- Normalized configuration UI
The OpenHarmony driver subsystem provides a unified configuration tool that supports cross-platform configuration conversion and generation, enabling seamless switchover across platforms.
## HDF
The Hardware Driver Foundation (HDF) provides driver framework capabilities, including driver loading, driver service management, and driver messaging mechanism. It strives to build a unified driver platform to back up a more precise and efficient environment for one-time development for multi-device deployment.
The HDF is built in an object-oriented programming model in C language. It provides a unified platform base to support different kernels through platform decoupling and kernel decoupling. The figure below shows the HDF architecture.
**Figure 1** HDF architecture
The HDF consists of the following:
- Hardware Device Interface (HDI) layer: provides unified and stable APIs for hardware operations.
- HDF: provides unified hardware resource management, driver loading management, device node management, device power management, and driver service model. It consists of the device management, service management, Device Host, and PnPManager modules.
- Unified configuration interface (DevEco): supports abstract description of hardware resources, shields hardware differences, and enables development of universal driver code that is not bound to configuration information. You can use HC-Gen to quickly create configuration files. This unified configuration interface improves development and porting efficiency.
- Operating system abstraction layer (OSAL): provides encapsulated kernel operation APIs, including the APIs for the memory, locks, threads, and semaphores, to shield operation differences between different systems.
- Platform driver: provides unified APIs for peripheral drivers to operate board hardware, such as I2C, SPI, and UART buses, and uniformly abstracts the APIs for board hardware operations.
- Peripheral driver model: provides common driver abstraction models for peripheral drivers to provide standard device drivers and implement driver model abstraction. With standard device driver models, you can deploy drivers through configuration without independent development. The driver model abstraction makes the drivers more general by shielding the interaction between drivers and different system components.
## Driver Development
### Platform Drivers
The OpenHarmony platform drivers provide APIs for accessing the operating system and peripheral drivers. The platform devices refer to buses, such as I2C and UART, and specific hardware resources, such as GPIO and RTC. The platform driver framework is an important part of the OpenHarmony driver framework. Based on the HDF, OSAL, and driver configuration and management mechanism, the platform driver framework provides standard models for implementing a variety of platform device drivers. The platform driver framework provides standard platform device access APIs for peripherals regardless of difference in underlying hardware. It also provides unified adaptation APIs for platform device drivers, focusing only their own hardware control.
The platform driver framework provides the following features:
- Unified platform device access interface: encapsulates platform device operation APIs in a unified manner to shield hardware differences between SoC platforms and differences between OSs.
- Unified platform driver adaptation interface: provides unified adaptation APIs for platform device drivers. You only need to focus on the hardware control the driver, without caring about device management and common service processes.
- Common capabilities irrelevant to SoCs, such as device registration, management, and access control.
Currently, the platform driver framework supports devices, including the ADC, DAC, GPIO, HDMI, I2C, I3C, MIPI CSI, MIPI DSI, MMC, pin, PWM, regulator, RTC, SDIO, SPI, UART, and watchdog.
### Peripheral Drivers
Based on the HDF and platform driver framework, OpenHarmony provides common driver models for peripheral drivers. Standard peripheral device drivers help reduce repeated development. In addition, the unified abstraction of peripheral driver models shields the interaction between drivers and different system devices, making the drivers more general for use.
Currently, OpenHarmony supports peripherals covering audio, cameras, codecs, LCD, lights, motion, sensors, touchscreens, vibrators, USB, WLAN, face authentication, fingerprint authentication, PIN authentication, and user authentication.
### Driver Code Repositories
The table below describes the code repositories of the HDF.
**Table 1** HDF code repositories
| Repository| Description|
| -------- | -------- |
| drivers/hdf_core/framework | Provides platform-independent frameworks:<br>- **framework/core**:<br> - Provides capabilities of loading and starting drivers.<br> - Implements elastic deployment and expansion of the driver framework through the object manager.<br>- **framework/model**:<br> Provides driver models, such as the network device model.<br>- **framework/ability**<br> Provides basic driver ability models, such as the I/O communication model.<br>- **framework/tools**:<br> Provides tools for HDI API conversion, and driver configuration and compilation.<br>- **framework/support**<br> Provides platform driver APIs and system APIs with normalized abstraction capabilities.|
| drivers/hdf_core/adapter | Provides adaptation code and build scripts related to LiteOS-M and LiteOS-A kernels and user-mode interface libraries.|
| drivers/hdf_core//adapter/khdf/linux | Provides adaptation code and build scripts related to Linux.|
| drivers/peripheral | Provides the hardware abstraction layer for peripheral modules, such as the display, input, sensor, WLAN, audio, and camera.|
| drivers/interface | Defines the HDI APIs of peripheral modules, such as the display, input, sensor, WLAN, audio, and camera.|
### How to Use
- To adapt the OpenHarmony driver to a new platform device, use the standard models and APIs provided by the OpenHarmony platform driver framework. You only need to focus on hardware control, without caring about the device management and common service processes. For details, see **Platform Driver Development**.
- After the platform driver adaptation, you can use the APIs provided by the OpenHarmony platform driver framework for the system and peripheral drivers to further develop services and applications. For details, see **Platform Driver Usage**.
- The OpenHarmony HDF provides a variety of standard peripheral driver models. These models shield hardware differences and provide stable and standard APIs for upper-layer services. You can use these models to develop peripheral drivers. For details, see **Peripheral Driver Usage**.
The interface through which you interact with an operating system (OS) is the outermost layer of the OS. The most important tasks, like hardware management and system resource allocation, are handled by a module at the core of the OS. This module is called the kernel of the OS.
### Working Principles
An OS is a system software located between applications and hardware. It provides program interfaces and running environments for upper-layer applications and manages underlying hardware resources. Located at a lower layer of the OS, the kernel provides concurrent management of hardware resources for the upper-layer program framework.
**Figure 1** OS architecture
### Multi-Kernel Architecture
There are many kernels in the industry. However, each kernel must have the basic units that provide the following functions:
- Implements data persistence and enables applications to easily access the file system of the persistent data.
- Manages the memory of the process address space.
- Manages multiple processes or tasks.
- Provides the "network" for communication between the OS and another OS.
OpenHarmony supports Linux and LiteOS. You can select OpenHarmony based on product specifications. Both Linux and LiteOS have the basic units, but the implementations are different. The Kernel Abstraction Layer (KAL) provides unified standard APIs for upper-layer applications, shielding the difference between kernels.
The kernel subsystem is located at the lower layer of OpenHarmony. Since OpenHarmony is oriented to devices with different CPUs and storage space, the kernel subsystem supports use of the optimal OS kernel for devices of different resource levels. The KAL shields differences between kernels and provides basic kernel capabilities for the upper layer.
**Figure 2** OpenHarmony architecture
### OpenHarmony Types
OpenHarmony can be classified into the following types based on the supported devices:
- Mini system
The mini system fits into the devices that come with MCU processors, such as Arm Cortex-M and 32-bit RISC-V, and memory greater than or equal to 128 KiB. This system provides a variety of lightweight network protocols, a lightweight graphics framework, and a wide range of read/write components with the Internet of Things (IoT) bus. The mini system applies to smart home products such as LinkIoT module devices and sensors.
- Small system
The small system fits into the devices that come with application processors, such as Arm Cortex-A, and memory greater than or equal to 1 MiB. This system provides higher security capabilities, a standard graphics framework, and video encoding and decoding capabilities. The small system applies to smart home products such as IP cameras, peephole cameras, and routers as well as smart travel products such as event data recorders (EDRs).
- Standard system
The standard system fits into the devices that come with application processors, such as Arm Cortex-A, and memory greater than or equal to 128 MiB. This system provides a complete application framework supporting enhanced interaction, 3D GPU, hardware composer, diverse components, and rich animations. The standard system applies to high-end refrigerator displays.
Different OpenHarmony systems use kernels of different forms. LiteOS applies to mini and small systems. Linux applies to small and standard systems. The table below lists the kernels and applicable systems.
**Table 1** Kernels and applicable systems
| Level| Mini System| Small System| Standard System|
| -------- | -------- | -------- | -------- |
| LiteOS-M | √ | × | × |
| LiteOS-A | × | √ | √ |
| Linux | × | √ | √ |
## LiteOS-M
### Kernel Architecture
OpenHarmony LiteOS-M is a lightweight OS kernel designed for the IoT field. It features small footprint, low power consumption, and high performance. It has a simple code structure, including the minimum kernel function set, kernel abstraction layer, optional components, and project directory. The LiteOS-M kernel is divided into the hardware layer and hardware-irrelevant layers. The hardware layer provides a unified HAL interface for easier hardware adaptation. A range of compilation toolchains can be used with different chip architectures to meet the expansion of diversified hardware and compilation toolchains in the Artificial Intelligence of Things (AIoT) field.
For details about how to use LiteOS-M, see "Usage" in LiteOS-M [Kernel Overview](kernel-mini-overview.md).
## LiteOS-A
### Kernel Architecture
The LiteOS-A kernel mainly applies to small-sized systems. It is oriented to devices with M-level memory and supports memory management unit (MMU) isolation. Similar kernels in the industry include Zircon and Darwin.
To keep pace with the rapid development of the IoT industry, the OpenHarmony lightweight kernel is continuously optimized and expanded to provide application developers with friendly development experience and unified and open ecosystem capabilities. LiteOS-A has the following new features:
- Diversified kernel mechanisms
- Mechanisms such as virtual memory, system call, multi-core, lightweight Inter-Process Communication (IPC), and Discretionary Access Control (DAC) enrich kernel capabilities.
- LiteOS-A supports multiple processes, which allows application memory isolation and improves system robustness.
- Unified HDF
The HDF provides unified driver standards and access mode for device vendors. This simplifies porting of drivers and allows one-time development for multi-device deployment.
- 1200+ standard POSIX APIs
LiteOS-A supports more Portable Operating System Interface (POSIX) APIs, which facilitate software development and porting and improve developers' experience.
- Decoupling between the kernel and hardware
LiteOS-A is highly decoupled from the hardware. New boards can be added without modifying the kernel code.
For details about how to use LiteOS-A, see "Usage" in LiteOS-A [Kernel Overview](kernel-small-overview.md).
## Linux
### Linux Kernel
Evolved from the open-source Linux kernel LTS 4.19.y and 5.10.y, the OpenHarmony Linux kernel has incorporated CVE patches and OpenHarmony features as the kernel baseline. Vendors can complete the kernel adaptation by applying the driver patches for boards.
- For more information about Linux LTS 4.19.y, visit the [official kernel website](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-4.19.y).
- For more information about Linux LTS 5.10.y, visit the [official kernel website](https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/?h=linux-5.10.y).
During the build process, you can merge the driver code based on the chip platform and build the kernel image. All patches are licensed under GNU General Public License (GPL) 2.0.
### Enhanced Kernel Features
OpenHarmony provides the enhanced swap (ESwap), related thread group (RTG), and lightweight CPU isolation features for the Linux kernel.
ESwap
Enhanced Swap (ESwap) allows a custom partition to serve as a swap partition and uses a resident process zswapd to encrypt and swap the anonymous pages compressed by [zram](https://gitee.com/link?target=https%3A%2F%2Fwww.kernel.org%2Fdoc%2Fhtml%2Flatest%2Fadmin-guide%2Fblockdev%2Fzram.html) to the ESwap partition. In this way, a block of memory can be completely released to ensure the available memory (Memavailable) waterline. In addition to this reclaiming mechanism, the entire memory framework is enhanced to improve the reclaiming efficiency of anonymous pages and file pages and streamline the reclaiming ratio of these two types of pages to prevent refaults caused by excessive reclamation.
**RTG**
The RTG provides optimized scheduling of a group of important threads. The load of an RTG can be collected and predicted separately and the preferred CPU cluster can be set to allow the important threads to run on the optimal CPU and the kernel to select a proper CPU frequency based on the group loads.
**Lightweight CPU Isolation**
Lightweight CPU isolation enables dynamic CPU isolation based on the system load and user configuration. The kernel migrates the tasks and interrupts from the isolated CPU to other CPUs for execution. The isolated CPU enters the idle state, which reduces the power consumption. In addition, user-mode configuration and query APIs are provided for better system optimization.
### How to Use
1. Apply HDF patches.
Apply the HDF kernel patches matching your kernel version. For details, see the method in **kernel.mk** in the **kernel/linux/build** repository.
Place the patches for the chip component in the corresponding path based on the path and naming rules for the patches of the chip component in **kernel.mk** in the **kernel/linux/build** repository.
Place the **config** file for the chip component in the corresponding path based on the path and naming rules of the chip component in **kernel.mk** in the **kernel/linux/build** repository.
> In the OpenHarmony project build process, patches are installed after "kernel/linux/linux-\*.\*" is copied. Before using the version-level build command of OpenHarmony, ensure that the "kernel/linux/linux-\*.\*" source code is available.
>
> After the build is complete, the kernel is generated in the kernel directory in the **out** directory. Modify the **config** file based on the kernel generated, and copy the generated **.config** file to the corresponding path in the **config** repository. Then, the configuration takes effect.
@@ -33,7 +31,7 @@ To keep pace with the rapid development of the IoT industry, the OpenHarmony lig
...
@@ -33,7 +31,7 @@ To keep pace with the rapid development of the IoT industry, the OpenHarmony lig
The lightweight kernel consists of the basic kernel, extended components, HDF, and POSIX APIs. Different from the microkernel which is running in the user mode, the extended functions, such as the file system and network protocols, of the lightweight kernel are running in the kernel address space. The direct function calling between components is much faster than inter-process communication \(IPC\) or remote procedure calls \(RPCs\).
The lightweight kernel consists of the basic kernel, extended components, HDF, and POSIX APIs. Different from the microkernel which is running in the user mode, the extended functions, such as the file system and network protocols, of the lightweight kernel are running in the kernel address space. The direct function calling between components is much faster than inter-process communication \(IPC\) or remote procedure calls \(RPCs\).
**Figure 1** Architecture of the OpenHarmony LiteOS-A kernel<aname="fig10235830103519"></a>
**Figure 1** Architecture of the OpenHarmony LiteOS-A kernel<aname="fig10235830103519"></a>
