disable ligthdm with "sudo systemctl disable lightdm" and reboot.

 

Log in with text mode. Run "sudo startx". If you see a gray screen with cursor, then X11 is working fine.

 

If not, then you will see a lot of debugging messages. Write down those that start with (EEE). Quit X11 by right-click and "Exit"

 

If you want to abandon X11, try compiling pi-greeter: a "greeter" for lightdm which avoids X11

 

https://github.com/robertojguerra/opiz3-labwc-setup/blob/main/4-pi-greeter.md

 

Related post: https://forum.armbian.com/topic/55882-critique-or-improve-my-method-to-get-a-lightweight-labwc-desktop/#comment-227469

 

Re-enable lightdm with "sudo systemctl disable lightdm"

Thank you for sharing your results  

 

Which other armbian boards would be compatible with the LeMaker LCD?

On 9/19/2026 at 6:05 PM, ValdikSS said:

Hello, have you found what is ED1 part? I have a fried board as well, and ED1 seems to be a culprit.

 

UPD: According to Orange Pi Zero2 schematics, it's JEB05DFC esd0402-6.

I just removed it and the board is working again.

 

I also have an orange pi zero 3 which was fried due to 12V applied to the GPIO +5V pin (forgot to turn a potentiometer to lower the voltage).

 

What is the ED1? Is it a fuse or similar? Is there an equivalent for the GPIO 5V?

On 8/26/2026 at 6:42 AM, Jacob George said:

@robertoj

I thought that is what github provides, a complete track record of commits, pushes and changes? It's all there, I also have had contributor's. It's being sanity checked. The Orange Pi 4 Pro is nearly identical to Radxa Cubie A7A, I will be making a branch for the A7A shortly.

Thank you Jacob

I hope to get a orange pi zero 3w in the near future, for NPU tasks (face and pose detection)

On 7/18/2026 at 9:21 PM, parker-int64 said:

I recently bought a SPI screen and managed to drive it with panel-mipi-dbi in the newer kernel (apparently this module didn't exist in Radxa's official image with kernel 5.15).

 

I am glad that someone else is also using that LCD driver. In the Raspberry community, it is also the favorite driver for LCDs, since it is universal and works well with Wayland.

 

 

There are several threads here, in the Raspberry forum and the notro repository: https://github.com/notro/panel-mipi-dbi/discussions

 

The signal inversion seems to be a deliberate change from linux 5.x to linux 6.x.

 

This panel-mipi-dbi can also be used with bigger SPI LCDs, but you need to upgrade to 6.x (cant remember which) to use the big and cheap ILI9486, ILI9488, and even accelerated video is possible.

 

 

 

I have seen the Orange Pi 4 Pro being mentioned. Is it similar enough to the Radxa A7* to use the same DTS? Is the Oranpe Pi Zero 3w also similar enough? (it has the same form factor as the Radxa A7z and same A733).

 

Jacob, you should understand everything that Claude produces for you. Keep track of what it's changing in the EDK code.

Make a diff patch from the unchanged code, and the code you are compiling. All the differences need to be sanity-checked by regular users, and rationalized by experts.

And share a link to the starting original EDK.

I think it has some similarity with Radxa Cubie

 

 

Which Linux version are you using? Did you use the CMA=256M kernel argument? There's a lot of information here.

 

 

8 hours ago, MMGen said:

Looks like Friendlyelec deleted some functions in their version of the library, or based it on an outdated version.

 

More likely: friendlyelec is maintaining a separate patch (source code additions to the official ffmpeg), that allows it to do it. The code should be available in the friendlyelec github, to be shared with the public.

 

"No v4l2request"... that means that they implemented another protocol and/or another kernel module to work with the video decoder.

Thank you for the information mmgen,

 

One thing you missed is the ffmpeg compilation information. Run:

 

$ ffmpeg

 

It will print out the ffmpeg version and all the libraries that were enabled, and all the libav* libraries it has compiled along with ffmpeg (libav* are parts of the ffmpeg project).

 

The interesting information is whether it uses the "v4l2-request" library, which lets ffmpeg control a part of the kernel that controls the hardware decoder.

 

When you run mpv -v yourvideo.mp4 you could also see v4l2request, or some other message about the hardware acceleration (at this point I doubt that v4l2request is used, because it works better in newer kernels)

8 hours ago, MMGen said:

With the official friendlyelec image for Nano Pi M6 (trixie, gnome, 6.1 kernel), I'm getting hardware acceleration with the plain vanilla mpv from Debian:

 

