13
stages, in order
Embedded Linux on Edge-AI 23rd Sept 2026 enrollingLinux kernel & Device drivers starts on 24th Oct 2026 enrollingCorporate on-site training - Submit proposal Pick your modulesSharpen your kernel skills: deep dives, drivers, Yocto, CVEs, careers — updated daily. Read the blog →Embedded Linux fast track starts 23rd sept 2026 enrollingEmbedded Linux Mastery track starts 23rd sept 2026 enrollingLinux systems engineering starts 23rd sept 2026 enrolling
Free resource
From power-on to running Linux
The order things actually have to happen in, and the check that proves each step before you move to the next. Written for a board that has never booted - your first dev kit or a custom design.
Get the printable PDF4
free in full on this page
9
more in the emailed PDF
Only have a Raspberry Pi or a dev kit? Stages 05, 08, 09 and 10 are your practice path — finish them and you have a real bring-up story to tell in an interview.
The checklist
A checklist that assumes nothing works yet
01–03 Before power04–06 First signs of life07–08 Into the bootloader09–10 Into Linux11–13 After the first boot
Bring-up goes wrong in a predictable way: a stage is assumed good, the next stage fails, and the debugging happens in the wrong place. A board that reaches U-Boot but hangs entering Linux is usually a DDR (main memory) or a device-tree problem, not a kernel problem. So each stage below carries the observation that proves it before you move on. If you cannot produce the proof, you have not finished the stage.
Learning on a Raspberry Pi or a dev kit? You will not need the schematic stages — the board makers did them for you. Stages 05, 08, 09 and 10 are the ones you can practise today. Stage 05 is complete on this page; the full checks for 08 to 10 arrive in the free PDF below. New vocabulary is normal here — the Embedded Linux Glossary decodes every acronym this page uses, so keep it open in a second tab.
Coming from bare-metal MCUs? Stages 01 to 06 do the work your startup code and linker script did on a microcontroller: stable power, clocks, working memory and a serial port. Stages 07 to 10 are the handoff that has no MCU equivalent — from there, Linux owns memory translation, scheduling and driver loading, and debugging moves from registers to subsystems. Read stages 01 to 03 in full below — the checks map directly to work you have already done on an MCU. When a term is new, the glossary defines it; start with device tree, the file that replaces the pin and peripheral setup you used to write in C.
Before power
Nothing is trustworthy yet
STAGE 01
Read the schematic against the reference design
The reference design is the only configuration the vendor has actually booted. Every deviation is a thing you will debug later, so write the deviations down now while they are cheap to find.
- List every difference from the reference: DDR part and topology, PMIC (the power-management chip), boot media, crystal, PHY (the network transceiver).
- Confirm the boot-mode strap resistors match the medium you intend to boot from.
- Confirm the debug UART pins are the ones the boot ROM (the fixed first-stage code burned into the chip) uses, not a UART chosen for convenience.
- Check reset and power-good routing, including any supervisor that can hold the SoC in reset.
Proof it worked: A written deviation list, reviewed by someone who did not draw the schematic. Working alone? Read the list aloud against the reference design.
Where this goes wrong: A board that never prints a character usually has the console on the wrong UART, or straps selecting a boot medium that is unpopulated. Both are schematic problems being debugged as software.
STAGE 02
Power rails and sequencing
The SoC has a required order and timing for its supplies. Out-of-order rails can leave the part in an undefined state that looks exactly like a dead chip.
- Measure every rail at the SoC pins, not at the regulator output.
- Capture the sequence on a scope: order, ramp time, and the gap between rails.
- Compare against the sequencing diagram in the datasheet, including any minimum delays.
- Confirm the PMIC comes up in the expected default state before any software touches it.
Proof it worked: A scope capture showing each rail in the datasheet order and within tolerance, with reset released after the last rail is stable.
Where this goes wrong: Rails measured at the regulator look perfect while the SoC pin sags under load. IR drop across a thin trace has ended more bring-ups than firmware has.
STAGE 03
Clocks and reset release
The boot ROM cannot run without its input clock. This is a five-minute check that saves days.
- Verify the main oscillator or crystal is oscillating, at the frequency the boot ROM expects.
- Verify the RTC or 32 kHz source if the part needs one to leave reset.
- Confirm reset is released, and stays released, after the supplies are good.
- Check that no watchdog is resetting the part in a loop.
Proof it worked: A scope on the crystal showing a clean waveform at the specified frequency, and reset high and stable.
Where this goes wrong: A crystal with the wrong load capacitors starts intermittently: it works on the bench and fails cold. Check the load caps against the crystal datasheet, not against the reference design.
The full version of every stage is in the PDF
Stages 01 to 03 above are complete. Enter your email and we send the full 13-stage checklist, laid out to print.
No mailing list, no spam. By email we send the file once and stop.
First signs of life
Make the board tell you something
STAGE 04
Boot ROM and boot media selection
The boot ROM is masked silicon and cannot be changed. Your job is to make it find a valid image on a medium it is configured to read.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →STAGE 05
Serial console
Until you have a console you are debugging blind. Everything after this stage depends on it.
- Confirm the UART level shifter or USB-serial adapter is powered and wired for the right voltage.
- Confirm baud rate, and that the adapter ground is common with the board.
- Check for output during the boot ROM stage, before any of your firmware runs.
- If nothing appears, probe TX at the SoC pin to separate a silent SoC from a broken level shifter.
Proof it worked: Any characters at all from the boot ROM or first-stage loader. Even a garbled banner proves clocking, supplies and the UART path.
Where this goes wrong: Garbled output at a plausible baud rate almost always means the reference clock feeding the UART divisor is not what the software believes. That is a clock-tree bug, not a UART bug.
STAGE 06
First-stage loader and DDR initialisation
DDR is the stage that produces the most confusing downstream failures, because a marginal memory system does not fail cleanly. It corrupts.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →Want all 13 stages, with the proofs, at the bench? Get the printable checklist ↓
Into the bootloader
A prompt you can script against
STAGE 07
U-Boot prompt and environment
A working prompt means DDR, clocks, console and storage stack are all healthy enough to be scripted against.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →STAGE 08
Load a kernel and pass a device tree
This is the handoff. Most first-boot failures here are the device tree describing a board that does not exist.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →Into Linux
From kernel to a shell
STAGE 09
Root filesystem and a shell
A shell prompt is the boundary between bring-up and development. Get there on the simplest possible rootfs first.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →STAGE 10
Peripherals, one at a time
Bring peripherals up individually. Enabling everything at once turns one failure into an unreadable log.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →After the first boot
What professionals do after the board boots
STAGE 11
Capture the configuration
At this point the board boots because of a sequence of manual steps. None of that is reproducible until it is written down as build inputs.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →STAGE 12
Decide where the kernel comes from
This decision sets your security position for the life of the product, and it is hard to reverse late.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →STAGE 13
Production concerns
The remaining work is what separates a board that boots from a product you can ship and support.
4 checks, the proof and the failure modes — in the full checklistEnter your email for the full version →What it leads to
Where the kernel choice leads
If you are learning, this section is a preview of the judgment the job pays for.
Stage 12 is the one with consequences beyond bring-up, and it takes ten minutes to do properly. Find the kernel series your BSP pins (uname -r on the running board, or the tag in the vendor tree), then look it up on the kernel.org releases page, which publishes the projected end-of-life for every longterm series. Write that date next to the life you expect the product to have; any gap between the two is engineering work someone has to own. Stage 13 runs into the CRA reporting obligations that begin on 11 September 2026.
Take the checklist with you
The complete version, laid out to print and keep. Sent once.
No mailing list, no spam. By email we send the file once and stop.
Questions
Common questions
How do I use this checklist?
Work the stages in order, from 01 to 13. At each stage, run the checks and produce the proof before you move to the next stage. If a stage fails, the failure notes for that stage list the usual causes in the order they are worth checking. The printable PDF contains every stage in full, so you can mark each step off at the workbench.
I am using a Raspberry Pi or a dev kit. Do all 13 stages apply?
No. The board maker completed the hardware stages for you. Start at stage 05, the serial console — on a Raspberry Pi you reach it with a low-cost USB-to-serial adapter on the GPIO header. Then practise stage 08 (load a kernel and pass a device tree), stage 09 (root filesystem and a shell) and stage 10 (bring up peripherals one at a time). The free PDF contains the full checks for each.
What equipment do I need?
The early hardware stages assume a multimeter and an oscilloscope, which is normal for custom-board bring-up. From the serial console stage onward, a USB-to-serial adapter is enough. On a development kit you can work the software stages with only the adapter.
My board already boots. Is this page still useful?
Yes, as an audit. Run the proof for each stage in order. The first proof you cannot produce shows where the real state of the board differs from what everyone assumes, and that is usually where the next intermittent fault comes from.
Is the full checklist free?
The page shows the key stages at no cost. The complete printable PDF with all 13 stages is sent by email. We send the file once, and there is no mailing list.
Related tools and resources
Keep going
Kernel Bug Report Checklist →
Most reports that go unanswered fail on preparation, not on the difficulty of the bug. 13 steps, each with the proof that it was done, and the private route for the one case that must never go to a public list.
Read free + printable PDFEmbedded Linux GlossaryBSP, DTB, SBOM - the acronyms that fill docs, forum posts and reviews, decoded. 25 terms with the misunderstanding corrected: a BSP treated as a kernel, an SBOM produced by scanning.Open →
Free guideChoosing Your First SBCWhich board fits what you want to build - learning Linux internals, home automation, vision, robotics. Matched by use case, with the four checks before you buy.Open →
Live once a monthFree monthly masterclassOne free hour, live, every month, with a working kernel engineer. Bring your questions - including the one about how to get into this field. Recordings stay on YouTube.Open →
Free career guideCareer roadmapsWhich skills stay in demand as AI spreads, and the order to learn them - for the embedded Linux and kernel paths.Open →