What Is Embedded Linux?

Goal: Build a clear mental model of what an operating system does, where Linux fits in the landscape, and why embedded systems use it — before diving into boot sequences and drivers.

1. What Is an Operating System?

An operating system (OS) is the software layer between hardware and applications. Its job:

Responsibility	What It Does	Without an OS
Resource sharing	Divides CPU, memory, and I/O among multiple programs	Your single `main()` loop owns everything
Protection	Prevents one program from corrupting another	A bug anywhere can crash everything
Hardware abstraction	Provides a uniform API regardless of hardware details	You write to specific registers for each chip
Scheduling	Decides which task runs when, for how long	You manually yield control in your super-loop

On a microcontroller, you are the operating system — your code manages everything directly. Once the system grows beyond a single control loop (multiple tasks, networking, a display, a filesystem), an OS takes over these responsibilities so you can focus on application logic.

Real-Time Operating Systems

Not all OSes are equal in timing:

A general-purpose OS (Linux, Windows) optimizes for throughput and fairness — it gives every task a fair share, but makes no timing promises.
A real-time OS (RTOS) guarantees response times — if an event occurs, the system reacts within a defined deadline.

Most products have a mix: some tasks are time-critical (motor control, sensor sampling), others are not (logging, UI updates). This is why many embedded systems combine an RTOS for the critical path with Linux for everything else.

2. Where Linux Runs

Linux is not just "a server OS" or "a desktop OS." It runs across virtually every computing platform:

Platform	Linux Market Share	Examples
Servers	~80% of web servers	AWS, Google Cloud, every major cloud provider
Mobile	~72% (via Android)	Android phones and tablets
Supercomputers	100% of Top 500	Every supercomputer since 2017
Embedded / IoT	~65% of embedded projects	Routers, IP cameras, industrial HMIs, cars
Desktop	~4%	Developer workstations, Chromebooks

This ubiquity is not an accident. Linux is:

Free and open source — no per-unit license cost (critical when shipping 10,000 devices)
Portable — runs on ARM, x86, RISC-V, MIPS, and more
Mature — 30+ years of development, thousands of drivers, battle-tested networking stack
Supported — massive community, commercial vendors (Canonical, Red Hat, SUSE), and SoC manufacturers contribute drivers and BSPs

Tip

The Embedded Systems course uses MicroPython on the Pico (bare-metal/RTOS territory). This course moves up to Linux — the same concepts (GPIO, I2C, SPI, interrupts) appear, but now managed through an OS layer.

3. The Hardware: MCU vs MPU vs SoC

Before choosing an OS, you need to understand what hardware you are targeting:

	MCU (Microcontroller)	MPU (Microprocessor)	SoC (System-on-Chip)
What it is	CPU + RAM + flash + peripherals in one chip	CPU only; RAM, storage, peripherals are external	CPU + memory controllers + peripherals on one die
RAM	KB (264 KB on Pico)	External, GB-scale	External, GB-scale
MMU	Usually none (Cortex-M)	Yes (Cortex-A, x86)	Yes
Typical OS	Bare-metal or RTOS	Linux, Windows	Linux
Examples	RP2040, STM32, ESP32	Intel Core, AMD Ryzen	BCM2711 (RPi 4), i.MX6, AM335x
Power	mW range	Watts	Watts
Cost	\(0.50–\)5	\(10–\)100+	\(5–\)50

The key dividing line is the MMU (Memory Management Unit). Linux requires an MMU for virtual memory, process isolation, and memory protection. This is why Linux runs on Cortex-A processors (with MMU) but not on Cortex-M processors (without MMU) like the Pico.

Minimum Hardware for Embedded Linux

Requirement	Minimum	Practical
Processor	32-bit or 64-bit with MMU	ARM Cortex-A, x86, RISC-V
RAM	~16 MB	64 MB+ for comfortable operation
Storage	~4 MB (NOR flash, minimal rootfs)	16 MB+ (NAND, eMMC, SD card)

A Buildroot-based system with BusyBox can fit in 4 MB of flash and boot with 16 MB of RAM. A Debian-based system needs gigabytes. The choice depends on your product constraints.

4. Embedded Linux = Linux Under Constraints

Embedded Linux is standard Linux used with product constraints:

boot deadline
storage limit
power budget
lifecycle/maintainability requirements
reliability under power loss and network failures

