Mainline-friendly products are designed so their board support lives in upstream Linux, U-Boot, and standard build systems instead of a vendor fork. The decision is architectural, not aspirational: it is made when you choose the SoC, design the add-on connectors, and write the device tree — not when the product is already shipping. This article gives the strategic case, the product design rules that follow from current kernel work on hot-pluggable add-on boards, a vendor checklist for tech leads, and the concrete steps to upstream your own board support.

We have covered why silicon vendors are moving to upstream-first BSPs. This article covers the product team's side of that shift: what you should do about it. Building mainline-friendly products means making a set of design decisions — SoC selection, connector design, device tree structure, and an upstreaming plan — so that mainline Linux and U-Boot treat your board as a normally supported board rather than as a permanent private port. Each section below turns one of those decisions into rules you can apply on your next board.

Why mainline-friendly products are a strategic decision

The cost of a vendor-fork BSP is not paid at bring-up; it is paid for the life of the product. Every kernel upgrade becomes a forward-port of private patches. Every security fix arrives on the vendor's schedule, not the kernel's — and for devices in scope of regulations such as the EU Cyber Resilience Act, patch latency is now a compliance question, not just an engineering one. Hiring is harder, because engineers must learn your fork before they can touch it, and the knowledge they build does not transfer in either direction.

Board support that lives in mainline inverts each of these. New kernels are more likely to boot your board without forward-porting private support patches, because your board is part of the kernel's own build-and-test surface; LTS security fixes are easier to consume because the code paths you depend on are already upstream; any engineer who knows mainline conventions is productive from the first day; and if the silicon vendor disappears or deprioritises your part, the support does not go with them.

💡 Key insight: mainline support is vendor independence in executable form. The fork you avoid writing is maintenance you never pay for, and the driver you upstream is maintained partly by people you never hired.

Design rule set: add-on boards, connectors, and overlays

The clearest place to see how mainline-friendly products change hardware design is add-on boards. Most products add variants over time — a sensor module, a display option, a radio — attached over I2C, SPI, or other buses that cannot enumerate devices. The kernel community has been working on exactly this problem: patch series under review propose a connector framework for hot-pluggable add-on boards on non-discoverable buses, where plugging a module applies a device tree overlay and unplugging reverts it, and the mikroBUS work discovers add-on boards from a manifest stored in an EEPROM on the module itself. The connector support is still being reviewed — the device tree binding questions are hard — but the design direction is clear. Product teams should read this work as design guidance, because it encodes what upstream expects a well-behaved extension system to look like.

This is a recommended pattern, not a universal rule: for modular products on non-enumerable buses, EEPROM-backed identification plus overlays is usually the cleanest upstream-friendly design, while products with fixed factory-selected variants may not need runtime identification at all. Where the pattern applies, three rules translate directly into product design:

  • Give every add-on an identity the base board can read. Put a small EEPROM on the module carrying a board identifier and revision — the approach the mikroBUS driver and BeagleBone capes use. Identification is what turns "a connector" into "a discoverable connector", and it is what makes automatic overlay selection possible.
  • Describe each add-on as a device tree overlay, one per module. Today an overlay is often tied to the socket it plugs into as well; the upstream connector work aims to remove exactly that coupling, so write your overlays to depend on the module, not the position. The base tree describes the board as shipped, with unused controllers present but status = "disabled"; each module ships a .dtbo that enables and describes exactly what it adds. Never fold variant hardware into the base tree.
  • Version the contract, not just the hardware. The connector pinout, the overlay naming, and the EEPROM identifier format are interfaces: version them explicitly, and treat a pinout change like an ABI break, because downstream that is exactly what it is.

💡 Key insight: a connector without identification forces every future variant into manual configuration. A few rupees of EEPROM at design time buys automatic discovery for the product's whole life.

The tech lead's checklist: what to demand from silicon vendors

SoC choice sets the upper limit, but connector, peripheral, and firmware choices decide whether the product reaches it. Before committing to a SoC, a tech lead should put these questions to every candidate vendor, in writing:

  • Is the SoC supported in current mainline, or only in a vendor kernel? Check yourself: the SoC's device trees should exist under arch/arm64/boot/dts/ in mainline, and the vendor's name should appear in recent kernel history, not only in their SDK.
  • Are the drivers you will actually use upstream? Display, camera, VPU, NPU and power management are where vendor forks usually remain. Ask for the mainline status of each peripheral on your block diagram, not a general statement.
  • Are the device tree bindings upstream and in YAML schema form? Open bindings under Documentation/devicetree/bindings/ are the sign that the hardware description is reviewed and stable, and they are what your own DTS will be validated against.
  • Is the boot chain clean and mainline-capable? Mainline U-Boot support for the SoC, upstream TF-A where applicable, and no boot stage that exists only as an unmodifiable vendor binary between you and your own kernel.
  • Does the vendor's Yocto or Buildroot support build against current upstream, or pin you to an old fork? A BSP layer that requires a two-year-old poky is a vendor fork in a different form.
  • What is the vendor's upstreaming track record? Their git history in mainline is public; read it. Past behaviour is the only reliable prediction of how your part will be treated.

When an answer is partly no, negotiate rather than walk away: if a peripheral you need is not upstream, make its upstreaming a written contract deliverable before you sign.

