In development · Features, versions and compatibility are reported by device and release.

rogpOS Wiki · technical reference

rogpOS architecture.

A drawing of how the R36S profile cuts across boot, hardware, and the gaming experience. The versions below describe the current engineering reference, not a public release.

R36S, R36S Plus and R40X Pro Max have registered hardware validation. The compatibility matrix informs the scope of each device.

Layer diagram

Layers from reference R36S.

The same flow is read from bottom to top: the physical base starts the device, boot delivers the kernel, the profile describes the peripherals and the experience layer presents the games.

Reference R36S · boot up experience

Choose a layer to see its function, technologies, and evidence criteria. Use the arrow keys to move through the tree.

L5

Selected layer

Experience

Launcher, interface and emulation. The launcher drives the library and the game session.

Function

Present the collection, guide the controls, and start a local session.

How is it checked

Validation observes the arrival of a usable interface on the profile device.

Launcher 0.2.0 RetroArch v1.21.0

The technical reference is not equivalent to an image of a public installation. Marks identify technologies used and do not represent endorsement or distribution.

L5

Experience

Launcher, interface and emulation. The launcher drives the library and the game session.

Launcher 0.2.0 · RetroArch v1.21.0
L4

Running system

Rootfs, systemd, SDL2 with KMSDRM and the local library index.

Buildroot 2026.05 · scanner 0.1.0
L3

Visual profile and hardware

DTB, dashboard and device-specific data come before the player experience.

Profiles with SHA-256 hash
L2

Kernel

The kernel initializes the devices described by the hardware profile.

Linux 6.18.36
L1

Startup

Loader, trust and U-Boot prepare the transition to the kernel.

U-Boot 2026.04
L0

Physical basis

BootROM and the device hardware form the immutable starting point for booting.

Technical reference: R36S
Algorithms and mechanisms

Operations that make the profile verifiable.

These are not promises of resources. These are routines that already shape the work of identifying a target, preparing the panel and organizing a local library.

01

Target identification

The profile compares known hashes of the target and, when necessary, the SHA-256 print of the active DTB. This avoids choosing an image with a similar name.

02

Dashboard profile

The generator normalizes panel DCS sequences and records a hash of the profile. The comparison works on canonical data, not on a loose description.

03

Library index

The C scanner traverses expected directories with limited depth, checks case-insensitive extensions, and writes the index to a temporary file followed by rename.

Current versions

Reference set.

The numbers correspond to the current engineering profile. They may change before a release and should not be used as installation instructions.

rogpOS
0.8.0-dev.1
Buildroot
2026.05
Linux
6.18.36
U-Boot
2026.04
RetroArch
v1.21.0
Launcher
0.2.0
Library Scanner
0.1.0
SDL2/KMSDRM
provided by Buildroot 2026.05
How we work

A change must keep the path readable.

  1. 01

    Fix the target

    Model, variant, DTB and version enter the registry before the change.

  2. 02

    Isolate a layer

    The bring-up reference separates the boot at L0 to L5 so that the failure is investigated at the right point.

  3. 03

    Validate on the device

    Boot, screen, input, and execution are observed on the profile's physical device.

  4. 04

    Publish with evidence

    A version only appears verified when the profile, hashes, and physical observation support the claim.

The matrix of compatibility is the public source for per-device status. The page does not advertise downloads, images or releases.