jack/chromebox_10th_audio_driver
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
dbb11f290d65c3b3c07fa73ca927dce46ec4591c
chromebox_10th_audio_driver/_bmad-output/problem-solution-2026-04-04-linux-hdmi-kaisa.md
jack c8713b8927 日常更新
2026-04-05 04:34:42 +08:00

11 KiB
Raw Blame History

Problem Solving Session: Linux HDMI 无输出（Google Kaisa / SOF）

日期： 2026-04-04
问题推进人： Jack
问题类别： 硬件-固件-内核栈交互 / 嵌入式音频（SOF + DisplayPort/iDisp HDMI）

问题界定

初始描述

在刷 Coreboot 的 **Google Kaisa（Chromebox 10 代）**上，Linux 下 HDMI 无声音（或无法稳定打开播放设备）；同机 ChromeOS / Windows 下 HDMI 正常。3.5mm 在 Linux 上通常正常。

精炼问题陈述

在 Linux + SOF + Intel HDA/iDisp 路径上，对 HDMI 相关 PCM 执行 hw_params 时，DSP 侧拒绝 STREAM_PCM_PARAMS（IPC 0x60010000）并返回约 -5（EIO），导致用户态无法完成 HDMI 音频播放；问题集中在 内核/固件 IPC 与机器拓扑的交互，而非显示器或线缆物理损坏。

问题背景（已知事实）

  • 声卡呈现：sof-rt5682，ALSA 可见 HDMI1/2/3（device 2/3/4）；播放测试时内核报 pcm4 (HDMI3) 等与 STREAM_PCM_PARAMS 失败 相关日志（物理口与 PCM 编号需对照，DPCM 下可能出现「选 HDMI1 却落在某条后端 PCM」的情况）。
  • 内核日志特征：ipc tx error for 0x60010000 (msg/reply size: 108/20): -5，sof_ipc3_pcm_hw_params: ... STREAM_PCM_PARAMS ipc failed。
  • 发行版：Ubuntu Noble + HWE 6.17.0-20 上现象仍存在（与早期 6.14 观察一致）。
  • 仓库内已弱化方向：单独换 tplg、单独换 intel-signed/community SOF 固件、已删除的旧 iDisp trigger 补丁、Ubuntu Mainline 5.15 deb 等（见 docs/linux-hdmi/Linux_HDMI_Audio_Roadmap.md）。

成功标准（可验证）

  • 客观：目标 HDMI 口播放时，与本次播放相关的 STREAM_PCM_PARAMS / ipc tx error 消失或可被证明无害。
  • 主观：显示器扬声器/耳机有稳定输出。
  • 回归：3.5mm、WiFi 等不因验证手段（自编内核、模块包）意外损坏。

诊断与边界（Is / Is Not）

维度 是（问题发生侧） 否（已排除或对照）
平台 Linux（Ubuntu HWE 6.17 等） 同机 ChromeOS、Windows HDMI 正常 → 非「整机声卡坏了」
输出形态 HDMI / DisplayPort 音频（iDisp 链路） 3.5mm 常正常 → 非 codec 模拟输出整条死
失败阶段 hw_params / STREAM_PCM_PARAMS（打开流参数阶段） 非单纯 PulseWire/PipeWire 选错 sink 即可解释（dmesg 已有 IPC -5）
根因层级 内核 SOF 驱动与 固件拓扑内 DSP 行为 的 IPC 契约 非「仅缺 NHLT」一类（仓库分析：ChromeOS 无 NHLT 仍可 HDMI）
单靠用户态 难以绕过内核 IPC 失败 用户态只能在 IPC 成功后做路由

模式：失败稳定复现于 打开 HDMI PCM，与 ChromeOS 5.15 + 定制栈 行为不一致 → 差异在 Linux 6.x 发行版内核 + SOF 路径与 Kaisa/Coreboot 组合。

根因分析（症状 → 机制）

直接症状

  • 用户态：speaker-test / 播放器报 无法完成格式协商或「错误的地址」类错误（与驱动返回错误一致）。
  • 内核：0x60010000 类 IPC tx error -5，HW params ipc failed。

机制链（简化）

  1. ALSA 打开 HDMI 前端 PCM → DPCM 落到 SOF 侧对应流/stream_tag。
  2. 驱动向 DSP 发送 STREAM_PCM_PARAMS（缓冲、格式、速率、通道等）。
  3. DSP/固件拒绝该组参数或当前状态下不允许该流 → 回复错误 → 驱动返回 -EIO。

