同步操作将从 OpenHarmony/docs 强制同步,此操作会覆盖自 Fork 仓库以来所做的任何修改,且无法恢复!!!
确定后同步将在后台操作,完成时将刷新页面,请耐心等待。
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.
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.
Create a JSON file named after the SoC name in the //productdefine/common/device directory and specify the CPU architecture.
For example, to port MySOC, which uses a 32-bit ARM kernel, configure the file as follows:
//productdefine/common/device/MySOC.json
{
"target_os": "ohos",
"target_cpu": "arm"
}
Currently, target_cpu can be set to arm only. In the future, you can set the value depending on the CPU architecture, such as arm64, riscv, or x86.
Create a JSON file named after the product name in the //productdefine/common/products directory. This file is used to describe the SoC used by the product and the required subsystems. Configure the file as follows:
//productdefine/common/products/MyProduct.json
{
"product_name": "MyProduct",
"product_company" : "MyProductVendor",
"product_device": "MySOC",
"version": "2.0",
"type": "standard",
"parts":{
"ace:ace_engine_standard":{},
"ace:napi":{},
...
"xts:phone_tests":{}
}
}
The main configurations are as follows:
You can find available 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.
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/ohos-arm-release/packages/phone/images.
Now, you need to port the Linux kernel to enable it to run successfully.
Add the following subsystem configuration to the //build/subsystem_config.json file:
"MySOCVendor_products": {
"project": "hmf/MySOCVendor_products",
"path": "device/MySOCVendor/MySOC/build",
"name": "MySOCVendor_products",
"dir": "device/MySOCVendor"
},
Then, open the configuration file //productdefine/common/products/MyProduct.json, which is used to define the product, and add the new subsystem to the product.
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 recommended directory structure is as follows:
├── build
│ ├── kernel
│ │ ├── linux
│ │ ├──standard_patch_for_4_19.patch // Patch for the Linux kernel 4.19
│ ├── BUILD.gn
│ ├── ohos.build
The BUILD.gn file is the only entry for building the subsystem.
The expected build result is as follows:
Now start build, and check whether the kernel image is generated as expected.
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.
In the Init method of the driver, call RegisterPanel to register the model instance.
int32_t XXXInit(struct HdfDeviceObject *object)
{
struct PanelData *panel = CreateYourPanel();
// Register the model instance.
if (RegisterPanel(panel) != HDF_SUCCESS) {
HDF_LOGE("%s: RegisterPanel failed", __func__);
return HDF_FAILURE;
}
return HDF_SUCCESS;
}
struct HdfDriverEntry g_xxxxDevEntry = {
.moduleVersion = 1,
.moduleName = "LCD_XXXX",
.Init = XXXInit,
};
HDF_INIT(g_xxxxDevEntry);
root {
...
display :: host {
device_lcd :: device {
deviceN :: deviceNode {
policy = 0;
priority = 100;
preload = 2;
moduleName = "LCD_XXXX";
}
}
}
}
For details about driver development, see LCD.
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 the touch_ic_name.c file in the directory. Replace ic_name with the name of your chip. The file template is as follows:
#include "hdf_touch.h"
static int32_t HdfXXXXChipInit(struct HdfDeviceObject *device)
{
ChipDevice *tpImpl = CreateXXXXTpImpl();
if(RegisterChipDevice(tpImpl) != HDF_SUCCESS) {
ReleaseXXXXTpImpl(tpImpl);
return HDF_FAILURE;
}
return HDF_SUCCESS;
}
struct HdfDriverEntry g_touchXXXXChipEntry = {
.moduleVersion = 1,
.moduleName = "HDF_TOUCH_XXXX",
.Init = HdfXXXXChipInit,
};
HDF_INIT(g_touchXXXXChipEntry);
Implement the following interfaces in ChipDevice:
Reads data from a touchscreen and writes the touch point data to device > driver > frameData. |
|
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 {
policy = 0;
priority = 130;
preload = 0;
permission = 0660;
moduleName = "HDF_TOUCH_XXXX";
deviceMatchAttr = "touch_XXXX_configs";
}
For details about driver development, see TOUCHSCREEN.
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.
To port a WLAN driver, perform the following steps:
static int32_t HdfWlanHisiChipDriverInit(struct HdfDeviceObject *device) {
static struct HdfChipDriverFactory factory = CreateChipDriverFactory();
struct HdfChipDriverManager *driverMgr = HdfWlanGetChipDriverMgr();
if (driverMgr->RegChipDriver(&factory) != HDF_SUCCESS) {
HDF_LOGE("%s fail: driverMgr is NULL!", __func__);
return HDF_FAILURE;
}
return HDF_SUCCESS;
}
struct HdfDriverEntry g_hdfXXXChipEntry = {
.moduleVersion = 1,
.Init = HdfWlanXXXChipDriverInit,
.Release = HdfWlanXXXChipRelease,
.moduleName = "HDF_WIFI_CHIP_XXX"
};
HDF_INIT(g_hdfXXXChipEntry);
Create an HdfChipDriverFactory in the CreateChipDriverFactory. The interfaces are as follows:
Implement the following interfaces in the HdfChipDriver.
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.
The sample code is as follows:
root {
wlan_config {
chip_name :& chipList {
chip_name :: chipInst {
match_attr = "hdf_wlan_chips_chip_name"; /* Configure the matching attribute, which is used to provide the configuration root of the driver.*/
driverName = "driverName"; /* The value must be the same as that of driverName in HdfChipDriverFactory.*/
sdio {
vendorId = 0x0296;
deviceId = [0x5347];
}
}
}
}
}
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 {
policy = 0;
preload = 2;
moduleName = "HDF_WLAN_CHIPS";
deviceMatchAttr = "hdf_wlan_chips_chip_name";
serviceName = "driverName";
}
config DRIVERS_WLAN_XXX
bool "Enable XXX WLAN Host driver"
default n
depends on DRIVERS_HDF_WIFI
help
Answer Y to enable XXX Host driver. Support chip 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:
source "../../../../../device/MySoCVendor/peripheral/Kconfig"
Create a build script.
Add the following configuration to the end of the //drivers/adapter/khdf/linux/model/network/wifi/Makefile file:
HDF_DEVICE_ROOT := $(HDF_DIR_PREFIX)/../device
obj-$(CONFIG_DRIVERS_WLAN_XXX) += $(HDF_DEVICE_ROOT)/MySoCVendor/peripheral/build/standard/
When DRIVERS_WLAN_XXX is enabled in the kernel, makefile in //device/MySoCVendor/peripheral/build/standard/ is called. For more details, see WLAN Development.
For details about the porting sample, see the DAYU development board adaptation guide.
此处可能存在不合适展示的内容,页面不予展示。您可通过相关编辑功能自查并修改。
如您确认内容无涉及 不当用语 / 纯广告导流 / 暴力 / 低俗色情 / 侵权 / 盗版 / 虚假 / 无价值内容或违法国家有关法律法规的内容,可点击提交进行申诉,我们将尽快为您处理。