Services
Embedded Linux & Device Software
Yocto Project and OpenEmbedded builds for connected medical devices — custom BSPs, kernel and driver work, secure boot, and signed updates — from the team whose SVH Platform device agent runs on the same stack.
The problem
-
Your device runs a vendor BSP nobody on the team can rebuild, on a kernel that stopped getting patches years ago.
-
The FDA premarket cybersecurity questions ask for an SBOM and an update story, and the answer today is “we reflash it in the field.”
-
Every image build is a hand-tuned snowflake on one engineer’s laptop, so a security fix takes weeks to ship.
How we work
- 01
Platform assessment
We audit your hardware, current BSP, kernel, and package set, then hand you a written plan: what to keep, what to rebase, what to replace.
- 02
Reproducible build
A Yocto / OpenEmbedded build with your own meta-layers, pinned revisions, and CI that produces the same image from a clean checkout every time.
- 03
Secure the device
Secure boot chain, read-only root filesystem, signed A/B OTA updates with rollback, and hardening of services, users, and network exposure.
- 04
Maintain & hand over
CVE monitoring against your SBOM, kernel and layer updates on a schedule, and documentation your team can run without us — or we keep running it.
What you get
- A reproducible Yocto / OpenEmbedded build with custom BSP and application layers
- CI pipeline producing signed images and update bundles
- Secure boot and signed A/B OTA updates with tested rollback
- SBOM and CVE triage process designed to support FDA cybersecurity expectations
- Board bring-up notes, build documentation, and maintenance runbooks
Standards & technologies
- Yocto Project
- OpenEmbedded
- BitBake
- Linux kernel
- U-Boot
- C/C++
- RAUC / SWUpdate
- SPDX SBOM
- ARM / x86
Common questions
Can you work with our existing vendor BSP?
Yes. We start from what ships today, move it into a layer you control, and rebase onto a maintained kernel and Yocto release when the assessment says it pays off.
Do you do board bring-up?
Yes — device tree, bootloader, and kernel drivers for custom carrier boards and SoMs, working alongside your hardware team.
How does this fit with IEC 62304?
Device software work follows an SDLC designed to support IEC 62304: requirements traceability, verified builds, and documented SOUP — including every open-source package in the image.
Does this tie into the SVH Platform?
It can. Images we build can ship with the SVH device agent preinstalled, so devices enroll into zero-trust fleet management on first boot. It is optional, not a requirement.
Have a device that needs a Linux it can trust?
Bring us an integration problem, a device fleet, or a product idea — we will come back with an approach, not a slide deck.