SoCs and hardware platforms: Factors influencing embedded software development

• The choice of platform influences the effort required for initial commissioning, driver integration, kernel customisation and subsequent product maintenance
• From a software perspective, an SoC only becomes a usable platform through the combination of board design, bootloader, device tree, BSP and drivers
• A well-maintained, traceable BSP is usually more important than an extensive list of features in the datasheet
• Components that are close to the mainline can facilitate kernel upgrades and maintenance; however, project-specific manufacturer customisations often remain necessary
• Update and recovery strategies, reproducible builds and documented customisations must be taken into account right from the platform selection stage

An embedded system does not run on an abstract processor. It is based on a specific combination of SoC, memory interface, power supply, peripherals, board layout, bootloader, operating system and application. This combination determines which functions are available, how they are initialised and how well they are supported by the chosen software stack.

The CPU is just one component of a system-on-chip. For embedded software development, the key factors are how the entire platform is structured and which subsystems are actually used in a specific product variant.

Factors of relevance include, amongst others:

• memory architecture and memory bandwidth
• DMA and interrupt architecture
• interfaces such as Ethernet, USB, SPI, I²C, UART or CAN
• display, graphics and, where applicable, camera interfaces
• audio, network and communication blocks
• mechanisms for booting, debugging and system recovery
• power and clock management

These characteristics have a direct impact on drivers, data paths, latencies and system integration. A comprehensive range of peripherals is not automatically an advantage. Every function that is actually used requires a robust software foundation, a transparent configuration and testing under realistic load and fault conditions.

What matters is not what an SoC offers in theory, but which functions can be reliably integrated and maintained in the long term on the intended kernel and BSP basis.

The Board Support Package, or BSP for short, provides the hardware-specific software foundation for a specific board or platform family. It bridges the gap between the general operating system foundation and the specific characteristics of the target hardware.

In a Linux-based system, a BSP typically comprises:

• bootloader configuration and customisations
• kernel configuration and, where applicable, kernel patches
• device tree descriptions
• drivers and firmware components
• build configurations, layers and recipes
• peripheral initialisation and system-specific settings

A BSP may be provided as a manufacturer’s base, as the foundation for a system-on-module supplier, or as a customised further development. It is not merely a question of whether a BSP is available. It must be assessed whether it is suitable for the planned product and whether its technical basis will remain manageable in the long term.

A data sheet describes the hardware capabilities of an SoC. However, what is crucial for a product is whether the required functions are available in the intended software stack in a stable, documented and testable form.

The driver layer should be examined with particular care if a product relies on specialised or complex peripherals, such as:

• display and touch interfaces
• graphics and video paths
• camera and image sensor integration
• audio components
• fieldbus and communication interfaces
• customer-specific sensors or actuators
• power management components

If a suitable driver is missing or an existing driver is not compatible with the kernel base being used, work is required across several layers: in the driver itself, in the device tree, during initialisation, in the build system and during validation. This may be sensible and necessary – but must be planned for as a specific scope of development.

We have proven project experience, particularly with Linux BSPs, camera integrations and specialised drivers on i.MX platforms.

In many ARM-based Linux systems, the device tree describes the specific hardware configuration. For example, it specifies which components are present, which pins and buses are used, which interrupts are assigned, and how peripherals are enabled.

In the case of a custom hardware platform, this includes, amongst other things:

• pin multiplexing and GPIO mappings
• memory and bus connections
• interrupt mappings
• clock sources and reset lines
• activation of interfaces and peripherals
• parameters for connected devices such as displays, sensors or communication modules

The device tree does not replace driver development. However, it provides the kernel with the information that existing drivers require to correctly recognise and initialise hardware. Incorrect or incomplete descriptions often lead to boot failures, unstable peripherals or runtime issues that are difficult to reproduce.

For product variants, the hardware description should be versioned, documented and clearly separated from general platform components. This improves maintainability, debugging and future migrations.

The term ‘mainline proximity’ refers to a situation where kernel drivers and hardware descriptions are as closely aligned as possible with the official Linux kernel and its established subsystems. This can offer advantages, as components are more likely to be further developed and tested by a wider community with new kernel versions.

Possible advantages include:

• reduced porting effort during kernel upgrades
• a more transparent driver and patch base
• better traceability of bug fixes
• less dependence on individual, proprietary custom implementations
• clearer prospects for long-term maintenance.

However, proximity to the mainline is not a universal selection criterion. Vendor BSPs often include support for new SoCs, specialised graphics or multimedia functions, and manufacturer-specific extensions that are not yet available – or not fully available – in the mainline kernel.

The right question is therefore not: “Is everything in the mainline?”

But rather: “What deviations are required for our product, how well are they documented, and how can they be maintained over the planned lifecycle?”

A system is not capable of being updated simply because it has a bootloader. A robust update and recovery strategy is the result of the interaction between several components:

Long-term availability is often reduced to the availability of SoCs, memory or communication modules. Whilst this is necessary, it is not sufficient. A platform can only remain usable in the long term if its software base can also be maintained, understood and, where necessary, further developed.

A platform change during the product lifecycle is usually not merely a matter of replacing the SoC. Depending on the architecture and peripherals, the bootloader, kernel, drivers, device tree, build system, tests and application may all be affected. A software base that is assessed at an early stage therefore reduces the risk of subsequent, unplanned redesigns.

Before deciding on an SoC, system-on-module or custom board, hardware and software managers should carry out a joint technical assessment.

Checklist for platform selection

• Which functions and interfaces are actually required in the production product?
• Which of these are verifiably supported by the intended BSP and kernel version?
• Which drivers need to be adapted, extended or developed from scratch?
• How are board variants, device tree customisations and patches versioned?
• Which bootloader and which memory layout support updates and recovery?
• How are images created and tested in a reproducible manner?
• What dependencies exist with regard to SoC, module or BSP suppliers?
• How realistic are kernel upgrades, bug fixes and hardware migrations over the planned product lifecycle?

Such an assessment is no substitute for architectural work. However, it prevents critical risks from only becoming apparent once the hardware has already been finalised and integration is well advanced.

The best platform is not necessarily the one with the highest computing power or the longest list of features. It is the one that meets the product’s requirements whilst also providing a robust foundation for integration, updates, fault analysis and long-term maintenance.

To achieve this, the SoC, target hardware, BSP, drivers, boot chain and build process must be evaluated together right from the start. Choosing a platform is therefore an architectural decision spanning the entire product lifecycle – not merely a preliminary decision in hardware development.