根因层级判断

  • 不是「显示器没接好」：多系统对照已否定。
  • 不是「Linux 完全没驱动」：设备节点与 SOF 加载存在，失败点在 参数协商。
  • 更可能根因区：下列之一或组合（需证据排序）：
    1. 固件侧：该 HDMI 流在当拓扑/状态下不接受当前参数集（格式、stream tag、与 iDisp 联动时序）。
    2. 内核侧：与 ChromiumOS 5.15 相比，ipc3-pcm / Intel HDA DAI / machine 板级 在 hw_params、流分配、iDisp 绑定 上存在差异，导致下发载荷或顺序与固件预期不一致。
    3. Coreboot/ACPI：影响较小但仍可能参与 display audio 枚举与路由（优先级低于已观测到的明确 IPC 失败）。

与仓库补丁的关系

  • 0001（FREE/trigger）：对齐 Chrome 的 另一段 IPC 路径，不修改 STREAM_PCM_PARAMS 发送内容；不能假定单独解决 HDMI hw_params -5。
  • 0002：诊断用字段打印，不改载荷，用于对比 Chrome 与 6.17 的字段差异。

关键洞察

  1. 问题类型是「契约失败」：Linux 发出的 STREAM_PCM_PARAMS 与 当前 SOF 固件 + 拓扑 期望不匹配或时机不对，而非「没有 HDMI 设备」。
  2. 对照黄金标准应是 ChromiumOS 内核树 + 同机 trace，而非 Ubuntu Mainline 5.15 tarball。
  3. 验证任何内核补丁必须 unsigned 镜像与模块同源 且装全 modules / extra / iwlwifi，否则易误判。

对策方向（不按耗时排序）

A. 证据强化（低成本、应优先）

  • 按 docs/linux-hdmi/OPERATION_Kaisa_SOF_HDMI_Trace.md 打开 sof_debug（含载荷） 与 dynamic_debug，保留一次 HDMI 播放失败前后 的完整 dmesg。
  • 对 每个 HDMI device 2/3/4 各做一次最短 speaker-test，标注 物理接线口 ↔ ALSA 设备号。

B. 内核差异（中高成本、对准根因）

  • ChromiumOS 5.15 与 Ubuntu 6.17 在 sound/soc/sof/ipc3-pcm.c、pcm.c、intel/hda-dai.c 及 Kaisa 相关 machine 上 git / 导出 diff（脚本见 scripts/export-chromeos-ubuntu-sound-file-diffs.sh）。
  • 针对 STREAM_PCM_PARAMS 载荷字段 做 逐字段对照（patches/ubuntu-hwe-6.17/STREAM_PCM_PARAMS_CHROME_UBUNTU_NOTES.md）。

C. 补丁与验证

  • 在 与运行内核一致的 HWE 源码（如 6.17.0-20）上打 0001/0002，完整构建 binary-generic，安装 unsigned + 全套模块 后复测 HDMI。
  • 若仍 -5：在 B 的结论上写 最小行为改变补丁（例如仅调整与 Chrome 一致的参数顺序/约束），再跑同样验证。

D. 上游与并行路径

  • 按 docs/linux-hdmi/UPSTREAM_SOF_Kaisa_HDMI_REPRO.md 打包 alsa-info + dmesg + 版本信息，投递 SOF / ALSA，避免长期闭门造车。

力场简析（驱动力 / 阻力）

驱动力 阻力
现象与日志明确，可复现 IPC 与固件黑盒，需 trace/diff
仓库已有路线图与脚本 全量内核构建磁盘与时间占用大
ChromeOS 证明硬件链路可行 与 Ubuntu 栈差异需耐心对齐

约束

  • Secure Boot：自编 linux-image-unsigned 可能需关闭或自行签名。
  • 与官方 signed 同 ABI 包冲突：需按 docs/kernel-build/OPERATION_Install_CustomKernel_Ubuntu_HWE617.md 处理。
  • 勿用 Mainline 5.15 deb 代替「ChromeOS 行为」（仓库已记录回归）。

建议的下一步（单选一条深入即可）

  1. 采集带 IPC 载荷的 trace（A） — 已完成（见下 A 续）。
  2. 导出 Chrome vs 6.17 关键文件 diff（B） — 已执行。
  3. 在 6.17.0-20 源码上完整构建并安装带 0001/0002 的内核（C）— 首次失败；CONCURRENCY_LEVEL=4 重试 见下 C（日志 full-build-620-j4.log）。

