Codex built and setup my Luckfox Lyra on the picocalc

PicoCalc
,
1

picocalc-weather-download
picocalc-weather-download320×320 8.58 KB

I bought the Luckfox Lyra last year. I tried to get it working a few times, but the setup requirements and the number of problems were just too much.

Yesterday, while working on another project, I thought, “Why don’t I let Codex figure this out and get it running for me?”

About four hours later, I had the Luckfox Lyra installed in my PicoCalc and running.

I do not know all the details, but there are supposed to be some legal issues between Luckfox and Ubuntu. There were also repository issues, so Codex recommended using the Luckfox kernel instead of Ubuntu. I was not sure about that choice at first, but it worked out.

The Python build did not include the curses module. Since we had the cross-compiler working, Codex found the needed source, compiled it, and installed it. Who needs a repo?

There were many restarts while trying to compile the kernel from source, but Codex kept going and solved each problem as it came up. I would not have been successful doing this by myself.

Once the system was installed, we needed Wi-Fi. I had the same Wi-Fi dongle that many people seem to use with this setup. That had problems too. For some reason, that family of dongles was blacklisted by the kernel. Codex found a driver with source code, made the needed changes, used the cross-compiler to build it, installed it, and configured everything to use it.

And it worked the first time.

At one point, we ran into a memory issue, so I asked about swap. The kernel was not set up to use swap yet. Codex created a swap file and configured the system to use it. The Rockchip board has about 120 MB of RAM, and after the system is running, about 94 MB is left for everything else. Now it also has 1 GB of swap. That is tiny on a normal computer, but huge for this system.

Here is an app Codex converted from a CircuitPython PicoCalc app.

What I have now is a set of tools and utilities that let me use the PicoCalc with the Luckfox Lyra without needing a full desktop GUI. The screen is so small that I am not sure I need a desktop or mouse emulation. I really just need a launcher, like the kind we build for the Pico 2 W.

The big difference is that the Luckfox gives me real internet access, REST calls, and SSH. I can SSH into it and out from it. It is much more capable than the Pico 2 W for this kind of work.

I am very happy that Codex got it running for me.

Here is a link to a repository that documents the work it took to get this running in my setup:

luckfox-lyra-picocalc

2 Likes
2

Here’s a quick forum post draft:

A Thonny-Like Dev Loop for Luckfox Lyra on PicoCalc

I added a small development loop to my Luckfox Lyra PicoCalc project that feels a bit like using Thonny, but for the Luckfox running Linux.

The basic idea is simple:

  1. Edit the code on my Windows machine.
  2. Use ADB to sync the shared Python library folder to the PicoCalc.
  3. Push the Python app I am working on.
  4. Run it on the PicoCalc as the normal neusse user.
  5. Repeat.

The helper script is here:

scripts/host/luckfox-dev.py

Example:

python .\scripts\host\luckfox-dev.py runpy .\examples\python\picocalc_weather.py --once

For framebuffer apps, this makes testing much faster. I can edit locally, run the command, and see the result on the PicoCalc screen without manually copying files around.

I also use it for one-shot screenshot renders, like the Sudoku app:

python .\scripts\host\luckfox-dev.py runpy .\examples\python\picocalc_sudoku.py --menu-once
python .\scripts\host\luckfox-dev.py runpy .\examples\python\picocalc_sudoku.py --demo --once

Interactive framebuffer apps still need to be launched from the physical PicoCalc console because they read the PicoCalc keyboard through /dev/input/event*. But for quick render tests, screenshots, and normal Python experiments, this loop is very handy.

The repo is updated with the code and docs here:

The dev-loop notes are in:

docs/dev-loop.md

And the helper itself is in:

scripts/host/luckfox-dev.py
1 Like
3

Graphical Sudoku on the Luckfox Lyra PicoCalc

I also added a graphical Sudoku app for the Luckfox Lyra running inside the PicoCalc.

This started as a CircuitPython PicoCalc app, but it is now running as a Linux framebuffer app on the Luckfox. It draws directly to /dev/fb0, uses the PicoCalc keyboard through /dev/input/event*, and saves unfinished games so they can be continued later.

Here is what it looks like:

picocalc-sudoku-board-20260616-181316
picocalc-sudoku-board-20260616-181316320×320 4.32 KB

The app has a graphical start menu. If a saved game exists, it shows:

CONTINUE
EASY
MEDIUM
HARD
EXIT

If there is no saved game, it starts with the difficulty choices:

EASY
MEDIUM
HARD
EXIT

Controls are simple:

Arrow keys     Move around the board
1-9            Enter a number
0 or Delete    Clear a cell
s              Save
q              Save and quit
Backspace      Save and quit

One important detail: this is meant to run from the physical PicoCalc console, not over SSH. The app reads the real PicoCalc keyboard device and owns the framebuffer while it is running.

The code and docs are now in the repo:

Useful files:

examples/python/picocalc_sudoku.py
python/picogames/sudoku.py
python/picoterm/evdev.py
docs/picocalc-sudoku.md

This is a nice proof that the Luckfox can run real graphical PicoCalc apps without needing a full desktop environment.

