Skip to content

D
Docs

OpenHarmony / Docs
1 年多 前同步成功

通知 159
Star 292
Fork 28
D
Docs
提交 00bc1928 编写于 作者: D duangavin123
浏览文件
操作

update 导入OpenHarmony工程 

Signed-off-by: Nduangavin123 <duanxichao@huawei.com>
上级 bac9ba16
展开全部 隐藏空白更改
内联 并排
Showing with 1320 addition and 500 deletion
zh-cn/device-dev/porting/Readme-CN.md
浏览文件 @ 00bc1928
<<<<<<< HEAD
# 开发板移植
目前OpenHarmony已经成立了SIG组[sig-devboard](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard_cn.md)。该SIG组以支持更多第三方开发板为目标，提供开发板移植的支撑。
......@@ -23,37 +22,7 @@ repo init -u https://gitee.com/openharmony-sig/manifest.git -b master -m devboar
# 2. 开始移植你的开发板
- [轻量级系统](lite_system_port_guide.md)
- 小型系统（待发布）
- [轻量级系统](transplant-minichip.md)
- [小型系统](transplant-smallchip.md)
- [标准系统](standard_system_porting_guide.md)
=======
# 开发板移植
目前OpenHarmony已经成立了SIG组[sig-devboard](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard_cn.md)。该SIG组以支持更多第三方开发板为目标，提供开发板移植的支撑。
在了解开发板移植前，需要先了解一下OpenHarmony对设备的分类。不同设备类型的移植方法会有较大差异。
| 设备类型 | 硬件要求 | 支持的内核 |
|---------|-------------|----------------|
| 轻量系统类设备 | 内存>128KB | LiteOS-M |
| 小型系统类设备 | 内存>1MB、有MMU | LiteOS-A、Linux |
| 标准系统类设备 | 内存>128MB | Linux |
# 1. 代码准备
目前OpenHarmony已经为各厂家创建了仓库并在openharmony-sig中进行孵化。参与孵化仓开发，需要使用如下方法初始化和下载代码。
```shell
repo init -u https://gitee.com/openharmony-sig/manifest.git -b master -m devboard.xml --no-repo-verify
```
其他下载步骤与主线相同。
# 2. 开始移植你的开发板
- [轻量级系统](lite_system_port_guide.md)
- 小型系统（待发布）
- [标准系统](standard_system_porting_guide.md)
>>>>>>> 2969611b3e2a25755ebcd7f632c8fe3f7f0c615f
zh-cn/device-dev/porting/lite_system_port_guide.md 已删除 100644 → 0
浏览文件 @ bac9ba16
# 移植指南
- [三方库移植指导](三方库移植指导.md)
- [概述](概述.md)
- [CMake方式组织编译的库移植](CMake方式组织编译的库移植.md)
- [Makefile方式组织编译的库移植](Makefile方式组织编译的库移植.md)
- [三方芯片移植指导](三方芯片移植指导.md)
- [移植准备](移植准备.md)
- [移植须知](移植须知.md)
- [编译构建适配流程](编译构建适配流程.md)
- [内核移植](内核移植.md)
- [移植概述](移植概述.md)
- [内核基础适配](内核基础适配.md)
- [内核移植验证](内核移植验证.md)
- [板级系统移植](板级系统移植.md)
- [移植概述](移植概述-0.md)
- [板级驱动适配](板级驱动适配.md)
- [HAL层实现](HAL层实现.md)
- [系统组件调用](系统组件调用.md)
- [三方组件适配](三方组件适配.md)
- [XTS认证](XTS认证.md)
- [常见问题](常见问题.md)
zh-cn/device-dev/porting/standard_system_porting_guide.md
浏览文件 @ 00bc1928
<<<<<<< HEAD
# 标准系统移植指南
<!-- @import "[TOC]" {cmd="toc" depthFrom=2 depthTo=6 orderedList=false} -->
......@@ -373,379 +372,3 @@ obj-$(CONFIG_DRIVERS_WLAN_XXX) += $(HDF_DEVICE_ROOT)/MySoCVendor/peripheral/buil
更多详细的开发手册，请参考[WLAN开发](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/WLAN.md)
=======
# 标准系统移植指南
<!-- @import "[TOC]" {cmd="toc" depthFrom=2 depthTo=6 orderedList=false} -->
<!-- code_chunk_output -->
- [定义开发板](#定义开发板)
- [1. 定义SOC](#1-定义soc)
- [2. 定义产品](#2-定义产品)
- [3. 移植验证](#3-移植验证)
- [内核移植](#内核移植)
- [1. 为SOC添加内核构建的子系统](#1-为soc添加内核构建的子系统)
- [2. 编译内核](#2-编译内核)
- [3. 移植验证](#3-移植验证-1)
- [HDF驱动移植](#hdf驱动移植)
- [1. LCD](#1-lcd)
- [2. 触摸屏](#2-触摸屏)
- [3. WLAN](#3-wlan)
<!-- /code_chunk_output -->
## 定义开发板
本文以移植名为MyProduct的开发板为例讲解移植过程，假定MyProduct是MyProductVendor公司的开发板，使用MySoCVendor公司生产的MySOC芯片作为处理器。
### 1. 定义SOC
在`//productdefine/common/device`目录下创建以SOC名字命名的json文件，并指定CPU的架构。
如要移植一个叫MySOC的SOC，这个SOC采用32位ARM内核。配置如下：
`//productdefine/common/device/MySOC.json`
```json
{
"target_os": "ohos",
"target_cpu": "arm"
}
```
根据实际情况，这里的target_cpu也可能是arm64 、riscv、 x86等。当前仅支持arm作为target_cpu。
### 2. 定义产品
在`//productdefine/common/products`目录下创建以产品名命名的json文件。该文件用于描述产品所使用的SOC 以及 所需的子系统。
配置如下
`//productdefine/common/products/MyProduct.json`
```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":{}
}
}
```
主要的配置内容包括：
1. `product_device`：配置所使用的SOC
2. `type`： 配置系统的级别， 这里直接standard即可
3. `parts`： 系统需要启用的子系统。子系统可以简单理解位一块独立构建的功能块。
已定义的子系统可以在`//build/subsystem_config.json`中找到。当然你也可以定制子系统。
这里建议先拷贝Hi3516DV300 开发板的配置文件，删除掉 hisilicon_products 这个子系统。这个子系统为Hi3516DV300 SOC编译内核，显然不适合MySOC。
### 3. 移植验证
至此，你可以使用如下命令，启动你产品的构建了：
`./build.sh --product-name MyProduct `
构建完成后，可以在如下目录看到构建出来的OpenHarmony镜像文件
`//out/ohos-arm-release/packages/phone/images`
## 内核移植
这一步需要移植Linux内核，让Linux内核可以成功运行起来。
### 1. 为SOC添加内核构建的子系统
修改文件 `//build/subsystem_config.json` 增加一个子系统. 配置如下：
```json
"MySOCVendor_products": {
"project": "hmf/MySOCVendor_products",
"path": "device/MySOCVendor/MySOC/build",
"name": "MySOCVendor_products",
"dir": "device/MySOCVendor"
},
```
接着需要修改定义产品的配置文件`//productdefine/common/products/MyProduct.json`。将刚刚定义的子系统加入到产品中
### 2. 编译内核
在上一节定义subsystem的时候，定义了构建的路径path，即`//device/MySOCVendor/MySOC/build`。这一节会在这个目录创建构建脚本，告诉构建系统如何构建内核。
目前OpenHarmony源码中提供了Linux 4.19的内核，归档在`//kernel/linux-4.19`。请尽可能使用这个内核。
每个SOC必然需要对内核做一些修改或扩展，建议采用补丁的方式。
建议的目录结构
```
├── build
│   ├── kernel
│   │ ├── linux
│   │ ├──standard_patch_for_4_19.patch
│   ├── BUILD.gn
│   ├── ohos.build
```
BUILD.gn是subsystem构建的唯一入口。
期望的构建结果
| 文件 | 文件说明|
|------|------|
|$root_build_dir/packages/phone/images/uImage| 内核镜像|
|$root_build_dir/packages/phone/images/uboot | bootloader镜像|
### 3. 移植验证
启动编译，验证预期的kernel镜像是否成功生成。
## HDF驱动移植
### 1. LCD
HDF为LCD设计了驱动模型。支持一块新的LCD，需要编写一个驱动，在驱动中生成模型的实例，并完成注册。
这些LCD的驱动被放置在`//drivers/framework/model/display/driver/panel`目录中。
- 创建Panel驱动
在驱动的Init方法中，需要调用RegisterPanel接口注册模型实例。如:
```C
int32_t XXXInit(struct HdfDeviceObject *object)
{
struct PanelData *panel = CreateYourPanel();
// 注册
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);
```
- 配置加载panel驱动
产品的所有设备信息被定义在文件`//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs`中。修改该文件，在display的host中，名为device_lcd的device中增加配置。
注意：moduleName 要与panel驱动中的moduleName相同。
```hcs
root {
...
display :: host {
device_lcd :: device {
deviceN :: deviceNode {
policy = 0;
priority = 100;
preload = 2;
moduleName = "LCD_XXXX";
}
}
}
}
```
更详细的驱动开发指导，请参考 [LCD](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/LCD.md)
### 2. 触摸屏
本节描述如何移植触摸屏驱动。触摸屏的驱动被放置在`//drivers/framework/model/input/driver/touchscreen`目录中。移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。
- 创建触摸屏器件驱动
在目录中创建名为`touch_ic_name.c`的文件。代码模板如下：
注意：请替换ic_name为你所适配芯片的名称
```C
#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);
```
其中ChipDevice中要提供若干方法
| 方法| 实现说明|
|------|------|
|int32_t (*Init)(ChipDevice *device)| 器件初始化|
|int32_t (*Detect)(ChipDevice *device)| 器件探测|
|int32_t (*Suspend)(ChipDevice *device)| 器件休眠|
|int32_t (*Resume)(ChipDevice *device)| 器件唤醒|
|int32_t (*DataHandle)(ChipDevice *device)| 从器件读取数据，将触摸点数据填写入device->driver->frameData中|
|int32_t (*UpdateFirmware)(ChipDevice *device)| 固件升级|
- 配置产品，加载器件驱动
产品的所有设备信息被定义在文件`//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs`中。修改该文件，在名为input的host中，名为device_touch_chip的device中增加配置。
注意：moduleName 要与触摸屏驱动中的moduleName相同。
```hcs
deviceN :: deviceNode {
policy = 0;
priority = 130;
preload = 0;
permission = 0660;
moduleName = "HDF_TOUCH_XXXX";
deviceMatchAttr = "touch_XXXX_configs";
}
```
更详细的驱动开发指导，请参考 [TOUCHSCREEN](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/TOUCHSCREEN.md)
### 3. WLAN
![tu](./figures/HDF_WIFI.png)
Wi-Fi驱动分为两部分，一部分负责管理WLAN设备，另一个部分负责处理WLAN流量。`HDF WLAN`分别为这两部分做了抽象。目前支持SDIO接口的WLAN芯片
主要需要实现的接口有:
| 接口| 定义头文件| 说明|
|------|------|------|
| HdfChipDriverFactory| `//drivers/framework/include/wifi/hdf_wlan_chipdriver_manager.h`| ChipDriver的Factory，用于支持一个芯片多个Wi-Fi端口|
| HdfChipDriver | `//drivers/framework/include/wifi/wifi_module.h`| 每个WLAN端口对应一个HdfChipDriver，用来管理一个特定的WLAN端口|
|NetDeviceInterFace| `//drivers/framework/include/wifi/net_device.h`| 与协议栈之间的接口，如发送数据、设置网络接口状态等|
建议适配按如下步骤操作：
1. 创建HDF驱动
建议将代码放置在`//device/MySoCVendor/peripheral/wifi/chip_name/`
```C
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);
```
在CreateChipDriverFactory中，需要创建一个HdfChipDriverFactory
| 接口| 说明|
|------|------|
|const char *driverName| 当前driverName |
|int32_t (*InitChip)(struct HdfWlanDevice *device)| 初始化芯片|
|int32_t (*DeinitChip)(struct HdfWlanDevice *device)| 去初始化芯片|
|void (*ReleaseFactory)(struct HdfChipDriverFactory *factory)| 释放HdfChipDriverFactory对象|
|struct HdfChipDriver *(*Build)(struct HdfWlanDevice *device, uint8_t ifIndex)|创建一个HdfChipDriver；输入参数中，device是设备信息，ifIndex是当前创建的接口在这个芯片中的序号|
|void (*Release)(struct HdfChipDriver *chipDriver)| 释放chipDriver
|uint8_t (*GetMaxIFCount)(struct HdfChipDriverFactory *factory)| 获取当前芯片支持的最大接口数|
HdfChipDriver需要实现的接口有
|接口| 说明|
|------|------|
|int32_t (*init)(struct HdfChipDriver *chipDriver, NetDevice *netDev)| 初始化当前网络接口，这里需要向netDev提供接口NetDeviceInterFace|
|int32_t (*deinit)(struct HdfChipDriver *chipDriver, NetDevice *netDev)| 去初始化当前网络接口|
|struct HdfMac80211BaseOps *ops| WLAN基础能力接口集|
|struct HdfMac80211STAOps *staOps| 支持STA模式所需的接口集|
|struct HdfMac80211APOps *apOps| 支持AP模式所需要的接口集|
2. 编写配置文件，描述驱动支持的设备
在产品配置目录下创建芯片的配置文件`//vendor/MyProductVendor/MyProduct/config/wifi/wlan_chip_chip_name.hcs`
注意： 路径中的vendor_name、product_name、chip_name请替换成实际名称
```hcs
root {
wlan_config {
chip_name :& chipList {
chip_name :: chipInst {
match_attr = "hdf_wlan_chips_chip_name"; /* 这是配置匹配属性，用于提供驱动的配置根 */
driverName = "driverName"; /* 需要与HdfChipDriverFactory中的driverName相同*/
sdio {
vendorId = 0x0296;
deviceId = [0x5347];
}
}
}
}
}
```
3. 编写配置文件，加载驱动
产品的所有设备信息被定义在文件`//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs`中。修改该文件，在名为network的host中，名为device_wlan_chips的device中增加配置。
注意：moduleName 要与触摸屏驱动中的moduleName相同。
```hcs
deviceN :: deviceNode {
policy = 0;
preload = 2;
moduleName = "HDF_WLAN_CHIPS";
deviceMatchAttr = "hdf_wlan_chips_chip_name";
serviceName = "driverName";
}
```
4. 构建驱动
- 创建内核菜单
在 `//device/MySoCVendor/peripheral` 目录中创建Kconfig文件，内容模板如下：
```
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
```
接着修改文件 `//drivers/adapter/khdf/linux/model/network/wifi/Kconfig`,在文件末尾加入如下代码将配置菜单加入内核中
```
source "../../../../../device/MySoCVendor/peripheral/Kconfig"
```
- 创建构建脚本
在`//drivers/adapter/khdf/linux/model/network/wifi/Makefile` 文件末尾增加配置，模板如下
```
HDF_DEVICE_ROOT := $(HDF_DIR_PREFIX)/../device
obj-$(CONFIG_DRIVERS_WLAN_XXX) += $(HDF_DEVICE_ROOT)/MySoCVendor/peripheral/build/standard/
```
当在内核中开启`DRIVERS_WLAN_XXX`开关时，会调用`//device/MySoCVendor/peripheral/build/standard/`中的makefile
更多详细的开发手册，请参考[WLAN开发](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/WLAN.md)
>>>>>>> 2969611b3e2a25755ebcd7f632c8fe3f7f0c615f
zh-cn/device-dev/porting/三方组件适配.md → zh-cn/device-dev/porting/transplant-chip-board-bundle.md
浏览文件 @ 00bc1928
......@@ -51,7 +51,7 @@
hb build -f --patch
```
>![](public_sys-resources/icon-caution.gif) **注意：**
>![](../public_sys-resources/icon-caution.gif) **注意：**
>最后一次打patch的产品信息会被记录，在进行下一次编译操作时，会对上一次的patch进行回退（即执行\`patch -p1 -R < xxx\`），回退patch失败或新增patch失败均会终止编译过程，请解决patch冲突后再次尝试编译。
zh-cn/device-dev/porting/系统组件调用.md → zh-cn/device-dev/porting/transplant-chip-board-component.md
浏览文件 @ 00bc1928
......@@ -11,7 +11,7 @@
系统服务框架基于面向服务的架构，提供了服务开发、服务的子功能开发、对外接口的开发、以及多服务共进程、进程间服务调用等开发能力。
>![](public_sys-resources/icon-notice.gif) **须知：**
>![](../public_sys-resources/icon-notice.gif) **须知：**
>本组件在板级系统移植中必须要使用，否则其他服务组件无法运行。
**SAMGR使用说明，请参考：[SAMGR 使用指导](https://gitee.com/openharmony/distributedschedule_samgr_lite/blob/master/README_zh.md)**
......@@ -22,5 +22,5 @@
DFX子系统主要包含DFR（Design for Reliability，可靠性）和DFT（Design for Testability，可测试性）特性，为开发者提供代码维测信息。
**DFX子系统使用说明，请参考：[DFX子系统使用指导](../subsystems/DFX.md)**
**DFX子系统使用说明，请参考：[DFX子系统使用指导](../subsystems/subsys-dfx-overview.md)**
zh-cn/device-dev/porting/移植概述-0.md → zh-cn/device-dev/porting/transplant-chip-board-overview.md
浏览文件 @ 00bc1928
......@@ -13,11 +13,11 @@
4. 业务功能验证。
**图 1** 单板驱动适配流程<a name="fig14619153362215"></a>
![](figures/单板驱动适配流程.png "单板驱动适配流程")
![](figure/单板驱动适配流程.png "单板驱动适配流程")
## 板级目录规范<a name="section6204129143013"></a>
板级系统编译适配参考[编译系统介绍](编译构建适配流程.md)，板级相关的驱动、SDK、目录、HAL实现存放在device目录，目录结构和具体描述如下：
板级系统编译适配参考[编译系统介绍](transplant-chip-prepare-process.md)，板级相关的驱动、SDK、目录、HAL实现存放在device目录，目录结构和具体描述如下：
```
.
......
zh-cn/device-dev/porting/XTS认证.md → zh-cn/device-dev/porting/transplant-chip-board-xts.md
浏览文件 @ 00bc1928
......@@ -12,7 +12,7 @@ XTS是OpenHarmony生态认证测试套件的集合，当前包括acts（applicat
- acts，存放acts相关测试用例源码与配置文件，其目的是帮助终端设备厂商尽早发现软件与OpenHarmony的不兼容性，确保软件在整个开发过程中满足OpenHarmony的兼容性要求。
- tools，存放acts相关测试用例开发框架。
>![](public_sys-resources/icon-note.gif) **说明：**
>![](../public_sys-resources/icon-note.gif) **说明：**
>XTS的启动依赖SAMGR系统服务。
适配分为两步，包括：
......@@ -46,7 +46,7 @@ XTS是OpenHarmony生态认证测试套件的集合，当前包括acts（applicat
请在如下目录获取版本镜像：out/hispark\_pegasus/wifiiot\_hispark\_pegasus/。
>![](public_sys-resources/icon-note.gif) **说明：**
>![](../public_sys-resources/icon-note.gif) **说明：**
>判断当前版本镜像是否集成acts测试套件方法：在map文件中查看对应.a是否被编译即可。
2. 版本镜像烧录进开发板。
......
zh-cn/device-dev/porting/transplant-chip-board.md 0 → 100644
浏览文件 @ 00bc1928
# 板级系统移植<a name="ZH-CN_TOPIC_0000001062604739"></a>
- **[移植概述](transplant-chip-board-overview.md)**
- **[板级驱动适配](transplant-chip-board-drive.md)**
- **[HAL层实现](transplant-chip-board-hal.md)**
- **[系统组件调用](transplant-chip-board-component.md)**
- **[三方组件适配](transplant-chip-board-bundle.md)**
- **[XTS认证](transplant-chip-board-xts.md)**
zh-cn/device-dev/porting/内核基础适配.md → zh-cn/device-dev/porting/transplant-chip-kernel-adjustment.md
浏览文件 @ 00bc1928
......@@ -15,7 +15,7 @@
**图 1** 启动流程<a name="fig10838105524917"></a>
![](figures/zh-cn_image_0000001073943511.png)
![](figure/zh-cn_image_0000001073943511.png)
启动文件startup.S需要确保中断向量表的入口函数（例如reset\_vector）放在RAM的首地址，它由链接配置文件来指定。其中iar、keil和gcc工程的链接配置文件分别为xxx.icf、xxx.sct和xxx.ld，如果startup.S已经完成系统时钟初始化，并且能够引导到main函数，则启动文件不需要进行修改，采用厂商自带的startup.S即可，否则需要实现以上功能。
......
zh-cn/device-dev/porting/移植概述.md → zh-cn/device-dev/porting/transplant-chip-kernel-overview.md
浏览文件 @ 00bc1928
......@@ -21,7 +21,7 @@
**图 1** liteos-m内核模块图<a name="fig10838105524917"></a>
![](figures/zh-cn_image_0000001072304191.png)
![](figure/zh-cn_image_0000001072304191.png)
内核的目录结构和说明如下：
......
zh-cn/device-dev/porting/内核移植验证.md → zh-cn/device-dev/porting/transplant-chip-kernel-verify.md
浏览文件 @ 00bc1928
......@@ -55,5 +55,5 @@ LITE_OS_SEC_TEXT_INIT int main(void)
}
```
第一个任务运行正常后，说明最小系统的核心流程基本OK；由于xts用例框架对外依赖较多，主要是utils、bootstrap的链接脚本和编译框架，暂时无法支撑内核单独跑xts；此处略过内核测试套的测试，可以通过[XTS测试套](XTS认证.md)来覆盖最小系统是否完整移植成功。
第一个任务运行正常后，说明最小系统的核心流程基本OK；由于xts用例框架对外依赖较多，主要是utils、bootstrap的链接脚本和编译框架，暂时无法支撑内核单独跑xts；此处略过内核测试套的测试，可以通过[XTS测试套](transplant-chip-board-xts.md)来覆盖最小系统是否完整移植成功。
zh-cn/device-dev/porting/transplant-chip-kernel.md 0 → 100644
浏览文件 @ 00bc1928
# 内核移植<a name="ZH-CN_TOPIC_0000001063110705"></a>
- **[移植概述](transplant-chip-kernel-overview.md)**
- **[内核基础适配](transplant-chip-kernel-adjustment.md)**
- **[内核移植验证](transplant-chip-kernel-verify.md)**
zh-cn/device-dev/porting/移植须知.md → zh-cn/device-dev/porting/transplant-chip-prepare-knows.md
浏览文件 @ 00bc1928
......@@ -33,7 +33,7 @@ OpenHarmony整体工程较为复杂，目录及实现为系统本身功能，如
</tr>
<tr id="row44321715131917"><td class="cellrowborder" valign="top" width="27.71%" headers="mcps1.2.3.1.1 "><p id="p20432181501911"><a name="p20432181501911"></a><a name="p20432181501911"></a>/device</p>
</td>
<td class="cellrowborder" valign="top" width="72.28999999999999%" headers="mcps1.2.3.1.2 "><p id="p64331415171913"><a name="p64331415171913"></a><a name="p64331415171913"></a>板级相关实现，各个三方厂商按照<span id="text117091750175520"><a name="text117091750175520"></a><a name="text117091750175520"></a>OpenHarmony</span>规范适配实现，device下具体目录结构及移植过程参见<a href="移植概述-0.md">板级系统移植</a></p>
<td class="cellrowborder" valign="top" width="72.28999999999999%" headers="mcps1.2.3.1.2 "><p id="p64331415171913"><a name="p64331415171913"></a><a name="p64331415171913"></a>板级相关实现，各个三方厂商按照<span id="text117091750175520"><a name="text117091750175520"></a><a name="text117091750175520"></a>OpenHarmony</span>规范适配实现，device下具体目录结构及移植过程参见<a href="transplant-chip-board-overview.md">板级系统移植</a></p>
</td>
</tr>
<tr id="row19497111381917"><td class="cellrowborder" valign="top" width="27.71%" headers="mcps1.2.3.1.1 "><p id="p12498181381916"><a name="p12498181381916"></a><a name="p12498181381916"></a>/vendor</p>
......@@ -75,10 +75,10 @@ vendor # 产品解决方案厂商
OpenHarmony的device目录是基础芯片的适配目录，如果在三方芯片应用过程中发现此目录下已经有完整的芯片适配，则不需要再额外移植，直接跳过移植过程进行系统应用开发即可，如果该目录下无对应的芯片移植实现，则根据本文完成移植过程。OpenHarmony三方芯片移植主要过程如下：
**图 1** 芯片移植关键步骤<a name="fig24801925498"></a>
![](figures/芯片移植关键步骤.png "芯片移植关键步骤")
![](figure/芯片移植关键步骤.png "芯片移植关键步骤")
## 移植规范<a name="section187870185219"></a>
- 满足OpenHarmony[开源贡献基本规范和准则](https://gitee.com/openharmony/docs/blob/master/zh-cn/contribute/%E5%8F%82%E4%B8%8E%E8%B4%A1%E7%8C%AE.md)。
- 三方芯片适配所需要贡献的代码主要在device、vendor和arch三个目录，参照[内核目录规范](移植概述.md)和[板级目录规范](移植概述-0.md#section6204129143013)满足基本目录命名和使用规范。
- 三方芯片适配所需要贡献的代码主要在device、vendor和arch三个目录，参照[内核目录规范](transplant-chip-kernel-overview.md)和[板级目录规范](transplant-chip-board-overview.md#section6204129143013)满足基本目录命名和使用规范。
zh-cn/device-dev/porting/移植准备.md → zh-cn/device-dev/porting/transplant-chip-prepare.md
浏览文件 @ 00bc1928
# 移植准备<a name="ZH-CN_TOPIC_0000001063252862"></a>
- **[移植须知](移植须知.md)**
- **[移植须知](transplant-chip-prepare-knows.md)**
- **[编译构建适配流程](编译构建适配流程.md)**
- **[编译构建适配流程](transplant-chip-prepare-process.md)**
zh-cn/device-dev/porting/transplant-chip.md 0 → 100644
浏览文件 @ 00bc1928
# 三方芯片移植指导<a name="ZH-CN_TOPIC_0000001157479383"></a>
- **[移植准备](transplant-chip-prepare.md)**
- **[内核移植](transplant-chip-kernel.md)**
- **[板级系统移植](transplant-chip-board.md)**
- **[常见问题](transplant-chip-faqs.md)**
zh-cn/device-dev/porting/transplant-minichip.md 0 → 100644
浏览文件 @ 00bc1928
# 轻量系统芯片移植指导<a name="ZH-CN_TOPIC_0000001157479383"></a>
- **[移植准备](transplant-chip-prepare.md)**
- **[内核移植](transplant-chip-kernel.md)**
- **[板级系统移植](transplant-chip-board.md)**
- **[常见问题](transplant-chip-faqs.md)**
zh-cn/device-dev/porting/transplant-smallchip-drive-des.md 0 → 100644
浏览文件 @ 00bc1928
# 移植概述<a name="ZH-CN_TOPIC_0000001172160289"></a>
驱动主要包含两部分，平台驱动和器件驱动。平台驱动主要包括通常在SOC内的GPIO、I2C、SPI等；器件驱动则主要包含通常在SOC外的器件，如 LCD、TP、WLAN等。
**图 1** OpenHarmony 驱动分类<a name="fig11697182018375"></a>
![](figure/分类.png)
HDF驱动被设计为可以跨OS使用的驱动程序，HDF驱动框架会为驱动达成这个目标提供有力的支撑。开发HDF驱动中，请尽可能只使用HDF驱动框架提供的接口，否则会导致驱动丧失跨OS使用的特性。在开始驱动开发前，建议先了解[HDF驱动框架](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/HDF%E9%A9%B1%E5%8A%A8%E6%A1%86%E6%9E%B6.md)。
zh-cn/device-dev/porting/transplant-smallchip-drive-plat.md 0 → 100644
浏览文件 @ 00bc1928
# 平台驱动移植<a name="ZH-CN_TOPIC_0000001170794079"></a>
在这一步，我们会在源码目录//device/vendor\_name/soc\_name/drivers 目录下创建平台驱动，如果你要移植的SOC的厂商还没有创建仓库的话，请联系[sig-devboard](https://gitee.com/openharmony/community/blob/master/sig/sig-devboard/sig_devboard_cn.md)创建。
建议的目录结构：
```
device
├── vendor_name
│ ├── drivers
│ │ │ ├── common
│ │ │ ├── Kconfig # 厂商驱动内核菜单入口
│ │ │ └── lite.mk # 构建的入口
│ ├── soc_name
│ │ ├── drivers
│ │ │ ├── dmac
│ │ │ ├── gpio
│ │ │ ├── i2c
│ │ │ ├── LICENSE
│ │ │ ├── mipi_dsi
│ │ │ ├── mmc
│ │ │ ├── pwm
│ │ │ ├── README.md # docs 如果需要的话
│ │ │ ├── README_zh.md
│ │ │ ├── rtc
│ │ │ ├── spi
│ │ │ ├── uart
│ │ │ └── watchdog
│ ├── board_name
```
HDF为所有的平台驱动都创建了驱动模型，移植平台驱动的主要工作是向模型注入实例。 这些模型你可以在源码目录//drivers/framework/support/platform/include中找到定义。
本节我们会以GPIO为例，讲解如何移植平台驱动，移植过程包含以下步骤：
1. 创建GPIO驱动
在源码目录//device/vendor\_name/soc\_name/drivers/gpio中创建文件soc\_name\_gpio.c 内容模板如下：
```
#include "gpio_core.h"
// 定义GPIO结构体，如果需要的话
struct SocNameGpioCntlr {
struct GpioCntlr cntlr; // 这是HDF GPIO驱动框架需要的结构体
int myData; // 以下是当前驱动自身需要的
};
// Bind 方法在HDF驱动中主要用户对外发布服务，这里我们不需要，直接返回成功即可
static int32_t GpioBind(struct HdfDeviceObject *device)
{
(void)device;
return HDF_SUCCESS;
}
// Init方法时驱动初始化的入口，我们需要在Init方法中完成模型实例的注册
static int32_t GpioInit(struct HdfDeviceObject *device)
{
SocNameGpioCntlr *impl = CreateGpio(); // 你的创建代码
ret = GpioCntlrAdd(&impl->cntlr); // 注册GPIO模型实例
if (ret != HDF_SUCCESS) {
HDF_LOGE("%s: err add controller:%d", __func__, ret);
return ret;
}
return HDF_SUCCESS;
}
// Release方法会在驱动卸载时被调用，这里主要完成资源回收
static void GpioRelease(struct HdfDeviceObject *device)
{
// GpioCntlrFromDevice 方法能从抽象的设备对象中获得init方法注册进去的模型实例。
struct GpioCntlr *cntlr = GpioCntlrFromDevice(device);
//资源释放...
}
struct HdfDriverEntry g_gpioDriverEntry = {
.moduleVersion = 1,
.Bind = GpioBind,
.Init = GpioInit,
.Release = GpioRelease,
.moduleName = "SOC_NAME_gpio_driver", // 这个名字我们稍后会在配置文件中用到，用来加载驱动。
};
HDF_INIT(g_gpioDriverEntry); // 注册一个GPIO的驱动入口
```
2. 创建厂商驱动构建入口
如前所述device/vendor\_name/drivers/lite.mk是厂商驱动的构建的入口。我们需要从这个入口开始，进行构建
```
#文件device/vendor_name/drivers/lite.mk
SOC_VENDOR_NAME := $(subst $/",,$(LOSCFG_DEVICE_COMPANY))
SOC_NAME := $(subst $/",,$(LOSCFG_PLATFORM))
BOARD_NAME := $(subst $/",,$(LOSCFG_PRODUCT_NAME))
# 指定SOC进行构建
LIB_SUBDIRS += $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/
```
3. 创建SOC驱动构建入口
```
#文件device/vendor_name/soc_name/drivers/lite.mk
SOC_DRIVER_ROOT := $(LITEOSTOPDIR)/../../device/$(SOC_VENDOR_NAME)/$(SOC_NAME)/drivers/
# 判断如果打开了GPIO的内核编译开关
ifeq ($(LOSCFG_DRIVERS_HDF_PLATFORM_GPIO), y)
# 构建完成要链接一个叫hdf_gpio的对象
LITEOS_BASELIB += -lhdf_gpio
# 增加构建目录gpio
LIB_SUBDIRS += $(SOC_DRIVER_ROOT)/gpio
endif
# 后续其他驱动在此基础上追加
```
4. 创建GPIO构建入口
```
include $(LITEOSTOPDIR)/config.mk
include $(LITEOSTOPDIR)/../../drivers/adapter/khdf/liteos/lite.mk
# 指定输出对象的名称，注意要与SOC驱动构建入口里的LITEOS_BASELIB 保持一致
MODULE_NAME := hdf_gpio
# 增加HDF框架的INCLUDE
LOCAL_CFLAGS += $(HDF_INCLUDE)
# 要编译的文件
LOCAL_SRCS += soc_name_gpio.c
# 编译参数
LOCAL_CFLAGS += -fstack-protector-strong -Wextra -Wall -Werror -fsigned-char -fno-strict-aliasing -fno-common
include $(HDF_DRIVER)
```
5. 配置产品加载驱动
产品的所有设备信息被定义在源码文件//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs中。
平台驱动请添加到platform的host中。
>![](../public_sys-resources/icon-note.gif) **说明：**
>moduleName要与驱动定义中的相同。
```
root {
...
platform :: host {
device_gpio :: device {
device0 :: deviceNode {
policy = 0;
priority = 10;
permission = 0644;
moduleName = "SOC_NAME_gpio_driver";
}
}
}
}
```
zh-cn/device-dev/porting/transplant-smallchip-drive.md 0 → 100644
浏览文件 @ 00bc1928
# 驱动移植<a name="ZH-CN_TOPIC_0000001123149616"></a>
- **[移植概述](transplant-smallchip-drive-des.md)**
- **[平台驱动移植](transplant-smallchip-drive-plat.md)**
- **[器件驱动移植](transplant-smallchip-drive-oom.md)**
zh-cn/device-dev/porting/transplant-smallchip-kernel-a.md 0 → 100644
浏览文件 @ 00bc1928
# LiteOS-A内核<a name="ZH-CN_TOPIC_0000001113392962"></a>
- [移植概述](#section14876256185510)
- [移植场景](#section1986014410569)
- [目录规范](#section10916181716564)
- [基础适配](#section814974018565)
- [编程样例](#section10854481825)
- [验证](#section646410453212)
## 移植概述<a name="section14876256185510"></a>
### 移植场景<a name="section1986014410569"></a>
LiteOS-A当前支持ARMv7-a指令集架构，如果三方芯片为ARMv7-a架构，可以进行内核基础适配；否则还需要先根据芯片的架构来新增内核对该芯片架构的支持，这个工作较为复杂，不在这篇文章范围内。
### 目录规范<a name="section10916181716564"></a>
LiteOS-A目录规范参考[LiteOS-A 简介](https://gitee.com/openharmony/kernel_liteos_a)。
## 基础适配<a name="section814974018565"></a>
LiteOS-A提供系统运行所需的系统初始化流程和定制化配置选项。移植过程中，需要关注初始化流程中跟硬件配置相关的函数。
如下图所示，LiteOS-A的初始化流程主要包含以下五步：
1. 新增target\_config.h文件，并且编写单板内存相关的配置宏DDR\_MEM\_ADDR和DDR\_MEM\_SIZE，分别表示内存起始地址和内存的长度，预链接脚本board.ld.S会根据这两个宏进行展开生成链接脚本board.ld。
2. 链接阶段根据链接脚本board.ld生成内核镜像。
3. 单核CPU镜像运行入口为汇编文件reset\_vector\_up.S，多核CPU的入口为reset\_vector\_mp.S，在汇编文件中进行中断向量表初始化、MMU页表初始化等操作。
4. reset\_vector.S汇编代码最终会跳转到C语言的main函数，进行硬件时钟、软件定时器、内存和任务等初始化，这个过程会依赖target\_config.h的特性宏配置，最后会创建SystemInit任务，并且开启任务调度OsSchedStart\(\)。
5. SystemInit任务在单板代码中实现，其中调用DeviceManagerStart函数进行HDF驱动初始化，这个过程会调用单板代码中的驱动配置文件hdf.hcs以及drivers源码实现。
整体启动流程如下图所示：
**图 1** 整体启动流程<a name="fig10838105524917"></a>
![](figure/zh-cn_image_0000001126358814.png)
从图1中可以看到，内核基础适配需要单板进行适配的代码包含三部分：
- 新增target\_config.h文件，其中新增单板硬件配置参数和特性开关的配置参数，具体说明如下：
**表 1** target\_config.h配置项说明
<a name="table174922816418"></a>
<table><thead align="left"><tr id="row549388144112"><th class="cellrowborder" valign="top" width="34.81%" id="mcps1.2.3.1.1"><p id="p04939810417"><a name="p04939810417"></a><a name="p04939810417"></a>配置项</p>
</th>
<th class="cellrowborder" valign="top" width="65.19%" id="mcps1.2.3.1.2"><p id="p9493588417"><a name="p9493588417"></a><a name="p9493588417"></a>说明</p>
</th>
</tr>
</thead>
<tbody><tr id="row249319816418"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p6493788413"><a name="p6493788413"></a><a name="p6493788413"></a>OS_SYS_CLOCK</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p74937810416"><a name="p74937810416"></a><a name="p74937810416"></a>系统cycle的频率</p>
</td>
</tr>
<tr id="row1649388104117"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p2049316816414"><a name="p2049316816414"></a><a name="p2049316816414"></a>DDR_MEM_ADDR</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p349317815413"><a name="p349317815413"></a><a name="p349317815413"></a>系统内存的起始地址</p>
</td>
</tr>
<tr id="row5493182419"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p1149316814114"><a name="p1149316814114"></a><a name="p1149316814114"></a>DDR_MEM_SIZE</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p1949311816415"><a name="p1949311816415"></a><a name="p1949311816415"></a>系统内存的大小</p>
</td>
</tr>
<tr id="row9493178194110"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p13493108134115"><a name="p13493108134115"></a><a name="p13493108134115"></a>PERIPH_PMM_BASE</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p1549318134111"><a name="p1549318134111"></a><a name="p1549318134111"></a>外设寄存器的起始地址</p>
</td>
</tr>
<tr id="row1749314894112"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p1749328154115"><a name="p1749328154115"></a><a name="p1749328154115"></a>PERIPH_PMM_SIZE</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p1449312816410"><a name="p1449312816410"></a><a name="p1449312816410"></a>外设寄存器的长度大小</p>
</td>
</tr>
<tr id="row149398114120"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p16493982410"><a name="p16493982410"></a><a name="p16493982410"></a>OS_HWI_MIN</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p184931781412"><a name="p184931781412"></a><a name="p184931781412"></a>系统中断最小值</p>
</td>
</tr>
<tr id="row124939854118"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p1349348194113"><a name="p1349348194113"></a><a name="p1349348194113"></a>OS_HWI_MAX</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p134935894120"><a name="p134935894120"></a><a name="p134935894120"></a>系统中断最大值</p>
</td>
</tr>
<tr id="row1332213815810"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p14322781588"><a name="p14322781588"></a><a name="p14322781588"></a>NUM_HAL_INTERRUPT_UART0</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p43224815817"><a name="p43224815817"></a><a name="p43224815817"></a>UART0中断号</p>
</td>
</tr>
<tr id="row108730542581"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p4873115455813"><a name="p4873115455813"></a><a name="p4873115455813"></a>UART0_REG_BASE</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p3873115417581"><a name="p3873115417581"></a><a name="p3873115417581"></a>UART0寄存器基址</p>
</td>
</tr>
<tr id="row12172101495718"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p1172514115717"><a name="p1172514115717"></a><a name="p1172514115717"></a>GIC_BASE_ADDR</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p1617216144572"><a name="p1617216144572"></a><a name="p1617216144572"></a>GIC中断寄存器基址</p>
</td>
</tr>
<tr id="row24371957115711"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p143785715710"><a name="p143785715710"></a><a name="p143785715710"></a>GICD_OFFSET</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p7437125725717"><a name="p7437125725717"></a><a name="p7437125725717"></a>GICD相对GIC基址的偏移地址</p>
</td>
</tr>
<tr id="row19221159175917"><td class="cellrowborder" valign="top" width="34.81%" headers="mcps1.2.3.1.1 "><p id="p152211159185918"><a name="p152211159185918"></a><a name="p152211159185918"></a>GICC_OFFSET</p>
</td>
<td class="cellrowborder" valign="top" width="65.19%" headers="mcps1.2.3.1.2 "><p id="p522105912593"><a name="p522105912593"></a><a name="p522105912593"></a>GICC相对GIC基址的偏移地址</p>
</td>
</tr>
</tbody>
</table>
- SystemInit函数用于单板用户态业务初始化，典型的初始化场景如图2所示：
**图 1** 业务启动流程<a name="fig15798236163510"></a>
![](figure/zh-cn_image_0000001126198996.png)
- main函数用于内核基础初始化和单板内核态业务初始化，流程如下图3所示，整体由内核启动框架主导初始化流程，图中浅蓝色部分为启动框架中可接受外部模块注册启动的阶段。
>![](../public_sys-resources/icon-caution.gif) **注意：**
>同一层级内的模块不能有依赖关系。
**图 2** 内核启动框架<a name="fig32611728133919"></a>
![](figure/内核启动框架.jpg "内核启动框架")
**表 2** 启动框架层级
<a name="table38544719428"></a>
<table><thead align="left"><tr id="row286134714423"><th class="cellrowborder" valign="top" width="34.089999999999996%" id="mcps1.2.3.1.1"><p id="p886164717423"><a name="p886164717423"></a><a name="p886164717423"></a>层级</p>
</th>
<th class="cellrowborder" valign="top" width="65.91%" id="mcps1.2.3.1.2"><p id="p586194716421"><a name="p586194716421"></a><a name="p586194716421"></a>说明</p>
</th>
</tr>
</thead>
<tbody><tr id="row48664764218"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p7861447174211"><a name="p7861447174211"></a><a name="p7861447174211"></a>LOS_INIT_LEVEL_EARLIEST</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p1561350125815"><a name="p1561350125815"></a><a name="p1561350125815"></a>最早期初始化</p>
<p id="p13865183210552"><a name="p13865183210552"></a><a name="p13865183210552"></a>说明：不依赖架构，单板以及后续模块会对其有依赖的纯软件模块初始化</p>
<p id="p1686104764216"><a name="p1686104764216"></a><a name="p1686104764216"></a>例如：Trace模块</p>
</td>
</tr>
<tr id="row4861478429"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p1986164710423"><a name="p1986164710423"></a><a name="p1986164710423"></a>LOS_INIT_LEVEL_ARCH_EARLY</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p6864470423"><a name="p6864470423"></a><a name="p6864470423"></a>架构早期初始化</p>
<p id="p118192355598"><a name="p118192355598"></a><a name="p118192355598"></a>说明：架构相关，后续模块会对其有依赖的模块初始化，如启动过程中非必需的功能，建议放到LOS_INIT_LEVEL_ARCH层</p>
</td>
</tr>
<tr id="row98694774219"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p118624714210"><a name="p118624714210"></a><a name="p118624714210"></a>LOS_INIT_LEVEL_PLATFORM_EARLY</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p118531052143510"><a name="p118531052143510"></a><a name="p118531052143510"></a>平台早期初始化</p>
<p id="p666132195816"><a name="p666132195816"></a><a name="p666132195816"></a>说明：单板平台、驱动相关，后续模块会对其有依赖的模块初始化，如启动过程中必需的功能，建议放到LOS_INIT_LEVEL_PLATFORM层</p>
<p id="p1986104794218"><a name="p1986104794218"></a><a name="p1986104794218"></a>例如：uart模块</p>
</td>
</tr>
<tr id="row8863470423"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p19861547114214"><a name="p19861547114214"></a><a name="p19861547114214"></a>LOS_INIT_LEVEL_KMOD_PREVM</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p2862471421"><a name="p2862471421"></a><a name="p2862471421"></a>内存初始化前的内核模块初始化</p>
<p id="p989110481520"><a name="p989110481520"></a><a name="p989110481520"></a>说明：在内存初始化之前需要使能的模块初始化</p>
</td>
</tr>
<tr id="row4861147124218"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p16863472426"><a name="p16863472426"></a><a name="p16863472426"></a>LOS_INIT_LEVEL_VM_COMPLETE</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p1186114715427"><a name="p1186114715427"></a><a name="p1186114715427"></a>基础内存就绪后的初始化</p>
<p id="p26441930165910"><a name="p26441930165910"></a><a name="p26441930165910"></a>说明：此时内存初始化完毕，需要进行使能且不依赖进程间通讯机制与系统进程的模块初始化</p>
<p id="p76991543175013"><a name="p76991543175013"></a><a name="p76991543175013"></a>例如：共享内存功能</p>
</td>
</tr>
<tr id="row12869472429"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p178694712429"><a name="p178694712429"></a><a name="p178694712429"></a>LOS_INIT_LEVEL_ARCH</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p1086104719427"><a name="p1086104719427"></a><a name="p1086104719427"></a>架构后期初始化</p>
<p id="p556511281688"><a name="p556511281688"></a><a name="p556511281688"></a>说明：架构拓展功能相关，后续模块会对其有依赖的模块初始化</p>
</td>
</tr>
<tr id="row128624717424"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p198684711427"><a name="p198684711427"></a><a name="p198684711427"></a>LOS_INIT_LEVEL_PLATFORM</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p65519915524"><a name="p65519915524"></a><a name="p65519915524"></a>平台后期初始化</p>
<p id="p187247164213"><a name="p187247164213"></a><a name="p187247164213"></a>说明：单板平台、驱动相关，后续模块会对其有依赖的模块初始化</p>
<p id="p138046651010"><a name="p138046651010"></a><a name="p138046651010"></a>例如：驱动内核抽象层初始化（mmc、mtd）</p>
</td>
</tr>
<tr id="row2149155220436"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p8150105215436"><a name="p8150105215436"></a><a name="p8150105215436"></a>LOS_INIT_LEVEL_KMOD_BASIC</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p81509525436"><a name="p81509525436"></a><a name="p81509525436"></a>内核基础模块初始化</p>
<p id="p763134221115"><a name="p763134221115"></a><a name="p763134221115"></a>说明：内核可拆卸的基础模块初始化</p>
<p id="p7781186191213"><a name="p7781186191213"></a><a name="p7781186191213"></a>例如：VFS初始化</p>
</td>
</tr>
<tr id="row19671355174317"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p1596825564317"><a name="p1596825564317"></a><a name="p1596825564317"></a>LOS_INIT_LEVEL_KMOD_EXTENDED</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p6968155513438"><a name="p6968155513438"></a><a name="p6968155513438"></a>内核扩展模块初始化</p>
<p id="p669712304124"><a name="p669712304124"></a><a name="p669712304124"></a>说明：内核可拆卸的扩展模块初始化</p>
<p id="p7600114618125"><a name="p7600114618125"></a><a name="p7600114618125"></a>例如：系统调用初始化、ProcFS初始化、Futex初始化、HiLog初始化、HiEvent初始化、LiteIPC初始化</p>
</td>
</tr>
<tr id="row357517134414"><td class="cellrowborder" valign="top" width="34.089999999999996%" headers="mcps1.2.3.1.1 "><p id="p12575676449"><a name="p12575676449"></a><a name="p12575676449"></a>LOS_INIT_LEVEL_KMOD_TASK</p>
</td>
<td class="cellrowborder" valign="top" width="65.91%" headers="mcps1.2.3.1.2 "><p id="p7128122619143"><a name="p7128122619143"></a><a name="p7128122619143"></a>内核任务创建</p>
<p id="p1657587184419"><a name="p1657587184419"></a><a name="p1657587184419"></a>说明：进行内核任务的创建（内核线程，软件定时器任务）</p>
<p id="p55485297219"><a name="p55485297219"></a><a name="p55485297219"></a>例如：资源回收系统常驻任务的创建、SystemInit任务创建、CPU占用率统计任务创建</p>
</td>
</tr>
</tbody>
</table>
进行单板移植适配，推荐关注LOS\_INIT\_LEVEL\_ARCH至LOS\_INIT\_LEVEL\_KMOD\_TASK之间的层级，且尽可能拆分初始化行为进行细化阶段注册。
>![](../public_sys-resources/icon-note.gif) **说明：**
>启动框架中同一层级内的注册模块不能有依赖关系，建议新增模块按照上述启动阶段进行模块初始化的拆分，按需注册启动。
>可通过查看系统编译生成文件OHOS\_Image.map中.rodata.init.kernel.\*段内的符号表来了解当前已注册进内核启动框架中的各个模块初始化入口，以及检查新注册的模块初始化入口是否生效。
### 编程样例<a name="section10854481825"></a>
在单板SDK文件中
```
/* 内核启动框架头文件 */
#include "los_init.h"
......
/* 新增模块的初始化函数 */
unsigned int OsSampleModInit(void)
{
PRINTK("OsSampleModInit SUCCESS!\n");
......
}
......
/* 在启动框架的目标层级中注册新增模块 */
LOS_MODULE_INIT(OsSampleModInit, LOS_INIT_LEVEL_KMOD_EXTENDED);
```
## 验证<a name="section646410453212"></a>
```
main core booting up...
OsSampleModInit SUCCESS!
releasing 1 secondary cores
cpu 1 entering scheduler
cpu 0 entering scheduler
```
根据上述系统启动阶段的打印可知，内核在启动时进行了该注册模块的初始化函数调用，完成该模块的初始化操作。
系统启动完毕后进入内核态shell，能够运行task命令能够正常显示即可。
```
OHOS # help
*******************shell commands:*************************
arp cat cd chgrp chmod chown cp cpup
date dhclient dmesg dns format free help hwi
ifconfig ipdebug kill log ls lsfd memcheck mkdir
mount netstat oom partinfo partition ping ping6 pmm
pwd reset rm rmdir sem shm stack statfs
su swtmr sync systeminfo task telnet touch umount
uname v2p virstatfs vmm watch writeproc
```
zh-cn/device-dev/porting/transplant-smallchip-kernel-linux.md 0 → 100644
浏览文件 @ 00bc1928
# Linux内核<a name="ZH-CN_TOPIC_0000001159912785"></a>
- [移植概述](#section6282121355111)
- [基本信息](#section19589322515)
- [Bootloader](#section19062510518)
- [适配编译和烧录启动](#section11112101695215)
- [验证](#section17318153325311)
## 移植概述<a name="section6282121355111"></a>
Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后，进行基础的内核编译构建及验证。
### 基本信息<a name="section19589322515"></a>
当前Linux内核基线是基于Linux社区 4.19 LTS版本演进，合入CVE及bugfix补丁。具体信息参考[代码库](https://gitee.com/openharmony/kernel_linux)，对应repo工程代码路径为kernel/linux-4.19。
### Bootloader<a name="section19062510518"></a>
可以使用芯片厂商自带的Bootloader，或者是开源Uboot等加载内核镜像。比如为支持Hi3516DV300开发板，OpenHarmony引入的开源[Uboot](https://gitee.com/openharmony/device_hisilicon_third_party_uboot)。
## 适配编译和烧录启动<a name="section11112101695215"></a>
1. 准备内核config（特别是芯片相关的config）。
config文件所在源码目录：kernel/linux/config/
以hi3516dv300芯片为例，可在对应的linux-4.19/arch/arm/configs/目录下新建<YOUR\_CHIP\>\_small\_defconfig，如hi3516dv300\_small\_defconfig表示针对hi3516dv300小型系统的defconfig。该config文件可以由基础defconfig文件small\_common\_defconfig与该芯片相关的config组合生成。
2. 准备芯片补丁。
补丁文件所在源码目录：kernel/linux/patches/linux-4.19
以hi3516dv300芯片为例，参考已有的patch目录hi3516dv300\_small\_patch目录，新建<YOUR\_CHIP\>\_patch目录，放置相关芯片补丁，注意hdf.patch等驱动补丁。
3. 编译。
具体内核编译入口脚本位于工程目录kernel/linux/patches/下面，版本级整编命令会通过BUILD.gn进入kernel\_module\_build.sh和kernel.mk，需要在这2个文件中针对性进行patch及defconfig文件路径、编译器、芯片架构、内核Image格式等的适配。
通过编译错误日志调整补丁，典型错误场景：
（1）补丁合入失败，出现冲突，需要进行上下文适配修改。
（2）编译失败，内核版本差异（函数实现调整等）需要针对性进行内核适配。
>![](../public_sys-resources/icon-caution.gif) **注意：**
>- 参考kernel.mk，在OpenHarmony工程的编译构建流程中会拷贝kernel/linux-4.19的代码环境后进行打补丁动作，在使用版本级编译命令前，需要kernel/linux-4.19保持原代码环境。
>- 对应拷贝后的目录位于: out/<\*\*\*\>/kernel/linux-4.19，可以在该目录下进行补丁的修改适配。
4. 烧录启动。
由于不同芯片的开发板的烧录方式不一样，此处不表述具体的烧录方式。需要注意烧录的各镜像的大小及启动参数的配置，参考hi3516dv300采用uboot启动参数：
```
setenv bootargs 'mem=128M console=ttyAMA0,115200 root=/dev/mmcblk0p3 ro rootfstype=ext4 rootwait blkdevparts=mmcblk0:1M(boot),9M(kernel),50M(rootfs),50M(userfs)'
```
## 验证<a name="section17318153325311"></a>
调试init进程、启动shell和运行简单的用户态程序，验证内核移植是否成功。OpenHarmony[小型系统](https://device.harmonyos.com/cn/docs/start/introduce/oem_start_guide-0000001054913231)的OS镜像结构以及linux用户态的启动流程如下图1所示：
**图 1** 基于linux内核的OS镜像结构和用户态程序启动流程<a name="fig1296918391004"></a>
![](figure/zh-cn_image_0000001126354076.png)
基于上述流程，推荐按以下步骤完成验证：
1. 制作根文件系统镜像。
请参考[新建芯片解决方案和产品解决方案](https://device.harmonyos.com/cn/docs/develop/subsystems/oem_subsys_build_guide-0000001060378721)生成根文件系统镜像rootfs.img。从上图可以看到启动过程与产品配置强相关，在制作rootfs.img过程中请完成如下四种配置：
- 组件配置
产品组件配置文件vendor/\{company\}/\{product\}/config.json需配置启动恢复子系统\(startup\)的init\_lite组件和内核子系统的linux\_4\_1\_9组件。
- 系统服务配置
系统服务配置文件vendor/\{company\}/\{product\}/init\_configs/init\_xxx.cfg需要启动shell服务。
- 文件系统配置
文件系统配置vendor/\{company\}/\{product\}/fs.yml中需要创建“/bin/sh -\> mksh“和“/lib/ld-musl-arm.so.1 -\> libc.so“软连接，这两个文件分别是shell可执行程序和可执行程序依赖的c库。
- 启动配置
启动配置在vendor/\{company\}/\{product\}/init\_configs/etc目录下，包括fstab、rsS和Sxxx文件，请按开发板实际情况配置。
编译完成后，可通过检查产品编译输出目录下的rootfs内容，确认rootfs.img文件生成是否符合预期。
2. 调试init进程和shell。
烧录rootfs.img并调试init进程和shell，不同厂商的开发板的烧录工具和流程可能不同，请按芯片解决方案提供的流程进行烧录。烧录rootfs.img前请确认bootloader和linux内核启动正常。如果rootfs.img被内核正常挂载，接着将运行/bin/init程序，init进程为用户态的第一个应用程序，它的运行意味着用户态的开始。
init程序首先会调用/etc/init.d/rcS脚本，rcS脚本执行第一条命令为"/bin/mount -a”，该命令会加载fstab文件，在fstab中的命令执行完后rcS将顺序调用Sxxx脚本完成设备节点创建和扫描、文件权限配置等操作。
最后，init程序会读取init.cfg系统服务配置文件。根据步骤1中的设置，init程序将会启动shell。如果上述流程运行正常，系统则会进入shell。
若串口有如下版本号日志打印，则表示init程序启动正常：
**图 2** init启动正常日志<a name="fig13510844174415"></a>
![](figure/init.jpg)
正常进入shell后执行ls命令，串口打印信息如下图：
**图 3** 正常进入shell后输入ls命令串口打印<a name="fig584415944917"></a>
![](figure/shell.jpg)
3. 配置NFS。
init进程和shell正常启动后，以服务端IP为192.168.1.22、客户端IP为192.168.1.4为例，可在根目录执行如下命令开启NFS:
```
ifconfig eth0 192.168.1.4 netmask 255.255.255.0
mkdir -p /storgage/nfs
mount -t nfs -o nolock,addr=192.168.1.22 192.168.1.22:/nfs /storage/nfs
```
zh-cn/device-dev/porting/transplant-smallchip-kernel.md 0 → 100644
浏览文件 @ 00bc1928
# 移植内核<a name="ZH-CN_TOPIC_0000001105566322"></a>
- **[LiteOS-A内核](transplant-smallchip-kernel-a.md)**
- **[Linux内核](transplant-smallchip-kernel-linux.md)**
zh-cn/device-dev/porting/transplant-smallchip-prepare-building.md 0 → 100644
浏览文件 @ 00bc1928
# 编译构建<a name="ZH-CN_TOPIC_0000001105406466"></a>
- [编译环境搭建](#section3336103410314)
- [编译构建系统介绍](#section354343816319)
- [新建芯片解决方案](#section18612153175011)
## 编译环境搭建<a name="section3336103410314"></a>
首先请搭建OpenHarmony基础环境，步骤请参考轻量和小型系统入门[linux环境搭建](https://device.harmonyos.com/cn/docs/start/introduce/oem_minitinier_environment_lin-0000001105407498)。用户态和LiteOS-A的内核态编译均使用llvm编译器编译，安装方法在搭建基础环境中已提供。若选择移植linux内核，请执行如下命令安装gcc-arm-linux-gnueabi交叉编译工具链，用于编译linux内核态镜像：
```
sudo apt-get install gcc-arm-linux-gnueabi
```
## 编译构建系统介绍<a name="section354343816319"></a>
编译构建流程、编译脚本编写、目录规则、独立编译单个组件、独立编译芯片解决方案等介绍请见[编译构建子系统介绍](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/subsystems/%E7%BC%96%E8%AF%91%E6%9E%84%E5%BB%BA.md)。
## 新建芯片解决方案<a name="section18612153175011"></a>
了解编译框架和搭建完编译环境后，请参考如下步骤新建芯片解决方案：
1. <a name="li20894101862"></a>新建目录
芯片解决方案的目录规则为：device/\{芯片解决方案厂商\}/\{开发板\}。以海思的hispark\_taurus开发板为例，在代码根目录执行如下命令建立目录：
```
mkdir -p device/hisilicon/hispark_taurus
```
芯片解决方案目录树的规则如下：
```
device
└── company # 芯片解决方案厂商
└── board # 开发板名称
├── BUILD.gn # 编译脚本
├── hals # OS南向接口适配
├── linux # 可选，linux内核版本
│ └── config.gni # linux版本编译配置
└── liteos_a # 可选，liteos内核版本
└── config.gni # liteos_a版本编译配置
```
以hispark\_taurus移植linux内核为例，目录树应该如下：
```
device
└── hisilicon
└── hispark_tautus
├── BUILD.gn
├── hals
├── ......
└── linux
└── config.gni
```
目录树建立后开发板相关的源码放到hispark\_taurus目录下。
2. 配置开发板编译选项
[步骤1](#li20894101862)中的config.gni可配置开发板相关的编译选项，编译构建框架将会遵照该配置文件中的参数编译所有用户态OS组件。其中关键的字段说明如下：
```
kernel_type: 开发板使用的内核类型，例如：“liteos_a”, “liteos_m”, “linux”。
kernel_version: 开发板使用的内核版本，例如：“4.19”。
board_cpu: 开发板CPU类型，例如：“cortex-a7”, “riscv32”。
board_arch: 开发板芯片arch, 例如： “armv7-a”, “rv32imac”。
board_toolchain: 开发板自定义的编译工具链名称，例如：“gcc-arm-none-eabi”。若为空，则使用默认为ohos-clang。
board_toolchain_prefix：编译工具链前缀，例如：“gcc-arm-none-eabi”。
board_toolchain_type： 编译工具链类型，目前支持gcc和clang。例如：“gcc” ，“clang”。
board_cflags： 开发板配置的c文件编译选项。
board_cxx_flags： 开发板配置的cpp文件编译选项。
board_ld_flags： 开发板配置的链接选项。
```
还以海思的hispark\_taurus开发板为例，对应的device/hisilicon/hispark\_taurus/config.gni内容如下：
```
# Board CPU type, e.g. "cortex-a7", "riscv32".
board_cpu = "cortex-a7"
# Toolchain name used for system compiling.
# E.g. gcc-arm-none-eabi, arm-linux-harmonyeabi-gcc, ohos-clang, riscv32-unknown-elf.
# Note: The default toolchain is "ohos-clang". It's not mandatory if you use the default toochain.
board_toolchain = "mips-linux-gnu-gcc"
# The toolchain path instatlled, it's not mandatory if you have added toolchian path to your ~/.bashrc.
board_toolchain_path =
rebase_path("//prebuilts/gcc/linux-x86/arm/arm-linux-ohoseabi-gcc/bin",
root_build_dir)
# Compiler prefix.
board_toolchain_prefix = "arm-linux-ohoseabi-"
# Compiler type, "gcc" or "clang".
board_toolchain_type = "gcc"
# Board related common compile flags.
board_cflags = [
]
board_cxx_flags = [
]
board_ld_flags = []
# Board related headfiles search path.
board_include_dirs = []
board_include_dirs += [ rebase_path(
"//prebuilts/gcc/linux-x86/arm/arm-linux-ohoseabi-gcc/target/usr/include",
root_build_dir) ]
# Board adapter dir for OHOS components.
board_adapter_dir = ""
# Sysroot path.
board_configed_sysroot = ""
# Board storage type, it used for file system generation.
storage_type = "emmc"
```
3. 编写开发板编译脚本
步骤1中的BUILD.gn为新增的开发板的编译入口，主要用于编译开发板相关的代码，主要为设备侧驱动、设备侧接口适配\(媒体，图形等\)和开发板的SDK等等。
海思的hispark\_taurus开发板的device/hisilicon/hispark\_taurus/BUILD.gn可写成：
```
# group名称建议与开发板名称一致
group("hispark_taurus") {
deps = [ "//kernel/linux/patches:linux_kernel" ] # 拉起内核编译
deps += [
...... # 开发板其他编译单元
]
}
```
4. 编译调试
在开发板目录下执行hb set和hb build即可启动芯片解决方案的编译，编译框架会以开发板下的BUILD.gn为入口启动编译。
zh-cn/device-dev/porting/transplant-smallchip-prepare-needs.md 0 → 100644
浏览文件 @ 00bc1928
# 移植须知<a name="ZH-CN_TOPIC_0000001152006279"></a>
本文详细介绍如何将OpenHarmony[小型系统](https://device.harmonyos.com/cn/docs/start/introduce/oem_start_guide-0000001054913231)的linux和LiteOS-A内核移植到新的开发板上，要求读者具有一定的嵌入式系统开发经验。建议先查看[入门指导](https://gitee.com/openharmony/docs/blob/master/zh-cn/OpenHarmony-Overview_zh.md)，以了解OpenHarmony软件架构、目录结构、内核子系统和驱动子系统相关知识。当前小型系统已适配的开发板如下表所示：
**表 1** OpenHarmony小型系统已适配的开发板
<a name="table1839174685713"></a>
<table><thead align="left"><tr id="row1540164617570"><th class="cellrowborder" valign="top" width="14.18858114188581%" id="mcps1.2.8.1.1"><p id="p2400466575"><a name="p2400466575"></a><a name="p2400466575"></a>开发板</p>
</th>
<th class="cellrowborder" valign="top" width="16.498350164983503%" id="mcps1.2.8.1.2"><p id="p1401946115713"><a name="p1401946115713"></a><a name="p1401946115713"></a>内核</p>
</th>
<th class="cellrowborder" valign="top" width="13.948605139486054%" id="mcps1.2.8.1.3"><p id="p840194625718"><a name="p840194625718"></a><a name="p840194625718"></a>arch</p>
</th>
<th class="cellrowborder" valign="top" width="10.818918108189182%" id="mcps1.2.8.1.4"><p id="p289613324413"><a name="p289613324413"></a><a name="p289613324413"></a>ROM</p>
</th>
<th class="cellrowborder" valign="top" width="7.119288071192881%" id="mcps1.2.8.1.5"><p id="p73310186181"><a name="p73310186181"></a><a name="p73310186181"></a>RAM</p>
</th>
<th class="cellrowborder" valign="top" width="12.48875112488751%" id="mcps1.2.8.1.6"><p id="p9883194110564"><a name="p9883194110564"></a><a name="p9883194110564"></a>文件系统</p>
</th>
<th class="cellrowborder" valign="top" width="24.937506249375062%" id="mcps1.2.8.1.7"><p id="p1740164625715"><a name="p1740164625715"></a><a name="p1740164625715"></a>Flash 类型</p>
</th>
</tr>
</thead>
<tbody><tr id="row164094619576"><td class="cellrowborder" valign="top" width="14.18858114188581%" headers="mcps1.2.8.1.1 "><p id="p940546135713"><a name="p940546135713"></a><a name="p940546135713"></a>hispark_taurus</p>
</td>
<td class="cellrowborder" valign="top" width="16.498350164983503%" headers="mcps1.2.8.1.2 "><p id="p74084625719"><a name="p74084625719"></a><a name="p74084625719"></a>LiteOS-A和linux-4.19</p>
</td>
<td class="cellrowborder" valign="top" width="13.948605139486054%" headers="mcps1.2.8.1.3 "><p id="p18424818407"><a name="p18424818407"></a><a name="p18424818407"></a>ARM cortex-a7</p>
</td>
<td class="cellrowborder" valign="top" width="10.818918108189182%" headers="mcps1.2.8.1.4 "><p id="p1389623220417"><a name="p1389623220417"></a><a name="p1389623220417"></a>8G</p>
</td>
<td class="cellrowborder" valign="top" width="7.119288071192881%" headers="mcps1.2.8.1.5 "><p id="p533221819182"><a name="p533221819182"></a><a name="p533221819182"></a>1GB</p>
</td>
<td class="cellrowborder" valign="top" width="12.48875112488751%" headers="mcps1.2.8.1.6 "><p id="p1088394155619"><a name="p1088394155619"></a><a name="p1088394155619"></a>VFAT、EXT4</p>
</td>
<td class="cellrowborder" valign="top" width="24.937506249375062%" headers="mcps1.2.8.1.7 "><p id="p14024611578"><a name="p14024611578"></a><a name="p14024611578"></a>eMMC4.5</p>
</td>
</tr>
<tr id="row740646115717"><td class="cellrowborder" valign="top" width="14.18858114188581%" headers="mcps1.2.8.1.1 "><p id="p14405465576"><a name="p14405465576"></a><a name="p14405465576"></a>hispark_aries</p>
</td>
<td class="cellrowborder" valign="top" width="16.498350164983503%" headers="mcps1.2.8.1.2 "><p id="p64084655720"><a name="p64084655720"></a><a name="p64084655720"></a>LiteOS-A</p>
</td>
<td class="cellrowborder" valign="top" width="13.948605139486054%" headers="mcps1.2.8.1.3 "><p id="p44054610573"><a name="p44054610573"></a><a name="p44054610573"></a>ARM cortex-a7</p>
</td>
<td class="cellrowborder" valign="top" width="10.818918108189182%" headers="mcps1.2.8.1.4 "><p id="p289612321545"><a name="p289612321545"></a><a name="p289612321545"></a>16M</p>
</td>
<td class="cellrowborder" valign="top" width="7.119288071192881%" headers="mcps1.2.8.1.5 "><p id="p63323184186"><a name="p63323184186"></a><a name="p63323184186"></a>512M</p>
</td>
<td class="cellrowborder" valign="top" width="12.48875112488751%" headers="mcps1.2.8.1.6 "><p id="p2883124112564"><a name="p2883124112564"></a><a name="p2883124112564"></a>JFFS2</p>
</td>
<td class="cellrowborder" valign="top" width="24.937506249375062%" headers="mcps1.2.8.1.7 "><p id="p34019466577"><a name="p34019466577"></a><a name="p34019466577"></a>SPI NOR</p>
</td>
</tr>
</tbody>
</table>
表1中的开发板可作为待移植开发板的参考，当前LiteOS-A和linux-4.19支持的arch、ROM占用、支持的文件系统和支持的Flash类型如下表所示：
**表 2** OpenHarmony小型系统内核移植信息表
<a name="table1447964818426"></a>
<table><thead align="left"><tr id="row114791148154215"><th class="cellrowborder" valign="top" width="10.54%" id="mcps1.2.6.1.1"><p id="p10479134834218"><a name="p10479134834218"></a><a name="p10479134834218"></a>内核</p>
</th>
<th class="cellrowborder" valign="top" width="24.529999999999998%" id="mcps1.2.6.1.2"><p id="p64791548164211"><a name="p64791548164211"></a><a name="p64791548164211"></a>支持的arch</p>
</th>
<th class="cellrowborder" valign="top" width="8.459999999999999%" id="mcps1.2.6.1.3"><p id="p1347984854212"><a name="p1347984854212"></a><a name="p1347984854212"></a>ROM</p>
</th>
<th class="cellrowborder" valign="top" width="33.35%" id="mcps1.2.6.1.4"><p id="p650414725815"><a name="p650414725815"></a><a name="p650414725815"></a>文件系统</p>
</th>
<th class="cellrowborder" valign="top" width="23.119999999999997%" id="mcps1.2.6.1.5"><p id="p204791048124211"><a name="p204791048124211"></a><a name="p204791048124211"></a>Flash类型</p>
</th>
</tr>
</thead>
<tbody><tr id="row147904814423"><td class="cellrowborder" valign="top" width="10.54%" headers="mcps1.2.6.1.1 "><p id="p1348044810423"><a name="p1348044810423"></a><a name="p1348044810423"></a>LiteOS-A</p>
</td>
<td class="cellrowborder" valign="top" width="24.529999999999998%" headers="mcps1.2.6.1.2 "><p id="p124801448124214"><a name="p124801448124214"></a><a name="p124801448124214"></a>ARMv7</p>
</td>
<td class="cellrowborder" valign="top" width="8.459999999999999%" headers="mcps1.2.6.1.3 "><p id="p5480124814429"><a name="p5480124814429"></a><a name="p5480124814429"></a>&gt; 2M</p>
</td>
<td class="cellrowborder" valign="top" width="33.35%" headers="mcps1.2.6.1.4 "><p id="p20361621185812"><a name="p20361621185812"></a><a name="p20361621185812"></a>VFAT、JFFS2、YAFFS2</p>
</td>
<td class="cellrowborder" valign="top" width="23.119999999999997%" headers="mcps1.2.6.1.5 "><p id="p348018481421"><a name="p348018481421"></a><a name="p348018481421"></a>SPI NOR、NAND、EMMC</p>
</td>
</tr>
<tr id="row148871689436"><td class="cellrowborder" valign="top" width="10.54%" headers="mcps1.2.6.1.1 "><p id="p688718854317"><a name="p688718854317"></a><a name="p688718854317"></a>linux-4.19</p>
</td>
<td class="cellrowborder" valign="top" width="24.529999999999998%" headers="mcps1.2.6.1.2 "><p id="p1588818812437"><a name="p1588818812437"></a><a name="p1588818812437"></a>ARM， ARM64、 MIPS、 X86等</p>
</td>
<td class="cellrowborder" valign="top" width="8.459999999999999%" headers="mcps1.2.6.1.3 "><p id="p1688828194310"><a name="p1688828194310"></a><a name="p1688828194310"></a>&gt; 5M</p>
</td>
<td class="cellrowborder" valign="top" width="33.35%" headers="mcps1.2.6.1.4 "><p id="p2504117185816"><a name="p2504117185816"></a><a name="p2504117185816"></a>VFAT、JFFS2、YAFFS、EXT/2/3/4、NFS等等</p>
</td>
<td class="cellrowborder" valign="top" width="23.119999999999997%" headers="mcps1.2.6.1.5 "><p id="p8452944910"><a name="p8452944910"></a><a name="p8452944910"></a>NOR、NAND、EMMC等</p>
</td>
</tr>
</tbody>
</table>
zh-cn/device-dev/porting/transplant-smallchip-prepare.md 0 → 100644
浏览文件 @ 00bc1928
# 移植准备<a name="ZH-CN_TOPIC_0000001105401594"></a>
- **[移植须知](transplant-smallchip-prepare-needs.md)**
- **[编译构建](transplant-smallchip-prepare-building.md)**
zh-cn/device-dev/porting/transplant-smallchip.md 0 → 100644
浏览文件 @ 00bc1928
# 小型系统芯片移植指导<a name="ZH-CN_TOPIC_0000001132588824"></a>
- **[移植准备](../porting/transplant-smallchip-prepare.md)**
- **[移植内核](../porting/transplant-smallchip-kernel.md)**
- **[驱动移植](../porting/transplant-smallchip-drive.md)**
zh-cn/device-dev/porting/CMake方式组织编译的库移植.md → zh-cn/device-dev/porting/transplant-thirdparty-cmake.md
浏览文件 @ 00bc1928
......@@ -227,12 +227,12 @@ CMake方式可通过指定工具链进行交叉编译，修改并编译该库，
1. 搭建OpenHarmony环境
以hi3518ev300为例，编译出OpenHarmony镜像，烧写到开发板，参考[开发Hi3518第一个示例程序](https://device.harmonyos.com/cn/docs/start/introduce/oem_camera_start_example-0000001051610926)。
以hi3518ev300为例，编译出OpenHarmony镜像，烧写到开发板，参考[开发Hi3518第一个示例程序](../quick-start/quickstart-lite-steps-board3518-running.md)。
进入系统如下所示：
**图 1** OpenHarmony启动成功界面<a name="fig13279524162418"></a>
![](figures/OpenHarmony启动成功界面.png "OpenHarmony启动成功界面")
![](figure/OpenHarmony启动成功界面.png "OpenHarmony启动成功界面")
2. 挂载nfs目录，将[表2](#table1452412391911)中test目录下cctest可执行文件放入nfs目录
3. 执行用例
......@@ -306,7 +306,7 @@ CMake方式可通过指定工具链进行交叉编译，修改并编译该库，
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p1626675812177"><a name="p1626675812177"></a><a name="p1626675812177"></a>将三方库加入工程的gn适配文件</p>
</td>
</tr>
<tr id="row1726610589179"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p12266115815170"><a name="p12266115815170"></a><a name="p12266115815170"></a>openHarmony/third_party/double-conversion/build_thirdpaty.py</p>
<tr id="row1726610589179"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p12266115815170"><a name="p12266115815170"></a><a name="p12266115815170"></a>openHarmony/third_party/double-conversion/build_thirdparty.py</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p122661958201719"><a name="p122661958201719"></a><a name="p122661958201719"></a>GN调用shell命令脚本文件，由上面GN文件将相关命令传入，实现GN转CMake</p>
</td>
......
zh-cn/device-dev/porting/Makefile方式组织编译的库移植.md → zh-cn/device-dev/porting/transplant-thirdparty-makefile.md
浏览文件 @ 00bc1928
......@@ -148,7 +148,7 @@
## 测试<a name="section1830015913391"></a>
yxml库测试步骤与double-conversion库基本一致，可参考[CMake方式组织编译的库移植](CMake方式组织编译的库移植.md#section6686144293611)的测试过程，以下内容介绍yxml库测试用例的使用方法：
yxml库测试步骤与double-conversion库基本一致，可参考[CMake方式组织编译的库移植](transplant-thirdparty-cmake.md#section6686144293611)的测试过程，以下内容介绍yxml库测试用例的使用方法：
**表 3** 生成的test目录结构示意
......@@ -236,7 +236,7 @@ echo "All tests completed successfully."
## 将该库编译添加到OpenHarmony工程中<a name="section1898016213406"></a>
yxml库添加的过程除了适配文件build.gn和config.gni有些许变化外，其他和double-conversion库完全一致，参考[CMake方式组织编译的库移植](CMake方式组织编译的库移植.md#section1651053153715)的配置过程。要修改的适配文件及添加后的目录结构如下：
yxml库添加的过程除了适配文件build.gn和config.gni有些许变化外，其他和double-conversion库完全一致，参考[CMake方式组织编译的库移植](transplant-thirdparty-cmake.md#section1651053153715)的配置过程。要修改的适配文件及添加后的目录结构如下：
- yxml库新增的BUILD.gn实现如下：
......@@ -289,7 +289,7 @@ if (TEST_ENABLE == "YES") {
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p1626675812177"><a name="p1626675812177"></a><a name="p1626675812177"></a>将三方库加入工程的gn适配文件</p>
</td>
</tr>
<tr id="row1726610589179"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p12266115815170"><a name="p12266115815170"></a><a name="p12266115815170"></a>openHarmony/third_party/yxml/build_thirdpaty.py</p>
<tr id="row1726610589179"><td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.1 "><p id="p12266115815170"><a name="p12266115815170"></a><a name="p12266115815170"></a>openHarmony/third_party/yxml/build_thirdparty.py</p>
</td>
<td class="cellrowborder" valign="top" width="50%" headers="mcps1.2.3.1.2 "><p id="p122661958201719"><a name="p122661958201719"></a><a name="p122661958201719"></a>GN调用shell命令脚本文件，由上面GN文件将相关命令传入，实现GN转Makefile</p>
</td>
......
zh-cn/device-dev/porting/transplant-thirdparty.md 0 → 100644
浏览文件 @ 00bc1928
# 三方库移植指导<a name="ZH-CN_TOPIC_0000001157479373"></a>
- **[概述](transplant-thirdparty-overview.md)**
- **[CMake方式组织编译的库移植](transplant-thirdparty-cmake.md)**
- **[Makefile方式组织编译的库移植](transplant-thirdparty-makefile.md)**
zh-cn/device-dev/porting/transplant.md 0 → 100644
浏览文件 @ 00bc1928
# 移植<a name="ZH-CN_TOPIC_0000001157479393"></a>
- **[三方库移植指导](transplant-thirdparty.md)**
- **[轻量系统芯片移植指导](transplant-minichip.md)**
- **[小型系统芯片移植指导](transplant-smallchip.md)**
zh-cn/device-dev/porting/三方库移植指导.md 已删除 100644 → 0
浏览文件 @ bac9ba16
# 三方库移植指导<a name="ZH-CN_TOPIC_0000001157479373"></a>
- **[概述](概述.md)**
- **[CMake方式组织编译的库移植](CMake方式组织编译的库移植.md)**
- **[Makefile方式组织编译的库移植](Makefile方式组织编译的库移植.md)**
zh-cn/device-dev/porting/三方芯片移植指导.md 已删除 100644 → 0
浏览文件 @ bac9ba16
# 三方芯片移植指导<a name="ZH-CN_TOPIC_0000001157479383"></a>
- **[移植准备](移植准备.md)**
- **[内核移植](内核移植.md)**
- **[板级系统移植](板级系统移植.md)**
- **[常见问题](常见问题.md)**
zh-cn/device-dev/porting/内核移植.md 已删除 100644 → 0
浏览文件 @ bac9ba16
# 内核移植<a name="ZH-CN_TOPIC_0000001063110705"></a>
- **[移植概述](移植概述.md)**
- **[内核基础适配](内核基础适配.md)**
- **[内核移植验证](内核移植验证.md)**
zh-cn/device-dev/porting/板级系统移植.md 已删除 100644 → 0
浏览文件 @ bac9ba16
# 板级系统移植<a name="ZH-CN_TOPIC_0000001062604739"></a>
- **[移植概述](移植概述-0.md)**
- **[板级驱动适配](板级驱动适配.md)**
- **[HAL层实现](HAL层实现.md)**
- **[系统组件调用](系统组件调用.md)**
- **[三方组件适配](三方组件适配.md)**
- **[XTS认证](XTS认证.md)**
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或