Active threads

I'm not gonna explain all that. If you know the exact additions you need in the defconfig, post them here and I'll add them when I do my next PR. Which will probs be sometime this week.

@MMGen Thank you. But if you recreate the partitions, why would it matter? The new gpt partition will overwrite/ignore the mbr stuff... I'm just trying to understand here. I actually had that problem with missing backup table, but fixed it with rewriting the tables with gdisk. But I don't recreate the partition in that situation, because when I do recreate the partition the problem with missing backup table did not happen, that's why I'm confused. But I will do some testing if not copying the first 32k will actually fix that issue (or rather, if I dd /dev/zero to clear it), even though it sounds very strange to me because the backup table on gpt is on the LAST blocks, only for mbr/hybrid are they on the first.

I've made some progress in debugging the mpv error... I introduced some additional debug display instructions into the mpv source code, so I could see what was actually happening. And here is the new log: [vd] Codec list: [vd] hevc - HEVC (High Efficiency Video Coding) [vd] hevc_rkmpp (hevc) - Rockchip MPP (Media Process Platform) HEVC decoder [vd] hevc_v4l2m2m (hevc) - V4L2 mem2mem HEVC decoder wrapper [vd] Opening decoder hevc [vd] Looking at hwdec hevc_rkmpp-rkmpp... ctx->hwdec_devs = 0xffff64347e20 [vo/gpu] Loading hwdec drivers for format: 'drm_prime' [vo/gpu] Loading hwdec driver 'drmprime' [vo/gpu/drmprime] Using EGL dmabuf interop via GL_EXT_EGL_image_storage [vo/gpu/drmprime] Using DRM device: /dev/dri/renderD128 [vo/gpu/drmprime] ADDING DRMPRIME DEVICE [vo/gpu/drmprime] hw->devs=0xffff64347e20 [vo/gpu/drmprime] av_device_ref=0xffff64348860 ADD: ctx=0xffff6434af60 hw_imgfmt=1057 type=8 av_device_ref=0xffff64348860 num_hwctxs=1 [vo/gpu/drmprime] DEVICE ADDED [vo/gpu] Loading hwdec driver 'drmprime-overlay' [vo/gpu/drmprime-overlay] Failed to retrieve DRM fd from native display. [vo/gpu] Loading failed. Searching: hw_imgfmt=1057 device_type=12 (rkmpp) num_hwctxs=1 ENTRY 0: ctx=0xffff6434af60 av_device_ref=0xffff64348860 hw_imgfmt=1057 type=8 (drm) hw_ctx = (nil) [vd] Could not create device. [vd] Using software decoding. [vd] Detected 8 logical cores. [vd] Requesting 9 threads for decoding. [vd] Selected decoder: hevc - HEVC (High Efficiency Video Coding) [vd] DR parameter change to 1920x1088 yuv420p align=64 [vd] Allocating new (host-cached) DR image... [vo/gpu] DR path suspected slow/uncached, disabling. [vd] ...failed.. [vd] DR failed - disabling. [vd] Using software decoding. [vd] Decoder format: 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/auto CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none [vd] Using container aspect ratio. [vo/gpu] reconfig to 1920x1080 yuv420p bt.709/bt.709/bt.1886/limited/display CL=mpeg2/4/h264 crop=1920x1080+0+0 A=none [vo/gpu/wayland] Reconfiguring! [vo/gpu] max content size: 1024x600 [vo/gpu] monitor size: 1024x600 The result says exactly this: VO (drmprime): add a DRM type device Decoder (rkmpp): look for an RKMPP type device => can't find it => hw_ctx = NULL => Could not create device => decoding software More precisely: ADD: hw_imgfmt = 1057 type = DRM and immediately after: Searching: hw_imgfmt = 1057 device_type = RKMPP So the problem is not: The MPP, FFmpeg, mpv does not create hwdec_devs, drmprime driver The problem is that the two components are not talking about the same type of device. Actually, that tells me something else very important: hwdec_drmprime.c from mpv was written for decoders using: Vape, V4L2, other DRM backends It creates AVHWDeviceType = DRM, instead, FFmpeg's hevc_rkmpp is a new decoder, which expects AVHWDeviceType = RKMPP. These two pieces of code were not made for each other. That also explains why the decoder exists... I have hevc_rkmpp, but mpv knows absolutely nothing about RKMPP. mpv only knows: drmprime and drmprime creates a DRM device. My logical conclusion is that the official MPV is not suitable for the rkmpp hardware (it doesn't know about its existence). So what to do ? Where do I get a suitable MPV ?

I tried installing it to the internal eMMC memory, and now it won't boot. It looks like it'll have to stay on the SD card—or is there a way to install it?

