OpenHarmony设备开发 小型系统芯片移植指导

标准系统移植指南

本文描述了移植一块开发板的通用步骤，和具体芯片相关的详细移植过程无法在此一一列举。后续社区还会陆续发布开发板移植的实例供开发者参考。

定义开发板

本文以移植名为MyProduct的开发板为例讲解移植过程，假定MyProduct是MyProductVendor公司的开发板，使用MySoCVendor公司生产的MySOC芯片作为处理器。

定义产品

在“//vendor/MyProductVendor/{product_name}名称的目录下创建一个config.json文件，该文件用于描述产品所使用的SOC 以及所需的子系统。配置如下：

//vendor/MyProductVendor/MyProduct/config.json

{
    "product_name": "MyProduct",
    "version": "3.0",
    "type": "standard",
    "target_cpu": "arm",
    "ohos_version": "OpenHarmony 1.0",
    "device_company": "MyProductVendor",
    "board": "MySOC",
    "enable_ramdisk": true,
    "subsystems": [
      {
        "subsystem": "ace",
        "components": [
          { "component": "ace_engine_lite", "features":[] }
        ]
      },
	...
    ]
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

主要的配置内容

product_name：产品名称 必填

version：版本 必填

type：配置的系统级别，包含（small，standard …) 必填

target_cpu ：设备的CPU类型（根据实际情况，这里的target_cpu也可能是arm64 、riscv、 x86等。） 必填

ohos_version：操作系统版本 选填

device_company：device厂商名 必填

board：开发板名称 必填

enable_ramdisk：是否启动ramdisk 必填

kernel_type 选填

kernel_version 选填 kernel_type与 kernel_version在 standard 是固定的不需要写。

subsystems:系统需要启用的子系统。子系统可以简单理解为一块独立构建的功能块。必填

product_company：不体现在配置中，而是目录名，vendor下一级目录就是product_company，BUILD.gn脚本依然可以访问。

已定义的子系统可以在“//build/subsystem_config.json”中找到。当然你也可以定制子系统。

这里建议先拷贝Hi3516DV300 开发板的配置文件，删除掉 hisilicon_products 这个子系统。这个子系统为Hi3516DV300 SOC编译内核，显然不适合MySOC。

移植验证

至此，你可以使用如下命令，启动你产品的构建了：

./build.sh --product-name MyProduct 
1.

构建完成后，可以在“//out/{device_name}/packages/phone/images”目录下看到构建出来的OpenHarmony镜像文件。

内核移植

这一步需要移植Linux内核，让Linux内核可以成功运行起来。

为SOC添加内核构建的子系统

修改文件 //build/subsystem_config.json增加一个子系统. 配置如下：

接着需要修改定义产品的配置文件//vendor/MyProductVendor/MyProduct/config.json，将刚刚定义的子系统加入到产品中。

编译内核

源码中提供了Linux 4.19的内核，归档在//kernel/linux-4.19。本节以该内核版本为例，讲解如何编译内核。

在子系统的定义中，描述了子系统构建的路径path，即​​//device/MySOCVendor/MySOC/build​​。这一节会在这个目录创建构建脚本，告诉构建系统如何构建内核。

建议的目录结构

├── build
│ ├── kernel
│ │     ├── linux
│ │           ├──standard_patch_for_4_19.patch // 基于4.19版本内核的补丁
│ ├── BUILD.gn
│ ├── ohos.build
1.
2.
3.
4.
5.
6.

BUILD.gn是subsystem构建的唯一入口。

期望的构建结果

移植验证

启动编译，验证预期的kernel镜像是否成功生成。

用户态启动引导

1. 用户态进程启动引导总览。

系统上电加载内核后，按照以下流程完成系统各个服务和应用的启动：

1. 内核启动init进程，一般在bootloader启动内核时通过设置内核的cmdline来指定init的位置；如上图所示的"init=/init root/dev/xxx"。
2. init进程启动后，会挂载tmpfs，procfs，创建基本的dev设备节点，提供最基本的根文件系统。
3. init继续启动ueventd监听内核热插拔事件，为这些设备创建dev设备节点；包括block设备各个分区设备都是通过此事件创建。
4. init进程挂载block设备各个分区（system，vendor），开始扫描各个系统服务的init启动脚本，并拉起各个SA服务。
5. samgr是各个SA的服务注册中心，每个SA启动时，都需要向samgr注册，每个SA会分配一个ID，应用可以通过该ID访问SA。
6. foundation是一个特殊的SA服务进程，提供了用户程序管理框架及基础服务；由该进程负责应用的生命周期管理。
7. 由于应用都需要加载JS的运行环境，涉及大量准备工作，因此appspawn作为应用的孵化器，在接收到foundation里的应用启动请求时，可以直接孵化出应用进程，减少应用启动时间。

