All Activity

Thanks, I am aware of that. But that's an Ubuntu that's using the barebones vendor kernel. I need a fuller kernel than that, and Debian. As it turns out, in looking at recent updates here, it looks like the audio issue has been addressed within the past few days, and that it's an easy fix (as I thought it would be): https://patchwork.kernel.org/project/linux-rockchip/list/ I have yet to try that out, but it looks like I can either wait for the update in the bleeding edge kernel (if it's not already present) or modify the devicetree myself with the fix they discovered.

That seems to have gone away. ? SNILMERG... Now using very small but 1920x1080 screen, xfce terminal text is about 7 microns tall, way too small for my ancient eyes, Simplified keyboard. ctrl&shift&+ magnify's text but when big enough to read, bottom of xfce4 terminal is offscreen below bottom of screen, so cannot see command line. Is there a keycode combo that expands text independently from terminal window size? Thank you.

The most interesting thing is that everything works fine for joshua-riek Ubuntu 24.04 with the 6.1 kernel https://joshua-riek.github.io/ubuntu-rockchip-download/boards/orangepi-5-plus.html

Armbian kernel and BSP Debian/Ubuntu userland

With the armbian build system, you can build either Bookworm or Trixie You will always get the latest Bookworm or the latest Trixie packages in a freshly built armbian OS. This is what's meant by "always rolling release"... not to be understood as "always sid or Trixie". Independently, the armbian build system will let you choose a stable Linux version, or the latest available from Armbian (edge).

You are still using an old Linux. You need Linux 6.13 or newer. You need to build your own Armbian OS. Also, don't forget the cma=256M kernel argument

Ho ! That's a new thing isn't it ? And IMHO, a strange choice. Is there a way to disable that rolling release during the image building process?

Stable images can only be built by Armbian. All user built images are essentially rolling releases. But once booted into an image, you can use armbian-config to switch to the stable apt repositories, which means you won't get bug fixes or security updates to the kernel, but instead you get a stable kernel build released once every three months.