mpv --vo=gpu my.mp4
mpp[2968]: mpp_platform: client 18 driver is not ready!
● Video  --vid=1  (h264 1080x1920 59.9998 fps) [default]
● Audio  --aid=1  (aac 2ch 44100 Hz 128 kbps) [default]
arm_release_ver: g24p0-00eac0, rk_so_ver: 10-616430-r0
mpp[2968]: mpp_info: mpp version: 958803d7 author: Herman Chen   2026-02-26 fix[h265d_rkv]: Fix rkv ref and poc setup overflow
Using hardware decoding (rkmpp).
AO: [pipewire] 44100Hz stereo 2ch floatp
VO: [gpu] 1080x1920 drm_prime[nv12]
 

Everything works wonderfully, and CPU usage is about 25%, compared to 500% for Armbian. Why can't rkmpp be enabled on Armbian to give us harware accel out of the box?
 

@Igor: The overlay link you provided above (mesa-vpu) is broken. And no such overlay exists in the prebuilt images for the Nano Pi M6. Result: still no hardware acceleration for my M6 with Armbian.

 

If you are using the friendlyelec image, can you really say "mpv is vanilla from Debian"?

 

I am really asking, because I haven't used friendlyelec in a long time, and I don't remember if they have their own DEB repository.

 

Can you identify the ffmpeg version and compilation options? Same with mpv.

 

Run $ ffmpeg with no options, and it will print out the version and the libraries that were activated.

 

$ apt list ffmpeg

$ apt list mpv

$ mpv --version

$ cat /etc/issue

$ uname -a

 

I do remember that friendlyelec has some extra video abilities, because they maintain their own patches with bleeding edge code, while the official ffmpeg and mpv maintainers are still checking whether to accept the pull requests.

 

Is it even possible to run "armbianmonitor -u" in friendlyelec?

 

Do you see "v4l2-request" or "va-api" (or "vaapi") anywhere in the mpv log? is your gnome desktop running under X11 or Wayland? (last time I used friendlyelec with Kodi, the graphic server was gbm, and there was no desktop, only Kodi).

 

If you run $ mpv --vo=gpu -v my.mp4 , mpv will print a more verbose log, with more details of how its running.

On 3/10/2026 at 3:03 AM, flappyjet said:

I agree with you. Neural network works well on NPU. I tried to load tiny llm model, but it's still too large for NPU. The bottleneck is the sram in NPU, not computing capacity. And I found an interesting project https://github.com/NotPunchnox/rkllama

 

Can you give more details about the limitations of this NPU? I thought that they would be using shared system RAM. because all models are multiple megabytes,

 

Can you comment about the ability to convert any model to your desired NPU target with "AI model conversion"

https://tinycomputers.io/posts/rockchip-rk3588-npu-benchmarks.html (search for "Conversion Performance (x86_64)")

 

Maybe its possible to run LCM-Lora in an armbian device, if it has 16GB. It is already running in a 16GB laptop without NPU or GPU.

https://forums.raspberrypi.com/viewtopic.php?t=398225&sid=2b66e2cebe37506dd74215ead3dd264c

 

I am thinking about buying an Orange PI zero 3W (allwinner NPU), but if you have troubles with a 6 TOPs NPU, I will have more troubles with a 2 TOPs NPU

Refer to the experiences here:

 

I think someone wrote that the mainline kernel has NPU support.

Is this NPU going to load only models that are in the Rockchip model repository?

Great job  I don't have time to replicate this, but I would like to see more photos, screenshots, and what you can do with so many SDRs

 

It's perfect to use an older kernel, if you don't need anything from a newer Linux (for example more stable Wifi, and resistive LCDs with Wayland)...

In your writeup, you could have included the dmesg or journalctl messages, just prior to the crash.

Sometimes, there's a confict between a new or changed kernel module and the module you want to use, and it causes crashes, or not being able to start Linux. Then you deactivate the module that gives you the problem.

 

Which services were disabled with sudo systemctl mask systemd-networkd-wait-online ? It sounds like you never want to start a network service automatically on boot.

 

I hope that the SoapySDR developers can fix the root issue, so that you don't need to lock a library .SO like that

 

I made a thread showing how to control GPIO with Python gpiod

https://forum.armbian.com/topic/33800-orange-pi-zero-3-gpio/#findComment-181191