2.init。
init启动引导组件配置文件包含了所有需要由init进程启动的系统关键服务的服务名、可执行文件路径、权限和其他信息。每个系统服务各自安装其启动脚本到/system/etc/init目录下。
新芯片平台移植时，平台相关的初始化配置需要增加平台相关的初始化配置文件/vendor/etc/init/init.{hardware}.cfg；该文件完成平台相关的初始化设置，如安装ko驱动，设置平台相关的/proc节点信息。
init相关进程代码在//base/startup/init_lite目录下，该进程是系统第一个进程，无其它依赖。
初始化配置文件具体的开发指导请参考​​​init启动子系统概述​​。

HDF驱动移植

LCD

HDF为LCD设计了驱动模型。支持一块新的LCD，需要编写一个驱动，在驱动中生成模型的实例，并完成注册。

这些LCD的驱动被放置在//drivers/framework/model/display/driver/panel目录中。

• 创建Panel驱动

在驱动的Init方法中，需要调用RegisterPanel接口注册模型实例。如:

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);
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

• 配置加载panel驱动产品的所有设备信息被定义在文件//vendor/MyProductVendor/MyProduct/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";
            }
        }
    }
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.

更详细的驱动开发指导，请参考 ​​LCD​​。

触摸屏

本节描述如何移植触摸屏驱动。触摸屏的驱动被放置在//drivers/framework/model/input/driver/touchscreen目录中。移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。

• 创建触摸屏器件驱动

在目录中创建名为touch_ic_name.c的文件。代码模板如下：注意：请替换ic_name为你所适配芯片的名称。

#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);
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.

其中ChipDevice中要提供若干方法。

• 配置产品，加载器件驱动 产品的所有设备信息被定义在文件//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs中。修改该文件，在名为input的host中，名为device_touch_chip的device中增加配置。注意：moduleName 要与触摸屏驱动中的moduleName相同。

更详细的驱动开发指导，请参考 ​​TOUCHSCREEN​​。

WLAN

Wi-Fi驱动分为两部分，一部分负责管理WLAN设备，另一个部分负责处理WLAN流量。HDF WLAN分别为这两部分做了抽象。目前支持SDIO接口的WLAN芯片。

图1 WLAN芯片

支持一款芯片的主要工作是实现一个ChipDriver驱动。实现HDF_WLAN_CORE和NetDevice提供的接口。主要需要实现的接口有:

建议适配按如下步骤操作：

1.创建HDF驱动建议将代码放置在//device/MySoCVendor/peripheral/wifi/chip_name/，文件模板如下：

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);
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.

在CreateChipDriverFactory中，需要创建一个HdfChipDriverFactory，接口如下：

HdfChipDriver需要实现的接口有

2.编写配置文件，描述驱动支持的设备

在产品配置目录下创建芯片的配置文件//vendor/MyProductVendor/MyProduct/config/wifi/wlan_chip_chip_name.hcs。

注意： 路径中的vendor_name、product_name、chip_name请替换成实际名称。

模板如下：

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];
                }
            }
        }
    }
}
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

3.编写配置文件，加载驱动

产品的所有设备信息被定义在文件//vendor/MyProductVendor/MyProduct/config/device_info/device_info.hcs中。修改该文件，在名为network的host中，名为device_wlan_chips的device中增加配置。注意：moduleName 要与触摸屏驱动中的moduleName相同。

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
1.
2.
3.
4.
5.
6.

接着修改文件//drivers/adapter/khdf/linux/model/network/wifi/Kconfig,在文件末尾加入如下代码将配置菜单加入内核中，如：

source "../../../../../device/MySoCVendor/peripheral/Kconfig"
1.

• 创建构建脚本 在//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/
1.
2.

当在内核中开启DRIVERS_WLAN_XXX开关时，会调用//device/MySoCVendor/peripheral/build/standard/中的makefile。更多详细的开发手册，请参考​​WLAN开发​​。

开发移植示例

开发移植示例请参考​​DAYU开发板​​。

一种快速移植OpenHarmony Linux内核的方法

移植概述

