All Activity

maybe this bug at Rockchip/mpp is relative : https://github.com/rockchip-linux/mpp/issues/855

Hi The rights seems to be ok : gart@orangepi5:~$ ls -la /dev/dma_heap total 0 drwxr-xr-x 2 root root 100 Jan 1 1970 . drwxr-xr-x 20 root root 3940 Jul 4 19:49 .. crw-rw---- 1 root video 251, 2 Jul 4 19:48 cma crw-rw---- 1 root video 251, 0 Jul 4 19:48 system crw-rw-rw- 1 root video 251, 1 Jul 4 19:48 system-uncached my user is in the video group gart@orangepi5:~$ sudo cat /etc/group | grep video video:x:44:gart There should not be any issue If I launch ffmpeg encoding with sudo, it does'nt work neither I still have this kind of messages in syslog : 2025-07-06T15:32:19.769702+02:00 orangepi5 kernel: rk_vcodec: mpp_collect_msgs:1622: session 1 process cmd 401 ret -22 2025-07-06T15:32:19.769706+02:00 orangepi5 kernel: rk_vcodec: mpp_dev_ioctl:1732: collect msgs failed -22 2025-07-06T15:32:19.769708+02:00 orangepi5 kernel: rk_vcodec: mpp_task_attach_fd:1841: can't import dma-buf 275 2025-07-06T15:32:19.769711+02:00 orangepi5 kernel: rk_vcodec: mpp_translate_reg_address:1897: reg[ 0]: 0x00000113 fd 275 failed 2025-07-06T15:32:19.769713+02:00 orangepi5 kernel: rk_vcodec: mpp_task_dump_mem_region:2084: --- dump task 0 mem region --- 2025-07-06T15:32:19.769716+02:00 orangepi5 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: no memory region mapped 2025-07-06T15:32:19.769718+02:00 orangepi5 kernel: rk_vcodec: mpp_process_task_default:589: alloc_task failed. 2025-07-06T15:32:19.769721+02:00 orangepi5 kernel: rkvenc2_wait_result:2340: session 00000000b0422e29 pending list is empty! 2025-07-06T15:32:19.769724+02:00 orangepi5 kernel: rk_vcodec: mpp_msgs_wait:1693: session 1 wait result ret -5 2025-07-06T15:32:19.768265+02:00 orangepi5 mpp[3723]: message repeated 2 times: [ mpp_serivce: mpp_service_ioc_attach_fd failed ret -1 errno 22 Invalid argument] 2025-07-06T15:32:19.785062+02:00 orangepi5 mpp[3723]: mpp_serivce: mpp_service_ioc_attach_fd failed ret -1 errno 22 Invalid argument 2025-07-06T15:32:19.786302+02:00 orangepi5 kernel: rk_vcodec: mpp_process_request:1434: can not import fd 143 2025-07-06T15:32:19.786319+02:00 orangepi5 kernel: rk_vcodec: mpp_collect_msgs:1622: session 1 process cmd 401 ret -22 2025-07-06T15:32:19.786321+02:00 orangepi5 kernel: rk_vcodec: mpp_dev_ioctl:1732: collect msgs failed -22 2025-07-06T15:32:19.786322+02:00 orangepi5 kernel: rk_vcodec: mpp_task_attach_fd:1841: can't import dma-buf 274 2025-07-06T15:32:19.786323+02:00 orangepi5 kernel: rk_vcodec: mpp_translate_reg_address:1897: reg[ 0]: 0x00000112 fd 274 failed 2025-07-06T15:32:19.786324+02:00 orangepi5 kernel: rk_vcodec: mpp_task_dump_mem_region:2084: --- dump task 0 mem region --- 2025-07-06T15:32:19.786324+02:00 orangepi5 kernel: mpp_rkvenc2 fdbd0000.rkvenc-core: no memory region mapped 2025-07-06T15:32:19.786325+02:00 orangepi5 kernel: rk_vcodec: mpp_process_task_default:589: alloc_task failed. 2025-07-06T15:32:19.786327+02:00 orangepi5 kernel: rkvenc2_wait_result:2340: session 00000000b0422e29 pending list is empty! I lauch a simple file encoding from an AV1 file to x265 : sudo ffmpeg -i file1.AV1.mkv -c:v hevc_rkmpp -c:a copy ~/Downloads/file1.x265.mkv The result is a file that has a correct size, but is unreadable, black screen.

