Key Lessons for New Linux Driver Engineers: Device Trees, Toolchains, Kernel Integration

Device Tree

When starting with Linux driver development, the typical workflow begins with a simple .c file that implements module_init and module_exit, prints a hello‑world message via printk, and is built into a .ko module loaded with insmod. Later, the engineer discovers device trees ( .dtb) and learns that not only the Linux kernel but also other programs such as U‑Boot can have their own device trees, provided they implement the device‑tree mechanism and related Kconfig support.

Toolchain

Cross‑compilation toolchains supplied by hardware vendors are often used, but swapping to a custom toolchain can cause runtime failures. Errors like "xxx command not found" or missing GLIBC versions arise because different toolchains may use different C libraries ( glibc, uclibc, musl) and GCC versions, leading to incompatibilities between the compiled binary and the target filesystem.

For example, a toolchain built with gcc10 and glibc may only support glibc 2.30; compiling the same source with a gcc12 toolchain on that filesystem will trigger "glibc version not found" errors.

Filesystem

The relationship between the toolchain and the target root filesystem is critical. Even though driver development focuses on kernel modules, understanding key filesystem files such as /etc/init.d/rcS, inittab, passwd, and shadow is necessary for early driver loading and system initialization.

Before delivering a filesystem to a customer, developers often replace the default username and password (e.g., setting root with the company name) by editing these files.

Integrating Drivers into the Kernel

Adding a driver to the kernel requires more than editing a Makefile. The driver must also be referenced in the appropriate Kconfig entry and enabled via the menuconfig (or menconfig) interface.

After building, verify that an .o file is produced and check the driver’s initialization level ( module_init, arch_initcall, etc.). Use printk to output the initcall level and the address of the init function, then disassemble vmlinux to confirm the probe function runs.

Manual defconfig Modifications

Modifying a default configuration ( make xxx_defconfig) by adding a macro such as CONFIG_XXX=y often fails unless the corresponding entry is also added to the relevant Kconfig file. Dependencies between configuration options can also prevent a setting from taking effect.

The safest approach is to use menuconfig to enable options, only editing defconfig directly when the relationships are fully understood.

Source Code Tracing and Debugging

While various kernel debugging tricks exist, adding strategic printk statements remains the most reliable method for tracing issues. When investigating complex problems (e.g., kernel self‑extraction), focus on function parameters and call flow rather than deep‑diving into algorithmic code unless it directly relates to the bug.

How Many Drivers Should You Know?

Junior driver engineers start with simple drivers (clocks, timers, LEDs). Advancing to complex drivers (USB, network cards) requires understanding foundational concepts such as clocks, resets, and DMA, as these are used by higher‑level drivers.

Job Responsibilities

A Linux driver engineer is effectively a low‑level systems developer, handling not only kernel drivers but also U‑Boot, filesystem, and board bring‑up tasks. In some organizations, responsibilities may be split between system‑level and driver‑level work, but the core skill set spans the entire embedded Linux stack.