The vocabulary, defined so it is usable

Ordered roughly as you meet them, from the board on your desk to the product you have to support for a decade. Every term is defined here; the full version adds the correction for each — the thing people usually get wrong.

Hardware you will be asked to compare

SoCsystem on chip

The processor die itself, integrating CPU cores with memory controllers, peripherals and usually GPU, video and imaging blocks.

Commonly misunderstood: The SoC decides your kernel support story. Two boards carrying the same SoC share the same upstream situation whatever the board vendor claims.

SoMsystem on module

A small board carrying the SoC, memory and power, designed to be soldered or socketed onto a custom carrier board (your own product PCB).

Commonly misunderstood: A module vendor longevity promise covers the module, not the silicon, and not the kernel support behind it. Those are three separate commitments and only one of them is being made.

SBCsingle-board computer

A complete usable computer on one board, with connectors fitted, such as a Raspberry Pi or a Khadas VIM3.

Commonly misunderstood: Superb for learning and prototyping, and rarely what a product ships. The board that teaches you the SoC is usually not the board you manufacture.

Evaluation boardEVM

The silicon vendor reference board for an SoC, built to demonstrate every feature.

Commonly misunderstood: The vendor BSP is developed and tested against this board. Every way your board differs from it is a difference you will personally debug.

The board and the boot

BSPboard support package

The collection of bootloader, kernel, device tree and drivers that makes Linux run on a specific board. Usually shipped by the silicon vendor (the chip maker) as a git tree (a downloadable source-code repository) pinned to one kernel version.

Commonly misunderstood: A BSP is not a product. It is a demonstration that the silicon works, built to sell the silicon. It is optimised for showing every peripheral working on the evaluation board, not for being maintained across a ten-year product life.

Device treeDT

A data structure describing the hardware to the kernel: what devices exist, at what addresses, on which buses, with which clocks and interrupts. Compiled from .dts and .dtsi sources.

Commonly misunderstood: It describes hardware, not configuration. If a device is absent from the device tree the kernel cannot find it however correct the driver is, and the failure is silent rather than an error.

DTBdevice tree blob

The compiled binary form of the device tree, loaded by the bootloader and handed to the kernel at boot.

Commonly misunderstood: The DTB and the kernel are separately versioned artefacts that must agree. Updating one and not the other produces devices that vanish, which reads like a driver bug and is not one.

U-Boot

The bootloader used by most embedded Linux systems: initialises DDR and basic peripherals, loads the kernel and DTB into memory, and hands control over.

Commonly misunderstood: Reaching a U-Boot prompt proves a great deal has already worked: supplies, clocks, DDR and console. When bring-up fails after this point, the earlier stages are usually fine.

SPL / TF-Asecondary program loader / Trusted Firmware-A

The very first code to run from on-chip SRAM, small enough to fit there, whose job is to bring up DDR so that a full bootloader can be loaded into it. The correction is in the full glossary

earlycon

A kernel parameter that brings up a minimal console very early, before the real serial driver probes, so you can see output from a kernel that dies during boot. The correction is in the full glossary

Building it

defconfig

A minimal, checked-in kernel configuration file listing only the options that differ from the defaults, from which a full .config is generated. The correction is in the full glossary

initramfs

A small root filesystem packed into memory and mounted before the real root, used to load whatever drivers are needed to reach the real root device. The correction is in the full glossary

Yocto Project

A build system that compiles a complete, reproducible Linux distribution from source for a specific device, from layered recipe metadata.

Commonly misunderstood: Yocto is a build system, not a distribution. What you ship is your distribution, which means its maintenance and its CVEs are yours.

Layermeta-*

A directory of Yocto recipes and configuration that adds or modifies functionality, such as meta-ti or meta-xilinx for a silicon vendor. The correction is in the full glossary

Recipe.bb

A file telling Yocto how to fetch, configure, compile and package one piece of software. The correction is in the full glossary

Toolchain

The cross-compiler, linker, C library and headers used to build code for the target architecture (the board CPU) on a different host architecture (your PC).

Commonly misunderstood: The C library choice, glibc or musl, is a product decision with licensing and compatibility consequences, not a build detail to be settled by whoever sets up CI.

Keeping it alive

LTSlongterm support

A kernel series the kernel.org stable maintainers continue to backport fixes to for an extended period, with a published projected end-of-life date.

Commonly misunderstood: LTS describes the upstream kernel, not your vendor BSP. If your BSP is pinned to a series, its cover ends when upstream ends it, whatever the vendor calls its own tree.

Mainline

The kernel tree maintained upstream at kernel.org, as opposed to a vendor fork.

Commonly misunderstood: Mainline support for an SoC is not all or nothing. The core may be upstream while the video encoder, NPU or ISP are not, and that per-block detail is what decides whether you can actually move.

Backport

Applying a fix written against a newer kernel to an older series, adapting it to the older code. The correction is in the full glossary

Security cliff

The date after which the kernel your product ships stops receiving upstream fixes, and the maintenance burden becomes yours.

Commonly misunderstood: This date is set at design time, when the BSP is chosen, and it is usually discovered years later by someone who did not choose it.

SBOMsoftware bill of materials

A machine-readable inventory of the components in a shipped image, with versions and relationships. SPDX and CycloneDX are the common formats.

Commonly misunderstood: An SBOM produced by scanning a finished image is a guess. Generate it from the build system, which knows exactly what it included and what it configured out.

VEXvulnerability exploitability exchange

A statement, attached to an SBOM, saying whether a product is actually affected by a given vulnerability and why. The correction is in the full glossary

CVEcommon vulnerabilities and exposures

An identifier assigned to a publicly disclosed vulnerability.

Commonly misunderstood: Since the kernel became its own CVE numbering authority the volume rose sharply, and a CVE identifier alone says nothing about severity or whether your configuration is reachable.

CRACyber Resilience Act

EU regulation setting cybersecurity requirements for products with digital elements. Reporting obligations apply from 11 September 2026; the main obligations from 11 December 2027.

Commonly misunderstood: The September 2026 date is reporting only, and it covers products already on the market. SBOM and the essential requirements arrive with the December 2027 date.

Support period

The period during which a manufacturer undertakes to supply security updates for a product. The correction is in the full glossary

Several of these terms come alive when you see them against real hardware: the SBC comparison sheet puts kernels, cutoff dates and mainline status behind 32 boards you are likely to meet.