Hacking a Clone R36S: From Retro Handheld to Hyper-Mobile Compute Node

TL;DR: I turned a cheap clone R36S – a retro handheld gaming console – into a low-cost, ultra-portable Linux box with its own battery, Wi-Fi and GPU acceleration. I’m also working on hooking it into the Bless network. It wasn’t easy – this knock-off had its own NAND-based firmware and lots of quirks (think inverted joysticks, non-functional headphones and a bootloader with trust issues) – but after much kernel hacking, partition juggling and caffeinated troubleshooting, it works. This is the story of how I did it, told from the trenches, with all the hiccups and triumphs along the way.

The clone console conundrum 🤖

I aped into a super-cheap R36S handheld console clone – you know, those ~$30 retro game emulators you see on sketchy sites. It looks like a normal R36S on the outside, but under the hood it’s a different beast entirely. Unlike the official model, which boots off a microSD card, this clone came with its own internal NAND flash preloaded with a customized EmuELEC Linux firmware. In other words, the clone had a secret sauce baked into its internal storage, not just a removable SD card.

My goal? Boot my own custom firmware from the TF1 microSD slot instead of relying on the internal NAND. Essentially, I wanted to take control of the system software.

Why? Because I didn’t just want another retro gaming toy – I wanted to transform this thing into a hyper-mobile Linux compute node. Picture a pocket-sized server with a screen and controls: battery-powered, Wi-Fi connected and even boasting a little GPU that I could someday enlist in distributed computing projects (first port of call: the Bless network, the decentralized computing platform I help to lead as CTO).

But first, I had to deal with the clone’s quirks. And oh boy, there were many:

• Internal NAND firmware: The clone’s OS lived on internal flash memory (NAND), which complicates booting from SD. It’s like the device had an identity crisis: it defaulted to its built-in firmware and wasn’t eager to let an external SD take over.
• EmuELEC 4.7 (clone edition): It ran a skinned EmuELEC retro-gaming OS out of the box. Decent for games, but as soon as I tried other firmware builds or updates, things went wonky – because this was a “fake” R36S with different hardware under the hood.
• Odd hardware behavior: Using standard firmware images meant broken audio and controls. The headphone jack was effectively possessed – plug in headphones and you got sound, unplug the headphones and the speakers sometimes didn’t come back on. The volume rocker did nothing at all (imagine blasting sound with no way to turn it down – thanks, clone!). Even the analog thumbsticks were mapped all wrong; at one point up was down, left was right – a real Stranger Things situation. Clearly, the clone’s hardware wasn’t fully supported by off-the-shelf images.
• Missing drivers: Some of the hardware simply wasn’t recognized on alternative firmware. The Wi-Fi wouldn’t connect because the driver for the clone’s Wi-Fi chip wasn’t present. Who knows what else was missing – likely the kernel on stock EmuELEC had custom patches for this weird variant that vanilla builds lacked.

In short, this clone was a beautiful headache. To make my dream – a mini Linux server that plays SNES games – come true, I had to get around the NAND boot, fix the hardware bugs and customize the system at a low level. Time to pop open a terminal and get my hands dirty.

Partition puzzle: reverse-engineering the NAND 🗺️

First step in any good console hack: map out the land. I needed to understand how the internal NAND was organized – what partitions it had, where the bootloader was, where the system files were, etc. Since I couldn’t just plug the NAND into my PC (it’s soldered inside the device), I went full-on cyber detective using the device’s own Linux.

On the device, I ran good ol’ lsblk (list block devices) and some mount commands to see what was what. The output revealed a maze of partitions on the internal eMMC (mmcblk0). It looked something like this:

• mmcblk0boot0 & mmcblk0boot1: Tiny 4MB regions – likely where the low-level bootloader (U-Boot) resides. These don’t show up as normal mounts (they’re special hidden boot areas).
• mmcblk0p1 & mmcblk0p2: Small partitions (a few MB each). Possibly containing bootloader config or used as scratch space. One seemed to be labeled “boot” but wasn’t mounted – suspicious.
• mmcblk0p3: About 1GB, formatted as VFAT and mounted at /var/media/EMUELEC. Aha, this looked like the boot partition for EmuELEC. Indeed, listing its contents showed the telltale files of an EmuELEC setup: a KERNEL image, a SYSTEM file, a dtb (device tree blob), plus config files like boot.ini and an extlinux directory. So p3 was basically the /boot partition containing the kernel and initial filesystem.
• mmcblk0p4: ~512MB, not mounted by the running system. This smelled like the “system” partition – possibly containing the compressed root filesystem (EmuELEC often stores its core OS in a file on the boot partition or a dedicated partition). The size made sense for a SquashFS image or ext4 with system files. We’d confirm this soon.
• mmcblk0p5: ~1.1GB, ext4, mounted at /var/media/STORAGE. In EmuELEC terms, this is the “storage” partition – where all the user data, saves, and configuration live (basically your /home and saves for emulators). This is equivalent to “/storage” in EmuELEC’s Linux.