The main engineering task is choosing what to keep, remove, and harden.

5. Linux vs MCU Firmware (Decision Model)

Use Linux when you need:

rich device support (camera, USB, networking)
process isolation and service management
complex user-space software

Use MCU firmware when you need:

very low power
hard real-time timing
minimal system complexity

Many products use both: MCU for strict control loops, Linux for orchestration and connectivity.

Concrete Comparison

	Raspberry Pi Pico (MCU)	Raspberry Pi 4 (Embedded Linux)	Desktop Linux
CPU	133 MHz dual-core Cortex-M0+	1.5 GHz quad-core Cortex-A72	3+ GHz multi-core
RAM	264 KB	2-8 GB	8-64 GB
Storage	2 MB flash	16+ GB SD card	256+ GB SSD
Boot time	~100 ms	5-40 s	15-60 s
Power	~25 mW	~3-7 W	50-300 W
OS	None / RTOS	Linux	Linux
Networking	Add-on (WiFi module)	Built-in (Ethernet, WiFi)	Built-in
Process isolation	None	Full (MMU)	Full (MMU)

Real product examples: - MCU (Pico-class): thermostat controller, motor driver, sensor node - Embedded Linux (RPi-class): home gateway, IP camera, industrial HMI, POS terminal - Desktop Linux: development workstation, server

"Use Both" — Hardware Architectures

When a product needs both Linux (networking, UI, storage) and hard real-time control (motor loops, safety, fast ADC sampling), three hardware architectures are common:

Architecture	How It Works	Example SoCs / Boards
Heterogeneous SoC	Cortex-A + Cortex-M on the same chip — Linux on A-core, RTOS on M-core, communication via shared memory	STM32MP1, i.MX8M Plus, TI AM62x
External MCU	Separate MCU connected via UART / SPI / CAN — two independent systems exchanging commands and telemetry	RPi + STM32, BeagleBone + Arduino
FPGA fabric	Programmable logic alongside a CPU — sub-microsecond determinism for signal processing or custom protocols	Xilinx Zynq, Intel Cyclone V SoC

Heterogeneous SoC example — STM32MP1:

The STM32MP157 contains a 650 MHz Cortex-A7 (running Linux) and a 209 MHz Cortex-M4 (running FreeRTOS or bare-metal) on the same die, sharing SRAM. The M4 boots in under 50 ms — sensors and actuators are running before Linux even starts. Communication uses RPMsg (Remote Processor Messaging), a lightweight protocol over shared memory that avoids the latency and complexity of an external bus.

  ┌─────────────────────────────────────────────┐
  │  STM32MP157                                 │
  │                                             │
  │  Cortex-A7 (650 MHz)   Cortex-M4 (209 MHz) │
  │  ┌───────────────┐     ┌──────────────┐    │
  │  │ Linux         │     │ FreeRTOS     │    │
  │  │ • Web UI      │ ◄─► │ • PID loop   │    │
  │  │ • OTA updates │RPMsg│ • 1 kHz ADC  │    │
  │  │ • Data logger │     │ • Motor PWM  │    │
  │  └───────────────┘     └──────────────┘    │
  │          shared memory (SRAM)               │
  └─────────────────────────────────────────────┘

External MCU example — RPi + STM32:

When you already have working MCU firmware (e.g., a motor controller) or need a certified safety boundary between domains, use two separate chips connected by a bus:

  Raspberry Pi 4                    STM32F4
  ┌──────────────┐     UART/SPI    ┌──────────────┐
  │ Linux        │ ◄──────────────► │ FreeRTOS     │
  │ • Dashboard  │   commands +     │ • Sensor 1kHz│
  │ • Cloud MQTT │   telemetry      │ • Motor ctrl │
  │ • Camera     │                  │ • Safety     │
  └──────────────┘                  └──────────────┘

Pros: use any MCU, easy prototyping with off-the-shelf boards, clean certification boundary. Cons: two power supplies, two PCBs (or wires), bus latency (~1 ms for UART).

Choosing an architecture:

Requirement	Heterogeneous SoC	External MCU	FPGA
Hard RT + Linux on one board	Best fit	Works (with wires)	Overkill
Existing MCU firmware to reuse	Port needed	Plug and play	Port needed
BOM cost sensitive (high volume)	Lowest (one chip)	Two chips	Expensive
Sub-µs determinism	M4 core: ~1 µs	MCU: ~1 µs	Fabric: < 100 ns
Certification boundary	Shared silicon	Clean separation	Clean separation

Rule of thumb: Start with a heterogeneous SoC (STM32MP1, i.MX8M). Fall back to an external MCU if you need a certified safety boundary or have existing firmware. Use FPGA only for sub-microsecond requirements.

6. The Layered Stack

Hardware -> Bootloader -> Kernel -> Init -> Application

Each layer has a different role:

bootloader: bring-up and image loading
kernel: scheduling, memory, drivers
init system: startup order and supervision
application: product behavior

graph TD
    A[Application] <--> B[Init System — systemd]
    B <--> C[Linux Kernel]
    C <--> D[Bootloader — U-Boot]
    D <--> E[Hardware — SoC, RAM, Storage, Peripherals]

    style A fill:#4CAF50,color:#fff
    style B fill:#2196F3,color:#fff
    style C fill:#FF9800,color:#fff
    style D fill:#9C27B0,color:#fff
    style E fill:#607D8B,color:#fff

Each layer communicates only with its immediate neighbors. Skipping layers (e.g., application directly accessing hardware registers) breaks portability and safety.

If the roles are mixed, debugging becomes expensive.

7. Two Levels of Engineering

Working with embedded Linux means working at one of two levels — or both. Understanding this distinction helps you navigate the course and your career.

	Application Development	Platform / System Development
What you build	Services, UIs, data pipelines, networking, cloud integration	Kernel drivers, device tree, boot configuration, custom images
Language	Python, C, C++, Rust, shell scripts	C (kernel), DTS (device tree), Kconfig, Makefiles
Interfaces you use	`/dev/`, sysfs, sockets, libraries (OpenCV, SDL2, smbus)	Kernel APIs, register maps, bus subsystems
When you crash	Your process dies; restart it	Kernel panic — entire system reboots
Typical job title	Embedded software engineer, IoT developer	BSP engineer, kernel engineer, platform engineer
This course	Display Apps, Level Display, Data Logger, Camera Pipeline, Shell Scripting	MCP9808 Driver, BMI160 Driver, BUSE Driver, Buildroot, Boot Timing

In a product team, application engineers depend on platform engineers — the drivers and boot config must work before applications can run. But both roles are essential. A perfect kernel driver is useless without an application that uses it. A great application is impossible without drivers that expose the hardware.

The boundary in practice:

Application    (Python: read sensor, render UI, send MQTT)
    ↕          system calls, /dev/, sysfs
Platform       (kernel driver, device tree, systemd service file, Buildroot config)
    ↕          hardware registers, bus protocols
Hardware       (SoC, sensors, display)

This course teaches both levels. The first half focuses on understanding the platform (how Linux works, how it boots, how drivers expose hardware). The second half builds applications on top of that platform (display pipelines, data logging, real-time graphics). Some tutorials are purely application-level (Level Display, Camera Pipeline), some are purely platform-level (kernel drivers, Buildroot), and some bridge both (Data Logger Appliance: systemd service + read-only root + overlayfs).

Tip

You don't need to master both levels to be productive. Many embedded engineers specialize in one. But understanding the other level — even at a high level — makes you a far better engineer. Application developers who understand drivers debug faster. Kernel developers who understand applications design better interfaces.

8. The Four Building Blocks

Every embedded Linux system is made of four components. The rest of this course explores each in depth:

Component	What It Is	Built By	Course Coverage
Toolchain	Compiler + linker + C library — turns source code into target binaries	Buildroot or manual setup	Building Custom Linux
Bootloader	First software to run; initializes hardware, loads the kernel	U-Boot (most common), GRUB2 (x86)	Boot Architectures
Kernel	Scheduling, memory management, drivers, hardware abstraction	Configured via `menuconfig`, built by Buildroot/Yocto	Linux Fundamentals, Device Tree and Drivers
Root filesystem	User-space programs, libraries, configuration, your application	Buildroot, Yocto, or manual assembly	Building Custom Linux

On a stock Raspberry Pi OS, these are pre-built and ready to use. In a product, you build each one yourself (or through a build system like Buildroot) to control exactly what goes into the image.

