EC-20.4 Embedded Linux, Device Drivers and the Board Support Layer

What this is and why it exists

There is a size of system above which writing everything yourself stops being sensible.

Below it, a microcontroller running your code and perhaps a small kernel is predictable and cheap. Above it, you want a network stack, a file system, several processes and a graphical interface. Writing those yourself is a career rather than a project.

This topic is about the larger side of that line. It is deliberately not a Linux course. It is the map. What makes the crossing possible, what each boot stage does, what a driver is, and what you give up in timing.

The vocabulary

• Applications processor — a processor with memory management hardware, able to run a general-purpose operating system.
• Bootloader — the small program that brings up memory and loads the kernel.
• Kernel — the part of the operating system managing memory, processes and hardware.
• Root filesystem — the files the kernel mounts and runs programs from.
• Device tree — a description of the hardware attached to a processor, read at boot.
• Driver — the code connecting a standard kernel interface to one piece of hardware.
• User space — where ordinary programs run, isolated from the kernel and from each other.
• Board support — the collection of changes that make a general kernel run on your board.

The mental model

The line between a microcontroller and an applications processor is drawn by three things: memory management hardware, external memory, and a storage device. Those are what make a general-purpose operating system possible. Their absence is what makes a microcontroller predictable.

Booting happens in stages, and being able to name them turns a dead board into a question with an answer.

A small boot program in read-only memory starts first and knows almost nothing. The bootloader then sets up external memory, finds a kernel, and hands over. The kernel initialises hardware, mounts a root filesystem, and starts the first user program. Each stage has its own way of announcing itself, usually on a serial port, and a failure sits in exactly one of them.

A processor cannot discover what is wired to its pins the way a computer discovers a plug-in card. So the wiring is written down separately, in the device tree, which the kernel reads at boot. Most bring-up work on a new board is edits to that description: this sensor is on this bus, at this address, with this interrupt.

A driver is less mysterious than it sounds. It presents a standard interface upward and talks to registers downward, and nearly all of its difficulty is in the middle. Reading one small existing driver end to end teaches more than any amount of description.

Code in the kernel can crash the whole system and is much harder to debug. The standard advice is to do as little there as possible. Several interfaces exist specifically so that ordinary programs can reach hardware safely, and using one of them is usually the right first answer.

Finally, the cost. A general-purpose kernel will occasionally take milliseconds to return to your code, which destroys any hard deadline. The two usual answers are a real-time variant of the kernel, or a separate small processor. That processor keeps the hard timing while the large one does everything else.

What you should now be able to explain or do

• Say what hardware makes an applications processor different from a microcontroller.
• Name the boot stages in order, and say which one a given failure sits in.
• Read a device tree entry and say what hardware it describes.
• Explain what a driver connects, and why most work belongs above the kernel boundary.
• Say what happens to hard deadlines when a general-purpose kernel is introduced.
• Describe the two standard ways of getting real-time behaviour back.

Check yourself