Go to the content

Capability Reference ManualOSSRMRev. 1108/2026

Talk to us
Chapter 1Overview

Embedded Linux, maintained upstream since 2002

We maintain meta-freescale, the board support layer for NXP platforms in the Yocto Project. We build custom Linux systems for your hardware.

Start a projectRead about the company

OSSRM_MAINT

Width
32 bits
Access
Read only
Reset value
0x9EDF_F7C7

Select a field to read it.

BitFieldValueDescriptionPublic source
31META_FSL1Otavio Salvador maintains meta-freescale, the board support layer for NXP i.MX platforms in the Yocto Project. The layer README names him, and no one else, as maintainer.meta-freescale README
30:19MFSL_MERGES987We performed 987 of the 992 merges in the history of meta-freescale, and all 160 merges made in the last year. Only the maintainer of a layer can merge into it.meta-freescale git log
18:14NIXPKGS31We are named in the maintainer field of 31 package definitions in nixpkgs, and we are the only maintainer of 24 of them. They are the embedded tools that we use every day, such as uuu, snagboot and oelint-adv.nixpkgs maintainer entries
13:11ZEPHYR6An engineer of the company maintains six areas of the Zephyr Project. One of them is the UpdateHub subsystem.Zephyr Project MAINTAINERS file
10:9UBOOT3The company holds three board maintainer entries in the mainline U-Boot tree.U-Boot board maintainer files
8:0OE_CORE455The company has 455 commits in OpenEmbedded-Core, the base layer that every Yocto Project build uses. That places it 14th of the 616 organizations that contributed to the layer.openembedded-core git log

Every field is read only. You can check each one in a public repository.

Figure 1-1. Upstream maintainership register
1.1

The Company

O.S. Systems started in 2002. At that time, few companies could customize operating systems or give specialized consultancy on open source software.

We adopted GNU/Linux for our products because open source systems give us stability, security and flexibility. We are a Yocto Project Participating Organization. Between 2014 and 2018 we cast votes in the Yocto Project Advisory Board. Those votes decided which layers earn the Yocto Project Compatible mark, and some of the layers belonged to other companies.

Our engineers maintain the software that other companies use. Otavio Salvador maintains meta-freescale, the layer that supports NXP i.MX platforms in the Yocto Project.

We send our customer work upstream. Our commits are in the Linux kernel, in U-Boot, in OpenEmbedded-Core and in the Zephyr Project. Your hardware support stays in the mainline tree.

We work as part of your development team, for the months that a board support package takes. Chapter 3 states what you can order, and chapter 4 gives the record that you can check.

Yocto Project Participating Organization

Chapter 2

Functional Blocks

Where our work sits in your product, and the blocks that we build and maintain

We build and maintain this
APPYour applicationYour product logic
DISTROLinux distributionYocto Project build, SDK for your team
BSPBoard support packagemeta-freescale and custom layers
KERNELLinux kernelDrivers and device trees
BOOTBoot loaderU-Boot port
HWYour hardwareYour schematic and your board

We build and maintain thisYou own this

Figure 2-1. Where our work sits in an Embedded Linux product
We build and maintain this
APPYour applicationYour product logic
MODULESModules and subsystemsZephyrBT and motor control
RTOSZephyr RTOSSix areas that we maintain upstream
BSPBoard supportDrivers, device trees, custom boards
BOOTMCUbootSigned updates over MCUmgr
HWYour hardwareYour schematic and your board

We build and maintain thisYou own this

Figure 2-2. Where our work sits in a Zephyr product

  • 2.1YOCTO

    Yocto Project

    We build custom Linux distributions with the Yocto Project. We contribute to OpenEmbedded-Core since 2011.

  • 2.2BSP

    Board Support Packages

    We maintain meta-freescale, the BSP layer for NXP i.MX platforms. We also build BSPs for other hardware.

  • 2.3KERNEL

    Linux Kernel

    We write kernel drivers and device trees. Our commits are in the mainline tree since 2007.

  • 2.4UBOOT

    Boot Loader

    We port and configure U-Boot. We maintain three boards in the mainline U-Boot tree.

  • 2.5ZEPHYR

    Zephyr Project

    We maintain six areas of the Zephyr Project, and the UpdateHub subsystem in it. We write this firmware in C and in C++, and we publish ZephyrBT, our behaviour tree framework.

  • 2.6LANGS

    C, C++, Rust and Go

    We write device software in C, C++, Rust and Go. We reworked the Go support in OpenEmbedded-Core in 2017.

  • 2.7RENODE

    Simulation and automated tests

    We run the firmware in Renode, so a test needs no board. Twister and Robot Framework then drive those tests in continuous integration, on every pull request. We maintain the renode package in nixpkgs.

