doc/iso_boot.md: document CorePlus/TinyCore display limitation and Layer 1 check

- Add subsection explaining the DRM/KMS display driver check in Layer 1
- Document that CorePlus/TinyCore relies on vesafb (needs VESA BIOS,
  absent on coreboot without CSM) and has no KMS driver
- Note that all major distros (Debian, Ubuntu, Fedora, etc.)
  ship DRM/KMS drivers and pass the display check

Author: tlaurion

doc/iso_boot.md

@@ -164,3 +164,31 @@ kexec-tools to properly convey the framebuffer state across kexec.
 **TPM Disk Unlock Key** works around this for encrypted disks by
 injecting the LUKS key before kexec — the initramfs never prompts for
 a passphrase on a blank display.  Serial console is unaffected.
+
+#### Layer 1 display driver check
+
+Before showing boot options, Heads inspects each initrd for DRM/KMS
+kernel modules (i915, nouveau, amdgpu, bochs, virtio-gpu, etc.).
+These drivers reinitialize the display after kexec and make the booted
+OS visible regardless of efifb availability.
+
+Entries where at least one such driver is found get `[OK]` markers.
+Where none is found and the initrd has other loadable modules, a warning
+dialog is shown before the boot menu.
+
+#### ISOs without display drivers (CorePlus/TinyCore)
+
+CorePlus and TinyCore ship a minimal kernel that uses `vesafb.ko`
+(VESA framebuffer) as its only display driver.  `vesafb` requires
+VESA BIOS, which is unavailable under coreboot without a
+Compatibility Support Module (CSM).
+
+The ISO's userspace extensions (`Xvesa.tcz`, window managers, etc.)
+are loaded by TinyCore's init after boot and do not provide kernel
+display drivers.  After kexec, the target kernel has no KMS or
+framebuffer driver for any GPU — the display stays blank even though
+the OS boots and runs normally.
+
+All other distributions tested (Debian, Ubuntu, Fedora, PureOS,
+NixOS, Tails) ship at least one DRM/KMS driver in their initrd and
+pass the display check.