Since U-Boot v2025.04 works very well on Orange Pi Zero v3 and has a shorter boot process time, if there was a possibility to switch to U-Boot v2504 for Orange Pi Zero V1, I would be grateful, as would probably other users of this SBC Regards

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?

Here's what I get when booting with the cubieboard dts: [ 1.728145] sun4i-drm display-engine: bound 1e00000.display-frontend (ops 0xc0a991d0) [ 1.728324] sun4i-drm display-engine: bound 1e20000.display-frontend (ops 0xc0a991d0) [ 1.728769] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc0a98948) [ 1.729127] sun4i-drm display-engine: bound 1e40000.display-backend (ops 0xc0a98948) [ 1.729663] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.729694] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc0a96e08) [ 1.730170] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 1.730197] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xc0a96e08) [ 1.731739] sun4i-drm display-engine: bound 1c16000.hdmi (ops 0xc0a99bb4) [ 1.732958] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0 [ 1.733040] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes [ 1.740576] sun4i-drm display-engine: [drm] Cannot find any crtc or sizes [ 20.185738] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... [ 20.660147] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 20.680927] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. [ 29.081755] [drm] Initialized lima 1.2.0 20200215 for 1c40000.gpu on minor 1 And here's what I get when I boot with the topwise a721 dts: [ 3.444277] sun4i-drm display-engine: bound 1e00000.display-frontend (ops 0xc0a991d0) [ 3.444440] sun4i-drm display-engine: bound 1e20000.display-frontend (ops 0xc0a991d0) [ 3.444985] sun4i-drm display-engine: bound 1e60000.display-backend (ops 0xc0a98948) [ 3.445348] sun4i-drm display-engine: bound 1e40000.display-backend (ops 0xc0a98948) [ 3.446154] sun4i-drm display-engine: bound 1c0c000.lcd-controller (ops 0xc0a96e08) [ 3.446799] sun4i-drm display-engine: No panel or bridge found... RGB output disabled [ 3.446830] sun4i-drm display-engine: bound 1c0d000.lcd-controller (ops 0xc0a96e08) [ 3.473706] [drm] Initialized sun4i-drm 1.0.0 20150629 for display-engine on minor 0 [ 3.555810] sun4i-drm display-engine: [drm] fb0: sun4i-drmdrmfb frame buffer device [ 7.940078] systemd[1]: Starting modprobe@drm.service - Load Kernel Module drm... [ 8.543295] systemd[1]: modprobe@drm.service: Deactivated successfully. [ 8.553328] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm. [ 15.005964] [drm] Initialized lima 1.2.0 20200215 for 1c40000.gpu on minor 1 Thanks, Shivam

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

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.

