Active threads

A difference between FriendlyElec image and Armbian image is U-Boot ( bootloader/firmware ) variant I think. For my NanoPi-R6C, HDMI audio does not work if I boot from SD-card where an image with a U-Boot from 2026 is written in the boot area (between main GPT and 1st partition). If I wipe that U-Boot by zeroing that area, the OS will take EDK2 UEFI v1.1 that I have written to eMMC. Then there is HDMI sound, on Armbian and Opensuse Tumbleweed. I need to check if I run it in hybrid ACPI+DeviceTree mode or just DeviceTree mode. The setting is anyway 'mainline kernel' DT, which should be about 6.10 or later. If I select 'vendor kernel', it can only run Armbian 6.1.115, but I don't remember if KDE6 Wayland does work then. I only did that to check if I idle power consumption was still < 1.5 Watt, which was the case. Else it is 3 Watt and min clock is 1GHz instead of 480MHz and more differences. I remember I saw some U-Boot version scrolling by when I messed up partitions on eMMC (might just be corrupt 2nd backup GPT), I think the UEFI code did fall back to some build-in U-Boot. Now I did check certain things: # gunzip < rk3588-sd-debian-trixie-gnome-wayland-desktop-6.1-arm64-20260629.img.gz | dd count=32k status=none | grep -FUzi "U-Boot SPL 20" U-Boot SPL 2017.09-g50821b3c8bd-241113 #fa (Jan 02 2025 - 16:53:42) # cat nanopi-r6c_UEFI_Release_v1.1.img | dd count=32k status=none | grep -FUzi "U-Boot SPL 20" U-Boot SPL 2017.09-g5f53abfa1e-221223 #zzz (Dec 26 2022 - 09:10:09) So the EDK2 seems to contain some old base U-Boot and also the FriendlyElec image same U-Boot base, however, it can be different and certainly is incompatible with mainline recent year U-Boot and also likely the vendor tagged one from Armbian. FriendlyElec could do various HW initialization in a different way and on top of that or mixed with it, EDK2 again does things. It needs rebuild EDK2 from source or so in order to gain more know-how and check. I also see the kernel version string in the FriendlyElec image is '6.1.141' (Armbian is '6.1.115-vendor-rk35xx' ), what that means I don't know, kernel.org is at 6.1.177 (2026-07-04). I am using 7.1.3+deb14-arm64-16k #1 SMP PREEMPT Debian 7.1.3-1 (2026-07-04) from Debian Sid repo, userspace is Armbian Trixie. So no HW accel, at least not in KDE6 with FireFox. The added RKMPP libs are 1 thing, the DMA devices are another. Names like 'uncached' and 'dma32' are important hints on how and what is implemented, wrapping tactics etc. The whole issue with those FriendlyElec images is, at a Debian minor update for example, those libav* files get overwritten. In addition, kernel sources w.r.t RKMPP are banned from github. So those images from FriendlyElec are a 1-time shot, works as longs as you don't update. I spent a lot of time to build RPI kernels and their ffmpeg/libav variant. It changed several times, now I don't use it anymore in a generic way, mainly because the HW encoder is fairly limited and does also not work anymore with Jellyfin ffmpeg build (for transcoding on-the-fly). Same for OpenSuse, they are strict on MPEG licensing/royalties, so no MPEG2,H264,HEVC etc, you extra need other repo to make it work. To come back to OP topic title, LibreElec (so dedicated Kodi) worked fine HW accel for HEVC, H264, H265, AV1 and partly for VP9. Was about 9 months ago I ran that dedicated from separate SD-card, so LE's own U-Boot and kernel etc, all mainline based. But is only decoders, so playing video on a usually larger HDMI monitor. So the kernel can do it, it is just many different API's and protocols. FireFox focuses on VAAPI AFAIK, so known to work fine on Intel HW, but needs then tweaks to work with v4l2_m2m AFAIK. Maybe look at RPi's FireFox patches, although I think it is proprietary for their Broadcom tailored kernel, so won't work with mainline Linux nor Rockchips stuff on RK3588.

