All Activity

Created another version of script for this ... https://gist.github.com/avatar21/e0deca347665bd620d0ea3f9f299028e I believe we need to compile our own armbian/ Kernel 6.13 (or above? because as @elvis claimed user driver is only 1/2 of the equation) before running this script ya? all copy/ flatten to a temp/fake root folder and repackage as an img file ya? Or better still, can someone compile the whole thing? start from burning image ...

That RK356x would not be much faster than the H618 I think and "sunxi kernel" is 32-bit, I assume you use and mean 64-bit. DKMS always needs attention (in my experience), so I am happy I made/have my computers/boards such that I do not need it. actually, this topic made me do: apt purge dkms -y, as last week dist-upgrade from Bookworm to Trixie/Testing also had some issue (only a warning, not fatal) regarding DKMS. In the past I used it for some SDR hardware module, but for WiFi USB dongles I simply have a red line: If no mainline kernel integrated code, I do not use is. Also what Igor points to, that stick you have is just very low wireless performance. Use RJ45 or buy good WiFi module I would say. zfs-dkms has no hardware/vendor origin, so that is less of a problem, but note that for cheap low end SBC hardware, Btrfs also works fine and is in the Linux kernel so no special care needed. Also works fine on old ARMv6 Raspberry Pi0/1 including Zstd on-the-fly compression etc. You could create an 2-parttiton image (and U-Boot blob will be between partition table and 1st partition). Use Btrfs as rootfs and also install vanilla Debian kernel and GRUB EFI. Tag 1st as 0xEF00 (ESP) type. Then that image can run as Virtual Machine (hardware accelerated) on all ARM64 SoCs and also emulated on fast x86-64 PCs. Run armbian build inside that VM. I did that for 32-bit Allwinner as I have NanoPi-NEOs, don't have 64-bit Allwinner SoCs. So then easier experiementing and developing and you also have kernel log via virtual tty. Still make sure you have real serial cable/console for that H618.

Thanks for your help, and I found the official image not support NPU, only Joshua-Riek image support? @Hqnicolas root@h96-tvbox-3566:~# ls /dev/dri/ by-path card0 card1 renderD128

During the first few boots on my Orange Pi Zero 3 1GB, RAM size seemed to be detected correctly. Yesterday I saw RAM size being reported as 2GB, also after a reboot. As soon as the fixed U-Boot is available to install I am happy to provide test results or other test procedures when needed!

Glade to see you back @sicxnull. Thanks for the shoutout! Tried my best while you were gone. I don’t own one of these boxes. But I guess it doesn’t matter which one I get because theirs so many variations of the same box.

@Igor I have been using uboot V2025.04(2025-snuxi) on orangepi zero2w since 19 April and everything is works as it should no problems. https://github.com/ZjemCiKolege/build/commit/b3eaeb7d2059c3429951da7e6022c9528237c0e7

And I have ruled out that this is Armbian OS problem.

I try your prebuild image, and no luck with wifi/Bluetooth. My tv box new revision and have YC8800D wifi chip. Can i do something to get work WiFi?

Thanks for this!

Just checked in and am surprised this thread has gotten so much attention. Glad people have been able to use and modify the image as needed. Huge shoutout to @Nick A for all the support he's giving in here

Rockchip devices generally cannot be bricked. Short the maskrom pin i showed you and reflash. You can build the image from source or from here https://github.com/armbian/community/releases

Am also have T95Z Plus w/ H616 and my TV box new revision. It has another wifi chip YC8800D. tried to run this build https://github.com/LYU4662/t95zplus-h618-build It work fine but no wifi and Bluetooth. Looks like it made already with 8800 driver, but system does recognize any wireless interfaces. Also try to run community build Armbian-unofficial_25.05.0-trunk_Vontar-h618_bookworm_edge_6.12.11_server Its running good, but still no wifi and Bluetooth. In android /vendor/lib/modules found attached modules. Can i use them to get work wifi? aic8800_bsp.ko aic8800_btlpm.ko aic8800_fdrv.ko

Try looking for hints here: https://jellyfin.org/docs/general/post-install/transcoding/hardware-acceleration/rockchip/ They use mali blobs for hw en-/decoding.

