/vendor
@@ -75,10 +75,10 @@ vendor # 产品解决方案厂商
OpenHarmony的device目录是基础芯片的适配目录，如果在三方芯片应用过程中发现此目录下已经有完整的芯片适配，则不需要再额外移植，直接跳过移植过程进行系统应用开发即可，如果该目录下无对应的芯片移植实现，则根据本文完成移植过程。OpenHarmony三方芯片移植主要过程如下：
**图 1** 芯片移植关键步骤
-
+
## 移植规范
- 满足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)满足基本目录命名和使用规范。
diff --git "a/zh-cn/device-dev/porting/\347\274\226\350\257\221\346\236\204\345\273\272\351\200\202\351\205\215\346\265\201\347\250\213.md" b/zh-cn/device-dev/porting/transplant-chip-prepare-process.md
similarity index 100%
rename from "zh-cn/device-dev/porting/\347\274\226\350\257\221\346\236\204\345\273\272\351\200\202\351\205\215\346\265\201\347\250\213.md"
rename to zh-cn/device-dev/porting/transplant-chip-prepare-process.md
diff --git a/zh-cn/device-dev/porting/transplant-chip-prepare.md b/zh-cn/device-dev/porting/transplant-chip-prepare.md
new file mode 100644
index 0000000000000000000000000000000000000000..358da845b74ef9ce278a3bff22ee09be59501cb2
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-chip-prepare.md
@@ -0,0 +1,7 @@
+# 移植准备
+
+- **[移植须知](transplant-chip-prepare-knows.md)**
+
+- **[编译构建适配流程](transplant-chip-prepare-process.md)**
+
+
diff --git a/zh-cn/device-dev/porting/transplant-chip.md b/zh-cn/device-dev/porting/transplant-chip.md
new file mode 100644
index 0000000000000000000000000000000000000000..d0fbee119dd00fe8fb475196714a9a253e676f2b
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-chip.md
@@ -0,0 +1,11 @@
+# 三方芯片移植指导
+
+- **[移植准备](transplant-chip-prepare.md)**
+
+- **[内核移植](transplant-chip-kernel.md)**
+
+- **[板级系统移植](transplant-chip-board.md)**
+
+- **[常见问题](transplant-chip-faqs.md)**
+
+
diff --git a/zh-cn/device-dev/porting/transplant-minichip.md b/zh-cn/device-dev/porting/transplant-minichip.md
new file mode 100644
index 0000000000000000000000000000000000000000..58bebe026e881c23d1d2aa1cd173cc6bc86ea777
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-minichip.md
@@ -0,0 +1,11 @@
+# 轻量系统芯片移植指导
+
+- **[移植准备](transplant-chip-prepare.md)**
+
+- **[内核移植](transplant-chip-kernel.md)**
+
+- **[板级系统移植](transplant-chip-board.md)**
+
+- **[常见问题](transplant-chip-faqs.md)**
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-drive-des.md b/zh-cn/device-dev/porting/transplant-smallchip-drive-des.md
new file mode 100644
index 0000000000000000000000000000000000000000..bba3736632bc974821981b0e4839f629ab4d1551
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-drive-des.md
@@ -0,0 +1,11 @@
+# 移植概述
+
+驱动主要包含两部分，平台驱动和器件驱动。平台驱动主要包括通常在SOC内的GPIO、I2C、SPI等；器件驱动则主要包含通常在SOC外的器件，如 LCD、TP、WLAN等。
+
+**图 1** OpenHarmony 驱动分类
+
+
+
+
+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)。
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-drive-oom.md b/zh-cn/device-dev/porting/transplant-smallchip-drive-oom.md
new file mode 100644
index 0000000000000000000000000000000000000000..353aa15d2a8b5b84c66b3192fc30ccc8c6975694
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-drive-oom.md
@@ -0,0 +1,390 @@
+# 器件驱动移植
+
+- [LCD驱动移植](#section1574513454119)
+- [TP驱动移植](#section20284142116422)
+- [WLAN驱动移植](#section0969448164217)
+
+本章节讲解如何移植各类器件驱动。
+
+## LCD驱动移植
+
+移植LCD驱动的主要工作是编写一个驱动，在驱动中生成模型的实例，并完成注册。
+
+这些LCD的驱动被放置在源码目录//drivers/framework/model/display/driver/panel中。
+
+1. 创建Panel驱动
+
+ 创建HDF驱动，在驱动初始化中调用RegisterPanel接口注册模型实例。如:
+
+ ```
+ int32_t LCDxxEntryInit(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 = LCDxxEntryInit,
+ };
+
+ HDF_INIT(g_xxxxDevEntry);
+ ```
+
+2. 配置加载panel驱动
+
+ 产品的所有设备信息被定义在源码文件//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs中。修改该文件，在display的host中，名为device\_lcd的device中增加配置。
+
+ > **注意：**
+ >moduleName 要与panel驱动中的moduleName相同。
+
+ ```
+ root {
+ ...
+ display :: host {
+ device_lcd :: device {
+ deviceN :: deviceNode {
+ policy = 0;
+ priority = 100;
+ preload = 2;
+ moduleName = "LCD_XXXX";
+ }
+ }
+ }
+ }
+ ```
+
+
+## TP驱动移植
+
+本节描述如何移植触摸屏驱动。触摸屏的器件驱动被放置在源码目录//drivers/framework/model/input/driver/touchscreen中。 移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。
+
+详细的驱动开发指导，请参考 [TOUCHSCREEN开发指导](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/TOUCHSCREEN.md)。
+
+1. 创建触摸屏器件驱动
+
+ 在上述touchscreen目录中创建名为touch\_ic\_name.c的文件。编写如下内容
+
+ ```
+ #include "hdf_touch.h"
+
+ static int32_t HdfXXXXChipInit(struct HdfDeviceObject *device)
+ {
+ ChipDevice *tpImpl = CreateXXXXTpImpl();
+ if(RegisterChipDevice(tpImpl) != HDF_SUCCESS) { // 注册ChipDevice模型
+ ReleaseXXXXTpImpl(tpImpl);
+ return HDF_FAILURE;
+ }
+ return HDF_SUCCESS;
+ }
+
+ struct HdfDriverEntry g_touchXXXXChipEntry = {
+ .moduleVersion = 1,
+ .moduleName = "HDF_TOUCH_XXXX", // 注意这里的moduleName要与后续的配置完全一致
+ .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)
+ |
+ 实现固件升级
+ |
+
+
+
+
+2. 配置产品，加载器件驱动
+
+ 产品的所有设备信息被定义在源码文件//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs中。修改该文件，在名为input的host中，名为device\_touch\_chip的device中增加配置。
+
+ > **说明：**
+ >moduleName 要与触摸屏驱动中的moduleName相同。
+
+ ```
+ deviceN :: deviceNode {
+ policy = 0;
+ priority = 130;
+ preload = 0;
+ permission = 0660;
+ moduleName = "HDF_TOUCH_XXXX";
+ deviceMatchAttr = "touch_XXXX_configs";
+ }
+ ```
+
+
+## WLAN驱动移植
+
+WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负责处理WLAN流量。
+
+**图 1** OpenHarmony WLAN结构示意图
+
+
+
+
+如图1，左半部分负责管理WLAN设备，右半部分负责WLAN流量。HDF WLAN分别为这两部分做了抽象，驱动的移植过程可以看做分别实现这两部分所需接口。这些接口有：
+
+
+接口
+ |
+定义头文件
+ |
+接口说明
+ |
+
|---|
+
+HdfChipDriverFactory
+ |
+drivers\framework\include\wifi\hdf_wlan_chipdriver_manager.h
+ |
+ChipDriver的Factory，用于支持一个芯片多个WLAN端口
+ |
+
+HdfChipDriver
+ |
+drivers\framework\include\wifi\wifi_module.h
+ |
+每个WLAN端口对应一个HdfChipDriver，用来管理一个特定端口
+ |
+
+NetDeviceInterFace
+ |
+drivers\framework\include\wifi\net_device.h
+ |
+与协议栈之间的接口，如发送数据、设置网络接口状态等
+ |
+
+
+
+
+> **说明：**
+>详细的接口开发指导，请参考[WLAN开发](https://gitee.com/openharmony/docs/blob/master/zh-cn/device-dev/driver/WLAN.md)。
+
+具体的移植步骤如下：
+
+1. 创建HDF WLAN 芯片驱动
+
+ 在目录/device/vendor\_name/peripheral/wifi/chip\_name/ 创建文件 hdf\_wlan\_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)
+ |
+ 获取当前芯片支持的最大接口数
+ |
+
+
+
+
+ 其中Build方法负责创建一个管理指定网络接口的对象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/vendor\_name/product\_name/config/wifi/wlan\_chip\_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 = 0xXXXX; /* your vendor id */
+ deviceId = [0xXXXX]; /*your supported devices */
+ }
+ }
+ }
+ }
+ }
+ ```
+
+ > **说明：**
+ >路径和文件中的vendor\_name、product\_name、chip\_name请替换成实际名称
+ >vendorId 和 deviceId需要根据实际芯片的识别码进行填写。
+
+3. 编写配置文件，加载驱动
+
+ 产品的所有设备信息被定义在源码文件//vendor/vendor\_name/product\_name/config/device\_info/device\_info.hcs中。修改该文件，在名为network的host中，名为device\_wlan\_chips的device中增加配置。模板如下：
+
+ ```
+ deviceN :: deviceNode {
+ policy = 0;
+ preload = 2;
+ moduleName = "HDF_WLAN_CHIPS";
+ deviceMatchAttr = "hdf_wlan_chips_chip_name";
+ serviceName = "driverName";
+ }
+ ```
+
+ > **说明：**
+ >moduleName 要与HDF WLAN 芯片驱动中的moduleName相同。
+
+4. 修改Kconfig文件，让移植的WLAN模组出现再内核配置中
+
+ 在device/vendor\_name/drivers/Kconfig中增加配置菜单，模板如下
+
+ ```
+ config DRIVERS_HDF_WIFI_chip_name
+ bool "Enable chip_name Host driver"
+ default n
+ depends on DRIVERS_HDF_WLAN help
+ Answer Y to enable chip_name Host driver.
+ ```
+
+ > **说明：**
+ >请替换模板中的chip\_name为实际的芯片名称
+
+5. 修改构建脚本，让驱动参与内核构建
+
+ 在源码文件//device/vendor\_name/drivers/lite.mk末尾追加如下内容
+
+ ```
+ ifeq ($(LOSCFG_DRIVERS_HDF_WIFI_chip_name), y)
+ # 构建完成要链接一个叫hdf_wlan_chipdriver_chip_name的对象，建议按这个命名，防止冲突
+ LITEOS_BASELIB += -lhdf_wlan_chipdriver_chip_name
+ # 增加构建目录gpio
+ LIB_SUBDIRS += ../peripheral/wifi/chip_name
+ endif
+ ```
+
+ > **说明：**
+ >请替换模板中的chip\_name为实际的芯片名称
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-drive-plat.md b/zh-cn/device-dev/porting/transplant-smallchip-drive-plat.md
new file mode 100644
index 0000000000000000000000000000000000000000..a28bc2faf3fae4cb54a85094e10a185d20b34041
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-drive-plat.md
@@ -0,0 +1,165 @@
+# 平台驱动移植
+
+在这一步，我们会在源码目录//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中。
+
+ > **说明：**
+ >moduleName要与驱动定义中的相同。
+
+ ```
+ root {
+ ...
+ platform :: host {
+ device_gpio :: device {
+ device0 :: deviceNode {
+ policy = 0;
+ priority = 10;
+ permission = 0644;
+ moduleName = "SOC_NAME_gpio_driver";
+ }
+ }
+ }
+ }
+ ```
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-drive.md b/zh-cn/device-dev/porting/transplant-smallchip-drive.md
new file mode 100644
index 0000000000000000000000000000000000000000..8d265ae4d089593010d0ddd7ef6bcbc0ab327f99
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-drive.md
@@ -0,0 +1,9 @@
+# 驱动移植
+
+- **[移植概述](transplant-smallchip-drive-des.md)**
+
+- **[平台驱动移植](transplant-smallchip-drive-plat.md)**
+
+- **[器件驱动移植](transplant-smallchip-drive-oom.md)**
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-kernel-a.md b/zh-cn/device-dev/porting/transplant-smallchip-kernel-a.md
new file mode 100644
index 0000000000000000000000000000000000000000..f4de2f397dbc53de27f711e7bfa1e909a35b222c
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-kernel-a.md
@@ -0,0 +1,265 @@
+# LiteOS-A内核
+
+- [移植概述](#section14876256185510)
+ - [移植场景](#section1986014410569)
+ - [目录规范](#section10916181716564)
+
+- [基础适配](#section814974018565)
+ - [编程样例](#section10854481825)
+
+- [验证](#section646410453212)
+
+## 移植概述
+
+### 移植场景
+
+LiteOS-A当前支持ARMv7-a指令集架构，如果三方芯片为ARMv7-a架构，可以进行内核基础适配；否则还需要先根据芯片的架构来新增内核对该芯片架构的支持，这个工作较为复杂，不在这篇文章范围内。
+
+### 目录规范
+
+LiteOS-A目录规范参考[LiteOS-A 简介](https://gitee.com/openharmony/kernel_liteos_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** 整体启动流程
+
+
+
+
+从图1中可以看到，内核基础适配需要单板进行适配的代码包含三部分：
+
+- 新增target\_config.h文件，其中新增单板硬件配置参数和特性开关的配置参数，具体说明如下：
+
+ **表 1** target\_config.h配置项说明
+
+
+ 配置项
+ |
+ 说明
+ |
+
|---|
+
+ OS_SYS_CLOCK
+ |
+ 系统cycle的频率
+ |
+
+ DDR_MEM_ADDR
+ |
+ 系统内存的起始地址
+ |
+
+ DDR_MEM_SIZE
+ |
+ 系统内存的大小
+ |
+
+ PERIPH_PMM_BASE
+ |
+ 外设寄存器的起始地址
+ |
+
+ PERIPH_PMM_SIZE
+ |
+ 外设寄存器的长度大小
+ |
+
+ OS_HWI_MIN
+ |
+ 系统中断最小值
+ |
+
+ OS_HWI_MAX
+ |
+ 系统中断最大值
+ |
+
+ NUM_HAL_INTERRUPT_UART0
+ |
+ UART0中断号
+ |
+
+ UART0_REG_BASE
+ |
+ UART0寄存器基址
+ |
+
+ GIC_BASE_ADDR
+ |
+ GIC中断寄存器基址
+ |
+
+ GICD_OFFSET
+ |
+ GICD相对GIC基址的偏移地址
+ |
+
+ GICC_OFFSET
+ |
+ GICC相对GIC基址的偏移地址
+ |
+
+
+
+
+- SystemInit函数用于单板用户态业务初始化，典型的初始化场景如图2所示：
+
+ **图 1** 业务启动流程
+
+
+ 
+
+- main函数用于内核基础初始化和单板内核态业务初始化，流程如下图3所示，整体由内核启动框架主导初始化流程，图中浅蓝色部分为启动框架中可接受外部模块注册启动的阶段。
+
+ > **注意：**
+ >同一层级内的模块不能有依赖关系。
+
+ **图 2** 内核启动框架
+ 
+
+ **表 2** 启动框架层级
+
+
+ 层级
+ |
+ 说明
+ |
+
|---|
+
+ LOS_INIT_LEVEL_EARLIEST
+ |
+ 最早期初始化
+ 说明：不依赖架构，单板以及后续模块会对其有依赖的纯软件模块初始化
+ 例如：Trace模块
+ |
+
+ LOS_INIT_LEVEL_ARCH_EARLY
+ |
+ 架构早期初始化
+ 说明：架构相关，后续模块会对其有依赖的模块初始化，如启动过程中非必需的功能，建议放到LOS_INIT_LEVEL_ARCH层
+ |
+
+ LOS_INIT_LEVEL_PLATFORM_EARLY
+ |
+ 平台早期初始化
+ 说明：单板平台、驱动相关，后续模块会对其有依赖的模块初始化，如启动过程中必需的功能，建议放到LOS_INIT_LEVEL_PLATFORM层
+ 例如：uart模块
+ |
+
+ LOS_INIT_LEVEL_KMOD_PREVM
+ |
+ 内存初始化前的内核模块初始化
+ 说明：在内存初始化之前需要使能的模块初始化
+ |
+
+ LOS_INIT_LEVEL_VM_COMPLETE
+ |
+ 基础内存就绪后的初始化
+ 说明：此时内存初始化完毕，需要进行使能且不依赖进程间通讯机制与系统进程的模块初始化
+ 例如：共享内存功能
+ |
+
+ LOS_INIT_LEVEL_ARCH
+ |
+ 架构后期初始化
+ 说明：架构拓展功能相关，后续模块会对其有依赖的模块初始化
+ |
+
+ LOS_INIT_LEVEL_PLATFORM
+ |
+ 平台后期初始化
+ 说明：单板平台、驱动相关，后续模块会对其有依赖的模块初始化
+ 例如：驱动内核抽象层初始化（mmc、mtd）
+ |
+
+ LOS_INIT_LEVEL_KMOD_BASIC
+ |
+ 内核基础模块初始化
+ 说明：内核可拆卸的基础模块初始化
+ 例如：VFS初始化
+ |
+
+ LOS_INIT_LEVEL_KMOD_EXTENDED
+ |
+ 内核扩展模块初始化
+ 说明：内核可拆卸的扩展模块初始化
+ 例如：系统调用初始化、ProcFS初始化、Futex初始化、HiLog初始化、HiEvent初始化、LiteIPC初始化
+ |
+
+ LOS_INIT_LEVEL_KMOD_TASK
+ |
+ 内核任务创建
+ 说明：进行内核任务的创建（内核线程，软件定时器任务）
+ 例如：资源回收系统常驻任务的创建、SystemInit任务创建、CPU占用率统计任务创建
+ |
+
+
+
+
+ 进行单板移植适配，推荐关注LOS\_INIT\_LEVEL\_ARCH至LOS\_INIT\_LEVEL\_KMOD\_TASK之间的层级，且尽可能拆分初始化行为进行细化阶段注册。
+
+ > **说明：**
+ >启动框架中同一层级内的注册模块不能有依赖关系，建议新增模块按照上述启动阶段进行模块初始化的拆分，按需注册启动。
+ >可通过查看系统编译生成文件OHOS\_Image.map中.rodata.init.kernel.\*段内的符号表来了解当前已注册进内核启动框架中的各个模块初始化入口，以及检查新注册的模块初始化入口是否生效。
+
+
+### 编程样例
+
+在单板SDK文件中
+
+```
+/* 内核启动框架头文件 */
+#include "los_init.h"
+......
+
+/* 新增模块的初始化函数 */
+unsigned int OsSampleModInit(void)
+{
+ PRINTK("OsSampleModInit SUCCESS!\n");
+ ......
+}
+......
+/* 在启动框架的目标层级中注册新增模块 */
+LOS_MODULE_INIT(OsSampleModInit, LOS_INIT_LEVEL_KMOD_EXTENDED);
+```
+
+## 验证
+
+```
+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
+
+```
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-kernel-linux.md b/zh-cn/device-dev/porting/transplant-smallchip-kernel-linux.md
new file mode 100644
index 0000000000000000000000000000000000000000..911329dbd1b9971e422b9242171c031102a137b0
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-kernel-linux.md
@@ -0,0 +1,125 @@
+# Linux内核
+
+- [移植概述](#section6282121355111)
+ - [基本信息](#section19589322515)
+ - [Bootloader](#section19062510518)
+
+- [适配编译和烧录启动](#section11112101695215)
+- [验证](#section17318153325311)
+
+## 移植概述
+
+Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后，进行基础的内核编译构建及验证。
+
+### 基本信息
+
+当前Linux内核基线是基于Linux社区 4.19 LTS版本演进，合入CVE及bugfix补丁。具体信息参考[代码库](https://gitee.com/openharmony/kernel_linux)，对应repo工程代码路径为kernel/linux-4.19。
+
+### Bootloader
+
+可以使用芯片厂商自带的Bootloader，或者是开源Uboot等加载内核镜像。比如为支持Hi3516DV300开发板，OpenHarmony引入的开源[Uboot](https://gitee.com/openharmony/device_hisilicon_third_party_uboot)。
+
+## 适配编译和烧录启动
+
+1. 准备内核config（特别是芯片相关的config）。
+
+ config文件所在源码目录：kernel/linux/config/
+
+ 以hi3516dv300芯片为例，可在对应的linux-4.19/arch/arm/configs/目录下新建\_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目录，新建\_patch目录，放置相关芯片补丁，注意hdf.patch等驱动补丁。
+
+3. 编译。
+
+ 具体内核编译入口脚本位于工程目录kernel/linux/patches/下面，版本级整编命令会通过BUILD.gn进入kernel\_module\_build.sh和kernel.mk，需要在这2个文件中针对性进行patch及defconfig文件路径、编译器、芯片架构、内核Image格式等的适配。
+
+ 通过编译错误日志调整补丁，典型错误场景：
+
+ （1）补丁合入失败，出现冲突，需要进行上下文适配修改。
+
+ （2）编译失败，内核版本差异（函数实现调整等）需要针对性进行内核适配。
+
+ > **注意：**
+ >- 参考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)'
+ ```
+
+
+## 验证
+
+调试init进程、启动shell和运行简单的用户态程序，验证内核移植是否成功。OpenHarmony[小型系统](https://device.harmonyos.com/cn/docs/start/introduce/oem_start_guide-0000001054913231)的OS镜像结构以及linux用户态的启动流程如下图1所示：
+
+**图 1** 基于linux内核的OS镜像结构和用户态程序启动流程
+
+
+
+
+基于上述流程，推荐按以下步骤完成验证：
+
+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启动正常日志
+
+
+ 
+
+ 正常进入shell后执行ls命令，串口打印信息如下图：
+
+ **图 3** 正常进入shell后输入ls命令串口打印
+
+
+ 
+
+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
+ ```
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-kernel.md b/zh-cn/device-dev/porting/transplant-smallchip-kernel.md
new file mode 100644
index 0000000000000000000000000000000000000000..a1adc2dde7e4c576f8fc9137c42217474a15311e
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-kernel.md
@@ -0,0 +1,7 @@
+# 移植内核
+
+- **[LiteOS-A内核](transplant-smallchip-kernel-a.md)**
+
+- **[Linux内核](transplant-smallchip-kernel-linux.md)**
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-prepare-building.md b/zh-cn/device-dev/porting/transplant-smallchip-prepare-building.md
new file mode 100644
index 0000000000000000000000000000000000000000..6ca5022e46a9574c8856578edc48294feffee89c
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-prepare-building.md
@@ -0,0 +1,142 @@
+# 编译构建
+
+- [编译环境搭建](#section3336103410314)
+- [编译构建系统介绍](#section354343816319)
+- [新建芯片解决方案](#section18612153175011)
+
+## 编译环境搭建
+
+首先请搭建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
+```
+
+## 编译构建系统介绍
+
+编译构建流程、编译脚本编写、目录规则、独立编译单个组件、独立编译芯片解决方案等介绍请见[编译构建子系统介绍](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)。
+
+## 新建芯片解决方案
+
+了解编译框架和搭建完编译环境后，请参考如下步骤新建芯片解决方案：
+
+1. 新建目录
+
+ 芯片解决方案的目录规则为：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为入口启动编译。
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-prepare-needs.md b/zh-cn/device-dev/porting/transplant-smallchip-prepare-needs.md
new file mode 100644
index 0000000000000000000000000000000000000000..afe392369f2eb34c0c5a8dcf5a6204850347dd11
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-prepare-needs.md
@@ -0,0 +1,98 @@
+# 移植须知
+
+本文详细介绍如何将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小型系统已适配的开发板
+
+
+开发板
+ |
+内核
+ |
+arch
+ |
+ROM
+ |
+RAM
+ |
+文件系统
+ |
+Flash 类型
+ |
+
|---|
+
+hispark_taurus
+ |
+LiteOS-A和linux-4.19
+ |
+ARM cortex-a7
+ |
+8G
+ |
+1GB
+ |
+VFAT、EXT4
+ |
+eMMC4.5
+ |
+
+hispark_aries
+ |
+LiteOS-A
+ |
+ARM cortex-a7
+ |
+16M
+ |
+512M
+ |
+JFFS2
+ |
+SPI NOR
+ |
+
+
+
+
+表1中的开发板可作为待移植开发板的参考，当前LiteOS-A和linux-4.19支持的arch、ROM占用、支持的文件系统和支持的Flash类型如下表所示：
+
+**表 2** OpenHarmony小型系统内核移植信息表
+
+
+内核
+ |
+支持的arch
+ |
+ROM
+ |
+文件系统
+ |
+Flash类型
+ |
+
|---|
+
+LiteOS-A
+ |
+ARMv7
+ |
+> 2M
+ |
+VFAT、JFFS2、YAFFS2
+ |
+SPI NOR、NAND、EMMC
+ |
+
+linux-4.19
+ |
+ARM， ARM64、 MIPS、 X86等
+ |
+> 5M
+ |
+VFAT、JFFS2、YAFFS、EXT/2/3/4、NFS等等
+ |
+NOR、NAND、EMMC等
+ |
+
+
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip-prepare.md b/zh-cn/device-dev/porting/transplant-smallchip-prepare.md
new file mode 100644
index 0000000000000000000000000000000000000000..6ec4b45dff790140fe40830288b5c0bb961ceddb
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip-prepare.md
@@ -0,0 +1,7 @@
+# 移植准备
+
+- **[移植须知](transplant-smallchip-prepare-needs.md)**
+
+- **[编译构建](transplant-smallchip-prepare-building.md)**
+
+
diff --git a/zh-cn/device-dev/porting/transplant-smallchip.md b/zh-cn/device-dev/porting/transplant-smallchip.md
new file mode 100644
index 0000000000000000000000000000000000000000..4ba38ff4484d56d07681a0dce923d1839b80df87
--- /dev/null
+++ b/zh-cn/device-dev/porting/transplant-smallchip.md
@@ -0,0 +1,9 @@
+# 小型系统芯片移植指导
+
+- **[移植准备](../porting/transplant-smallchip-prepare.md)**
+
+- **[移植内核](../porting/transplant-smallchip-kernel.md)**
+
+- **[驱动移植](../porting/transplant-smallchip-drive.md)**
+
+
diff --git "a/zh-cn/device-dev/porting/CMake\346\226\271\345\274\217\347\273\204\347\273\207\347\274\226\350\257\221\347\232\204\345\272\223\347\247\273\346\244\215.md" b/zh-cn/device-dev/porting/transplant-thirdparty-cmake.md
similarity index 98%
rename from "zh-cn/device-dev/porting/CMake\346\226\271\345\274\217\347\273\204\347\273\207\347\274\226\350\257\221\347\232\204\345\272\223\347\247\273\346\244\215.md"
rename to zh-cn/device-dev/porting/transplant-thirdparty-cmake.md
index bb7404eca3e670115c48f40f4f219347162c5064..fb23041d28a62d9768390ecdf41c6cc3acd4c4e2 100644
--- "a/zh-cn/device-dev/porting/CMake\346\226\271\345\274\217\347\273\204\347\273\207\347\274\226\350\257\221\347\232\204\345\272\223\347\247\273\346\244\215.md"
+++ b/zh-cn/device-dev/porting/transplant-thirdparty-cmake.md
@@ -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启动成功界面
- 
+ 
2. 挂载nfs目录，将[表2](#table1452412391911)中test目录下cctest可执行文件放入nfs目录
3. 执行用例
@@ -306,7 +306,7 @@ CMake方式可通过指定工具链进行交叉编译，修改并编译该库，
将三方库加入工程的gn适配文件
|
|
-