Luckfox Lyra Zero W/ Arduino Uno Q

[F4tGuyJohn]

Hi DietPi Team,
I am a hardware enthusiast and an aspiring software developer. Recently, I’ve been working with the Luckfox Lyra W board and stumbled upon a missing configuration regarding display support.I tried connecting a budget, generic display to the board, but it failed to initialize. After debugging, I discovered that while the core image itself is good, it is missing the specific initialization code block and CPU timings required for the Lyra W variant.

The Issue:
The image includes a general code snippet that talks about display initialization, but it completely lacks the specific parameters and CPU timings needed for this exact board.It seems the current parameters might be inherited from or meant for the larger Luckfox Lyra board, which has different bus/pin mappings and timing requirements.

A huge appreciation for your work:
The reason I am bringing this up is because I absolutely love what you do. I’ve seen how DietPi behaves on the Raspberry Pi Zero 2 W, and it is honestly mind-blowing. It feels absolutely brilliant how a small, dedicated handful of people managed to optimize an operating system so perfectly for such lightweight hardware.Because DietPi is so incredibly well-optimized, I would love to see the Luckfox Lyra W reach that same level of perfection once this missing display configuration block is sorted out.

A side note on Arduino:
On a personal note, I recently purchased an Arduino UNO Q board. To be honest, until recently, I wasn't really a fan of the Arduino ecosystem or its overall philosophy. However, since getting my hands on this hardware, I've completely changed my mind. I discovered its massive potential and just how professionally built it actually is. Since DietPi is the king of lightweight setups, I think it would be amazing if the DietPi ecosystem could include some form of official integration or tooling for Arduino in the future (perhaps inside dietpi-software for managing or flashing microcontrollers).

Supporting the project:
I really wish I could put my money where my mouth is, but right now I'm a bit tight on cash and can't back you guys financially with a donation. As soon as I get the resources, I definitely want to drop some money your way. This doesn't just help the dev team, it lifts up the whole community, and we are all completely aware of that.

In conclusion:
To wrap it up, I don't think I've seen anyone else in the industry pull off what you guys did: taking a processor designed for 64-bit architecture and making it perform so flawlessly and efficiently that it feels completely native to 32-bit.Thank you so much for your incredible dedication and for making such an amazing OS!

[MichaIng]

The Luckfox Lyra Zero W uses the Rockchip RK3506 chip, which is not yet supported by mainline Linux: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/

But generally, it would be possible to create DietPi images for it. As a start, it could be tried to run dietpi-installer on their Ubuntu 22.04 image: https://wiki.luckfox.com/Luckfox-Lyra/Image-flashing

Better: Use the Armbian image as basis. That way, it can be also integrated natively into our build system: https://github.com/armbian/build/blob/main/config/boards/luckfox-lyra-zero-w.csc

Same with Arduino Uno Q: https://github.com/armbian/build/blob/main/config/boards/arduino-uno-q.csc
That one also has mainline Linux support: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/qcom/qrb2210-arduino-imola.dts

[F4tGuyJohn]

To be completely honest, I do not have an advanced background in software engineering. However, I want to explain why I started this project and where I am currently stuck.

The idea started with a simple need. I required a hardware board to handle various inputs from different peripherals (which I do not currently have on hand). My goal is to run a simple 2D Kalman filter directly on the Cortex-M0 core to make specific corrections for a guidance system, aimed at drone applications.

After exploring the market, the Luckfox Lyra Zero W stood out as the absolute best fit for my goals. It perfectly balances a 32-bit architecture with rich peripheral connectivity, onboard Wi-Fi, a DSI port, USB-C, integrated RAM, and MicroSD support—all while maintaining an incredibly optimized and minimal resource footprint, which is exactly what my project demands.

After flashing the image via rkdevtools, I realized how easy it is to work with this board. However, the real "wow" factor came when I discovered your DietPi distribution—it feels absolutely perfect for this setup.

Going back and forth over the past few weeks, I started diving much deeper into the environment. I even discovered tools like fzf (command-line fuzzy finder), which helped me dig further into debugging and system exploration.

To give you a bit more context on my workflow, I spend about 90% of my time leveraging AI tools. Sorting through these AI outputs consumes most of my energy. More often than not, the AI leads me down completely wrong paths, and I end up having to figure out the right approach on my own. For example, I've been spending several days trying to fix a display issue because the AI keeps chasing completely unrelated debugging paths and giving solutions that have nothing to do with the actual problem.

