Hardware Development for Linux Systems
Hardware Development for Linux Systems
Linux can significantly shorten the development of an embedded product. That only works when the hardware fits the Linux model. Good drivers, a clean Device Tree and a carefully designed circuit belong together.
This article is aimed at developers planning custom Linux hardware. Its focus is on ARM and SBC-based systems, but most principles apply to other platforms as well.
Why Linux?
Linux provides a large amount of proven infrastructure:
- networking and routing,
- file systems,
- user and permission management,
- logging and diagnostics,
- graphics and cameras,
- update mechanisms,
- security features,
- stable user-space APIs.
The tools are already available. An Ethernet interface can be checked with ip, ping, ethtool, tcpdump, and iperf3. I²C can be inspected with i2cdetect and i2ctransfer. Cameras use V4L2 and Media Controller tools.
This saves development time. More importantly, it reduces the amount of custom software that must be maintained for years.
Hardware Determines the Linux Effort
Linux does not provide these benefits automatically. Hardware decisions either support them or work against them.
A good design uses established kernel subsystems. A poor design creates special cases:
- private kernel patches,
- custom drivers,
- old vendor BSPs,
- manual steps after every update,
- failures that are difficult to reproduce.
The central rule is simple:
Connect hardware in the way expected by the existing Linux driver and its Device Tree binding.
Not every electrically possible connection is a good Linux solution.
Target Platform and BSP
It is not enough for one driver to fit. The whole platform must fit.
Define these items before drawing the schematic:
- target SoC,
- Linux distribution,
- kernel version,
- vendor BSP or mainline kernel,
- expected product lifetime.
A mainline driver is an excellent starting point. It may still require a particular kernel configuration or SoC feature. The target kernel must include and enable it.
For example, an Ethernet MAC-PHY driver can exist while a required kernel option is missing from the selected image. The component is then still not usable as intended.
Questions to answer early:
- Is the target kernel actively maintained on the selected SoC?
- Is there a current evaluation board?
- Do the required interfaces work on the target kernel?
- Is the required kernel configuration available?
- What are the restrictions of the vendor BSP?
- Can the product move to a later LTS kernel?
Recommended source: Linux Kernel Documentation – Driver Implementer’s API Guide
Component Selection: Mainline First
Component selection is the most important decision in a Linux hardware project. It has a larger effect on maintenance than many layout details.
A driver in the official Linux kernel is the gold standard. It is built with new kernel versions and used by a broad community. This simplifies updates and reduces long-term risk.
The associated Device Tree bindings should also be upstream. A driver without a documented binding is not a complete solution.
Verify Mainline Support Properly
The statement “Linux supported” is too vague. It can mean:
- an old vendor patch,
- a GitHub repository with no maintenance commitment,
- a binary kernel module,
- a driver in a vendor BSP,
- a driver in the official Linux kernel.
These cases are not equivalent.
Check:
- the Linux Kernel Documentation,
- the Linux source tree,
- the driver directory,
- Device Tree bindings,
- current LTS kernels,
- public patch and discussion history.
After a mainline driver, there is a large gap. A local patch may work today, but it often needs maintenance for a security update or the next LTS kernel.
If a non-mainline driver is used, the company should be able to maintain it itself. That means source code, a build system, tests, kernel knowledge, and clear ownership.
Components Without a Dedicated Linux Driver
A component without a dedicated Linux driver is not always a disqualifier. Simple register interfaces over I²C, SPI, or GPIO can sometimes be used deliberately from user space.
This can suit:
- a small control function,
- a simple ADC,
- an FPGA with a well-defined register interface,
- a prototype or bring-up setup.
However, the API, error handling, and long-term ownership still need to be planned. i2c-dev and spidev are tools. They do not automatically replace a sound driver model.
Firmware, Availability, and Lifecycle
Many components need firmware. This includes WLAN, cameras, Ethernet switches, FPGAs, and accelerators.
Check early:
- Is the firmware available and redistributable?
- How is it updated?
- Which firmware version matches which driver?
- Is there a longevity commitment?
- Are there errata and a current evaluation board?
A technically well-supported but obsolete component is not a good foundation for a new product.
Device Tree: Hardware as a Data Model
The Device Tree describes hardware to the kernel. It includes buses, addresses, interrupts, reset lines, regulators, clocks, GPIOs, and pin multiplexing.
It is therefore the contract between the schematic and Linux.
A good workflow is:
- Select the driver.
- Read the Device Tree binding.
- Design the circuit accordingly.
- Create the overlay in parallel.
- Test it with the target kernel.
If a hardware design cannot be described cleanly in the Device Tree, that is a serious warning sign. It may indicate an unsuitable driver model or an unnecessary special case.
Recommended source: Linux and the Devicetree
Connecting Components
A driver defines more than the communication protocol. It often also defines:
- valid clock frequencies,
- interrupt polarity,
- reset behavior,
- GPIO functions,
- power supplies,
- data formats,
- supported operating modes.
A hardware feature is only useful when the driver can configure it.
Examples:
- An IC accepts several clocks, but the driver supports only one.
- A data-sheet pin has several functions, but the driver uses it only as reset.
- A camera deserializer supports lane swapping, but the binding does not describe it.
The driver is part of the component specification.
Pinmux and Boot Straps
An SoC pin is rarely just a GPIO. It may also be SPI, I²C, UART, PWM, a clock, a debug signal, or a boot strap.
For every used pin, check:
- alternate functions,
- internal pull-ups and pull-downs,
- state after reset,
- state during boot,
- use by boot ROM or firmware,
- availability to Linux.
An incorrect pull resistor can prevent booting. A pin can also drive an unwanted level briefly during startup. This is particularly important for reset, enable, and load-switch signals.
Pinmux and pin control should be tested early with the target kernel.
Clocks
Clock signals need the same care as high-speed data lines.
Check:
- frequency and tolerance,
- jitter,
- direction: input or output,
- startup behavior,
- enable signal,
- voltage level,
- distribution to multiple receivers.
Shared clocks are possible, but all connected components must support the arrangement. Ethernet, PCIe, USB, MIPI-CSI, MIPI-DSI, and audio are particularly sensitive.
Interrupts and Reset
Linux can use many GPIOs as interrupts. The selected interrupt must still fit the driver and the hardware.
Check:
- edge or level,
- active high or active low,
- pull-up or pull-down,
- state during reset and boot,
- interrupt capability of the SoC pin.
Shared interrupts should be the exception. They are appropriate only when both hardware and driver explicitly support them.
Reset lines should not be shared without a good reason. A driver may request a reset at any time. A global reset can then affect unrelated devices.
Where possible, plan:
- separate reset lines,
- clear reset polarity,
- defined minimum duration,
- a safe power-up state,
- defined behavior after a watchdog reset.
Distinguish power reset, hardware reset, and software reset. They often have different effects.
Power Supplies and Power Sequencing
Power is part of Linux integration. Many drivers and bindings model regulators, enable signals, and dependencies.
Check:
- required rails,
- power-up order,
- voltage ramps,
- power-good signals,
- enable signals,
- inrush current,
- brown-out behavior,
- power-down order.
A shared power-enable signal can cause the same problems as a shared reset. If one driver turns off a rail, it must not disturb an independent device.
After restart, brown-out, and power interruption, the hardware must return to a defined state.
Recommended source: Linux Regulator Framework
I²C
I²C is simple, but it is not automatically robust.
Address 0x00 is reserved for the General Call. It must not be used as an ordinary target address.
Before the schematic, check:
- duplicate addresses,
- address pins or address registers,
- required pull-ups,
- bus capacitance and cable length,
- multiple voltage domains,
- reset or power isolation for individual devices.
Prevent back-powering. A powered-down device must not supply the bus through its I/O protection diodes.
Plan for faults as well:
- What happens when SDA is permanently low?
- What happens when SCL is permanently low?
- Is bus recovery possible?
- Can a faulty device be isolated?
Practical Example: Identical Sensor Addresses
Two identical cameras often have the same fixed sensor address. In a dual GMSL2 system, both IMX708 sensors can use native address 0x1a.
To let Linux address them separately, each link receives an I²C alias. In the BE-IIS GMSL2 setup, these are, for example, 0x52 and 0x53.
This shows that address planning is part of system architecture. It is not merely a schematic detail.
Sources: Linux I²C/SMBus, BE-IIS GMSL2 Camera Installer
SPI
SPI needs clear resource planning.
Check:
- number of chip-select lines,
- active polarity,
- maximum clock rate,
- timing,
- DMA support,
- interrupt line,
- data rate and CPU load.
GPIOs can be used as chip selects. Those GPIOs must be described in the Device Tree. An additional CS is therefore not an arbitrary spare GPIO. It is part of the defined SPI topology.
Practical Example: A Third Chip Select
Many SBCs provide two hardware SPI chip selects. A GPIO-based CS can be used for a third device.
The HAT++ concept deliberately extends SPI0 to three CS lines. The assignment is defined in advance. This allows several interface HATs to be combined without accidental chip-select conflicts.
At high data rates, SPI is not a free replacement for Ethernet or PCIe. Throughput, interrupt load, and CPU load must be measured.
Sources: Linux SPI subsystem, BE-IIS Installer
GPIOs and High-Speed Interfaces
Before using a GPIO, verify that it is really free. Many pins are already assigned to boot straps, debug, SD card, eMMC, Ethernet, USB, display, camera, or PMIC functions.
With SoCs that have several processor domains, ask additional questions:
- Does the GPIO belong to the application core?
- Is it used by a real-time core?
- Does firmware control it?
- Can Linux really use it?
For PCIe, USB 3, Ethernet, and MIPI, drivers do not solve signal-integrity problems.
Check early:
- stack-up,
- impedance,
- differential pairs,
- length matching,
- stubs,
- termination,
- reference planes,
- ESD protection,
- power integrity.
An interface can work briefly in the lab and still fail in the field. Common causes are return-path problems, poor supply design, and unsuitable protection components.
Sources: GPIO descriptor interface, Linux PCI documentation
Real Time
Linux is not automatically real-time capable. PREEMPT_RT also has limits.
Linux is very well suited to:
- networking,
- configuration,
- logging,
- visualization,
- data storage,
- diagnostics,
- updates.
For hard real-time work, a microcontroller, FPGA, or dedicated controller is often a better choice.
This includes:
- exact pulse sequences,
- fast control loops,
- very low latency limits,
- bit-accurate protocols,
- time-critical bus control.
LIN is a typical example. The timing-critical part often belongs in a communication controller or small embedded MCU. Linux then handles the higher-level logic.
Recommended source: Linux real-time documentation
Fieldbuses and Ethernet
Linux supports CAN very well. SocketCAN integrates CAN as a network interface in the Linux networking stack.
CAN remains useful for:
- machinery,
- vehicles,
- installed equipment,
- robust fieldbus communication.
An embedded Linux system should still consider Ethernet early. Ethernet provides IP, routing, familiar diagnostics, and remote access.
Single Pair Ethernet
Single Pair Ethernet is attractive for industrial systems. SPI-connected MAC-PHYs make Ethernet possible even on small Linux systems.
This works well for control and diagnostic data. For high data rates, a native Ethernet MAC and PHY are usually the better option.
The goal is always a normal Linux network interface. Application and diagnostics can then use standard tools.
The BE-IIS HPP-T1L practical test tests an SPI-connected 10BASE-T1L interface with ping and iperf3 just like a normal Linux network interface. It also shows how hardware, Device Tree, driver, and test scripts become a usable interface together.
Stable Names for Applications
Kernel device names are not always stable. The order of network interfaces, UARTs, and USB devices can change.
Applications should not rely on accidental names.
Useful methods are:
- udev rules,
- symbolic links,
- unambiguous Device Tree nodes,
- documented instance names,
- fixed MAC addresses.
A name such as beiis-t1l0 is more robust for test scripts and systemd services than assuming that eth1 always refers to the same hardware.
Sources: udev documentation, BE-IIS udev rules
Cameras
Cameras are a project of their own. Selection starts with the Linux driver.
Check:
- mainline or platform driver,
- supported sensor modes,
- resolution and frame rate,
- Bayer format,
- HDR,
- autofocus,
- embedded data,
- firmware,
- ISP pipeline.
A MIPI camera system often consists of a sensor, serializer, deserializer, CSI receiver, I²C tunnel, clocks, reset, power supplies, Device Tree, and media pipeline.
All of these parts must fit together.
Use lane or pin swaps only when driver and binding explicitly describe them. A hardware capability alone is not sufficient.
A staged bring-up saves time:
- Check power and reset.
- Check the I²C control path.
- Check aliases.
- Load the overlay.
- Detect the sensor.
- Configure the CSI pipeline.
- Start the video stream.
This makes it much easier to assign a failure to the control path, the Device Tree, or the video pipeline.
Sources: Linux media subsystem, V4L2 documentation, BE-IIS GMSL2 Camera Installer
Displays
Displays also need early Linux validation.
Check:
- interface: HDMI, LVDS, MIPI-DSI, eDP, or RGB,
- resolution,
- frame rate,
- timing and pixel clock,
- backlight control,
- touch controller,
- EDID,
- panel initialization.
MIPI-DSI is more than an electrical interface. Panel, SoC, bridge IC, and driver must work as one system.
Hardware Monitoring and Thermal Design
Professional systems should monitor their supplies and temperatures.
Typical values are:
- core voltages,
- supply rails,
- current,
- temperatures,
- fan speed,
- alarm limits.
This helps during bring-up and in the field. Problems become visible earlier:
- an undervoltage on the core rail,
- an unstable external supply,
- a failed fan,
- thermal overload.
The monitoring IC also needs a suitable driver. Measurement range, scaling, and sensor placement must match the real hardware.
Source: Linux hwmon subsystem
Boot, Debug, and Recovery
Always provide debug access.
At minimum, consider:
- a UART console,
- JTAG or SWD for MCU and FPGA,
- test points for supplies,
- test points for reset,
- test points for important buses.
The UART console is often the most important access path. When networking, graphics, or the application fail, it may be the only remaining way to diagnose the system.
Where possible, reuse the proven UART circuit from the evaluation board. Experiments with levels, pull resistors, or pinmux are expensive on early prototypes.
JTAG or SWD helps with first programming, bootloader problems, MCU debugging, FPGA programming, and recovery. It remains valuable even when no kernel development is planned.
Flashing and Bootloaders
The question is not only: How does Linux run? It is also: How does Linux get onto the device?
Flashing is often a multi-stage process:
- Program a bootloader through JTAG or a vendor tool.
- Establish a connection through UART, USB, or Ethernet.
- Configure the bootloader.
- Transfer the Linux image.
- Update the root file system and application.
Hardware needed at boot often requires support in boot ROM, firmware, or bootloader.
This includes:
- boot flash,
- eMMC,
- SD card,
- DDR,
- PMIC,
- Ethernet for recovery or network boot.
A Linux driver cannot help at this stage because the kernel is not running yet.
Source: U-Boot Documentation
Update Concept
A product often contains more than Linux. Updates can affect the bootloader, kernel, root file system, application, MCU firmware, FPGA bitstream, or device firmware.
Plan:
- version dependencies,
- update order,
- interruption during update,
- error detection,
- fallback,
- A/B update strategy,
- signature verification,
- permissions.
An update without a recovery concept is not a robust update concept.
Security
Security begins with hardware.
Ask early:
- Which keys are needed?
- Where are they stored?
- Who programs them?
- Can they be read or replaced?
- How are debug ports protected?
Possible measures include:
- Secure Boot,
- signed updates,
- TPM,
- secure element,
- protected key storage,
- disabled or protected debug ports,
- secure production programming.
Not every product needs all measures. The architectural decision must still be made early.
Production and System Test
Testability begins in the schematic.
Check:
- Can important rails be measured?
- Are reset lines accessible?
- Can GPIOs and buses be tested?
- Is there a production-test mode?
- Can the hardware revision be read?
Production often also needs to program:
- serial number,
- MAC address,
- certificates,
- keys,
- calibration data,
- hardware revision.
These data need a documented and protected process.
Documentation on the PCB
Early hardware moves between benches and people. Good markings save time.
Useful markings include:
- clear connector names,
- voltage labels,
- test point names,
- a visible hardware revision,
- reset and boot buttons,
- UART and JTAG pins,
- a QR code linking to documentation.
A clearly marked RESET-SOC button is often more useful during bring-up than a reference designator such as S4.
Bring-Up Linux and Tools
A small bring-up image is extremely useful. It should include login, a terminal, SSH, kernel logs, and diagnostic tools.
| Task | Tools | Documentation |
|---|---|---|
| Kernel logs | dmesg -w, journalctl -kf |
dmesg, journalctl |
| Networking | ip, ping, ethtool, tcpdump, iperf3 |
ip, ethtool, tcpdump, iperf3 |
| I²C | i2cdetect, i2ctransfer |
i2c-tools |
| GPIO | gpioinfo, gpioget, gpioset |
libgpiod tools |
| Camera | v4l2-ctl, media-ctl |
v4l2-ctl, media-ctl |
| Performance | htop, stress-ng, perf |
perf |
Create test scripts during bring-up. They later help with regression testing, production, and support.
Conclusion
A Linux system does not begin when an image is flashed.
Good Linux hardware follows one shared model:
- platform,
- kernel,
- driver,
- Device Tree,
- electrical connection,
- standard Linux interfaces.
The best hardware solution is not always the most flexible circuit. It is the solution that works reliably with a maintained Linux system over the product lifetime.
Special solutions are not inherently wrong. They must be developed deliberately, tested, documented, and maintained for the life of the product.
Further Reading
Linux and Kernel
- Linux Kernel Documentation
- Device Tree Usage Model
- Device Tree Specification
- Driver Implementer’s API Guide
- SocketCAN
- Linux Media Documentation
- U-Boot Documentation