To implement board-level driver adaptation, perform the following steps:
1.Develop the SDK based on the CMSIS/POSIX APIs provided by OpenHarmony.
1. Develop the SDK based on the CMSIS/POSIX APIs provided by OpenHarmony.
The board-level SDK can be adapted to OS interfaces via CMSIS and POSIX APIs. Currently, the LiteOS Cortex-M kernel is adapted to most CMSIS APIs \(including APIs used for basic kernel management, thread management, timer, event, mutex, semaphore, and queue\), which meets the requirements of porting. POSIX APIs provide basic capabilities for porting, and more POSIX APIs are to be implemented. If the SDK is implemented based on the CMSIS or POSIX APIs, it can directly adapt to the LiteOS Cortex-M kernel.
The board-level SDK can be adapted to OS interfaces via CMSIS and POSIX APIs. Currently, the LiteOS Cortex-M kernel is adapted to most CMSIS APIs \(including APIs used for basic kernel management, thread management, timer, event, mutex, semaphore, and queue\), which meets the requirements of porting. POSIX APIs provide basic capabilities for porting, and more POSIX APIs are to be implemented. If the SDK is implemented based on the CMSIS or POSIX APIs, it can directly adapt to the LiteOS Cortex-M kernel.
If the SDK is developed based on other embedded OSs such as FreeRTOS, or has an abstraction layer for OS interfaces, it is recommended that the OS-dependent APIs be directly adapted to the CMSIS APIs.
If the SDK is developed based on other embedded OSs such as FreeRTOS, or has an abstraction layer for OS interfaces, it is recommended that the OS-dependent APIs be directly adapted to the CMSIS APIs.
Here is an OS interface defined by a product for creating a queue:
Here is an OS interface defined by a product for creating a queue:
2. Compile the SDK independently or modify the SDK based on the OpenHarmony building framework and integrate the SDK code into the **device** directory of OpenHarmony as required.
2.Compile the SDK independently or modify the SDK based on the OpenHarmony building framework and integrate the SDK code into the **device** directory of OpenHarmony as required.
After completing the OS API adaptation, you can integrate the board-level driver to OpenHarmony by the following two methods:
After completing the OS API adaptation, you can integrate the board-level driver to OpenHarmony by the following two methods:
- Compile the SDK independently and link it to the OpenHarmony project in the binary format.
- Modify the SDK building framework based on OpenHarmony. Considering the long-term evolution and subsequent joint debugging, you are advised to compile the SDK based on the GN building framework and link it to the OpenHarmony project in the form of source code.
- Compile the SDK independently and link it to the OpenHarmony project in the binary format.
- Modify the SDK building framework based on OpenHarmony. Considering the long-term evolution and subsequent joint debugging, you are advised to compile the SDK based on the GN building framework and link it to the OpenHarmony project in the form of source code.
## How Do I Mount the Heap Memory to the Kernel?<a name="section965418378552"></a>
- The following table describes the macros for configuring the kernel heap memory. You can configure them as required in the **target\_config.h** file.
## How Do I Mount the Heap Memory to the Kernel?
**Table 1** Macros for configuring the kernel heap memory
The following table describes the macros for configuring the kernel heap memory. You can configure them as required in the **target\_config.h** file.
<tdclass="cellrowborder"valign="top"width="60.88%"headers="mcps1.2.3.1.2 "><pid="p5127138175710"><aname="p5127138175710"></a><aname="p5127138175710"></a>Specifies whether the internal kernel heap memory or the user heap memory will be used. The default value is <strongid="b161891157141719"><aname="b161891157141719"></a><aname="b161891157141719"></a>0</strong> and indicates that the internal heap memory whose size is <strongid="b116218121820"><aname="b116218121820"></a><aname="b116218121820"></a>0x10000</strong> will be used. If you want to use the external heap memory, set this macro to <strongid="b2744657141814"><aname="b2744657141814"></a><aname="b2744657141814"></a>1</strong>.</p>
<tdclass="cellrowborder"valign="top"width="60.88%"headers="mcps1.2.3.1.2 "><pid="p65520125619"><aname="p65520125619"></a><aname="p65520125619"></a>Specifies the start address of the kernel heap memory.</p>
<tdclass="cellrowborder"valign="top"width="60.88%"headers="mcps1.2.3.1.2 "><pid="p1030252965619"><aname="p1030252965619"></a><aname="p1030252965619"></a>Specifies the size of the kernel heap memory, that is, size of the memory block specified by <strongid="b1611815991419"><aname="b1611815991419"></a><aname="b1611815991419"></a>LOSCFG_SYS_HEAP_ADDR</strong>.</p>
</td>
</tr>
</tbody>
</table>
**Table 1** Macros for configuring the kernel heap memory
- Note:
| Macro | Description |
| -------- | -------- |
| LOSCFG_SYS_EXTERNAL_HEAP | Specifies whether the internal kernel heap memory or the user heap memory will be used. The default value is **0** and indicates that the internal heap memory whose size is **0x10000** will be used. If you want to use the external heap memory, set this macro to **1**. |
| LOSCFG_SYS_HEAP_ADDR | Specifies the start address of the kernel heap memory. |
| LOSCFG_SYS_HEAP_SIZE | Specifies the size of the kernel heap memory, that is, size of the memory block specified by **LOSCFG_SYS_HEAP_ADDR**. |
Ensure that the specified heap memory range is not used by other modules. Otherwise, functions of the heap memory will be damaged due to the heap memory corruption.
> Ensure that the specified heap memory range is not used by other modules. Otherwise, functions of the heap memory will be damaged due to the heap memory corruption.
@@ -87,7 +87,7 @@ After the build is complete, you can view the built image file in **//out/{*devi
Now, you need to port the Linux kernel to enable it to run successfully.
### 1. Adding a Kernel-built Subsystem to the SoC
### Adding a Kernel-built Subsystem to the SoC
Add the following subsystem configuration to the **//build/subsystem_config.json** file:
...
...
@@ -104,7 +104,7 @@ Add the following subsystem configuration to the **//build/subsystem_config.json
Then, open the configuration file **//vendor/MyProductVendor/MyProduct/config.json** and add the new subsystem to the product.
### 2. Building the Kernel
### Building the Kernel
The OpenHarmony source code provides the Linux kernel 4.19, which is archived in **//kernel/linux-4.19**. This section uses this kernel version as an example to describe how to build the kernel.
...
...
@@ -132,7 +132,7 @@ The expected build result described in the table below.
Now start build, and check whether the kernel image is generated as expected.
...
...
@@ -166,7 +166,7 @@ Now start build, and check whether the kernel image is generated as expected.
## Porting the HDF Driver
### 1. LCD
### LCD
This section describes how to port a Liquid Crystal Display (LCD) driver. The hardware driver framework (HDF) designs a driver model for the LCD. To support an LCD, you must compile a driver, generate a model instance in the driver, and register the instance.
...
...
@@ -220,7 +220,7 @@ root {
For details about driver development, see [LCD](../driver/driver-peripherals-lcd-des.md).
### 2. Touchscreen
### Touchscreen
This section describes how to port a touchscreen driver. The touchscreen driver is stored in the **//drivers/framework/model/input/driver/touchscreen** directory. To port a touchscreen driver, register a **ChipDevice** model instance.
...
...
@@ -280,7 +280,7 @@ Implement the following APIs in **ChipDevice**:
For details about driver development, see [Touchscreen](../driver/driver-peripherals-touch-des.md).
### 3. WLAN
### WLAN
The WLAN driver is divided into two parts. One of the parts manages WLAN devices, and the other part manages WLAN traffic. HDF WLAN provides abstraction for the two parts. Currently, only the WLAN with the SDIO interface is supported.