Hi there! Made some further research. It seems I was wrong assuming hw GPU/VPU is used. The reduced CPU load is more likely a result of the lower fps when using -hwaccel drm (aka v4l2request) and the v4l2 layer falls back to soft decoding. I also tried now mpv but just with null output (as it can't fbdev) and captured the debug trace like so mpv Big_Buck_Bunny_720_10s_10MB.mp4 -vo=null --msg-level=all=trace [vd] Codec list: [vd] h264 - H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 [vd] h264_v4l2m2m (h264) - V4L2 mem2mem H.264 decoder wrapper [vd] Opening decoder h264 [vd] Looking at hwdec h264-drm... [vd] Could not create device. [vd] No hardware decoding available for this codec. [vd] Using software decoding. no hw accel used! I also captured a ffmpeg trace. ffmpeg -v trace -re -hwaccel drm -i Big_Buck_Bunny_720_10s_10MB.mp4 -f null - Maybe its in fact a duo2 only device tree related? Could someone try the same on any other H3 and provide thr results? If it really works with hwaccel and the org. 30fps I would like to have the trace logs, ideally the ffmpg* or both. lsmod | grep ced sunxi_cedrus 40960 0 v4l2_mem2mem 16384 1 sunxi_cedrus videobuf2_dma_contig 16384 1 sunxi_cedrus videobuf2_v4l2 16384 2 sunxi_cedrus,v4l2_mem2mem videobuf2_common 45056 5 sunxi_cedrus,videobuf2_dma_contig,videobuf2_memops,v4l2_mem2mem,videobuf2_v4l2 videodev 188416 3 sunxi_cedrus,v4l2_mem2mem,videobuf2_v4l2 mc 36864 5 sunxi_cedrus,videobuf2_common,videodev,v4l2_mem2mem,videobuf2_v4l2 *ffmpeg has been installed from below as the compiled 8x throws errors with -hwaccel. # Install the precompiled # ffmpeg version 5.1.6-0+deb12u1 Copyright (c) 2000-2024 the FFmpeg developers # built with gcc 12 (Debian 12.2.0-14) # https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/ # As root, no sudo # APT REPOSITORY SETUP wget http://apt.undo.it:7242/apt.undo.it.asc -O /etc/apt/trusted.gpg.d/apt.undo.it.asc . /etc/os-release && echo "deb http://apt.undo.it:7242 $VERSION_CODENAME main" | sudo tee /etc/apt/sources.list.d/apt.undo.it.list echo -e "Package: *\nPin: release o=apt.undo.it\nPin-Priority: 600" | sudo tee /etc/apt/preferences.d/apt-undo-it # We only install ffmpeg. mpv doesn't work anyway with framebuffer # INSTALL FFMPEG AND MPV PACKAGES apt install ffmpeg

I was just wondering if there would be an issue because of different U-Boot and kernel combination in the 2 tests, but that does not seem to be the case. I think there might be some issue with the controller in the eMMC module that is starting to reveal when wear-level is or is getting higher. What fsck commands are done? So how is it fixed and is it fixed or is only metadata corrected and might there be corrupted data-blocks still without knowing. I don't use Ext4, I use Btrfs for rootfs and all other storage devices. In doubt, I use DUP profile for meta data, that is more for HDDs. As said Btrfs allows adhoc or regular scrubs, you will be able to detect where corrupt blocks are if that is the issue. It also might be that there is an issue in the 6.6 kernel that reveals itself when higher write delays or so, maybe update the OS. Maybe mmc-utils can show some issue (I have no experience with it).

reopening after moving to "Software / Applications / Userspace"

You realized the wrong thing: the topic is actual but this is not a forum where to discuss about Android or stock firmwares

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

@Nick A thank you.

Very bad advice. You just made all files under /home/odroid executable. Don't run server software unless you have at least a rudimentary understanding of Linux, especially if accessible from the internet. Better get hosting and not pwned and part of a botnet. This topic is not specific to Armbian and thus more suitable to be discussed elsewhere.

Hi @dale What is your DTS node for your display? My first guess is that your DT node is not being picked up/inexistent since the module loads but the display device is not present. You can use dtc /proc/device-tree to see your loaded DT and find your display node, if any. Then, have you checked dmesg for any tm16xx kernel message? Then, you can ls /sys/class/leds to see if any device were created. The display-service/display-utils scripts expect /sys/class/leds/display. That should not be your issue here, but I'm not sure that aip1688 is the same as tm1628 variants. Googling aip1688 list it besides aip1618, so that would be the tm1618 variant. Whatsoever, I think you should have partial working display if using tm1628. To be 100% of which compatible string to use, we would need the aip1688 datasheet but I couldn't find it online. Good luck with your experimentation! Let me know how you results.

OK, personally I like btrfs and have been using it exclusively for about a decade now, I guess. Reason are manifold, but the one applicable to your case is that it will automatically detect and if possible fix corruption even when mounted. This can help prevent it from mushrooming into a bricked situation. You can also do an online "btrfs scrub" while the system is mounted, akin to the fsck that requires taking the ext4 FS offline. Look into an AB option where you have a (readonly if you like) failsafe boot system somewhere accessible to uboot in addition to your main OS. And if uboot detects main OS boot failure, have it switch over to the failsafe, ssh in to it and fix the FS corruption. How to do that with uboot, I am not sure. @eselarm might know and quite possibly that is the reason he was asking what uboot version you have as it might depend on that. There are also commercial solutions available like qubee, rauc and mender that you might want to look into.

Anyone an idea?

Hi, @Jean-Francois Lessard I'm using a x98h box with self-built image. I have issue with the tm16xx kernel module using a patch https://github.com/paolosabatino/armbian-build/blob/main/patch/kernel/archive/rockchip64-6.16/general-driver-tm16xx-led-driver.patch The vfd controller is AIP1688 which is similar to fd628. Do you have any idea why it fails?

Yup, I opened a bug report about this on his github, I have yet to receive an answer. I'm having trouble figuring out if it's a hardware issue or a software issue, since I don't have a second bug to test at the same time. When I try the Makerbase OS on this same board, I don't have connectivity either, but at least, the link led turns on and off with the cable connect/disconnect.

Did you try to build the image with compile.sh and this following setting? INCLUDE_HOME_DIR=yes See https://docs.armbian.com/Developer-Guide_Build-Switches/#advanced

Hello ! I'm trying to build my custom Armbian image for a Raspberry Pi. When I build it with these settings, I get a rolling release, which I don't want. compile.sh BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes DISABLE_IPV6=true INCLUDE_HOME_DIR=yes KERNEL_CONFIGURE=no NETWORKING_STACK=network-manager RELEASE=trixie EXPERT=yes BOARD=rpi4b But when I boot with the official armbian minimal image (Armbian_25.8.1_Rpi4b_trixie_current_6.12.41_minimal.img) It's not on the rolling release. Do I miss a setting ? edit: I've tried with building the image on the main and the v25.08 branch.

@Ducdanh Nguyen you forgot these steps choose "Show CSC/WIP/EOS/TVB" choose "I understand and agree" you should see a few x96q in the list.

@Nick A heres the complete info : 🧠 DRAM Chip 1: Marking: MPF694C4G-P Maker: UniIC (UnilC) Type: DDR3/DDR3L Density: 4 Gb (512 MB) Date code: 2021 (week 11) Chip 2: Marking: SBC13H4G150 Maker: UniIC (UnilC) Type: DDR3/DDR3L Density: 4 Gb (512 MB) Date code: 2020 (week 11) ✅ Total RAM = 1 GB (2 × 512 MB) 💾 Storage (eMMC) Chip: Marking (line 1): NCEMAM60-08G Maker: FORESEE Type: eMMC Flash (not raw NAND) Capacity: 8 GB Marking (line 2): 000 Serial/Batch: Z1S1801147073 Date code: 1802 → Year 2018, Week 02 ✅ Total storage = 8 GB eMMC (manufactured early 2018)

@eselarm Thanks for the reply. We are using U-Boot: 2024.01-armbian-2024.01-S866c-P00ff-Ha5c2-V4cad-Bb703-R448a (Jan 21 2025 - 02:21:57 +0000) Allwinner Technology U-Boot 2024.01-armbian-2024.01-S866c-P00ff-Ha5c2-V4cad-Bb703-R448a (Jan 21 2025 - 02:21:57 +0000) Allwinner Technology CPU: Allwinner H3 (SUN8I 1680) Model: FriendlyARM NanoPi NEO Air DRAM: 512 MiB Core: 64 devices, 16 uclasses, devicetree: separate WDT: Not starting watchdog@1c20ca0 MMC: mmc@1c0f000: 0, mmc@1c10000: 2, mmc@1c11000: 1 Loading Environment from FAT... Unable to use mmc 0:1... In: serial,usbkbd Out: serial Err: serial Net: No ethernet found. starting USB... No working controllers found Autoboot in 1 seconds, press <Space> to stop