Skip to content

D
Docs

OpenHarmony / Docs
1 年多 前同步成功

通知 159
Star 292
Fork 28
D
Docs
未验证 提交 9da41759 编写于 作者: O openharmony_ci 提交者： Gitee
浏览文件
操作

!22232 同步master，修改显示格式问题 

Merge pull request !22232 from liyan/OpenHarmony-3.2-Release
上级 89fde4df deb6d2ea
展开全部 隐藏空白更改
内联 并排
Showing with 296 addition and 268 deletion
zh-cn/device-dev/porting/porting-smallchip-driver-oom.md
浏览文件 @ 9da41759
......@@ -8,9 +8,10 @@
移植LCD驱动的主要工作是编写一个驱动，在驱动中生成模型的实例，并完成注册。
这些LCD的驱动被放置在源码目录//drivers/hdf_core/framework/model/display/driver/panel中。
这些LCD的驱动被放置在源码目录`//drivers/hdf_core/framework/model/display/driver/panel`中。
1. 创建Panel驱动
创建HDF驱动，在驱动初始化中调用RegisterPanel接口注册模型实例。如:
......@@ -36,7 +37,8 @@
```
2. 配置加载panel驱动
产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。修改该文件，在display的host中，名为device_lcd的device中增加配置。
产品的所有设备信息被定义在源码文件`//vendor/vendor_name/product_name/config/device_info/device_info.hcs`中。修改该文件，在display的host中，名为device_lcd的device中增加配置。
> ![icon-caution.gif](public_sys-resources/icon-caution.gif) **注意：**
> moduleName 要与panel驱动中的moduleName相同。
......@@ -61,12 +63,13 @@
## TP驱动移植
本节描述如何移植触摸屏驱动。触摸屏的器件驱动被放置在源码目录//drivers/hdf_core/framework/model/input/driver/touchscreen中。 移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。
本节描述如何移植触摸屏驱动。触摸屏的器件驱动被放置在源码目录`//drivers/hdf_core/framework/model/input/driver/touchscreen`中。 移植触摸屏驱动主要工作是向系统注册ChipDevice模型实例。
详细的驱动开发指导，请参考 [TOUCHSCREEN开发指导](../driver/driver-peripherals-touch-des.md)。
详细的驱动开发指导，请参考[TOUCHSCREEN开发指导](../driver/driver-peripherals-touch-des.md)。
1. 创建触摸屏器件驱动
在上述touchscreen目录中创建名为touch_ic_name.c的文件。编写如下内容
在上述touchscreen目录中创建名为`touch_ic_name.c`的文件。编写如下内容：
```
......@@ -103,21 +106,22 @@
| int32_t (\*UpdateFirmware)(ChipDevice \*device) | 实现固件升级 |
2. 配置产品，加载器件驱动
产品的所有设备信息被定义在源码文件//vendor/vendor_name/product_name/config/device_info/device_info.hcs中。修改该文件，在名为input的host中，名为device_touch_chip的device中增加配置。
产品的所有设备信息被定义在源码文件`//vendor/vendor_name/product_name/config/device_info/device_info.hcs`中。修改该文件，在名为input的host中，名为device_touch_chip的device中增加配置。
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
> moduleName 要与触摸屏驱动中的moduleName相同。
```
deviceN :: deviceNode {
policy = 0;
priority = 130;
preload = 0;
permission = 0660;
moduleName = "HDF_TOUCH_XXXX";
deviceMatchAttr = "touch_XXXX_configs";
}
deviceN :: deviceNode {
policy = 0;
priority = 130;
preload = 0;
permission = 0660;
moduleName = "HDF_TOUCH_XXXX";
deviceMatchAttr = "touch_XXXX_configs";
}
```
......@@ -126,6 +130,7 @@
WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负责处理WLAN流量。
**图1** OpenHarmony WLAN结构示意图
![zh-cn_image_0000001207756867](figures/zh-cn_image_0000001207756867.png)
如图1，左半部分负责管理WLAN设备，右半部分负责WLAN流量。HDF WLAN分别为这两部分做了抽象，驱动的移植过程可以看做分别实现这两部分所需接口。这些接口有：
......@@ -141,8 +146,9 @@ WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负
具体的移植步骤如下：
1. 创建HDF WLAN 芯片驱动
在目录/device/vendor_name/peripheral/wifi/chip_name/ 创建文件 hdf_wlan_chip_name.c。内容模板如下：
1. 创建HDF WLAN芯片驱动
在目录`/device/vendor_name/peripheral/wifi/chip_name/`创建文件`hdf_wlan_chip_name.c`。内容模板如下：
```
......@@ -166,7 +172,7 @@ WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负
HDF_INIT(g_hdfXXXChipEntry);
```
在上述代码的CreateChipDriverFactory方法中，需要创建一个HdfChipDriverFactory类型的对象。该对象提供如下方法
在上述代码的CreateChipDriverFactory方法中，需要创建一个HdfChipDriverFactory类型的对象。该对象提供如下方法：
| 接口 | 说明 |
| -------- | -------- |
......@@ -178,7 +184,7 @@ WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负
| void (\*Release)(struct HdfChipDriver \*chipDriver) | 释放chipDriver |
| uint8_t (\*GetMaxIFCount)(struct HdfChipDriverFactory \*factory) | 获取当前芯片支持的最大接口数 |
其中Build方法负责创建一个管理指定网络接口的对象HdfChipDriver 。该对象需要提供方法:
其中Build方法负责创建一个管理指定网络接口的对象HdfChipDriver。该对象需要提供方法:
| 接口 | 说明 |
| -------- | -------- |
......@@ -189,7 +195,9 @@ WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负
| struct HdfMac80211APOps \*apOps | 支持AP模式所需要的接口集 |
2. 编写配置文件描述驱动支持的芯片
在产品配置目录下创建芯片的配置文件，保存至源码路径//vendor/vendor_name/product_name/config/wifi/wlan_chip_chip_name.hcs
在产品配置目录下创建芯片的配置文件，保存至源码路径`//vendor/vendor_name/product_name/config/wifi/wlan_chip_chip_name.hcs`。
该文件模板如下：
......@@ -212,29 +220,32 @@ WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
> 路径和文件中的vendor_name、product_name、chip_name请替换成实际名称
>
> 路径和文件中的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中增加配置。模板如下：
产品的所有设备信息被定义在源码文件`//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";
}
deviceN :: deviceNode {
policy = 0;
preload = 2;
moduleName = "HDF_WLAN_CHIPS";
deviceMatchAttr = "hdf_wlan_chips_chip_name";
serviceName = "driverName";
}
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
> moduleName 要与HDF WLAN 芯片驱动中的moduleName相同。
> moduleName要与HDF WLAN芯片驱动中的moduleName相同。
4. 修改Kconfig文件，让移植的WLAN模组出现再内核配置中
在device/vendor_name/drivers/Kconfig中增加配置菜单，模板如下
在`device/vendor_name/drivers/Kconfig`中增加配置菜单，模板如下：
```
......@@ -246,10 +257,11 @@ WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
> 请替换模板中的chip_name为实际的芯片名称
> 请替换模板中的chip_name为实际的芯片名称。
5. 修改构建脚本，让驱动参与内核构建
在源码文件//device/vendor_name/drivers/lite.mk末尾追加如下内容
在源码文件`//device/vendor_name/drivers/lite.mk`末尾追加如下内容：
```
......@@ -262,4 +274,4 @@ WLAN驱动分为两部分，一部分负责管理WLAN设备，另一个部分负
```
> ![icon-note.gif](public_sys-resources/icon-note.gif) **说明：**
> 请替换模板中的chip_name为实际的芯片名称
> 请替换模板中的chip_name为实际的芯片名称。
zh-cn/device-dev/porting/porting-smallchip-kernel-linux.md
浏览文件 @ 9da41759
......@@ -8,7 +8,7 @@ Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后
### 基本信息
当前Linux内核基线是基于Linux社区 4.19 LTS版本演进，合入CVE及bugfix补丁。具体信息参考[代码库](https://gitee.com/openharmony/kernel_linux)，对应repo工程代码路径为kernel/linux-4.19。
当前Linux内核基线是基于Linux社区 4.19 LTS版本演进，合入CVE及bugfix补丁。具体信息参考[代码库](https://gitee.com/openharmony/kernel_linux)，对应repo工程代码路径为`kernel/linux-4.19`。
### Bootloader
......@@ -19,17 +19,20 @@ Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后
## 适配编译和烧录启动
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组合生成。
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等驱动补丁。
补丁文件所在源码目录：`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格式等的适配。
具体内核编译入口脚本位于工程目录`kernel/linux/patches/`下面，版本级整编命令会通过`BUILD.gn`进入`kernel_module_build.sh`和`kernel.mk`，需要在这2个文件中针对性进行patch及defconfig文件路径、编译器、芯片架构、内核Image格式等的适配。
通过编译错误日志调整补丁，典型错误场景：
......@@ -38,11 +41,12 @@ Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后
（2）编译失败，内核版本差异（函数实现调整等）需要针对性进行内核适配。
> ![icon-caution.gif](public_sys-resources/icon-caution.gif) **注意：**
> - 参考kernel.mk，在OpenHarmony工程的编译构建流程中会拷贝kernel/linux-4.19的代码环境后进行打补丁动作，在使用版本级编译命令前，需要kernel/linux-4.19保持原代码环境。
> - 参考`kernel.mk`，在OpenHarmony工程的编译构建流程中会拷贝`kernel/linux-4.19`的代码环境后进行打补丁动作，在使用版本级编译命令前，需要`kernel/linux-4.19`保持原代码环境。
>
> - 对应拷贝后的目录位于: out/<\*\*\*>/kernel/linux-4.19，可以在该目录下进行补丁的修改适配。
> - 对应拷贝后的目录位于: `out/<***>/kernel/linux-4.19`，可以在该目录下进行补丁的修改适配。
4. 烧录启动。
由于不同芯片的开发板的烧录方式不一样，此处不表述具体的烧录方式。需要注意烧录的各镜像的大小及启动参数的配置，参考hi3516dv300采用uboot启动参数：
......@@ -56,42 +60,55 @@ Linux内核移植主要涉及基于linux内核基线合入三方芯片补丁后
调试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_4_1_9组件。
产品组件配置文件`vendor/{company}/{product}/config.json`需配置启动恢复子系统(startup)的init_lite组件和内核子系统的linux_4_1_9组件。
- 系统服务配置
系统服务配置文件vendor/{company}/{product}/init_configs/init_xxx.cfg需要启动shell服务。
系统服务配置文件`vendor/{company}/{product}/init_configs/init_xxx.cfg`需要启动shell服务。
- 文件系统配置
文件系统配置vendor/{company}/{product}/fs.yml中需要创建“/bin/sh -&gt; mksh“和“/lib/ld-musl-arm.so.1 -&gt; libc.so“软连接，这两个文件分别是shell可执行程序和可执行程序依赖的c库。
文件系统配置`vendor/{company}/{product}/fs.yml`中需要创建“/bin/sh -&gt; mksh“和“/lib/ld-musl-arm.so.1 -&gt; libc.so“软连接，这两个文件分别是shell可执行程序和可执行程序依赖的c库。
- 启动配置
启动配置在vendor/{company}/{product}/init_configs/etc目录下，包括fstab、rsS和Sxxx文件，请按开发板实际情况配置。
编译完成后，可通过检查产品编译输出目录下的rootfs内容，确认rootfs.img文件生成是否符合预期。
启动配置在`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脚本完成设备节点创建和扫描、文件权限配置等操作。
烧录`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:
```
......
zh-cn/device-dev/porting/porting-smallchip-prepare-building.md
浏览文件 @ 9da41759
......@@ -20,7 +20,8 @@ sudo apt-get install gcc-arm-linux-gnueabi
了解编译框架和搭建完编译环境后，请参考如下步骤新建芯片解决方案：
1. 新建目录
芯片解决方案的目录规则为：device/{芯片解决方案厂商}/{开发板}。以海思的hispark_taurus开发板为例，在代码根目录执行如下命令建立目录：
芯片解决方案的目录规则为：`device/{芯片解决方案厂商}/{开发板}`。以海思的hispark_taurus开发板为例，在代码根目录执行如下命令建立目录：
```
......@@ -59,7 +60,8 @@ sudo apt-get install gcc-arm-linux-gnueabi
目录树建立后开发板相关的源码放到hispark_taurus目录下。
2. 配置开发板编译选项
步骤1中的config.gni可配置开发板相关的编译选项，编译构建框架将会遵照该配置文件中的参数编译所有用户态OS组件。其中关键的字段说明如下：
步骤1中的`config.gni`可配置开发板相关的编译选项，编译构建框架将会遵照该配置文件中的参数编译所有用户态OS组件。其中关键的字段说明如下：
```
......@@ -75,7 +77,7 @@ sudo apt-get install gcc-arm-linux-gnueabi
board_ld_flags： 开发板配置的链接选项。
```
还以海思的hispark_taurus开发板为例，对应的device/hisilicon/hispark_taurus/config.gni内容如下：
还以海思的hispark_taurus开发板为例，对应的`device/hisilicon/hispark_taurus/config.gni`内容如下：
```
# Board CPU type, e.g. "cortex-a7", "riscv32".
......@@ -121,9 +123,10 @@ sudo apt-get install gcc-arm-linux-gnueabi
```
3. 编写开发板编译脚本
步骤1中的BUILD.gn为新增的开发板的编译入口，主要用于编译开发板相关的代码，主要为设备侧驱动、设备侧接口适配(媒体，图形等)和开发板的SDK等等。
海思的hispark_taurus开发板的device/hisilicon/hispark_taurus/BUILD.gn可写成：
步骤1中的`BUILD.gn`为新增的开发板的编译入口，主要用于编译开发板相关的代码，主要为设备侧驱动、设备侧接口适配（媒体，图形等）和开发板的SDK等等。
海思的hispark_taurus开发板的`device/hisilicon/hispark_taurus/BUILD.gn`可写成：
```
......@@ -137,4 +140,5 @@ sudo apt-get install gcc-arm-linux-gnueabi
```
4. 编译调试
在开发板目录下执行hb set和hb build即可启动芯片解决方案的编译，编译框架会以开发板下的BUILD.gn为入口启动编译。
在开发板目录下执行`hb set`和`hb build`即可启动芯片解决方案的编译，编译框架会以开发板下的`BUILD.gn`为入口启动编译。
Markdown is supported
0% 或 .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑！
想要评论请 注册 或