9. The Open-Source Ecosystem

Embedded Linux does not exist in isolation. It is supported by a large ecosystem — but that ecosystem has its own challenges:

Actor	Role	Example
Kernel community	Maintains the mainline Linux kernel	kernel.org, ~1,700 developers per release
SoC vendors	Provide chip-specific kernel patches, drivers, BSPs	Broadcom (RPi), NXP (i.MX), TI (AM335x)
Board/SoM vendors	Provide board-specific BSPs and reference images	Raspberry Pi Foundation, Toradex, Variscite
Build system projects	Provide tools to assemble custom images	Buildroot, Yocto/OpenEmbedded
Commercial companies	Offer long-term support, certification, custom engineering	Bootlin, Pengutronix, Siemens (mentor)

Common pain points in practice:

Your specific board may not have full upstream kernel support yet
Vendor kernels lag behind mainline — security patches arrive late
Vendors don't always upstream their patches, creating maintenance debt
Long product lifecycles (10+ years) vs fast kernel release cycles (~9 weeks)

This is an engineering reality you will encounter. The tutorials use well-supported hardware (Raspberry Pi), but in industry, navigating this ecosystem is a core skill.

10. Distribution vs Custom Build

Two fundamentally different approaches to getting Linux on your board:

	Stock Distribution (Debian, Ubuntu)	Custom Build (Buildroot, Yocto)
Setup time	Minutes (flash an image)	Hours to days (configure + build)
Image size	1–4 GB	30–100 MB
Package manager	Yes (apt, dnf)	Usually none
Control over contents	Limited	Total
Reproducibility	Depends on package versions	Full (deterministic builds)
Best for	Prototyping, learning, development	Production, constrained hardware

For this course: We start with Raspberry Pi OS (a Debian derivative) for prototyping and lab work. In Building Custom Linux, we build a custom Buildroot image and compare the two approaches.

11. Cross-Compilation

Embedded targets (ARM Cortex-A, RISC-V) typically cannot compile their own software efficiently — they have limited CPU, RAM, and storage. Instead, you compile on a powerful host machine (your x86 laptop or a build server) using a cross-compiler that produces binaries for the target architecture.

A cross-compiler toolchain name encodes its target: arm-linux-gnueabihf-gcc breaks down as:

Component	Meaning
`arm`	Target CPU architecture (32-bit ARM)
`linux`	Target OS (Linux kernel)
`gnueabihf`	ABI: GNU, embedded, hard-float (uses FPU for floating-point)
`gcc`	The compiler (GNU Compiler Collection)

The toolchain also includes a sysroot — a directory containing the target's C library, headers, and shared libraries. When the cross-compiler resolves #include <stdio.h>, it searches the sysroot (ARM headers), not your host's /usr/include (x86 headers). Build systems like Buildroot manage the sysroot automatically; if you build manually, passing --sysroot=/path/to/target/rootfs ensures the compiler finds the correct libraries.

12. Power Management Fundamentals

Embedded devices often run on batteries or have strict thermal limits. Linux provides several power management mechanisms:

DVFS (Dynamic Voltage and Frequency Scaling)

The CPU governor adjusts clock speed and voltage based on load. The powersave governor minimizes frequency; performance locks it at maximum; ondemand scales dynamically. But why is DVFS so effective? The answer lies in the CMOS power equation.

The dynamic power dissipation of a CMOS circuit is:

\[P_{dynamic} = C \cdot V^2 \cdot f\]

where \(C\) is the switched capacitance (determined by chip design — how many transistors switch per clock cycle), \(V\) is the supply voltage, and \(f\) is the clock frequency. At first glance, power scales linearly with frequency — halve the clock, halve the power. But that misses a crucial coupling.

In CMOS logic, transistors need a minimum voltage to reliably switch at a given frequency. Higher frequency demands faster switching, which requires higher voltage to overcome transistor threshold effects. To a first-order approximation, the minimum required voltage is proportional to frequency:

\[V \propto f \quad \Rightarrow \quad V = k \cdot f\]

The constant \(k\) (units: V·s) is specific to each chip's manufacturing process — it captures how much voltage the transistors need per unit of clock frequency. It depends on gate oxide thickness, transistor threshold voltage, and circuit design. In practice you never compute \(k\) directly; the SoC vendor publishes a table of valid voltage-frequency pairs (the OPP table — Operating Performance Points). What matters is the proportionality: when frequency goes down, voltage goes down with it.

