@hmos-library-adapter/fast 0.0.17-beta.0 → 0.0.17-beta.2

package/node_modules/@ohos-agent/pc-adapter/skills/openharmony-device-porting/references-full/porting/porting-linux-kernel.md

@@ -0,0 +1,317 @@
+# 一种快速移植OpenHarmony Linux内核的方法
+
+
+## 移植概述
+
+
+本文面向希望将OpenHarmony移植到三方芯片平台硬件的开发者，介绍一种借助三方芯片平台自带Linux内核的现有能力，快速移植OpenHarmony到三方芯片平台的方法。
+
+
+## 移植到三方芯片平台的整体思路
+
+
+### 内核态层和用户态层
+
+为了更好的解释整个内核移植，首先需要介绍一些概念：
+
+我们可以把OpenHarmony简单的分为
+
+OpenHarmony = OpenHarmony内核态层 + OpenHarmony用户态层。
+
+![zh-cn_image_0000001167753296](figures/zh-cn_image_0000001167753296.png)
+
+其中OpenHarmony内核层就是上图的紫色部分，可以看到，它主要由内核本身（如Linux Kernel，LiteOS），和一些运行在内核态的一些特性组成，比如HDF等。
+
+而OpenHarmony用户态层，在上图，就是紫色之外的部分。可以看到，由下往上看，它主要由系统服务层，框架层，应用层组成。在这儿我们将这三层整体称为“OpenHarmony用户态层”。
+
+为什么这么区分呢？因为我们这篇文章主要是要讨论如何快速的把OpenHarmony移植到三方芯片平台上。而OpenHarmony的用户态层，整体来说和三方芯片平台的耦合度不高，移植较为方便。而内核态层中的内核本身以及HDF驱动框架等，和三方芯片平台的耦合度较高，是移植的重难点。我们先做这个区分，就是为了先把聚光灯打到我们最需要关注的OpenHarmony内核态层上，开始分析和解题。另外说明，本文只包含Linux内核的快速移植，不包含LiteOS的移植。
+
+
+### 获得内核态层的两种方法
+
+为了表述方便，我们在下文部分地方用“OH”代替“OpenHarmony”。
+
+将OH内核态层继续分解。
+
+OH内核态层 = OH Linux内核 + OH内核态特性（可选特性或者必选特性，如必选特性HDF，今后的可选特性HMDFS等）。
+
+而OH Linux内核 = 标准LTS Linux 内核 + 三方SoC芯片平台代码 + OH内核态基础代码（支撑OH用户态层运行的最基础代码）。
+
+因此OH内核态层 = 标准LTS Linux 内核 + 三方SoC芯片平台代码 + OH内核态基础代码 + OH内核态特性（如HDF）。
+
+![zh-cn_image_0000001210623027](figures/zh-cn_image_0000001210623027.png)
+
+而将前两项组合，标准LTS Linux 内核 + 三方SoC芯片平台代码，其实就是一个三方Linux内核的基础组成。从上面的推导可以看出，OpenHarmony 内核态层其实能够由两种方法得到：
+
+方法一：OH 内核态层 = 三方Linux内核 + OH内核态基础代码 + OH内核态特性（如HDF，今后的HMDFS等）。
+
+也就是直接借助三方Linux内核，再加上基础OH内核态基础代码、以及HDF等OH内核态特性。
+
+方法二：OH 内核态层 = OH Linux内核 + OH内核态特性（如HDF，今后的HMDFS等）。
+
+也就是直接采用OHLinux内核，然后再加入OH的其他内核态特性。
+
+当前方法二中OHLinux内核支持的三方芯片平台还不够丰富。为了能够响应三方开发者快速移植OpenHarmony的要求，下文会着重介绍方法一，即借助三方已有的Linux内核，来快速移植OpenHarmony。
+
+
+### **借助已有Linux内核来移植OpenHarmony的流程**
+
+
+整个移植流程可以分为三步：
+
+
+1. 准备整体构建环境，包括将三方芯片平台的现有内核代码拷贝到OpenHarmony的整体编译环境下。
+
+2. OpenHarmony内核态基础代码的移植。
+
+3. OpenHarmony内核态必选特性（如HDF等）的移植。
+
+
+详细步骤在接下来的章节中介绍。
+
+
+## 移植到三方芯片平台的步骤
+
+下面以树莓派3b (BCM2837) 为例，演示将OpenHarmony移植到树莓派的过程。
+
+
+### 准备整体构建环境
+
+1. 将三方内核纳入OpenHarmony编译环境。
+   完整编译过一遍标准Hi3516DV300的内核之后，clone树莓派内核源码并复制到manifest输出目录下：
+
+     
+   ```
+   export PROJ_ROOT=[OpenHarmony manifest]
+   git clone https://gitee.com/xfan1024/oh-rpi3b-kernel.git
+   cp -r oh-rpi3b-kernel $PROJ_ROOT/out/KERNEL_OBJ/kernel/src_tmp/linux-rpi3b
+   ```
+
+2. 配置树莓派内核编译环境。
+     
+   ```
+   # 进入树莓派kernel目录
+   cd out/KERNEL_OBJ/kernel/src_tmp/linux-rpi3b
+   
+   # 配置编译环境,使用工程项目自带的clang
+   export PATH=$PROJ_ROOT/prebuilts/clang/ohos/linux-x86_64/llvm/bin:$PROJ_ROOT/prebuilts/gcc/linux-x86/arm/gcc-linaro-7.5.0-arm-linux-gnueabi/bin/:$PATH
+   export MAKE_OPTIONS="ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- CC=clang HOSTCC=clang"
+   export PRODUCT_PATH=vendor/hisilicon/hispark_taurus_linux
+   ```
+
+3. 注释掉clang不识别的flag。
+   PROJ_ROOT/out/KERNEL_OBJ/kernel/src_tmp/linux-rpi3b/arch/arm/Makefile注释掉以下这一行：
+
+     
+   ```
+   KBUILD_CFLAGS  +=-fno-omit-frame-pointer -mapcs -mno-sched-prolog
+   ```
+
+
+### 移植内核态基础代码
+
+目前OpenHarmony内核态的基础代码，主要是日志服务相关。轻量化内核日志服务代码包含：
+
+  
+```
+drivers/staging/hilog
+drivers/staging/hievent
+```
+
+将以上代码，从OpenHarmony内核代码目录kernel/linux/linux-4.19/drivers/staging中，拷贝到out/KERNEL_OBJ/kernel/src_tmp/linux-rpi3b/drivers/staging下。
+
+在三方内核的drivers/staging/Kconfig文件内增加如下代码：
+
+  
+```
+source "drivers/staging/hilog/Kconfig"
+source "drivers/staging/hievent/Kconfig"
+```
+
+在三方内核的drivers/staging/Makefile文件内增加如下代码：
+```
+obj-$(CONFIG_HILOG)             += hilog/
+obj-$(CONFIG_HIEVENT)           += hievent/
+```
+
+在内核config项中打开对应的CONFIG控制宏：CONFIG_HILOG和CONFIG_HIEVENT。
+
+具体日志使用说明请参见：[Hilog_lite组件介绍](https://gitcode.com/openharmony/hiviewdfx_hilog_lite/blob/master/README_zh.md)。
+
+
+### 移植内核态必选特性HDF
+
+1. 打HDF补丁。
+   在Linux内核打HDF补丁时，执行补丁shell脚本合入HDF补丁。
+
+   1. 配置HDF补丁脚本的四个变量参数。
+   2. 获取patch_hdf.sh脚本。
+   3. 执行patch_hdf.sh脚本依次传入四个变量参数。
+
+   patch_hdf.sh脚本四个参数含义为：第一个入参为工程根目录路径，第二入参为内核目录路径，第三个入参为内核版本路径，第四个参数是当前设备名。
+
+     
+   ```
+   ./patch_hdf.sh [工程根目录路径] [内核目录路径] [内核补丁路径] [设备名]
+   ```
+
+   以树莓派3b为示例介绍：
+
+     
+   ```
+   # 进入树莓派kernel目录。
+   PROJ_ROOT/drivers/hdf_core/adapter/khdf/linux/patch_hdf.sh \
+   PROJ_ROOT  # 指定工程根目录路径 \
+   PROJ_ROOT/out/KERNEL_OBJ/kernel/src_tmp/linux-rpi3b  # 打补丁的内核目录路径 \
+   PROJ_ROOT/kernel/linux/patches/linux-4.19 # 内核补丁路径.\
+   hi3516dv300 # 设备名.
+   ```
+
+2. 配置config。
+   提供HDF基本配置，如果需要其他功能，通过menuconfig打开对应驱动开关即可。
+
+   HDF补丁执行成功后，默认HDF开关是关闭的，打开HDF基本配置选项如下：
+
+     
+   ```
+   CONFIG_DRIVERS_HDF=y
+   CONFIG_HDF_SUPPORT_LEVEL=2
+   CONFIG_DRIVERS_HDF_PLATFORM=y
+   CONFIG_DRIVERS_HDF_PLATFORM_MIPI_DSI=y
+   CONFIG_DRIVERS_HDF_PLATFORM_GPIO=y
+   CONFIG_DRIVERS_HDF_PLATFORM_I2C=y
+   CONFIG_DRIVERS_HDF_PLATFORM_UART=y
+   CONFIG_DRIVERS_HDF_TEST=y
+   ```
+
+   或者通过menuconfig界面打开HDF相关配置，命令如下：
+
+     
+   ```
+   # 生成 .config 配置文件。
+   make ${MAKE_OPTIONS} rpi3b_oh_defconfig
+   
+   # 更改HDF内核配置。
+   make ${MAKE_OPTIONS} menuconfig
+   # [*] Device Drivers
+   # [*]   HDF driver framework support --->
+   ```
+
+   配置如下（在Device Drivers -> HDF driver framework support 目录下）：
+
+   ![zh-cn_image_0000001208524821](figures/zh-cn_image_0000001208524821.png)
+
+
+### 编译Image
+
+  
+```
+# 执行编译命令
+make ${MAKE_OPTIONS} -j33 zImage
+```
+
+
+### 编译和运行HDF测试用例（可选）
+
+**简介**
+
+HDF（Hardware Driver Foundation)自测试用例，用于测试HDF框架和外设的基本功能，本文主要介绍HDF内核态用例测试方法。
+
+**预置条件**
+
+测试前需要在menuconfig里检查HDF测试开关CONFIG_DRIVERS_HDF_TEST=y，代码全量编译通过。
+
+**用例编译和测试方法**
+
+  通过[hdc_std工具](../subsystems/subsys-toolchain-hdc-guide.md)把用例执行文件推送到设备中，然后执行用例即可，操作步骤如下：
+1. 编译hdf测试用例。
+
+2. 用hdc_std工具推送测试文件到设备中。
+
+3. 进入设备data/test目录，执行测试文件即可。
+
+用例编译和测试详细步骤如下：
+
+1. 编译hdf测试用例。
+   编译hdf测试用例命令和文件路径如下：
+
+     
+   ```
+   ./build.sh --product-name hispark_taurus_standard --build-target hdf_test
+   ```
+
+   等待编译完成。
+
+2. 将测试文件移动到目标移植设备上（以树莓派为例）。
+  
+   方法一：使用[hdc_std工具](../subsystems/subsys-toolchain-hdc-guide.md)。
+
+   1. 先在树莓派里新建data/test目录。
+         
+       ```
+       mkdir -p data/test
+       ```
+   2. 推送依赖库和测试用例到树莓派。
+         
+       ```
+       hdc file send XXX\out\{device_name}\hdf\hdf\libhdf_test_common.z.so  /system/lib
+       hdc file send XXX\out\{device_name}\tests\unittest\hdf\config\hdf_adapter_uhdf_test_config  /data/test
+       hdc file send XXX\out\{device_name}\tests\unittest\hdf\devmgr\DevMgrTest  /data/test
+       hdc file send XXX\out\{device_name}\tests\unittest\hdf\osal\OsalTest  /data/test
+       hdc file send XXX\out\{device_name}\tests\unittest\hdf\sbuf\SbufTest  /data/test
+       ```
+
+   方法二：移动到储存卡内，启动树莓派之后装载。
+
+   1. 拔掉树莓派连接电脑的串口、USB线，然后拔下数据卡。
+   2. 将数据卡插入到电脑的读取口，将编译好的zImage和测试文件夹test/下载到电脑，然后移动到数据卡的根目录下。zImage文件会被替换，请提前做好备份。
+   3. 最后将数据卡插回树莓派。
+         
+       ```
+       # 让树莓派文件系统读取储存卡根目录。
+       mount -t vfat /dev/block/mmcblk0p1 /boot
+       cd /boot/[测试文件目录]
+       # 允许修改系统文件。
+       mount -o remount,rw /
+       # 安装测试用库。
+       mv libhdf_test_common.z.so /system/lib
+       mkdir /data/test
+       mv * /data/test
+       ```
+
+3. 执行测试。
+   1. 进入目录执行测试文件目录data/test。
+         
+       ```
+       cd /data/test
+       ```
+   2. 修改文件执行权限。
+         
+       ```
+       chmod 777 hdf_adapter_uhdf_test_config DevMgrTest OsalTest SbufTest
+       ```
+   3. 开始测试。
+         
+       ```
+       ./hdf_adapter_uhdf_test_config
+       ./DevMgrTest
+       ./OsalTest
+       ./SbufTest
+       ```
+   4. 如果所有测试文件输出均显示 PASSED，那么HDF功能即安装成功。
+         示例：DevMgrTest用例成功结果显示：
+         
+       ```
+       ./DevMgrTest
+       Running main() from gmock_main.cc
+       [==========] Running 1 test from 1 test case.
+       [----------] Global test environment set-up.
+       [----------] 1 test from DevMgrTest
+       [ RUN      ] DevMgrTest.DriverLoaderTest_001
+       [       OK ] DevMgrTest.DriverLoaderTest_001 (0 ms)
+       [----------] 1 test from DevMgrTest (0 ms total)
+       [----------] Global test environment tear-down
+       Gtest xml output finished
+       [==========] 1 test from 1 test case ran. (0 ms total)
+       [  PASSED  ] 1 test.
+       ```

