# 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_PARAMS` IPC 失败、约 -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 行为」。

---

## 三、自定义内核相关：避免「假阴性」

在继续改内核前，建议先确认实验条件可靠（否则会出现「补丁无效」误判）：

1. **确已启动自编镜像**：`dpkg -l | grep linux-image | grep 6.17.0-19` 应为 **`linux-image-unsigned-...`**，而非仍占位的官方 **`linux-image-6.17.0-19-generic`**（二者互斥，易只装上 modules）。见安装文档第 2.1 节。
2. **模块包装全**：至少 **`linux-modules` + `linux-modules-extra`**，Intel 无线常见还需 **`linux-modules-iwlwifi-*`**；否则会出现 **WiFi 消失** 等与 HDMI 无关的干扰。见 `OPERATION_Install_CustomKernel_Ubuntu_HWE617.md`。
3. **用户态与物理口**：`aplay -L` 列出所有 HDMI 类设备后，对 **每个候选 `plughw:卡,设备`** 做 `speaker-test`；系统设置里默认输出勿锁死在错误 sink。

---

## 四、推荐修复路径（按性价比重排）

下列顺序在 **不推翻已有结论** 的前提下，把精力集中到最可能见效的方向。

### 1. 基线采集（每次改内核/固件前后各做一次）

- `uname -a`、`/proc/version`
- `aplay -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](https://github.com/thesofproject/sof)、alsa-devel

### 5. 仍可调参但预期有限的项

- **SOF / 模块参数**（`snd_sof`/`snd_sof_intel_hda` 等 debug、probe 顺序）：多用于佐证，不一定能「一键修好」。
- **PipeWire / PulseAudio 配置**：在 IPC -5 已出现在 dmesg 时，**通常不是根因**，但应用层默认 sink 选错会造成「以为完全没声」。

---

## 五、结论摘要（给决策用）

```mermaid
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`](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 冲突等坑。

---

<a id="appendix-ubuntu-515"></a>

## 附录：找不到「带 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**，进系统先执行：

```bash
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 等）的前提下：

```bash
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 显示为准），然后：

```bash
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 做完才报上游）：
  1. **上游**：用 **6.17.0-20** + Kaisa + Coreboot +「ChromeOS 同机 HDMI 正常」打 **SOF/ALSA** issue 或邮件列表（材料见第四节）。
  2. **内核 diff**：在本地对 **ChromiumOS 5.15 树** 做 **有范围的 git 历史 / 文件 diff**（见 7.2），找 **与 SOF / Intel / HDMI / CML / rt5682** 相关的提交，再判断能否 **移植到 6.17** 或交给上游。

### 7.2 查看 ChromeOS **内核**里与音频相关的定制（推荐流程）

ChromeOS 内核通常是 **v5.15 + 大量提交**；不要指望「一个补丁文件」解决问题，应 **缩小目录 + 看提交说明**。

1. **拿到树**（见 `docs/WORK_PROGRESS.md` 第二节），例如本仓库 `chromiumos_kernel/v5.15/`，分支如 `release-R144-16503.B-chromeos-5.15`。

2. **操作清单与三文件 diff 导出**：[`docs/OPERATION_ChromeOS_Kernel_Deep_Diff.md`](OPERATION_ChromeOS_Kernel_Deep_Diff.md)（`git fetch --unshallow`、`git log`、`diff` / `export-chromeos-ubuntu-sound-file-diffs.sh`）。
3. **自动对照摘要**（本机可跑）：[`docs/CHROMEOS_vs_UBUNTU617_SOUND_AUTODIFF.md`](CHROMEOS_vs_UBUNTU617_SOUND_AUTODIFF.md)。随时重跑：

   ```bash
   ./scripts/diff-chromeos-ubuntu-sound.sh
   ```

4. **只看音频相关路径上的提交**（需 **非浅克隆** 的 ChromeOS 树，见 OPERATION / AUTODIFF 文档）：

   ```bash
   cd chromiumos_kernel/v5.15
   git log --oneline -50 -- sound/soc/sof sound/soc/intel include/sound
   git log --oneline -30 -- drivers/soundwire
   ```

   若提交太多，可加关键字过滤（效果因提交说明写法而异）：

   ```bash
   git log --oneline --grep=sof -- sound/soc/
   git log --oneline --grep=hdmi -i -- sound/
   ```

5. **与 Ubuntu 6.17 做「同文件 diff」**（你们已对 `sof_board_helpers.c` 做过；应扩展到 **整段 SOF Intel 链路**）。示例（把路径换成你本机仓库根下的实际位置）：

   ```bash
   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 绑定代码

6. **若有上游 5.15 tag**：可尝试找 ChromeOS 分支与 **linux v5.15.x** 的基线，再列「仅 ChromeOS 多出来的提交」（不同团队合并策略不同，**不一定**有干净 merge-base；若 `git merge-base` 不合理，就以 **按路径 `git log`** 为主）。

7. **别忽略用户态**：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** 还是 **交给上游**。