What is RITY? MediaTek's Genio reference distribution explained

Q: What is the difference between rity-bringup, rity-demo, and rity-skeleton?

rity-bringup is a minimal debug image (~150MB) for initial hardware verification. rity-demo is the full-featured image (~1GB) with GStreamer, AI/ML, Chromium, PipeWire, and camera support. rity-skeleton is a template layer for creating a custom derivative distribution on top of RITY.

RITY is the name MediaTek gives to their reference Yocto distribution for Genio AIoT boards. The name stands for Reference Implementation of Things in Yocto. It is not an RTOS, it is a standard Linux distribution that demonstrates how all of MediaTek’s hardware IP blocks (GPU, NPU, VPU, camera ISP, audio) integrate into a complete Yocto image. Understanding RITY is the fastest way to understand how a production Genio image should be structured.

Key Insights

RITY is not an RTOS: it is a Yocto-based Linux distribution; the name causes consistent confusion
Three useful distro variants: rity-bringup (minimal debug), rity-demo (full-featured), rity-skeleton (custom derivative template)
Packagegroup architecture keeps hardware IP isolated, each MediaTek feature is in its own packagegroup, which makes it easy to include or exclude
KAS is the build tool: kas build kas/rity-demo.yml is the single command that fetches all 8+ layer repos and builds the image
nda-mtk DISTRO_FEATURE is the gate for proprietary content, ISP, NeuroPilot, and hardware codecs require it
rity-skeleton is the right starting point for custom products, never modify meta-rity directly

What RITY actually is

RITY is a collection of Yocto layers hosted on MediaTek’s GitLab that demonstrate the full Genio software stack. It sits on top of:

poky, Yocto reference distribution
meta-openembedded, community package collection
meta-arm, ARM toolchain and firmware
meta-mediatek-bsp, MediaTek’s hardware drivers and firmware

RITY adds the integration layer on top: it knows which MediaTek firmware files belong together, which GStreamer plugins work with the VPU, and how to assemble a working Wayland display stack with the Mali GPU.

Layer structure

meta-rity/
├── kas/                    # KAS YAML build configurations
├── meta/                   # Base RITY layer (priority 8)
├── meta-rity-bringup/      # Minimal bringup variant (priority 9)
├── meta-rity-demo/         # Full demo variant (priority 9)
└── meta-rity-skeleton/     # Template for custom derivatives

Sublayers at priority 9 override the base layer at priority 8. LAYERSERIES_COMPAT is scarthgap, this is the Yocto release the current RITY version targets.

Distro variants

Distro	Image name	Size	What it includes
`rity-bringup`	`rity-bringup-image`	~150MB	SSH, debug tools, minimal rootfs
`rity-demo`	`rity-demo-image`	~1GB	Weston, GStreamer, AI/ML, PipeWire, NetworkManager
`rity-demo` + browser	`rity-browser-image`	~2GB	Everything in demo + Chromium
`rity-skeleton`	-	,	Template only, not a buildable image

rity-bringup

The right image for first board bring-up. It boots, gives you SSH access, and includes debug utilities (strace, gdb, bpftrace, perf). Use this to verify the hardware works before adding complexity.

rity-demo

The full integration demonstration. Key components enabled:

DISTRO_FEATURES:append = " \
    pipewire        # PipeWire audio replaces PulseAudio
    demo            # Demo-specific packages
    pam             # PAM authentication
    fwupdate        # EFI capsule firmware updates
    expand-rootfs   # Auto-expand rootfs on first boot
    btf             # eBPF introspection
"

rity-skeleton

The right starting point for a custom product. Copy meta-rity-skeleton, rename it, and build your product-specific recipes on top. Never modify meta-rity directly, any upstream update will conflict.

cp -r meta-rity-skeleton meta-myproduct
cd meta-myproduct
# Edit conf/layer.conf, change collection name, update LAYERDEPENDS
# Add your recipes in recipes-*/

Packagegroup architecture

RITY isolates each hardware capability into its own packagegroup. This makes it straightforward to include only what your product needs:

Packagegroup	Key contents
`rity-multimedia`	GStreamer 1.0 + libcamera + V4L2 tools
`rity-display`	Weston (Wayland compositor) + kmscube + Vulkan tools
`rity-audio`	PipeWire + ALSA utils + Bluetooth codecs (AAC, LC3)
`rity-ai-ml`	TensorFlow Lite + ArmNN + ONNX Runtime + NNStreamer
`rity-mtk-video`	VCU/VCodec hardware drivers + `mtk-vpud` daemon
`rity-mtk-camisp`	Camera ISP driver (public) or prebuilts (NDA)
`rity-mtk-neuropilot`	APUSys firmware + NPU driver + NeuroPilot middleware
`rity-net`	NetworkManager + iperf3
`rity-debug`	gdb, strace, bpftrace, perfetto, bcc, iotop
`rity-tsn`	linuxptp + `libopen62541` (OPC-UA) + real-time edge sysrepo