Watch the components around the SoC as closely as the SoC itself, because they are where mainline plans usually fail: PMICs and regulators without upstream bindings, Wi-Fi and Bluetooth modules that depend on opaque vendor stacks, camera pipelines that require closed ISP user space, and display bridges, touch controllers, or audio codecs with no upstream driver. Each of these can pull an otherwise clean board back onto a vendor fork.

Vendor evaluation checklist — for procurement and engineering to use together:

  • [ ] Show the upstream DTS path for the SoC family.
  • [ ] Show active driver maintenance in mainline for the peripherals on our block diagram.
  • [ ] Show upstream YAML bindings for those peripherals.
  • [ ] Show mainline U-Boot support and the full boot chain.
  • [ ] Identify everything still dependent on vendor forks, in writing.
  • [ ] Agree that missing upstream support becomes a written contractual deliverable.

💡 Key insight: every one of these questions is answerable from public trees before you sign anything. A vendor who cannot point at mainline is asking you to fund their fork's maintenance for the life of your product.

The engineering path: upstreaming your own board support

When the SoC is already supported, adding a board is one of the most achievable upstream contributions an embedded team can make, and it follows a well-defined sequence. The bindings and the hardware description come first, validated with the kernel's own schema tooling:

[email protected]:~$ make ARCH=arm64 dt_binding_check DT_SCHEMA_FILES=vendor,myboard.yaml
[email protected]:~$ make ARCH=arm64 dtbs_check W=1
[email protected]:~$ ./scripts/checkpatch.pl --strict my-board-patches/*.patch
[email protected]:~$ ./scripts/get_maintainer.pl my-board-patches/0002-arm64-dts-add-myboard.patch

Enter fullscreen mode Exit fullscreen mode

The shape of the submission: any new binding goes in as its own patch (YAML schema under Documentation/devicetree/bindings/), the board DTS follows as a separate patch, and a defconfig change enabling the board's drivers comes last. The SoC subtree maintainers listed by get_maintainer.pl take the series, and the standing rule for DTS is strict: no new dtbs_check warnings, with linux-next as the reference. Expect review rounds — bindings reviewers in particular will push back on descriptions that encode software convenience rather than hardware — and treat that review as expert correction of your hardware description at no cost. A board series typically lands through the SoC subtree over one to two kernel cycles, so set that expectation with management before you start.

Two habits keep the board healthy after the merge. Build your product kernel from mainline or an LTS plus a short, rebasing patch queue, so drift stays visible and small. And put a mainline build of your board into CI — build every release candidate against your defconfig, boot-test it if you can — so a regression that touches your board is caught while the commit is fresh, which is when upstream is most responsive to a report.

Learning to work this way — bindings, DTS, defconfigs, and the submission process — is exactly the kind of board bring-up skill we build in our Embedded Linux Mastery Track.

The decisions at a glance

Decision area Mainline-friendly choice Fork-heavy anti-pattern
SoC selection DTs in mainline, drivers upstream, active vendor history in kernel git Supported only in a vendor SDK kernel
Add-on hardware EEPROM-identified modules, overlay per module Unidentified connectors, variants hard-coded in images
Device tree structure Minimal base tree, disabled controllers, .dtbo per option One patched tree per product variant
Bootloader strategy Mainline U-Boot, upstream TF-A where applicable Unmodifiable vendor boot binaries in the chain
Vendor engagement Upstreaming gaps as written contract deliverables Verbal assurances, support only via the fork

Two boards with the same SoC can land on opposite ends of this table. A product built on an upstream-supported SoC with standard bindings, mainline U-Boot, EEPROM-identified expansion modules and a short rebasing patch queue stays cheap to maintain for its whole life. The same SoC paired with a closed camera stack, a vendor-only display pipeline and a private BSP fork inherits every cost this article opened with — the silicon was mainline-capable, but the product was not designed to be.

Key takeaways

  • Mainline-friendly products are an architecture decision made at SoC selection, connector design, and device tree time — not a cleanup task for later.
  • Vendor-fork BSPs cost you at every kernel upgrade and every security fix; mainline support makes your board part of the kernel's own test surface.
  • Design add-on connectors with EEPROM identification, one overlay per module, and an explicitly versioned pinout contract — the direction current kernel connector work encodes.
  • Qualify silicon vendors on public evidence: mainline DTs, upstream drivers for your actual peripherals, YAML bindings, mainline U-Boot, and their upstream git history.
  • Upstream board support in the standard sequence — bindings, DTS, defconfig — validated with dt_binding_check and dtbs_check W=1, and keep a mainline build of your board in CI.

Frequently asked questions

What makes a product mainline-friendly?
Its board support can live upstream: the SoC and peripherals have mainline drivers and bindings, the board's device tree is written to upstream rules, add-on hardware is described with overlays, and the boot chain works with mainline U-Boot rather than only a vendor binary.

Why should add-on boards carry an EEPROM?
Because buses like I2C and SPI cannot enumerate devices, an EEPROM with a board identifier lets the base system detect which module is attached and apply the matching device tree overlay automatically — the approach used by BeagleBone capes and the kernel's mikroBUS work.

In what order should board support be upstreamed?
Bindings first, as YAML schema in their own patch; then the board device tree as a separate patch; then the defconfig change. Validate with dt_binding_check and dtbs_check W=1 before sending, and route the series with get_maintainer.pl.

Does choosing mainline mean giving up vendor support?
No. It means choosing a vendor whose support flows through mainline. You can still buy support contracts; the difference is that the code paths you depend on are public, reviewed, and outlive any single vendor relationship.

Further reading

Originally published on TECH VEDA.