Homebrew app lkl-switch — Linux kernel running INSIDE Horizon as an NRO, executing real ELF binaries

[mnnobre]

Hi all,

I've been working on something I haven't seen done before and wanted to share it.

TL;DR: This is the Linux kernel (6.12) compiled as a library (LKL) and linked into a homebrew NRO. It boots inside Horizon OS — no reboot, no L4T, running as an app — and on top of it there's a from-scratch ELF loader + syscall bridge that executes an actual aarch64 Linux binary. The guest binary makes real Linux syscalls (openat/write/close) that hit the live kernel, and I can read back the file it wrote. All tested on hardware.

Let me be upfront about what this is NOT, because I don't want to oversell it:
- No GUI, no browser, no GPU, no desktop. The kernel is built no-MMU.
- It does not replace or compete with L4T Ubuntu. If you want a real Linux desktop on your Switch, use L4T — that's the right tool and it's great.
- No interactive shell yet (see roadmap).

What it IS: the Linux kernel as a library running inside Horizon, with a working binary executor. To my knowledge this specific thing (Linux executing binaries from inside Horizon, as homebrew) hasn't been published. I think it's a neat first and, more usefully, a foundation others can build on.

How the executor works (the interesting part):
No CPU emulation, no exception handler. The guest is aarch64, same as the Switch, so it runs natively. I load the ELF into jitCreate memory, apply relocations, and rewrite every svc #0 into a branch to a small trampoline that translates the Linux syscall ABI (x8=nr, x0–x5=args) into a call into the kernel. Three subtle bugs took most of the time — PIE relocations, out-of-range branches needing veneers, and x30 corruption when the svc sits inside a function. Full writeup in the repo's DEVLOG.

Source + build instructions: https://github.com/mnnobre/lkl-switch

Everything builds in a Docker container and there's a PC test harness (qemu-aarch64) so you can hack on it without a Switch.

Roadmap / help wanted:
The engine is done; the frontier is an interactive busybox shell — needs /dev/console wired to keyboard/screen, a lot more syscalls, and a fork story (LKL has no processes; busybox standalone mode should help). If anyone with LKL or no-MMU userland experience wants to jump in, PRs and ideas very welcome.

Happy to answer questions. Thanks to the LKL and libnx/devkitPro folks whose work this stands on.

 

[hippy dave]

Very interesting, good work!
Does the plan include being able to run graphical programs/games in the future or is this likely to be strictly command line?

 

[mnnobre]

Very interesting, good work!
Does the plan include being able to run graphical programs/games in the future or is this likely to be strictly command line?

Good question! Honestly: it's very likely to stay command-line / TUI, and I'd rather be upfront about why.

The kernel here is built no-MMU (LKL has no memory management unit), and it has no GPU driver — Horizon doesn't give homebrew the low-level GPU access a Linux DRM driver would need. So a real graphical stack (X11/Wayland + a compositor + GPU acceleration) isn't on the table for this approach. That's genuinely what L4T Ubuntu is for, and it does it well.

What could happen down the line is more limited and app-side: the NRO itself can draw to the screen (via deko3d), so in principle a program running on top of this Linux could render into a framebuffer we hand it — think a framebuffer-only browser like NetSurf, or simple TUI/ncurses apps — rather than a full desktop. That's a "someday, maybe" stretch goal, not a promise.

tl;dr: think "real Linux binaries + a terminal environment inside Horizon," not "desktop." For a graphical Linux desktop on Switch, L4T is still the right tool. Thanks for checking it out!

 

[hippy dave]

Good question! Honestly: it's very likely to stay command-line / TUI, and I'd rather be upfront about why.

The kernel here is built no-MMU (LKL has no memory management unit), and it has no GPU driver — Horizon doesn't give homebrew the low-level GPU access a Linux DRM driver would need. So a real graphical stack (X11/Wayland + a compositor + GPU acceleration) isn't on the table for this approach. That's genuinely what L4T Ubuntu is for, and it does it well.

What could happen down the line is more limited and app-side: the NRO itself can draw to the screen (via deko3d), so in principle a program running on top of this Linux could render into a framebuffer we hand it — think a framebuffer-only browser like NetSurf, or simple TUI/ncurses apps — rather than a full desktop. That's a "someday, maybe" stretch goal, not a promise.

tl;dr: think "real Linux binaries + a terminal environment inside Horizon," not "desktop." For a graphical Linux desktop on Switch, L4T is still the right tool. Thanks for checking it out!

Thanks for the detailed response! Do you think it could potentially run raspberry pi binaries that target raw framebuffer rather than desktop/windowing?

 

[mnnobre]

Thanks for the detailed response! Do you think it could potentially run raspberry pi binaries that target raw framebuffer rather than desktop/windowing?

Potentially yes — raw framebuffer software is actually one of the more realistic graphical targets for this approach.

If the program uses the standard Linux framebuffer interface (/dev/fb0, FBIOGET_VSCREENINFO, FBIOGET_FSCREENINFO, and mmap), I could implement a virtual framebuffer shim. The application would draw into a Linux-style pixel buffer, and the NRO would present that buffer through libnx/deko3d on the Switch screen.

There are some important limitations: the binary would currently need to be a static AArch64 Linux binary, avoid fork, and not depend on Raspberry Pi-specific hardware interfaces. ARM32/armhf binaries are not supported yet.

Software that accesses Broadcom MMIO, /dev/mem, the VideoCore mailbox, DispmanX, or Pi-specific GPU drivers would not run unchanged because the Switch uses completely different hardware. But portable fbdev applications should be feasible with a compatibility layer.

So: “Raspberry Pi binary” alone is not enough, but an AArch64 Linux application targeting generic /dev/fb0 rather than Broadcom hardware is a realistic future target.

Post automatically merged: 56 minutes ago

Big update: it now runs real unmodified busybox on the Switch —
ls, uname, echo all working via the LKL kernel. Details + screenshot
in the first post.