I am doing this purely out of passion to learn low-level hardware and software development on a unique board that isn't very mainstream yet, so I have no strict time constraints. However, my current roadblock is dealing with the manufacturer’s marketing approach and their messy SDK. Managing the specific app libraries within the Luckfox SDK consumes a massive amount of time. They heavily push environments like QT for application development—which could be highly beneficial for my project—but it is incredibly difficult to actually implement on top of their proprietary SDK structure.

If this sounds interesting to you and you think it is worth the effort to support or expand DietPi for this board, I would be more than happy to order a Luckfox Lyra Zero W from AliExpress and have it shipped directly to you (it should take about 3 weeks to arrive).

Best regards,

Andrew

[F4tGuyJohn]

Just coming back with a quick clarification regarding my previous messages to make sure we are fully aligned on the intended system architecture before looking at any files or deciding if it is worth implementing.

I’m looking into using the Luckfox Lyra Zero W (RK3506B) for an asymmetric multiprocessing (AMP) architecture. The idea is to run a lightweight DietPi image on the 3 × Cortex-A7 cores, while isolating the Cortex-M0 core strictly to act as a real-time 2D Kalman Filter verification engine.

Before diving into any code, I am analyzing how the hardware resources can actually be split within the OS environment, because right now there are major low-level architectural gaps on the vendor software side that make this setup a no-go.

This is a standard industrial/automotive model (similar to how NXP i.MX8 or STM32MP1 handle safe data validation), and the hardware design needs to work exactly like this:

1. CORE ALLOCATION & WORKLOAD BOUNDARIES

• Cortex-A7 (Triple-Core): Runs the Linux SMP kernel (DietPi). It manages the sensor input buses, pre-processes the raw data, sends it to the M0 for filtering, and handles the final external communication.
• Cortex-M0 (Single-Core): Must run bare-metal at 200MHz under strict non-preemptive execution. Its sole job is to receive data from A7, compute the 2D Kalman Filter matrix instantly with zero jitter, and pass the verified state back.

2. HARDWARE BUSES & PERIPHERAL ISOLATION

• All sensor inputs (SPI/I2C) are owned and managed directly by the A7 cores (Linux/DietPi).
• The Cortex-M0 does not need direct access to physical I/O pins, which completely eliminates hardware bus arbitration conflicts in the Device Tree.

3. MEMORY MANAGEMENT, IPC (RPMSG) & CACHE COHERENCY

• The Cortex-M0 firmware must load into the integrated SRAM acting as Tightly Coupled Memory (TCM, around the 0xFFF84000 range).
• For the high-speed bi-directional data exchange between A7 and M0, a "reserved-memory" carve-out (2MB–4MB) inside the DDR3L pool is required. This block must be marked as "no-map" and un-cached in the Linux device tree so the A7 cores don't allocate pages there.
• CRITICAL HARDWARE REQUIREMENT: Because the A7 has an MMU/Cache and the M0 does not, the shared memory driver must handle strict Cache Coherency (explicit L1/L2 Cache Flush before M0 reads, and Cache Invalidate before A7 reads) to prevent data corruption during the high-speed Kalman matrix exchange.

4. THE DATA PIPELINE

• Step 1: A7 (DietPi) pulls raw data from SPI/I2C sensors.
• Step 2: A7 pre-processes the data and writes it to Shared Memory (RPMSG).
• Step 3: A7 triggers a Mailbox Interrupt to alert the M0 core.
• Step 4: M0 wakes up instantly and computes the 2D Kalman Filter.
• Step 5: M0 writes the filtered/verified state back to Shared Memory.
• Step 6: DietPi receives the verified data and pipes it out via Wired I/O.

---

THE SYSTEM INFRASTRUCTURE ROADBLOCKS:

Right now, the current Rockchip BSP ecosystem for the RK3506B lacks the necessary low-level plumbing to make this workable:

1. BROKEN/MISSING REMOTEPROC: There is no functional Linux RemoteProc (rockchip_rproc) driver implemented by the vendor for the RK3506B that can map the SRAM region and handle the life-cycle (start/stop/load) of the M0 core without freezing the system.
2. NO DEVICE TREE OVERLAY SUPPORT FOR MEMORY CARVE-OUT: There are no reference overlays or documentation from Luckfox/Rockchip on how to safely set up the "reserved-memory" block with "no-map" attributes and un-cached operations for the RPMSG subsystem on this specific kernel.
3. LACK OF M0 TOOLCHAIN COMPATIBILITY: The vendor SDK provides no baseline workflow, memory maps, or linker scripts to compile a bare-metal M0 binary with a proper resource table that the Linux kernel can actually recognize and inject into the SRAM at boot.

