DD'Notes

概述OpenHarmony编译子系统是以GN和Ninja构建为基座，对构建和配置粒度进行部件化抽象、对内建模块进行功能增强、对业务模块进行功能扩展的系统，该系统提供以下基本功能： 以部件为最小粒度拼装产品和独立编译。 支持轻量、小型、标准三种系统的解决方案级版本构建，以及用于支撑应用开发者使用IDE开发的SDK开发套件的构建。 支持芯片解决方案厂商的灵活定制和独立编译。 编译子系统通过配置来实现编译和打包，该子系统主要包括：模块、部件、子系统、产品。 编译子系统的各部分关系，主要体现为： 子系统是某个路径下所有部件的集合，一个部件只能属于一个子系统。 部件是模块的集合，一个模块只能归属于一个部件。 通过产品配置文件配置一个产品包含的部件列表，部件不同的产品配置可以复用。 部件可以在不同的产品中实现有差异，通过变体或者特性feature实现。 模块就是编译子系统的一个编译目标，部件也可以是编译目标。 系统架构编译构建子系统架构 目录结构： build ├── build_scripts # 编译相关的python脚本 ├── ...

OpenHarmony南向之PWM背光概述之前在讲《OpenHarmony南向之LCD显示屏》时，有提到显示屏的背光，但没有展开，今天我们来详细讲讲。 背光驱动模型也是基于HDF框架开发的，整个框架如下： 现在以RK3568为例，来看看PWM背光整个驱动，这里使用的是PWM占空比控制的背光，默认基于hdf的pwm驱动已经OK！ 需要注意的是：这里是基于HDF实现的PWM和PWM背光，所以Linux内核里面原生的PWM和PWM背光相关配置需要关闭 相关代码路径： drivers/hdf_core/framework/model/display/driver/backlight/ vendor/hihope/rk3568/hdf_config/khdf/device_info/device_info.hcs vendor/hihope/rk3568/hdf_config/khdf/lcd/lcd_config.hcs hcsdevice_infodisplay :: host { hostName = "display_host"; ...

OpenHarmony南向之TP触摸屏概述Touchscreen驱动用于驱动触摸屏使其正常工作，该驱动主要完成如下工作：对触摸屏驱动IC进行上电、配置硬件管脚并初始化其状态、注册中断、配置通信接口（I2C或SPI）、设定Input相关配置、下载及更新固件等操作。 Touchscreen驱动基于HDF的Input驱动模型 Input驱动模型 Input驱动模型基于HDF驱动框架、Platform接口、OSAL接口进行开发，向上对接规范化的驱动接口HDI（Hardware Device Interface）层，通过Input-HDI层对外提供硬件能力，即上层Input Service可以通过HDI接口层获取相应的驱动能力，进而操控Touchscreen等输入设备。 Input驱动模型核心部分由设备管理层、公共驱动层、器件驱动层组成。 Input设备管理：为各类输入设备驱动提供Input设备的注册、注销接口，同时对Input设备列表进行统一管理。 Input平台驱动：指各类Input设备的公共抽象驱动（例如触摸屏的公共驱动），该部分主要负责对板级硬件进行初始化、硬件中断处理、向mana ...

OpenHarmony南向之LCD显示屏概述LCD（Liquid Crystal Display）驱动，通过对显示器上下电、初始化显示器驱动IC（Integrated Circuit）内部寄存器等操作，使其可以正常工作。 HDF Display驱动模型 LCD器件驱动是显示框架最底层的部分。向上对接到 Display 公共 HAL 层，辅助 HDI 的实现。通过Display-HDI对图形服务提供各类驱动能力接口；向下对接显示屏 panel 器件，驱动屏幕正常工作，自上而下打通显示全流程通路。所以驱动LCD主要在于LCD panel器件驱动。 LCD接口通常可分为MIPI DSI接口、TTL接口和LVDS接口，这里以rk3568平台为例，是常见的mipi接口的显示屏 驱动主要分为2大部分：hcs配置和panel驱动 vendor/hihope/rk3568/hdf_config/khdf/device_info/device_info.hcs drivers/hdf_core/framework/model/display/driver/panel/ 下面就这2大部分分别来简单分析 ...

OpenHarmony南向之Camera简述Camera驱动框架该驱动框架模型内部分为三层，依次为HDI实现层、框架层和设备适配层： HDI实现层：实现OHOS（OpenHarmony Operation System）相机标准南向接口。 框架层：对接HDI实现层的控制、流的转发，实现数据通路的搭建，管理相机各个硬件设备等功能。 设备适配层：屏蔽底层芯片和OS（Operation System）差异，支持多平台适配。 Camera模块主要包含服务、设备的初始化，数据通路的搭建，流的配置、创建、下发、捕获等。基于HDF驱动框架的Camera驱动模型 目前，Camera驱动框架主要提供了两种适配方式：V4L2和MPP。 MPP方式主要是针对海思系列的芯片，MPP是海思自己实现的多媒体框架，之前有介绍，具体可参见：Linux之摄像头简述 V4L2方式主要是针对Camera驱动是基于V4L2接口实现的芯片平台，比如Rockchip，展锐等 如果其他芯片平台想适配OH的Camera驱动框架，如果是V4L2实现可参考Rockchip的适配方式，如果是私有实现（比如ioctl方式）则需要自己 ...

wsl2上折腾docker背景上次重新整了下电脑上的WSL2: https://notes.z-dd.online/2023/11/07/WSL2%E7%9B%B8%E5%85%B3/ 现在需要在上面弄下docker，以为和在真机上一样，后来发现还有比较大的差异，所以在此记录下 环境： Windows 11 家庭中文版(22H2) WSL2(2.0.9.0) WSL Ubuntu20.04发行版 问题在wsl上安装的Ubuntu20.04里，默认好像已经安装了docker，有docker等命令但是使用docker pull命令拉取镜像报错： docker: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?. See 'docker run --help'. wsl2不支持systemctl命令，所以执行如下命令先启动docker： service docker start 但是报错： docker: unrecognized servic ...

Android之摄像头框架简介Android Camera HAL每个Soc厂家的HAL实现不一样，以前主要基于V4L2，openMAX等，如TI等，后面随着Android相机功能越来越多，运用越来越复杂，都形成了自己独有的一套架构，比如高通Camx架构，MTK的MtkCam3架构等 Camx架构： MtkCam3: 新版HAL3从 Android 8.0 开始，相机 HAL 实现必须使用 HIDL API，不支持使用旧版接口。 新相机 HAL 的 HIDL 接口在 hardware/interfaces/camera 中定义 HIDL 的目标是，可以在无需重新构建 HAL 的情况下替换框架。HAL 将由供应商或 SOC 制造商构建，并放置在设备的 /vendor 分区中，这样一来，就可以在框架自己的分区中通过 OTA 替换框架，而无需重新编译 HAL。从 Android 10 开始，HIDL 已废弃，Android 将在所有位置改用 AIDL 应用框架应用代码位于应用框架级别，它使用 Camera 2 API 与相机硬件进行互动。在内部，此代码会调用相应的 Binder ...

Linux之摄像头简述Linux下与摄像头相关的部分主要分有以下几类： V4L2/Media框架，包括UVC MPP框架 ISP V4L2/Meida框架 V4L2 This driver emulates video4linux hardware of various types: video capture, video output, vbi capture and output, radio receivers and transmitters and a software defined radio receiver. V4L2（Video4Linux）是Linux下关于视频相关设备的驱动框架，为驱动和应用程序提供了一套统一的接口规范 拓扑链路多媒体设备涉及到多个设备之间的数据链接和数据流控制，按照v4l2的标准，它会将一个数据流设备抽象成一个videoX节点，从属主设备都对应着各自的v4l2_subdev实现，并且按照media controller进行统一管理。 media将这些媒体设备形成的数据通路上的各个设备建立拓扑关系，便于实现各个设备之间的链接控制和数据 ...

OpenHarmony之分布式软总线背景概述从之前的文档(OpenHarmony之内核层)可知， 分布式软总线是多设备终端的统一基座，为设备间的无缝互联提供了统一的分布式通信能力，能够快速发现并连接设备，高效地传输任务和数据。 分布式软总线实现近场设备间统一的分布式通信管理能力，提供不区分链路的设备间发现连接、组网和传输能力，主要功能如下： 发现连接：提供基于Wifi、蓝牙等通信方式的设备发现连接能力。 设备组网：提供统一的设备组网和拓扑管理能力，为数据传输提供已组网设备信息。 数据传输：提供数据传输通道，支持消息、字节、流、文件的数据传输能力。 分布式软总线是OpenHarmony重要特性、重要组件之一，是其他分布式子系统的基础，包括分布式数据管理，分布式任务调度，分布式硬件子系统等 架构目录结构：分布式软总线框架主要位于 foundation/communication/dsoftbus目录下，其目录结构如下： //foundation/communication/dsoftbus ├── adapter # 适配层 │ ├── commo ...

WSL2相关背景WSL: Windows Subsystem for Linux（简称WSL）是一个在Windows 10\11上能够运行原生Linux二进制可执行文件（ELF格式）的兼容层 在逛OpenHarmony开发者论坛的时候，看到使用WSL2编译OpenHarmony，突起想起自己之前在自己的Windows的电脑上也捣鼓了一下WSL2，装了个Ubuntu20.04，然后一直就扔在那没用，今天正好再继续弄弄 安装WSL配置 WSL 环境使用 win+s 搜索 启用或关闭windows功能，并打开： 适用于Linux的Windows子系统 虚拟机平台 下载 Linux 内核更新包：适用于 x64 计算机的 WSL2 Linux 内核更新包 运行并安装 将 WSL 2 设置为默认版本wsl --set-default-version 2 安装Linux分发版Microsoft Store搜索Ubuntu对应版本，这里选的是20.04，安装默认情况下会安装到C盘。 配置Linux为新的 Linux 分发版创建用户帐户 切换源 sudo vim /etc/apt/sources ...

OpenHarmony之系统调用背景对于运行L0系统的硬件一般是mcu，资源有限，L0系统没有区分内核态和用户态，所有的代码都在内核态运行，所以不需要系统调用L2系统用的是Linux内核，所以系统调用跟Linux Kernel的是一样的。可以参见我之前的博文Linux之系统调用 所以我们主要来看看L1系统中系统调用机制的是怎么实现的。 后面的分析基于如下版本： OpenHarmony v3.3.2 musl v1.2.0 L1系统调用对于运行L1系统的硬件一般集成了MMU，而且CPU有特权级别状态（状态寄存器的某些位），可以实现进程之间的隔离、内核态和用户态的隔离。系统调用就是在有内核态和用户态隔离的操作系统上，用户态进程访问内核态资源的一种方式 用户态c库通常我们的应用不会直接调用系统调用，而是通过c库的库函数来间接调用。 OpenHarmony上层使用的C库是musl libc， c库的一些函数接口调到最下面就是系统调用接口了。 通过third_party/musl/src/internal/syscall.h文件中，各种宏的展开，最终都会变成类似与__syscall3等这样的 ...

OpenHarmony南向之Audio音频架构Audio驱动框架基于HDF驱动框架实现，包含内核态（KHDF），和用户态（UHDF）， 对北向提供音频HDI接口 音频框架图 驱动架构主要由以下几部分组成。 HDI adapter：实现Audio HAL层驱动（HDI接口适配），给Audio服务（frameworks）提供所需的音频硬件驱动能力接口。包含 Audio Manager、Audio Adapter、Audio Control、Audio Capture、Audio Render等接口对象。 Audio Interface Lib：向下配合内核中的Audio Driver Model使用，实现音频硬件的控制、录音数据的读取、播放数据的写入，向上和上层的Audio HDI Adapter层进行对接。 ADM（Audio Driver Model）：音频驱动框架模型，向上服务于多媒体音频子系统，向下统一接口适配各自的驱动代码。 主要代码目录 drivers/hdf_core/framework/model/audio及 device/board/xxx/yyy/audio_dr ...