So the clone’s internal flash was partitioned much like a typical EmuELEC SD card, just carved into internal memory. The existence of separate boot (p3) and storage (p5) and an unmounted p4 strongly hinted that mmcblk0p4 held the root filesystem (OS) in some form. In EmuELEC, the root filesystem is often a read-only SquashFS image named SYSTEM (which might actually reside on the boot partition). Since I saw a file named SYSTEM on p3, it could be that mmcblk0p4 was unused or for a secondary OS… The clone-makers did something funky here, but either way, I identified the partitions I cared about:

• Boot – /dev/mmcblk0p3 (FAT32, contains kernel + boot files).
• System – /dev/mmcblk0p4 (ext4 or SquashFS partition for OS).
• Storage – /dev/mmcblk0p5 (ext4, holds configs, game ROMs, saves, etc).

Also lurking was a boot.ini and an extlinux.conf on the boot partition. These are bootloader config files. On RK3326 devices like this, U-Boot (the BIOS-like firmware) uses those files to know what to boot. I cracked open extlinux.conf and found it referencing partitions by label (e.g. boot=LABEL=EMUELEC disk=LABEL=STORAGE) – which is friendly, since using labels means it’s not hard-coded to mmcblk0 (internal). This gave me hope: if I cloned these partitions to an SD card and kept the labels, the bootloader might happily boot off an inserted SD. Boot order on these devices usually tries SD (TF1) first, then internal – but with a clone you never know. At least no obvious UUID or fixed mmc path was in the config to foil us.

One curveball: I expected to find a U-Boot binary or something in the boot partition (like uboot.img or similar), but it wasn’t there. Likely, the bootloader is stored in those mmcblk0boot0/1 regions or was flashed to a reserved area – meaning it’s hidden from the Linux filesystem view. This meant I didn’t need to copy the bootloader itself (and frankly, you shouldn’t mess with it). I just needed the data partitions. Good.

NAND to SD: cloning the brain 🧠➡️💾

To run custom firmware from the TF1 SD slot, I decided to clone the internal boot and system partitions onto an SD card, then modify things as needed. Essentially, I needed to perform a DIY “brain transplant” – taking the OS out of the device’s internal brain and moving it to a removable card where I could tinker freely.

Since the R36S clone was a Linux system with both the internal flash and the SD slot accessible, I used the device to clone itself (a bit meta, I know). I inserted a fresh microSD (let’s call it TF1 card) and noted it showed up as /dev/mmcblk1 (or /dev/mmcblk2 depending on how the kernel enumerated; the naming was slightly confusing with “TF1” and possibly “TF2” slots, but basically I found the SD card device node). Then I used the trusty dd command to dump the internal partitions to image files on the SD. For example:

# Back up boot partition to an image file on SD: dd if=/dev/mmcblk0p3 of=/path/to/sdcard/boot_backup.img bs=4M

# Back up system partition: dd if=/dev/mmcblk0p4 of=/path/to/sdcard/system_backup.img bs=4M

(Pro tip: always double-check your if (input file) and of (output file) when using dd. Swapping them or pointing to the wrong mmc can turn your console into a very nice paperweight. I triple-checked and used bs=4M to speed it up a bit.)

This process took a while (several hundred MB being read at slow eMMC speeds), but eventually I had boot_backup.img and system_backup.img sitting on the SD card. These were essentially raw images of the clone’s firmware. I copied these to my PC for safekeeping – a backup in case I needed to restore the original setup (or if I bricked something, which was a non-zero possibility in this adventure).

Now, I wanted to make the SD card itself bootable with these images. One way was to flash those images onto the SD as actual partitions. I decided to replicate the partition structure on the SD:

• Partition 1: FAT32, label it EMUELEC, size ~1GB, and put the contents of boot_backup.img there.
• Partition 2: ext4, label it STORAGE, size ~1.1GB, and copy storage (I could also clone p5 if I wanted all my games/settings, but I was okay setting that up fresh or copying selectively).
• Partition 3: ext4, label it maybe SYSTEM if needed, size ~512MB, and restore system_backup.img there (if the OS expects a separate partition).

However, because the original used p4 for system but also had a SYSTEM file on the boot partition, there was some weirdness. Upon inspection, the SYSTEM file on the boot partition was likely a compressed OS image that gets loaded at boot. So it’s possible that mmcblk0p4 wasn’t actively used at runtime. It might have been a failsafe or a red herring. Just to be safe, I cloned it anyway.

Using a partitioning tool on my PC, I set up the SD with matching labels and sizes and wrote the images to those partitions. A simpler approach crossed my mind: I could have used dd to copy the entire mmcblk0 device to the SD in one go (making a block-for-block clone), but since the internal flash was 8GB and my SD was larger (and I also wanted to tweak things), I went with manual partitioning.

Once the SD card had the cloned partitions, I had to adjust a couple of things:

• UUIDs or labels: Because I was essentially cloning, the labels “EMUELEC” and “STORAGE” were now present on both the internal NAND and the SD card. If both were inserted/connected, that could confuse the system (two volumes with the same label). The bootloader might boot the wrong one or mount the wrong storage. To avoid this, I decided to temporarily rename the internal ones or just rely on one at a time. Easiest hack: I changed the labels on my SD card clones to something like EMUELECSD and STORAGESD, and then edited the SD’s extlinux.conf to point to those new labels. This way, the bootloader would specifically boot the SD card’s system. Alternatively, I could have removed the internal flash or its entries, but I wasn’t about to desolder anything.
• boot.ini/extlinux.conf: I double-checked these files on the SD’s boot partition. They contained references to EMUELEC and STORAGE. Since I changed labels to avoid conflict, I updated them accordingly. For example, in extlinux.conf I set boot=LABEL=EMUELECSD and disk=LABEL=STORAGESD. If I kept the labels the same, I might have had to ensure the internal NAND was not accessed or was absent during boot tests (maybe by physically removing the NAND’s power or something extreme). Editing the config was cleaner.

With that done, it was the moment of truth: time to boot from TF1.

Booting from TF1: waking the Frankenstein 🧟♂️

I popped the prepared SD (TF1) into the clone and powered it on with fingers crossed. Lo and behold, it booted right up from the SD! 🎉 The screen lit up with the EmuELEC logo and soon I was in the familiar EmuELEC front-end. At first glance, it looked just like the internal system – it was an exact clone, after all. The best part: because it was essentially running the stock firmware (just relocated), all the hardware worked as before. The thumbsticks weren’t inverted, the volume and audio issues were the same as ever (still needed fixing, but at least they were no worse than stock), and the device didn’t explode. Success, in a basic sense: I had wrestled control away from the internal NAND – now I could boot into my own SD-based system.

Importantly, the internal NAND was untouched and still there. If I removed the SD, the device would fall back to booting its original firmware from NAND. This dual-boot scenario was a nice safety net: if my SD experiments went south, I could always boot back into NAND by just pulling the card. In effect, I had a backup brain for the device.

At this point, I effectively had a working baseline on the SD that mirrored the original firmware. This was my sandbox in which I could start customizing. The real fun (and frustration) was about to begin: fixing those glitches and modding the OS for my grander purposes.

EmuELEC versus the clone: fixing the glitches 🎮👾

Running the stock EmuELEC clone OS from SD was fine, but I wanted to upgrade and customize. The stock was based on EmuELEC 4.x, which is a bit dated. I was itching to try newer firmware like ArkOS or AmberELEC, or at least update EmuELEC itself for better performance and features. Plus, I had to resolve the pesky issues (audio, volume, controls) to have a truly solid system.

So I tried flashing an official EmuELEC build for RK3326 devices and booting that. Cue the Twilight Zone theme: the device booted, but the experience was janky:

• The console UI loaded, but no sound came out of the speaker. Plugging in headphones gave sound, but unplugging them would sometimes not restore speaker output without a reboot. Essentially, the headphone jack sensor or amp driver wasn’t behaving. Likely the clone uses a different audio codec or amp that the official firmware didn’t fully support.
• The volume buttons were dead. The UI showed volume 100% and pressing the side volume rocker did nothing. The device had two volume settings: maxed, or mute (if I poked around in the settings). Not ideal for a handheld!
• The analog sticks were acting wonky – as I feared, the axes were possibly inverted or mis-mapped. Navigating menus felt weird and in games my character would stare at the sky when I pushed the stick up. This mapping issue was probably down to the device tree or input driver differences on the clone.
• Some buttons were mismatched in certain apps (like the File Manager using Start/Select oddly, as other users have flagged online). A minor annoyance, but evidence of subtle input differences.
• Wi-Fi was not connecting. The menu showed Wi-Fi options, but the device couldn’t find any networks. On stock, Wi-Fi worked (the clone likely has a Realtek chip that was supported in their kernel). The new firmware was probably missing firmware blobs or drivers for that chip. No Wi-Fi meant my “portable node” dream was on hold until I fixed it. What’s a node that can’t connect to a network, right?

Essentially, the clone hardware was sufficiently different that mainstream OS builds didn’t fully support it. This is a common pain with knock-off devices: they often use slightly different components (to cut cost) or different GPIO mappings. The manufacturer had addressed the issue by customizing EmuELEC for the device, but those changes weren’t in the public releases.

I had two paths: either find a community firmware specifically for this clone (if one existed), or roll up my sleeves and patch things myself. Spoiler: I ended up doing a bit of both. There was talk online of an unofficial ArkOS build for R36S clones, but early reports said it still had issues (like the volume and performance problems). Rather than waiting for a perfect pre-made solution, I decided to take matters into my own hands. After all, I had the working stock system as reference – I could use that to guide fixes in a custom build.

Kernel hacking 101 🛠️🐧

The key to fixing most of these issues lay in the Linux kernel and the device tree (DTB). The kernel is responsible for hardware drivers (audio codec, input devices, etc.), and the device tree is like a blueprint that tells the kernel what hardware is present and how it’s wired up (which GPIO pin is the volume button, what I2C bus the audio codec is on, etc.). The clone’s working kernel likely had specific drivers enabled and a custom DTB tuned for its hardware. My plan: extract those elements and use them in a new build.

Step 1: Grab the clone’s kernel config and DTB. On the running stock system, I pulled /proc/config.gz (which, if enabled, contains the kernel configuration used to build the running kernel) and the device tree blob file (rk3326-evb-lp3-v12-linux.dtb in this case). With these, I had the ingredients list of the working system.

Step 2: Set up a build environment. I fired up a Linux machine and downloaded the source code for the kernel that EmuELEC/ArkOS uses for RK3326 devices (this SoC is well-supported by the community). Using the clone’s config as a base (I literally did zcat config.gz > .config in the kernel source), I configured the kernel. I made sure to enable drivers that I suspected were needed:

• The audio driver for whatever codec/amp the device has (maybe a specific GPIO amp enable or a mixer quirk).
• The rk_adc_joystick driver for the analog sticks (this reads the voltage from the sticks if they are ADC-based).
• The GPIO volume keys as input devices.
• Wi-Fi drivers/firmware for the Realtek chip (enabled the module and made sure firmware files are included in the build).
• Basically, anything in the config that looked “non-standard” and was shared by the config of the clone, I kept. The motto was “If it ain’t broke in the stock kernel, don’t remove it.” In fact, I compared the clone’s config to mainline EmuELEC’s config to spot differences – those differences were clues to what needed to be enabled.

Step 3: Build the kernel (and maybe U-Boot). I kicked off the kernel compile (cross-compiling for ARM on my PC – no way I was compiling natively on the tiny handheld). This took some time, but eventually I got a shiny new zImage (kernel image) and modules. I also compiled a matching DTB, using the clone’s DTB as reference. I even considered building a custom U-Boot with some tweaks, but that was optional flair – still, I enabled splash screen support in U-Boot for fun, because why not have a custom boot logo?

Step 4: Integrate and test. I copied the new kernel and DTB onto the SD’s boot partition, replacing the old ones (keeping backups of course). I also put the compiled kernel modules into the SD’s storage partition under /lib/modules/.... With everything in place, I attempted to boot the device with this new custom kernel.

The first boot attempt with a new kernel is always suspenseful. Will it boot at all? Or will I get a black screen because I screwed up the device tree? In this case it booted – phew! EmuELEC’s front-end came up. Now the moment of truth: did it solve the issues?