A/B/C 执行记录（2026-04-04）

A — Trace

  • 已安装 /etc/modprobe.d/sof-ipc-payload.conf（sof_debug=0x800），需重启后载荷才会进 dmesg。
  • 已运行 scripts/collect-kaisa-sof-trace.sh（dynamic_debug +p）。
  • 已保存：audio_topology/collected/dmesg_sof_TRACE_AB_stepA_6.17.0-20-generic_20260404_210012.txt（含 ipc tx: 0x60010000、pcm2 (HDMI1)、iDisp1 等；重启前 sof_debug 仍为 0）。

B — Chrome vs Ubuntu diff

  • 已运行 scripts/preflight-chromeos-ubuntu-diff.sh（统计 + 导出）。
  • patches/ubuntu-hwe-6.17/reference/：ipc3.c、pcm.c、hda-dai.c 的 unified diff 已按当前 kernel-src/linux-hwe-6.17-6.17.0（6.17.0-20） 重导；另有人工增补的 diff-u_sound_soc_sof_ipc3-pcm.c.txt（约 170 行，此前基于 .19 树；若需与 .20 完全一致可在未打补丁的干净树上重导）。

C — 自编内核（6.17.0-20 + 0001 + 0002）

  • 已 apt-get source --download-only 补齐 linux-hwe-6.17_6.17.0-20.20~24.04.1.diff.gz。
  • 已解压 6.17.0-20 完整树；旧 6.17.0-19 树保留为 kernel-src/linux-hwe-6.17-6.17.0.bak-619-preserved-*。
  • 已 patch -p1 应用 0001、0002，make mrproper。
  • 首次后台 binary-generic 日志：kernel-src/full-build-620.log（失败：semop(1): Invalid argument / 高并行 make 中断，非 C 语法错误）。
  • 重试（低并行）：CONCURRENCY_LEVEL=4 下 fakeroot debian/rules clean && fakeroot debian/rules binary-generic，日志 kernel-src/full-build-620-j4.log，PID kernel-src/full-build-620-j4.pid。完成后 deb 在 kernel-src/；安装见 docs/kernel-build/OPERATION_Install_CustomKernel_Ubuntu_HWE617.md（unsigned、modules-extra / iwlwifi）。

A 续：带载荷 dmesg（已完成）

  • 文件：audio_topology/collected/dmesg_sof_TRACE_PAYLOAD_jack-Kaisa_6.17.0-20-generic_20260404_210954.txt
  • 摘要：0x60010000 后 100 字节 hex（不含 前 8 字节 sof_ipc_cmd_hdr）。字段与 struct sof_ipc_pcm_params 对齐后的要点：comp_id=0x14、48000 Hz、2 ch / stream_tag 1、no_stream_position=1、buffer phy/pages/size 合理；逐项解码表见 patches/ubuntu-hwe-6.17/STREAM_PCM_PARAMS_CHROME_UBUNTU_NOTES.md §5。

建议下一步

  1. 对照解码 — 已在 §5 落表；若需与 Chrome 树逐字段对比，可再在 未打补丁 的 .20 树上重导 ipc3-pcm.c diff。
  2. 等待 / 完成低并行 binary-generic，安装自编 deb 复测 HDMI。
  3. 仍无解则按 UPSTREAM_SOF_Kaisa_HDMI_REPRO.md 发上游。
  4. BP 后续三条用户故事（A 上游复现 / B 链路对照 / C 0001 A-B）：stories-hdmi-kaisa-bp-2026-04-04.md。

与 CIS 工作流的对照说明

本文件将 bmad-cis-problem-solving 的第 1–3 步（界定、边界、根因）与第 4–5 步（方案与验证方向）合并为一次交付，因上下文已在仓库与真机日志中大量存在。若你希望按模板 逐步互动（每步后选 [a]/[c]/[p]/[y]），可在新对话中指定从某一 <template-output> 续写。

生成说明：基于本仓库 docs/linux-hdmi/*、patches/ubuntu-hwe-6.17/* 及已观测 dmesg（0x60010000 / STREAM_PCM_PARAMS / -5）整理，符合 CIS「先诊断后方案」原则。

Reference in New Issue View Git Blame Copy Permalink