Figure 2-3. Functional blocks that we build and maintain
Chapter 3

Service Description

What you can order from us, and what each service delivers

  • 3.1CONS

    Consultancy and Migration

    We move your product to the Yocto Project, and we review the build that you have now. Chapter 6 gives the platform that we use for release engineering and licence compliance.

    Ask about this service

    Includes

    • Migration from Buildroot, LTIB or a hand-built system
    • Review of your layers, your recipes and your build
    • Release engineering, licence compliance and CVE handling
    • Training for your team on the Yocto Project
  • 3.2DEV

    Board Support and Custom Development

    We make your board boot and run: the boot loader, the kernel, the drivers and the distribution. We send the work upstream, so your hardware support stays in the mainline tree.

    Ask about this service

    Includes

    • U-Boot port and board bring-up
    • Kernel drivers and device trees
    • A board support layer for the Yocto Project
    • An SDK for your application team
  • 3.3NIX

    Nix and NixOS Engineering

    We make your build reproducible with Nix, and we run your build machines on NixOS. Chapter 7 gives the public record.

    Ask about this service

    Includes

    • Reproducible development shells
    • NixOS build machines and CI
    • Packaging in nixpkgs
    • Migration from a hand-built host
  • 3.4AI

    AI-Assisted Engineering

    We build the development system that lets your engineers work with coding agents. It lives in your repository, under version control. Chapter 8 gives the public record.

    Ask about this service

    Includes

    • A versioned plugin, installed with one command
    • Agents that read every pull request in your pipeline
    • Your own systems recorded as skills
    • Third-party skills pinned and credited
Chapter 4

Upstream Positions

A project outside the company granted us the position in six of these twelve rows. In meta-freescale we performed 987 of the 992 merges, and all 160 merges made in the last year.

Table 4-1. Positions in public upstream projects. Measured on 15 August 2026. Each count is authored commits from company addresses, and it excludes the merges that we performed as maintainer. The years are the years of our work.
SymbolProjectOur positionCommits and yearsSource
MFSLmeta-freescaleMaintainer of the layer1,981 · 2011–2026Layer README, git log
NIXPKGSnixpkgsMaintainer of 31 packages, and the only maintainer of 24225 · 2020–2026Package maintainer fields
ZEPHYRzephyrMaintainer of six areas, and of the UpdateHub subsystem94 · 2018–2026MAINTAINERS.yml
ZEPHYRNIXzephyr-nixOne of the two maintainers that nix-community names10 · 2024–2026Repository description
UBOOTu-bootBoard maintainer for three boards211 · 2012–2020Board MAINTAINERS files
MBROWSERmeta-browserOne of three maintainers. We performed 91 of the 95 merges, to 201852 · 2012–2018OpenEmbedded layer index, git log
MUHUBmeta-updatehubMaintainer of record for the layer of our own product, in the OpenEmbedded layer index394 · 2016–2026OpenEmbedded layer index
MSHUBmeta-shellhubMaintainer of record for the layer of our own product, in the OpenEmbedded layer index81 · 2019–2026OpenEmbedded layer index
OECOREopenembedded-core14th contributing organization of 616455 · 2011–2026openembedded-core git log
METAOEmeta-openembedded15th contributing organization of 495385 · 2011–2023meta-openembedded git log
LINUXlinuxThe elgin vendor prefix and the RV1108 board are in the mainline tree40 · 2007–2023Mainline Linux tree
OEORGOpenEmbeddedVoting member of the organization, able to stand in the Yocto Project and OpenEmbedded elections. We hold no seat on the board and none on the technical steering committee—OpenEmbedded members roster

