R36S WiFi handheld beside a microSD card and card reader, ready for a firmware install

How to Install Arch R Linux on the R36S (Tested, With Real Measurements)

We installed Arch R on an R36S WiFi from our own stock and measured what it does. Everything below is from that console, including the parts that went wrong. Use a spare SD card so the one your console shipped with stays untouched.

What Arch R actually changes
  • A modern kernel. 6.12 mainline, against the 2021-era 4.4 kernel that ArkOS and dArkOS both run.
  • A working hardware video decoder. This is the headline. Your console has a video decoding chip that older firmware never exposes at all.
  • Real Arch Linux underneath, with the pacman package manager and signed repositories.
  • No web browser, and that matters more than it sounds. See the honest section at the end.

Before you start

  • A spare microSD card, 8 GB minimum, 16 GB recommended.
  • Your console's original DTB file. This is not optional. Copy every .dtb file and the ScreenFiles folder off your existing card's small BOOT partition before you begin. Arch R images do not include panel data, and without the right overlay you get a black screen.
  • The console on a charger. First boot reboots twice.
  • A PC. The official flasher has Windows, Mac and Linux builds.

Step 1: Download and verify

Get the latest release from the Arch R releases page. Choose Original for a genuine R36S board and Clone for K36 and similar. The image is about 1.6 GB compressed.

Check the download against the published SHA256SUMS file before flashing. We did, and it matched. This takes seconds and saves you chasing phantom faults later.

Step 2: Generate your panel overlay

This is the step people skip, and it is the one that produces the dreaded black screen. Arch R needs a small file describing your exact display, generated from your own console's device tree.

Use the Arch R overlay generator in your browser, or the offline Python tool if you prefer. Feed it the rk3326-r36s-linux.dtb from your original card. It extracts your panel's timing, initialisation sequence and wiring, and produces one file called mipi-panel.dtbo.

The filename is not negotiable. It must be exactly mipi-panel.dtbo and it must sit in the overlays folder on the boot partition. That path is hardcoded in the bootloader. Rename it or move it and the console boots to a black screen while running perfectly underneath.

Step 3: Flash

The easiest route is the Arch R Flasher, which downloads, verifies, flashes and installs your overlay in one pass. Enable its verification option; it checks the write and measures card speed, catching a bad card before you waste a boot on it.

If you flash manually instead, mount the boot partition afterwards and copy the overlay into overlays/mipi-panel.dtbo yourself.

Step 4: First boot

Insert the card in slot 1 and power on. You will see a message about initialising configuration while it resizes the partition and generates identifiers. It reboots itself, creates the game folders, and reboots again into the games menu. Two automatic reboots, two to three minutes total.

Do not touch the power button during this. Interrupting a filesystem resize is the one reliable way to corrupt the card, and we learned that the hard way later in our own testing.

Step 5: Network and remote access

Connect WiFi from the network section of the games menu. Our internal Realtek WiFi module worked without any configuration on this kernel.

SSH is off by default. Turn it on under System Settings, then Network, then Enable SSH. The login is user root with password archr, and the console answers to archr.local. Change that password immediately with passwd, because it is published on the project's own website and anyone on your network knows it.

What we measured on the console

The hardware video decoder is real

This is the genuine advance. On Arch R your console exposes a video decoder and a video encoder as standard devices, with the hantro_vpu driver loaded and helper modules for H.264, VP9 and JPEG. The bundled ffmpeg lists hardware decoders for H.264, HEVC, MPEG-1, MPEG-2 and H.263.

On ArkOS and dArkOS none of this exists. There are no video device nodes at all, only a legacy vendor interface that ordinary software cannot address. So on those systems every frame of video is decoded by the CPU.

The CPU is deliberately held back

Setting Value
Maximum clock as shipped 1.416 GHz
Available steps 408, 816, 1008, 1416 MHz
Turbo step in the hardware 1.512 GHz, disabled by default
Governor performance

Arch R ships with turbo mode switched off, so you run at 1.416 GHz rather than the 1.512 GHz that dArkOS allows. The project's own troubleshooting notes list turbo as a cause of boot loops on this hardware, so we would leave it alone.

Thermal throttling starts very early

Out of the box, the first throttle point is 70°C and the second is 85°C, with emergency shutdown at 115°C. That is conservative. Our console idles in the low seventies, so it begins stepping the clock down almost immediately under any real work.

You can raise those limits, and we did. Be aware of what we found on the older firmware though: raising the limit from 85°C to 100°C and then 105°C bought no extra performance at all. The chip simply ran twenty degrees hotter and throttled just as hard once it got there, because a fanless plastic shell cannot shed the heat regardless. The only real fix is physical, a copper shim or thermal pad between the chip and the back cover.

Space is tight where it matters

The system partition is 4.4 GB and arrives 97% full, with about 136 MB free. The separate storage partition has around 9.9 GB. Anything you add has to go on storage, not the system partition.

The honest part: no browser

Arch R's own repository holds 543 packages covering emulators, RetroArch, PortMaster and PPSSPP. It contains no web browser, and no Moonlight either.

We tried hard to add one and it did not stick. The short version:

  • Arch Linux ARM's Chromium is compiled with hardware decoding support, which is exactly what you would want here. It refuses to run because it was built against a newer system C library than Arch R ships, and when we supplied one it could not locate its own data files.
  • Google's ARM64 Chrome extracted and launched, and we signed into a cloud gaming service with it. After a reboot it stopped starting entirely, failing at graphics initialisation.
  • There is no X server, only the Wayland compositor Sway. More surprisingly, the console has no pointer device at all, so nothing in a browser is clickable until you create a virtual mouse. We had to build one before a single button could be pressed.

And the GPU never rendered anything

This one is worth knowing before you invest a weekend. We checked the graphics chip's own frequency records, which count how long it spends at each speed and how often it changes. Across an entire session of running a browser:

Measurement Result
Time at idle speed, 200 MHz 100% of uptime
Time at any higher speed zero
Frequency changes zero

A graphics chip doing work clocks up within milliseconds. Ours never left idle. So despite the newer kernel and the open driver being available, browser rendering still happened entirely on the CPU, exactly as on the older firmware.

So should you install it?

Yes, if your console is for emulation. A mainline kernel, an actively maintained project with regular updates, a real package manager and a hardware video decoder make it a more modern foundation than firmware built on a 2021 vendor kernel.

No, if you want a browser or cloud gaming. There is no browser in the repository, adding one is fragile, and the hardware decoder that makes Arch R interesting is not reachable from any browser we could get running.

Either way, use a spare card. Your original card stays untouched in a drawer, and swapping back takes thirty seconds. We hit a corrupted filesystem and an unexplained reboot during our testing, and being able to fall back cost us nothing.

Questions about any step? Message us on WhatsApp from the product page and mention this guide. We tested this on the exact console we sell, so send a photo of the screen and we can usually tell you what went wrong.

Back to blog