Active threads

Hi, I haven't posted for a while since I don't have an OrangePi 4A, just a Cubie A5E. I compiled Armbian for OrangePi 4a, kernel 6.16-rc4. No video yet, just a serial console. Can anyone test the image? https://github.com/juanesf/build/commits/Opi4A/ https://paste.armbian.com/ranagabiku https://drive.google.com/drive/folders/1dx0TApPAEjFDz24Rm22J4jgtIbJrYYHC?usp=sharing

What kernel version are you using now, and what was the linux version that failed before? If you can't remember: cat /var/log/apt/term.log |grep linux-image

@Nick A good news, everything seems to work except emmc. For now I'll just use the SD card. Thanks again for the help Update: I messed around with the device trees and found out that eMMC works if the frequency is lowered to 12Mhz as done in this patch: https://github.com/sicXnull/armbian-build/blob/333e462466670e9a8609771ccd05977b87800881/patch/u-boot/u-boot-sunxi/board_x96q-v5-1/sunxi_mmc-dec-f_max-to-12MHz-to-get-emmc-reliable.patch Maybe the next x96q-v5.1 builds can just use the x98h base with this patch applied

Hi Guillame, I forget how many hours/days I worked on this to get this box to work and at times I felt like chuckin it in the wastebin! It's not in a github, sadly, but all the info is here in this thread - I tried to document my madness as I went along and as you say I am very indebted to Nick and others for getting me started and the help he provided along the way. In the end I just moved to a Raspberry Pi as it was so much easier lol But I think I have a working SD Card somewhere. I got everything working, including the remote, with the exception of the onboard wifi chip had no drivers for Armbian, that may well have changed by now, I don't know, but I just used a wifi dongle with wifi and bluetooth - It's here in the thread. I can image the sd card if you have somewhere to upload it to - maybe start your own github and let me uploaded the img there to get you started? Regards, Mark

Once PR is merged, automated nightly beta repository has this kernel within hours.

Thanks! 🙏

please share more information about the problem you ran into for the sake of the next guy coming to the forum to look for a solution to the same problem. Thank you.

I am checking now Before installing plymouth, I checked that panel-mipi-dbi-spi is still loaded late: I added the include-lcd-bin.sh and installed plymouth: Checking that my bin file is there: The LCD works with plymouth: it starts the LCD earlier, with a smaller font, then switches to normal font, showing all the boot messages My armbian is not setup yet with lightdm+openbox (x11) or greetd+gtkgreet+labwc (wayland)... I will continue tomorrow

I am using my orange pi zero 3 with an SPI 4.0" LCD, with driver panel-mipi-dbi-spi. It works great with Linux 6.13.7 (started with a self built image with edge, minimal, Bookworm) and older, but I am having troubles with 6.14.8. Result from armbianmonitor -u after upgrading to linux 6.14.8: sudo apt install linux-image-edge-sunxi64=25.5.1 I reboot and the SPI LCD starts the text mode console, then turns black instead of starting lightdm https://paste.armbian.com/ucoxuwetiq Also xorg log after "sudo startx" fails to start. When I start the opiz3 with an HDMI screen connected (appears as /dev/fb0), startx and lightdm start normally, but NOT displaying anything in the small LCD Then, I downgrade to linux 6.13.7, sudo apt install linux-image-edge-sunxi64=25.2.3 I reboot and lightdm starts normally in the 4.0 LCD https://paste.armbian.com/uqafuxexiv Stopping lightdm and trying x11 to see the log sudo startx ... starts xorg normally Just downgrading to Linux 6.13.7 allows the 4.0" SPI LCD to work again. Dowgrading the linux package did not cause a downgrade of X11 (version 1.21.1.7). The small LCD always works ok in text mode. The driver is DRM but it is using the X11 fbdev submodule The fbdev.conf file: Using an HDMI screen is not affected When I disable the fbdev conf file sudo mv 99-fbdev.conf 99-fbdev.conf.disabled Then x11 fails in another way: The xorg log doesn't show any error: dmesg|grep MESA shows nothing. Probably here is the solution https://github.com/agherzan/meta-raspberrypi/issues/1389 rebuilding mesa with some extra dependencies Bookworm containg mesa 22.3.6 right now, but Trixie contains mesa 25.0.5 I tried the same in Trixie and Sid, but still get the same error: not able to load panel-mipi-dbi_dri.so I don't know what else to look for.

@Turbine Thank you, I had this problem and your solution was spot on. Problem fixed.

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!

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 if one is willing to go the distance with electronics, for the microphone i did a little research and found that there are mems microphone modules around small, compact and possibly can be easily paired with boards like z , z2 or z3 https://www.aliexpress.com/w/wholesale-mems-microphone.html but that most of these are I2S interfaces and I'm not too sure if it is feasible apparently it is there for output, but I'm not sure about input https://github.com/elkoni/Opi_Zero_3_I2S3_5.4

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.

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.