Substituting \(V = k \cdot f\) into the power equation:

\[P = C \cdot (k \cdot f)^2 \cdot f = C \cdot k^2 \cdot f^3\]

Power scales with the cube of frequency. This means:

Halving the frequency also halves the voltage, so power drops to \((1/2)^3 = 1/8\) — an 8× reduction, not 2×
Running at 60% frequency does not save 40% power — it saves approximately 78% power

Frequency	Voltage	Relative Power
1.5 GHz (max)	1.0 V	100%
1.0 GHz	~0.8 V	~34%
750 MHz	~0.7 V	~18%
600 MHz	~0.6 V	~10%

Info

The \(f^3\) relationship holds for dynamic power only. At very low voltages, static (leakage) power dominates — current leaks through transistors even when they are not switching. Real SoCs have a voltage floor below which further DVFS gives diminishing returns. The chip datasheet specifies the available operating points (voltage-frequency pairs) as an OPP (Operating Performance Points) table.

C-states (CPU idle states)

When the CPU has no work, it progressively shuts down internal components:

State	Name	Latency to Wake	Power	What's Off
C0	Active	0	Full	Nothing — CPU executing
C1	Halt	~1 µs	~50%	Clock stopped, core idle
C2	Stop-Clock	~100 µs	~20%	Clock + PLL stopped
C3	Sleep	~1 ms	~5%	Cache may be flushed

Battery life estimation example: A sensor node with a 3000 mAh battery, active for 5 ms at 150 mA (reading sensor + transmitting), then sleeping for 9995 ms at 0.5 mA:

Average current: (150 × 5 + 0.5 × 9995) / 10000 = 0.57 mA
Battery life: 3000 / 0.57 ≈ 5263 hours ≈ 219 days

This back-of-envelope calculation is the starting point for every battery-powered product design. The key insight: sleep current dominates battery life, not active current — reducing sleep current from 0.5 mA to 0.1 mA extends life from 219 days to over 2 years.

Thermal Modeling

The \(P = C k^2 f^3\) relationship from DVFS tells you how much heat the chip produces. Thermal modeling tells you where that heat goes — and whether the chip overheats.

Junction Temperature

The temperature at the silicon die (junction temperature \(T_j\)) determines whether the chip operates within its rated limits:

\[T_j = T_a + P \cdot R_{\theta,ja}\]

where:

\(T_a\) is the ambient temperature (°C)
\(P\) is the power dissipation (W)
\(R_{\theta,ja}\) is the thermal resistance from junction to ambient (°C/W)