If the vendor's underlying driver stack and kernel support aren't actually present in the base Rockchip source, then using this board for an AMP architecture is a dead end.

In any case, I'm glad this info reached you, and I really appreciate the fact that you are aware of the hardware potential here... if any. On paper, it seems like a great project. Write back whenever you have the time.

Thank you,

Andrew

[MichaIng]

My first goal would be a well booting image. I2C and SPI support should generally work, or can be toggled with overlays. We can add them from the vendor sources, if missing, or create them ourselves (if it is only a status = "okay" switch in the device tree).

If a proper driver for the Cortex-M0 is not even part of the Rockchip BSP kernel, respectively Luckfox's fork of it, then we cannot do much about it either. Actually, a quick search gives a repo with this driver and firmware: https://github.com/nvitya/rk3506-mcu
I wonder what the status of this is in Rockchip BSP, or at least whether Luckfox has some plan of adding this to their builds, just so that there is any semi-official and more widely used/tested source, rather than a random repo.

A reserved-memory block can be defined in the device tree, which follows pretty stable standards. But possible that the M0 requires a node as well which needs to reference the reserved memory block to be used. Or it is done entirely by the driver, and just needs to be at a specific path or have a specific alias.

As said, we can patch the kernel with whichever driver and device tree overlay or change needed. But we need sources.

For the software/toolchain/SDK side: We won't add 3rd party software to our images. But we can add links to our documentation or so, if somewhat official sources are found which work with the kernel driver.

[F4tGuyJohn]

Thank you so much, I really appreciate your willingness to help with this!

To be honest, I don't have the technical solutions or the source files ready right now. I need a few weeks to dig deeper, send out some emails to see what I can find, and see if I can actually get a hold of those vendor sources.

If I manage to find anything useful or get some working files, I will definitely let you know right away so we can take it from there.

In the meantime, I have an Arduino setup that does pretty much the same thing for my project, so I will be using that as a backup plan while I investigate this.

Thanks again for your support, and I'll keep you updated!

[F4tGuyJohn]

Just an update regarding our discussion. Half of the infrastructure problem is solved: another developer (nvitya) created a working 'remoteproc' driver that successfully loads and boots the Cortex-M0 from Linux (https://github.com).

However, we are still blocked by the hardware firewalls we discussed (SRAM lockup after boot, disabled SWD pins, and shared RAM mapping). To bypass this, I have escalated the issue to Luckfox and Rockchip for the missing register overrides.

Here are the emails I sent them for your reference:

1. EMAIL TO LUCKFOX SUPPORT
   Subject: Technical Support Request: AMP Architecture Implementation on Luckfox Lyra Zero W (RK3506B)

Dear Luckfox Support and R&D Team,
I am currently developing an AMP system on the Luckfox Lyra Zero W (Discussion #8187). We are using nvitya's remoteproc driver framework but are blocked by the following:

1. SRAM Lockup: Once the M0 starts, the SRAM region becomes inaccessible to Linux, breaking firmware hot-swapping.

2. SWD Lockout: SWCLK and SWDIO are blocked or multiplexed at early boot.

3. RAM Allocation: We need the proper shared-dma-pool (reserved-memory) DTS structure for RPMsg.
   Please provide the register overrides or TF-A patch details to bypass these firewall limitations.

4. EMAIL TO ROCKCHIP FAE
   Subject: RK3506 Technical Query: MCU (Cortex-M0) Subsystem Isolation and SWD/SRAM Restrictions

Dear Rockchip Engineering Team,
We are implementing an AMP architecture on the RK3506 processor. We request technical clarification on the public TRM limits:

1. Hardware Firewall: Which GRF registers or TF-A modifications prevent SRAM lockup when using remoteproc?
2. SWD Access: Which internal register offsets route and force-enable MCU_SWCLK / MCU_SWDIO to physical GPIOs?
3. Shared Memory: Do you have a reference Resource Table configuration for VirtIO/RPMsg on RK3506?

I will get back to you with an update as soon as I receive a reply from them.

Thanks again,
Andrew