Embedded Linux Development — Custom Distros & BSPs
Custom BSPs, Yocto layers, device tree, kernel drivers, and production image configuration — embedded Linux built for the hardware, not ported from a reference design.
What We Build on This Platform
Yocto & OpenEmbedded
Custom layer, recipe, machine configuration for production embedded Linux images targeting NXP, TI, Rockchip, and Allwinner SoCs.
Buildroot
Minimal embedded Linux for resource-constrained or fast-boot applications where Yocto overhead is unacceptable.
Board Support Package
Device tree authoring, bootloader configuration, and kernel configuration specific to custom hardware, not copied from a vendor reference design.
Kernel Driver Development
Character driver, platform driver, DMA driver, and interrupt handler development for custom peripherals not covered by mainline drivers.
Device Tree Authoring
DTS bindings for custom SoC peripherals, and DTS overlays for modular hardware variants sharing a base carrier board.
U-Boot & Secure Boot
Bootloader configuration, environment, fit image, and verified boot chain from U-Boot through signed kernel to dm-verity rootfs.
systemd & Init
Service unit authoring with correct dependency ordering, socket activation, watchdog integration, and hardware probe synchronisation.
OTA Update
Mender, SWUpdate, RAUC, and custom dual-partition OTA for embedded Linux products with automatic rollback on failed update.
How Ankh Uses This Platform
SoC and BSP Selection
SoC family selected from the processing requirement, interface set, available upstream kernel support, and vendor BSP quality. BSP quality assessed by upstream mainline kernel coverage, patch count relative to mainline, and the vendor's security update track record.
Yocto Layer Architecture
Machine configuration for the custom hardware, kernel recipe with custom defconfig, device tree recipe, and application recipe established. Layer dependency managed against the Yocto release compatible with the vendor BSP layer. BSP layer, distro layer, and application layer separated so hardware changes do not require application layer modification.
Device Tree and Driver Development
Device tree source authored for every custom peripheral: SPI ADC with chip select, clock polarity, max-frequency, and compatible string; I2C sensor with address, interrupt GPIO, and regulator supply; custom display panel with timing parameters and reset GPIO. Kernel driver developed for custom interfaces not covered by existing mainline drivers.
Root Filesystem and Image Configuration
Minimal image for the specific application: unused packages removed, read-only squashfs rootfs with overlayfs for the mutable partition, tmpfs for runtime data, and a data partition with correct filesystem for the write pattern. Init system configured with service units ordered after hardware probe completion.
OTA, Security, and Production
OTA update architecture using Mender or RAUC dual-partition update with atomic switch and automatic rollback. Secure boot chain from U-Boot verified boot through signed kernel fit image to dm-verity rootfs integrity. Production image signing, key management, and factory provisioning script for device-unique configuration injection at manufacturing.
Deep Technical Capability
Device Tree as Hardware Contract
The device tree source file is the contract between the Linux kernel and the custom hardware — specifying every peripheral's bus address, interrupt line, GPIO number, clock source, regulator supply, and compatible driver binding string. A device tree copy-modified from the vendor reference board without systematic comparison to the custom PCB schematic produces a kernel that boots on the reference board but hangs at I2C controller initialisation on the custom board because the custom board's I2C pull-up regulator is on a different GPIO, or produces incorrect SPI clock polarity because the reference design used a different ADC with different CPOL/CPHA requirements. Ankh authors device tree from the custom schematic — every node verified against the custom PCB netlist, every property value verified against the peripheral datasheet, every interrupt polarity verified by measurement on the prototype board.
Read-Only Rootfs with OverlayFS for Production Reliability
An embedded Linux product deployed in the field with a read-write rootfs on eMMC or SD card accumulates filesystem corruption risk from every uncontrolled power removal — journalled ext4 reduces but does not eliminate this risk in products that experience frequent power cycling. The production-reliable architecture is a read-only squashfs rootfs verified at boot by dm-verity against a stored hash, with an overlayfs upper layer on a separate writable partition for mutable files: configuration, logs, runtime state. The read-only rootfs survives any power loss without corruption; the overlayfs upper layer is a small, bounded dataset whose corruption does not affect the base system. Ankh designs production embedded Linux images with read-only rootfs and overlayfs from the first production image build — not as a reliability improvement added after field corruption events.
Yocto Reproducibility and Long-Term Maintainability
The Yocto build that produces a working image from the vendor's BSP layer today produces a different image in 18 months if recipe SRCREV values are not pinned — upstream git commits change, PyPI packages update, and the host build environment diverges. Ankh pins every recipe's SRCREV, SRCPV, and external dependency version in the Yocto layer, uses a fixed Yocto release rather than master or HEAD, and builds inside a reproducible container build environment — so the production image binary can be reproduced exactly from the same source inputs 3 years after first build. This is the requirement for generating a compliant software bill of materials for security patch management across the product's operational lifetime.
Products Built on This Platform
AI Vision Systems
Embedded Linux on NVIDIA Jetson AGX Orin and Raspberry Pi CM4 for vision pipeline host.
View ProductFleet Telematics
Embedded Linux on AM62x SoC for in-vehicle gateway processing J1939 CAN Bus and cellular telemetry.
View ProductIndustrial Equipment Monitoring
Embedded Linux on i.MX8 for industrial HMI with Qt-based touchscreen UI.
View ProductData Loggers
Embedded Linux on Raspberry Pi CM4 for high-throughput data logger with USB 3.0 download.
View ProductRobotics & Drones
Embedded Linux with ROS2 for autonomous mobile robot navigation and sensor fusion.
View ProductSmart Home Devices
Custom embedded Linux on NXP i.MX8 for smart home gateway and Thread border router.
View ProductThe BSP is not the starting point — it is the constraint
The SoC vendor's BSP is a reference implementation for the vendor's evaluation kit, not a production BSP for the custom hardware. Every difference between the evaluation kit and the custom PCB — a different PMIC, different DDR timing, different display interface, a custom peripheral on a shared bus — requires a change to the device tree, bootloader environment, or kernel configuration. Ankh's embedded Linux engagements begin with a systematic comparison of the vendor BSP against the custom PCB schematic, identifying every required deviation before the first kernel build — so the BSP changes are known and planned, not discovered during board bring-up.
systemd ordering is not a guess
The systemd service that starts the application daemon before the SPI peripheral driver has finished its asynchronous probe results in an application that cannot open the device file and exits with ENOENT — and the failure is intermittent because driver probe timing varies with the kernel's workqueue scheduler. Ankh writes systemd service units with explicit after/requires dependencies on the device-mapper events or udev rules that signal the completion of hardware probe — so the service start ordering is deterministic and the application's hardware interface is guaranteed available at the point the application attempts to open it.
Long-term security patch management requires a planned BSP strategy
The SoC vendor who supports a BSP on Yocto Dunfell may not provide a BSP on Kirkstone, leaving the product on a kernel version that no longer receives upstream CVE patches. The embedded Linux strategy without a 5-year kernel support plan produces a product whose security patch pipeline ends at the first kernel LTS transition. Ankh evaluates the vendor's kernel support commitment as part of SoC selection, and designs the Yocto layer structure for forward compatibility with the next LTS kernel before the first production image is built.