Linux BSP and Driver DevelopmentKernel, Device Tree and Board Bring-Up

• Companies with a custom board that needs Linux brought up: the boards are back, the serial console prints nothing, peripherals are not recognised, and someone needs to take the system from bootloader to running application.

• Teams missing peripheral drivers: the vendor kernel has no driver for your part, or has one that is not stable.

• Router and gateway vendors who need custom features and protocol integration on OpenWRT.

• Clients inheriting legacy Linux devices whose vendor SDK is old and unmaintained, and who need someone to take it over and keep it moving.

A BSP (board support package) is not finished when the kernel boots. Bootloader and boot parameters, device tree configuration, peripheral drivers, the root file system and auto-start services are all in scope, up to the point where the application processes run stably. The Allwinner R528 control board is a complete example: from Tina-Linux up to the WebSocket control service, including five UART channels, GPIO and USB drivers and auto-start management, all delivered. Boundaries are agreed per project in the contract.

The Allwinner R528 control board runs Tina-Linux. The challenge was keeping multiple peripheral drivers and web services running stably side by side on the R528 over long periods. Delivered: peripheral drivers for five UART channels plus GPIO and USB, an HTTP channel for file (photo) transfer, a WebSocket channel for real-time control, GCODE file dispatch, and auto-start service management. Drivers and upper-layer services came from one team, so cross-layer problems like "the driver says it sent the data, the service says nothing arrived" are located internally.

The Raspberry Pi DSI display project runs on a Raspberry Pi 5. The challenge was driving multiple screen sizes with accurate touch calibration. The DSI device tree is configured through DTS and DTBO, an ICN6211 bridge chip handles MIPI DSI conversion, Waveshare panel drivers served as reference for adaptation, and I2C debug logs from an STC8G1K08 were used for troubleshooting, ending with support for 4.3, 5, 7 and 10 inch screens. The device tree is the main battleground on projects like this: swap the screen on the same interface and timing parameters, power-up sequence and touch configuration all have to change with it.

The i.MX6 CAN bus data acquisition system runs Linux on an i.MX6 Quad/Dual platform. The challenge was real-time multi-channel CAN bus acquisition and reliable communication on the i.MX6. A CanMain module handles CAN data capture, BMS_CAN protocol parsing turns raw frames back into battery management system data, and minicom and cutecom were used for serial debugging during integration. On an industrial bus project the point is not receiving frames but never dropping them under multi-channel concurrency, with protocol parsing and the capture cadence not blocking each other.

Peripheral configuration can be hard-coded into drivers or written into the device tree for the kernel to parse. The Raspberry Pi DSI project went the DTS/DTBO route throughout: changing the screen, adjusting parameters and tuning timing all happen in device tree overlays, not kernel code. Hard-coding is faster in the short term, but every hardware revision means recompiling the driver, so it costs more over time. XTELL BSP work uses the device tree by default, keeping configuration separate from code so a board change does not mean a code change.

The effort in display drivers concentrates on interface timing. On the Raspberry Pi DSI project, configuring the ICN6211 bridge, the panel initialisation sequence and touch calibration took most of the debugging time. Camera drivers - the V4L2 framework and module bring-up - are within this service, and at assessment we check our experience directly against your platform and module part number.

Industrial bus acquisition on Linux has to handle two things at once: latency jitter from kernel scheduling, and data integrity under multi-channel concurrency. The i.MX6 CAN bus data acquisition system separates capture from parsing - the CanMain module only receives frames on time, BMS_CAN protocol parsing runs independently above it, and parsing never slows the capture cadence. The same design applies across battery management, industrial control and vehicle equipment: deterministic on the bus side, extensible on the application side.

The services running once the board is up are in scope as well. On the R528 control board, HTTP file transfer, WebSocket real-time control and GCODE dispatch are the application running above the drivers; on the i.MX6 acquisition system, BMS_CAN protocol parsing is the application layer on Linux. In the traditional model where drivers and services come from two suppliers, mismatched interfaces get resolved by guessing over email. With one team delivering both, that problem is absorbed internally.

Board-level troubleshooting depends heavily on records. The Raspberry Pi DSI project kept the STC8G1K08 I2C debug logs as the evidence chain for diagnosing the touch path, and the R528 project archived its peripheral driver and auto-start service configuration with each version. Delivery documentation covers device tree changes, driver configuration, auto-start entries and a known-issues list, so whoever takes over later can reproduce the decisions and state of the time rather than starting again from serial output.

Firmware on MCUs without Linux - FreeRTOS or bare metal - is on the firmware development page. Board design is on the PCB design and hardware design pages. This page covers systems that run Linux: kernel drivers, device tree, BSP bring-up and the service layer on the board. If a new product has not yet settled whether to run Linux or an RTOS, we decide it together at the assessment stage - the choice affects BOM cost, power and development time, and is worth getting right before the board is drawn.

1. Requirements review: share the board platform or target platform, the peripheral list and the business goal, and we confirm the BSP scope.

2. Proposal and contract: bring-up scope, driver list, service-layer content and milestones are written down. Whether kernel source and device tree files are delivered, and under an open or closed model, is agreed item by item in the contract. Nothing on this page constitutes a blanket commitment.

3. Development and integration: bring-up, driver development, service integration and measured verification progress version by version.

4. Delivery: scope follows the contract. Timeline and price are given after assessment; this page does not fix numbers.

Products built on a Raspberry Pi Compute Module get the Raspberry Pi software ecosystem, which removes a great deal of risk - but a custom carrier board still needs bring-up. Peripherals on the carrier are not the ones on a development board, so the device tree is where the work lands: overlays for the panel and touch controller, pin configuration for the interfaces the carrier exposes, and boot media that matches whether the module carries eMMC or boots from a card.

This is the same work we do on Allwinner, Rockchip and NXP platforms, and our Raspberry Pi DSI display project is directly relevant: four panel sizes brought up on a Raspberry Pi 5 through DTS and DTBO overlays, with an ICN6211 bridge handling MIPI DSI conversion and I2C debug logs used to diagnose the touch path. Swap the panel on the same electrical interface and timing, power-up sequence and touch configuration all change with it - which is exactly why that configuration belongs in device tree overlays rather than hard-coded in drivers.

XTELL (Shenzhen XTELL Future Technology) was founded in Shenzhen in 2016. Over the ten years since, it has delivered more than 100 projects, with clients predominantly western B2B companies. Its work covers every layer from circuit board to cloud: PCB design, FPGA, embedded firmware, Linux BSP, device interfaces, mobile apps, backends and IoT platforms.