package/node_modules/@ohos-agent/pc-adapter/skills/openharmony-device-porting/references-full/porting/porting-smallchip-kernel-linux.md

@@ -0,0 +1,119 @@
+# Linux内核
+
+
+## 移植概述
+
+Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后，进行基础的内核编译构建及验证。
+
+
+### 基本信息
+
+当前Linux内核基线是基于Linux社区 5.10 LTS版本演进，合入CVE及bugfix补丁。具体信息参考[代码库](https://gitcode.com/openharmony/kernel_linux_5.10)，对应repo工程代码路径为`kernel/linux-5.10`。
+
+
+### Bootloader
+
+可以使用芯片厂商自带的Bootloader，或者是开源Uboot等加载内核镜像。比如为支持Hi3516DV300开发板，OpenHarmony引入的开源[Uboot](https://gitcode.com/openharmony/third_party_u-boot)。
+
+
+## 适配编译和烧录启动
+
+1. 准备内核config（特别是芯片相关的config）。
+
+   config文件所在源码目录：`kernel/linux/config/`
+
+   以hi3516dv300芯片为例，可在对应的`linux-5.10/arch/arm/configs/`目录下新建<YOUR_CHIP>_small_defconfig，如`hi3516dv300_small_defconfig`表示针对hi3516dv300小型系统的defconfig。该config文件可以由基础defconfig文件`small_common_defconfig`与该芯片相关的config组合生成。
+
+2. 准备芯片补丁。
+
+   补丁文件所在源码目录：`kernel/linux/patches/linux-5.10`
+
+   以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）编译失败，内核版本差异（函数实现调整等）需要针对性进行内核适配。
+
+   > ![icon-caution.gif](public_sys-resources/icon-caution.gif) **注意：**
+   >
+   > - 参考`kernel.mk`，在OpenHarmony工程的编译构建流程中会拷贝kernel/linux-5.10的代码环境后进行打补丁动作，在使用版本级编译命令前，需要kernel/linux-5.10保持原代码环境。
+   > 
+   > - 对应拷贝后的目录位于：`out/<***>/kernel/linux-5.10`，可以在该目录下进行补丁的修改适配。
+
+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小型系统的OS镜像结构以及linux用户态的启动流程如下图1所示：
+
+  **图1** 基于linux内核的OS镜像结构和用户态程序启动流程
+
+  ![zh-cn_image_0000001154372318](figures/zh-cn_image_0000001154372318.png)
+
+基于上述流程，推荐按以下步骤完成验证：
+
+1. 制作根文件系统镜像。
+
+   请参考[新建芯片解决方案和产品解决方案](../subsystems/subsys-build-all.md)生成根文件系统镜像`rootfs.img`。从上图可以看到启动过程与产品配置强相关，在制作rootfs.img过程中请完成如下四种配置：
+
+   - 组件配置
+
+     产品组件配置文件`vendor/{company}/{product}/config.json`需配置启动恢复子系统(startup)的init_lite组件和内核子系统的linux_5_1_0组件。
+
+   - 系统服务配置
+
+     系统服务配置文件`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启动正常日志
+
+     ![zh-cn_image_0000001154212516](figures/zh-cn_image_0000001154212516.png)
+
+   正常进入shell后执行ls命令，串口打印信息如下图：
+
+     **图3** 正常进入shell后输入ls命令串口打印
+
+     ![zh-cn_image_0000001200171991](figures/zh-cn_image_0000001200171991.png)
+
+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
+   ```

package/node_modules/@ohos-agent/pc-adapter/skills/openharmony-device-porting/references-full/porting/porting-smallchip-prepare-building.md

@@ -0,0 +1,144 @@
+# 编译构建
+
+## 编译环境搭建
+
+首先请搭建OpenHarmony基础环境，相关操作请参考[快速入门环境搭建章节](../quick-start/quickstart-overview.md)。用户态和LiteOS-A的内核态编译均使用llvm编译器编译，安装方法在搭建基础环境中已提供。若选择移植linux内核，请执行如下命令安装gcc-arm-linux-gnueabi交叉编译工具链，用于编译linux内核态镜像：
+
+
+```
+sudo apt-get install gcc-arm-linux-gnueabi
+```
+
+
+## 编译构建系统介绍
+
+编译构建流程、编译脚本编写、目录规则、独立编译单个组件、独立编译芯片解决方案等介绍请见[编译构建子系统介绍](../subsystems/subsys-build-all.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_taurus          
+           ├── BUILD.gn    
+           ├── hals        
+           ├── ......      
+           └── linux    
+               └── config.gni  
+   ```
+
+   目录树建立后开发板相关的源码放到hispark_taurus目录下。
+
+2. 配置开发板编译选项。
+
+   步骤1中的`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 installed, it's not mandatory if you have added toolchain 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`为入口启动编译。

package/node_modules/@ohos-agent/pc-adapter/skills/openharmony-device-porting/references-full/porting/porting-smallchip-prepare-needs.md

@@ -0,0 +1,23 @@
+# 移植须知
+
+
+本文详细介绍如何将OpenHarmony小型系统的linux和LiteOS-A内核移植到新的开发板上，要求读者具有一定的嵌入式系统开发经验。建议先查看[入门指导](../../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等 |