DD'Notes

基于QEMU的内核调试环境搭建背景在没有相应的实体硬件，只有自己的一台开发机器，在学习内核或是调试破坏性大的内核功能时，又不想用庞大麻烦的Virtualbox或VMware，只是简单单纯地调试下内核，QEMU是个不错的选择。 关于QEMU QEMU is a generic and open source machine emulator and virtualizer. When used as a machine emulator, QEMU can run OSes and programs made for one machine (e.g. an ARM board) on a different machine (e.g. your own PC). By using dynamic translation, it achieves very good performance. When used as a virtualizer, QEMU achieves near native performance by executing the guest code direc ...

解决WSL2网络和存储问题背景之前在电脑上折腾了WSL2(https://notes.z-dd.online/2023/11/07/WSL2%E7%9B%B8%E5%85%B3/)，还存在2个不严重但很重要的问题： 网络配置问题，主要是不能从外部局域网访问wsl网络，这使得用板子没法挂载wsl里的nfs和使用tftp，网上有些间接的办法解决了这个问题，但很麻烦，懒得去折腾 内存占用和硬盘存储不能自动回收，就像VirtualBox和VMWare的虚拟硬盘文件一样，会不断扩大，只能手动回收。 新的 23H2 系统版本已经直接解决了上面的问题，但我的系统一直未收到相应的正式版的更新推送。也懒得去折腾预览版，所以就一直将就地在用，最近刚好收到了更新，于是就弄了弄。 步骤 更新系统版本到 23H2，这是最重要的步骤和前提 更新wsl版本 wsl --update --pre-release 修改配置在 %userprofile%.wslconfig 中写入以下内容然后保存： [experimental] # 可以在 gradual 、dropcache 、disabled 之间选择 au ...

MMC和SD与SDIO以前一直不太清楚SDIO、SD卡、MMC等之间的区别和联系，偶然间在 蜗窝 上看到下面这幅图，才算稍微有点清晰明了： MMCMMC(Multimedia Card)是一种协议或者规范，规范了卡的形状尺寸，通讯协议等内容，符合MMC协议的卡叫做MMC卡，即多媒体卡 两种操作模式，分别为MMC模式与SPI模式 eMMCeMMC (Embedded Multi Media Card) 为MMC协会所订立的、主要是针对手机或平板电脑等产品的内嵌式存储器标准规格eMMC = NAND flash + 控制器 + 标准封装接口eMMC是一种支持MMC协议的芯片 SDSD (Secure Digital Memory Card)它在MMC的基础上发展而来，增加了两个主要特色：SD卡强调数据的安全，可以设定所储存的使用权限，防止数据被他人复制；另外一个特色就是传输速度比2.11版的MMC卡快，microSD/TF、SDHC、SDXC等这些都是SD卡的进化版 两个可选的通信协议：SD模式和SPI模式 SDIOSDIO（Secure Digital I/O）：安全数字输入输出，就是 ...

【端侧AI系列】入坑篇–瑞芯微RV1126及RKNNRV1126一直想业余学习学习端侧AI，刚好前段时间从朋友那弄了一套RV1126的硬件。开始这一切的前提条件是软硬件都已调通OK，可以正常使用的板子，这里主要涉及RKNN及其应用，不涉及硬件驱动调试及系统调试 RV1126简介RV1126基于四核arm Cortex A7 32位内核，集成NEON和FPU。每个核心都有一个32KB I-cache和32KB D-cache以及 512KB 的共用 二级缓存。内置2.0Tops神经网络处理器NPU支持 INT8/INT16 混合操作，算力强大，实现AI运算的功耗不及所需GPU的10%。配套AI算法工具完善，支持Tensorflow、Pytorch、Caffe、MxNet、DarkNet、ONNX等主流AI框架直接转换和部署 rknpu驱动顾名思义，即NPU的驱动，它包含了NPU驱动、API接口及示例等。 Rockchip的NPU有几套，适用于RK1808/RK1806系列和RV1109/RV1126系列的是：https://github.com/rockchip-linux/rknpu ...

概述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将这些媒体设备形成的数据通路上的各个设备建立拓扑关系，便于实现各个设备之间的链接控制和数据 ...