v4l2loopback-dkms 0.12.7-2 fails to build make.log: DKMS make.log for v4l2loopback-0.12.7 for kernel 6.12.32-current-rockchip64 (aarch64) Sat Jul 5 09:16:17 PM CDT 2025 Building v4l2-loopback driver... make -C /lib/modules/6.12.32-current-rockchip64/build M=/var/lib/dkms/v4l2loopback/0.12.7/build modules make[1]: Entering directory '/usr/src/linux-headers-6.12.32-current-rockchip64' CC [M] /var/lib/dkms/v4l2loopback/0.12.7/build/v4l2loopback.o /var/lib/dkms/v4l2loopback/0.12.7/build/v4l2loopback.c: In function ‘vidioc_querycap’: /var/lib/dkms/v4l2loopback/0.12.7/build/v4l2loopback.c:717:9: error: implicit declaration of function ‘strlcpy’; did you mean ‘strncpy’? [-Werror=implicit-function-declaration] 717 | strlcpy(cap->driver, "v4l2 loopback", sizeof(cap->driver)); | ^~~~~~~ | strncpy cc1: some warnings being treated as errors make[3]: *** [scripts/Makefile.build:229: /var/lib/dkms/v4l2loopback/0.12.7/build/v4l2loopback.o] Error 1 make[2]: *** [/usr/src/linux-headers-6.12.32-current-rockchip64/Makefile:1945: /var/lib/dkms/v4l2loopback/0.12.7/build] Error 2 make[1]: *** [Makefile:224: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.12.32-current-rockchip64' make: *** [Makefile:43: v4l2loopback.ko] Error 2 Edit: I had the wrong make.log contents. The old one was after I tried to fix it and failing. The actual build error is missing strlcpy().

I've gone round in circles with this one and it seems that there might not be a solution, so will set it up again on the NVME drive. Thanks for all the help offered.

Pull Request submitted: https://github.com/armbian/build/pull/8360

I hadn't done an upgrade but a fresh install; (v25.5.1 for Raspberry Pi 3 Model B running Armbian Linux 6.12.28-current-bcm2711) Realised that I had the same problem, only channel 2 was present; though I only realised something was missing when I'd tried RaspberryOS on a Pi Zero with the same i2c device. Adding to the /boot/config.txt didn't of itself solve the issue; adding the i2c1 to the armbian-config overlays also didn't see. However I did find the `/boot/firmware/config.txt` that has a lot more settings, and seems to be where armbian-config edits Note the `dtparam-i2c_arm=on` line... which was commented out. Adding that back and it works... (well after figuring out I needed to level shift the i2c device but that's another story) # For more options and information see # http://rptl.io/configtxt # Some settings may impact device functionality. See link above for details # Uncomment some or all of these to enable the optional hardware interfaces dtparam=i2c_arm=on #dtparam=i2s=on #dtparam=spi=on # .. dtoverlay=dwc2 i2c0 i2c1 i2c-gpio vc4-kms-v3d

Remote backup maybe only as data ... e.g. restic / rsync programs In my opinion it is best to make a backup of the SD card in linux connect miniSD card and make a backup in terminal: fdisk -l if your SD card is: sda / sda1.... then choose sda ! and then make a backup: dd if=/dev/sda of=/path_to_backup.img status=progress Restoring the image to the SD card with the same size: dd bs=4M if=/path_to_copy.img of=/dev/sdb status=progress If you want to burn the image to a smaller capacity SD card because, for example, the system is only 30% occupied, use the program:PiShrink https://github.com/Drewsif/PiShrink it works great for me for Armbian 🙂 sudo pishrink.sh /path_to_backup.img / /new_backup-Pishrink.img

After a recent kernel upgrade on a nanopi-r5s, the NVME device files /dev/nvme0* are no longer present. The relevant part of /var/log/syslog shows: 2025-07-05T20:55:35.716376+02:00 nanopi-r5s kernel: [ 0.000000] Linux version 6.12.35-current-rockchip64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.2.0-23ubuntu4) 13.2.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP PREEMPT Fri Jun 27 10:11:46 UTC 2025 ... 2025-07-05T20:55:35.719736+02:00 nanopi-r5s kernel: [ 4.491538] nvme nvme0: pci function 0002:01:00.0 2025-07-05T20:55:35.719739+02:00 nanopi-r5s kernel: [ 4.491584] nvme 0002:01:00.0: enabling device (0000 -> 0002) There is a single NVME drive installed and the output of a previous kernel where /dev/nvme0* was present is as follows. 2025-07-05T02:17:37.940170+02:00 nanopi-r5s kernel: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050] 2025-07-05T02:17:37.954269+02:00 nanopi-r5s kernel: [ 0.000000] Linux version 6.12.35-current-rockchip64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #1 SMP PREEMPT Fri Jun 27 10:11:46 UTC 2025 ... 2025-07-05T02:17:37.969044+02:00 nanopi-r5s kernel: [ 4.406406] nvme nvme0: pci function 0002:01:00.0 2025-07-05T02:17:37.969049+02:00 nanopi-r5s kernel: [ 4.406455] nvme 0002:01:00.0: enabling device (0000 -> 0002) 2025-07-05T02:17:37.969053+02:00 nanopi-r5s kernel: [ 4.540002] nvme nvme0: D3 entry latency set to 10 seconds 2025-07-05T02:17:37.969074+02:00 nanopi-r5s kernel: [ 4.628689] nvme nvme0: allocated 64 MiB host memory buffer. 2025-07-05T02:17:37.969080+02:00 nanopi-r5s kernel: [ 4.737972] nvme nvme0: 4/0/0 default/read/poll queues The contents of /etc/armbian-image-release currently are as follows: # PLEASE DO NOT EDIT THIS FILE BOARD=nanopi-r5s BOARD_NAME="NanoPi R5S" BOARDFAMILY=rockchip64 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=f149a11b4 LINUXFAMILY=rockchip64 ARCH=arm64 BOOT_SOC=rk3568 IMAGE_TYPE=nightly BOARD_TYPE=csc INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image KERNEL_TARGET=current,edge KERNEL_TEST_TARGET=current FORCE_BOOTSCRIPT_UPDATE= FORCE_UBOOT_UPDATE= OVERLAY_DIR="/boot/dtb/rockchip/overlay" VENDOR="Armbian_community" VENDORCOLOR="247;16;0" VENDORDOCS="https://docs.armbian.com" VENDORURL="https://github.com/armbian/build" VENDORSUPPORT="https://community.armbian.com/" VENDORBUGS="https://github.com/armbian/community/issues" BOOTSCRIPT_FORCE_UPDATE="no" BOOTSCRIPT_DST="boot.cmd" VERSION=25.8.0-trunk.245 REVISION=25.8.0-trunk.245 IMAGE_UUID=bef97f49-0290-4f2c-9d7a-0229540b307a INSTALLED=true The contents of /etc/armbian-release currently are as follows: # PLEASE DO NOT EDIT THIS FILE BOARD=nanopi-r5s BOARD_NAME="NanoPi R5S" BOARDFAMILY=rockchip64 BUILD_REPOSITORY_URL=https://github.com/armbian/build BUILD_REPOSITORY_COMMIT=034e9253c LINUXFAMILY=rockchip64 ARCH=arm64 BOOT_SOC=rk3568 IMAGE_TYPE=nightly BOARD_TYPE=csc INITRD_ARCH=arm64 KERNEL_IMAGE_TYPE=Image KERNEL_TARGET=current,edge KERNEL_TEST_TARGET=current FORCE_BOOTSCRIPT_UPDATE= FORCE_UBOOT_UPDATE= OVERLAY_DIR="/boot/dtb/rockchip/overlay" VENDOR="Armbian" VENDORCOLOR="247;16;0" VENDORDOCS="https://docs.armbian.com" VENDORURL="https://www.armbian.com/" VENDORSUPPORT="https://forum.armbian.com" VENDORBUGS="https://www.armbian.com/bugs" BOOTSCRIPT_FORCE_UPDATE="no" BOOTSCRIPT_DST="boot.cmd" VERSION=25.8.0-trunk.319 REVISION=25.8.0-trunk.319 BRANCH=6.1.0 Unfortunately, I don't have a version of the file when the NVME device files were still present. If I remember correctly, the working version was 25.8.0-trunk.313 https://github.com/armbian/os/tags Strangely, the current version 25.8.0-trunk.319 shows "(Ubuntu 13.2.0-23ubuntu4) 13.2.0" in the kernel boot output whereas the previous version (probably 25.8.0-trunk.313) shows "(Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0", i.e., a later version. Is there a way to try version 25.8.0-trunk.313 again or figure out what might be the problem with the current version?

