Kernel Drivers, Device Tree and Board Bring-Up
Embedded Linux board support packages and device drivers for custom hardware, covering kernel drivers, device tree configuration, peripheral bring-up and the build system. Delivered on Allwinner R528, Rockchip RK3128/RK3566, MediaTek MT7621 and Raspberry Pi 5.
XTELL develops embedded Linux board support packages and device drivers for custom hardware. That covers kernel driver work, device tree configuration, peripheral bring-up and the build system that ties it together — the layer between a board that powers on and a board that actually runs your application.
We work across Allwinner, Rockchip, MediaTek and Broadcom silicon. Recent platforms include the Allwinner R528 running Tina-Linux, Rockchip RK3128 and RK3566, MediaTek MT7621 under OpenWRT 19.07, and Raspberry Pi 5 with custom MIPI DSI display support. In most engagements we designed the board as well, which removes the usual argument about whether a problem is hardware or software.
Driver work on undocumented or poorly documented parts is normal here rather than exceptional. On the Raspberry Pi DSI project we configured an ICN6211 bridge chip through DTS and DTBO overlays, used an STC8G1K08 to capture I2C debug logs during bring-up, and referenced Waveshare panel drivers to support 4.3, 5, 7 and 10 inch panels from one code base.
Embedded Linux devices increasingly need a network control surface, and we build that too. The R528 control board serves HTTP for file transfer and WebSocket for real-time control, dispatches GCODE to the motion subsystem, drives five UART channels alongside GPIO and USB peripherals, and manages its own auto-start services.
What transfers at handover depends on the model. Under an open engagement you receive the driver work, device tree files, build configuration and a reproducible image with build steps documented, so your team can rebuild independently. Under a closed engagement we maintain the BSP and supply validated images against your hardware revisions. Either is fine - agree it before kickoff.
Kernel version strategy is worth deciding early. A vendor BSP pinned to an old kernel gets a product shipping quickly but makes security updates and upstream driver reuse painful two years later, while tracking mainline costs more effort up front and rewards you afterwards. We will lay out that tradeoff for your product rather than defaulting to whichever is convenient for us. Linux kernel driver development services also cover maintenance: when a peripheral is discontinued or a panel supplier changes, the device tree and driver work to accommodate it is usually far smaller than a redesign, provided the original BSP was structured with that in mind.
Tina-Linux on R528 with HTTP file transfer and WebSocket real-time control, GCODE dispatch, five UART channels plus GPIO and USB peripheral drivers, and auto-start service management.
MIPI DSI display support via an ICN6211 bridge configured through DTS/DTBO, with STC8G1K08 I2C debug logging and one code base covering 4.3, 5, 7 and 10 inch panels.
OpenWRT 19.07 on MediaTek MT7621 with 512MB RAM and dual-band WiFi, integrating Zigbee 3.0, MQTT and CoAP for unified device management.
SoC, kernel version, peripheral list and upstream driver availability assessed before work starts.
Boot chain, console, storage and power management brought up on real hardware.
Device tree configuration and kernel driver work for each peripheral, including undocumented parts.
Services, network control surface and auto-start management as required.
Reproducible build, documented flashing procedure and resource measurements.
Allwinner R528 with Tina-Linux, Rockchip RK3128 and RK3566, MediaTek MT7621 under OpenWRT 19.07, and Raspberry Pi 5 including DSI device tree work. Board support is normally bundled with the hardware design when we lay out the board too.
Usually. The Raspberry Pi DSI work involved an ICN6211 bridge chip configured through DTS/DTBO with an STC8G1K08 providing I2C debug logs, supporting 4.3, 5, 7 and 10-inch panels. Undocumented parts are normal in this work.
Either, depending on the model. Open engagements hand over the driver work, device tree, build configuration and a reproducible image with documented build steps. Closed engagements keep the BSP with us and deliver validated images tracking your hardware revisions. Say which you need at quoting time.
Yes. The R528 control board runs HTTP for file transfer and WebSocket for real-time control, with GCODE dispatch, five UART channels plus GPIO and USB peripheral drivers, and auto-start service management.
Contact us for customized solutions and quotes