• Audio/headphone: I tested the headphone jack trick: plugged in, got sound in headphones; unplugged, and YES – the speakers sprang back to life! 🎶 The audio driver was handling jack events properly now. No more silent treatment after using headphones. Victory!
• Volume keys: I mashed the volume rocker and saw the on-screen volume indicator move! The buttons were finally recognized and working. I could actually turn the volume down if a game intro was blaring. Small quality of life improvement, huge satisfaction.
• Analog sticks: Went into a game and moved the sticks – they responded correctly, no inverted axes. The character moved exactly as my thumbs intended. That was a big relief. The combination of the right driver and the correct device tree calibration did the trick. It felt buttery smooth, just like on stock.
• Wi-Fi: Entered the network settings, and hallelujah, it scanned and found my Wi-Fi network. The driver loaded and the clone was online once again. Time to ssh in or scrape some achievement data, etc. For my future plans (using it as a mini-server), network is key – so this was huge.

I basically merged the best of both worlds: the community firmware base + the clone-specific fixes. The result was a custom firmware tailored to this clone hardware. No more funky bugs – it was stable enough to use daily, either for retro gaming or as a tiny Linux box.

Low-Cost Linux Node: The Bigger Vision 🌐🚀

Okay, so I got EmuELEC working nicely – big whoop, I can play retro games as intended. But remember, I had a grander plan. This $30 gadget isn’t just a Game Boy; it’s a fully functional Linux computer with a battery, screen, controls, Wi-Fi and even a 3D GPU (the RK3326 has a Mali GPU that can do OpenGL ES and possibly some lightweight compute).

In hacker terms, I now have an ultra-portable, self-powered node. It’s not going to replace my laptop or a Raspberry Pi 4 for heavy tasks, but it has something many SBCs don’t: an integrated UPS (the battery) and a built-in display/control interface. This makes it a kind of cyberdeck in miniature – I can throw it in a bag and run it on the go.

My plan is to integrate it into the Bless network. For the uninitiated, Bless is a decentralized compute network which turns idle devices into a globally shared supercomputer. Think of it as folding@home meets crypto meets edge computing. Nodes in Bless can contribute CPU/GPU power for distributed tasks and earn rewards, and anybody who needs a little computing muscle can submit workload requests to the network.

Now, running heavy AI tasks on an R36S clone might sound silly, but a network is all about many devices working together. And hey, every bit counts! Plus, it’s an awesome thought that my little retro handheld could, when I’m not using it, help process data for AI, crunch numbers or serve content in a distributed web. It’s the whole Web3 ethos of using what you have to contribute to a decentralized system.

I haven’t hooked it up to Bless yet – that’s the next chapter – but I’ve prepared the ground. The device now runs a clean Armbian/EmuELEC hybrid with full shell access, so I can install Docker or native binaries for the Bless client. I even tested some OpenGL compute shaders on the Mali GPU – it’s limited, but it works. Who knows, maybe I’ll get PyTorch running with the OpenCL drivers and have it do tiny ML tasks, just for giggles.

In essence, what started as a goofy idea – “can I make this fake Game Boy into a server?” – turned into a sweet reality. I can SSH into it, run scripts and use it as a media server or an emulator, all on battery power. And when I’m feeling extra degen, I’ll let it contribute to some decentralized compute jobs overnight. It’s about maximizing value: why let the device sit idle when I’m not gaming? Idle devices are the devil’s playground – better put them to work for humanity (or at least for science).

Chaotic triumph 🏆🤘

The journey wasn’t all sunshine and rainbows. I had nights where nothing would boot and I thought I’d bricked the thing. I had a heart attack when a dd command froze (was sure I nuked the bootloader – turned out it was just writing slowly). I cursed U-Boot more than once when dealing with extlinux.conf syntax. I learned to read device tree source like it was ancient scripture, hunting for the line that defines the headphone detect pin. There were moments of “why am I doing this to myself?” followed by “aha, got it!” when a fix worked.

In true hacker spirit, I also got sidetracked adding extras: I set up a custom boot splash screen (I couldn’t resist putting a custom ASCII art and a cheeky “gm” message on boot – very Web3 of me, I know). I wrote an autostart script that connects to Wi-Fi and prints a random crypto meme to the terminal on startup, just for laughs. The device now greets me with “🌅 gm! ready to pwn some bytes” when I SSH in. It’s the little things.

Finally seeing the device boot with no errors, sound working, controls perfect – that felt like beating the final boss. But in this game, the end is just the beginning: now I get to actually use this Franken-console for my experiments.

