Kernel 7.2.5 (EL1) VENUS r4

Kernel 7.2.5 (EL1) VENUS r4 — 7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r4

目标设备：HUAWEI MateBook E Go 2022 性能版（GK-W76 / SC8280XP / 设备树 gaokun3）
发布标签：kernel-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r4-20260915
基线：kernel.org stable v7.2.5 + 本项目自有补丁（gaokun3-7.2.5-el1.patch）
上一版：r3

本版主题：GPU 遥测。 把 msm 驱动里本来就有的 GPU 数据（使用率 / 显存占用 / 时钟 / 温度）
暴露到系统监视器（GNOME Resources 等）真正去读的路径上，并修掉一个应用侧 glob 缺陷造成的连锁失效。
本版不含待机功耗修复（仍在查，见 §8）。

---

1. 问题：GPU 页四项全是"不可用"

用户看到的界面里，显卡的使用率、频率、功耗、温度全部不可用。查下来是两层原因，缺一层都修不好：

层	原因
内核侧	msm 驱动从不注册 hwmon，也没有 gpu_busy_percent（全树只有 amdgpu 有）。数据都在驱动里，只是没有对外暴露。
应用侧	resources 找 hwmon 用的是 glob card?/device/hwmon/hwmon? —— 单个 ? 只匹配一个字符，所以只能匹配 hwmon0…hwmon9。本机 hwmon 索引是 15（/sys/class/hwmon 共 26 个）⇒ first_hwmon_path: None，走 hwmon 的温度/时钟/功耗永远拿不到；只有走 gpu_busy_percent 的使用率是好的。

应用侧那条是通用缺陷：任何 hwmon 数量 ≥10 的机器（大量笔记本都是）都会踩到，与 msm 无关。
证据是应用自己的 trace（RUST_LOG=trace，注意它是单实例应用，必须先退出再启动才会打日志）：

TRACE resources::utils::gpu > Gathered GPU data for 1: GpuData { usage_fraction: Some(0.1),
      used_vram: None, clock_speed: None, temperature: None, power_usage: None, ... }
TRACE resources::utils::gpu > OtherGpu { ..., first_hwmon_path: None }

2. 本版做了什么（patches/gpu-telemetry/，6 文件 / +346 行）

在 card?/device 指向的那个设备上（对 msm 就是支撑 DRM 实例的平台设备，与 amdgpu/i915/xe 的落点一致）：

