DD'Notes

基于QEMU搭建RISC-V的Linux环境背景和之前搭建x86的类似(基于QEMU的内核调试环境搭建)，只是需要交叉编译即可，重点其实是在交叉编译工具链。 前提：QEMU已安装好！ 准备工具链RISC-V支持GNU工具链和LLVM工具链，目前主流Linux发行版好像都没有预编译的二进制包可以下载安装，只能自己通过源码编译安装。 获取工具链源码$ git clone https://gitee.com/mirrors/riscv-gnu-toolchain $ cd riscv-gnu-toolchain 注意上面 clone 的主仓库并不包含子仓库的内容，所以需要继续更新子仓库。注意这里首先排除了 qemu 这个子仓库，一来因为 qemu 完整下载太大；二来 qemu 对 toolchain 的编译本身来说其实并不需要。 $ git rm qemu $ git submodule update --init --recursive 上面的过程可能要点时间，需要耐心等待。。。 编译安装工具链riscv-gnu-toolchain工具链分 elf-gcc、linux-gnu-gcc ...

让Windows成为更好用的Linux发行版之WSL2折腾NFS背景生命不息，折腾不止。前段时间，为了让WSL更好地来开发Linux和OH，折腾出了一系列文章： WSL2相关 wsl2上折腾docker 解决WSL2网络和存储问题 上次把WSL2的网络弄好了，最近就准备将开发环境更进一步，开始折腾NFS。以为和Ubuntu主机上搭建NFS一样(嵌入式Linux基础开发环境搭建)，简单的一条命令加配置就搞定了，但后面发现根本不是那么一回事。而且网上也很少有完整实用的借鉴参考，只能自己摸索，实战出真知。 启用systemdWSL2默认是没有启用systemd，但很多程序是依赖它的，特别是需要开机启动的。在发行版中添加配置文件/etc/wsl.conf，并加入如下内容： [boot] systemd=true 安装配置NFSsudo apt install nfs-common nfs-kernel-server rpcbind 新建一个目录(如这里的/home/xxx/nfs)，作为NFS的目录，修改/etc/export，在最后添加如下一行： /home/xxx/nfs * ...

使用GDB和VSCode调试内核背景上一篇，已经搭建好QEMU的内核调试环境：https://notes.z-dd.online/2024/03/06/%E5%9F%BA%E4%BA%8EQEMU%E7%9A%84%E5%86%85%E6%A0%B8%E8%B0%83%E8%AF%95%E7%8E%AF%E5%A2%83%E6%90%AD%E5%BB%BA/ 这篇主要在前面的基础上尝试用gdb来调试内核，躺了不少坑。 安装GDB这里安装支持多种硬件体系架构的GDB版本，也可直接使用系统自带的默认gdb。如架构不同，需使用交叉编译工具链中的gdb，后面有时间会更新不同架构下的调试。 sudo apt-get install -y gdb-multiarch # 支持多种硬件体系架构的GDB版本 准备调试内核在以前的基础上需修改一些内核配置才能调试： 打开CONFIG_GDB_SCRIPTS：在内核主目录下生成gdb脚本文件vmlinux-gdb.py，该脚本实现了一些便于内核调试的命令，它们都以lx-开头,这个暂时先没用，后面再研究看看 打开CONFIG_DEBUG_INFO：该选项用 ...

基于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方式）则需要自己 ...