What is RITY? MediaTek's Genio reference distribution explained

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.

---