# Standard System Porting Guide<a name="EN-US_TOPIC_0000001180064129"></a>
# Standard System Porting Guide
This document describes the general process for porting a development board, rather than the porting process specific to a System on Chip \(SoC\). In the future, the community will provide more development board porting examples for your reference.
## Defining a Development Board<a name="section132mcpsimp"></a>
This document describes the general process for porting a development board, rather than the porting process specific to a System on Chip (SoC). In the future, the community will provide more development board porting examples for your reference.
## Defining a Development Board
This document uses the process of porting a development board named **MyProduct** as an example. This development board is provided by **MyProductVendor** and uses the SoC **MySOC** produced by **MySoCVendor**.
### Defining a Product<a name="section145mcpsimp"></a>
Create a **config.json** file in the directory **//vendor/MyProductVendor/*{product_name}***. This file is used to describe the SoC used by the product and the required subsystems.
### Defining a Product
Create a file named **config.json** in the **//vendor/MyProductVendor/*{product_name}*** directory. This file is used to describe the SoC used by the product and the required subsystems. For example, if **product_name** is **MyProduct**, configure the **//vendor/MyProductVendor/MyProduct/config.json** file as follows:
For example, if **product_name** is **MyProduct**, configure the **//vendor/MyProductVendor/MyProduct/config.json** file as follows:
//vendor/MyProductVendor/MyProduct/config.json
```
...
...
@@ -29,23 +32,22 @@ For example, if **product_name** is **MyProduct**, configure the **//vendor/MyPr
**product_name**: product name. This parameter is required.
**version**: version. This parameter is required.
**type**: system level, which can be **mini**, **small**, or **standard**. This parameter is required.
**type**: system level, such as **small** or **standard**. This parameter is required.
**target_cpu**: CPU type of the device (depending on the actual situation, the target_cpu here may also be arm64, riscv, x86, etc..). This parameter is required.
**target_cpu**: CPU type of the device, such as **arm64**, **riscv**, or **x86**. This parameter is required.
**ohos_version**: operating system version. This parameter is optional.
...
...
@@ -55,33 +57,40 @@ The main configurations are as follows:
**enable_ramdisk**: whether to enable the RAM disk. This parameter is required.
**kernel_type** and **kernel_version**: fixed in the standard system. They are optional.
**kernel_type**: kernel type. This parameter is optional.
**kernel_version**: kernel version. This parameter is optional. Both **kernel_type** and **kernel_version** are fixed.
**subsystems**: subsystem to enable. A subsystem can be treated as an independently built functional block. This parameter is required.
**product_company**: device manufacturer name. It is not set in the configuration, but in the directory name, next to the vendor name. It can be accessed from **build.gn script**.
You can find predefined subsystems in **//build/subsystem\_config.json**. You can also customize subsystems.
You are advised to copy the configuration file of Hi3516D V300 and delete the **hisilicon\_products** subsystem, which is used to compile the kernel for Hi3516D V300.
You can find predefined subsystems in **//build/subsystem_config.json**. You can also customize subsystems.
You are advised to copy the configuration file of Hi3516D V300 and delete the **hisilicon_products** subsystem, which is used to compile the kernel for Hi3516D V300.
### Verifying the Porting<a name="section163mcpsimp"></a>
Run the following command to start the build of your product:
### Verifying the Porting
Run the following command to start the build of your product:
```
./build.sh --product-name MyProduct
```
After the build is complete, you can view the built OpenHarmony image file in **//out/{device_name}/packages/phone/images**.
After the build is complete, you can view the built image file in **//out/{*device_name*}/packages/phone/images**.
## Porting the Kernel<a name="section171mcpsimp"></a>
## Porting the Kernel
Now, you need to port the Linux kernel to enable it to run successfully.
### 1. Adding a Kernel-built Subsystem to the SoC<a name="section174mcpsimp"></a>
Add the following subsystem configuration to the **//build/subsystem\_config.json** file:
### 1. Adding a Kernel-built Subsystem to the SoC
Add the following subsystem configuration to the **//build/subsystem_config.json** file:
```
"MySOCVendor_products": {
...
...
@@ -92,16 +101,18 @@ Add the following subsystem configuration to the **//build/subsystem\_config.jso
},
```
Then, open the configuration file **//vendor/MyProductVendor/MyProduct/config.json**, which is used to define the product, and add the new subsystem to the product.
Then, open the configuration file **//vendor/MyProductVendor/MyProduct/config.json** and add the new subsystem to the product.
### 2. Building the Kernel<a name="section182mcpsimp"></a>
### 2. 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.
The path for building the subsystem is defined when you define the subsystem in the previous step. The path is **//device/MySOCVendor/MySOC/build**. Now, you need to create a build script in this path to instruct the build system to build the kernel.
The path for building the subsystem is defined when you define the subsystem in the previous step. In this example, the path is `//device/MySOCVendor/MySOC/build`. Now, you need to create a build script in this path to instruct the build system to build the kernel.
The recommended directory structure is as follows:
```
├── build
│ ├── kernel
...
...
@@ -113,49 +124,65 @@ The recommended directory structure is as follows:
The **BUILD.gn** file is the only entry for building the subsystem.
Now start build, and check whether the kernel image is generated as expected.
## Porting the HDF Driver<a name="section210mcpsimp"></a>
## User-mode Boot
1. Overview of user-mode boot process
When the system is powered on, the kernel loads and starts services and applications as follows:
1. The kernel loads the init process, which is specified by **cmdline** of the kernel when the bootloader starts the kernel, for example, **init=/init root/dev/xxx**.
2. After the init process is started, **tmpfs** and **procfs** are mounted and basic **dev** nodes are created to establish a basic root file system.
3. The init process starts the ueventd process to listen for device hot-swap events in the kernel and creates **dev** nodes for related devices as well as partitions for the block device.
4. After mounting partitions (**system** and **vendor**) of the block device, the init process scans for the init startup script of each system service and launches the respective service ability (SA).
5. Each SA registers with the samgr process, which serves as the service registration center. The samgr process assigns each SA with an ID, which will be used by an application to access the desired SA.
6. The foundation process implements application lifecycle management. It is a special SA service process that provides the user program management framework and basic services.
7. The appspawn process directly spawns the application process, eliminating the need for the application to load the JS runtime environment. This reduces the application startup time.
2. init module
The configuration file of the init module contains service names, executable file paths, permissions, and other information of all key system services that need to be started by the init process. The boot script of each system service is installed in the **/system/etc/init** directory.
When porting a new chip platform, you need to add the **/vendor/etc/init/init.{hardware}.cfg** file that contains the platform-level initialization configuration. This file is used to implement platform-level initialization, for example, installing the ko driver and configuring information on the related **/proc** nodes.
The code of the init process is stored in the **//base/startup/init_lite** directory. This process is the first process in the system and does not depend on other processes.
For details about how to develop the initialization configuration file, see [Startup](../subsystems/subsys-boot-overview.md).
### 1. LCD<a name="section212mcpsimp"></a>
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.
## Porting the HDF Driver
### 1. 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.
The LCD drivers are stored in the **//drivers/framework/model/display/driver/panel** directory.
- Create a panel driver.
- Create a panel driver.
In the **Init** method of the driver, call **RegisterPanel** to register the model instance.
In the **Init** method of the driver, call **RegisterPanel** to register the model instance.
- Configure and load the panel driver. All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device\_info/device\_info.hcs** file. Modify the file by adding configurations for the device named **device\_lcd** to the host named **display**. Note: The value of **moduleName** must be the same as that in the panel driver.
-Configure and load the panel driver. All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs** file. Modify the file by adding configurations for the device named **device_lcd** to the host named **display**. Note: The value of **moduleName** must be the same as that in the panel driver.
```
root {
...
...
@@ -192,13 +219,15 @@ root {
For details about driver development, see [LCD](../driver/driver-peripherals-lcd-des.md).
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.
- Create a touchscreen driver.
- Create a touchscreen driver.
Create the **touch_ic_name.c** file in the directory. Replace **ic_name** with the name of your chip. The file template is as follows:
Create the **touch\_ic\_name.c** file in the directory. Replace **ic\_name** with the name of your chip. The file template is as follows:
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry250mcpsimpp0"><aname="entry250mcpsimpp0"></a><aname="entry250mcpsimpp0"></a>Initializes a touchscreen.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry253mcpsimpp0"><aname="entry253mcpsimpp0"></a><aname="entry253mcpsimpp0"></a>Detects a touchscreen.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry256mcpsimpp0"><aname="entry256mcpsimpp0"></a><aname="entry256mcpsimpp0"></a>Suspends a touchscreen.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry259mcpsimpp0"><aname="entry259mcpsimpp0"></a><aname="entry259mcpsimpp0"></a>Resumes a touchscreen.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry262mcpsimpp0"><aname="entry262mcpsimpp0"></a><aname="entry262mcpsimpp0"></a>Reads data from a touchscreen and writes the touch point data to <strongid="b109171435105216"><aname="b109171435105216"></a><aname="b109171435105216"></a>device</strong>><strongid="b103219389526"><aname="b103219389526"></a><aname="b103219389526"></a>driver</strong>><strongid="b0459173945212"><aname="b0459173945212"></a><aname="b0459173945212"></a>frameData</strong>.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry265mcpsimpp0"><aname="entry265mcpsimpp0"></a><aname="entry265mcpsimpp0"></a>Upgrades the firmware.</p>
</td>
</tr>
</tbody>
</table>
- Configure the product and load the driver.
All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device\_info/device\_info.hcs** file. Modify the file by adding configurations for the device named **device\_touch\_chip** to the host named **input**. Note: The value of **moduleName** must be the same as that in the touchscreen driver.
Implement the following APIs in **ChipDevice**:
| API| Description|
| -------- | -------- |
| int32_t (\*Init)(ChipDevice \*device) | Initializes a touchscreen.|
| int32_t (\*Detect)(ChipDevice \*device) | Detects a touchscreen.|
| int32_t (\*Suspend)(ChipDevice \*device) | Suspends a touchscreen.|
| int32_t (\*Resume)(ChipDevice \*device) | Resumes a touchscreen.|
| int32_t (\*DataHandle)(ChipDevice \*device) | Reads data from a touchscreen and writes the touch point data to **device** > **driver** > **frameData**.|
| int32_t (\*UpdateFirmware)(ChipDevice \*device) | Upgrades the firmware.|
- Configure the product and load the driver.
All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs** file. Modify the file by adding configurations for the device named **device_touch_chip** to the host named **input**. Note: The value of **moduleName** must be the same as that in the touchscreen driver.
```
deviceN :: deviceNode {
...
...
@@ -279,52 +277,29 @@ Implement the following interfaces in **ChipDevice**:
}
```
For details about driver development, see [TOUCHSCREEN](../driver/driver-peripherals-touch-des.md).
For details about driver development, see [Touchscreen](../driver/driver-peripherals-touch-des.md).
### 3. WLAN<a name="section274mcpsimp"></a>
### 3. 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.
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**.
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"><pid="entry294mcpsimpp0"><aname="entry294mcpsimpp0"></a><aname="entry294mcpsimpp0"></a>Factory of the <strongid="b0602182913593"><aname="b0602182913593"></a><aname="b0602182913593"></a>ChipDriver</strong>, which is used to support multiple WLAN interfaces of a chip.</p>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"><pid="entry299mcpsimpp0"><aname="entry299mcpsimpp0"></a><aname="entry299mcpsimpp0"></a>Manages a specific WLAN interface. Each WLAN interface corresponds to an <strongid="b1364875755918"><aname="b1364875755918"></a><aname="b1364875755918"></a>HdfChipDriver</strong>.</p>
<tdclass="cellrowborder"valign="top"width="33.33333333333333%"><pid="entry304mcpsimpp0"><aname="entry304mcpsimpp0"></a><aname="entry304mcpsimpp0"></a>Communicates with the protocol stack, such as sending data and setting the status of network interfaces.</p>
</td>
</tr>
</tbody>
</table>
**Figure 1** WLAN chip
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**.
| API| Header File| Description|
| -------- | -------- | -------- |
| HdfChipDriverFactory | //drivers/framework/include/wifi/hdf_wlan_chipdriver_manager.h | Supports multiple WLAN interfaces of a chip.|
| HdfChipDriver | //drivers/framework/include/wifi/wifi_module.h | Manages a specific WLAN interface. Each WLAN interface corresponds to an **HdfChipDriver**.|
| NetDeviceInterFace | //drivers/framework/include/net/net_device.h | Communicates with the protocol stack, such as sending data and setting the status of network interfaces.|
To port a WLAN driver, perform the following steps:
1. Create an HDF driver. You are advised to place the code file in the **//device/MySoCVendor/peripheral/wifi/chip\_name/** directory. The file template is as follows:
1. Create an HDF driver. You are advised to place the code file in the **//device/MySoCVendor/peripheral/wifi/chip_name/** directory. The file template is as follows:
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry322mcpsimpp0"><aname="entry322mcpsimpp0"></a><aname="entry322mcpsimpp0"></a>Indicates the driver name.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry325mcpsimpp0"><aname="entry325mcpsimpp0"></a><aname="entry325mcpsimpp0"></a>Initializes a chip.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry328mcpsimpp0"><aname="entry328mcpsimpp0"></a><aname="entry328mcpsimpp0"></a>Deinitializes a chip.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry331mcpsimpp0"><aname="entry331mcpsimpp0"></a><aname="entry331mcpsimpp0"></a>Releases the <strongid="b088418304215"><aname="b088418304215"></a><aname="b088418304215"></a>HdfChipDriverFactory</strong> object.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry334mcpsimpp0"><aname="entry334mcpsimpp0"></a><aname="entry334mcpsimpp0"></a>Creates an <strongid="b1253415231438"><aname="b1253415231438"></a><aname="b1253415231438"></a>HdfChipDriver</strong>. In the input parameters, <strongid="b45408231539"><aname="b45408231539"></a><aname="b45408231539"></a>device</strong> indicates the device information, and <strongid="b1154116231432"><aname="b1154116231432"></a><aname="b1154116231432"></a>ifIndex</strong> indicates the sequence number of this interface in the chip.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry337mcpsimpp0"><aname="entry337mcpsimpp0"></a><aname="entry337mcpsimpp0"></a>Releases the <strongid="b155367141846"><aname="b155367141846"></a><aname="b155367141846"></a>HdfChipDriver</strong>.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry340mcpsimpp0"><aname="entry340mcpsimpp0"></a><aname="entry340mcpsimpp0"></a>Obtains the maximum number of interfaces supported by the current chip.</p>
</td>
</tr>
</tbody>
</table>
Implement the following interfaces in the **HdfChipDriver**.
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry352mcpsimpp0"><aname="entry352mcpsimpp0"></a><aname="entry352mcpsimpp0"></a>Initializes the current network interface. The <strongid="b936614441419"><aname="b936614441419"></a><aname="b936614441419"></a>NetDeviceInterFace</strong> needs to be provided for the <strongid="b1237215441347"><aname="b1237215441347"></a><aname="b1237215441347"></a>netDev</strong>.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry355mcpsimpp0"><aname="entry355mcpsimpp0"></a><aname="entry355mcpsimpp0"></a>Deinitializes the current network interface.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry361mcpsimpp0"><aname="entry361mcpsimpp0"></a><aname="entry361mcpsimpp0"></a>Provides the interface set required for supporting the standalone (STA) mode.</p>
<tdclass="cellrowborder"valign="top"width="50%"><pid="entry364mcpsimpp0"><aname="entry364mcpsimpp0"></a><aname="entry364mcpsimpp0"></a>Provides the interface set required for supporting the access point (AP) mode.</p>
</td>
</tr>
</tbody>
</table>
Create an **HdfChipDriverFactory** in the **CreateChipDriverFactory**. The APIs are as follows:
| API| Description|
| -------- | -------- |
| const char \*driverName | Indicates the driver name.|
| int32_t (\*InitChip)(struct HdfWlanDevice \*device) | Initializes a chip.|
| int32_t (\*DeinitChip)(struct HdfWlanDevice \*device) | Deinitializes a chip.|
| void (*ReleaseFactory)(struct HdfChipDriverFactory *factory) | Releases the **HdfChipDriverFactory** object.|
| struct HdfChipDriver *(_Build)(struct HdfWlanDevice \*device, uint8*t ifIndex) | Creates an **HdfChipDriver**. In the input parameters, **device** indicates the device information, and **ifIndex** indicates the sequence number of this interface in the chip.|
| void (*Release)(struct HdfChipDriver *chipDriver) | Releases the **HdfChipDriver**.|
| uint8_t (\*GetMaxIFCount)(struct HdfChipDriverFactory \*factory) | Obtains the maximum number of APIs supported by the current chip.|
Implement the following APIs in the **HdfChipDriver**.
| API| Description|
| -------- | -------- |
| int32_t (\*init)(struct HdfChipDriver \*chipDriver, NetDevice \*netDev) | Initializes the current network interface. The **NetDeviceInterFace** needs to be provided for the **netDev**.|
| int32_t (\*deinit)(struct HdfChipDriver \*chipDriver, NetDevice \*netDev) | Deinitializes the current network interface.|
| struct HdfMac80211BaseOps \*ops | Provides the WLAN basic capability interface set.|
| struct HdfMac80211STAOps \*staOps | Provides the interface set required for supporting the standalone (STA) mode.|
| struct HdfMac80211APOps \*apOps | Provides the interface set required for supporting the access point (AP) mode.|
2. Compile the configuration file to describe the devices supported by the driver.
Create the chip configuration file **//vendor/MyProductVendor/MyProduct/config/wifi/wlan\_chip\_chip\_name.hcs** in the product configuration directory.
Create the chip configuration file **//vendor/MyProductVendor/MyProduct/config/wifi/wlan_chip_chip_name.hcs** in the product configuration directory.
Replace **MyProductVendor**, **MyProduct**, and **chip\_name** in the path with the actual names.
Replace **MyProductVendor**, **MyProduct**, and **chip_name** in the path with the actual names.
The sample code is as follows:
The sample code is as follows:
```
root {
...
...
@@ -456,7 +372,8 @@ root {
3. Edit the configuration file and load the driver.
All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device\_info/device\_info.hcs** file. Modify the file by adding configurations for the device named **device\_wlan\_chips** to the host named **network**. Note: The value of **moduleName** must be the same as that in the touchscreen driver.
All device information about the product is defined in the **//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs** file. Modify the file by adding configurations for the device named **device_wlan_chips** to the host named **network**. Note: The value of **moduleName** must be the same as that in the touchscreen driver.
```
deviceN :: deviceNode {
...
...
@@ -470,7 +387,7 @@ All device information about the product is defined in the **//vendor/MyProductV
4. Build the driver.
-Create a kernel configuration menu. Create a **Kconfig** file in the **//device/MySoCVendor/peripheral** directory. The file template is as follows:
- Create a kernel configuration menu. Create a **Kconfig** file in the **//device/MySoCVendor/peripheral** directory. The file template is as follows:
```
config DRIVERS_WLAN_XXX
...
...
@@ -483,23 +400,17 @@ config DRIVERS_WLAN_XXX
Add the following sample code to the end of the **//drivers/adapter/khdf/linux/model/network/wifi/Kconfig** file to add the configuration menu to the kernel:
When **DRIVERS\_WLAN\_XXX** is enabled in the kernel, **makefile** in **//device/MySoCVendor/peripheral/build/standard/** is called. For more details, see [WLAN Development](../guide/device-wlan-led-control.md).
For details about the porting sample, see the DAYU development board adaptation guide.
When **DRIVERS_WLAN_XXX** is enabled in the kernel, **makefile** in **//device/MySoCVendor/peripheral/build/standard/** is called. For details about the development, see [LED Peripheral Control](../guide/device-wlan-led-control.md).