Hi all, After a recent update bumped the current kernel to the 6.18 series, the rear 3.5mm jack on my NanoPC-T6 LTS stopped playing any sound. I'm connecting it to an external amplifier that worked fine before the update. What I see on 6.18 (6.18.35-current-rockchip64): The audio card (rt5616) still shows up in aplay -l and playback commands run without errors, but no sound comes out. Volume levels and mute aren't the issue — I checked those. What fixed it: downgrading via armbian-config to linux-image-current-rockchip64=25.11.2 (kernel 6.12.58). With 6.12 the audio works perfectly again. So 6.12 works and 6.18 doesn't, at least on my board. Is anyone else seeing this on a T6 / T6 LTS with the 6.18 current kernel? Happy to share any logs or run commands if it helps to narrow it down. Thanks!

Thank you for moving my post to the appropriate section. I apologize for posting in the wrong area initially. To reiterate my question for this General forum: I have a Skyworth TV box with a Realtek RTD1325. I am looking for any guidance on whether it is possible to run Armbian on this hardware, even experimentally. Has anyone here worked with similar Realtek-based devices, or could someone point me toward resources for building a custom image for the RTD13xx family? I understand this is outside the usual supported hardware, but any advice would be greatly appreciated. Thank you.

Hi SymbiosisSystems, Same problem like you with kernel 6.18.35 and 6.18.37, all it's Okok with 6.18.10 like I said in this post:

moved

Hi Taz! I am trying to replicate your success with booting Debian Trixie on the Teclast T60AI tablet using the Radxa OS vendor kernel (6.6.98-vendor-sun60iw2 from the Radxa-cubie-a7z-v0.6.4 build). I am very close, but I've hit a dead end with a kernel panic on the very last stage of the boot process. I would really appreciate your advice on how you bypassed this. [ 10.852267] EXT4-fs (sda28): mounted filesystem ... [ 10.866540] VFS: Mounted root (ext4 filesystem) readonly on device 259:12. [ 10.875759] devtmpfs: mounted [ 10.881784] Freeing unused kernel memory: 1920K [ 10.887909] Run /sbin/init as init process [ 16.097167] request_module: modprobe binfmt-0000 cannot be processed, kmod busy with 50 threads for more than 5 seconds now [ 16.102268] Kernel panic - not syncing: Requested init /sbin/init failed (error -8).

My fix for what I was trying accomplish, which was to run Armbian Debian with vendor kernel with nvme boot, was to install the mainline kernel change the kernel with Armbian-config and then reinstall with option 2 'Boot from MTD; system on nvme'. Installing with this option to begin with instead of trying to flash the boot loader on MTD after the fact may have been the better choice.

for that price and feature set the odroid c4/c5 and the orange pi 5 (or 5b with onboard emmc) are the usual sweet spot. if you want zigbee i'd lean toward a board with proper usb (not just the otg ports some of the cheaper ones have) so your zigbee stick gets a clean port and a decent antenna position. one thing worth saying upfront from experience: skip the sd card for anything thats writing 24/7 like home assistant's database or pihole logs, you already know this but emmc or a small ssd over usb3 will save you a ton of corruption headaches down the line. and budget a few euro for a heatsink, the rk3588 boards in particular will thermal throttle in a closed case without one. for the support angle werner's spot on, sticking to standard/platinum boards on the download page means kernel updates keep coming and you're not chasing a dead community image in a year. raspberry pi 4/5 is the boring-but-safe option if you can stretch the budget, just because the software ecosystem assumes it exists. on the software side, since youre running pihole + HA + zigbee you'll basically be living in docker, which armbian-config can set up for you. if you ever want the rest of the self-host stack (nextcloud, file sync, vpn back in) without hand-rolling reverse proxy and certs, full disclosure im involved in an open source project called syncloud thats basically a thin layer that does one-click app installs and handles https/auth/updates for you on arm boards. its not for everyone, if you enjoy wiring up nginx and docker-compose yourself you'll probably find it too hands-off, but for a set-and-forget home box it takes the fiddly parts off your plate. either way the boards above will serve you well.

Hi, thank, I forget this method. new result... same with 6.18.37: With 6.18.10-current-rockchip64 and rk3399-kobol-helios64.dtb-6.18.18-opp dtb file, Ok With 6.18.37-current-rockchip64 and overlay helios64 patch with armbian-config, Ko With 6.18.37-current-rockchip64 and k3399-kobol-helios64.dtb-6.18.18-opp dtb file, Ko more information: On "Cold Boot": System blink red After "Reset": Same crash like without DTB file patch on previous Kernel like 6.18.10... I try edge with 7.1 kernel but not compile, finish with error during process. Back to 6.18.10 with dtb file patch and freeze with this stable config and kernel for this time, I don't have time to investigate more at this time. Have a nice day