We put a customer board in the mainline kernel, so the customer name is now in the vendor list of Linux. A gold row is a position that a project outside the company granted. The two layer index rows carry our own products, so we list ourselves there and the mark stays off. Every row comes from a public source. Filter a git log by our domain to check any row yourself.

Chapter 5

Revision History

More than twenty years of upstream work

Table 5-1. Revision history of the company
Rev.DateDescription of change
02002Otavio Salvador starts the company
12005Custom Debian systems for desktops, servers and clusters. One of them, Linux Educacional, later runs on 120,000 school machines for the Ministry of Education
22008Our founder becomes the release manager of the Debian Installer. First contributions to OpenEmbedded
32010First direct contributions to the Yocto Project
42011We become the maintainer of the Freescale board support layer for the Yocto Project
52012Work starts on O.S. Systems Embedded Linux, our own Yocto Project platform
62014Our founder co-authors the first edition of a book about the Yocto Project
72017First release of UpdateHub
82019Development of ShellHub starts
92020First reproducible build environment, and first packages that we maintain in nixpkgs
102024The nix-community organization makes us a maintainer of zephyr-nix
112026Fourth edition of the co-authored book, for Yocto Project 6.0 WrynoseRev. 11 · 08/2026
Chapter 6

O.S. Systems Embedded Linux

Our own Yocto Project platform, in continuous development since 2012

A customer who ships a product line needs more than a build. That customer needs release engineering, licence compliance, and a record of what went into each image. O.S. Systems Embedded Linux is the platform that we built for this work, and we keep a branch of it for each Yocto Project release.

  • 6.1HISTORY

    Fourteen years of one platform

    Company addresses account for 1,176 commits since 2012. We published the work on GitHub in 2020, but the history starts eight years earlier. The layer index of OpenEmbedded lists the layer on 23 branches, with a named maintainer.

  • 6.2RELEASES

    A branch for each release

    We keep a branch for each Yocto Project release, from 1.6 Daisy in 2014 to 6.0 Wrynose in 2026. A product that starts on one release can move to the next release without a rewrite.

  • 6.3SCOPE

    No vendor lock in the platform

    The platform carries no board support of its own. It uses the QEMU machines of OpenEmbedded-Core as its reference. Silicon support comes from meta-freescale, or from the layer that your board needs.

Table 6-1. What the meta-ossystems-base layer adds to OpenEmbedded-Core
ItemCountDetail
Classes14Release bundles, licence manifests, CVE filters and factory defaults
Recipes21The base software of the distribution
Recipe extensions12Changes to recipes that OpenEmbedded-Core supplies
Distributions2oel, and oel-tiny for small images
Chapter 7

Reproducible Build Environments

The same build environment on every machine, from one pinned description

A new engineer must not lose a week on host tools. We give the team one description that puts the correct BitBake, the correct setup tools and the correct host tools on any machine. We have shipped this promise since 2020, first with Docker and then with Nix. Example 7-1 and Example 7-2 solve the same problem by the two routes. Both are public, and you select the one that fits your team.

yocto-env.nix

Pinned releases
master, 6.0 Wrynose, 5.0 Scarthgap, 4.0 Kirkstone
  1. nix develop github:OSSystems/yocto-env.nix

    Enter a shell that carries kas, bitbake-setup, repo and every host tool, at pinned versions.

The build CI of our own layer runs in this shell. You get the environment that we use.

Example 7-1. A complete Yocto Project build environment with Nix

ossystems/yocto-env

Ubuntu images
16.04, 18.04, 20.04, 22.04, 24.04
  1. docker run ossystems/yocto-env:24.04 wrapper > ~/bin/yocto-env

    Write the wrapper script. You do this one time.

  2. chmod a+x ~/bin/yocto-env

    Give the script permission to run.

  3. yocto-env 24.04

    Enter a container that carries the host tools. The argument selects the Ubuntu image.

The image solves the same problem as the Nix flake, and it solves it by the other route. Row 7.1.2 gives its record.

