DD'Notes

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

OpenHarmony之HDIHDI 介绍HDI（Hardware Device Interface，硬件设备接口）是HDF驱动框架为开发者提供的硬件规范化描述性接口。通过规范化的设备接口标准，为系统提供统一、稳定的硬件设备操作接口。 HDI支持“IPC模式”及“直通模式”两种调用方式。 IPC模式即跨进程通信模式，基于binder机制实现，调用端通过Proxy代理库调用HDI接口，具备良好的解耦性和安全性，是标准系统的默认部署方式。 直通模式，将HDI实现为共享库，调用端使用dlopen加载HDI实现库并直接调用HDI接口，是小型系统的默认部署方式，同时还适用于对性能有特殊需求的标准系统模块。 HDI硬件设备接口为硬件的接入提供了统一的实现通路。屏蔽了硬件接口的具体实现，实现系统软件与硬件的架构解耦。让开发者专注于硬件接口的使用，从而简化开发过程，提升开发效率。 HDI 实现下面主要介绍IPC模式下基于C/S（Client-Server客户端与服务端）结构的HDI接口实现，OpenHarmony的IPC也是基于Android的Binder机制。 IPC进程间通信IPC（I ...

OpenHarmony之hdc简介 hdc（OpenHarmony Device Connector）是 OpenHarmony 为开发人员提供的用于调试的命令行工具，通过该工具可以在Windows/Linux/MacOS等系统上与开发机或者模拟器进行交互。 类似于Android的adb，和adb类似，使用hdc的前提是开发机器hdc工具已安装好，设备端hdc已安装且已配置好。 开发机HDC开发机hdc工具通过OpenHarmony sdk获取，hdc在sdk的 toolchains目录下 从官方每日构建版本(http://ci.openharmony.cn/workbench/cicd/dailybuild/dailylist)里下载对应分支的SDK， 这里我对应的是OpenHarmony-3.2-Release的 ohos-sdk-full 解压： zdd@xxx-PC:~/WorkSpace/OHOS/ohos-sdk$ tree . ├── linux │ ├── ets-linux-x64-3.2.15.3-Release.zip │ ├── js-linux-x6 ...

USB Gadget 与 Configfs USB Gadget 与 Configfs USB Gadget Configfs 使用configfs配置usb gadget 配置UAC 配置adb功能 参考 USB Gadget A USB Linux Gadget is a device which has a UDC (USB Device Controller) and canbe connected to a USB Host to extend it with additional functions like a serial A gadget is seen by its host as a set of configurations, each of which containsa number of interfaces which, from the gadget’s perspective, are known asfunctions, each function representing e.g. a serial connection ...