Drivers, device trees, bootloaders: what really needs to be customised in embedded integration projects

From the outside, an embedded project often appears to be simply a matter of the application or the user interface. In practice, however, the real risk usually lies in the basic integration.

Even minor discrepancies in

• memory connectivity
• display
• touch
• GPIOs
• interrupts
• power supply
• interfaces

can mean that, whilst a standard BSP may boot up in principle, it does not yet result in a viable product.

The fact that, according to Yocto, BSPs explicitly include additional hardware drivers and other software components beyond a generic Linux stack highlights precisely this reality: product integration is almost always more than just ‘Linux running’.

A common misconception is to view the bootloader as a purely technical preliminary stage. In fact, it plays a key role in determining

• how a device boots up,
• which console is active,
• which images are loaded,
• and how recovery or update scenarios can be implemented

Ubuntu itself documents that the bootloader uses the device tree for its configuration – including the devices present on the board, the UART for the console, the image format and even public keys for Secure Boot.

This makes it clear: as soon as the boot medium, recovery behaviour, update path or Secure Boot requirements become project-specific, the bootloader also becomes part of the customer-specific system integration.

In the Linux environment, custom integration is very often carried out via the device tree. The kernel documentation describes it as a data structure and language for describing hardware, so that the operating system does not have to hard-code machine-specific details.

Among other things, it describes:

• buses
• interrupts
• GPIO connections
• peripheral devices
• other hardware properties

This is crucial for integration projects, as it is precisely here that it is determined which components the system actually recognises and how they are connected.

This is not merely a detail for new platforms. The kernel documentation explicitly states that, in many embedded architectures, the device tree has replaced the previous hardware description via board files.

This is precisely why device tree customisations are among the most common tasks in integration projects, for example when dealing with:

• new I²C or SPI components,
• modified GPIO mappings,
• customised interrupts,
• additional regulators,
• different display timings,
• new touch controllers.

Not every project requires completely new kernel drivers. Very often, the initial focus is on correctly integrating existing drivers with the specific hardware and stabilising their interaction with the system.

This is particularly typical for SoC-based devices: the kernel documentation describes platform devices as units that can be addressed directly via the CPU bus, a category that includes many controllers integrated onto the SoC. Drivers for these follow the standard model with probe() and remove() methods; device detection takes place outside the driver. In practical terms, this means that even if resources, addresses, IRQs or hardware variants are not clearly defined, a theoretically available driver does not automatically result in stable product integration.

Equally important is the distinction between kernel-space and user-space solutions.

For some SPI interfaces, user-space access can be useful for prototyping; the kernel documentation explicitly mentions simple protocols or experimental use cases in this context. However, it also makes it clear that certain drivers cannot be implemented effectively in user space because they require kernel interfaces such as IRQ handling or other parts of the driver stack.

This is an important point in projects: not every peripheral can be permanently connected ‘simply from within the application’.

Manufacturers of SoCs or evaluation boards usually supply a working base system. This is valuable for the initial set-up and initial testing. However, it is often not sufficient for a production product.

The Yocto definition of a BSP alone shows that hardware support involves not only configurations and drivers, but also additional software for essential and optional platform features.

In practical terms, this means that as soon as

• product variants,
• custom peripheral designs,
• special boot logic,
• security requirements
• or custom update paths

come into play, the initial BSP must be further developed to make it production-ready.

A single successful boot on a prototype does not constitute robust system integration. A project only becomes viable once the hardware description, bootloader customisations, kernel configuration, driver versions and additional software can be built and versioned in a reproducible manner.

This is precisely why the Yocto Project works with structured BSP layers and clear file structures. For product teams, this is not just a matter of organisation, but a prerequisite for keeping variants, releases and subsequent maintenance manageable.

In embedded projects, the greatest effort is often not required for individual, spectacular new developments, but rather for the interfaces between the layers:

• The bootloader must initialise the target system correctly.
• The device tree must accurately describe the actual hardware.
• Drivers must interface with the specific resources and interfaces.
• The software above must be able to utilise the whole system reliably.

The fact that U-Boot and Linux both rely on the device tree, and that, according to Yocto, BSPs are designed to structure precisely this hardware-software coupling, clearly demonstrates why integration projects are rarely just ‘driver work’ or just ‘application work’.

In custom embedded projects, work is usually not limited to the application itself. The layers beneath it are particularly relevant to the product:

• Bootloader
• Device Tree
• Kernel configuration
• Driver integration
• Build and maintenance process

Not every one of these components needs to be created from scratch in every project. However, almost every professional embedded project requires targeted customisation, stabilisation and structuring in precisely these areas.

If these layers are addressed too late, there is a risk that problems arising from the basic integration will only become apparent during testing, field operation or maintenance.