# 内核功能 Qualcomm^®^ Linux^®^ 内核提供以下与 Qualcomm 平台上的主线 Linux 内核相关的关键功能和改进： - Qualcomm Linux BSP 专为支持使用 Qualcomm 平台的设备而量身定制。 - 设备树与 Qualcomm Linux 开发套件相对应。 - 提供多种定制编译版本配置以满足您的要求。 - Qualcomm Linux 内核集成到 Yocto 编译系统中。 - Qualcomm Linux 内核与上游 LTS 内核保持一致。增加的 Qualcomm 特定配置将单独维护。 - 支持配置、定制和编译可在使用 Qualcomm 硬件 SoC 产品的设备上刷写和启动的内核镜像。 - 使用 Gunyah™ Hypervisor 软件支持不受信虚拟机的虚拟化。 - 定期 LTS 从相应的 LTS 内核分支合并以获取最新的安全性和稳定性修复。 ## UEFI 启动管理器 Qualcomm Linux 支持 systemd-boot 作为通用可扩展固件接口 (UEFI) 启动管理器来加载和启动 Linux 内核。在这种情况下，Qualcomm Linux 内核是作为 EFI 存根编译的。 ### 启动流程和架构概述 冷启动是指从关机状态启动系统的过程。冷启动过程包括以下步骤： 1. 冷启动从 primary boot loader (PBL) 开始执行，以此设置初始系统，以便执行 eXtensible boot loader (XBL)。 2. XBL 执行包括 DDR 初始化在内的更广泛的系统初始化，并加载 UEFI 镜像。 3. UEFI 提供丰富的固件接口，用于将 systemd-boot 作为启动管理器加载至 Qualcomm Linux，以管理操作系统镜像。 有关完整冷启动流程的更多信息，请参阅 [Qualcomm Linux 启动指南](bundle/publicresource/topics/80-70018-4)中的[冷启动架构](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-4/bootloader-architecture.html)。 ### Systemd-boot Systemd-boot 是一种 UEFI 启动管理器，用于执行 EFI 镜像、提供启动项并支持统一内核镜像 (UKI)。Systemd-boot 支持以下组件： - 启动条目：类型 1 boot loader 规范条目位于 ESP 上的 `loader/entries/` 目录。这些文件描述了 Qualcomm Linux 内核镜像及其相关的 initrd 镜像和其他 EFI 可执行文件。 - UKI：类型 2 boot loader 规范 EFI 统一内核镜像是位于 ESP 上的 `/EFI/Linux/` 目录中的可执行 EFI 二进制文件。 有关启动项和统一内核镜像的更多信息，参见 [BootLoader Specification](https://uapi-group.org/specifications/specs/boot_loader_specification)。 Systemd-boot 是 元 Yocto 层的 systemd 软件包的一部分。Yocto recipe 使用 `systemd-boot_254.4.bb` 配方文件编译 systemd-boot，以及 `uki.bbclass` 配方文件来处理 ESP 镜像生成。 有关 systemd-boot 的更多信息，请参阅[使用 systemd-boot 和 UKI 配置和安全启动](https://docs.qualcomm.com/bundle/publicresource/topics/80-70018-27/qualcomm_linux_software_components.html#configure-and-secure-boot-with-systemd-boot-and-uki)。 ### Qualcomm Linux 内核作为 EFI stub EFI boot stub 允许直接启动 Qualcomm Linux 内核，而无需传统的 EFI boot loader。 当使用 `CONFIG_EFI_STUB` 内核配置选项编译 Qualcomm Linux 内核时，启动固件可以将 EFI 镜像作为可执行文件加载。在这种情况下，固件加载程序导航到 EFI 镜像 `drivers/firmware/efi/libstub/` 中的 `EFI boot stub` 位置以启动内核。 对于 Arm^®^ (Arm64)，在没有压缩内核支持的情况下，内核镜像作为可移植可执行 (PE) 文件格式或通用目标文件格式 (COFF) 镜像运行，并且 EFI 存根链接到内核中。 有关将 Linux 内核作为 EFI 镜像启动的详细信息，参见 [EFI Boot Stub](https://docs.kernel.org/admin-guide/efi-stub.html)。 ### 启动镜像和 ESP 或启动分区 ESP 或启动分区作为打包 systemd-boot 和 UKI 的 `efi.bin` 镜像的存储位置。UKI 包括内核镜像、initramfs 和内核命令行参数。 UEFI 固件用于启动 UEFI boot loader 并加载内核启动镜像。ESP 分区使用 UEFI 规范支持的文件分配表 (FAT) 文件系统进行格式化。有关 UKI 镜像格式以及基础 Qualcomm Linux 元层中相应支持的更多信息，请参阅 [systemd-boot](https://docs.qualcomm.com/bundle/publicresource/topics/80-70015-27/platform_software_features.html#systemd-boot)。 ### DTB 的选择 所有设备树 blob 均打包至 `dtb.bin` 中。UEFI 选择并加载适合 Qualcomm Linux 内核的 DTB。 要了解启动时 DTB 选择，可参见[平台设备树和内核配置](https://docs.qualcomm.com/doc/80-70020-3SC/topic/customize.html##platform-support-0)。 ## 配置 DTB 支持 Qualcomm Linux 按照以下步骤来选择设备树文件、更改内核配置以及编译树外内核模块。 ## 平台设备树 Qualcomm Linux 支持设备树叠加功能，以维护设备外树 blob 并将其与基线设备树 blob 合并。SoC 设备树支持存在于 `arch/arm64/boot/dts/qcom` 目录中的内核源代码中。 Qualcomm 设备树源文件列出了设备树，并进行明确区分，以包含下游增加的配置，同时支持与上游对齐的基本配置。 下游内容托管在内核源代码之外。树外驱动程序在内核之外维护增加的设备树叠加内容。在编译过程中，相应的设备树叠加文件与基本的板级 DTB 合并，生成统一的 DTB，与启动镜像配合使用。 下图显示了 QCS6490 上设备树叠加的编译过程以及自定义 BSP 的 DTB 生成： Note - 基本 BSP 遵循相同的编译过程，不包含 **addons** 下游设备树文件。 - 对于 DT 叠加 和 DTB 生成，所有支持的 Qualcomm 硬件 SoC 都遵循相同的编译流程。 Page-1 Sheet.1 Sheet.2 Sheet.3 Rectangle.1000 Kernel 内核 Rectangle.1001 sc7280.dtsi sc7280.dtsi Rectangle.1002 qcm6490.dtsi qcm6490.dtsi Rectangle.1004 qcs6490-rb3gen2.dts qcs6490-rb3gen2.dts Rectangle.1005 qcm6490-addons.dtsi qcm6490-addons.dtsi Rectangle.1007 qcm6490-addons-rb3gen2.dtsi qcm6490-addons-rb3gen2.dtsi Rectangle.1008 qcs6490-addons-rb3gen2.dts qcs6490-addons-rb3gen2.dts Rectangle.1009 qcs6490-addons-rb3gen2-ia.mezz.dts qcs6490-addons-rb3gen2-ia.mezz.dts Rectangle.1010 qcs6490-addons-rb3gen2-ptz-mezz.dts qcs6490-addons-rb3gen2-ptz-mezz.dts Rectangle.1011 qcs6490-addons-rb3gen2-video-mezz.dts qcs6490-addons-rb3gen2-video-mezz.dts Rectangle.1012 qcs6490-addons-rb3gen2-vision-mezz.dts qcs6490-addons-rb3gen2-vision-mezz.dts Rectangle.1013 Rectangle.1014 Camera 摄像头 Rectangle.1015 qcm6490-camera.dtsi qcm6490-camera.dtsi Rectangle.1017 qcs6490-addons-camera-rb3gen2.dtso qcs6490-addons-camera-rb3gen2.dtso Rectangle.1019 Component N 组件 N Rectangle.1020 qcm6490-<component>.dtsi qcm6490-<component>.dtsi Rectangle.1021 qcm6490-addons-<component>.dtso qcm6490-addons-<component>.dtso Rectangle.1023 qcs6490-rb3gen2.dtb qcs6490-rb3gen2.dtb Rectangle.1026 qcs6490-addons-camera-rb3gen2.dtbo qcs6490-addons-camera-rb3gen2.dtbo Rectangle.1028 qcm6490-addons-<component>.dtbo qcm6490-addons-<component>.dtbo Sheet.25 Rectangle.1029 Build time fdt overlay 编译时间 fdt 叠加 Sheet.27 Sheet.28 Sheet.29 Sheet.30 (Board dependent) （依赖于主板） Sheet.31 (Board independent) （依赖于主板） Sheet.32 Sheet.33 Sheet.34 Sheet.35 Sheet.36 Sheet.37 Sheet.38 Sheet.39 Sheet.40 Sheet.41 Sheet.42 Dynamic connector.1061 Rectangle.1062 qcs6490-addons-rb3gen2.dtb qcs6490-addons-rb3gen2.dtb Sheet.45 Sheet.46 Sheet.47 Sheet.48 Sheet.49 Upstream 上游 Sheet.50 Sheet.51 Open source 下游 Sheet.52 Sheet.53 Downstream 开源代码 Sheet.54 Sheet.55 Build blobs 编译 blob **图：QCS6490 上的设备树叠加** 构建系统使用 `fdt_overlay` 工具用于在构建期间配置树外设备树叠加处理。 DTBO 合并流程支持合并 `meta-qcom-hwe/conf/machine/--.conf` 文件中列出的 DTBO 文件。 以下是如何在 QCS6490 上枚举设备树变量的示例。有关平台特定的信息，可参见电路板特定的机器配置文件。 # List of dtbs for corresponding supported qcs6490 platforms KERNEL_DEVICETREE = " \ qcom/-addons-.dtb \ " # Additional list of dtbos to be overlaid on top of base kernel devicetree files # Format - KERNEL_TECH_DTBOS[] = " ..." # For example: KERNEL_TECH_DTBOS[qcs6490-addons-rb3gen2] = " \ qcm6490-graphics.dtbo qcm6490-wlan-rb3.dtbo \ qcm6490-display-rb3.dtbo qcm6490-bt.dtbo \ qcm6490-video.dtbo qcm6490-wlan-upstream.dtbo \ " Copy to clipboard 按照以下步骤更新内核中支持的 DTB，并在启动时选择 DTB： **内核中的 DTB 编译支持** 要将新平台的设备树集成到内核编译中，可更新 `Makefile`。 以下示例展示了为 QCS6490 SoC 定制 DTB 的方法。复制以下方法以添加新的 DTB。 diff --git a/arch/arm64/boot/dts/qcom/Makefile b/arch/arm64/boot/dts/qcom/Makefile index 183aeba47193..a7815c774f7c 100644 --- a/arch/arm64/boot/dts/qcom/Makefile +++ b/arch/arm64/boot/dts/qcom/Makefile dtb-$(CONFIG_ARCH_QCOM) += qcs6490-addons-rb3gen2.dtb +dtb-$(CONFIG_ARCH_QCOM) += qcs6490-my-board.dtb dtb-$(CONFIG_ARCH_QCOM) += qcs6490-rb3gen2.dtb dtb-$(CONFIG_ARCH_QCOM) += qcs404-evb-1000.dtb Copy to clipboard **在机器配置中包含 DTB** Yocto 机器配置也进行了更新，包括相应的设备树 blob。例如，要添加支持 QCS6490 机器的设备树，请使用以下文件： `meta-qcom-hwe/conf/machine/qcs6490-rb3gen2-core-kit.conf`： OUT_OF_KERNEL_DTSO - qcs6490-rb3gen2-core-kit.conf # List of dtbs for corresponding supported qcs6490 platforms KERNEL_DEVICETREE = " \ qcom/qcs6490-my-board.dtb \ qcom/qcs6490-addons-rb3gen2.dtb \ qcom/qcs6490-my-board.dtb \ " # Additional list of DTBOs to be overylaid on top of base kernel devicetree # See how existing boards are managing it in the following example: # Format - KERNEL_TECH_DTBOS[] = " ..." KERNEL_TECH_DTBOS[qcs6490-addons-rb3gen2] = " \ qcm6490-graphics.dtbo qcm6490-wlan-rb3.dtbo \ qcm6490-display-rb3.dtbo qcm6490-bt.dtbo \ qcm6490-video.dtbo qcm6490-wlan-upstream.dtbo \ Copy to clipboard Note 请参见 `meta-qcom-hwe/conf/machine/*.conf` 目录中有关不同 SoC 的机器配置文件。定制 BSP 版本的 DTB 文件名包含 `addons`。 **启动时选择 DTB** 定制 DTB 将作为 UKI 镜像的一部分打包，该镜像可在 EFI 中更新，从而通过所选 DTB 启动。 使用 ukify 工具生成 UKI 镜像。ukify 工具是 `tmp-glibc/sysroots-components/x86_64/systemd-boot-native/usr/bin/ukify` 编译目录中 Yocto 编译的一部分。 要生成 UKI 镜像，请运行以下命令： # Note - ukify tool need python 3.10 version or above ukify build --efi-arch=aa64 \ --stub=/tmp-glibc/deploy/images//linuxaa64.efi.stub \ --linux=/tmp-glibc/deploy/images//Image \ --initrd=/tmp-glibc/deploy/images//initramfs-qcom-image-.cpio.gz \ --cmdline="console=ttyMSM0,115200n8 earlycon qcom_geni_serial.con_enabled=1 kernel.sched_pelt_multiplier=4 mem_sleep_default=s2idle" \ --devicetree=/tmp-glibc/deploy/images//-my-board.dtb \ --output=./uki.efi Copy to clipboard ukify 编译命令生成带有自定义板卡 DTB `uki.efi` 的镜像。 要更新 ESP 分区中的 `uki.efi` 镜像，请执行以下操作： # Following may need sudo privilege # Take the yocto build generated efi.bin and mount it locally mount /tmp-glibc/deploy/images//efi.bin /mnt --options rw # Overwrite the uki.efi with one packaged above cp uki.efi /mnt/EFI/Linux/uki.efi umount /mnt # now efi.bin carries packaged uki.efi which can be flashed to the target and booted # UEFI shall now pick the -my-board.dtb that is part of uki.efi image # reboot into fastboot and flash efi.bin fastboot flash efi /tmp-glibc/deploy/images//efi.bin Copy to clipboard 有关设备树规范的更多信息，请参见 [The Devicetree Specification](https://www.devicetree.org/specifications/)。 有关设备树的 Linux 内核文档，请参见 [Linux and the Devicetree](https://docs.kernel.org/devicetree/usage-model.html)。 **DTBO 合并序列** `image-qcom-deploy.bbclass` 分类中的 `merge_dtbos()` 任务使用 `fdt_overlay` 工具合并 DTBO。 `merge_dtbos()` 任务迭代按以下顺序进行： 1. 在配置文件中列出 DTBO 文件名。 2. DTBO 文件名通过 `KERNEL_DEVICETREE` 变量进行迭代。 3. 对于每个基础 DTB，DTBO 合并任务叠加 `KERNEL_TECH_DTBOS` 变量中列出的 DTBO。 4. 叠加过程完成后，将生成最终的 DTB 输出。 ## Remoteproc 子系统 Remoteproc 框架用于将固件加载到 Qualcomm 平台上的其他子系统中，例如音频数字信号处理器 (aDSP) 和计算数字信号处理器 (cDSP)。 Remoteproc 框架分为两部分： - 核心框架：核心框架包含了共同的逻辑。核心框架用于加载固件并启动或停止远程处理器。 - Remoteproc 驱动程序：驱动程序包含管理相应核心的平台特定操作。Remoteproc 驱动程序向核心框架注册一个 remoteproc 实例和一组操作。 在非对称多处理 (ASMP) 配置中，SoC 上存在多个异构远程处理器。远程处理器运行不同的固件（或操作系统）实例。 如需详细了解 Qualcomm Linux 用于管理其他核心的标准框架，参见 [Remote Processor Framework](https://www.kernel.org/doc/html/next/staging/remoteproc.html)。 ## Qualcomm 对 remoteproc 的支持 Qualcomm 已增强 remoteproc 框架，以便使用上游 PAS 驱动程序进行外设固件鉴权。 Qualcomm Linux 中的 remoteproc 驱动程序实现了外设鉴权服务 (PAS) 驱动程序，该驱动程序是一种基于 TrustZone 的外设镜像加载程序，用于 Qualcomm SoC 设备上的远程处理器。 有关详细信息，请参阅 [qcom_q6v5_pas.c](https://github.com/torvalds/linux/blob/master/drivers/remoteproc/qcom_q6v5_pas.c)。 远程处理器用于管理各种协处理器的生命周期，如 aDSP、cDSP、modem 外设子系统 (MPSS) 和无线处理器子系统 (WPSS) 等。基于 QCS6490 的电路板和 Dragonwing™ RB3 Gen 2 开发套件上支持的协处理器包括 aDSP、cDSP 和 WPSS。 Note 支持的远程处理器子系统列表取决于正在使用的 SoC。 **用户界面：** remoteproc 框架可跟踪注册的 remoteproc 设备并提供用于启动和关闭设备的用户接口。用户空间可以使用以下 `sysfs` 接口查询和更改 remoteproc 的当前状态界面： remoteproc user space interface # start remoteproc: echo "start" > /sys/class/remoteproc/remoteprocN/state # stop remoteproc: echo "stop" > /sys/class/remoteproc/remoteprocN/state Copy to clipboard Page-1 Sheet.1 Process.1001 Process Process.5 Sheet.6 User space clients 用户空间客户端 Sheet.7 Peripheral manager 外设管理器 Process.11 Sheet.9 /sys/class/remoteproc/remoteproc* /sys/class/remoteproc/remoteproc* Lateral line Lateral line.27 Process.28 Lateral line.29 Sheet.14 Userspace 用户空间 Sheet.15 /dev/remoteproc* /dev/remoteproc* Sheet.16 Kernel 内核 Process.1002 Process.1003 Process.1004 Mdt-loader/SCM driver Mdt-loader/SCM 驱动程序 Process.1005 Process.1006 Process.1007 Process.1008 Sheet.24 Remoteproc core Remoteproc 核心 Sheet.25 Remoteproc platform device Remoteproc平台设备 Sheet.26 sysmon sysmon Sheet.27 Glink Glink Sheet.28 SSR notification SSR 通知 Sheet.29 Sheet.30 Sheet.31 Sheet.32 Process.1026 Kernel clients 内核客户端 Sheet.34 Sheet.35 Sheet.36 Remoteproc subdevices Remoteproc 子设备 Sheet.37 Sheet.38 Sheet.39 Open source 开源代码 **图：Remoteproc 支持** ## 配置 Remoteproc 恢复和子系统重启 Remoteproc 子设备负责管理远程处理器子系统崩溃和恢复场景中的通信环境。 通信环境等实体必须确定远程处理器何时启动或关闭。每个子设备都有两个操作： - `probe()`，在 remoteproc `start()` 之后调用 - `remove()`，在 `stop()` 之前调用 当远程处理器发生致命错误时，remoteproc 驱动程序会处理该错误并调用 `rproc_report_crash()`，从而触发故障远程处理器的恢复。 恢复处理程序会执行以下操作： Page-1 Sheet.1 Rectangle Sheet.3 Sheet.4 Sheet.5 Sheet.6 Sheet.7 Rectangle.1012 Sheet.9 Start remoteproc instance 启动 remoteproc实例 Sheet.10 Rectangle.1006 Sheet.12 Reload firmware 重新加载固件 Sheet.13 Rectangle.1005 Sheet.15 Invoke coredump generator 调用 coredump生成器 Sheet.16 Rectangle.1001 Sheet.18 Stop remoteproc instance 停止 remoteproc实例 **图：Remoteproc 崩溃序列** 要使用用户空间中的恢复 `debugfs` 节点来启用和禁用恢复，请执行以下操作： mount -t debugfs nodev /sys/kernel/debug echo disabled > /sys/kernel/debug/remoteproc/remoteprocN/recovery Copy to clipboard ## 启用或禁用核心 dump 使用 Qualcomm Linux 内核 devcoredump 功能，支持远程处理器核心 dump，以便调试子系统崩溃问题。 当子系统崩溃时，devcoredump 会将正在恢复的 remoteproc 的内存拍照呈现在 `/sys/class/devcoredump/devcdN/data` 节点中，同时将相关的崩溃 `uevent` 发送到用户空间。读取 sysfs 节点时，sysfs 会通过 ELF 容器提供内存段；对该节点进行写入操作时，会释放相关资源并销毁 devcoredump 实例。 公开 debugfs 节点，用于从用户空间启用和禁用核心 dump。 # Disable core dumps: echo disabled > /sys/kernel/debug/remoteproc/remoteprocN/coredump # Enable core dumps: echo enabled > /sys/kernel/debug/remoteproc/remoteprocN/coredump # # N represents the index number of the remote processor. Copy to clipboard Note Qualcomm SoC 在 remoteproc 崩溃（远程处理器上的致命错误）时会触发内核 panic，以便收集完整的 RAM dump 文件，用于进行崩溃分析。仅当核心 dump 禁用时，才会启用内核 panic 模式。 仅当为子系统启用了核心 dump 时，才会在子系统崩溃时创建 devcoredump `/sys/class/devcoredump/devcdN/data` 节点。要启用核心 dump，请运行 `echo enabled > /sys/kernel/debug/remoteproc/remoteprocN/coredump` 命令。`devcdN/data` 节点是临时的，超时后会被删除。要调试问题，请使用 `copy` 命令将 `devcdN/data` 节点复制到本地设备以便安全使用。删除超时在 `base/devcoredump.c` 中定义。 以下是复制核心 dump 的示例命令： # Copy Core dump to a local device cp /sys/class/devcoredump/devcdN/data > /var/spool/crash/dump_file.elf # # N represents the index of core dump. It is incremented each time a new core dump is generated. Copy to clipboard 要将核心 dump 文件传输到主机设备并调试问题，请使用 Qualcomm Crash Analysis Portal (QCAP)。 Note 有关 QCAP 的更多信息，请参阅 [Parse RAM dumps using QCAP](https://docs.qualcomm.com/bundle/resource/topics/80-70020-12A/debugging_linux_kernel.html#parse_ram_dumps_using_qcap)。 ## 在 DT 中配置 remoteproc 节点和固件加载 Remoteproc 设备使用 DT 绑定在相应的设备树文件中进行配置。根据 `Documentation/devicetree/bindings/remoteproc/` 目录中的 DT 绑定，该配置包括兼容的设备名称、内存区域、中断设置和时钟参考。 以下示例显示了 `arch/arm64/boot/dts/qcom/qcs6490.dtsi` 文件中的 QCS6490 aDSP remoteproc 设备树配置： remoteproc_adsp: remoteproc@3000000 { compatible = "qcom,sc7280-adsp-pas"; reg = <0x0 0x03000000 0x0 0x100>; interrupts-extended = <&pdc 6 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, <&adsp_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; interrupt-names = "wdog", "fatal", "ready", "handover", "stop-ack", "shutdown-ack"; clocks = <&rpmhcc RPMH_CXO_CLK>; clock-names = "xo"; }; Copy to clipboard 检查 `arch/arm64/boot/dts/qcom/sa8775p.dtsi` 路径中的 IQ-9075 设备树配置文件。 Note 要获取所有 Qualcomm SoC 的设备树配置文件，参见相应的平台 DTSI 文件。 所有固件文件都位于 `rootfs` 中的 `/lib/firmware` 目录中并在相应板卡设备树 `arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts` 文件中进行相关配置。对于其他 Qualcomm 硬件 SoC，请参阅 `arch/arm64/boot/dts/qcom/-.dts` 文件。 以下示例展示了 remoteproc DT 配置： &remoteproc_adsp { firmware-name = "qcom/qcs6490/adsp.mdt"; status = "okay"; }; Copy to clipboard 在 remoteproc 成功启动后，会显示以下日志： ** \# remoteproc success** "remoteproc remoteproc1: remote processor 4080000.remoteproc is now up" Copy to clipboard 在 remoteproc 固件加载失败后，会显示以下日志： ** \# remoteproc failure** Error log: "remoteproc remoteproc0: Direct firmware load for qcom/qcs6490/modem.mdt failed with error -2" # Caused by: error loading firmware. # Solution: ensure that the modem firmware is copied to /lib/firmware/qcom/qcs6490 in rootfs. Copy to clipboard Qualcomm^®^ Linux 内核基线支持所有内存管理功能和分配器。以下信息概述了如何定制内存映射和执行堆管理。 有关 Linux 内核内存管理的详细信息，参见 [Memory management](https://www.kernel.org/doc/html/next/core-api/index.html#memory-management)。 **内存映射** 内存映射描述了内核启动过程中为子系统（如 Modem、摄像头、aDSP 和 cDSP 等）保留的区域。 内存映射为 DTSI 中的划分区域设置 `no-map`，使内核无法访问这些区域。 可配置的划分区域定义在 `reserved-memory` 节点下的 `arch/arm64/boot/dts/qcom/qcs6490.dtsi` 文件中。 reserved-memory { cdsp_secure_heap_mem: cdsp-secure-heap@81800000 { reg = <0x0 0x81800000 0x0 0x1e00000>; no-map; }; camera_mem: camera@84300000 { reg = <0x0 0x84300000 0x0 0x500000>; no-map; }; wpss_mem: wpss@0x84800000 { reg = <0x0 0x84800000 0x0 0x1900000>; no-map; }; adsp_mem: adsp@86100000 { reg = <0x0 0x86100000 0x0 0x2800000>; no-map; }; }; Copy to clipboard Note 对于 Qualcomm SoC ，参见 SoC 特定的 Qualcomm DTSI 文件以获取此信息。 以下早期启动日志显示了为不同子系统创建的划分区域： [ 0.000000] OF: reserved mem: 0x0000000081800000..0x00000000835fffff (30720 KiB) nomap non-reusable cdsp-secure-heap@81800000 [ 0.000000] OF: reserved mem: 0x0000000084300000..0x00000000847fffff (5120 KiB) nomap non-reusable camera@84300000 [ 0.000000] OF: reserved mem: 0x0000000084800000..0x00000000860fffff (25600 KiB) nomap non-reusable wpss@0x84800000 [ 0.000000] OF: reserved mem: 0x0000000086100000..0x00000000888fffff (40960 KiB) nomap non-reusable adsp@86100000 Copy to clipboard Qualcomm Linux 分发版支持 CMA 来分配物理上连续的大内存。CMA 在启动时会保留大块的物理上连续的内存区域，并在 CMA 分配时提供物理上连续的内存。不使用时，CMA 内存可供内核伙伴分配器进行可移动分配。 要更改默认 CMA 区域的大小，请运行内核命令行参数中的 `cma=size_in_MB`。有关如何使用内核参数的详细信息，可参见以下示例： cma=nn[MG]@[start[MG][-end[MG]]] [KNL,CMA] Sets the size of kernel global memory area for contiguous memory allocations and optionally the placement constraint by the physical address range of memory allocations. A value of 0 disables CMA altogether. For more information, see kernel/dma/contiguous.c Copy to clipboard 自定义 CMA 区域定义在 `reserved-memory` 节点，其兼容标签 `shared-dma-pool` 指示 CMA 区域： adsp_heap_mem: adsp-heap { compatible = "shared-dma-pool"; alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>; reusable; alignment = <0x0 0x400000>; size = <0x0 0xc00000>; }; Copy to clipboard 以下所示为启动时保留的 aDSP CMA 内存区域的日志示例： [ 0.000000] OF: reserved mem: initialized node adsp-heap, compatible id shared-dma-pool [ 0.000000] OF: reserved mem: 0x00000000ff000000..0x00000000ffbfffff (12288 KiB) map reusable adsp-heap Copy to clipboard ## 添加自定义 CMA 堆 要使用 DMA-BUF 堆创建自定义 CMA 区域，请使用 Qualcomm Linux 内核中现有的 DMA-BUF 框架。 Qualcomm Linux 内核导出自定义 DMA-BUF 堆的 `cma_heap_add()` API。 /** * cma_heap_add - adds a CMA heap to dmabuf heaps * @cma: pointer to the CMA pool to register the heap for * @data: unused * * Returns 0 on success. Else, returns errno. */ int cma_heap_add(struct cma *cma, void *data); Copy to clipboard 导出到用户空间的 DMA-BUF 堆，其名称与设备树中 CMA 区域的 phandle 相同。 要添加自定义 CMA 堆，可执行以下操作： 1. 要创建定制 CMA 区域，请参见[连续内存分配器](https://docs.qualcomm.com/doc/80-70020-3SC/topic/features.html##memory-contiguous)。 2. 在要添加自定义堆的驱动程序中： 1. 解析新添加的 CMA 区域的设备树。 2. 添加与驱动程序相关的 DMA-BUF 堆。 int create_my_cma_heap(struct device *dev) { int rc = 0, idx = 0; rc = of_reserved_mem_device_init_by_idx(dev, dev->of_node, 0); // Parse the devicetree for the cma region if (rc) { pr_err("No reserved DMA memory, ret=%d\n", rc); rc = -EINVAL; goto err; } rc = cma_heap_add(dev->cma_area, NULL); // Add a dmabuf heap associated with the cma region if (rc) { pr_err("cma_heap_add failed, ret=%d\n", rc); rc = -EINVAL; goto err; } err: return rc; } Copy to clipboard Note 将 CMA 区域对齐到 4 MB 地址基址并设置大小，以支持页面迁移。迁移发生在 page-block 级别的 2 ^pageblock\_order^ 页。在 Qualcomm Linux 内核中，页面块阶次为 10。 ## 支持的堆 下表列出了 Qualcomm Linux 分发版默认支持的堆： 表：默认支持的堆 | 堆名称 | Dev 节点 | 说明 | 用法 | | --- | --- | --- | --- | | 系统堆 | /dev/dma_heap/system
Copy to clipboard | 内核会创建默认的 DMA-BUF 堆。 | 所有通用用例都必须遵循系统堆，系统堆在底层使用的是常见的 Linux 内存管理伙伴分配器。 | | Reserved | /dev/dma_heap/reserved
Copy to clipboard | 系统中创建的默认 CMA 类型的堆，使用默认*保留的* CMA 区域。 | 如果由于任何限制而需要使用连续内存，可使用 CMA 堆。 | | 定制 CMA 堆 | /dev/dma_heap/my_cma_heap
Copy to clipboard | 用户定义的 CMA 类型的堆。 | 为特定的定制 CMA 堆创建自己的 CMA 类型的堆时使用。 | ## 使用 DMA-BUF 堆 Qualcomm Linux 分发版支持 DMA-BUF 堆，用于分配自定义 CMA 堆。对于 DMA-BUF 堆，每个堆在 `/dev/dma_heap` 文件系统中都有一个设备文件。除了系统堆和常用的 CMA 预留堆外，用户还可以创建自己的 CMA 类型的 DMA-BUF 堆。 下面是一个示例程序，演示了如何使用 Qualcomm Linux 内核创建的 DMA-BUF 系统堆 `/dev/dma_heap/system:` include include include include include include include #include define DMA_HEAP_NAME "system" define SZ_4 0x00000004 // to allocate a 4K buffer int main() { int fd, dma_buf_fd; struct dma_heap_allocation_data dma_alloc_data = { .len = SZ_4, .fd_flags = O_RDWR | O_CLOEXEC, }; struct dma_buf_sync sync_start = { .flags = DMA_BUF_SYNC_START, }; struct dma_buf_sync sync_end = { .flags = DMA_BUF_SYNC_END, }; fd = open("/dev/dma_heap/system", O_RDWR); if (fd < 0) { perror("open"); return errno; } dma_buf_fd = ioctl(fd, DMA_HEAP_IOCTL_ALLOC, &dma_alloc_data); if (dma_buf_fd < 0) { perror("ioctl"); return errno; } printf("Allocated DMA buffer with fd %d\n", dma_buf_fd); if (ioctl(dma_buf_fd, DMA_BUF_IOCTL_SYNC, &sync_start)) { perror("ioctl DMA_BUF_IOCTL_SYNC start"); return errno; } // Do something with the buffer here if (ioctl(dma_buf_fd, DMA_BUF_IOCTL_SYNC, &sync_end)) { perror("ioctl DMA_BUF_IOCTL_SYNC end"); return errno; } if (close(dma_buf_fd)) { perror("close"); return errno; } if (close(fd)) { perror("close"); return errno; } return 0; } Copy to clipboard ## 将 ZRAM 配置为交换设备 ZRAM 是一种压缩交换机制，可在 RAM 中创建虚拟块设备。ZRAM 已作为模块在内核 defconfig 中启用。 在 `recipes-extended/zram/zram/zram-swap-init-update` 文件的 Yocto 编译中配置 ZRAM。 如需启用或配置 ZRAM，可执行以下程序： # check if zram module is loaded lsmod | grep zram # else load it modprobe zram # Configure /dev/zram0 size according to your RAM size echo 128M > /sys/block/zram0/disksize # activate swap mkswap /dev/zram0 swapon /dev/zram0 Copy to clipboard 要将 ZRAM 配置为交换设备，请参阅 [zram: Compressed RAM-based block devices](https://www.kernel.org/doc/html/v6.6/admin-guide/blockdev/zram.html)。 ## 扩展内存映射 若要扩展内存映射，可调整 DTSI 文件中内存区域的地址和大小。 使用以下信息扩展划分区域： 使用以下语法在 **reserved-memory** 节点中的 `arch/arm64/boot/dts/qcom/--.dts` 文件中添加划分区域： my_carveout_mem: my_carveout_mem@address { reg= <0x0 0xbase_address 0x0 0xsize>; no-map; } Copy to clipboard 例如： my_carveout_mem: my_carveout_mem@d0800000 { reg= <0x0 0xd0800000 0x0 0x100000>; no-map; } Copy to clipboard 表：划分区域的语法 | 变量 | 说明 | | --- | --- | | my_carveout_mem@d0800000
Copy to clipboard | 指示设备节点的名称。按照惯例，应将内存区域的基址附加到名称中。 | | my_carveout_mem
Copy to clipboard | 指示分配给此节点的标签，该标签可供设备树中的其他节点使用 phandle 引用此节点时使用。 | | reg
Copy to clipboard | 指示属性，该属性是一个 64 位值，用于定义内存区域的基址和大小。 | | no-map
Copy to clipboard | 指示此区域已划分，内核应从其可寻址范围中删除映射。 | Note - 任何区域都不应重叠。如果必须增大某个区域的大小，则移动所有其他后续区域，并在设备树中进行配置以避免重叠。 - 内核要求供内核使用的所有内存区域边界都对齐到 1 MB。 - 现有划分区域受受信任固件保护，防止内核访问。减小其大小或将其删除可能会导致外部中止，造成内核崩溃。 **添加 CMA 区域** 要在**保留内存**节点下的 `arch/arm64/boot/dts/qcom/--.dts` 文件中添加 CMA 区域，请使用以下语法： my_cma_mem: my_cma { compatible = "shared-dma-pool"; alloc-ranges = <0x0 0x00000000 0x0 0xffffffff>; reusable; alignment = <0x0 0x400000>; size = <0x0 0x1400000>; }; Copy to clipboard 表：添加 CMA 区域的语法 | 参数 | 说明 | | --- | --- | | my_cma_mem
Copy to clipboard | CMA 节点的标签，可用作 phandle。标签 `my_cma` 是 CMA 区域的名称。 | | shared-dma-pool
Copy to clipboard | 指示此区域是 CMA 区域。 | | alloc-ranges
Copy to clipboard | 指示此区域是否应处于某个特定的内存限制范围内，因为某些设备无法访问超过 32 位地址限制的内存区域。 | | reusable
Copy to clipboard | 指示内核可以在该内存区域空闲时使用其中的内存。 | | alignment
Copy to clipboard | 指示此区域中的任何对齐要求。 | | size
Copy to clipboard | 指示区域的大小： | | reg
Copy to clipboard | 这是一个可选属性，指示用于内存分配的固定区域，若不设置此属性，则以随机地址动态分配内存。 | Qualcomm Linux 内核支持标准的 Linux 调度器方案。内核使用调度器根据 CPU 能耗选择适合放置任务的目标 CPU。 调度器决定进程的运行顺序。调度器运行每个 CPU 的运行队列中的进程。 内核基线支持标准的 Linux 调度器方案。内核使用 [Energy Aware Scheduling (EAS)](https://www.kernel.org/doc/html/next/scheduler/sched-energy.html) 功能根据 CPU 能耗选择适合放置任务的目标 CPU。 EAS 会取代完全公平调度器 (CFS) 任务唤醒负载均衡代码。在采用非对称 CPU 拓扑的系统中，它会使用 CPU 的能量模型 (EM) 和实体负载跟踪 (PELT) 信号，在任务唤醒负载均衡期间选择节能的目标 CPU。 有关调度器的基本文档，参见 [Scheduler](https://www.kernel.org/doc/html/next/scheduler/index.html)。 ## 了解 CPU 拓扑和 EAS Qualcomm SoC 采用异构 CPU 拓扑，这些拓扑通过 EAS 中使用的 CPU 容量指标加以区分。 EAS 使用*容量*的概念来区分具有不同计算能力的 CPU。CPU 的容量表示的是相对于系统中性能最强的 CPU 而言，以最高频率运行时完成的工作量。容量值归一化至 1024 范围内（最强大 CPU/群集的容量值配置为 1024）。 EAS 根据 CPU 节点中指定的 Dhrystone 每秒百万条指令 (DMIPS) 值和群集支持的最高频率确定群集的容量。 下表列出了 CPU 拓扑和容量对应的 `sysfs` 节点： > > > 表：CPU 拓扑和容量 > > > | 命令 | 目的 | > | --- | --- | > | cat /sys/devices/system/cpu/cpu*/cpu_capacity
Copy to clipboard | 获取系统中每个 CPU 的相关容量。 | > | cat /sys/devices/system/cpu/cpufreq/policy*/related_cpus
Copy to clipboard | 获取与系统中每个群集相关的 CPU 列表。 | 有关调度器如何使用 CPU 容量的详细信息，参见 [Capacity Aware Scheduling](https://www.kernel.org/doc/html/next/scheduler/sched-capacity.html)。 ## 更改默认 CPU 频率调节器 CPU 频率调节器可以在 runtime 更改，也可以在编译版本编译过程中静态设置。 1. Kconfig 配置选项：要设置 CPU 频率调节器，请在内核 defconfiguration 文件中启用相应的驱动程序。 要设置 `PERFROMANCE` 调节器作为默认 CPU 频率调节器，请在 defconfiguration 文件中设置 `CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y`。 2. 内核命令行选项：要覆盖内核配置选项，请在 `meta-qcom-hwe/conf/machine/include/qcom-.inc` 文件中的内核命令行中添加 `cpufreq.default_governor=performance` 参数，以设置适当的 CPU 频率调节器。 ## 配置实体负载跟踪 实体负载跟踪 (PELT) 是一种负载跟踪机制，用于跟踪 `sched_entities/groups/runqueues` 的负载计算。 调节 PELT 时钟乘数以满足功耗和性能要求。 命令行参数 `sched_pelt_multiplier` 允许您设置时钟乘数。时钟乘数可调节 PELT 上升/下降速度，以便优化系统功耗和性能。 半衰期越短，任务的 CPU 利用率累积得越快。这些任务被分配给性能 CPU，从而以更高的功耗实现更好的性能。此外，CPU 利用率也会累积起来，以便在更短的时间内选择更高的 CPU 频率。 Note 半衰期还会影响任务利用率的下降方式。UTIL EST 功能可加快下降速度。 在 Linux 内核中，PELT 半衰期乘数会影响系统如何适应不断变化的工作负载，并根据历史利用率数据调整 CPU 频率。该配置可加快 PELT 时钟并缩短半衰期，从而加快系统响应速度。 通过内核命令行参数配置 PELT 乘数： `kernel.sched_pelt_multiplier=[1, 2, 4] Default value: 1 (half life 32 msec), 2 (half life 16msec), 4(half life 8 msec)]` 有关 PELT 的详细信息，参见 [Per-entity load tracking](https://lwn.net/Articles/531853/)。 ## 配置 SchedUtil 调速器 SchedUtil CPU 频率调节器是 Qualcomm Linux 内核中的默认调节器。SchedUtil 根据 CPU 利用率预测最佳工作点 (OPP)，从而在频率请求与能耗预测之间保持一致。 SchedUtil CPU 频率调节器与 EAS 相关联，它试图预测所有 CPU 下一步将在哪个 OPP 下运行以估算它们的能耗。 有关更多信息，请参阅 [SchedUtil](https://www.kernel.org/doc/html/next/scheduler/schedutil.html)。 ## 配置利用率限制 (UCLAMP) 利用率限制是调度器的一个功能，允许用户空间管理任务的性能要求。 要执行限制操作，请配置以下参数： - `UCLAMP_MIN`：如果设置为任意值 `> 0`，则任务需求将始终大于或等于该值。如果实际任务需求大于此值，则使用实际需求信号，但如果实际任务需求小于此值，则将 `UCLAMP_MIN` 报告为任务需求。 - `UCLAMP_MAX`：如果设置为任意值 `> 0`，则任务需求将始终小于或等于该值。如果实际任务需求小于该值，则使用实际需求信号；但如果实际任务需求大于该值，则将 `UCLAMP_MAX` 作为任务需求报告。 Note `UCLAMP_MAX > UCLAMP_MIN` 使用 UCLAMP 影响调度器的任务分配决策。 在异构系统中，调度器使用任务需求或利用率信号（PELT 信号）将任务分类为小任务或大任务。根据任务分类的输入，调度器会选择较小（计算能力较低）或较大（计算能力较高）的 CPU 核心进行任务放置，这可能会对功耗产生影响。 例如，将非重要（琐碎/后台/综合管理）任务限制为较低的值 (`lower UCLAMP_MAX`)，从而促使调度器将任务分配到小群集。同样，将重要/前台/活动任务限制为较高的值 (`higher UCLAMP_MIN`)，从而促使调度器将任务分配到大群集。 UCLAMP 还允许通过调度器控制频率指导。 要满足任务的快速频率上升需求，可将任务限制为较高的需求 (`UCLAMP_MIN`) 值。更高的限制有助于提升群集的频率，以满足任务的性能要求。 UCLAMP 操作允许从用户空间对任务/任务组进行性能管理。 UCLAMP 允许放置任务或任务组，并允许性能提示或约束。此机制用于影响调度器放置决策或影响群集的频率指导。 有关更多信息，请参阅 [UCLAMP](https://www.kernel.org/doc/html/next/scheduler/sched-util-clamp.html)。有关接口和配置的更多信息，请参见 [Utilization Clamping](https://www.kernel.org/doc/html/v6.6/scheduler/sched-util-clamp.html)。 ## 了解 CPU 拓扑和 EAS Qualcomm SoC 采用异构 CPU 拓扑，这些拓扑通过 EAS 中使用的 CPU 容量指标加以区分。 EAS 使用*容量*的概念来区分具有不同计算能力的 CPU。CPU 的容量表示的是相对于系统中性能最强的 CPU 而言，以最高频率运行时完成的工作量。容量值归一化至 1024 范围内（最强大 CPU/群集的容量值配置为 1024）。 EAS 根据 CPU 节点中指定的 Dhrystone 每秒百万条指令 (DMIPS) 值和群集支持的最高频率确定群集的容量。 下表列出了 CPU 拓扑和容量对应的 `sysfs` 节点： > > > 表：CPU 拓扑和容量 > > > | 命令 | 目的 | > | --- | --- | > | cat /sys/devices/system/cpu/cpu*/cpu_capacity
Copy to clipboard | 获取系统中每个 CPU 的相关容量。 | > | cat /sys/devices/system/cpu/cpufreq/policy*/related_cpus
Copy to clipboard | 获取与系统中每个群集相关的 CPU 列表。 | 有关调度器如何使用 CPU 容量的详细信息，参见 [Capacity Aware Scheduling](https://www.kernel.org/doc/html/next/scheduler/sched-capacity.html)。 ## 配置实体负载跟踪 实体负载跟踪 (PELT) 是一种负载跟踪机制，用于跟踪 `sched_entities/groups/runqueues` 的负载计算。 调节 PELT 时钟乘数以满足功耗和性能要求。 命令行参数 `sched_pelt_multiplier` 允许您设置时钟乘数。时钟乘数可调节 PELT 上升/下降速度，以便优化系统功耗和性能。 半衰期越短，任务的 CPU 利用率累积得越快。这些任务被分配给性能 CPU，从而以更高的功耗实现更好的性能。此外，CPU 利用率也会累积起来，以便在更短的时间内选择更高的 CPU 频率。 Note 半衰期还会影响任务利用率的下降方式。UTIL EST 功能可加快下降速度。 在 Linux 内核中，PELT 半衰期乘数会影响系统如何适应不断变化的工作负载，并根据历史利用率数据调整 CPU 频率。该配置可加快 PELT 时钟并缩短半衰期，从而加快系统响应速度。 通过内核命令行参数配置 PELT 乘数： `kernel.sched_pelt_multiplier=[1, 2, 4] Default value: 1 (half life 32 msec), 2 (half life 16msec), 4(half life 8 msec)]` 有关 PELT 的详细信息，参见 [Per-entity load tracking](https://lwn.net/Articles/531853/)。 ## 配置 SchedUtil 调速器 SchedUtil CPU 频率调节器是 Qualcomm Linux 内核中的默认调节器。SchedUtil 根据 CPU 利用率预测最佳工作点 (OPP)，从而在频率请求与能耗预测之间保持一致。 SchedUtil CPU 频率调节器与 EAS 相关联，它试图预测所有 CPU 下一步将在哪个 OPP 下运行以估算它们的能耗。 有关更多信息，请参阅 [SchedUtil](https://www.kernel.org/doc/html/next/scheduler/schedutil.html)。 ## 配置利用率限制 (UCLAMP) 利用率限制是调度器的一个功能，允许用户空间管理任务的性能要求。 要执行限制操作，请配置以下参数： - `UCLAMP_MIN`：如果设置为任意值 `> 0`，则任务需求将始终大于或等于该值。如果实际任务需求大于此值，则使用实际需求信号，但如果实际任务需求小于此值，则将 `UCLAMP_MIN` 报告为任务需求。 - `UCLAMP_MAX`：如果设置为任意值 `> 0`，则任务需求将始终小于或等于该值。如果实际任务需求小于该值，则使用实际需求信号；但如果实际任务需求大于该值，则将 `UCLAMP_MAX` 作为任务需求报告。 Note `UCLAMP_MAX > UCLAMP_MIN` 使用 UCLAMP 影响调度器的任务分配决策。 在异构系统中，调度器使用任务需求或利用率信号（PELT 信号）将任务分类为小任务或大任务。根据任务分类的输入，调度器会选择较小（计算能力较低）或较大（计算能力较高）的 CPU 核心进行任务放置，这可能会对功耗产生影响。 例如，将非重要（琐碎/后台/综合管理）任务限制为较低的值 (`lower UCLAMP_MAX`)，从而促使调度器将任务分配到小群集。同样，将重要/前台/活动任务限制为较高的值 (`higher UCLAMP_MIN`)，从而促使调度器将任务分配到大群集。 UCLAMP 还允许通过调度器控制频率指导。 要满足任务的快速频率上升需求，可将任务限制为较高的需求 (`UCLAMP_MIN`) 值。更高的限制有助于提升群集的频率，以满足任务的性能要求。 UCLAMP 操作允许从用户空间对任务/任务组进行性能管理。 UCLAMP 允许放置任务或任务组，并允许性能提示或约束。此机制用于影响调度器放置决策或影响群集的频率指导。 有关更多信息，请参阅 [UCLAMP](https://www.kernel.org/doc/html/next/scheduler/sched-util-clamp.html)。有关接口和配置的更多信息，请参见 [Utilization Clamping](https://www.kernel.org/doc/html/v6.6/scheduler/sched-util-clamp.html)。 Qualcomm Linux 内核基线支持多种 DVFS 实现，以便根据系统要求以动态方式管理频率调节。 ## 选择 CPU DVFS 调速器 您可以选择一个调速器来调整系统的功率或性能，同时更改 `CPUfreq` 调节器（`powersave/performace/schedutil`）。默认情况下，在 Qualcomm Linux 内核上，将 CPU 频率调节器设置为 `performance`。 表：CPU DVFS 变量 | 变量 | 说明 | 路径 | | --- | --- | --- | | scaling_governor
Copy to clipboard | 将调节器设置为性能模式。 | echo performance > /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
Copy to clipboard | | scaling_max_freq
Copy to clipboard | 设置 CPU 群集的最高频率。 | /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
Copy to clipboard | | scaling_min_freq
Copy to clipboard | 设置 CPU 群集的最低频率。 | /sys/devices/system/cpu/cpufreq/policy*/scaling_min_freq
Copy to clipboard | 有关 `CPUfreq` 的更多信息，请参阅 [CPU frequency and voltage scaling code in the Linux(TM) kernel](https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt)。 ## 配置缓存和内存 DVFS 调节器 静态映射 DVFS 调节器将 CPU 工作频率与以下各项保持一致： - 三级缓存 (L3) - 最后一级缓存控制器 (LLCC) - DDR RAM 如果 CPU 频率达到最高，无论是通过将 CPU 频率调节器设置为性能模式来达到最高，还是因系统中的负载过高而达到最高，L3、LLCC 和 DDR 也以最高频率运行。 该调节器的驱动程序位于 `drivers/cpufreq/qcom-cpufreq-hw.c` 文件，并且静态映射位于 `arch/arm64/boot/dts/qcom/sc7280.dtsi` 文件。 Note 对于 Qualcomm SoC，请参阅特定于平台的 DTSI 文件以获取此信息。 另一个带宽监测 (BWMON) 调节器用于根据 CPU 与 LLCC 和 CPU 与 DDR 之间的流量检测，对 LLCC 和 DDR 的频率进行投票。该调节器的驱动程序位于 `drivers/soc/qcom/icc-bwmon.c` 文件。 **CPU 频率**与 **L3/DDR 频率**之间的映射根据功耗或性能要求调整。 在 DTSI 中，对于每个 CPUx 节点，都有一个 `operating-points-v2 = <&cpux_opp_table>` 条目。`cpux_opp_table` 保存 CPU、L3 和 DDR 频率之间的静态映射。 例如： cpu0_opp_300mhz: opp-300000000 { opp-hz = /bits/ 64 <300000000>; opp-peak-kBps = <800000 9600000>; }; Copy to clipboard 当 CPU 0 以 300 MHz 运行时，它对 L3 表决 9600000，这相当于 300,000 Hz（9600000/w）的 L3 频率。如果表决为 DDR 提供 800,000 Hz，则所得 DDR 工作频率为 200,000 Hz (800000 / w)。 在等式中，“w”表示单个周期内可以写入多少个字节： - 对于 DDR，“w”为 4（每个通道每个周期执行两次事务，每次事务为 2 个字节）。 - 对于 L3，“w”为 32（每个周期一个事务，每个事务 32 个字节）。 Note 这些值是针对 DDR 每条通道设置的，该映射将 CPU 频率与内存控制器 (MC) 通道带宽相关联。调整此映射表会影响功耗和性能特征。 有关工作性能点 (OPP) 框架和语法的更多信息，请参见 [Generic OPP (Operating Performance Points) Bindings](https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt)。 ## 配置调度程序 DVFS 设置 调度器 DVFS 设置在 `post_boot script` 文件中定义。 所有启动后设置都在 `meta-qcom-hwe/recipes-core/initscripts/files/post_boot.sh` 脚本中。更多信息，请参阅 [post_boot.sh](https://github.com/qualcomm-linux/meta-qcom-hwe/blob/scarthgap/recipes-core/initscripts/files/post_boot.sh)。 ## 选择 CPU DVFS 调速器 您可以选择一个调速器来调整系统的功率或性能，同时更改 `CPUfreq` 调节器（`powersave/performace/schedutil`）。默认情况下，在 Qualcomm Linux 内核上，将 CPU 频率调节器设置为 `performance`。 表：CPU DVFS 变量 | 变量 | 说明 | 路径 | | --- | --- | --- | | scaling_governor
Copy to clipboard | 将调节器设置为性能模式。 | echo performance > /sys/devices/system/cpu/cpufreq/policy*/scaling_governor
Copy to clipboard | | scaling_max_freq
Copy to clipboard | 设置 CPU 群集的最高频率。 | /sys/devices/system/cpu/cpufreq/policy*/scaling_max_freq
Copy to clipboard | | scaling_min_freq
Copy to clipboard | 设置 CPU 群集的最低频率。 | /sys/devices/system/cpu/cpufreq/policy*/scaling_min_freq
Copy to clipboard | 有关 `CPUfreq` 的更多信息，请参阅 [CPU frequency and voltage scaling code in the Linux(TM) kernel](https://www.kernel.org/doc/Documentation/cpu-freq/governors.txt)。 ## 配置缓存和内存 DVFS 调节器 静态映射 DVFS 调节器将 CPU 工作频率与以下各项保持一致： - 三级缓存 (L3) - 最后一级缓存控制器 (LLCC) - DDR RAM 如果 CPU 频率达到最高，无论是通过将 CPU 频率调节器设置为性能模式来达到最高，还是因系统中的负载过高而达到最高，L3、LLCC 和 DDR 也以最高频率运行。 该调节器的驱动程序位于 `drivers/cpufreq/qcom-cpufreq-hw.c` 文件，并且静态映射位于 `arch/arm64/boot/dts/qcom/sc7280.dtsi` 文件。 Note 对于 Qualcomm SoC，请参阅特定于平台的 DTSI 文件以获取此信息。 另一个带宽监测 (BWMON) 调节器用于根据 CPU 与 LLCC 和 CPU 与 DDR 之间的流量检测，对 LLCC 和 DDR 的频率进行投票。该调节器的驱动程序位于 `drivers/soc/qcom/icc-bwmon.c` 文件。 **CPU 频率**与 **L3/DDR 频率**之间的映射根据功耗或性能要求调整。 在 DTSI 中，对于每个 CPUx 节点，都有一个 `operating-points-v2 = <&cpux_opp_table>` 条目。`cpux_opp_table` 保存 CPU、L3 和 DDR 频率之间的静态映射。 例如： cpu0_opp_300mhz: opp-300000000 { opp-hz = /bits/ 64 <300000000>; opp-peak-kBps = <800000 9600000>; }; Copy to clipboard 当 CPU 0 以 300 MHz 运行时，它对 L3 表决 9600000，这相当于 300,000 Hz（9600000/w）的 L3 频率。如果表决为 DDR 提供 800,000 Hz，则所得 DDR 工作频率为 200,000 Hz (800000 / w)。 在等式中，“w”表示单个周期内可以写入多少个字节： - 对于 DDR，“w”为 4（每个通道每个周期执行两次事务，每次事务为 2 个字节）。 - 对于 L3，“w”为 32（每个周期一个事务，每个事务 32 个字节）。 Note 这些值是针对 DDR 每条通道设置的，该映射将 CPU 频率与内存控制器 (MC) 通道带宽相关联。调整此映射表会影响功耗和性能特征。 有关工作性能点 (OPP) 框架和语法的更多信息，请参见 [Generic OPP (Operating Performance Points) Bindings](https://www.kernel.org/doc/Documentation/devicetree/bindings/opp/opp.txt)。 Last Published: Jul 22, 2025