Example 7-2. A complete Yocto Project build environment with Docker
7.1

What your team runs

  • 7.1.1YOCTOENV

    yocto-env.nix

    One Nix flake carries the host tools for four Yocto Project releases: master, 6.0 Wrynose, 5.0 Scarthgap and 4.0 Kirkstone. You select the release, and the flake pins the rest. The shell carries the three setup tools, bitbake-setup, kas and repo, so your project keeps the layout that it uses today. The build CI of our own layer runs in this shell.

  • 7.1.2DOCKERENV

    docker-yocto-env

    Docker is the route for a team that does not use Nix. The image carries the host tools for a Yocto Project build on Ubuntu 16.04 to 24.04, and it writes its own wrapper script for you. We published the image in 2020, and Docker Hub reports more than 3,500 pulls.

  • 7.1.3NIXACTIONS

    nix-actions

    Two GitHub Actions keep a Nix repository correct with no copied pipeline code. The first one runs nix flake check and nix build on each pull request. The second one opens a pull request that updates flake.lock. The repository is on the GitHub Marketplace, under an MIT licence.

7.2

Our position in the Nix ecosystem

  • 7.2.1NIXPKGS

    31 packages in nixpkgs

    We are named in the maintainer field of 31 package definitions, and we are the only maintainer of 24 of them. Company addresses account for 225 commits in nixpkgs since 2020. Table 7-1 gives a sample.

  • 7.2.2ZEPHYRNIX

    zephyr-nix

    The nix-community organization names one of our engineers as one of the two maintainers of zephyr-nix, which builds Zephyr Project firmware with Nix. An independent organization granted that role, and he merges the work of other contributors.

  • 7.2.3NIXOSMOD

    The ShellHub NixOS service module

    We wrote services.shellhub-agent, the NixOS service module for our own product. It is in nixpkgs since November 2020, one month before the package itself. A NixOS user installs the ShellHub agent from the distribution, and not from us.

Table 7-1. Packages that we maintain in nixpkgs
PackageOur rolePurpose
uuuOnly maintainerWrites an image to an NXP i.MX board over USB
snagbootOnly maintainerRecovers and flashes boards over USB
oelint-advOnly maintainerChecks the style of OpenEmbedded recipes
renodeOnly maintainerSimulates a board, so tests run with no hardware
mcuboot-imgtoolOnly maintainerSigns firmware images for MCUboot
mcumgr-clientOnly maintainerManages a microcontroller over SMP
git-repoCo-maintainerManages the many repositories of a platform

Seven of the 31 packages. Search the maintainer name in nixpkgs to see them all.

Chapter 8

AI-Assisted Engineering

We build the system that lets your engineers work with coding agents

We do not sell models. We build the development system around them. That system lives in your repository, under version control, next to your code. Your engineers then ship the product with it. We started this work in 2025, and we now run it with teams in five industries.

We build the AI development system, and we hand it over.

Your engineers ship the product with it.

  1. A1Code quality
  2. A2Security
  3. A3Testing
  4. A4Go and TypeScript patterns
  5. A5Architecture and cross-repository

A separate agent then checks the result

Figure 8-1. The review team that reads every pull request

This figure shows the review team of one product, so agent A4 reads Go and TypeScript. The method does not depend on the language. We run the same review on Rust, C and C++ code.

You can check this yourself

ShellHub is a public product with an Apache-2.0 licence and 2060 stars. We added an AI review workflow to it in February 2026. The workflow is public, and so is every review it wrote.

531
public pull requests carry an AI review
5
review agents run at the same time
6
months of reviews, from February to August 2026

Read the workflow on GitHub

