There's a moment in almost every hardware project where someone says, let's just get it working first, and we'll clean it up later. We've all been there. A few months down the line, 'later' arrives - and with it, the full weight of what it actually means to upstream your hardware into Zephyr RTOS and ship it into production.

This post is about that journey. Not the polished version, but the real one.

What "Upstreaming" Actually Means

When people say they want their hardware "supported in Zephyr RTOS," they usually mean one of two things:

1. They want a working, out-of-tree board definition they can build against.
2. They want it merged into the mainline Zephyr tree, visible to the world, maintained by the community.

These are very different things. The first can be done in a weekend. The second is a process - sometimes a long one - that involves code quality, community review, CI pipelines, and a fair amount of patience.

Upstreaming is worth it. But it helps to go in with eyes open.

The Technical Gates

Before a board or driver lands in Zephyr RTOS mainline, it has to pass through a few layers of scrutiny.

Devicetree bindings.Zephyr RTOS's DTS bindings are strict. Every property needs to be declared, typed, and documented. If your hardware uses a peripheral that doesn't have an existing binding, you'll need to write one - and get that merged first.

Driver quality.The Zephyr RTOS community takes API conformance seriously. A driver that works on your specific chip isn't the same as a driver that handles errors gracefully, respects power management hooks, and plays nicely with the rest of the subsystem. Expect review comments.

Kconfig hygiene.Config symbols need to follow naming conventions, have sensible defaults, and not introduce unnecessary dependencies. It sounds minor until you're on your third revision of a single Kconfig file.

Test coverage.Twister, Zephyr RTOS's test runner, needs to be able to validate your board. At a minimum, your board should pass the basic sanity suite. The more coverage, the more confident the maintainers - and frankly, you - can be.

CI. If your board isn't in the CI matrix, it won't stay healthy. Hardware-in-the-loop CI is ideal, but even QEMU coverage for a simulation target helps. The maintainers want to know your board won't silently break six months from now.

The Review Process

Zephyr RTOS community uses GitHub for patch review, and the process can feel slow if you're not used to open source workflows. A PR might sit for a week before a maintainer picks it up. You'll get review comments, revise, wait again. Sometimes a review surfaces a design issue that requires rethinking something upstream of your board - a binding, a subsystem API, a Kconfig structure.

This isn't a criticism. It's how open source works, and it's why Zephyr RTOS's quality is what it is. But it does mean that we'll upstream this next sprint is rarely the right mental model. Budget time. Engage early. Respond promptly to review comments.

If you haven't already, introduce yourself on the Zephyr mailing list or Discord before you post your first PR. The community is welcoming, and a little context about what you're building goes a long way.

The Gap Between Upstream and Production

Here's the part that catches people off guard: getting your hardware into Zephyr mainline is not the same as being ready to ship a product.

Upstream acceptance means the community has agreed your code meets their quality bar. It does not mean:

• Your application layer is ready
• Your OTA update strategy is in place
• Your security hardening is done
• Your power consumption is optimised
• Your supply chain is sorted

Production readiness is a separate track that runs in parallel with upstreaming, not after it. The teams that handle this well treat them as two concurrent workstreams — one focused on getting the platform into the community, one focused on making it ready for a customer's real-world use.

What a Customer Launch Actually Looks Like

In practice, launching a customer on Zephyr-based hardware tends to look something like this:

Early stages. Board bring-up happens out of tree. The goal is to get something running fast - enough to validate the hardware, run basic peripherals, and start application development. Upstreaming is on the roadmap but not the critical path.

Mid stages.As the hardware stabilises, the upstream work begins in earnest. Drivers get cleaned up. Devicetree bindings get written properly. The first PR goes up. Application development continues on a branch that tracks mainline plus a small delta of not-yet-merged patches.

Late stages. The upstream PRs land, one by one. The out-of-tree delta shrinks. CI is green. The application is hardened. The customer goes into production on a codebase that is - mostly - mainline Zephyr with a thin layer of product-specific configuration on top.

After launch.This is where upstreaming really pays off. Bug fixes from the community flow in. New Zephyr releases bring improvements you didn't have to write. When the next hardware revision comes around, the foundation is solid.

Honest Advice

A few things we wish someone had told us earlier:

Start the upstream conversation early.Don't wait until your board is done. Post a draft PR or an RFC. Get feedback before you've committed to an approach.

One PR per logical change.A PR that adds a board, three drivers, two bindings, and a subsystem fix is hard to review. Split it up.

Don't underestimate the DTS work.It's often the longest part of the process for new hardware.

Plan for the delta.You will almost certainly ship with some patches that haven't landed upstream yet. That's fine - just track them deliberately and have a plan for when they merge.

The community is an asset.Once your hardware is upstream, you're not alone. Other people are using it, finding bugs, and fixing things. That's the real return on the investment.

Upstreaming hardware in Zephyr RTOS is real work. It takes longer than most people expect, requires attention to detail at every layer, and demands patience with the review process. But the teams that invest in it properly end up with something genuinely valuable: a production-grade platform built on a foundation they don't have to maintain alone.

That's worth the effort.

Have a business idea and want to convert it into a Zephyr RTOS based product? Want to know more about Aerlync’s expertise in Zephyr RTOS? Contact Us!