I use the Station M2 image with dtb joined. Adapt fdtfile entry in /boot/armbianEnv.txt as needed. rk3566-box-demo_x96x6_24-custom.dtb

I get it: DDR Version V1.10 20190926 In ID:0xFFF 330MHz LPDDR3 Bus Width=32 Col=10 Bank=8 Row=15 CS=2 Die Bus-Width=32 Size=2048MB mach:14 rd addr 0xC0000000 = 0xFFED ERR

I had a look in /var/log/gdm3/, which was originally denying me permission but after obtaining access, it is empty, so no GDM log, as least in this folder. I also edited custom.conf to enable GDM logs but it had no effect. I was curious to know why there is a GDM3 folder, rather then GDM.

please show the output of "apt policy zfs-dkms" but essentially, this looks the same as your other rodeo/struggle with this board and dkms. As mentioned there, you are much better off with btrfs instead of zfs on your SBC.

Boring? To learn and have discussions? Strange sentiment. About bcachefs, for your sake, let's hope Linus Torvalds goes back on his comment that he and Kent will split ways in kernel 6.17 then so you won't have to rely on dkms for your unstable filesystem. bcachefs is in beta and should not be used as primary filesystem. Linux kernel mailing list: https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=rz5j0Hdk3N6cWgfE03-Q@mail.gmail.com/ No, it's impossible to have the same UUID on two btrfs systems at the same time, you can't even format a btrfs system and give it the same UUID, the kernel won't let you. See btrfs documentation: https://btrfs.readthedocs.io/en/latest/Send-receive.html So you are lying for some reason. Maybe the same reason you "don't read links". xD Has nothing to do with "trust", it has to do with how COW and send|receive works witch you don't seem to understand/ignore. And ofc an rsync (suddenly you talk about rsync instead of btrfs send -p) will work, it just checks if the files are changed and update them if necessary, witch is exactly what I have been saying is the better way for backups the whole time. IMHO it's even better to just create the subvolume(s) and rsync from the first run altogether if you want a backup, send|receive is not necessary and is just slow. And in the case of a complete backup incl boot like shrink-backup does by dd:ing the "boot sector" (witch includes potential boot partition), all that has to be done is make sure configs point to the new UUID (in case of rpi derivative systems nothing has to be done, because they use PARTUUID witch can be the same in contrast to UUID). If you "don't want to click links" to learn, I won't pressure you. You already seem triggered for some reason. But for others that might read this I hope my knowledge about backup strategies came through. Again, snapshots are perfect for rollbacks, but NOT for backups. Have a good Saturday.