本文面向希望将OpenHarmony移植到三方芯片平台硬件的开发者，介绍一种借助三方芯片平台自带Linux内核的现有能力，快速移植OpenHarmony到三方芯片平台的方法。

移植到三方芯片平台的整体思路

内核态层和用户态层

为了更好的解释整个内核移植，首先需要介绍一些概念：

我们可以把OpenHarmony简单的分为

OpenHarmony = OpenHarmony内核态层 + OpenHarmony用户态层

其中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）

而将前两项组合，标准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
1.
2.
3.

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
1.
2.
3.
4.
5.
6.
7.

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
1.

移植内核态基础代码

目前OpenHarmony内核态的基础代码，主要是日志服务相关。轻量化内核日志服务代码包含：

drivers/staging/hilog
drivers/staging/hievent
1.
2.

将以上代码，从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"
1.
2.

在三方内核的drivers/staging/Makefile文件内增加如下代码：

obj-$(CONFIG_HILOG)             += hilog/
obj-$(CONFIG_HIEVENT)           += hievent/
1.
2.

在内核config项中打开对应的CONFIG控制宏：CONFIG_HILOG和CONFIG_HIEVENT。

具体日志使用说明请参见：​​Hilog_lite组件介绍​​。

移植内核态必选特性HDF

1. 打HDF补丁。 在Linux内核打HDF补丁时，执行补丁shell脚本合入HDF补丁。

1.配置HDF补丁脚本的四个变量参数。

2.获取patch_hdf.sh脚本。

3.执行patch_hdf.sh脚本依次传入四个变量参数。

patch_hdf.sh脚本四个参数含义为：第一个入参为工程根目录路径，第二入参为内核目录路径，第三个入参为内核版本路径，第四个参数是当前设备名。

./patch_hdf.sh [工程根目录路径] [内核目录路径] [内核补丁路径] [设备名]
1.

以树莓派3b为示例介绍：

# 进入树莓派kernel目录
PROJ_ROOT/drivers/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 # 设备名.
1.
2.
3.
4.
5.
6.

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
1.
2.
3.
4.
5.
6.
7.
8.

或者通过menuconfig界面打开HDF相关配置，命令如下：

# 生成 .config 配置文件
make ${MAKE_OPTIONS} rpi3b_oh_defconfig

# 更改HDF内核配置
make ${MAKE_OPTIONS} menuconfig
# [*] Device Drivers
# [*]   HDF driver framework support --->
1.
2.
3.
4.
5.
6.
7.

配置如下（在Device Drivers -> HDF driver framework support 目录下）：

编译Image

# 执行编译命令
make ${MAKE_OPTIONS} -j33 zImage
1.
2.

编译和运行HDF测试用例（可选）

简介

HDF（Hardware Driver Foundation)自测试用例，用于测试HDF框架和外设的基本功能，本文主要介绍HDF内核态用例测试方法。

预置条件

测试前需要在menuconfig里检查HDF测试开关CONFIG_DRIVERS_HDF_TEST=y，代码全量编译通过。

用例编译和测试方法

通过​​hdc_std工具​​把用例执行文件推送到设备中，然后执行用例即可，操作步骤如下：

1. 编译hdf测试用例。
2. 用hdc_std工具推送测试文件到设备中。
3. 进入设备data/test目录，执行测试文件即可。

用例编译和测试详细步骤如下：

1. 编译hdf测试用例。 编译hdf测试用例命令和文件路径如下：

./build.sh --product-name hispark_taurus_standard --build-target hdf_test
1.

等待编译完成。

2.将测试文件移动到目标移植设备上（以树莓派为例）。
方法一：使用​​​hdc_std工具​​。

1. 先在树莓派里新建data/test目录。

mkdir -p data/test
1.

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.
2.
3.
4.
5.

方法二：移动到储存卡内，启动树莓派之后装载。

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
1.
2.
3.
4.
5.
6.
7.
8.
9.

3.执行测试

1.进入目录执行测试文件目录data/test。

cd /data/test
1.

2.修改文件执行权限。

chmod 777 hdf_adapter_uhdf_test_config DevMgrTest OsalTest SbufTest
1.

3.开始测试。

./hdf_adapter_uhdf_test_config
./DevMgrTest
./OsalTest
./SbufTest
1.
2.
3.
4.

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.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

文章转载自：​​https://docs.openharmony.cn/pages/v3.2Beta/zh-cn/device-dev/porting/standard-system-porting-guide.md/​​