Boot partition not found: capturing early-boot diagnostics without serial console

When a Raspberry Pi fails to mount the boot partition during SD-card boot, the kernel never starts and no logs are written to the filesystem. The bootloader emits diagnostic messages only on the serial console (ttyAMA0 or ttyS0), which requires a USB-to-serial adapter and an active capture session at power-on. Without that hardware, the only visible symptom is a blank screen or a repeating LED pattern, leaving the root cause — missing boot partition, corrupted config.txt, or firmware mismatch — ambiguous.

The config.txt file controls boot order, GPU memory split, and low-level hardware settings; an unknown option or incorrect boot-order entry can prevent the bootloader from locating the kernel image. However, verifying the exact config.txt content on a non-booting card requires mounting it on another machine, and even then the bootloader's interpretation of those settings is not logged anywhere persistent.

Systemd and kernel logs only appear after a successful handoff, so they cannot distinguish between a bootloader configuration error and a filesystem corruption that occurs later in the mount process.

• What alternative methods exist to retrieve bootloader-stage diagnostics when a serial console is unavailable?
• Can the bootloader be configured to write a minimal log to the boot partition before attempting to load the kernel?
• How does the bootloader's behavior differ between Raspberry Pi OS Bookworm and Bullseye when config.txt contains an unrecognized directive?