@@ -73,11 +73,11 @@ kernel_version = "3.0.0" --- Kernel version, which corresponds to
Run the `hb set` command, enter the project root directory, and press `Enter`. The `hb` command traverses all `config.json` files in the `//vendor/<product_company>/<product_name>` directory and provides product compilation options. In the `config.json` file, `product_name` indicates the product name, `device_company` and `board` are used to locate the `//device/board/<device_company>/<board>` directory and find the matching `<any_dir_name>/config.gni` file. If multiple file matches are found, it indicates that the board has been adapted to multiple kernels. In this case, `kernel_type` and `kernel_version` in the `config.json` file can be used to uniquely match the `config.gni` file and thereby determine the board with which kernel needs to be compiled and adapted. If the information shown below is displayed, the `hb set` configuration is correct.
You can run the `hb env` command to view the selected precompilation environment variables.
Before running the `hb build` command, complete the LiteOS-M kernel adaptation. For details, see [Kernel Porting](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/porting/porting-bes2600w-on-minisystem-display-demo.md#%E5%86%85%E6%A0%B8%E7%A7%BB%E6%A4%8D).
...
...
@@ -263,7 +263,7 @@ In this example, the configuration file of `defconfig` is saved in `$(PRODUCT_PA
When the configuration is complete, run the `make menuconfig` command in the `kernel/liteos_m` directory to select `SoC Series`/`SoC`/`Board`.
The result is automatically saved in `$(PRODUCT_PATH)/kernel_configs/debug.config` and will be exported when `make menuconfig` is executed.
In the mini system, adapting the C library is a complex process. For details, see *Solution to Smooth Switchover Between musl and newlib for LiteOS-M Kernel*. The toolchain uses the `newlib` C library of the [gcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2](https://gitee.com/link?target=https%3A%2F%2Fdeveloper.arm.com%2F-%2Fmedia%2FFiles%2Fdownloads%2Fgnu-rm%2F10.3-2021.10%2Fgcc-arm-none-eabi-10.3-2021.10-x86_64-linux.tar.bz2). In light of this, the `newlib` C library is used for system porting. Select `newlib` in `make menuconfig` of the kernel, as shown below.
In the **startup.S** file, you must ensure that the entry function \(for example, **reset\_vector**\) of the interrupt vector table is stored in the RAM start address specified by the link configuration files. The link configuration files of IAR, Keil, and GCC projects are **xxx.icf**, **xxx.sct**, and **xxx.ld**, respectively. The startup file provided by the vendor does not need to be modified if the **startup.S** file has initialized the system clock and returned to the **main** function. Otherwise, the preceding functions need to be implemented.
...
...
@@ -34,6 +34,7 @@ The following table shows some typical configuration items:
@@ -12,7 +12,7 @@ For easy description, we divide the OpenHarmony architecture into two parts:
OpenHarmony = Kernel mode layer + User mode layer
The kernel mode layer is the OpenHarmony kernel layer \(purple part in the figure\). It consists of the kernel, such as Linux Kernel and LiteOS, and features, such as Hardware Driver Foundation \(HDF\), running in the kernel mode.
...
...
@@ -35,7 +35,7 @@ Therefore, the OpenHarmony kernel mode layer includes the following:
- OpenHarmony basic kernel-mode code
- OpenHarmony kernel-mode features, such as HDF
The standard LTS Linux kernel and third-party SoC chip platform code constitute the basis of a third-party Linux kernel. The OpenHarmony kernel mode layer can be composed of either of the following:
...
...
@@ -175,7 +175,7 @@ For details about how to use the logs, see [Hilog\_lite](https://gitee.com/open
The configuration \(in **Device Drivers** \> **HDF driver framework support**\) is as follows:
### Building the Image<a name="section1681965561911"></a>
As shown in [Figure 1](#fig155920160203), the part on the left manages WLAN devices, and the part on the right manages WLAN traffic. The HDF WLAN framework abstracts these two parts. The porting process of the driver can be considered as the implementation of the APIs required by the two parts. These APIs are described as follows:
Drivers can be classified as platform drivers or device drivers. The platform drivers are generally in the SoC, such as the GPIO, I2C, and SPI drivers. The device drivers are typically outside of the SoC, such as the LCD, TP, and WLAN drivers.
The Hardware Driver Foundation \(HDF\) is designed to work across OSs. The HDF driver framework provides strong support for drivers to achieve this goal. During HDF driver development, you are advised to use only the APIs provided by the HDF driver framework. Otherwise, the driver cannot be used across OSs. Before driver development, familiarize yourself with the [HDF](../driver/driver-hdf-overview.md).
- Implementing the **main** function for basic kernel initialization and initialization of services in the board kernel space. [Figure 3](#fig32611728133919) shows the initialization process, where the kernel startup framework takes the lead in the initialization process. The light blue part in the figure indicates the phase in which external modules can be registered and started in the startup framework.
...
...
@@ -116,7 +116,7 @@ As can be seen from preceding figure, kernel basic adaptation involves the follo
>Modules at the same layer cannot depend on each other.
@@ -54,7 +54,7 @@ You can use the Bootloader provided by the chipset vendor or open-source U-Boot
Debug the **init** process, start shell, and run a simple program in the user space to check whether the kernel porting is successful. Below is the OS image structure of the OpenHarmony [small system](../quick-start/quickstart-lite-overview.md) and the Linux user-space program startup process.
**Figure 1** OS image structure and user-space program startup process based on the Linux kernel<aname="fig91631652715"></a>
2. Mount the **nfs** directory and put the executable file **cctest** into the **test** directory \(listed in [Table 2](#table1452412391911)\) to the **nfs** directory.
@@ -277,7 +277,7 @@ For details about driver development, see [TOUCHSCREEN](../driver/driver-periph
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.
To support a chip, implement a **ChipDriver** for it. The major task is to implement the following interfaces provided by **HDF\_WLAN\_CORE** and **NetDevice**.
@@ -148,7 +148,7 @@ To remotely access the Ubuntu environment through Windows and enjoy the benefits
### Installing Remote SSH
1. Open Visual Studio Code in Windows, click , and search for **remote-ssh** in the Extension Marketplace.
1. Open Visual Studio Code in Windows, click , and search for **remote-ssh** in the Extension Marketplace.
@@ -148,7 +148,7 @@ To remotely access the Ubuntu environment through Windows and enjoy the benefits
### Installing Remote SSH
1. Open Visual Studio Code in Windows, click , and search for **remote-ssh** in the Extension Marketplace.
1. Open Visual Studio Code in Windows, click , and search for **remote-ssh** in the Extension Marketplace.
