Active threads

After updating the edge kernel to 6.17, and then to 6.18-rc, the performance of my ODroid-N2 dropped drastically. Here are the performance test results of 7zip with different kernel versions for comparison I compile the kernel myself using the armbian build system and install the resulting .deb. '7z b' 7-Zip 23.01 (arm64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20 64-bit arm_v:8 locale=en_GB.UTF-8 Threads:6 OPEN_MAX:1024 Compiler: 13.2.0 GCC 13.2.0 Linux : 6.16.6-edge-meson64 : #1 SMP PREEMPT Tue Sep 9 17:02:41 UTC 2025 : aarch64 PageSize:4KB THP:always hwcap:8FF:CRC32:SHA1:SHA2:AES:ASIMD LE 1T CPU Freq (MHz): 1901 1897 1904 1904 1904 1904 1903 3T CPU Freq (MHz): 298% 1894 298% 1892 RAM size: 3769 MB, # CPU hardware threads: 6 RAM usage: 1334 MB, # Benchmark threads: 6 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 7244 525 1343 7048 | 136762 553 2109 11660 23: 6896 533 1317 7026 | 128222 535 2071 11092 24: 6626 539 1323 7124 | 114197 478 2096 10021 25: 6170 542 1301 7045 | 121553 536 2020 10818 ---------------------------------- | ------------------------------ Avr: 6734 535 1321 7061 | 125184 526 2074 10898 Tot: 530 1698 8979 ------------------------------------------------------------------------------------------------- 7-Zip 23.01 (arm64) : Copyright (c) 1999-2023 Igor Pavlov : 2023-06-20 64-bit arm_v:8 locale=en_GB.UTF-8 Threads:6 OPEN_MAX:1024 Compiler: 13.2.0 GCC 13.2.0 Linux : 6.18.0-rc7-edge-meson64 : #1 SMP PREEMPT Sun Nov 23 22:53:16 UTC 2025 : aarch64 PageSize:4KB THP:always hwcap:8FF:CRC32:SHA1:SHA2:AES:ASIMD LE 1T CPU Freq (MHz): 1966 1985 1732 1940 1979 1946 1486 3T CPU Freq (MHz): 64% 424 97% 641 RAM size: 3773 MB, # CPU hardware threads: 6 RAM usage: 1334 MB, # Benchmark threads: 6 Compressing | Decompressing Dict Speed Usage R/U Rating | Speed Usage R/U Rating KiB/s % MIPS MIPS | KiB/s % MIPS MIPS 22: 1045 85 1191 1018 | 20252 91 1903 1727 23: 1078 90 1218 1099 | 18815 86 1889 1628 24: 1100 93 1274 1183 | 19644 92 1880 1724 25: 914 78 1332 1044 | 19697 94 1873 1753 ---------------------------------- | ------------------------------ Avr: 1034 87 1253 1086 | 19602 91 1886 1708 Tot: 89 1570 1397 I have done similar tests on ODroid-M1 (rockchip), but nothing similar happens there. What could be the reason?

But I still need to short-circuit the TV box to be able to install anything; it's locked and I can't do anything, If you can help me, I would really appreciate it.

The problem has been solved. I installed a distribution with a different kernel, namely 6.18, and then https://github.com/shenmintao/aic8800d80.git Thanks everyone for your help.

The purpose in this guide is to make installation simple for those who wish to follow what I did. This is specifically for the Yoka TV KB2 Pro which uses the S912 chipset with 3GB RAM and 32 GB ROM. It was successful and works for setting up windows mapped drives just fine with Samba. (for example Z:\) I am using it off the SD card, I left Android 7.1 on the EMMC. Notes: My intentions are to use it for a file server for use with USB 2.0 drives I have laying around that are old but still technically usable. The file transfer speed is only expected to be around 30% of the 1GBPS wired network. The bottleneck will definitely be the USB 2.0, but for what I am using it for, it should work just fine. Leaving it on 24/7 is only slightly more power than a Raspberry PI 4, so very low cost. The Wireless and Bluetooth do not work as is, I am not sure if you can get the drivers to make them work, I did not try. The 1GBPS network port works just fine. There is also no GPU/VPU acceleration, but for a file server who cares? This was done with windows 11 and win32diskimager (note the original website is https://sourceforge.net/projects/win32diskimager/) the other links are not what you are looking for and likely viruses and malware. Balena Etcher did not like the image file, win32diskimager had no issues once I extracted the .img file. Head to https://www.armbian.com/amlogic-s9xx-tv-box/ Download the Armbian 26.2.0-trunk.22 Noble Gnome - I did not test any of the other images. Burn it to an SD card - note (it says it will only work with up to 32GB micro SD cards. My 64GB amazon micro SD card worked just fine after upgrading my Yoka TV KB2 PRO to android 7.1 earlier, go figure.) I would suggest for this get a name brand SD card that is 32GB or less (the image uses around 2GB) At the boot partition you have to rename the file u-boot-s905x-s912 to u-boot.ext Now you have to edit the /extlinux/extlinux.conf file, look for the line that says FDT /dtb/meson-something (and change it to say FDT /dtb/meson-gxm-q200.dtb save the file This lets it know what chipset/model you are using, this is for the S912 chip that is in your Yoka TV kb2 pro You will need a usb keyboard and mouse, you also have to have it plugged into an HDMI cord that runs to a monitor or TV. Now for booting it in multiboot mode - hold the reset button (between AV and HDMI ports, this button is inside and very small, google suggests a toothpick, I used a phone sim remover tool) for 10 seconds before and while powering it on, do not let go until you hit 10 seconds. Now every time you restart it, it defaults to SD card first. It may take 2 or 3 attempts, but it does work. To boot to Android, just remove the SD card. First boot username and password is root and 1234, it will force you to change the password. When it asks for bash or zsh, I chose bash because I am way more familiar with it. When it asks for locale I used en_US.UTF-8 Time zone is based on wherever you are I used America/Chicago It will also ask you to create a new user account (non-root) and a password) This should get you up and running. The button to access everything is in the upper left corner, then you can access all your apps. There are tutorials to upgrade it to android 7.1 - it does work and well documented. I upgraded mine to android 7.1 it worked just fine. Do Not try to upgrade to android 9 slimBOXtv, there are no successful attempts proven, just bricked devices. I did not see a single picture of anyone having it running. I did however see plenty of complaints for bricked devices. Good enough for me to steer clear. I know this is rather long, but it will get you through the entire process, be safe, and hope you enjoy this how-to guide.

Thanks for your help. I will stay with the bookworm image, it works, that's fine.

Edit: I'm not sure how to format nicely here... so I updated the related PR. That said, this probably isn't the best reference location for this. In any case, posting in case helpful for anyone else. If it's useful for the project to better community (and potentially automate) some of this I'm happy to get involved, but here's what I've got for now: There are fundamentally two driver paths for RK3588: libMali path - Enables NPU for ML inference, basic GPU only Panthor path - Enables full GPU acceleration, no NPU Within each path, you can choose headless or desktop (XFCE/GNOME), but: libMali + desktop = slow rendering (software only) Panthor + desktop = smooth rendering (hardware accelerated) Key insight: The NPU and GPU hardware are separate, but the software drivers conflict. You must choose which accelerator matters more for your use case. Additional constraint: Kernel matters - NPU only works on 6.1 vendor kernel. Mainline 6.12 has no NPU support but best GPU drivers. This creates a matrix of ~6 viable configurations, each optimized for different workloads (production ML, ML development, desktop, latest kernel, etc). More detailed breakdown: https://github.com/armbian/build/pull/8979#issuecomment-3587135022

Thank you, it booted on tv98 pro clone 1gb ram with assembled + 1gb ram (256x4)

Collabora will be at Embedded Software Engineering Kongress! Catch our talk as we share our expertise in training large open source models. View the full article

It might be related to Trixie (quick test is checking this on Ubuntu variant). We fix few bugs in user space - some packages were missing due to changes in their relations ... if we are talking about hardware RTC, then it is kernel related. Generic kernels usually have only basic support for most boards we are dealing with, but still, this specific function could work different or not at all. Depending of the version and time of build. Hard to say without investigation. I added battery to my N2+ a while ago and tested RTC functionality. It worked, but its a long time ago since I did that test. I will look into this when possible.

hi, @rollinglabs Have you already had a chance to play with it SBC?

Thank you, I found this information very helpful. I have modified both 10_linux and 30_os-prober in a more fancy way, inspired by AmazingFate's Rockchip Debian live CD. Here are the patches in case anyone is interested... 10_linux.patch 30_os-prober.patch

@Jeeva Kandasamy depends on which branch you are looking at? V20250306 hasn’t changed much. https://github.com/NickAlilovic/build/commits/v20250306/

@dale I had the same problem last night. Should be fixed now. Clone or update the repository. You will need to install Docker. https://github.com/NickAlilovic/build/commit/025e4487f87233bfb823c7d51162d877b2a9fd6f https://github.com/armbian/build/issues/8572

25.2.3 build fine after upgrade though I had to hold rpi-eeprom, raspi-firmware and raspberrypi-sys-mods Also still getting the Method gave a blank filename apt error

This was my original approach. I don't have the knowledge/experience to parse a script like that and is the reason I was asking here.

Hello there, I have found another problem. My setup: Monitor Samsung syncmaster 2032mw Windoze 10 reports 1280x768 60Hz T95Z plus box cpu amlogic meson(s912)arm cortex-a53 mali t820 gpu dtb used: amlogic/meson-gxm-t95z-plus.dtb everything works including WIFI. But I have overscan in the terminal and in de Cinnamon desktop I am looking for info https://docs.armbian.com/User-Guide_Advanced-Configuration/ enable a custom screen resolution whitin x.org for a resolution when i open a terminal and run xrandr --listmonitors the result is: Monitors: 1 0: +HDMI 1920x1080/90+0+0 HDMI-1 then i type cvt 1628080 1768 but the next command allready result in bash:cvt: command not found Now i am stuck here any tips?

From the serial_log.txt I can conclude that your SPI-flash must be empty, as it uses the u-boot version that is on the SD-card. So if you also don't have an eMMC attatched, that is now more simple. It is that older legacy based U-Boot, so should work with kernel 6.1.x. But kernellogging level is default set to 1, so I cannot see from the txt file what kernel it is, it might be older 6.1.x, I had lots of trouble with those. At least the 6.1.115 runs very solid on my ROCK3A now; it does all I/O I want: SPI, NVME, SATA (and SD-card as well but slot normally empty). This U-Boot: root@rock3a:~# strings /dev/mtdblock0 | grep "U-Boot SPL 20" U-Boot SPL 2017.09-armbian (May 20 2024 - 00:46:51) You can set loglevel to 7 in armbianEnv.txt (or directly on kernel commandline is more generic), then you see much more what is going on, it even might spit out info about crashing itself. A key thing for ROCK3A is to have proper PSU: Mine is never stable with whatever 5V only PSU, so also not the RPI5 PSU for example. Various U-Boot versions don't support USB-C PD, so I just soldered my own USB-C cable/connector that I connect to a 12V old car battery or some random 12V PSU that can do 2A or so. Then the onboard DC-DC converter is used to create a stable 5V etc. I don't remember how the ROCK3C should be powered, also not sure if it has own DC-DC converter onboard, so in that case it is just 5V and you are quite dependent on the quality of your PSU. If only an SD-card, it should be fine, but when PCIe is used fort NVME, I think expect freezes. Also think what you want with the ROCK3C; If you want a generic Arm64 Linux computer, you might be better off with 'edge' (both u-boot and kernel). You can't use quite some specific RK35xx features, but should be stable and easier to maintain. You can always compile/build an image yourself.

I am glad that you have the first 15% done: get your kernel module in the OS, and the uboot accepting the DTBO Now you are stuck in correcting the DTS, so that it configures the SPI pins correctly. My last advice for you (through this stage) is: make sure you don't have anything else using SPI pins. Deactivate "spi_dev" in armbian-config. Since I only had experience with H3 and H618 CPUs, I can't help with confidence. Post your question in the appropriate Rockchip forum section for up-to-date reliable advice. I can say that Radxa/Waveshare DTS is very out of date: it uses the fb_ili9486, which is "framebuffer" (poor fps), instead of the modern "DRM" display driver (high fps, will allow wayland). You should stay with that DTS with fb_ili9486, because it is still the closest starting point for you, and when you have it working, claiming all the GPIO pins needed, I can help again to use the DRM driver panel-mipi-dbi. Regarding MISO and MOSI, I only meant to change that nomenclature in the graphic that you show in the forum. I did't mean to change it in the DTS, if that's how other people make it work. Maybe you need to have the full linux source, so you can decompile the DTBO correctly, showing the gpio pin addresses or symbols. Is it possible that you get the Radxa/Waveshare original DTS?

Apologies! I managed to find another post after a while and the answer was to untick the panthor device tree! It works now, amazing!

@thanh_tan You found one armbian image to boot on Orangepi4A?

We don't deal with Android here. Ask vendor or at some place like xda developer forums.

Hi @djurny, Yes it’s nice to tinker just so busy/tired that I’m not even doing that on the Windows side anymore. Still like the helios64 and would love to bring it up and running stable when needed, was just curious if worth the effort so looking for some success stories. I only plan to use it as a handy backup device which does sound strange for something unsupported. I think I’m still on buster as well on the sd card and never had the instability issues discussed around here (I think I mostly let it run 3 or 4 days at once in the first couple of years just to see if anything happens and did not). But I do read around here every couple of weeks. Thank you for your time!

I used the latest official image for a brand new install and set up OMV afterwards. So far everything works, but I ran into the "sata-reboot" bug. That said: Once I reboot after an update for example the sata drive is not being recognized. M2 nvme does come up as usual but not the sata ssd. Only remedy: Shutdown the M1, unplug, replug power cable and this cold reboot does the trick and the sata drive comes up again properly. It seems to be a kernel bug somehow and via armbian-config I tried several kernels but the bug unfortunately persists. Any ideas?

keep pushing, this device is not brickable, you can make your trip worry-free

We don't support 3rd party forks. Ask at the place where you got this OS from.