1 Like
4

What’s your reason not just to use Calculinux?

5

We chose the Luckfox SDK / Buildroot path because it was the lowest-risk bring-up path for this specific hardware, not because CalcuLinux was a bad idea.

The local decision is recorded in [luckfox-roadmap.md (line 17)](C:/Users/georg/Codex_Projects/luckfox-lyra/luckfox-roadmap.md:17): preferred OS path was Buildroot, with “Buildroot first” because it is officially supported and better suited to the Lyra’s small-RAM embedded target. The active baseline became [benklop/picocalc-luckfox-lyra (line 3)](C:/Users/georg/Codex_Projects/luckfox-lyra/upstream/picocalc-luckfox-lyra/README.md:3), which already provided a Dockerized Luckfox SDK flow and PicoCalc-specific device tree, kernel config, SD-card Buildroot config, RTC, display/input, and Wi-Fi work.

Pros of Luckfox SDK / Buildroot

  • Closest to the vendor-supported RK3506/Lyra stack: kernel, U-Boot, Rockchip packaging, parameter files, and flash artifacts.
  • Already had a PicoCalc-specific defconfig: [nekocharm README (line 78)](C:/Users/georg/Codex_Projects/luckfox-lyra/upstream/nekocharm-picocalc-luckfox-lyra/README.md:78) shows picocalc_luckfox_lyra_buildroot_sdmmc_defconfig.
  • Smaller and more appropriate for 128 MB RAM than a general-purpose distro.
  • Easier to patch kernel/device-tree behavior directly; that mattered for keyboard MCU battery/backlight sysfs and Wi-Fi module work.
  • Reproducible from WSL2/Docker once we moved the SDK build to ext4.
  • It actually booted: the logs show the Lyra reached userspace from the SD rootfs/overlay layout and got to a PicoCalc login prompt in [2026-06-15-checklist-session.md (line 424)](C:/Users/georg/Codex_Projects/luckfox-lyra/logs/2026-06-15-checklist-session.md:424).

Cons of Luckfox SDK / Buildroot

  • More embedded-Linux work: package additions, init scripts, overlays, and driver integration are manual.
  • No comfortable desktop-distro package workflow by default; even pip, non-root user setup, sudo, fonts, Wi-Fi persistence, etc. had to be fixed or added.
  • Build system friction was real: SDK path had to be ext4, Docker memory/parallelism needed tuning, and some downloads/tools needed patching.
  • Less convenient for “install random software and experiment” compared with a package-managed distro.

Pros of CalcuLinux

  • Current CalcuLinux docs describe it as PicoCalc/Luckfox-focused, Yocto-based, with package management, LCD/keyboard/audio support, A/B update support, and active community work: Calculinux docs.
  • It is more “daily-driver distro” oriented than a raw SDK Buildroot image.
  • It may now be a better starting point if the priority is usable apps and package management rather than owning the full hardware bring-up stack.

Cons / risks of CalcuLinux for our decision point

  • It is independent from the Luckfox SDK: current docs say it uses upstream Yocto and only borrows kernel/U-Boot sources from the SDK, rather than staying inside the SDK Buildroot flow: Luckfox SDK vs Calculinux.
  • That independence is good long-term, but it increases risk when debugging board-specific boot, storage, kernel, and driver issues.
  • For our immediate goal, we needed a known build path we could patch, rebuild, flash, and verify against the exact Lyra/PicoCalc hardware.

So the short version: we chose Luckfox SDK Linux because we were doing hardware bring-up and driver integration first. CalcuLinux is more attractive as a user-facing distro, especially now, but the SDK/Buildroot route gave us control, reproducibility, and the cleanest path to debug the Lyra B inside the PicoCalc.

6

That text must have been written by an AI. It doesn’t make any sense to me. Calculinux is an open-source, functional Linux system for the Luckfox Lyra in the PicoCalc. All required drivers are included. As it’s open-source, you can carry on working on it rather than reinventing the wheel.

8

For my use case, I think I’m going to stay with the Luckfox/Buildroot approach.

CalcuLinux looks like solid work, but it feels more like a complete managed distro than what I personally want on the PicoCalc. I see the PicoCalc more as a small hacker machine than a polished appliance. The Buildroot image is lean, simple, and easier for me to poke at directly.

What I really want is a base system where I can add the few apps I care about, make the hardware work, and keep the rest out of the way. I don’t need a full “big city” OS on this little device.

It’s probably just my taste. I had the same kind of preference with the Pico 2 W and Pimoroni Pico Plus 2 W: I ended up doing better with CircuitPython than MicroPython, even though both are valid choices.

So I respect the CalcuLinux work, but I’m going to pass for now and keep going with the smaller Buildroot setup.

1 Like
9

Could it be that you haven’t even looked at Calculinux? Anyway, everyone does what they enjoy.

10

Sure I looked at it. Not what I want on my picocalc.

11

I think I may never go back to my Pimoroni Pico Plus 2 W board.

At the time, the Pico Plus 2 W with CircuitPython felt huge. It felt like I had all the room in the world. But now that I have the Luckfox Lyra running real Linux inside the PicoCalc, it feels like a whole new level of freedom.