新增	数据来源	说明
gpu_busy_percent	devfreq 已经在算的 GMU busy/total（a6xx 读 POWER_COUNTER_XOCLK_0，19.2 MHz 基准）	累积到 500 ms 窗口再发布（devfreq 单次采样只有 50 ms，对 1 Hz 的消费者噪声太大）；不在 sysfs 读路径上读寄存器，GPU 挂起时归零
mem_info_vram_used	priv->total_mem —— msm 为 gpu_mem_total tracepoint 维护的真实 GEM 计数器	纯计数器读取，不碰硬件
hwmon temp1_input	thermal zone gpu-thermal（每次读时按名字解析，tsens 可能比 msm 晚 probe）	走 hwmon_temp 正规通道
hwmon freq1_input	GPU 核心时钟（devfreq，含 idle 影子频率），单位 Hz	内核 hwmon 没有频率传感器类型，只能走 extra_groups 的 SENSOR_DEVICE_ATTR_RO（amdgpu/radeon 同法）
hwmon0 -> hwmonN 兼容别名	sysfs_create_link(hwmon->kobj.parent, &hwmon->kobj, "hwmon0")	专门为绕开上面那个应用 glob 缺陷；由 devres 管理，在 hwmon 注销前自动删除；/sys/class/hwmon/* 与真实 hwmonN 条目都不受影响。上游把 glob 改成 hwmon* 之后这一项应当删掉

sysfs 不允许用户态创建符号链接（ln -s 直接 Permission denied），所以这个别名只能在内核里做 —— udev 规则/启动脚本都做不到。

3. 实测（GK-W76 / SC8280XP / Adreno 690 / 真机装机复测）

$ ls /sys/class/drm/card1/device/hwmon/
hwmon0 -> hwmon15
hwmon15

$ cat /sys/class/drm/card1/device/hwmon/hwmon0/{name,temp1_input,freq1_input}
msm_gpu
34200                      # 34.2 °C，与 thermal zone0 gpu-thermal 一致
270000000                  # 270 MHz，与 /sys/class/devfreq/3d00000.gpu/cur_freq 一致

$ cat /sys/class/drm/card1/device/{gpu_busy_percent,mem_info_vram_used}
0                          # 桌面空闲；施加 GPU 负载时上升（另一轮实测 1–2 → 8）
242061312                  # 230.8 MiB（GEM 当前占用）

$ cat /sys/class/devfreq/3d00000.gpu/trans_stat | head -3     # 270↔547↔690 MHz 正常调频

同一时刻应用的 trace：

Found hwmon at "/sys/class/drm/card1/device/hwmon/hwmon0"
OtherGpu { ..., first_hwmon_path: Some("/sys/class/drm/card1/device/hwmon/hwmon0") }
GpuData { usage_fraction: Some(0.0), used_vram: Some(244924416),
          clock_speed: Some(547000000.0), temperature: Some(34.2), ... }

⇒ 使用率、显存占用、GPU 时钟、温度四项全部有值（时钟那一刻是 547 MHz，说明拿到的是真实调频值而不是 OPP 下限）。

4. 仍然显示"不可用"的项目（照实说明，不伪造）

界面项	原因
功耗 / 最大功耗	本机没有任何 GPU 功耗/电流传感器：EC hwmon 只有 20 路温度，电池 hwmon 只有整机侧 curr1_input，PMIC ADC 只有温度通道，调节器只报电压；设备树 GPU OPP 用 opp-level（RPMH 档位）而非 opp-microvolt，也没有 dynamic-power-coefficient ⇒ 连上游 devfreq-cooling 的标准功率模型都无法估算。编一个数字比显示 N/A 更糟
显存频率	UMA，没有独立显存时钟（GPU 侧只有 gfx-mem interconnect 带宽投票）
显存总量	UMA 没有"显存容量"这个物理量；mem_info_vram_used 给的是当前被 GEM 占用的内存
视频编码器/解码器占用	resources 对非 AMD/Intel/NVIDIA 显卡未实现该读取（应用侧限制，非本机缺失）
制造商 / PCI 插槽 / 接口	msm 的卡设备是平台设备，没有 PCI_ID/PCI_SLOT_NAME；伪造一个出来属于造假，不做

5. 资产

文件	大小 (B)	SHA-256
Image	24,734,208	53fc53fcd1db4b620c84b0aa5a235f0d0334c58ae36a738494850e4c5172483a
modules-7.2.5-…-r4.tar.zst	6,506,204	950c629935ec98b900d860715d8d10ede100a3837733fc6adbaa4137df5bf80b
sc8280xp-huawei-gaokun3.dtb	170,672	b16eef32b7f6d10ea0a3161931f708c1916cf512d20575f48bdd07e148ab49e0
System.map-7.2.5-…-r4	4,711,073	564063e87743768ddde6e1cb9c8b4ca769365fb9cc923efcb785e8d3291b89da
config-7.2.5-…-r4	209,239	3749cf333d1a5b8751925b49d94fc2c89ee7dfcd4d2c13b1798c852f4bb9fea2
gaokun3-7.2.5-el1.patch	192,322	d53a86a4e83e50267db2fe0cfc826965d528b91a8b919d568cb6c2ced96f73e9
BUILD-PROVENANCE.md	3,287	effd3b96244566800db97bea7e08c5bef679dcf5ff415db4119760c4aaf52de4
sha256sums.txt	707	—

sha256sum -c sha256sums.txt 可一次校验全部资产。

6. 安装 / 回滚

用仓库脚本安装（只新增 BLS 条目，不动 loader.conf 默认项、不碰 EFI 变量）：

sudo ./scripts/gk-install-kernel.sh \
  --kver 7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r4 \
  --image ./Image --dtb ./sc8280xp-huawei-gaokun3.dtb \
  --modules ./modules-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r4.tar.zst \
  --oneshot
sudo ./scripts/gk-install-kernel.sh --kver 7.2.5-…-r4 --uninstall   # 回滚

本版顺带修掉一个真机踩坑：模块包内含 lib/modules/<ver>/… 前缀（便于 tar -C / 手动展开），
而安装脚本此前只归一化 <ver>/<ver> 形态 ⇒ 展开后目录嵌套、depmod 找不到 modules.order、
initrd 缺模块，脚本只打印一句警告就继续。现在两种形态都归一化，并在真机上用同一个 tar 包重跑验证过。

内核串无尾部 +（CONFIG_LOCALVERSION_AUTO 已关且构建时移开 .git）⇒ 一份逻辑源码只派生一个串。

7. 复现

源码、补丁集、配置、工具链与逐条命令见随包 BUILD-PROVENANCE.md；摘要：

tar xf linux-7.2.5.tar.xz && cd linux-7.2.5
patch -p1 < gaokun3-7.2.5-el1.patch
cp config-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r4 out/.config
make O=out ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- olddefconfig
make O=out ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j16 Image modules dtbs

工具链：aarch64-linux-gnu-gcc (Debian 12.2.0-14) 12.2.0、GNU Make 4.3、binutils 2.40。

8. 已知问题与下一步

• ★ 待机功耗仍未修（本版不含）：实测挂起根本留不住 —— ①VPU 被占用时挂起失败
  （qcom-venus: wait for cpu and video core idle fail (-110)，且失败会把 DPU 打死成黑屏）；
  ②VPU 空闲时挂起只活 2–3 秒就被 PDC 上的唤醒 IRQ（dp_hs_phy_3 等）拉醒。
  这解释了"待机一夜掉电 70%"：机器其实是醒着、屏灭。修复随 r5。
• 开机动画（居中 LOGO + 左下角三行滚动启动输出）在做，做完随下一版发。
• EL1 的固有权衡：本版是 EL1（硬解 venus 需要），因此没有 /dev/kvm。
• 视频编解码器占用等 N/A 项的说明见 §4；GPU 页的功耗项不会在后续版本里出现，除非硬件有传感器。

9. 许可

内核为 GPL-2.0。本产物是 Linux 内核的二进制分发，对应源码可由上游 tag + 随包补丁 + 本仓库脚本完整复现
（见 BUILD-PROVENANCE.md），满足 GPL-2.0 的源码提供要求。本项目自有改动同以 GPL-2.0 发布。

Kernel 7.2.5 (EL1) VENUS r3

Kernel 7.2.5 (EL1) VENUS r3 — 7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3

目标设备：HUAWEI MateBook E Go 2022 性能版（GK-W76 / SC8280XP / 设备树 gaokun3）
发布标签：kernel-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3-20260913
基线：kernel.org stable v7.2.5 + 本项目自有补丁
上一版：r1

本版主题：触屏"幽灵中断"治理 + 一个真实驱动缺陷的修复。
修完缺陷后重新实测，才发现此前一轮（内部 r2）的结论是测量假象——详情见
docs/touch-idle-policy.md。

---

1. r3 相对 r1 改了什么

#	变更	说明
1	★ 修复 himax_lock()/himax_unlock() 中断使能不对称	himax_lock() 会 disable_irq_nosync() + synchronize_irq()，而 himax_unlock() 从不 enable_irq() ⇒ 任何一次 sysfs 访问都会把触屏中断永久屏蔽，直到下一次完整重初始化。修复：进入临界区记录使能状态，退出时按 irq_resume && panel_enabled && !idle_active && !shutting_down 恢复。该缺陷继承自社区驱动，r1 也带（日常使用不易察觉：面板 enabled 之后必然跟一次重初始化会把它重新打开；但一次 inplace_reset/算法参数写入就会让触屏"死掉"）
2	★ 新增可选空闲策略：中断门控采样	连续 7200 帧（≈60 s @120 Hz） 无已上报触点后 disable_irq()，随后每 30 ms 只放行一帧走正常中断路径判断有无触点；检出触点立刻恢复中断模式。默认启用，idle_enter_frames=0 可关闭
3	诊断节点（供排障/复现）	frame（不依赖中断地读一帧并返回校验和）、idle_state（空闲策略状态）、irq_gate、regs（裸 AHB 读写，受 allow_raw_ahb 门控、默认关闭）、AFE 回读日志
4	AFE 邮箱队列初始化	按 Windows 运行时的做法，芯片初始化后清零 5 个命令槽并把 host 写指针 0x1000753C 置 0

未变的部分：venus 硬解路径、qcom,force-gsi-mode（GSI/DMA）、触屏 SPI 驱动与 gpio174 拉低、
DSC/面板/EC/音频等板级补丁、EL1 启动级别、CONFIG_VIDEO_QCOM_VENUS=m + # CONFIG_VIDEO_QCOM_IRIS is not set。

---

2. 实机验证（2026-09-13）

装机方式：scripts/gk-install-kernel.sh 只新增一个 BLS 条目，
loader.conf 的 default 与 EFI 变量均未改动（一次性 bootctl set-oneshot）。

项	结果
启动级别	CPU: All CPU(s) started at EL1 ✅
内核串	7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3（无 +）✅
视频硬解	venus decoder + encoder ✅
触屏	Himax Capacitive TouchScreen，驱动正常绑定 ✅
KVM	无 /dev/kvm（EL1 的固有代价，与硬解互斥）

2.1 ★ 空闲策略实测（面板点亮、无人触摸）

指标	r1 行为	r3	改善
触屏 IRQ 速率	120.0 Hz	22.9 Hz	−81%
触屏 kthread CPU	2.00%（单核）	0.50%（单核）	−75%
空闲时 IC 是否仍扫描	是	是（未改变）	—
首触延迟	一帧 ≈8.3 ms	≈ 采样周期 30 ms + 一帧	真手指实测通过

触发时序已用 idle_state 逐秒核对：模块加载后计数单调增长（≈120 帧/秒），
60 s 时准时进入空闲并稳定保持（active=1，采样按 30 ms 节奏开合，无振荡）。

唤醒路径已用真手指验证（在携带同一退出路径的 r3-dev 构建上）：点按屏幕后 dmesg 出现
idle exit: touch after 30ms sampling，触点由正常中断路径上报；松手 7200 帧后重新进入空闲。
r3 装机后的复核结果见 §2.4。

2.4 r3 装机复核（2026-09-13）

装机方式：scripts/gk-install-kernel.sh --kver 7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3 … --oneshot，
只新增一个 BLS 条目（loader.conf 的 default 仍是原 7.1.0-rc3-el2 条目）。

项	结果
内核串	7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3（无 +）✅
启动级别	CPU: All CPU(s) started at EL1 ✅
venus	Quadcomm Venus video decoder = /dev/video32、encoder = /dev/video33 ✅
触屏	Himax Capacitive TouchScreen 绑定，msmgpio 175 IRQ 正常计数 ✅
空闲策略默认值	idle_enter_frames=7200、idle_poll_ms=30 ✅
空闲 IRQ 速率（面板点亮、无人触摸）	23.1 Hz（对照：策略关闭时 120 Hz）✅
空闲 kthread CPU	0.50%（单核；对照 2.00%）✅
60 s 触发	开机后 dmesg：idle: one frame every 30ms after 7200 contact-free frames（t=109 s，含开机初始化），idle_state 显示 active=1 ✅
触摸唤醒	✅ 已在 r3 正式内核上确认（见下方日志）

r3 上的唤醒复核（2026-09-13，真手指点按屏幕）【已核实】：dmesg 出现两次独立事件
himax-spi spi0.0: idle exit: touch after 30ms sampling（t=1138.5 s 与 t=1645.9 s），
两次之间 t=1204.0 s 又按"60 s 无触点"重新进入空闲（1138→1204 = 65.5 s，符合 7200 帧 + 开销）
⇒ 进空闲 → 触摸退出 → 松手重新计时 的完整闭环在正式内核上成立。
退出后 3 s 采样窗口内 msmgpio 175 增量 356（≈118.7 Hz），即已回到 120 Hz 中断模式（对照空闲 23 Hz）；
同时 idle_state = active=0 sampling=0 frames=2188 threshold=7200 poll_ms=30（松手后重新累积，走向下一次空闲）。

若该行未出现，请勿使用本内核并立即回滚（gk-install-kernel.sh --kver … --uninstall）。

2.2 ★ 为什么不采用"让 IC 自己睡"（AFE 0x0A）

修好中断屏蔽缺陷后，AFE 邮箱语义第一次被测准（详见 docs/touch-idle-policy.md §4）：
0x0A/0x00 确实让 IC 停扫（帧数据全 0、IRQ 0.3 Hz），0x0E/0x00 确实能把它重新唤醒；
但 IC 停扫期间主机读不到帧，也就无从判断"手指来了没有"，唤醒只能靠定时盲发或完整重初始化
（30–50 ms）。因此本版选择只屏蔽主机中断、让 IC 继续扫描：
收益是撤销了 81% 的中断与 75% 的空闲 CPU，代价只有约一个采样周期，不需要任何芯片重初始化。

2.3 已知取舍

• 空闲时 IC 自身仍在以 120 Hz 扫描（IC 侧功耗未降低）；若要压这部分功耗，需要另行设计
  "AFE 深睡 + 盲唤醒"策略并接受 30–50 ms 首触延迟，本版有意不做。
• regs（裸 AHB 读写）是取证用节点，默认关闭且不建议在正常使用中打开。

---

3. 产物（8 项，与 r1 同名同结构）

文件	大小
Image	24,734,208 B
modules-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3.tar.zst	6,502,281 B
sc8280xp-huawei-gaokun3.dtb（EL1 用）	170,672 B
config-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3	209,239 B
System.map-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3	4,711,028 B
gaokun3-7.2.5-el1.patch（本项目相对 mainline v7.2.5 的完整补丁）	178,960 B
sha256sums.txt / BUILD-PROVENANCE.md	—

驱动增量部分另有独立可审阅补丁：
patches/touch-idle/（+481 / −92 行）。

4. 安装与回滚

# 安装（只新增 BLS 条目，不动默认项）
sudo scripts/gk-install-kernel.sh --image Image --dtb sc8280xp-huawei-gaokun3.dtb \
     --modules modules-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r3.tar.zst --tag r3 --oneshot
# 回滚
sudo scripts/gk-install-kernel.sh --uninstall --tag r3

运行时若需临时关闭空闲策略：echo 0 | sudo tee /sys/module/himax_hx83121a_spi/parameters/idle_enter_frames
（采样周期可调：idle_poll_ms）。

Kernel 7.2.5 (EL1) VENUS r1

Kernel 7.2.5 (EL1) VENUS r1 — 7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r1

目标设备：HUAWEI MateBook E Go 2022 性能版（GK-W76 / SC8280XP / 设备树 gaokun3）
发布标签：kernel-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r1-20260913
基线：kernel.org stable v7.2.5 + 本项目自有补丁（23 个文件，+4524 / −196）

这是本仓库改名后的第一个内核产物（新命名规范自 r1 起生效），
也是第一个把「触屏 QUP-SPI 强制走 GSI（DMA）模式」合入的内核。

---

1. r1 相对 r0（7.2.5-aoripus-ml-gaokun-eog-el1+）改了什么

#	变更	说明
1	新增 2 条补丁：SPI 强制 GSI 模式	Pengyu Luo 的 v1 系列（binding + driver），见 patches/spi-gsi/。本机 DTS 早已写了 qcom,force-gsi-mode，但 v7.2.5 的驱动不读它，因此此前一直静默退回 FIFO 模式
2	内核串改用新命名规范	…-gaokun3-eog-el1-venus-r1（新增设备树代号 gaokun3、启动级别、VPU 驱动线、修订号四个字段）
3	内核串不再带尾部 +	构建时移开 .git（scripts/setlocalversion 在 git 树里必然追加 +，CONFIG_LOCALVERSION_AUTO=n 挡不住）—— 这是 r0 串 …-el1+ 那个 + 的来源，也是 r0 串不可复现的原因
4	移除 I²C-HID 变体产物	该路线在 GK-W76 上实测枚举不出来（见 r0 说明与 AGENTS.md §7.11），本版不再产出 …-i2c.dtb

未变的部分：venus 硬解路径、触屏 SPI 驱动与 gpio174 拉低、DSC/面板/EC/音频等板级补丁、
EL1 启动级别、CONFIG_VIDEO_QCOM_VENUS=m + # CONFIG_VIDEO_QCOM_IRIS is not set。

---

2. 实机验证（2026-09-13）

装机方式：scripts/gk-install-kernel.sh 只新增一个 BLS 条目，
loader.conf 的 default 与 EFI 变量均未改动（一次性 bootctl set-oneshot）。

项	结果
启动级别	CPU: All CPU(s) started at EL1 ✅
内核串	7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r1（无 +）✅
视频硬解	Qualcomm Venus video decoder（本次开机为 /dev/video32）+ encoder ✅
触屏	Himax Capacitive TouchScreen on event11，驱动正常绑定，gpio174 输出低 ✅
KVM	无 /dev/kvm（EL1 的固有代价，与硬解互斥）

2.1 ★ GSI 模式生效判据（空闲 20 s 窗口、无人触摸、两次采样取增量）

中断线	r0（FIFO 模式）	r1（GSI 模式）
998000.spi（GENI SE）	+6,206	0
gpi-dma	无此行（= 0）	+4,803
msmgpio 175（触屏 IC）	+2,397	+2,401

⇒ ① GSI 确实生效：GENI SE 中断恒为 0，传输完成改由 GPI DMA 中断报告
（约 2 次 DMA 中断 / 次触屏中断，即一次传输的 TX+RX 完成）；
② 每次触屏中断对应的 SPI 完成中断数从 ≈2.59 降到 ≈2.00（约 −23%）；
③ 逐字 FIFO 处理被 DMA 取代。

2.2 ★★ 滑动实测：每帧 IRQ 从 15.39 降到 3.56、CPU 占用降 63%

本节第一版写错了，特此更正并保留痕迹：最初根据空闲数据判定"GSI 不会改变
irq_per_frame，因为那条 IRQ 属于触屏 IC、与 SPI 模式无关"。真实滑动实测推翻了它 ——
空闲时两版确实一样，滑动时差 4.3 倍。教训：空闲数据不足以推断负载下的行为。

滑动对照（同一台机器、同一支脚本 tools/gk-touch-bench.py，用户匀速来回划屏）：

指标	r0（FIFO）	r1（GSI）	变化
帧数	1,413	4,017	+184%
有效帧率（剔除 >100 ms 停顿）	当时未记录该字段	119.3 Hz	—
帧间隔 中位	8.328 ms	8.329 ms	持平
帧间隔 p95	9.38 ms	9.523 ms	持平
帧间隔 p99	32.8 ms	10.267 ms	−69%（抖动显著收窄）
每帧触屏 IRQ	15.39	3.558	−77%
每帧触点事件	3.99	3.95	持平
CPU 忙	14.97 %	5.56 %	−63%

⇒ 报点率与帧间隔中位数不变（由 IC 决定），但每帧中断数 −77%、CPU 占用 −63%、p99 抖动 −69%
（上表为工具原始读数）。折算到"每次触点事件"：r0 ≈ 3.9 次中断，r1 ≈ 0.9 次 —— 已接近
"IC 每报一次只触发一次"的物理下限。

口径提示（重要）：r0 那次的 45 s 窗口内含一段约 29 s 的松手停顿；空闲时触屏 IC 仍以
约 120 次/秒触发中断（"幽灵中断"），故 r0 的 irq_per_frame 被高估、cpu_busy_pct 被低估。
扣除空闲段后更公平的估算是：每帧中断 ≈12.9 → ≈3.33（−74%）；r1 滑动段内 CPU ≈ 6.6%，
而 r0 的真实滑动段占用高于其窗口均值 14.97%，即"CPU 至少降到 1/2.7"。
原始 JSON、中断线增量与估算过程见 docs/bench/touch-bench-20260913.md。

滑动期间 GSI 依然生效（同一窗口的中断线增量）：998000.spi（GENI SE）前后均为 0，
gpi-dma +28,706，msmgpio 175（触屏 IC）+14,302，即约 2 次 DMA 中断 / 次触屏中断。

为什么"空闲时两版一致、滑动时差 4 倍"【机制为推测，现象为实测】：空闲时没有触点数据，
两版都只是 IC 约 120 次/秒的空转中断；滑动时 IC 持续产出数据，而 FIFO 模式每次 SPI 读都要
逐字中断、排空慢，level-low 的 INT 在数据被读完前会反复触发；GSI 用 DMA 快速排空，
于是每帧只需少数几次中断。

2.3 顺带发现（r0 与 r1 皆有，非本版引入）

无人触摸时，触屏 IC 仍以约 120 次/秒触发中断，却不产生任何输入事件（"幽灵中断"）。
45 秒空闲窗口内实测：触屏 IRQ +10,788、输入事件 0。
这条已记入下一轮待办（怀疑与 sense on 常开或 INT 未正确清除有关）。

---

3. 未完成 / 未验证（请勿据此过度推断）

#	项	状态
1	滑动状态下的报点率 / 帧间隔 / 中断 / CPU 对照（r0 vs r1）	✅ 已测（2026-09-13，用户匀速划屏）：每帧 IRQ 15.39 → 3.558、CPU 14.97% → 5.56%、p99 32.8 → 10.27 ms，报点率与中位帧间隔持平。详见 §2.2
2	GSI 对 CPU 占用与延迟的实际影响	✅ 已量化：CPU 忙 −63%；p99 抖动 −69%
3	"空闲时 IC 仍以 ~120 次/秒中断却无输入事件"（幽灵中断）	未查清（r0/r1 皆有，非本版引入）
4	Chromium V4L2VideoDecoder 复核	未做
5	热管理（75 °C 节流）、音频 UCM	仍未纳入本内核配套

测量口径：tools/gk-touch-bench.py --seconds 45 --wait-timeout 900，从检测到首个触摸帧
才开始计时；r0 那次的 --seconds 45 窗口内含一段约 29 s 的松手停顿（已由 long_gaps/max 反映，
故 r0 的 rate_hz 不具可比性，仅比较中位数与分位数）。

---

4. 产物清单

文件	大小 (B)	SHA-256
Image	24,734,208	955153d431d6d4ab4faae1d5bf39c392ed4cd851226edb1635b1b92dc9f2abce
sc8280xp-huawei-gaokun3.dtb	170,672	b16eef32b7f6d10ea0a3161931f708c1916cf512d20575f48bdd07e148ab49e0
modules-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r1.tar.zst	6,497,342	ea98f206313d2fe20f0e3bfc0b005bedc07a1770db8bda87c98d62263aeb5e36
config-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r1	209,239	1413ba3f2bbec2a27b24d82ba0300eaf455ad9d0ee58792739bbd875ae5d731f
System.map-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r1	4,711,028	17eee7e42c22376394321810f424b1acdfb8043d076d1b1f813c7d6e5e2418b7
gaokun3-7.2.5-el1.patch	160,550	72de3cefe2151cd1b95fb97d11e6bb7cf9a92709657c86a159c5c03f17877f5c
BUILD-PROVENANCE.md	1,410	0ebb25df57b54c47b25f94d88005984a5cb470351b55a38c687ec7105e018766
sha256sums.txt	700	—

• 模块包含 360 个 .ko。
• gaokun3-7.2.5-el1.patch 是本项目相对 mainline v7.2.5 的完整自有补丁
  （23 个文件，+4524 / −196），可直接 git apply 到 linux-7.2.5 复现。
• 上游源码：https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.2.5.tar.xz（160,133,944 B）。
• 完整配方与门禁：https://github.com/aoripus/easy-for-gaokun/blob/main/docs/kernel-7.2.5-el1-build.md。

---

5. 安装

# 在已装好本基线系统的 GK-W76 上（EL1 DTB，进入 EL1 启动级别）
sudo ./scripts/gk-install-kernel.sh \
  --kver 7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r1 \
  --image Image \
  --dtb sc8280xp-huawei-gaokun3.dtb \
  --modules modules-7.2.5-aoripus-ml-gaokun3-eog-el1-venus-r1.tar.zst \
  --oneshot

脚本只新增 BLS 条目，不改 loader.conf、不动 EFI 变量；--uninstall --kver … 一键回滚。

EL1 与 EL2 的差别只是条目里 devicetree 指向哪一份 DTB（…-gaokun3.dtb ↔ …-gaokun3-el2.dtb），
slbounce 会按 DTB 嗅探自行决定。切勿通过移除 EFI/systemd/drivers/ 下的
slbounce/qebspil 来"切到 EL1"——那会破坏 Secure Launch 导致黑屏挂死（本项目已实测踩坑）。

---

6. 风险声明

• EL1 下没有 /dev/kvm：本版为硬解走 EL1，虚拟化加速不可用，二者当前互斥。
• 本机型没有 EDL / 9008 救援通道：刷写前务必保留可用启动项。
• GSI 模式的前置条件：需要 CONFIG_QCOM_GPI_DMA=m 且 GPI DMA 节点 status = "okay"、
  SPI 节点有 dmas/dma-names。本机已满足；其他机型不保证。
• 上游补丁属 Pengyu Luo 的 v1 系列（未被上游合入，其 v2 已被作者本人撤回）。
• 内核源码为 GPL-2.0；本仓库为 GPL-2.0-only。

Kernel 7.2.5 (EL1) VENUS

Kernel 7.2.5 (EL1) — 7.2.5-aoripus-ml-gaokun-eog-el1+

发布日期：2026-09-13
基线：Linux stable v7.2.5（mainline 的 stable 版本，非 RC）
目标设备：HUAWEI MateBook E Go 2022 性能版（GK-W76）/ SC8280XP / gaokun3
启动级别：EL1（标准启动；slbounce 依设备树嗅探后留在 EL1）

---

1. 这一版解决了什么

问题	之前（基线 EL2 内核）	本版（EL1）
视频硬解	无任何 V4L2 解码器（venus/iris 均 probe 失败于 -22）	✅ /dev/video* 出现 qcom-venus-decoder，支持 H264 / VP8 / VP9 / HEVC / MPEG-2
触屏	完全无输入（中断计数恒为 1）	✅ Himax Capacitive TouchScreen 正常工作，中断持续触发
内核来源	第三方构建	✅ 本项目自编（稳定版 mainline + 本项目自有补丁）
KVM	有 /dev/kvm	❌ 无（EL1 的固有代价；硬解与 KVM 目前互斥）

实机验证（已核实）

$ uname -r
7.2.5-aoripus-ml-gaokun-eog-el1+
$ dmesg | grep 'started at EL'
[    0.008204] CPU: All CPU(s) started at EL1
$ v4l2-ctl --list-devices
Qualcomm Venus video decoder (plat:aa00000.video-codec:dec):  /dev/video33
Qualcomm Venus video encoder (plat:aa00000.video-codec:enc):  /dev/video32
$ mpv --hwdec=v4l2m2m-copy -v test1080p.mp4      # 片段节选
[vd] Trying hardware decoding via h264_v4l2m2m-v4l2m2m-copy.
[vd] Using underlying hw-decoder 'h264_v4l2m2m'
[ffmpeg/video] h264_v4l2m2m: Using device /dev/video33
$ grep himax /proc/interrupts
 322:      90419 ... msmgpio  175 Level  himax-spi-ts

触屏通路实测（45 s 有效窗口、匀速滑动）：

指标	值
帧间隔 中位 / p95 / p99	8.328 / 9.38 / 32.8 ms
由中位间隔推算的报点率	≈120 Hz
每帧触屏 IRQ 数	15.39
CPU 忙	15 %

---

2. 关键结论：为什么必须 EL1

• 上游 venus / iris 驱动都按 EL1 写：qcom_mdt_load(…, NULL) 分配固件缓冲 + 裸调
  qcom_scm_pas_auth_and_reset()。EL1 下这两步由 EL2 的 hypervisor 代管；
  在 bare-metal EL2 下无人代管，固件元数据会被 TrustZone 以 -22 拒绝。
• 即便补上 SHM bridge 侧的处理，上游 EL2 补丁集亦明确记载：
  "可以在 EL2 认证并启动固件，但 remoteproc 永不脱离复位" —— DSP 靠
  qcom,broken-reset/attach 兜底，而视频核没有 attach 可言。
• 因此本机（GK-W76）经 EL2 无法让视频核工作；EL1 是唯一可行路径。

EL1/EL2 的切换只需要换 BLS 条目里的 devicetree：
sc8280xp-huawei-gaokun3.dtb（EL1）↔ sc8280xp-huawei-gaokun3-el2.dtb（EL2）。
slbounce 会嗅探设备树并决定留在 EL1 还是切到 EL2。
不要用"移除 EFI/systemd/drivers/ 下的 slbounce/qebspil"来试图回退到 EL1 —— 那会破坏引导链导致黑屏。

---

3. 相对 mainline v7.2.5 的改动（自有补丁）

单一补丁：gaokun3-7.2.5-el1.patch（159,047 B，21 个文件，+4512 −196）。

方面	内容	来源
板级设备树 + defconfig	内屏双 DSI/面板/背光、SPI 触屏、EC、热区、摄像头等完整板级描述	社区（right-0903 系）
显示驱动	面板默认开 DSC、DPU DSC 时序宽度取整、面板 bl 供电表	社区
触屏	Himax HX83121A SPI 驱动（12 文件）+ DTS gpio174 输出低	社区 + 本项目
视频	venus 的 sm8350_res/sc8280xp_res、sc8280xp.dtsi 的 venus/videocc/pil_video_mem	Konrad Dybcio / Johan Hovold
本项目自有	板级 &venus { firmware-name = …; status = "okay"; };；EC 节点引脚/中断按社区意图收敛；pdc_map 移除 gpio175 映射	本项目
EL2 补丁集	一律不套用（本内核目标是 EL1）	—

上游状态提示：mainline v7.2.5 的板级 DTS 内屏是空的（只有 simple-framebuffer），
且把触屏描述成 i2c4@0x4f 的 hid-over-i2c —— 后者在本机实测无法枚举（见 §4）。

---

4. 已知问题

1. 上游 hid-over-i2c 触屏描述对本机无效：4-004f 设备节点存在但 i2c_hid 从不绑定、
   无输入设备、无中断。⇒ 必须走 SPI 路线（本内核即如此）。
2. 每帧 15.39 个触屏 IRQ 偏高：DTS 里写了 qcom,force-gsi-mode，但 v7.2.5 的
   spi-geni-qcom.c 不读该属性，SPI 退回 FIFO 模式（逐传输中断）。
   待补 spi: qcom-geni: Add property to force GSI mode（或跟进其 v2「DMA 可用即用 GSI」）。
3. 无 /dev/kvm（EL1 代价）。
4. 本内核未经长时间日常使用验证，建议保留原 EL2 菜单项作为兜底。
5. 音频 UCM、热管理节流（75 °C）等增强项未纳入本版。

---

5. 产物

文件	说明
Image	ARM64 内核镜像（24,734,208 B）
sc8280xp-huawei-gaokun3.dtb	EL1 用设备树（配本内核）
modules-7.2.5-aoripus-ml-gaokun-eog-el1+.tar.zst	全量模块树（360 个 .ko）
config-7.2.5-aoripus-ml-gaokun-eog-el1+	完整内核配置（可审计）
gaokun3-7.2.5-el1.patch	本项目相对 mainline v7.2.5 的全部改动
System.map-… / sha256sums.txt	符号表与校验和

安装（只新增菜单项，不动默认启动项，可一键回滚）：

sudo ./scripts/gk-install-kernel.sh \
  --kver 7.2.5-aoripus-ml-gaokun-eog-el1+ \
  --image Image \
  --dtb sc8280xp-huawei-gaokun3.dtb \
  --modules modules-7.2.5-aoripus-ml-gaokun-eog-el1+.tar.zst

---

6. 复现构建

见 docs/kernel-7.2.5-el1-build.md：包含完整配方、补丁来源表、
必须钉死的编译门禁（CONFIG_VIDEO_QCOM_IRIS 必须为 n，否则 venus 的 compatible 会被
预处理器静默删除、零报错、永不出解码器）。

curl -sSLO https://cdn.kernel.org/pub/linux/kernel/v7.x/linux-7.2.5.tar.xz
# 施加 gaokun3-7.2.5-el1.patch，然后
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- gaokun3_defconfig
# 断言：CONFIG_VIDEO_QCOM_VENUS=m 且 # CONFIG_VIDEO_QCOM_IRIS is not set
make ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu- -j$(nproc) Image modules dtbs

---

7. 许可证与致谢

内核本体为 GPL-2.0-only；本项目补丁沿用同一许可。
板级支持与驱动修复来自社区多位作者的成果，详见
docs/kernel-7.2.5-el1-build.md 的补丁来源表与仓库 README 的致谢列表。

Kernel 7.2.0-rc2 (EL2) IRIS

Kernel 7.2.0-rc2-aoripus-ml-gaokun-eog-iris-el2+

发布日期：2026-09-13
适用设备：HUAWEI MateBook E Go 2022 性能版（GK-W76 / GK-W7X-PCB / SC8280XP / gaokun3）

---

状态

已在本机（GK-W7X）实测启动验证：

子系统	实测结果
启动	one-shot 试启动通过，uname -r 即本产物的 release 串
音频	声卡 SC8280XP-HUAWEI-GAOKUN3 注册；SpkrLeft/Right PA Volume = 17
触屏	gpio174 : out low，Himax 中断计数持续增长
remoteproc	slpi / adsp / cdsp 均为 attached：EL2 下不做复位，接管引导固件已启动的实例
视频硬解	不可用（根因已定型：TZ 侧 QTEE + 签名 TA，Linux 够不到；不是 EL2 的限制），见下节

本机是标准 UEFI 平台：有固件设置界面、可从 USB 启动、ESP 是普通 FAT32 分区。安装时保留原
默认条目即可；即使引导项写错，也能用 U 盘启动挂载 ESP 修复。

视频硬解：尚未打通（附结论更正）

⚠️ 更正（2026-09-13 第三轮）

本节此前写的是"EL2 下不可用，且不可修复"。该结论已被推翻。

Steev Klimaszewski 在 Lenovo ThinkPad X13s（同为 SC8280XP） 上实测 iris 通过：
v4l2-compliance 48/48、真实播放正常，且明确包括 EL2（"In el2, the device seems to be
/dev/video33 … if I let the video play, it plays just fine"）。

同为该 SoC、同为 EL2，X13s 能跑而本机不能 —— 这说明问题是设备特有的，不是架构性的。
下面保留原始证据链（逐寄存器验证部分仍然完全有效），但结论改为"本机尚未打通、原因待查"。

本机是标准 UEFI 平台，安装与回滚都很简单。

固件启动要跨过四道关卡，本产物停在第四道：

阶段	结果	说明
qcom_scm_pas_init_image	通过	需要 patches/iris-el2/ 的 tzmem/ctx 修复，否则报 -22
qcom_scm_pas_auth_and_reset	通过	需要改用 qcom_scm_pas_prepare_and_auth_reset()：EL2 下 SHM bridge 必须由 Linux 自建
qcom_scm_mem_protect_video_var	-5（EIO）	只服务于 DRM 内容保护；上游在此处会直接 pas_shutdown() 并中止 probe，本产物改为非致命后继续
iris_vpu_boot_firmware	-62（ETIME）	驱动写 CTRL_INIT 后轮询 1000 次（约 110 ms），CTRL_STATUS 恒为 0

逐寄存器验证（2026-09-13 第二轮）

在驱动已完成上电与固件加载、并已写好 UC region 的 90 秒上电窗口内，从用户态经 /dev/mem
读取全部相关寄存器。供电、时钟、复位、固件四项全部正常，核心就是不执行：

检查项	地址	实测	判读
video_cc_mvs0c_clk	videocc+0xc34	0x221，运行于 840 MHz	时钟在跑
video_cc_mvs0_clk	videocc+0xd34	0x221，运行于 560 MHz	核心时钟在跑
ARES 异步复位位	上述两处 bit2	0 / 0	不在复位
mvs0c_gdsc / mvs0_gdsc	videocc+0xbf8 / +0xd18	均 PWR_STATE=1、SW_COLLAPSE=0	两个电源域都已上电
GCC_VIDEO_AXI0_CLK ARES	gcc+0x28010	0x221	AXI 时钟在跑、无复位
固件保留区	0x86700000	合法镜像头 06 10 00 00 01 ff ff ff …	固件在内存里
CTRL_STATUS	iris+0xa004c	轮询 1000 次恒为 0	固件从未应答
WRAPPER_TZ_CPU_STATUS	iris+0xc0010	WFI 位 = 0	CPU 不在运行

窗口内还穷举了全部可写路径，无一奏效：直接写 CTRL_INIT、撤销 AON/IRIS/调试桥三处 NOC
低功耗请求、清 TZ 侧时钟 halt、桥复位序列、TZ FIFO 复位、mvs0/mvs0c 两个 GDSC 各做一次
掉电→上电、以及写 CPU_CS_X2RPMH 的 MSK_CORE_POWER_ON（已回读确认寄存器可写）。

根因

上游 EL2 补丁集的作者对此有明确记载：

"It's possible to authenticate and start new firmware, but the remoteproc is never actually
brought out of reset. … all the PAS related calls still succeed, it will just not release the
remoteproc from reset."

即：EL2 下所有 PAS 调用都返回成功，但子系统永远不会真正脱离复位。 这与本机现象逐字吻合。

DSP（adsp / cdsp / slpi）之所以没事，是因为它们在开机时就已被引导固件启动，驱动可以靠
qcom,broken-reset 跳过复位、直接接管运行中的实例；而视频核必须由 Linux 亲自启动，没有
"在位接管"这条路，因此无从绕过。要让视频硬解可用，需要内核运行在 EL1（下方由 hypervisor
代管 PAS），而本机固件是把 Linux 直接投到 EL2。

已无改进空间的旁证

• 设备树不是原因：本产物生成的 iris 节点与上游 v7 系列（2026-05 最新）逐属性一致，
  含 iommus = <&apps_smmu 0x2a00 0x400>、resets、power-domains、memory-region。
• 上游也没有驱动支持：该系列只包含 DT 与 binding，不含任何驱动改动，且 cover letter
  自述 "The driver was very lightly tested on SC8280XP" —— 即上游同样没有在这个平台上跑通。
• 固件不是原因：换用 X13s 的 qcvss8280.mbn（2,035,812 B，与华为那份 2,035,748 B 仅差
  64 字节）后结果逐字节相同。

结论（更正后）

逐寄存器证据表明：供电、时钟、复位、固件四项全部正常，而视频核从不执行。
TrustZone 也确实活着（不存在的 PAS ID 一律返回 -22），并声称支持视频核
（pas_supported(9)=yes；镜像已加载时 pas_auth_and_reset(9)=0）。

与已知可用设备（X13s）最明确的差异是：qcom_scm_mem_protect_video_var 被本机 TrustZone
以 -EIO 拒绝 —— 在 X13s 上这一步必须成功，否则上游 iris 会在此处直接
pas_shutdown() 并中止 probe。此外本机固件经上游 master 的判定算法确认为 Gen1
（QC_IMAGE_VERSION_STRING=video-firmware.1.1-…），因此"用错 HFI 代次"已被排除。

根因（2026-09-13 第四轮定型）

把 Windows 驱动 qcdxkm8280.sys 的 TrustZone 接口逆向出来之后，根因清楚了：

该设备的 TrustZone 把视频子系统的安全世界支持（CP 内存保护 + 子系统状态机）实现在
QTEE + 签名 TA 之后，而 Linux 够不到那里。

• Windows 驱动视频核走的是 QTEE（TrEE）IOCTL，不是 Linux iris 用的 SIP SMC；
  并且它在视频核初始化时调用了 Linux 侧完全没有的 TZ 子系统状态函数
  （TZ_SUBSYS_STATE_RESUME、TZ_SUBSYS_STATE_VENUS_RESTORE_THRESHOLD，subsys = 9）。
• Linux 的 SIP 路径上，QCOM_SCM_MP_VIDEO_VAR 对本机无条件返回 -EIO：
  6 组参数（含从 Windows 逆向出的两套静态表）全部一致，且"冷状态"下作为第一个 SCM
  调用同样失败 —— 与顺序、状态、取值都无关。
• 经 qcomtee 复刻这条路被源码否决：drivers/tee/qcomtee/core.c 把 op 掩到 16 位
  （0x02000C08 当场 -EINVAL），且"只能调用 QTEE 托管的对象"，即需要签名 TA。

因此本机没有可走的 Linux 侧路径。 需要强调的是：这不是 EL2 的架构限制 ——
Lenovo ThinkPad X13s（同为 SC8280XP）已在 EL2 下把 iris 跑通。差异在设备专有的安全世界固件。

替代方案是软件解码：本机实测 1080p30 H.264 只吃约 0.5 个大核（14.2× 余量），
VP9 / AV1 分别为 6.3× / 7.5× —— 1080p 属"余量充足"。详见
../../docs/software-video-decode.md。

可复现的探针工具见 tools/pas-probe/，
Windows 侧接口逆向记录见 docs/windows-video-tz-interface.md。

实验记录与复现步骤见 patches/iris-el2/README.md。

变更

目标机的视频硬解单元是 Qualcomm IRIS (Gen1)，不是 Venus。基线内核以 CONFIG_VIDEO_QCOM_VENUS=m 配套一个 2023 年形态的 venus 设备树节点（compatible = "qcom,sm8350-venus"、iommus = <&apps_smmu 0x2e00 0x400>），启动时稳定报错：

qcom-venus aa00000.video-codec: error -22 initializing firmware qcom/sc8280xp/HUAWEI/gaokun3/qcvss8280.mbn
qcom-venus aa00000.video-codec: fail to load video firmware

本构建改用上游的 iris 方案：

项	基线	本构建
视频驱动	CONFIG_VIDEO_QCOM_VENUS=m	CONFIG_VIDEO_QCOM_IRIS=m，VENUS 关闭
视频设备树节点	venus: video-codec@aa00000，compatible = "qcom,sm8350-venus"，iommus = 0x2e00，缺 mmcx 电源域	iris: video-codec@aa00000，compatible = "qcom,sc8280xp-iris", "qcom,sm8250-venus"，iommus = 0x2a00，含 mmcx
视频固件	设备树 firmware-name = qcom/sc8280xp/HUAWEI/gaokun3/qcvss8280.mbn	不变。IRIS 的 sm8250_data.fwname 指向已被 linux-firmware 删除的 qcom/vpu-1.0/venus.mbn，必须由设备树覆盖
LOCALVERSION	-gaokun3-el2	-aoripus-ml-gaokun-eog-iris-el2

其余部分与基线一致：补丁集、DTS、defconfig 与配置项均未改动，仅跳过了 patches/media/（该目录下 6 个补丁针对 venus 方案，与本构建冲突）。

产物

SHA-256 列为前 16 位，完整值见 sha256sums.txt。

文件	说明	字节	SHA-256（前 16 位）
Image	内核映像（arm64，未压缩，供 systemd-boot 直接加载）	24,730,112	ca54a5bdb4611170
sc8280xp-huawei-gaokun3.dtb	标准设备树	170,694	337902cea29fa0ce
sc8280xp-huawei-gaokun3-el2.dtb	EL2 叠加变体，与当前运行的基线内核同构	170,967	b65aac1557a4198d
modules-7.2.0-rc2-aoripus-ml-gaokun-eog-iris-el2+.tar.zst	359 个内核模块，含 qcom-iris.ko	4,998,787	c201a89c3765d51b
config-7.2.0-rc2-aoripus-ml-gaokun-eog-iris-el2+	完整 .config	209,244	c37d7dc5083cda69
System.map-7.2.0-rc2-aoripus-ml-gaokun-eog-iris-el2+	符号表	4,706,864	e2947b981f627851
vmlinux-7.2.0-rc2-aoripus-ml-gaokun-eog-iris-el2+	未压缩 ELF，供调试	31,093,040	0b412ca788176c27
modules.builtin / modules.order	模块拓扑	9,823 / 10,456	e98dce0d217fe52e / e545381745c71052
modules.builtin.modinfo	内置模块元信息（供 modinfo 与内置模块固件查找使用）	118,595	f6c3be1c72eed3bf
BUILD-PROVENANCE.md	构建溯源与复现步骤（GPL-2.0 源码提供要求）	3,499	21c8ade36835b012
git-log-patched-tree.txt	打过补丁的源码树提交记录	1,269	97c43d106f7ea938
sha256sums.txt	全部产物的 SHA-256	1,076	bdd6602ee356f2d1

安装

产物未执行 modules_install，需要在目标机上手工落位。以下步骤在 GK-W7X 上实测通过。

基线镜像把内核交给 kernel-install 管理（/etc/kernel/install.conf 为 layout=bls，
条目名 <machine-id>-<内核 release 串>.conf），因此按同一机制生成条目最稳妥：

REL=7.2.0-rc2-aoripus-ml-gaokun-eog-iris-el2+
MACHINE=$(cat /etc/machine-id)
SRC=/var/tmp/iris-install          # 产物所在目录

# 1) 模块：包内路径相对于模块根，解到 /lib/modules/$REL
sudo mkdir -p "/lib/modules/$REL"
sudo tar --zstd -xf "$SRC/modules-$REL.tar.zst" -C "/lib/modules/$REL/"
sudo depmod -a "$REL"

# 2) 内核与设备树
#    90-loaderentry.install 会在若干前缀下查找 /etc/kernel/devicetree 指定的相对路径，
#    因此 DTB 必须落到 /usr/lib/modules/$REL/dtb/<相对路径>
sudo cp "$SRC/Image" "/boot/vmlinuz-$REL"
sudo mkdir -p "/usr/lib/modules/$REL/dtb/qcom"
sudo cp "$SRC/sc8280xp-huawei-gaokun3-el2.dtb" \
        "/usr/lib/modules/$REL/dtb/qcom/sc8280xp-huawei-gaokun3-el2.dtb"
sudo cp "$SRC/sc8280xp-huawei-gaokun3-el2.dtb" "/boot/dtb-$REL"
sudo cp "$SRC/config-$REL" "$SRC/System.map-$REL" /boot/

# 3) initrd：55-initrd.install 只把已存在的 /boot/initrd.img-$REL 链接进暂存区，
#    所以必须先自行生成，否则生成的条目里不会有 initrd
sudo update-initramfs -c -k "$REL"

# 4) 生成启动项（不动 loader.conf 的 default）
sudo kernel-install add "$REL" "/boot/vmlinuz-$REL"

# 5) 两条条目默认同名，改成可辨识的名字
sudo sed -i "s|^title .*|title      Ubuntu 26.04 LTS (IRIS 7.2.0-rc2)|" \
        "/boot/efi/loader/entries/$MACHINE-$REL.conf"

试启动与回滚

systemd-boot 支持 one-shot 条目：只启动一次，失败则下次开机自动回到原默认条目。
loader.conf 全程不必修改。

sudo bootctl set-oneshot "$MACHINE-$REL.conf"
sudo systemctl reboot

启动后核对：uname -r、dmesg | grep -iE 'iris|qcom_scm|q6v5_pas'、ls /dev/video*，以及触摸是否可用。

回滚即删除新增的这几处，基线内核不受影响：

sudo rm -rf "/boot/efi/$MACHINE/$REL"
sudo rm -f  "/boot/efi/loader/entries/$MACHINE-$REL.conf"
sudo rm -rf "/lib/modules/$REL" "/usr/lib/modules/$REL/dtb"
sudo rm -f  /boot/vmlinuz-$REL /boot/dtb-$REL /boot/config-$REL /boot/System.map-$REL /boot/initrd.img-$REL

完整的构建与安装说明见 docs/build-kernel-iris.md。

校验

sha256sum -c sha256sums.txt

复现

源码来源、补丁集、设备树改动与完整构建命令记录在随包 BUILD-PROVENANCE.md，摘要如下：

• 上游源码：torvalds/linux tag v7.2-rc2（git.kernel.org 快照）
• 补丁集：KawaiiHachimi/linux-gaokun-buildbot 的 patches/upstream、patches/others、patches/0099-*、patches/el2（patches/media 跳过）
• 设备树前置处理：本仓库 tools/gaokun-iris-dts-prep.py
• 上游 IRIS 节点来源：3a52eef16b979617156fa6e2ead24ca4d1336f0b、595eb4144f2ecc58e8e56e07ae94407b5a696031（v7.3-rc1 起）
• 构建机：Debian 12 x86_64，aarch64-linux-gnu-gcc 12.2.0，-j16，耗时约 6 分钟

许可

内核为 GPL-2.0。...