Hello, I make two away with both kernel version. With officiel 6.18.35 and a build by me 6.18.37 with armbian build framework. see here: For the moment, i freeze to version kernel 6.18.10 and DTB file patch and all is Okok. Have a good day.

Should work on all devices

Hi Igor, This worked! Falling back to 6.1.115 and a working internal WiFi... Ernst-Jan

512M seems too low: [ 70.791346] containerd: page allocation failure: order:1, mode:0x40820(GFP_ATOMIC|__GFP_COMP), nodemask=(null),cpuset=containerd.service,mems_allowed=0 [ 70.791404] CPU: 1 UID: 0 PID: 1727 Comm: containerd Not tainted 6.18.10-current-meson64 #1 PREEMPT [ 70.791410] Hardware name: linux,dummy-virt (DT) [ 70.791414] Call trace: [ 70.791417] show_stack+0x20/0x38 (C) [ 70.791427] dump_stack_lvl+0x74/0x90 [ 70.791436] dump_stack+0x18/0x28 [ 70.791441] warn_alloc+0x134/0x1c0 [ 70.791449] __alloc_frozen_pages_noprof+0x780/0xe70 [ 70.791457] alloc_pages_mpol+0xbc/0x1c8 [ 70.791463] alloc_frozen_pages_noprof+0x50/0xd0 [ 70.791468] new_slab+0x2ec/0x3a8 [ 70.791474] ___slab_alloc+0x654/0xbb8 [ 70.791480] __slab_alloc.isra.0+0x50/0xa8 [ 70.791485] __kmalloc_noprof+0x410/0x638 [ 70.791491] virtqueue_add_sgs+0x2e4/0x6d0 [ 70.791499] virtblk_add_req+0xb8/0x130 [ 70.791507] virtio_queue_rq+0x80/0x208 [ 70.791513] blk_mq_dispatch_rq_list+0x104/0x6f0 [ 70.791521] __blk_mq_sched_dispatch_requests+0x45c/0x570 [ 70.791527] blk_mq_sched_dispatch_requests+0x38/0x88 [ 70.791532] blk_mq_run_hw_queue+0x25c/0x2d0 [ 70.791538] blk_mq_dispatch_list+0x110/0x420 [ 70.791545] blk_mq_flush_plug_list+0x5c/0x190 [ 70.791551] __blk_flush_plug+0xf0/0x158 [ 70.791559] blk_finish_plug+0x40/0x60 [ 70.791565] read_pages+0x130/0x2c8 [ 70.791573] page_cache_ra_unbounded+0x1e4/0x300 [ 70.791580] page_cache_ra_order+0x41c/0x488 [ 70.791586] filemap_fault+0x5d8/0xb68 [ 70.791592] __do_fault+0x44/0x240 [ 70.791599] __handle_mm_fault+0x9e4/0x18a0 [ 70.791604] handle_mm_fault+0x194/0x2e0 [ 70.791609] do_page_fault+0x110/0x6f8 [ 70.791616] do_translation_fault+0x54/0x80 [ 70.791623] do_mem_abort+0x4c/0xa8 [ 70.791630] el0_ia+0x50/0xd0 [ 70.791637] el0t_64_sync_handler+0xe0/0xe8 [ 70.791644] el0t_64_sync+0x198/0x1a0 [ 70.791650] Mem-Info: [ 70.791832] active_anon:11944 inactive_anon:39978 isolated_anon:0 [ 70.791832] active_file:11107 inactive_file:13422 isolated_file:0 [ 70.791832] unevictable:0 dirty:0 writeback:8 [ 70.791832] slab_reclaimable:5622 slab_unreclaimable:10672 [ 70.791832] mapped:6999 shmem:423 pagetables:2117 [ 70.791832] sec_pagetables:0 bounce:0 [ 70.791832] kernel_misc_reclaimable:0 [ 70.791832] free:912 free_pcp:426 free_cma:29 [ 70.791874] Node 0 active_anon:47776kB inactive_anon:159912kB active_file:44428kB inactive_file:53688kB unevictable:0kB isolated(anon):0kB isolated(file):0kB mapped:27996kB dirty:0kB writeback:32kB shmem:1692kB shmem_thp:0kB shmem_pmdmapped:0kB anon_thp:0kB kernel_stack:6016kB pagetables:8468kB sec_pagetables:0kB all_unreclaimable? no Balloon:0kB [ 70.791907] Node 0 DMA free:3648kB boost:4096kB min:6768kB low:7436kB high:8104kB reserved_highatomic:2048KB free_highatomic:56KB active_anon:47776kB inactive_anon:159912kB active_file:44428kB inactive_file:53460kB unevictable:0kB writepending:32kB zspages:76228kB present:524288kB managed:484516kB mlocked:0kB bounce:0kB free_pcp:1960kB local_pcp:908kB free_cma:116kB [ 70.791945] lowmem_reserve[]: 0 0 0 0 [ 70.791963] Node 0 DMA: 276*4kB (MEC) 54*8kB (MEH) 90*16kB (MEH) 20*32kB (UE) 2*64kB (U) 0*128kB 1*256kB (U) 0*512kB 0*1024kB 0*2048kB 0*4096kB = 4000kB [ 70.792025] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=1048576kB [ 70.792038] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=32768kB [ 70.792051] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=2048kB [ 70.792063] Node 0 hugepages_total=0 hugepages_free=0 hugepages_surp=0 hugepages_size=64kB [ 70.792076] 24919 total pagecache pages [ 70.792084] 33 pages in swap cache [ 70.792091] Free swap = 184kB [ 70.792098] Total swap = 242256kB [ 70.792105] 131072 pages RAM [ 70.792112] 0 pages HighMem/MovableOnly [ 70.792119] 9943 pages reserved [ 70.792126] 32768 pages cma reserved [ 70.792133] 0 pages hwpoisoned [ 70.792140] SLUB: Unable to allocate memory on CPU 1 (of node 0) on node -1, gfp=0x820(GFP_ATOMIC) [ 70.792154] cache: kmalloc-8k, object size: 8192, buffer size: 8192, default order: 3, min order: 1 [ 70.792168] node 0: slabs: 29, objs: 116, free: 0 ... and many OOM killer actions to follow, but could type: poweroff It might be that is no zram swap and swap on disk, that is could work, but from some earlier HA topic here I remember that was a swapping hell on a 4-core Cortex-A53 and SD-card, way too slow. My KVM is image on NVME on ROCK5B, so fastest available more or less for 'cheap' ARM64 SBC. To compare: Domoticz did run OK with about the same amount of objects on a NanoPi-NEO (4x Cortex-A7, 512MiB, SD-card). It still does, but I moved most objects to a 2x Cortex-A55 1G RAM (KVM on same ROCK5B). # free -m total used free shared buff/cache available Mem: 963 330 77 2 635 632 Swap: 981 45 936 BUT I see also something with 'containers' when ZigBee in my google search. I would maybe see what exactly is needed. After many years, I also figured out that my 433MHz transceiver internally is just a 38k4 serial thing tied to an serial-to-USB chip. It was driven as serial port by Domoticz via USBIP on that NanoPi-NEO, but that needs explicit sync/reconnect actions at reboot. Now done via ser2net, swapping/replacing the device from serial to LAN in Domoticz, same database history, no actions at reboot/powercycle and with ser2net point-to-multipoint, also also available to multiple softwares in the home LAN or VPN etc if needed. Of course respecting write/send operations to be exclusive, just one. Same ser2net trick with electricity meter, that is why I can easily run HA/HAOS simultaneously with my normal home automation software stuff.