Since my last post, I have:

  • The biggest Freedom has to be a bash shell and ssh always ready to go like an old freind.
  • Upgraded the kernel to the latest 202508 version. It built without much trouble.
  • Added crond and ntpd, so programs do not all need to handle their own time sync anymore.
  • Installed and got a chess program working. Thanks @hpsaturn
  • Converted a bunch of my CircuitPython apps:
    • Bubble Universe
    • Fancy Clock
    • Breakout
    • Sudoku
    • Weather
    • Calculator
    • Minesweeper with the large board
    • Zork
  • Modified and compiled a version of Doom. It uses the framebuffer and runs well.
  • Added the Alpine email client. It can send and receive email, and it can read full message bodies no matter how long they are.
  • Converted my graphical launcher.
  • Added a text launcher too.
  • Added a bunch of other things I am probably forgetting.

I updated the GitHub repo with the code if anyone wants to dig through it.

I missed some good “this is a real Linux now” wins:

  • Wi-Fi is working with the RTL8188FU dongle.
  • Added swap, so the tiny RAM is not as scary.
  • Fixed Python pieces like curses, OpenBLAS/NumPy, Rich, requests, and yfinance.
  • Built a PicoCalc framebuffer graphics library, picofb.
  • Added screenshot support for the PicoCalc screen.
  • Added TrueType font support and console font switching.
  • Added battery/backlight tools through picocalc-mcu.
  • Added an SD card utility.
  • Added a clean shutdown command.
  • Added CPU speed control with picocpu.
  • Added htop.
  • Added a boot splash screen.
  • Added a Thonny-like edit, sync, run dev loop.
  • Added app guards so two framebuffer apps do not fight over the screen.
  • Documented the build and upgrade path for the repo.

The Luckfox SDK version of Linux has turned out to be easy to use, easy to upgrade, and easy to hack on. That is the part that feels the most freeing.

The biggest thing may not be any one app. It is the toolchain around the PicoCalc now. I have framebuffer graphics, screenshots, fonts, battery and backlight control, Wi-Fi, swap, time sync, CPU controls, a boot splash, and a real edit-sync-run loop. It feels less like fighting a tiny board and more like building on a small Linux computer.

Adios, little Pico boards.

12

But isn’t that the fun of a PicoCalc? Otherwise buy a 2nd hand chromebook for a fraction of the price and run Linux 10x times faster.

13

Been there, done that with the tiny RP2350 boards. In my experience, the Pimoroni boards are among the best because they have enough of everything to be useful. Real onboard PSRAM on a proper bus makes a big difference.

I’ve written a lot of CircuitPython programs for these boards, and I tried to share some of that work here, but that became its own issue.

The biggest problem I kept running into is that the web keeps moving forward with HTTPS security. Pico-class boards struggle with modern certificates, redirects, and TLS memory requirements. Even when you think you are using plain HTTP, many sites now redirect to HTTPS, and that can consume more SRAM than the board realistically has available.

I got tired of fighting that battle. At one point I was using a Raspberry Pi 4 as an HTTPS proxy just so my Pico projects could work reliably.

So for me, the LuckFox Lyra in the PicoCalc is not about avoiding the fun. It is about having enough resources to build the projects I actually want to build. As you can see in other threads, I’m not the only one exploring Linux on the PicoCalc.

To each his own, of course. I’m just finding the LuckFox route more rewarding for my use case. I hope your projects go well too.

As a side note the Luckfox Lyra on PicoCalc thread has almost twice as many views as the picoware thread with a comperable number of posts.

14

Based on the discussions in the forum, it is clear that “tinkering with low-level hardware” has always been a niche “pleasure” because the barrier to entry is simply too high. Even the Raspberry Pi was originally conceived to hide these hardware complexities as much as possible, allowing users to focus on “realizing their ideas” rather than “overcoming hardware obstacles just to realize their ideas.”

Turning to the PicoCalc itself, the resources on the stock Pico H are extremely limited. You can clearly see that whenever people try to build something interesting, they eventually end up switching to the 2W due to various resource constraints—the biggest one being available RAM. Furthermore, the lack of networking capabilities today truly hampers creative potential (a huge part of why the ESP32 became such a massive hit is that Wi-Fi and Bluetooth are standard features).

Ironically, code written for the Pico 2 most likely won’t run on the original Pico. This is the inherent weakness of the “bare-metal” approach: you are forced to develop for specific “hardware platforms,” and if that platform isn’t a standard, your audience shrinks significantly.

Taking myself as an example, the Lyra board on the PicoCalc essentially provides a much richer “playground.” It’s practically a modern computer science textbook: you have the opportunity to understand the entire stack—from building an OS kernel starting at the bootloader, to user-space init, to the rootfs, and even package management gui…etc. All of this is integrated into a convenient, comprehensive toolchain. If you want to customize drivers, you still get to engage with those “bare-metal” level hardware communication details; yet, if you just want to quietly write some Python code, you can just as comfortably enjoy the benefit of “standing on the shoulders of giants.”

3 Likes