All you need to know to use make the Linux kernel support your own hardware.
Overview
Everything you need to know to make the Linux kernel boot on your new embedded board and write drivers for its specific hardware devices. Learn how to describe your hardware with the device tree, and debug the kernel code (written by yourself or by the community).
Also learn how to contribute changes back to the upstream version of Linux, to reduce your own maintenance costs, make support for your hardware ubiquitous and enjoy contributions from the Linux kernel developer community.
Root Commit uses progressive but challenging practical labs and varying techniques to make the learning always stimulating and fun, and above all to make it stick.
Description
- Duration: 5 days – 40 hours (in-person), 8 half-days – 32 hours (on-line)
- Mix: 25% lectures, 75% practical labs
- Language: English or French
- Location: In-house (all continents) or remote
- Trainer: Michael Opdenacker
- Hardware: Beagle Play board with TI Sitara AM625 SoC (ARM 64)
- Prerequisites: familiarity with the Linux command line
- Cost: Ask for a quote
Agenda
Day 1: Configuring, building, booting and kernel modules
- Demo: Build a Linux kernel for a different board and boot it.
- Big picture: bootloader, kernel and user-space.
- Get a cross-compiling toolchain.
- Retrieve Linux kernel sources. Understand the Linux release process and and choose a version for your project.
- Configure the Linux kernel. Guided tour of most interesting options.
- Cross-compile the kernel. Speed up this build.
- Boot the kernel from the bootloader. Device Tree and kernel command line
- Kernel code constraints. Writing a kernel module.
Day 2: Device model – Bus, drivers and devices
- How the kernel abstracts busses, devices and drivers.
- Case of busses supporting device enumeration.
- Platform devices and drivers.
- Device Tree: how to describe hardware that cannot be detected.
- Example: the I2C bus.
- Pin multiplexing.
- Writing an I2C device driver
Day 3: Kernel frameworks, memory and I/O
- Character driver operations: read, write, ioctl(). Exchanging data with user-space.
- Kernel frameworks: abstracting devices in user-space.
- Example: the input subsystem.
- Completing the I2C driver: exposing device data to userspace.
- Kernel memory allocation – Understanding memory usage statistics.
- Reserving and mapping I/O memory (registers).
- Application: write data to board serial ports.
Day 4: Interrupts, differing work, locking
- Application: allow user space to write to serial ports.
- Processes and scheduling. Waiting for a condition.
- Support for interrupts to process hardware events.
- Application: read data received on the serial ports.
- Managing concurrency issues. Lock based and lock-less primitives. Debugging locks.
- Torture the serial driver. Expose and fix bugs due to concurrency issues.
Day 5: Board support, debugging, testing and contribution
- How to support a new board. How SoCs are supported.
- Available techniques for kernel debugging.
- Kernel testing.
- Performance analysis with perf and ftrace.
- Kernel development best practices: error handling, coding conventions, using the checkpatch.pl script.
- How to contribute to the upstream Linux kernel.
- Bisecting kernel code.
- Add your name to kernel history by submitting your first patch(es).
- Getting involved: ideas for kernel contribution.
- Conferences and useful resources.
- Q&A session.
FAQ
Q: In-house sessions: can practical labs be run on the CPU that my project uses?
A: The Linux kernel tries to offer the same mechanisms for all types of hardware, so most of what you learn on another platform should apply on other ones as well. Another reason to stick with our standard instructions is that the some drivers we develop during the labs depend on the CPU being driven, in particular its hardware registers. Therefore porting our practical labs to different hardware remains possible, if you are ready to accept substantial preparation costs.
Q: Will I get solutions to the practical labs?
A: Yes, C code and Device Tree solutions are shared at the end of each lab.
See also our FAQ for all types of courses and our sustainability efforts.