Tips & tricks for fellow tinkerers 🔧

If you’re crazy enough to attempt something similar (whether with an R36S clone or any retro handheld you want to repurpose), here are my hard-won tips:

• Back up everything first: Before you change anything, dump those internal partitions. Save your NAND contents to images so you can restore if needed. Trust me, you don’t want to accidentally lose the only copy of the clone’s working firmware.
• Know your boot order: Understand how your device decides between internal versus SD boot. Many devices will boot SD if present. Use that to your advantage (like I did) to experiment safely. If not, you might have to toggle a switch or flash a different U-Boot – do your research.
• Mind the labels/UUIDs: When cloning partitions, identical labels or UUIDs can confuse the system. Change labels on your cloned SD or use unique identifiers, and update boot configs (extlinux.conf or boot.ini) accordingly. This avoids the scenario of the device accidentally mounting the wrong root filesystem.
• dd with caution: The dd command is powerful but very dangerous. A tiny typo can overwrite your bootloader or partition table. Double-check device names (e.g., mmcblk0 vs mmcblk1) before hitting enter. And don’t mix up if= and of=! You want to read from the source (if) and write to the destination (of), not the other way around.
• Leverage the original firmware: Use the working stock system as a reference. Extract the kernel config (/proc/config.gz) and the device tree from it. These are gold mines of info about what drivers and settings the device needs. Diff them with a known working config from another build to spot what’s unique.
• Enable drivers in kernel build: When compiling a custom kernel, make sure to enable support for all the hardware. For example, in my case I ensured the audio codec driver, the joystick ADC driver, Wi-Fi modules and even quirky things like “GPIO volume keys” were turned on. If unsure, compile them as modules so you can load them later.
• Device tree tweaks: If you’re comfortable, edit the device tree source (.dts). This is where you can fix inverted axes (by swapping coordinates), correct button mappings or set the proper GPIO for the headphone detect. The stock DTB from the clone was my template – I basically ensured my new DTB had all the same nodes (audio, regulators, input) as the original.
• Test iteratively: Don’t change 100 things at once and then boot – you won’t know what broke it. Change a few things, boot up, and check dmesg logs for errors. For example, after enabling a driver, see if dmesg shows it initializing or throwing errors. Incremental progress beats blind overhauls.
• Have a serial console (if possible): This is optional, but if your device has a UART header, get a USB serial cable. It can spit out boot logs from U-Boot and early kernel. This could have saved me when I had a black screen – I would have been able to see that the kernel was panicking on serial. It’s a lifesaver for debugging boot issues.
• Patience & community: Hacking these devices can be maddening. When stuck, I searched forums and Discords for others who dealt with R36S clones. Sure enough, I found tidbits (like a particular DTB file someone shared, or a mention that “volume keys don’t work on clone unless you compile X”). The retro handheld community is full of smart folks – leverage that collective knowledge. And be patient with yourself; take a break if you hit a wall. Sometimes a fresh mind or a cup of coffee is the best debugging tool.
• Have fun with it: This isn’t enterprise IT – it’s a hobby project. So throw in a custom splash screen, give your device a funny hostname (i.e., hostnamectl set-hostname lil-degen-node), and enjoy the process. The more personality you infuse, the more rewarding it feels at the end.

Final thoughts

What started as a quest to fix a clone of a gaming handheld ended up as a celebration of hacking and repurposing tech. I now have a unique device that reflects my personality: it lets me play my retro games, and behind the scenes it’s running a tweaked Linux ready to do my bidding – whether that’s hosting a tiny web service, running a script to tweet weather data or joining a decentralized compute grid to earn some crypto.

In the era of disposable gadgets, it feels good to take control of a device and make it do things it was never “supposed” to do. There’s a special kind of satisfaction in beating proprietary quirks with open-source tools and a bit of elbow grease. It’s like shouting “I do what I want!” to the void – and the void saying “It’s true.”

So here’s to the hackers, the tinkerers, the ones who see more in a device than what the marketing tells us. Today it’s a clone R36S turned DIY Linux PC. Tomorrow, who knows – maybe I’ll be modding a smart toaster to mine Dogecoin (kidding… mostly). The spirit remains the same: take stuff apart, build it better and have a blast doing it.

Thanks for reading, and see you on the Bless network (look out for a tiny handheld node humming away 🌐✌️)!