Thank you very much. Thanks to your detailed guide—as well as the one by "Chiều Nhạt Nắng"—I successfully installed Armbian on my TV box. I had struggled for a long time previously, following outdated instructions without fully understanding them; I kept unplugging and replugging the power cable, which ended up damaging the power IC (so now I have to use the USB port for power). However, thanks to your specific guidance (user 0757), I followed the steps and finally succeeded. Thank you!

Honestly, I've already forgotten what the problem was there. Most likely, I used the Armbian installer and specified where to install the distribution in the automatic image download mode. Before that, I had tried writing it manually. Besides that, I found an important nuance — if you install software through armbian-config, for example GNOME and Chromium, the Plymouth splash screen will be automatically configured at boot, and hardware video decoding will be enabled in the browser, which for some reason does not get enabled when installing manually.

moved to off-topic neither a supported device nor about Armbian.

Totally agree, too little or niche market! I 'm thinking about soldering simcard directly on these cheap minipci lte modem and use a regular usb2.0 cable, what a joke!

One thing that helped me in a similar situation was checking that the running kernel version matched the headers exactly with uname -r. A mismatch there can be really confusing. If you've recently upgraded the kernel, a reboot before installing the headers is worth trying too.

Hey guys, I just wanted some help from you regarding my X96Q. It is a 1+8GB Model with PCB Revision V1.1. It has a H313 processor but sunxi-fel reports H616. A few weeks ago I repaired the USB port of this box and I was successful in it and everything worked perfectly after that(the device booted up to android and worked perfectly) but Then I started to play with that Hidden button in AV port and I randomly clicked it and I thought it would be harmless but after that the device stuck in Red LED and didn't booted anything(possibly an EMMC Corruption). I tried Phoneix Suit first but it stuck on ram init. Then I brought a CP2102 Adapter to read the serial logs, and it turned out to be a Dram calibration errors where: Boot0 starts > Initializes The Emmc, the Board and the CPU -> Then the PMU(reported as AXP806 but physically AXP305) sets ram voltage to 1500mV -> Then it tries to Dram training -> fails and throws [...] "Read calibration error" multiple times —> keeps retrying until it gives up with "[...] Restraining final error." I investigated further and found that my emmc chip's critical sectors are corrupted. I used sunxi-fel to read the emmc and found that it fails to read after 16MB mark, means emmc got corrupted when I repeatedly pressed the AV port button. Now I tried a Armbian via sd card and it says: [...] Your Current DRAM Config isnt supported... Retrying... And keeps doing In a endless retry loop. Same for Miniarch, Armbian and many other builds... Any idea what's the problem with my box?

lsusb? Aic8800 is on USB or PCI in radxa 2f?

@KhanhDTP, I used Mangohud and it showed the GPU did go up to 1GHz in most of the time (though not all the time) and the GPU usage is ~100%. Maybe I need to test more games I did see a ~7% boost for vkmark score to ~4400

The one from MR / my previous message

So I received my USB-PD trigger board, set it to 15V and it does nothing, the situation is still the same. I also ordered a USB tester to see the voltage and amperage, basically the board never draw more than 3 to 4W With Aarch64 UEFI image with EDK2 on the SPI flash, Linux starts to boot but then fails and I get a black screen

I am encountering similar issue in Allwinner-H618 based Kickpi-K2B board. Over the time, the video play stops with frozen frame display. The freeze is caused by the audio clock drifting from the video clock over time — and that drift happens during the video segments. have you (anyone) found the solution for this?

I tried editing /boot/boot.cmd and recompiling. my changes did persist (I saw 'echo' worked) but it doesn't seem like my scsi scan trick worked. interrupting boot and just going straight into the above steps worked. so i think I need to edit boot.cmd to skip all the boot code for hc4 and just 'scan' then 'boot'. https://docs.armbian.com/User-Guide_Advanced-Configuration/

Try this google AI search instead: create overlay on armbian orangepione for Nokia 5110 / PCD8544 LCD You might also need to add to armbianEnv.txt after enabling spi-spidev root@orangepione:~# more /boot/armbianEnv.txt verbosity=1 bootlogo=false console=both disp_mode=1920x1080p60 overlay_prefix=sun8i-h3 rootdev=UUID=f39623a3-f9cf-4fa1-be36-6854d244c378 rootfstype=ext4 overlays=spi-spidev param_spidev_spi_bus=0 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u root@orangepione:~# On successful startup of spi you should have a device: root@orangepione:~# ls /dev/spidev0.0 /dev/spidev0.0 root@orangepione:~#