Looks like I accidentally erased most of my u-boot from SPI flash since I don't have much experience with it. Are there any ways to restore it and what soft- and hardware do I need, apart from having a Linux PC and UART?

Updating U-Boot was the solution, kernel is now up to date!!! Thanks everyone for the tips, learned a few new things and the UART cable is really usefull!

Much to my chagrin I have had to do a similar dance today after running updates./. I tried sudo dpkg-reconfigure aic8800-usb-dkms but no joy. This time was easier and it was just a matter of getting the firmware and usb module directly from radxa's repo. ```wget https://github.com/radxa-pkg/aic8800/releases/download/5.0%2Bgit20260123.5f7be68d-6/aic8800-firmware_5.0+git20260123.5f7be68d-6_all.deb wget https://github.com/radxa-pkg/aic8800/releases/download/5.0%2Bgit20260123.5f7be68d-6/aic8800-usb-dkms_5.0+git20260123.5f7be68d-6_all.deb``` Then install both of them ```sudo dpkg -i aic8800-firmware_*.deb aic8800-usb-dkms_*.deb``` and then remapping the hardware and restarting ```sudo depmod -a sudo reboot``` Leaving this there... for next time I do an update

I want to compile a matching build for: https://armbian.com/boards/odroidhc4 Debian 13trixie Minimal (CLI)—current6.18.33 https://dl.armbian.com/odroidhc4/Trixie_current_minimal Matching the img is fine (rather than the img.xz). I haven't compiled a matching build yet. I am doing this to debug my issue with the stock builds. Running: ./compile.sh BOARD=odroidhc4 BRANCH=current RELEASE=trixie BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_CONFIGURE=no Logs forthcoming.

