Skip to content
willowark

An embedded Linux platform your product can live on for a decade

Embedded Linux is the operating system layer inside serious connected products: instruments, gateways, HMIs, controllers. Done well, it is invisible for ten years. Done as a hand-configured desktop distro on a dev board, it becomes the reason your product cannot be rebuilt, patched, or trusted. This service removes that fragility.

Willowark builds embedded Linux the reproducible way: minimal images generated from source with Yocto or Buildroot, updates and security designed on day one, and a build any engineer can regenerate bit-for-bit years later. The OS becomes an engineered component of your product, not an artifact nobody dares touch.

Illustrative: an edge gateway on a DIN rail with sensor cablesIoT & Smart Systems

How the work gets done

The same way every time: scope, build, hand over.

The work spans the whole stack. Board support packages for common silicon — NXP i.MX, TI Sitara, Rockchip, and others — get tailored device trees describing your hardware, plus kernel drivers where your peripherals need them. Images are stripped to what the product requires, which shrinks both attack surface and boot time. Updates use an A/B partition scheme through RAUC or Mender: the new image installs to the inactive slot, the bootloader tries it, and a failed boot rolls back automatically — so a bad update in the field is an inconvenience, not a brick. Secure boot and signed images keep untrusted code off the device.

Production success is measured in dullness: fleet update success rates near total, reproducible builds under version control, and a CVE patching cadence that keeps security teams satisfied without destabilizing devices. Factory provisioning — flashing, serialization, per-unit keys — is part of the deliverable, because a platform that cannot be manufactured efficiently is not finished.

Hardware choice shapes everything downstream, so we weigh it early. A system-on-module from an established vendor — with a maintained kernel tree and published longevity commitments — is usually the right foundation for volumes below the point where a fully custom board pays for itself; it moves the hardest layout and memory-interface work onto a supplier and leaves a simpler carrier board to design. Where a custom board is justified, we pick silicon with mainline or well-supported vendor kernels, because a chip that only boots on a frozen fork becomes the ceiling on your product's security and lifespan.

Above the OS, the application layer is kept separate from the platform so each can move at its own pace: application code deploys as its own package or container, talks to the outside world over standard interfaces — MQTT, REST, a local database — and never depends on undocumented quirks of a particular image. Everything is handed over in a repository you own: the build configuration, layer recipes, signing setup, and a written procedure for producing a release from a clean machine. The maintenance arrangement is explicit — who tracks upstream kernel and package advisories, how often patched images ship, and how a release is qualified before it reaches the fleet.

  1. Scope it in writing

    What we agree before work starts

    • Yocto or Buildroot build system under version control
    • Board support package work: device tree, drivers, bootloader
  2. Build with checkpoints

    Working results, not slide decks

    • A/B OTA update system with automatic rollback
    • Secure boot chain with signed images
  3. Hand over something you own

    Documentation, source, and training

    • Factory provisioning and serialization process
    • Maintenance plan for kernel updates and CVE patching

Sound familiar?

Where embedded linux systems earns its keep.

OS platform for an OEM instrument or device product line

Gateway and edge device operating systems

Touchscreen HMI products replacing desktop-PC-based designs

Migrating a product off an unmaintained or ad hoc Linux image

Common questions

Asked before every embedded linux systems project.

Yocto, Buildroot, or just Debian — how do you choose?

Yocto suits products with long lives, custom hardware, and license-compliance needs; its learning curve buys you control and reproducibility. Buildroot gets small, fast images with less machinery for simpler devices. Debian variants trade control for convenience and can be right for low-volume or internal systems. We recommend based on your product's lifespan and volume, not habit.

How do field updates work without risking bricked devices?

A/B partitioning: the device keeps two complete system images, updates the inactive one, and boots into it on a trial basis. If the new image fails its health checks, the bootloader falls back to the known-good slot automatically. Combined with signed images, this makes updates safe enough to ship regularly instead of fearfully.

Can you take over an existing BSP or vendor image?

Yes — this is common. We audit what the vendor or previous team left, get it building reproducibly under version control, then incrementally modernize the kernel, update mechanism, and security posture. You do not need a rewrite to escape a fragile image; you need a controlled path out, and that is usually cheaper than starting over.

How long does it take to bring up a new board?

For a supported system-on-module with a vendor BSP, a bootable, reproducible image with your peripherals working typically takes a few weeks; the update system, secure boot, and provisioning add more on top. Custom boards with unusual peripherals take longer because driver work and hardware debugging are unpredictable by nature. We stage the work so you have a bootable platform early and can start application development while the hardening finishes underneath it.

What about open-source license compliance?

An embedded Linux image contains hundreds of packages under a mix of licenses, and some — notably GPL — carry obligations to offer source to whoever receives the device. Yocto generates license manifests and can assemble the corresponding source archives as part of the build, which we set up so compliance is a build output rather than a scramble before shipment. We flag components with licenses your legal team may want to review, and we keep proprietary application code cleanly separated from the platform.

Where this sits

Embedded Linux Systems, inside a iot & smart systems system.

The lit component is the part of the system this service delivers; the rest is what it has to work with.

An IoT monitoring system, sensor to phoneModbusMQTTMQTTMQTTRESTpushSensorsfieldEdge gatewayDIN railMQTT brokerTime-series storeRules enginethresholdsDashboardOn-call phone

Hover or focus a component to see what it is and what it talks to. Arrow keys move between them.

Field sensors report through an edge gateway to a broker; a time-series store feeds dashboards, and rules raise alerts that reach a person.

Components:

  1. Sensors (field): Temperature, vibration, level, current — wired or wireless.
  2. Edge gateway (DIN rail): Reads the sensors, buffers when the link is down, speaks MQTT upward.
  3. MQTT broker: Pub/sub hub; many gateways, many consumers.
  4. Time-series store: Every reading, retained for the trend and the audit.
  5. Rules engine (thresholds): Thresholds, rates of change, missing-heartbeat detection.
  6. Dashboard: Live and historical views.
  7. On-call phone: The alert reaches someone who can act.

Connections:

  • Sensors to Edge gateway over Modbus
  • Edge gateway to MQTT broker over MQTT
  • MQTT broker to Time-series store over MQTT
  • MQTT broker to Rules engine over MQTT
  • Time-series store to Dashboard over REST
  • Rules engine to On-call phone over push
A typical architecture, drawn to explain the pattern — not a specific client's system.

Strategy. Software. Systems.

Have a system that should exist?

Tell us what your operation is doing manually, what isn't connected, or what you're trying to build. We'll tell you plainly whether and how we can help.