The 2060 stars belong to the product, which started in 2019. The review team started in 2026.

  • 8.1PLUGIN

    A plugin, not a prompt

    We deliver a versioned plugin through a marketplace. Your team installs it with one command. A prompt in a chat window helps one person one time. A plugin helps every engineer, every day, and you can review it in a pull request.

  • 8.2PINNED

    One toolchain for the agent and the engineer

    Chapter 7 pins your build environment with Nix. The agent runs inside that same environment. So it uses the compiler, the linter and the tests that your engineers use. An agent with different tools reports faults that do not exist.

  • 8.3PARALLEL

    Many small agents, and one that checks

    We divide the work between specialist agents that run at the same time. A separate agent then checks what they found. Five small agents with one task each find more than one large agent with five tasks.

  • 8.4DOMAIN

    Your own systems, written as skills

    We record how your systems work, and we give that record to the agent as a skill. The agent then knows your business rules, your hardware and your legacy interfaces. It does not know only the programming language.

  • 8.5LICENCE

    Third-party skills stay legal

    We publish ai-plugin-vendor-tool. It copies a skill from a public source, pins the version in a lockfile, and credits the author in a NOTICE file. You then know what you use, and where it came from.

  • 8.6PIPELINE

    The agent runs in your pipeline

    The agent reads every pull request in continuous integration. It does not run on one laptop only. This is how the 531 public reviews happened. A human still approves and merges the work.

The same method, in five industries

  • Vehicle electrification and industrial robots
  • Agricultural automation
  • Financial technology
  • Infrastructure software and SaaS
  • Embedded Linux and the Yocto Project

We describe the industries, and not the customers. We name a customer only with that customer's written permission.

Chapter 9

Supported Products

Open source products that O.S. Systems develops

  • 9.1UHUB

    UpdateHub

    Over-the-Air (OTA) Update Management

    A complete platform that updates embedded devices over the air.

    Features

    • Updates for Yocto Project and Zephyr Project devices
    • Signature check on each update package
    • Automatic rollback after a failed update
    • A/B installation with U-Boot or GRUB
    Explore UpdateHub
  • 9.2SHUB

    ShellHub

    Remote Access for the Internet of Things (IoT)

    A centralized SSH gateway that reaches your Linux devices in the field. The agent has more than 2.1 million pulls on Docker Hub.

    Features

    • SSH access to devices behind NAT and firewalls
    • No public IP address, VPN or jump host
    • Session recording and audit logs
    • Firewall rules and multi-factor authentication
    Explore ShellHub
Chapter 10

Related Documentation

Books and free material about the Yocto Project

Table 10-1. Books and free material
YearTitleYocto releaseKind
2014Embedded Linux Development with Yocto Project1.6 DaisyBook, Packt
2017Embedded Linux Development using Yocto Projects, 2nd edition2.4 RockoBook, Packt
2018Heading for the Yocto Project—Free, Creative Commons
2023Embedded Linux Development Using Yocto Project, 3rd edition4.0 Kirkstone LTSBook, Packt
2026Embedded Linux Development Using Yocto Project, 4th edition6.0 Wrynose LTSBook, Packt

The books

Otavio Salvador co-authored four editions of the book, across twelve years. The fourth edition covers Yocto Project 6.0 Wrynose, the current long term support release. Daiane Angolini is the other author.

The booklet

Heading for the Yocto Project is a booklet of 43 pages by Otavio Salvador and Daiane Angolini. It answers the question that comes before the manual: why a team selects the Yocto Project, and what changes when it does. It is free content under a Creative Commons licence, and the source is public. The published file has 2,063 downloads.

Read the booklet
Chapter 11

Operating Principles

How we run an engagement, and what you can expect from us

  • 11.1

    We send the work upstream

    We submit your board support to the mainline tree, and not only to your repository. The Elgin RV1108 board is in mainline Linux and in mainline U-Boot because we put it there. Your hardware support then survives the next release.

  • 11.2

    We work in the open

    Our layers, our build environments and our packages are public. You can read the commit that changes your build. Chapter 4 lists the repositories where a person outside the company can check our record.

  • 11.3

    We stay after the release

    A product lives longer than its first image. We keep our platform on a branch for each Yocto Project release, so your product moves to the next release without a rewrite. Chapter 6 gives the record.

Chapter 12

Ordering Information

Contact us to discuss your project or to ask a question

Contact Information

Supplier

Registered name
O.S. SYSTEMS SOFTWARE LTDA
Office
Pelotas, Rio Grande do Sul, Brazil

Project inquiry