Hi, I was not expecting someone to debug some old experimental kernel just for me. I've trying to report bug, give back something to the community. It is not build problem, so Github says use forums for that. I've spent more than a week to have latest and greatest experimental kernel (6.14.5, 6.14.8) or not so experimental (6.12.9, 6.12.23, 6.12.30) with DKMS. Did many rebuilds, reinstalls and reflashes. I was using INSTALL_HEADERS=yes in CLI args or config. DKMS drivers (zfs and aic8800) does not work. I am suspecting that problem is in sunxi headers like reported month ago in github issue. There, the same DKMS driver works on same version on the kernel on RaspiOS where it was working. When that person tried to do it on Armbian it doesn't work. If I was skillful enough I would try to fix it by myself, but I am not. Therefore I am reporting this bug here.

30-40% of GH runners we use are on arm64 platform. Compilation work in all combinations. Yes. This was lying around. Allwinner should work the same, but *edge kernels are experimental, adjust expectations. You have all tools you need, but nobody will be debugging some old experimental kernel just for you. Hint: when you generate image from sources, enable kernel headers install (i think parameter is INSTALL_HEADER=yes), so you have the one that are matching your kernel. In repository, they are probably different / not compatible. I checked if it works for latest stable (the only target that is worth spending time) kernel on supported hardware (that was around my desk). Unsupported hardware running unsupported kernel - it is expected that things will be failing.

If I understood correctly, Github job is running on amd64 platform, your test is on rockchip kernel. I am talking about sunxi kernel. Latest sunxi kernel where zfs-dkms worked (on Allwinner H618) was 6.11.2-edge. My RK356x board is on the way, but it would be nice to make this small LonganPi-3H with H618 usable

This 100% works - we are even running daily automated tests on Bookworm, Jammy and Noble. https://github.com/armbian/os/actions/runs/15362508470/job/43232345405 Manual test on Rockchip64 (Bananapi M7) with 6.12.28-current, latest kernel from daily repository. System: https://paste.armbian.com/tiwisuhugi Here is build log:

seems like the config should be distinguishing by models, not by .. idk even what it is. let say config->OrangePi2->hardware->peripherals->i2c->i2's enumerate.

Hi, I could try to help with maintenance, but first we should find where the problem is. Even if we ignore aic8800 driver (I can confirm that when it is working it is indeed shiet and there are occasional USB disconnections of WLAN card), zfs-dkms still doesn't work. Latest version where both drivers were working was 6.11.2. Currently compiling 6.11.9 to see if there DKMS drivers work. I am suspecting that kernel headers for 6.12 and later kernels are to blame

Welcome to the club Perhaps you rather help us maintaining and fixing what is possible, so I would guide you away from things that are complete waste of time. Such as this. DKMS works on Armbian, but if this (shit) driver works, that is another question. In some cases it takes years before driver become usable ... while performance still sucks. https://docs.armbian.com/WifiPerformance/#xradio-xr819 AFAIK, there are no reliable driver for aic8800. Sorry for bringing bad news ...

All the kernel panic options that you have shown here occur on v6.12.23. It all happens randomly. I suspect that this may be due to the presence of broken (faulty) blocks on the memory device. It's easy to check this.If you connect the SD card via an adapter to a Linux computer: sudo fsck.ext4 /dev/sdX1

Sometimes panic is after reboot, sometimes is after few hours of uptime. Panic1 from the previous post is while doing apt update. 2nd was while compiling zfs-dkms and 3rd I don't rember. The same Noble image works on eMMC, without panic, for now. I'll try to reproduce it with another SD card.

When you have started the device on a new operating system image, does the kernel panic appear? After what action does the core panic?

Yes in overlays i2c3-ph is on system is i2c-1 on OZPI v2/3 boards on pins 3 and 5 So you can check connected devices on pins 3 and 5 i2cdetect -y 1

I had this plan on utilizing the Radxa Rock 5 ITX+ as a Moonlight client device to stream games from my desktop computer to my living room TV, and using my 8BitDo Ultimate controller to play. On paper, the board has all the bells and whistles needed to do it, but I am having trouble getting hardware decoding of H264 and/or HEVC to work as expected. From what I gather, I need mesa-vpu support, but the documentation I find is very scattered, and repositories that once held the needed resources are no longer available. I am currently running Armbian_25.DBhsHKsx.2.2_Rock-5-itx_bookworm_vendor_6.1.99_cinnamon-backported-mesa_desktop.img (build date 21st of February, 2025), downloaded from Armbian.com. Hardware decoding does however not work, despite it being marked with "backported mesa". I've been at this for two weeks now with different images, including Armbian and Radxa OS, even going so far as trying to build Armbian myself from scratch. The image I am currently using is however the most stable I have experienced so far. Am I missing something? How do I get hardware decoding to work? Edit: Link to armbianmonitor output