# 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`](./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「先诊断后方案」原则。*