$ dmesg | grep -i boot

Hardware

What is it?

A cheat sheet on what the hardware actually does before your code ever runs. First topic: the secure boot chain of a modern SoC, from the first voltage rail to a verified program executing in DRAM, and what happens when verification fails.

// power-on → chain of trust

Anatomy of a secure boot

A reference diagram and walkthrough of what actually happens between power-on and a verified program running on a typical secure microcontroller (SoC, boot ROM, flash and DRAM), including the failure path, since that is usually the more interesting part.

Numbered badges (0 to 8) trace the main execution sequence. Unbadged blocks are supporting infrastructure without a single fixed step in the sequence. Below the dashed line is the OS world: only a verified boot crosses the firmware/software boundary, after which the kernel mounts a file system, init starts services, and shells and scripts finally become possible.

Step by step

0
Pre-boot. Power management brings up the voltage rails, clock/PLL switches off the slow internal oscillator onto the main clock, and boot mode straps (a handful of pins sampled once at reset) tell boot ROM which source to boot from. In parallel, the reset controller gates when reset actually releases, the watchdog timer is armed to catch a hang later on, the TRNG becomes available for nonces, and glitch-detection sensors start watching the power and clock lines for fault-injection attempts.
1
Reset. The CPU's program counter is set to a fixed address inside boot ROM. Nothing else is initialized yet.
2
Boot ROM executes. Immutable code, burned in at fabrication, starts running. It cannot be patched.
3
Read the root key. Boot ROM reads the public key hash and anti-rollback counter from OTP/eFuses.
4
Fetch the bootloader. Boot ROM reads the next-stage image from external flash over SPI/QSPI into on-chip SRAM, since DRAM isn't usable yet.
5
Stage-2 runs from SRAM. The fetched image is staged in SRAM pending verification.
6
Verify the signature. The secure boot engine checks the image against the OTP root key. If a glitch is detected at any point up to here, or the signature doesn't check out, execution branches to the failure path instead of continuing.
7
Bring up DRAM. Once trusted, the memory controller calibrates timing and initializes external DRAM. MPU/MMU protections are configured before anything is allowed to run there.
8
Load and run. The DMA controller copies the verified firmware into DRAM; the CPU jumps to its entry point. From here, a TrustZone-style switch may separate secure and normal execution worlds, an attestation register can record a hash of what was loaded, and the interrupt controller and UART come online for normal operation. If this eventually boots an OS, control passes via a device tree at kernel handoff.

Two connections worth calling out

Debug port (JTAG/SWD) wires directly into the CPU's own debug access port logic, not into boot ROM, flash, or anything else. It's a standing, always-available override channel, independent of whatever software is or isn't running, which is why production parts either blow a fuse to disable it or gate it behind an authenticated challenge.
Boot straps feed a small hardware latch sampled once at reset. That latched value becomes a config register that only boot ROM reads: it's a fixed, one-time hardware input, not something software chooses.

Note: TrustZone, attestation, the interrupt controller and UART don't have one universal ordering the way steps 1 to 8 do: real designs vary in exactly when each gets configured. They're shown in one plausible order here for clarity, not as a claim about a fixed sequence.