Reset and early firmware
After reset, the CPU starts from a defined reset vector or boot ROM path. Early code may establish a stack, configure clocks, initialize SRAM, read boot straps, and locate the next image. The exact sequence depends on the SoC and security architecture.
Boot stages
A common embedded path is Boot ROM → first-stage loader → trusted firmware or platform initialization → U-Boot/UEFI or another boot manager → operating-system kernel. Small systems may combine several stages; secure systems may authenticate each stage before execution.
What the kernel needs
Before transferring control, firmware must meet the target architecture's boot protocol. Depending on platform, that may include a valid kernel image, device tree or ACPI tables, initrd, memory map, CPU mode/exception level, cache and MMU state, and required registers. Linux ARM64 boot requirements are not interchangeable with x86 UEFI conventions.
Debugging the handoff
- Confirm the image format, load address, entry point, and decompression path.
- Check the bootloader log for memory reservation and device-tree selection.
- Verify the expected CPU mode and MMU/cache state.
- Use early console output or a debugger when normal kernel logs never appear.
- Inspect whether the kernel starts and fails later, rather than assuming the jump itself failed.
Why contracts matter
Each stage has an interface contract: image format, memory ownership, security state, and handoff registers. A successful branch to an entry point is not enough if the next stage's assumptions are violated.
Always use the boot protocol for your exact architecture and kernel version, plus the vendor's SoC documentation.
Final takeaway
Low-level engineering is about understanding the contract between hardware, firmware, and the operating system. Start with the specification, form a testable hypothesis, collect evidence, and validate behavior on the target platform.