In this lesson, you will learn how to diagnose driver initialization failures and verify hardware state by leveraging the kernel’s logging buffer and virtual file system interfaces.
When working with embedded Linux, your code often communicates with hardware via drivers that exist in kernel space. When things go wrong—such as a sensor failing to respond or a peripheral refusing to initialize—you need visibility into the "black box" of the kernel.
Inspecting Events with dmesg
The dmesg command provides access to the kernel ring buffer, which stores messages generated by drivers during boot and runtime. When a driver fails to probe your hardware, it often leaves a "bread-crumb" trail here. To catch errors as they happen, use:
dmesg -w
If you suspect a specific driver, you can filter for relevant keywords: dmesg | grep -i "my_sensor_driver". This helps identify if the kernel successfully matched your Device Tree node to the driver or if a resource conflict occurred.
Probing Status with Sysfs
While dmesg shows you the history of what happened, /sys (the sysfs filesystem) allows you to inspect the current state of your hardware. Sysfs is a virtual filesystem that exports kernel objects (like devices, buses, and classes) as a tree of files.
If you are debugging a GPIO-based peripheral, you don't need to write a full application to test it. You can interact with the driver directly through sysfs:
# Check if a device is registered
ls /sys/bus/platform/devices/my-device/
# Read the status of a specific device attribute
cat /sys/bus/platform/devices/my-device/status
If a driver reports an "invalid argument" or "probe failed," check the associated files in /sys/bus/platform/drivers/ or /sys/class/. Often, a driver will expose diagnostic nodes (like power, fault, or calibration) that you can read or write to in real-time to force state changes or confirm that the hardware is responding to configuration commands. By correlating the boot-time errors found in dmesg with the runtime state observed in sysfs, you can isolate whether an issue stems from a faulty Device Tree description or a hardware communication timeout.
Key Takeaway: Use dmesg to uncover the origin of initialization errors and use sysfs to actively probe and manipulate the live state of your drivers.