Custom Driver Integration
Custom Driver Integration
This section demonstrates how a custom out-of-tree driver can be integrated into the Yocto workflow used in this workspace.
The example is intentionally simple, but it follows the same structure commonly used for platform-specific drivers in Jetson systems.
The complete integration path includes device tree integration, driver binding, Yocto packaging, automatic module loading, and runtime validation through sysfs and character devices.
Integration Flow
The driver integration flow can be summarized as:
The overlay creates the platform device definition, the kernel driver binds through a compatible string match, and the runtime interfaces become available once the module loads successfully.
This is the same integration model commonly used by real platform drivers, sensors, and custom peripherals in embedded Linux systems.
Driver Recipe
The driver is packaged as a standard Yocto kernel module recipe:
layers/meta-tegrademo/recipes-kernel/tegrademo-sysfs-example/ └── tegrademo-sysfs-example_1.0.bb
Implementation files:
files/ ├── Makefile └── tegrademo_sysfs_example.c
The recipe uses:
inherit module
The Yocto module class provides the infrastructure required to build out-of-tree kernel modules against the active target kernel configuration.
This allows Yocto to compile, package, and deploy the driver automatically as part of the image build workflow.
Driver Behavior
The driver is implemented as a platform_driver and binds to a device tree node created by the overlay.
Once loaded, it exposes:
- A character device:
/dev/tegrademo0 - Sysfs attributes under:
/sys/bus/platform/devices/tegrademo_overlay_demo/
Runtime attributes:
| Attribute | Type | Description |
|---|---|---|
value
|
Read / Write | Runtime integer value |
label
|
Read only | Device label from DT |
test_string
|
Read only | String loaded from DT |
The original device tree property uses:
test-string
while the sysfs interface exposes:
test_string
This conversion is normal when mapping device tree properties into sysfs attributes because Linux sysfs naming conventions typically avoid hyphenated attribute names.
Device Tree Binding
The overlay creates the platform node using:
compatible = "oe4t,tegrademo-overlay-demo";
The driver matches this compatible string through its of_match_table.
During probe, the driver reads:
labeltest-stringinitial-value
These values are then exposed through the runtime interfaces created by the driver.
This binding model is commonly used by Linux platform drivers to associate runtime driver behavior with device tree-defined hardware descriptions.
Module Autoload
The recipe configures the module to load automatically at boot:
KERNEL_MODULE_AUTOLOAD += "tegrademo_sysfs_example"
This ensures the driver is available immediately after boot without requiring manual insertion through modprobe or insmod.
The module autoload configuration is packaged into the final image as part of the Yocto integration flow.
Image Integration
The module is included through the common validation packagegroup:
packagegroup-demo-basetests.bb
Packagegroups are commonly used in Yocto to group related packages, validation utilities, drivers, and test components into reusable image features.
As a result, the driver becomes part of the standard bring-up and validation workflow used throughout the project.
Build and Deployment
Build the module independently:
bitbake tegrademo-sysfs-example
Or rebuild the full image:
bitbake demo-image-base
Verify that the generated module exists in the deploy artifacts:
find tmp/deploy -name '*tegrademo*'
After rebuilding the image, flash the updated system:
./initrd-flash
For a comparison between the available Jetson flashing approaches, see:
Additional flashing details are covered in:
Validation on Target
After boot, verify that the driver loaded correctly:
dmesg | grep tegrademo
Expected output:
tegrademo_sysfs_example: loading out-of-tree module taints kernel. tegrademo-sysfs-example tegrademo_overlay_demo: bound label=tegrademo overlay demo test-string=jetson-agx-orin initial-value=42
The "taints kernel" message is expected for out-of-tree modules and does not necessarily indicate a functional problem.
Validate the runtime interfaces:
ls -l /dev/tegrademo0 ls /sys/bus/platform/devices/tegrademo_overlay_demo cat /sys/bus/platform/devices/tegrademo_overlay_demo/label cat /sys/bus/platform/devices/tegrademo_overlay_demo/test_string cat /sys/bus/platform/devices/tegrademo_overlay_demo/value
Update the runtime value:
echo 77 > /sys/bus/platform/devices/tegrademo_overlay_demo/value cat /dev/tegrademo0
Successful validation confirms:
- The overlay created the platform node
- The driver bound correctly
- The module loaded automatically
- Sysfs interfaces are operational
- The character device is functional
Troubleshooting
If the driver does not appear after boot, verify:
- The device tree overlay was applied correctly
- The compatible string in the overlay matches the driver
of_match_table - The module recipe was included in the image
- The image was rebuilt after adding the driver package
- The board was reflashed with the updated image
- The module autoload entry is present
- The generated module exists in the deploy artifacts
Useful debug commands:
dmesg | grep tegrademo
lsmod | grep tegrademo
find /sys/bus/platform/devices -name '*tegrademo*'
ls -l /dev/tegrademo0
modinfo tegrademo_sysfs_example
A common issue is rebuilding only the module without rebuilding and reflashing the final image that includes it.
In some cases, stale deploy artifacts or cached module packages may also require rebuilding the image completely before reflashing.
Key Repository Files
layers/meta-tegrademo/recipes-kernel/tegrademo-sysfs-example/ layers/meta-tegrademo/recipes-bsp/tegrademo-device-tree-overlays/ layers/meta-tegrademo/recipes-demo/packagegroups/