Thermal resistance is analogous to electrical resistance (Ohm's law: \(V = I \cdot R\) → \(\Delta T = P \cdot R_\theta\)). Heat flows from the die through a chain of resistances:

\[R_{\theta,ja} = R_{\theta,jc} + R_{\theta,cs} + R_{\theta,sa}\]

Segment	From → To	Typical Value
\(R_{\theta,jc}\)	Junction → case (chip package)	1–5 °C/W
\(R_{\theta,cs}\)	Case → heatsink (thermal paste/pad)	0.5–2 °C/W
\(R_{\theta,sa}\)	Heatsink → ambient (convection)	5–20 °C/W

Worked Example: Raspberry Pi 4

The BCM2711 SoC at full load dissipates approximately 3 W. Without a heatsink, \(R_{\theta,ja} \approx 12\text{ °C/W}\) (package to air through the PCB):

Scenario	\(T_a\)	\(P\)	\(T_j\)	Status
Lab bench	25 °C	3 W	\(25 + 36 = 61\) °C	OK (below 85 °C)
Industrial enclosure	40 °C	3 W	\(40 + 36 = 76\) °C	Marginal
Outdoor summer	50 °C	3 W	\(50 + 36 = 86\) °C	Throttling!

Adding a heatsink (\(R_{\theta,sa} \approx 8\text{ °C/W}\), total \(R_{\theta,ja} \approx 5\text{ °C/W}\)): \(T_j = 50 + 15 = 65\) °C — well within limits.

Thermal Throttling

When \(T_j\) exceeds the chip's thermal threshold (85 °C for BCM2711), the SoC automatically reduces clock frequency to reduce power — this is thermal throttling. It connects directly back to the DVFS section: the governor drops from performance to a lower OPP to reduce \(P\), which reduces \(T_j\).

Design rule: Always calculate \(T_j\) at the maximum ambient temperature for the deployment environment, at maximum sustained power. If \(T_j\) exceeds the threshold under these conditions, add thermal management (heatsink, forced air, or reduced clock) before deployment.

13. Product Trade-offs You Must Make Explicit

fast boot vs broad functionality
small image vs developer convenience
flexibility vs deterministic behavior
minimal attack surface vs remote manageability

These are product decisions, not just software decisions.

Quick Checks (In Practice)

Can the product recover after power loss?
Can you reproduce an image from source/config?
Can you identify which layer failed during boot?
Is your service startup order deterministic?

Mini Exercise

Your team is designing a greenhouse monitoring system that needs: - Temperature and humidity readings every 5 seconds - WiFi connectivity to upload data to a cloud dashboard - Local OLED display showing current values - Automatic fan control based on temperature thresholds - Remote firmware updates

In 6-8 lines, justify whether you would use an MCU (like the Pico), embedded Linux (like the RPi), or a combination of both. Your answer must address boot time, reliability, and long-term maintenance.

Key Takeaways

Embedded Linux is about constraints and trade-offs.
The stack is layered; each layer matters.
Tool choice follows system needs, not preference.
Embedded Linux engineering spans two levels: application development (building software that runs on Linux) and platform engineering (building and maintaining the Linux system itself). This course covers both.

Hands-On

Try this in practice: Tutorial: SSH Login — connect to an embedded Linux system for the first time.

14. How We Got Here

Embedded Linux didn't appear overnight. Understanding the history explains why certain tools exist and which ones are disappearing.

Timeline

Linux grew out of the Unix tradition. Understanding the lineage explains why Linux commands, file hierarchies, and the "everything is a file" philosophy look the way they do.

Year	Milestone
1969	Ken Thompson and Dennis Ritchie create Unix at AT&T Bell Labs (PDP-7)
1972	Unix rewritten in C — becomes the first portable operating system
1977	BSD (Berkeley Software Distribution) — adds TCP/IP, virtual memory, sockets
1983	Richard Stallman starts the GNU project — free software tools (gcc, bash, coreutils)
1988	POSIX standard published — portable OS interface, unifies Unix variants
1991	Linus Torvalds releases Linux 0.01 — a hobby project for x86 PCs
1999	BusyBox + uClibc make Linux practical on small ARM devices
2003	Buildroot project starts — simple cross-compilation framework
2006	Android announced — Linux becomes the world's most-deployed OS
2010	Yocto Project founded — industrial-grade embedded Linux build system
2015	Device Tree becomes mandatory for ARM — no more hard-coded board files
2023	PREEMPT_RT merged into mainline Linux — real-time is no longer a patch
2024	Rust modules accepted in mainline — new language option for drivers

What's Obsolete

Old Way	Replaced By	Why
devfs	udev (2004)	Dynamic device management, rules-based
fbdev (`/dev/fb0`)	DRM/KMS	Atomic page flips, multi-plane, VSync events
sysvinit	systemd	Parallel startup, dependency management, watchdog
HAL (Hardware Abstraction Layer)	udev + sysfs	Simpler, kernel-integrated
Board files (C code per board)	Device Tree	Hardware description separated from code

What's Emerging

eBPF for embedded tracing: Attach programs to kernel events without recompiling — powerful for production debugging
Rust in kernel modules: Memory-safe driver development, accepted in mainline since Linux 6.1
Zephyr RTOS: Modern, well-funded RTOS for MCUs — the "what PREEMPT_RT can't reach" tier
RISC-V boards: Open ISA gaining momentum; Buildroot and Yocto support RISC-V targets

Regulatory Landscape

Embedded devices increasingly face regulatory requirements:

Standard	Scope	Key Requirement
IEC 62443	Industrial cybersecurity	Security lifecycle, zone/conduit model
ETSI EN 303 645	Consumer IoT	No default passwords, secure updates, vulnerability disclosure
EU Cyber Resilience Act	All connected products (EU)	Security by design, vulnerability handling, 5-year update commitment

These regulations are not optional — they affect what you can legally sell in the EU starting 2027.