Instead of using Opi.GPIO, which relies of sysfs (deprecated, and you can't use it in newer Linux)

 

I had no idea that there's an OpiZ3W

 

Just in case, it is nothing at all like the Orange Pi Zero 3, which has a lot in common with the OpiZ2W.

 

Yeely: what are your first impressions about this board? Are there demos for the NPU? Are the video encoders and decoders working with the Orange Pi Linux OS?

 

Bring up verifiable (open source) examples of AI generated code, making an improved program.

The orange pi zero 2w is configured to only start u-boot from the microSD in the built-in microSD. You would have to:

 

* recompile that uboot to load the initramfs and the kernel from your alternative storage (did you really mean HDD? which connector would you use?)

or

* load initramfs and kernel from the typical microsd /boot partition, but configure the kernel argument line to accept the HDD as the rootfs (make sure that the initramfs contains the kernel modules, and the hdd name is in the /etc/fstab file)

or

https://jamesachambers.com/orange-pi-zero-2-usb-ssd-boot-guide/

 

Does sway eat a lot of RAM? Can it be used fine in a 640x480 display?

 

I've been staying with my labwc setup, because it's known to be minimalistic. Orange Pi Zero3 and Raspberries with 1GB RAM can run it fluidly.

Which kernel, debian, mesa and sway versions are running normally when you run a stock Armbian?

 

Which new versions have you observed working together? (even if it's not ARM).

 

If they are too different, they may not work together due to library functions expecting other parameters.

 

You can try it with Ubuntu Noble, which has newer packages than Debian Trixie (build Armbian by yourself).

I am glad that it's possible to use a different ffmpeg version than what the distribution expects.  (it gives me hope of installing it in Trixie, instead of changing over to the newest Ubuntu)

 

Did you install the locally compiled ffmpeg at OS level, or did you keep it in a folder within your /home/username/...?

On 11/11/2025 at 2:36 AM, usual user said:

FWIW, HEVC support is queued for 6.19.

With WIP patches on top, rkvdec2 is also available to me. With the gstreamer framework, this works for me out-of-the-box, as the necessary support has been available in mainline for quite some time. See video-pipeline.pdffor reference.

I have already rebuilt the Huffman package with the patches mentioned above, but currently the developers of the distribution of my choice are busy rebuilding all packages that depend on it. As soon as the Huffman package is rolled out, I will start to see how HEVC performs with the FFMPEG framework.

 

Usual User, the information you linked about Linux 6.19 seems like there's progress for Rockchip.

 

However, is there any indication that Allwinner H618 could get H265/HEVC decoding acceleration working too?

Thank you for being specific about the RKxxx+6.19+Noble information

 

As I asked in the other thread, please also specify which ffpmeg and mpv sources you used.

 

I hope I can make it work in opiz3 (H618) in a more recent Debian (I only could make it work in Bookworm). Do you see any difference in 8bit vs 10bit HEVC(H265)?

For context, he is talking about:

https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/20847 

 

There are many ffpmpeg options. Which ffmpeg did you use?

https://code.ffmpeg.org/Kwiboo/FFmpeg/src/branch/v4l2request-v3

https://code.ffmpeg.org/Kwiboo/FFmpeg/src/branch/v4l2-request-n8.1

 

And which debian/ubuntu version did you use? Which ffmpeg is included in that distribution? 

Maybe this comment and thread have a hint for you

https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/#findComment-229274

 

I don't own a waveshare LCD... but I would also like to know if its possible to make it work with Armbian

Can you repeat your amrbian OS version, Linux, and hardware?

 

I can't give a confident advice for you, but have you tried:

* extraargs=cma=256M in armbianEnv.txt

* turn off compositor, if using xfce (others have suggested it, and I found it unnecessary)

 

In mpv, turn on verbosity by adding -v to the command. Then while it is running, close it and copy all the mpv text in a text editor.

Search for the words h264, ffmpeg, v4l2, hardware, software

Make sure you have ili9486.ko in your ko module folder: modinfo ili9486

 

Can you use the DTS that I published in:

https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/#findComment-208446

But change the "compatible" line with waveshare,rpi-lcd-35 ,

Delete the stuff under the "compatible" line, until the "}vsync-len = <0>;", and replace it with what you had in your DTS. Change these lines, if they are different:

                spi-max-frequency = <24000000>;
                rotate = <270>;
                bgr;
                fps = <30>;
                buswidth = <8>;
                regwidth = <16>;

 

Reference:

https://github.com/raspberrypi/linux/blob/rpi-6.12.y/arch/arm/boot/dts/overlays/piscreen-overlay.dts

Linux is not a real time operating system

 

Realtime OSes have a 1 ms accuracy

 

You need an arduino dedicated only to make your square wave