Active threads

Tried creating an overlay and changing it to; peripheral? /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h2-plus", "allwinner,sun8i-h3"; fragment@0 { target = <&usb_otg>; __overlay__ { dr_mode = "peripheral"; }; }; };

some progress $ sudo rfcomm bind /dev/rfcomm0 41:BB:00:D0:D3:D8 && ls -l /dev/rfcomm* crw-rw---- 1 root dialout 216, 0 Jul 7 22:46 /dev/rfcomm0 but $ sudo hcitool info 41:BB:00:D0:D3:D8 Requesting information ... Can't create connection: Input/output error

Hi @stanelie, I so very happy because you can restored your box, I was only able to read the messages now, I'm just a curious, but I'm available to help!

please be sure to share whatever learnings you have with us

I'd say, boot from a different medium and then try the dd commands again (use pv for a nice progress bar) to see if you have the same errors again.

Thank you for reporting back. I am happy to hear you were able to find another way to solve the underlying issue without needing the v4l2loopback-dkms package anymore. I see you already have backports enabled but probably with low priority (as you should) by default. You can check "man apt" for information how to install that specific version (or use aptitude like I do). That being said, "sudo apt install v4l2loopback-dkms/bookworm-backports" should probably get you the version you need and hopefully it would install fine.

sound is a gotcha on the opi z3, actually opi z3 has sound but output only. accordingly opi z2 has sound both input (mic) and output. and i think for 'convenience' many would after all use a usb sound card instead, just that there is only one usb port and the other 2 is actually on the extension pins on opi z3 as do with the audio output on z3 http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-Zero-3.html as for usb + audio extension, orangepi sells an extension board but that accordingly without that it may be possible to hack those usb connectors https://www.aliexpress.com/w/wholesale-usb-female-type-a-with-wire.htmll

Thank you for the report and this indeed does look like a general bug. It appears as if this comes from the file 10-armbian-header and in particular line 199 or possibly line 214, but I cannot look into it further right now. It's probably got something to do with network not being configured at the point at which you encountered this. I do certainly encourage you to open a ticket on github with the first entry on the pulldown "bug report for the armbian build framework".

I haven't tested this... but I see that pins PH1, PI11, PI14 are not connectable in the orange pi zero 3. Only PH3 would be connectable. Is this correct? Is there an overlay to get PWM in PH2? (i read in the post from April 5 that it can be a PWM pin)

The problem was resolved by upgrading. I had been running Armbian_25.5.1_Orangepi5_bookworm_vendor_6.1.115_minimal and everything was was fine except after a reboot, there would be an Oops error. I reimaged the machine with Armbian_25.5.1_Orangepi5_bookworm_current_6.12.28_minimal and the problem has been resoled.

Hello WDR_s, If you upgraded kernel recently, did you have any problem starting X11 (or lightdm, or desktop)? I started with a downloaded arm minimal image with linux 6.12, and my DTS would bring up the panel-mipi-dbi-spi driver correctly in text mode, but X11 can't start. When I have my normal 99-fbdev.conf, I get this: FBDEV(0): FBIOPUT_VSCREENINFO: Invalid argument, When I remove 99-fbdev.conf and let X11 setup everything automatically, X11 complains about needing panel-mipi-dbi_dri.so. I restored an old armbian OS backup with linux 6.11, and everything worked normally. You are using a different LCD driver, did you have any problem?

The last year has seen substantial progress on the DRM infrastructure required to write GPU drivers in Rust. Developed in collaboration with Arm and Google, Tyr is a new Rust-based DRM driver targeting CSF-based Arm Mali GPUs. View the full article

just like to say that the recent images works just well _ _ _ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ __ ___ _ __ _ __ _ _ _ _ (_) |_ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ / _/ _ \ ' \| ' \ || | ' \| | _| || | /_/ \_\_| |_|_|_|_.__/_\__,_|_||_|_\__\___/_|_|_|_|_|_\_,_|_||_|_|\__|\_, | |___| |__/ v25.8 rolling for Orange Pi Zero3 running Armbian Linux 6.12.35-current-sunxi64 Packages: Debian stable (bookworm) Support: for advanced users (rolling release) IPv4: (LAN) xxx.xxx.xxx.xxx (WAN) yyy.yyy.yyy.yyy IPv6: fd00:xxxx:xxxx::xxxx:xxxx (WAN) xxxx:xxxx::yyyy:yyyy WiFi AP: SSID: (ssid), Performance: Load: 2% Uptime: 3:50 Memory usage: 4% of 3.83G CPU temp: 41°C Usage of /: 3% of 58G RX today: 7 MiB Commands: Configuration : armbian-config Monitoring : htop

You are right, supporting a board family is a different thing 🙂 The board can have different hardware (nic, wlan, usb .... ) But sorry im was only care about the processor, and if i'm not wrong, the SOC is completely the same (cpu, gpu, apu). Maybe some minor differences (frequencies etc). And so im looked about the kernel / user modules regarding the cpu/gpu not for the complete image 🙂 But looks like the situation is the the same there, for different features( vpu / openGLES / vulkan) you need special kernel / image versions.

Sorry this Post. https://forum.armbian.com/topic/34923-csc-armbian-for-rk322x-tv-box-boards/page/94/#comment-212510