SoC-specific additions are gated by machine overrides:

IMAGE_INSTALL:append:mt8395 = " packagegroup-rity-mtk-camisp packagegroup-rity-mtk-neuropilot"
IMAGE_INSTALL:append:mt8391 = " packagegroup-rity-mtk-neuropilot packagegroup-rity-mtk-video"

DISTRO_FEATURES gating

Certain features require explicit opt-in via DISTRO_FEATURES:

Feature flag	What it unlocks
`nda-mtk`	RAW ISP (`mtk-camisp-prebuilts`), NDA firmware, proprietary codecs
`secure-boot`	FIT image signing, U-Boot key provisioning
`fwupdate`	EFI capsule OTA update infrastructure
`pipewire`	PipeWire audio stack (replaces PulseAudio)
`btf`	Kernel BPF Type Format + eBPF introspection tools
`expand-rootfs`	Auto-expand rootfs service on first boot

If nda-mtk is not set, camera ISP and hardware codec features silently fall back to software alternatives or are excluded entirely.

KAS build system

RITY uses KAS to manage the 8+ layer repos the full stack requires. Each kas/*.yml file pins all layers to specific git refspecs:

# kas/rity-demo.yml (simplified)
machine: i500-pumpkin
target: rity-demo-image
distro: rity-demo
includes:
  - kas/include/base.yml
  - kas/include/deps.yml

deps.yml pins:

poky, meta-openembedded, meta-arm
meta-rity, meta-mediatek-bsp
meta-mediatek-tsn, meta-mediatek-bluedroid
meta-nn, meta-tensorflow, meta-clang

Build with a single command:

kas build kas/rity-demo.yml

KAS clones all layers, generates bblayers.conf and local.conf, and runs BitBake. No manual setup.

To build for a specific board, substitute the kas file:

kas build kas/genio-720-evk-demo.yml

Notable implementation details

LLVM is the default toolchain. RITY uses meta-clang and sets LLVM as the preferred compiler. If you add recipes that assume ${CC} is GCC, they may need patches.

NetworkManager replaces systemd-networkd. systemd-networkd is explicitly disabled to prevent DHCP conflicts. All network configuration goes through NetworkManager or its CLI (nmcli).

Package format is .deb. PACKAGE_CLASSES = "package_deb" means the rootfs uses Debian-style packages. You can run apt on the target if you serve a package feed from your build output.

Debian package feed setup:

# Build the package index
bitbake package-index
# Serve from build directory
cd tmp/deploy/deb && python3 -m http.server 9876
# On local.conf, add:
# PACKAGE_FEED_URIS = "http://<host-ip>:9876"
# EXTRA_IMAGE_FEATURES:append = " package-management"
# On target:
apt-get update && apt-get install <package>

For the full Yocto build workflow including fetching the RITY manifest and flashing the result, see Yocto build guide for MediaTek Genio. For creating a custom layer on top of RITY, see building a custom Yocto meta layer for Genio.

FAQ

Is RITY an RTOS?

No. RITY is a full Linux distribution built on Yocto/Poky. It runs a standard Linux kernel with optional real-time patches. RITY stands for Reference Implementation of Things in Yocto, it is MediaTek’s reference AIoT image, not a real-time operating system.

What is the difference between rity-bringup, rity-demo, and rity-skeleton?

rity-bringup is a minimal debug image (~150MB) for initial hardware verification. rity-demo is the full-featured image (~1GB) with GStreamer, AI/ML, Chromium, PipeWire, and camera support. rity-skeleton is a template layer for creating a custom derivative distribution on top of RITY.

Do I need to use RITY for MediaTek Genio development?

No. RITY is a reference starting point. You can build a custom Yocto distro on top of the MediaTek BSP layer (meta-mediatek-bsp) without using RITY at all. RITY is most useful for understanding how MediaTek integrates their hardware IP, treat it as documentation you can run.

What is KAS and why does RITY use it?

KAS is a Python tool for orchestrating Yocto builds across multiple layer repositories. RITY uses KAS because the full stack requires 8+ layer repos at specific git refspecs. A single kas build kas/rity-demo.yml fetches all layers and builds the image without manual repo cloning or bblayers.conf editing.