🩺 N100 真机黑屏 · 专家会诊

EOS 自研内核 N100 真机问题 — 全量事实与判别实验清单（版本 eos-0.2.1k，2026-09-15）

一、环境完整描述

项目	内容
目标机	Intel N100 小主机（Alder Lake-N），UEFI 启动，SecureBoot 已关闭，16GB 内存，核显 HDMI 输出，无独立串口（机箱无 COM 口，主板 COM 针脚未确认）
固件	AMI UEFI；核显 GOP 驱动版本 IGFX GOP 21.0.1050（BIOS 内可见）
启动介质	U 盘刻录 eos-0.2.1k.iso（历史版本问答记录,最新ISO见install页;0.2.1k含 /efi/boot/bootx64.efi GRUB 2.12 EFI 版 + El Torito BIOS 双启动）
操作步骤	插 U 盘 → 开机按启动菜单选 UEFI USB → 出现 GRUB 菜单（菜单文字渲染正常，说明显卡 GOP 在 GRUB 阶段工作）→ 选任一菜单项回车 → 立即黑屏
现象	三个菜单项（EFI GOP/multiboot2、text console safe、fallback keep）全部黑屏，现象一致；黑屏后无任何后续输出；尚未观察 NumLock 灯 / Ctrl+Alt+Del / 10 秒自动复位指纹等判别信号（见问题清单 Q1-Q3）
内核	EOS 0.2.1，自研 32 位 i386 ELF（21KB），Multiboot2 兼容（带合法 MB2 头），QEMU 下日志线确认能走到 "800x600@24bpp OK → boot complete → 10s 后自动复位指纹"

二、已试过的修复（两轮，均无效）

0.2.1jMB2 头 + framebuffer 请求：给内核补合法 Multiboot2 头并（声称）附带 framebuffer tag 请求 1024×768×32，改用 ELF 格式让 GRUB 原生加载。QEMU 双平台自测通过。真机：三菜单全黑，无变化。

0.2.1kVGA mode 0x13 兜底：在拿不到 GOP fb 时主动切 BIOS INT 10h mode 0x13（320×200×256 色）画彩虹条纹，意图绕开 GOP 依赖（所有 VGA 卡必支持）。真机：三菜单全黑，"跟之前一样的信息"，无变化。

⚠️ 关键后验事实（我们事后解包 0.2.1k ISO 发现）：ISO 内 kernel.elf 的 MB2 头是 24 字节最小头，不含任何 tag（framebuffer 请求 tag 实际缺失）——构建链在"源码修复→重新编译→打入 ISO"之间断了。即 0.2.1j 声称的 fb 请求在真机上从未存在过。

三、当前假设清单（附证据强度）

#	假设	支持证据	强度
H1	serial 死等自旋：内核第一动作是初始化 16550 UART 并 serial_puts 打印，send 前 `in 0x3FD & 0x20` 死等 THR 空位。N100 无 COM、LPC 上可能无 16550，`in` 返回 0 时 bit5=0 → 内核在第一条日志处无限自旋，CPU 活着但永远黑屏	可完整解释"三菜单全黑+两轮修复零变化"（兜底代码从未执行到）；QEMU 有模拟串口所以畅通	★★★★☆
H2	fb tag 修复未进 ISO（已实证缺失），真机上 GRUB 以当前 native GOP 模式交权，内核后续显示路径依赖的 fb 参数链路未按预期建立	解包实证 MB2 头无任何 tag；QEMU 里 GRUB 按 MB2 规范仍会自动提供当前 fb tag，掩盖了缺失	★★★★☆（缺失本身已实证）
H3	GRUB→内核交权瞬间显示切换失败：GRUB `terminal_output console` 切 GOP 图形控制台在 IGFX GOP 21.0.1050 上失败，黑屏发生在 GRUB 阶段而非内核	GRUB 菜单本身可见说明 GOP 初期正常；该 GOP 驱动版本行为已知特殊	★★★☆☆
H4	内核早期 triple fault / 异常重启循环	QEMU 同二进制正常；内核代码极简	★★☆☆☆
H5	磁盘/引导介质识别问题	内核是纯内存镜像，无 root 概念；与黑屏无逻辑通路	★☆☆☆☆

四、给专家的问题清单（按信息价值排序）

Q1. 黑屏后等 10 秒以上，机器会不会自己重启（我们的内核若跑通尾部会在约 10 秒打印后主动复位）？重启=内核基本跑通、纯显示问题；不重启且 NumLock 灯还能切换=CPU 活着但卡死（强烈支持 H1 串口自旋）；NumLock 也不响应=早期挂死。

Q2. 黑屏状态下 NumLock / CapsLock 灯能否切换？（判别"CPU 存活但自旋" vs "机器已死"的第一优先级现场信号，零成本）

Q3. 黑屏状态下 Ctrl+Alt+Del 是否触发重启？（键盘控制器/中断路径存活判据）

Q4. 显示器黑屏时输入源指示是什么状态：HDMI 掉信号（显示器提示无信号/进休眠）vs 有信号但全黑画面？（掉信号=发生过模式切换失败；有信号全黑=GPU 在输出但内容为空，指向更早）