Sadly no. https://github.com/armbian/build/tree/main/config/boards There are (too) many boards in the system, added by random people (this is build system and we accept anything that builds, but we don't maintain those boards as we can't afford associated costs / there are not enough resources), but only supported / .conf are recognized until there is someone willing to maintaining them and fits condition of "supported" board. When we find out that conditions are not met anymore, they are "un-recognized". Support is defined under those rules: https://docs.armbian.com/User-Guide_Board-Support-Rules

root@rock3a:/lan/tmp# ffmpeg -i file1.AV1.mkv -c:v hevc_rkmpp -c:a copy file1.x265.mkv ffmpeg version 5.1.6-0+deb12u1 Copyright (c) 2000-2024 the FFmpeg developers ... Unknown encoder 'hevc_rkmpp' root@rock3a:/lan/tmp# /usr/share/jellyfin-ffmpeg/ffmpeg -i file1.AV1.mkv -c:v hevc_rkmpp -c:a copy file1.x265.mkv ffmpeg version 7.0.2-Jellyfin Copyright (c) 2000-2024 the FFmpeg developers ... [out#0/matroska @ 0xaaaaeff1e660] video:223157KiB audio:6460KiB subtitle:0KiB other streams:0KiB global headers:0KiB muxing overhead: 0.220596% frame=27421 fps=138 q=-0.0 Lsize= 230124KiB time=00:15:21.52 bitrate=2045.7kbits/s speed=4.64x video plays fine You might have power issues, that is my thirst thought, as I had several issues with my rock3a when I used USB-C (so with default PD with 5V). Now 12V in and user on-board DC-DC to do proper feeding. OPi5 does not have this AFAIK from schematics. But is is a wild guess. Many other things can be wrong, like who knows something with iommu (I guess not). I might try same command sometime later on my NanoPi-R6C when I will upgrade Armbian from Bookworm to Testing/Trixie, it also has RK3588S, same as OPi5, but check this, it is just top-of-my-head. I use mainline kernels mostly now, so need to tune grub or so first.

labwc is available in debian trixie: Start with a minimal armbian install Make sure your /dev/fb0 is DRM, not framebuffer $ sudo apt install seatd labwc foot $ labwc -s foot

Okay, so I ran a little experiment to verify that it's not about mocp but rather something about the file or file system: $ cp -a /mnt/music/_INCOMING/Malukah\ -\ The\ Dragonborn\ Comes\ \(2017\)/01\ -\ Awake.flac 01.flac Segmentation fault The resulting file contains 9175040 Bytes instead of the expected 9593429, so is truncated. Consequently I also see the corresponding dmesg output parrots what I showed before. So it's about exfat, it appears. Prior to the upgrade did I move the file over to an ext4 partition as well (as I guessed it would be impossible with the 6.12.30-current-sunxi kernel). Copying that around, including _to_ the USB key doesn't seem to cause any issues. I'll see if I am able to figure out how to get the clusters of that particular file. Perhaps it becomes reproducible elsewhere with a (trimmed down) disk image? 2025-07-06_dmesg.txt

This would be very very hard. Would likely take years and would likely never achieve full functionality. If you have access to the source code for the firmware that comes on the device you would have a chance.

Right, judging by only one instance in the topwise a721 dts: [ 3.446799] sun4i-drm display-engine: No panel or bridge found... RGB output disabled I am inclined to think that is configuring the panel. This can be validated by checking ls /sys/devices/platform/display-engine/drm/card0 or looking for simple-panel in lsmod. I suspect it may be a pin-muxing issue where the pins are not being set. now what these are set depends on the lcd panel type which could be LVDS or a parallel panel. I believe it should be LVDS but just wanted to confirm. Now the A10's pin controller section within the dtsi does not map out as many function compared A20 dtsi, so within the topwise a721 dts under the pio node the display pins need to be declared and their function stated. Secondly attach the pin control handle to tcon0. For example: &pio { lvds0_pins: lvds0-pins@0 { pins = "PD0", "PD1", "PD2", "PD3", "PD4", "PD5", "PD6", "PD7", "PD8", "PD9"; function = "lvds0" }; }; &tcon0 { pinctrl-names = "default"; pinctrl-0 = <&lvds0_pins>; };

I can do that but it does not provide any useful information on the subject in my opinion. Is there a way to downgrade to 25.8.0-trunk.313? According to this post, it might be useful to set the kernel option nvme_core.default_ps_max_latency_us resp. the DT overlay parameter pciex1_gen=3. How can the kernel (cmdline) option be set in Armbian? Regarding the DT overlay parameter pciex1_gen, should I follow this part of the documentation?

The issue appears to be two things. These two patches and the current defconfig(s) being used. drv-rtc-sun6i-support-RTCs-without-external-LOSCs.patch drv-rtc-sun6i-Add-Allwinner-H616-support.patch When I disable those patches and use my own defconfig everything works as it should. https://paste.armbian.com/tixixocubu The hard part here would be figuring out exactly what in the defconfig(s) are either breaking things or missing. Also if I disable those patches, what does it break on other units? I'm under the impression these patches were rejects from the original h616 bring up in mainline. But I could be wrong?

If you need hdmi support use vendor or edge kernel. 6.12 was released with a bare minimum of support for rk3588 so nonworking hdmi is kind a expected.

I added a patch that activates the gpu. https://lore.kernel.org/linux-sunxi/20250706025625.2707073-1-iuncuim@gmail.com A ready to install kernel is available for manjaro. But it's worth realizing that without output it will be useless at the moment.