@ScoreABSM Sorry I had to revert that PR. It seemed to initially work, but in the end it started hitting fails more than it functioned. https://github.com/armbian/build/pull/8344 I'm still on the case.

Hi im having problems when booting armbian on my OPI5P it is just blinking green and not showing a picture. I am using this version of Armbian: Armbian_25.5.1_Orangepi5-plus_noble_current_6.12.28_gnome_desktop.img and I have tried it on all boot media i have available (NVME, USB and SD card) but none worked. Sorry if there are any gramatical errors, I am from germany and my english isnt the best.

Many thanks @c0rnelius! Is there a build available to test these patches for bluetooth? Upgrading from 25.2.2 Debian standard image or only in rolling (Trixie or Plunkie)? Denis

My pihole is a virtual machine; I do not use SD-card for it, I keep virtual machine 'objects' around on various machines, so I do not have to wait 'burning' SD-cards. I can tell way more to prevent further assumptions being made about how I operate computers in my home and foreign country, but this is getting boring. I won't click all the various URLs. I would rather start using bcachefs (again) and see how long it will take before Kent Overstreet will have added a send|receive in there like now is available in ZFS and Btrfs. But it seems you did not get the point that I use the word 'snapshot' to identify both: (pseudo code) raspi1:/.snapshots/numberX/snapshot and othermachine:/backups/numberY/snapshot (and multiple othermachines, clone NAS as I said) On raspi1 it is local on SD-card, on othermachine(s) is the exact same filetree and same subvol (received) UUID. If I would not trust btrfs send|receive, which could be the case sometimes when doing btrfs development kernel patching around 2013 timeframe, I could do a an rsync -avxc between the 2, where 1 side is a just taken RW snapshot of the otherwise RO snapshot. So you will see rsync do writes to the RW subvol if something had gone wrong with kernel implementation or userspace. Or if i manually poked 1 sector random data in some some random file at some random offset (simulating a HDD bad sector). I have done that as test several times. It take time to do that between 2 4TB HDDs but not a problem.

Look for a PR in the next few days

The bug arose with kernel commit: 21cfbeae7d7c54a6cdea4b00096150f438f4fbde ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback Committer Greg Kroah-Hartman<gregkh@linuxfoundation.org> Author Detlev Casanova<detlev.casanova@collabora.com> Author date 1/17/25 8:31 AM Parent RISC-V: Mark riscv_v_init() as __init Child io_uring/uring_cmd: use cached cmd_op in io_uring_cmd_sock() Branch kernel-rockchip64-6.12 (io_uring/uring_cmd: use cached cmd_op in io_uring_cmd_sock()) Follows test (ASoC: Intel: sof_sdw: Fix DMI match for Lenovo 83JX, 83MC...) ASoC: rockchip: i2s_tdm: Re-add the set_sysclk callback [ Upstream commit 5323186e2e8d33c073fad51e24f18e2d6dbae2da ] In commit 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates"), the set_sysclk callback was removed as considered unused as the mclk rate can be set in the hw_params callback. The difference between hw_params and set_sysclk is that the former is called with the audio sampling rate set in the params (e.g.: 48000 Hz) while the latter is called with a clock rate already computed with sampling_rate * mclk-fs (e.g.: 48000 * 256) For HDMI audio using the Rockchip I2S TDM driver, the mclk-fs value must be set to 128 instead of the default 256, and that value is set in the device tree at the machine driver level (like a simple-audio-card compatible node). Therefore, the i2s_tdm driver has no idea that another mclk-fs value can be configured and simply computes the mclk rate in the hw_params callback with DEFAULT_MCLK_FS * params_rate(params), which is wrong for HDMI audio. Re-add the set_sysclk callback so that the mclk rate is computed by the machine driver which has the correct mclk-fs value set in its device tree node. Fixes: 9e2ab4b18ebd ("ASoC: rockchip: i2s-tdm: Fix inaccurate sampling rates") Signed-off-by: Detlev Casanova <detlev.casanova@collabora.com> Link: https://patch.msgid.link/20250117163102.65807-1-detlev.casanova@collabora.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>