Q5. 在 GRUB 菜单按 c 进命令行，手动逐条执行：`insmod efi_gop` → `terminal_output console`，观察哪一条命令后屏幕变化/黑？再 `multiboot2 /boot/kernel.elf` 后 `boot` 前用 `lsefi`、`videoinfo`（或 `insmod all_video; videoinfo`）记录 N100 上 GOP 实际可用模式列表——能否截屏/拍照回传？

Q6. N100 主板是否有 COM 针脚（即使无机箱接口）？若有，用 USB-TTL 接上，我们的内核会把日志打到 115200-8N1 COM1；同时 GRUB 也有 serial 模块（ISO 已带 serial.mod/efi_gop.mod 等）可以在 grub.cfg 加 `serial; terminal_output serial` 双路输出。这是最强诊断路径。

Q7. IGFX GOP 21.0.1050 是否有已知 bug：在 CSM 关闭+纯 UEFI 下，GOP SetMode 后 framebuffer 短暂或永久不可用/需要保持 UEFI GOP 控制台不被重置？有没有人见过 GRUB2 在该驱动上 `terminal_output console` 黑屏的案例？

Q8. GRUB 2.12 的 multiboot2 加载器在真机交权时，对"内核 MB2 头无 framebuffer tag"的处理：是保持当前 GOP 模式并在 tag 列表里附带当前 fb 信息，还是可能调用 ExitBootServices 后重置显示？我们观察到 QEMU/OVMF 是前者（附带了 800×600 fb tag），想知道真机是否存在不带 fb tag 的交权路径（那内核会走 0xB8000 文本分支——但 EFI 模式下 0xB8000 可能不可写/不显示，也可解释黑屏）。

Q9. N100（Alder Lake-N）UEFI 下，ExitBootServices 之后**继续使用 GOP framebuffer** 是否有平台特定限制（如需要提前 `EFI Graphics Output Protocol` 的 Stop/Blt 锁释放、或 GOP 21.0.1050 的线性 framebuffer 需要写后 cache flush）？

Q10. 无 16550 UART 的现代 SoC 上，对 0x3F8-0x3FF I/O 端口做 `in` 的典型行为：返回 0xFF（THRE=1 恒真可过）还是 0x00（死等）还是触发 #GP/SMI？N100 有无公开资料？（决定 H1 假设是否成立的关键）

Q11. 同一 U 盘在另一台 UEFI 机器（任意品牌，最好也非 QEMU）上试过吗？分不清"这台 N100 的固件特性"还是"所有真机都黑"——这是区分 H1/H2（代码问题，应全网复现）与 H3/H7（N100 特有）的最便宜实验。

Q12. 用官方 Ubuntu/Fedora live USB 在该 N100 上正常启动过吗（排除机器本身/显示器/线材问题的对照实验）？

五、请求专家回复的格式建议

1. 最可能根因（从 H1-H5 中选或另提），一句话理由
2. 零成本现场判别实验：建议做哪 1-3 个（如 Q1-Q4 类）
3. 需要补充的信息（请列清单，我们可提供 grub.cfg 全文 / kernel.elf 二进制 / 反汇编 / QEMU 完整日志）
4. 推荐的最终修复方向（如：GRUB 侧 serial 双输出 / 内核 serial 加超时 / 交权前主动 SetMode 到 1024x768 / 改用 UEFI stub 直接以 EFI 应用启动绕开 GRUB）
5. 若方便：您处理过的类似"GRUB 可见、内核黑屏"案例的关键教训

附录：grub.cfg 全文（0.2.1k ISO 实录）

set timeout=5
if [ "$grub_platform" = "efi" ]; then set default=0; else set default=1; fi
insmod font; insmod terminfo
echo "Platform: $grub_platform"
if [ "$grub_platform" = "efi" ]; then
    insmod efi_gop
    insmod efi_uga
else
    insmod vbe
fi
insmod all_video
terminal_output console
echo "**** EOS 0.2.1k banner ****"
menuentry "EOS v0.2.1k (EFI GOP, multiboot2)" {
    multiboot2 /boot/kernel.elf
    boot
}
menuentry "EOS v0.2.1k (text console safe, BIOS)" {
    set gfxpayload=text
    multiboot /boot/kernel.elf
    boot
}
menuentry "EOS v0.2.1k (fallback keep, legacy)" {
    set gfxpayload=keep
    multiboot /boot/kernel.elf
    boot
}

QEMU/OVMF 实测串口日志（正常路径参考）：

[0.2.1] kernel alive, serial ok
[mb2] parsing tags, magic=920085129
... tag type=8 (fb tag FOUND) ...
[fb] addr=2147483648 [fb] bpp=24 [fb] w=800 [fb] h=600 → 800x600@24bpp OK
[boot] multiboot magic OK → GDT → IDT → PIT 100Hz → PS/2
EOS v0.2.1 (MB2) boot complete. → 10s 后自动复位指纹

EOS 项目组 · 2026-09-16 · 本页面自包含，无外部依赖，可直接转发。可提供 kernel.elf 二进制（21,748 字节）与完整构建脚本供复现。