17 KiB
Kaisa（Chromebox 10 代）Linux HDMI 音频：重新分析与修复路径
本文在已有采集与对照结论基础上，合并真机后续结果（含：自编 HWE 6.17、历史 HDMI 补丁实验、安装方式与 WiFi 回归等），重新整理「问题是什么、什么已基本排除、下一步该怎么试」。
仍请以以下为权威细节：
- 三平台对比与 dmesg：
audio_topology/ANALYSIS_Audio.md - 总修复顺序与文档索引：
audio_topology/REPAIR_Plan_Audio.md - ChromeOS 5.15 与 6.17 API 对照：
docs/CHROMEOS_VS_UBUNTU_HDMI_NOTES.md - ChromeOS 树深度 diff / 新补丁设计入口：
docs/OPERATION_ChromeOS_Kernel_Deep_Diff.md - 自编内核安装（含 signed 冲突、modules-extra / iwlwifi）：
docs/OPERATION_Install_CustomKernel_Ubuntu_HWE617.md
一、现象（Linux 侧）
- 机器：Google Kaisa，Coreboot 环境；声卡为 SOF +
sof-rt5682一类拓扑，HDMI 走 iDisp / DisplayPort 音频 链路。 - 3.5mm：Linux 上通常 正常。
- HDMI：Linux 上 无输出或无法稳定打开 PCM；历史 dmesg 典型为
STREAM_PCM_PARAMSIPC 失败、约 -5（EIO），常与 pcm2/3/4（HDMI1/2/3） 中某几条相关（物理口与 pcm 编号需实测对照）。 - 对照：同机 ChromeOS（5.15 内核）HDMI 正常；Windows HDMI 正常。说明硬件与显示器链路整体可用，问题集中在 Linux 内核/SOF/用户态路由，而非「线坏了」一类。
二、已基本排除或证明「单独不够」的方向
| 方向 | 结论 | 依据（仓库内） |
|---|---|---|
| 拓扑 tplg | 与 ChromeOS 等效（解压后规模一致、端点一致） | ANALYSIS_Audio.md 第四节、第五节 |
| 仅换 SOF 固件（intel-signed ↔ community） | 不能单独恢复 HDMI；还可能影响 3.5mm 插拔检测 | WORK_PROGRESS.md、ANALYSIS_Audio.md 第五节、OPERATION_Force_Intel_Signed_Firmware.md |
| NHLT 缺失 | 不是根因（ChromeOS 也无 NHLT 仍正常） | ANALYSIS_Audio.md 第六节 |
旧 0002 补丁（set_idisp_hdmi_link 里 SND_SOC_DPCM_TRIGGER_POST） |
真机验证仍无 HDMI 声；补丁已从仓库删除，不再维护 | 见 CHROMEOS_VS_UBUNTU_HDMI_NOTES.md、patches/ubuntu-hwe-6.17/DIFF_SUMMARY.txt |
Ubuntu Mainline 5.15（例：v5.15.201 deb 装在 Noble 上） |
HDMI 仍无声；且相对 6.17 3.5mm 也无声、WiFi 也无（整体音频/无线栈退化） | 真机反馈（jack-Kaisa）；见下文 「Mainline 5.15 ≠ ChromeOS 5.15」 |
重要区分：ChromeOS 上正常的「5.15」 是 Google 定制内核 + CRAS + 其配置/补丁；Ubuntu Mainline 的 5.15 是 Vanilla 主线 + 与 Noble 用户态/固件/模块集合的组合，二者不能等同。因此在 Mainline 5.15 上「HDMI 仍坏 + 其它输出也坏」并不能推翻「发行版 6.x 相对某条 Ubuntu/Chrome 5.15 路径在 HDMI 上存在差异」这类判断，只能说明 单靠换 Mainline 5.15 deb 不是可行修复手段。
推论（修订）：HDMI 仍优先从 6.x 下 SOF / Intel / DPCM / iDisp 与 Kaisa + Coreboot 的交互继续查（含上游报 bug、bisect Ubuntu 或上游 linux.git）；不要把「装了 Mainline 5.15」误认为「复现了 ChromeOS 5.15 行为」。
三、自定义内核相关：避免「假阴性」
在继续改内核前，建议先确认实验条件可靠（否则会出现「补丁无效」误判）：
- 确已启动自编镜像：
dpkg -l | grep linux-image | grep 6.17.0-19应为linux-image-unsigned-...，而非仍占位的官方linux-image-6.17.0-19-generic（二者互斥，易只装上 modules）。见安装文档第 2.1 节。 - 模块包装全：至少
linux-modules+linux-modules-extra，Intel 无线常见还需linux-modules-iwlwifi-*；否则会出现 WiFi 消失 等与 HDMI 无关的干扰。见OPERATION_Install_CustomKernel_Ubuntu_HWE617.md。 - 用户态与物理口：
aplay -L列出所有 HDMI 类设备后，对 每个候选plughw:卡,设备做speaker-test；系统设置里默认输出勿锁死在错误 sink。
四、推荐修复路径（按性价比重排）
下列顺序在 不推翻已有结论 的前提下，把精力集中到最可能见效的方向。
1. 基线采集（每次改内核/固件前后各做一次）
uname -a、/proc/versionaplay -L（保留 HDMI 相关行）sudo dmesg | grep -iE 'sof|STREAM_PCM|ipc failed|pcm[0-9]|ASoC|iDisp|hdmi'（尾部 80～120 行即可）- 可选：
alsa-info导出一份文本 - 可选（
STREAM_PCM_PARAMS深度）：按docs/OPERATION_Kaisa_SOF_HDMI_Trace.md开启sof_debug=0x800与 dynamic_debug，将带 IPC 载荷的 dmesg 放入audio_topology/collected/（见同目录README_TRACE_KAISA.md）。
输出放入 audio_topology/collected/，文件名带日期与内核版本，便于 diff。
2. 用 5.15 环境 做对照时，必须分清「哪一种 5.15」
已证阴性（真机）：在 Ubuntu 24.04 上安装 kernel.ubuntu.com Mainline 的 v5.15.201 deb 后，HDMI 仍无声，且 3.5mm、WiFi 也异常。结论：不要把 Mainline 5.15 当作日常或「验证 ChromeOS 行为」的手段；装完若无法使用，请 GRUB 切回 6.17（并确保 linux-modules + extra + iwlwifi 装全，见安装文档）。
若仍想做 「与 6.x 对比的 5.15」，只剩 更接近 Ubuntu 完整栈 的方式才有对照意义（仍不保证 HDMI 会好，但不会出现「整台机音频+无线全挂」这种明显栈不完整的情况）：
- Ubuntu 22.04.1 / 22.04.2 Live ISO（
old-releases），启动后uname -r确认为5.15.0-…-generic，再测 HDMI / 3.5mm（见ANALYSIS_Audio.md第六节）。 - 与 ChromeOS 对齐：只能以 ChromiumOS 内核树 / 真机 ChromeOS 为参照，而不是 Mainline tarball 内核。
若 Ubuntu 5.15 Live 下 HDMI 仍失败：说明问题不一定是「6.x 独有」，可能是 Coreboot 下通用 Linux + 某类 SOF 拓扑 与 CRAS/Chrome 栈 的差异，更适合走 上游 issue + dmesg/alsa-info，而不是继续换 Mainline 版本号。
3. 内核级深度对照（开发者路径）
在确认要攻 6.x 的前提下：
- 对照树：
chromiumos_kernel/v5.15/...与kernel-src/linux-hwe-6.17-6.17.0/... - 优先目录：
sound/soc/sof/、sound/soc/intel/boards/、sound/soc/intel/common/、与 HDMI HDA/iDisp 相关的 machine 选择与 DPCM 配置。 - 方法：从
STREAM_PCM_PARAMS/hw_params调用栈出发，在 6.17 上加dynamic_debug或局部pr_debug，对照 5.15 上同类路径；必要时 git bisect 主线内核。
4. 上游协同（与 3 并行）
向 SOF / ALSA 社区提交最小复现包：
- 机型：Google Kaisa、Coreboot、Ubuntu 版本、内核精确版本
- 完整 dmesg、alsa-info
- 说明：ChromeOS 5.15 同硬件 HDMI 正常、Linux 6.x
STREAM_PCM_PARAMS -5 - 入口：thesofproject/sof、alsa-devel
5. 仍可调参但预期有限的项
- SOF / 模块参数（
snd_sof/snd_sof_intel_hda等 debug、probe 顺序）：多用于佐证，不一定能「一键修好」。 - PipeWire / PulseAudio 配置：在 IPC -5 已出现在 dmesg 时，通常不是根因，但应用层默认 sink 选错会造成「以为完全没声」。
五、结论摘要（给决策用）
flowchart LR
unshallow[git_unshallow]
log[git_log_sound]
diff3[diff_ipc3_pcm_hda_dai]
hypothesis[minimal_hypothesis]
newpatch[new_patch]
smoke[make_objects]
deb[binary_generic]
unshallow --> log --> diff3 --> hypothesis --> newpatch --> smoke --> deb
- HDMI 问题性质：更可能是 Linux（尤其 6.x 发行版栈）里 SOF/Intel/iDisp 路径与 Kaisa + Coreboot 的组合问题；拓扑与「只换一份 SOF 固件」已反复证明不够。
- 旧 0001/0002：已自仓库移除；新补丁按
OPERATION_ChromeOS_Kernel_Deep_Diff.md流程重做。 - Mainline 5.15 deb：在 Kaisa 上 阴性且引入 3.5mm/WiFi 回归；不推荐继续折腾 Mainline 5.15。若已安装：用 GRUB 回到 6.17，日常以 完整 HWE 模块包 为准。
- 仍值得做的对照（可选、工作量更大）：Ubuntu 22.04 早期 Live 的 5.15.0-xx-generic（非 Mainline），或直接把材料交给 SOF/ALSA 上游；bisect 建议在 linux.git 或 Ubuntu 同源 上进行，而非混用 Noble + Mainline 老内核。
- 自编 6.17：务必 unsigned（若用）+ modules + extra（+ iwlwifi） 装全，并保留可启动旧内核。
六、文档维护建议
若你完成 5.15 Live 或 上游 issue 链接，可把结果摘要回写到 audio_topology/ANALYSIS_Audio.md（新增一小节）与 docs/WORK_PROGRESS.md 状态表，避免后人重复踩旧实验补丁/仅装两 deb/unsigned 冲突等坑。
附录：找不到「带 5.15 的 Ubuntu」时怎么办
很多人只在 https://releases.ubuntu.com/22.04/ 下 ISO，那里永远是当前 point release（例如 22.04.5），往往已是 HWE 6.x，Live 起来 uname -r 不是 5.15，这是正常现象，不是「Ubuntu 没有 5.15」。
A. 旧版 Ubuntu 22.04 ISO（推荐做 Live 验证）
到 old-releases 找 22.04.1 / 22.04.2 的 desktop amd64（发布时主线内核多为 5.15；仍请以启动后 uname -r 为准）：
- 22.04.1 目录：https://old-releases.ubuntu.com/releases/22.04.1/
- 22.04.2 目录：https://old-releases.ubuntu.com/releases/22.04.2/
- 上一级索引：https://old-releases.ubuntu.com/releases/22.04/
文件名通常为 ubuntu-22.04.1-desktop-amd64.iso 或 ubuntu-22.04.2-desktop-amd64.iso。下载后写入 U 盘，Try Ubuntu，进系统先执行：
uname -r
只有显示 5.15.0-…-generic 才说明本次 Live 符合「5.15 验证」前提；若是 5.19 / 6.x，换更旧的 point release ISO 或改用下文 B/C。
B. 在已安装的 Ubuntu 上装 Mainline 5.15（不必找老 ISO）
真机结论（Kaisa / Noble）：Mainline
v5.15.201已验证 HDMI 仍无声，且 3.5mm、WiFi 也异常（相对 6.17 HWE 全量模块栈明显退化）。不建议在主力机上长期停留于 Mainline 5.15；下列步骤仅作「如何安装」记录，决策上请优先 GRUB 回退 6.17。
Ubuntu 提供的 Mainline 构建（Vanilla 主线内核 deb，不是完整 Ubuntu 补丁集，也不等于 ChromeOS 5.15；与 Ubuntu 22.04 自带的 5.15.0-xx-generic 也不是同一套配置/模块切分）：
- 目录索引：https://kernel.ubuntu.com/~kernel-ppa/mainline/
- 在页面中进入
v5.15.x/（选最新的 5.15 末版即可，例如v5.15.201/，以你打开页面时为准）。 - 浏览器里列出的 deb 一般在
…/v5.15.201/amd64/（若目录结构不同，以该版本页实际链接为准）。
v5.15.201 目录内典型 4 个 deb（与你看到的文件列表一致）：
| 文件 | 作用 |
|---|---|
linux-headers-5.15.201-0515201_5.15.201-0515201.*_all.deb |
头文件（all） |
linux-headers-5.15.201-0515201-generic_5.15.201-0515201.*_amd64.deb |
头文件（generic） |
linux-image-unsigned-5.15.201-0515201-generic_5.15.201-0515201.*_amd64.deb |
内核镜像（未签名） |
linux-modules-5.15.201-0515201-generic_5.15.201-0515201.*_amd64.deb |
内核模块 |
最少：linux-image-unsigned-*-generic_*_amd64.deb + linux-modules-*-generic_*_amd64.deb。建议 4 个全下，再一次性安装，避免头文件依赖提示、并方便 DKMS。
在 保留当前可启动内核（GRUB 里能进 6.17 等）的前提下：
cd ~/下载/mainline-5.15.201 # deb 所在目录，自行改名
sudo dpkg -i \
linux-headers-5.15.201-0515201_*.deb \
linux-headers-5.15.201-0515201-generic_*.deb \
linux-image-unsigned-5.15.201-0515201-generic_*.deb \
linux-modules-5.15.201-0515201-generic_*.deb
sudo apt-get install -f
sudo update-grub
sudo reboot
重启 → Advanced options for Ubuntu → 选 5.15.201-0515201-generic（以 GRUB 显示为准），然后：
uname -r
# 期望含 5.15.201-0515201-generic
说明：
- Mainline 通常没有 Ubuntu HWE 那种
linux-modules-extra/linux-modules-iwlwifi分包；多数驱动在linux-modules-…一体包里。 linux-image-unsigned：开启 Secure Boot 时可能无法启动，需关闭或参考docs/OPERATION_Install_CustomKernel_Ubuntu_HWE617.md。- 务必留好旧内核，以便 GRUB 切回 6.x。
C. 其它带 5.15 的 Live（备选）
例如 Linux Mint 21.x（基于 22.04，早期版本默认 5.15 内核）的 Cinnamon ISO；启动后同样先 uname -r 确认 再测 HDMI。
D. 验证成功的判据
- 目标：在 确认 5.15 的前提下，
speaker-test或系统声音能在 HDMI sink 上出声，且 dmesg 中 不再出现（或明显减少）STREAM_PCM_PARAMS/ipc failed一类错误。 - 把
uname -a、aplay -L、dmesg 片段 存进audio_topology/collected/便于与 6.17 对比。
七、当前在 6.17.0-20-generic 上的建议 + 如何查 ChromeOS 定制补丁
7.1 对「jack-Kaisa @ 6.17.0-20」的优先级建议
- 这是合理的主力内核：官方 signed HWE，模块栈与 Noble 用户态匹配，比自编 unsigned / Mainline 5.15 更适合日常与排障。
- 先固定一条基线：在本内核上再采一份
dmesg（SOF/HDMI 段）、aplay -L、alsa-info，命名带6.17.0-20，放进audio_topology/collected/，与旧版 6.17.0-14/19 对比是否 IPC 行号/PCM 编号 有变化。 - 并行两条线（不必等 ChromeOS diff 做完才报上游）：
- 上游：用 6.17.0-20 + Kaisa + Coreboot +「ChromeOS 同机 HDMI 正常」打 SOF/ALSA issue 或邮件列表（材料见第四节）。
- 内核 diff：在本地对 ChromiumOS 5.15 树 做 有范围的 git 历史 / 文件 diff（见 7.2），找 与 SOF / Intel / HDMI / CML / rt5682 相关的提交，再判断能否 移植到 6.17 或交给上游。
7.2 查看 ChromeOS 内核里与音频相关的定制（推荐流程）
ChromeOS 内核通常是 v5.15 + 大量提交；不要指望「一个补丁文件」解决问题，应 缩小目录 + 看提交说明。
-
拿到树（见
docs/WORK_PROGRESS.md第二节），例如本仓库chromiumos_kernel/v5.15/，分支如release-R144-16503.B-chromeos-5.15。 -
操作清单与三文件 diff 导出：
docs/OPERATION_ChromeOS_Kernel_Deep_Diff.md（git fetch --unshallow、git log、diff/export-chromeos-ubuntu-sound-file-diffs.sh）。 -
自动对照摘要（本机可跑）：
docs/CHROMEOS_vs_UBUNTU617_SOUND_AUTODIFF.md。随时重跑：./scripts/diff-chromeos-ubuntu-sound.sh -
只看音频相关路径上的提交（需 非浅克隆 的 ChromeOS 树，见 OPERATION / AUTODIFF 文档）：
cd chromiumos_kernel/v5.15 git log --oneline -50 -- sound/soc/sof sound/soc/intel include/sound git log --oneline -30 -- drivers/soundwire若提交太多，可加关键字过滤（效果因提交说明写法而异）：
git log --oneline --grep=sof -- sound/soc/ git log --oneline --grep=hdmi -i -- sound/ -
与 Ubuntu 6.17 做「同文件 diff」（你们已对
sof_board_helpers.c做过；应扩展到 整段 SOF Intel 链路）。示例（把路径换成你本机仓库根下的实际位置）：diff -u \ chromiumos_kernel/v5.15/sound/soc/sof/intel/some_file.c \ kernel-src/linux-hwe-6.17-6.17.0/sound/soc/sof/intel/some_file.c常用对照目录（两棵树各扫一遍）：
sound/soc/sof/（含intel/、ipc/）sound/soc/intel/boards/（machine、sof_rt5682、helpers）sound/soc/intel/common/（如有）- 与 HDA/display 绑定的
sound/soc/intel/hda/或相关 HDMI 绑定代码
-
若有上游 5.15 tag：可尝试找 ChromeOS 分支与 linux v5.15.x 的基线，再列「仅 ChromeOS 多出来的提交」（不同团队合并策略不同，不一定有干净 merge-base；若
git merge-base不合理，就以 按路径git log为主）。 -
别忽略用户态：ChromeOS 上播放经 CRAS，可能有 重试 / 设备选择 / 延迟打开 等与 PipeWire 不同；内核 diff 找不到差异时，仍可能出现「同内核逻辑在 CRAS 下正常、在 PW 下触发竞态」。这更支持 上游 + 双栈对比日志，而不是无限改 tplg。
7.3 预期与边界
- 看到 Chrome 的补丁 ≠ 能直接 cherry-pick 到 6.17：API（如
playback_only/trigger[]）已变，需 移植或重写。 - 最有价值：找到 与
STREAM_PCM_PARAMS/hw_params/ iDisp BE 直接相关的提交或函数级差异，再在 6.17 上 最小复现 + dynamic_debug 验证。
若你在 git log 里筛出少量可疑 commit hash，可贴出 hash + 标题，便于判断下一步是 port 还是 交给上游。