Oh well, that's quite some time ago. The patchset used back then has been removed/renamed already to move on. Look at 6df6d0d607abfd59169a0ef2fddbed5fcd5b58f9 The question is has this introduced upstream or with one of the patches Armbian puts on top. Quite a journey to dig through that.

Thanks for the great work Nick. 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). The panel was a ST7789V 240*320 TFT LCD and I have a A7Z, with the `Radxa-cubie-A7a-a7z-v0.6.4` server image installed. And I have put the work on [Github](https://github.com/parker-int64/sun60i-a733-dtoverlays). During the experiment, I discovered that the PWM (used for display backlight) in the allwinner BSP seems to have a bug. The Allwinner Sunxi PWM driver may incorrectly reverts the PWM pin to GPIO input immediately after switching the pinctrl state. Thus I can control the PWM with the file nodes but can't attached it to related pins. For example, I'm using the `sun60i-a733-pwm1-7.dtso` overlay, which is supposed to enable the PJ25. After enabling the overlay, I noticed that the PWM nodes were created and I can controll these nodes. But the pinctrl suggest that it was unclamied: $ cat /sys/kernel/debug/pinctrl/2000000.pinctrl/pinmux- pins | grep PJ25 pin 313 (PJ25): UNCLAIMED Later on, AI found out that the `devm_pinctrl_put(pctl);` in bsp/drivers/pwm/pwm-sunxi.c may have been incorrectly called on the clean stage of the `sunxi_pwm_pin_set_state`: 520 static int sunxi_pwm_pin_set_state(struct device *dev, char *name) 521 { 522 struct pinctrl *pctl; 523 struct pinctrl_state *state = NULL; 524 int err; 525 526 pctl = devm_pinctrl_get(dev); 527 if (IS_ERR(pctl)) { 528 sunxi_err(dev, "pinctrl_get failed\n"); 529 err = PTR_ERR(pctl); 530 return err; 531 } 532 533 state = pinctrl_lookup_state(pctl, name); 534 if (IS_ERR(state)) { 535 sunxi_err(dev, "pinctrl_lookup_state(%s) failed\n", name); 536 err = PTR_ERR(state); 537 goto exit; 538 } 539 540 err = pinctrl_select_state(pctl, state); 541 if (err) { 542 sunxi_err(dev, "pinctrl_select_state(%s) failed\n", name); 543 goto exit; 544 } 545 546 exit: 547 /* 548 * devm_pinctrl_put() releases the last pinctrl reference, 549 * causing pinmux_disable_setting() to restore the pin to 550 * its default GPIO function. The devres framework will 551 * release this resource automatically when the device is 552 * destroyed. 553 */ 554 devm_pinctrl_put(pctl); 555 return err; 556 557 } Also it gives me a workaround `sunxi-pwm-child-pinctrl.c`, introduces an additional pinctrl reference, preventing `devm_pinctrl_put()` from reducing the reference count to zero. Both the patch file and the workaround source is available on Github. However I only tried the workaround since I have some trouble compile the full kernel at the moment, will try some time later and update more details on Github. And at last the pwm-backlight worked as expected and my LCD light up.

There is a previous topic on this from 2020, but it's closed and not much action was taken except discussing workarounds. I'd like to continue this. Looking at the kernel configs in this repo, many of them have CONFIG_RT_GROUP_SCHED=y. This does not play nicely with modern systemd (cgroups v2), breaking things like rtkit-daemon. See https://bugs.gentoo.org/569546 and https://bugzilla.redhat.com/show_bug.cgi?id=655321. rtkit is an important part of making pulseaudio and pipewire work smoothly, as well as for many other low-latency applications. There are a few currently available workarounds, but none are ideal: 1. Linux 6.16 or later has boot time param rt_group_sched=0 to override it, but there is still some runtime overhead. No exact alternative for earlier kernels. 2. kernel.sched_rt_runtime_us=-1 in sysctl.conf -- potentially dangerous as it removes the 95% CPU time safeguard for RT processes, leading to lockups when badly behaving processes exist. 3. disable cpu and cpuset cgroup controllers in systemd configs -- has a lot of other side effects, like preventing systemd's CPU limits for services Since the last post on this (linked above), forcefully assigning an rt time time slice won't even work anymore, since cgroup v2 doesn't even have that ability anymore. So this kernel config option is somewhat useless now.

thanks. The image has been launched. I will try to test gpio and mipi camera.

I already did the apt update & upgrade, it actually seems like the 6.18.35 did solve that issue - or at least, that's how I'd read the newer "armbianmonitor -u" as posted here: https://paste.armbian.com/orawuzawun PS: I didn't test again if it works now without the script for reasons of lack of access to the bananapi + local screen + local keyboard in case it still came up without end0 - bot the output of armbianmonitor at least doesnt show up that failure you pointed at.

Added https://github.com/armbian/build/pull/10213

You should check with: grep non-free /etc/apt/sources.list.d/*.sources And remove the non-free components and also remove/purge all packages that belong to non-free. You probably need some 'man apt-get' to figure out how to select those.

Of course. Kernel upgrade is handled via standard apt get update and upgrade. If you need to change to specific kernel, use https://docs.armbian.com/User-Guide_Armbian-Config/System/#alternative-kernels Make sure to update all packages before going that route, IIRC this problem is related to u-boot. Which is updated after all packages are up2date with armbian-install utility,

Software complexity is extreme ... And only x86 I would assume, so there is very little of interests for us. It is enough that packages are assembled at different time, so they will have different (bugs &) fixes. Either Ubuntu will get this bug or xtradebs will be fixed. Soon both wil be fixed or both broken .... unless bug is down to the OS level. Where snap will win with its, presumbly, stabilized OS container.

I discovered via an only partly working ssh (I thought was WiFi signal strenght issue or so) that a new version of firewalld was installed and also new conf file that had default set to public instead of trusted (what should be fine for LAN only direct traffic). On a typical generic client-only laptop/computer you probably won't notice. Best is to keep that default and add a zone= statement to the NM profile for a specific connection. I have seen the same for systemd-networkd, but not done anything myself with it. Also should not happen on Debian Stable, but rolling distro is another story.

Hi xaja34, The patches and all code modifications used to build the 1 GB Cubie A5E images are already present in my repository. I pushed the complete Git commits alongside the prebuilt images that I published in the Releases section. You can find the changes here: radxa-cubie-a5e-armbian-build@202f1bf Best regards, Guation

Weston 16 expands HDR and color management support, improves Perfetto debugging and DRM backend performance, and adds new protocol and renderer capabilities for more efficient and flexible Wayland compositor development. View the full article

Use framework and DIY. That's what it is made for

that looks like a very ambitious undertaking

sudo ip link set dev wlp1s0 down sudo ip link set dev wlp1s0 address 02:00:00:00:00:01 sudo ip link set dev wlp1s0 up sudo systemctl restart NetworkManager

Same problem here. There are two other (older) threads without a real solution. Has anyone found a fix?