Search the Community

Description As per title. How Has This Been Tested? [ ] Build test at CI Checklist: [ ] My changes generate no new warnings View the full article

@usual user Thank you very much for taking the time for the description! Honestly I must confess that I am not that deep in all this kernel build stuff that I would dare to build my own distro 🙈. I followed another guide and now my clinfo looks different but still not good. It seems that it has detected three OpenCL profiles, but still no entire GPU (driver): Number of platforms 3 Platform Name ARM Platform Platform Vendor ARM Platform Version OpenCL 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58 Platform Profile FULL_PROFILE Platform Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_subgroups cl_khr_create_command_queue cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory Platform Extensions function suffix ARM Platform Name rusticl Platform Vendor Mesa/X.org Platform Version OpenCL 3.0 Platform Profile FULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions with Version cl_khr_icd 0x400000 (1.0.0) Platform Numeric Version 0xc00000 (3.0.0) Platform Extensions function suffix MESA Platform Host timer resolution 0ns Platform Name Clover Platform Vendor Mesa Platform Version OpenCL 1.1 Mesa 22.3.6 Platform Profile FULL_PROFILE Platform Extensions cl_khr_icd Platform Extensions function suffix MESA Platform Name ARM Platform Number of devices 1 Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Device Name <printDeviceInfo:0: get CL_DEVICE_NAME size : error -6> Device Vendor ARM Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Device Vendor ID <printDeviceInfo:2: get CL_DEVICE_VENDOR_ID : error -6> Device Version OpenCL 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58 Driver Version 2.0 Device OpenCL C Version OpenCL C 2.0 git.c8adbf9.122c9daed32dbba4b3056f41a2f23c58 Device Type GPU Device Profile FULL_PROFILE Device Available Yes Compiler Available Yes Linker Available Yes Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max compute units <printDeviceInfo:32: get CL_DEVICE_MAX_COMPUTE_UNITS : error -6> Available core IDs (ARM) <printDeviceInfo:33: get CL_DEVICE_COMPUTE_UNITS_BITFIELD_ARM : error -30> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max clock frequency <printDeviceInfo:40: get CL_DEVICE_MAX_CLOCK_FREQUENCY : error -6> Device Partition (core) Max number of sub-devices 0 Supported partition types None Supported affinity domains (n/a) Max work item dimensions 3 Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max work item sizes <printDeviceInfo:62: get number of CL_DEVICE_MAX_WORK_ITEM_SIZES : error -6> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max work group size <printDeviceInfo:63: get CL_DEVICE_MAX_WORK_GROUP_SIZE : error -6> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Preferred work group size multiple (kernel) <getWGsizes:1950: create context : error -6> Preferred / native vector sizes char 16 / 4 short 8 / 2 int 4 / 1 long 2 / 1 half 8 / 2 (cl_khr_fp16) float 4 / 1 double 0 / 0 (n/a) Half-precision Floating-point support (cl_khr_fp16) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Single-precision Floating-point support (core) Denormals Yes Infinity and NANs Yes Round to nearest Yes Round to zero Yes Round to infinity Yes IEEE754-2008 fused multiply-add Yes Support is emulated in software No Correctly-rounded divide and sqrt operations No Double-precision Floating-point support (n/a) Address bits 64, Little-Endian Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Global memory size <printDeviceInfo:108: get CL_DEVICE_GLOBAL_MEM_SIZE : error -6> Error Correction support No Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Max memory allocation <printDeviceInfo:114: get CL_DEVICE_MAX_MEM_ALLOC_SIZE : error -6> Unified memory for Host and Device Yes Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Shared Virtual Memory (SVM) capabilities <printDeviceInfo:117: get CL_DEVICE_SVM_CAPABILITIES : error -6> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Shared Virtual Memory (SVM) capabilities (ARM) <printDeviceInfo:118: get CL_DEVICE_SVM_CAPABILITIES_ARM : error -6> Minimum alignment for any data type 128 bytes Alignment of base address 1024 bits (128 bytes) Preferred alignment for atomics SVM 0 bytes Global 0 bytes Local 0 bytes Max size for global variable 65536 (64KiB) Preferred total size of global vars 0 Global Memory cache type Read/Write Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Global Memory cache size <printDeviceInfo:139: get CL_DEVICE_GLOBAL_MEM_CACHE_SIZE : error -6> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Global Memory cache line size <printDeviceInfo:140: get CL_DEVICE_GLOBAL_MEM_CACHELINE_SIZE : error -6> Image support Yes Max number of samplers per kernel 16 Max size for 1D images from buffer 65536 pixels Max 1D or 2D image array size 2048 images Base address alignment for 2D image buffers 32 bytes Pitch alignment for 2D image buffers 64 pixels Max 2D image size 65536x65536 pixels Max 3D image size 65536x65536x65536 pixels Max number of read image args 128 Max number of write image args 64 Max number of read/write image args 64 Max number of pipe args 16 Max active pipe reservations 1 Max pipe packet size 1024 Local memory type Global Local memory size 32768 (32KiB) Max number of constant args 8 Max constant buffer size 65536 (64KiB) Max size of kernel argument 1024 Queue properties (on host) Out-of-order execution Yes Profiling Yes Queue properties (on device) Out-of-order execution Yes Profiling Yes Preferred size 2097152 (2MiB) Max size 16777216 (16MiB) Max queues on device 1 Max events on device 1024 Prefer user sync for interop No Failed creating base context during opening of kernel driver. Kernel module may not have been loaded Profiling timer resolution <printDeviceInfo:195: get CL_DEVICE_PROFILING_TIMER_RESOLUTION : error -6> Execution capabilities Run OpenCL kernels Yes Run native kernels No printf() buffer size 1048576 (1024KiB) Built-in kernels (n/a) Device Extensions cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_subgroups cl_khr_create_command_queue cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory Platform Name rusticl Number of devices 0 Platform Name Clover Number of devices 0 NULL platform behavior clGetPlatformInfo(NULL, CL_PLATFORM_NAME, ...) ARM Platform clGetDeviceIDs(NULL, CL_DEVICE_TYPE_ALL, ...) Success [ARM] Failed creating base context during opening of kernel driver. Kernel module may not have been loaded clCreateContext(NULL, ...) [default] <checkNullCtx:4108: create context with device from default platform : error -6> clCreateContext(NULL, ...) [other] <error: no devices in non-default plaforms> Failed creating base context during opening of kernel driver. Kernel module may not have been loaded clCreateContextFromType(NULL, CL_DEVICE_TYPE_DEFAULT) <checkNullCtxFromType:4160: create context from type CL_DEVICE_TYPE_DEFAULT : error -6> clCreateContextFromType(NULL, CL_DEVICE_TYPE_CPU) No devices found in platform Failed creating base context during opening of kernel driver. Kernel module may not have been loaded clCreateContextFromType(NULL, CL_DEVICE_TYPE_GPU) <checkNullCtxFromType:4160: create context from type CL_DEVICE_TYPE_GPU : error -6> clCreateContextFromType(NULL, CL_DEVICE_TYPE_ACCELERATOR) No devices found in platform clCreateContextFromType(NULL, CL_DEVICE_TYPE_CUSTOM) No devices found in platform Failed creating base context during opening of kernel driver. Kernel module may not have been loaded clCreateContextFromType(NULL, CL_DEVICE_TYPE_ALL) <checkNullCtxFromType:4160: create context from type CL_DEVICE_TYPE_ALL : error -6> ICD loader properties ICD loader Name OpenCL ICD Loader ICD loader Vendor OCL Icd free software ICD loader Version 2.2.14 ICD loader Profile OpenCL 3.0 My system is Armbian bookworm on an ODROID N2+ (Mali-G52). Do you have any idea about a workflow how to get OpenCL running properly? What driver (ARM, HK...), what to copy, what to compile, where to copy... Thank you!

Hello, I will use the NanoPC-T6 for a micro server. The main thing it will run on is LibreNMS (currently my LibreNMS is on a NanoPi R6S) I will also use ZFS, tftp, bond, vlan and others. The reason I use the NanoPC-T6 is the 16GB ram as well as the PCIe slot. I am attaching 2 pictures if anyone is curious about what I have created. It's not very pretty, but it's functional. What I have further configured in /boot/armbianEnv.txt verbosity=7 - I prefer to see the OS loading extraargs=net.ifnames=0 biosdevname=0 consoleblanl=0 brd.rd_nr=0 mitigations=off brd.rd_nr=0 stops all Ram Block Devices mitigations=off - this is on an internal network and since I don't know if I'll lose performance I just stop everything console=serial - console output only serial port docker_optimizations=off - I don't use docker I only use the memory card for /boot The OS is on the SSD in raid1 (about 16GB), the rest is raid1 in a zfs array, for 3 pools (mysql, librenms, storage) I have installed ZFS like this: apt install linux-headers-vendor-rk35xx zfsutils-linux zfs-dkms zfs-zed From the kernels offered by Armbian 5.10, 6.1 and 6.8, I use 6.1 I removed the network-manager wpasupplicant packages, instead of network-manager I use ifupdown2 The control of the fan is through the dts file. The steering has 5 levels. 1st degree is at 50 degrees, then 2nd degree - 60 and so on With installed fan and stress-ng more than 55 degrees I can not lift. At linux-image-vendor-rk35xx_24.5.0-trunk.226_arm64 ZFS - compiles normally. governor - on CPU works, has all modes of operation governor for dmc, gpu and npu - only ondeman. Network cards work normally. FAN - management through the dts file works normally. At linux-image-vendor-rk35xx_24.5.0-trunk.231_arm64 Installed from apt dist-upgrade, ZFS doesn't compile, had to do aptitude reinstall zfsutils-linux zfs-dkms zfs-zed governor - on CPU works, has all modes of operation governor at dmc, gpu and npu - , has all modes of operation Network cards work normally. FAN - management through the dts file works normally. On this build, one core is constantly at 100% (probably ZFS, but not sure about top and htop doesn't show which one is causing the IO) I am using the 13.03 image, in this version in install linux-headers does not work, I installed it by hand. While writing this I saw in armbian-config that there is already a version linux-image-vendor-rk35xx_24.5.0-trunk.244_arm64 but I can't find what is fixed and will wait for it to appear with apt. I have further increased the size of /boot to 2GB like this: aptitude install fatresize umount /boot/ fatresize -v -p -s 2G /dev/mmcblk1p1 mount -a Before using armbian kernel I had compiled 6.1 with these optimizations. General setup ---> Preemption Model (Voluntary Kernel Preemption (Desktop)) ---> No Forced Preemption (Server) General setup ---> Compiler optimization level (Optimize for performance (-O2)) ---> Optimize for performance (-O2) Kernel Features ---> Timer frequency (300 HZ) ---> (X) 100 HZ As a positive effect, the system is a little more "agile". Negative effect, slightly warmer is the housing of the box. What I would like fixed. My version of NanoPC-T6 is 16GB ram and 256GB internal disk. In this case I don't see the internal disk. The other thing I want is to keep the old versions of the kernel. Currently, when I install a new version of the kernel, the old version of the kernel is uninstalled, and if the OS does not start, I have to do everything from the beginning. It could be a setting, but I can't find where it is. Regarding what I used like FAN, PCIe to Sata and SSD cage, I don't know if it is allowed to post links, not to be considered as advertising. I hope this is useful to someone. Regards,

Hi all, Just want to share this issue i came across from my recently purchased OPI5+ 32GB version. I noticed it freezes when transferring .img from micro SD card to eMMC or NVMe drives via the command line. Now the img file are armbian OS and no its not the img file issue. at times I can get it to around 70seconds and it will freeze. hard reboot is required, unable to complete the transfer. I have also tried to reduce the bs=10 speed but still the same. Now i have also got the 16GB version and this works fine with no issues... Good chance there is something wrong with this latest hardware.. ? ?

Yes. Both kernels vendor and edge have pros and cons. Usually switching is possible via armbian-config.

Description As per tittle. How Has This Been Tested? [ ] Build test, will run smoke tests right after too. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

WSL2 "boards" wsl2-x86/wsl2-arm64 with current (6.1.y) and edge (6.6.y) kernels with Microsoft patches WSL2 "boards" wsl2-x86/wsl2-arm64 with current (6.1.y) and edge (6.6.y) kernels with Microsoft patches tl,dr: add 4 small-ish UEFI-like kernels, with Microsoft patches & fixes, for use with Microsoft WSL2 on x86/arm64 and 6.1.y/6.6.y the boards are UEFI derivatives, using a common microsoft vendor include to modify KERNELPATCHDIR/LINUXFAMILY (for now, we don't want those patches in regular UEFI builds / .debs) disable EXTRAWIFI (kernel is for a VM, will never have wifi so doesn't need any drivers) LINUXCONFIG, so we can use Microsoft's own monolithic kernel, required for WSL2 (their initrd is a mistery) really, what we're mostly interested right now are the kernels (in the future we might have an "Armbian" WSL2 app in the Microsoft Store) current 6.1.y: rebased from https://github.com/microsoft/WSL2-Linux-Kernel/tree/linux-msft-wsl-6.1.y onto real 6.1.y using Microsoft's .config exactly (monolithic, there are no =m's) edge 6.6.y: also from https://github.com/microsoft/WSL2-Linux-Kernel/tree/linux-msft-wsl-6.1.y but rebased onto 6.6.y using updated Microsoft's .config (monolithic, there are no =m's) dropped 2 of 6.1.y's patches that were actually upstreamed in the meantime: mm-page_reporting-Add-checks-for-page_reporting_order-param - mainlined in https://lore.kernel.org/all/1664517699-1085-2-git-send-email-shradhagupta@linux.microsoft.com/ hv_balloon-Add-support-for-configurable-order-free-page-reporting - mainlined in https://lore.kernel.org/all/1664517699-1085-3-git-send-email-shradhagupta@linux.microsoft.com/ drop the arm64: hyperv: Enable Hyper-V synthetic clocks/timers patch, since it causes asm breakage on 6.6.y a shame, but I tried and can't fix it myself - @kelleymh ? add my own patch to fix: 1709-drivers-hv-dxgkrnl-restore-uuid_le_cmp-removed-from-upstream-in-f5b3c341a.patch due to https://lore.kernel.org/all/20230202145412.87569-1-andriy.shevchenko@linux.intel.com/ landing in 6.6 1710-drivers-hv-dxgkrnl-adapt-dxg_remove_vmbus-to-96ec29396-s-reality-void-return.patch to adapt to https://lore.kernel.org/all/TYCP286MB2323A93C55526E4DF239D3ACCAFA9@TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM/ wsl2: detect Armbian-built wsl2 kernel as well as Microsoft's default kernel previous commit introduces Armbian wsl2 kernels, might as well detect them View the full article

Did you test that image ? None of the Armbian built 6.6.x (x >8) kernels (downloadable on beta.armbian.com) are stable on my system. They all seem to have the same issue.

I now use some uboot settings analogous to what you propose on the base of archinux configuration. But as you said value coded in uboot spi have to be changed when you update the kernel. This is the purpose of not storing kernel dependent values in the spi, but loading them from the device, like it is done in ArmbianEnv.txt or in archlinux in /boot/uEnv.txt. What I still does not understand is while the itb image, gives an error when trying to bootm from it. I agree that chaining UEFI bootloader should be a more flexible option, after updating the kernel it is very easy to do an update-grub, and let it generate the initrd and new grub code. And you don't have to touch the uboot itself. I have to learn more about uboot UEFI, before being able to try this option. I have never used the bootflows, so I have to learn. I have seen an interesting thread on the boot process in this forum in The boot process and various devices , beginning by a good summary by @ManoftheSea @bschnei you seem to have expertise in uboot, you should contribute to Armbian. Armbian is not to be despised, its strength is the maintenance of many sbc kernels that are not available in Debian or archlinux. And they have developed a build system that allow the update of so many device, a task out of reach of an individual alone.

Dear Armbian Community, Here are the latest news! With each new Armbian release, we bring you plenty of improvements. However, we also encounter some new bugs along the way. While some are our own doing, most come from various sources. Much of the software we distribute is common and maintained by third parties upstream, with our main focus on single board computers. Challenges and Improvements During the first week after the release, we faced some problems with the package repository. Our system is highly automated, but sometimes things don’t go smoothly. While trying to improve things, we accidentally caused a delay in updates for two weeks. We’re working hard to fix these issues and make our processes smoother for the future. Rockchip Kernel Developments We’ve been busy improving Rockchip vendor kernels, and we’re currently working on porting and testing their new 6.1.y release. KDE Plasma Desktop Integration Even though we were in the final stages of our release cycle, we managed to include the brand new release of the KDE Plasma desktop. Now, all supported boards come with KDE Plasma Neon v6.1 desktop images, based on the Ubuntu package base. These images offer the latest stable Armbian kernels and LTS package base, without the bloatware or Snap, giving you the best desktop experience. Documentation Enhancement Initiative We’re committed to improving our documentation. We’ve updated our Pull Request templates to make it easier for people to contribute. If you’re interested in helping us improve our documentation, join our upcoming Documentation Follow-up Meeting for more collaboration. Stay tuned for more updates and improvements! The Armbian team. View the full article

Description Bumped Allwinner kernels. legacy - 5.15.137 -> 5.15.139 current - 6.1.62 -> 6.1.63 edge - 6.6.1 -> 6.6.2 Updated ov5640 camera patches to fix patch application failure. Also rebased the config files. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [X] Both 32-bit and 64-bit kernel builds fine. [X] Tested 32-bit kernel on NanoPi Duo2(H3). All 3 kernels seems to work fine. [X] Tested ov5640 camera with current and edge kernels. Autofocus didn't worked for me, but its possible that I might have damaged my camera by placing something on it. Have to retest with an older kernel later to make sure. But video capture worked fine. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Nicely done! Yes, I would encourage you to customize variables and bootcmd to suit your specific purpose and avoid using the confusing and bloated scripts/commands that are often found in the default settings. Yes, you are right, boot.scr overwrites the root kernel parameter. Do you know if you were using UUID before to boot? I've found the /dev names to be stable especially if it's mmc. There is the possibility for problems if you use both USB and SATA drives for example, but unless that is your case I would probably just use the /dev device name. Arch Linux ARM has some much simpler u-boot settings you could probably use/adapt for your situation: https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-espressobin/uEnv.txt By default u-boot runs the value of bootcmd. So for example, a simpler approach like this could work for you: get_images=ext4load mmc 0:1 $kernel_addr_r boot/Image && ext4load mmc 0:1 $fdt_addr_r boot/${fdt_name} get_ramdisk=ext4load mmc 0:1 $initrd_addr boot/uInitrd bootargs=console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p1 rw rootwait bootcmd=mmc dev 0; if run get_images; then if run get_ramdisk; then booti $kernel_addr_r $initrd_addr $fdt_addr_r; else booti $kernel_addr_r - $fdt_addr_r; fi; fi Saving the values you want (and that you have confirmed work) to permanent storage with saveenv will then bypass boor.scr and armbianEnv.txt entirely. Be warned that this does have tradeoffs though because if Armbian developers decide they want to change the location/name of the kernel (for example) or any of the other values you have coded into a u-boot environment variable then a simple upgrade could mean boot fails again until you go and figure out what was done. Having seen how Arch does things and here how Armbian does things for these devices, my opinion is that both are super clunky. Modern U-Boot supports EFI stub booting so that's the approach I use. The result is: => printenv arch=arm baudrate=115200 board=mvebu_armada-37xx board_name=mvebu_armada-37xx bootcmd=bootflow scan bootdelay=2 cpu=armv8 ethact=ethernet@30000 ethprime=eth0 fdt_addr_r=0x6f00000 fdtcontroladdr=3faf8900 filesize=722 kernel_addr_r=0x7000000 loadaddr=0x6000000 netdev=eth0 pcb_rev=1.2.0 pcb_sn=CPE-2247-000050 ramdisk_addr_r=0xb000000 soc=mvebu stderr=serial@12000 stdin=serial@12000 stdout=serial@12000 vendor=Marvell and then I can use systemd-boot (or GRUB or whatever) to manage where kernels get installed, which get booted, etc. I wanted to be able to update the device kernel remotely (without having to use the USB console). Needing to change u-boot settings at all is problematic for that situation. With EFI boot there's also no need to load an initramfs nor a device tree to memory either, though there can be use cases (e.g. full disk encryption) where you would still need an initramfs.

Description In the tittle. How Has This Been Tested? [ ] Build test View the full article

Description These are dead kernels with no ties to either vendor or mainline support. Remove patchsets to reduce clutter and confusion for any/all future contribution. (Example: Fixes should be posted to all LTS and current stable mainline kernel, not to these dead ones) How Has This Been Tested? Kernels have to be manually selected be editing config files, they aren't being used in the build system itself, any niche use for them can be accomplished by pulling them from history by the user. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

The quick fix is to use armbian-config to go back to the older working kernel, and then freeze kernel updates.

Description As per description. How Has This Been Tested? [x] Patch test Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Description Legacy - 5.15.135 -> 5.15.137 Current - 6.1.57 -> 6.1.60 How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [X] Both 32-bit and 64-bit Kernel builds [X] Booted on Orange Pi Zero, Orange Pi 3-LTS Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Hello. Recently I noticed the buster and bullseye sources were removed. Is that mean Armbian buster and bullseye EOL? However I can't find any news about this. If they are EOL, is there anyone able to give me a URL to find their archives? Because of my devices' hardware, their OS's kernels can't be upgraded. (AML S805 with Nand flash) cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com buster main buster-utils buster-desktop

IT'S FINALLY HERE... THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons). I. Installation Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es". II. Features Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K). - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV. ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed. III. Sources This is the list of the sources used for the packages: IV. FAQ ¿Why did you use Debian Buster as a base for this implementation? It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal. ¿Why Legacy instead of Mainline? This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels. ¿Will you add new features to this implementation? No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

Mine freeze randomly on pi 5 plus. Let say freeze once a week, but I can still get control with ssh and reboot. I guess this is the best we can get with voluntary support . So would rather thanks all the ones giving us a not so bad working system. The question I would ask is how to diagnose the cause of a kodi freeze? What should be run before the freeze? After the freeze?

@FuSan The recommended way to switch kernels.in Armbian is through armbian-config

@FuSan So, you have kernel 6.1.x running on your Armbian install. The driver for RTL8821CS chip was added in version 6.3 or 6.4 in the mainline kernel. You can change to a kernel with version 6.6 or later. Try searching for 'linux-image-rockchip64' using apt search command and install that kernel. I usually prefer the edge kernels because I like to stay on the bleeding edge Then, also install 'armbian-firmware-full' because it has firmware blobs to enable both wifi and bt for 8821cs.

Description Legacy - 5.15.134 -> 5.15.135 Current - 6.1.56 -> 6.1.57 Edge - 6.5.6 -> 6.5.7 Config refreshed using rewrite-kernel-config How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [X] All patches apply fine, builds fine, and seems to work fine as well. Checklist: [ ] My code follows the style guidelines of this project [ ] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [ ] I have made corresponding changes to the documentation [ ] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

Armbian still support this way. I verified yesterday on Ubuntu Jammy derivative. Just add some command like touch /run/test following by reboot, login and see if file was created at /run I suggest you to use previous build (or latest but choose 5.4 from armbian config -> old kernels menu), freeze kernel upgrade and enjoy. I am not sure at this point what we will do with this kernel. If Hardkernel stop maintaining it, we might need to roll back to 5.4.y. I know. We are trying best to take that pain away. Also this way: https://github.com/armbian/os?tab=readme-ov-file#latest-smoke-tests-results but problem is that all this costs a lot of time and we have to cover this from our own pockets almost entirely. Even doing it for everyone, also for our competitors that only wants you (our users) but not our costs of software support.

At least for legacy kernels, it possible to use Radxa's overlay for the 25W PoE hat. This should allow you to use the PWM fan on the PoE hat. #!/bin/bash # Install linux headers apt-get install -y linux-headers-legacy-rk35xx # Download and compile the device tree overlay h=/usr/src/linux-headers-$(uname -r) wget https://raw.githubusercontent.com/radxa/overlays/f2679399887b678dec62cb50cb44c767a2bcb293/arch/arm64/boot/dts/rockchip/overlays/rock-5b-radxa-25w-poe.dts cpp -nostdinc -I $h/include -I $h/arch -undef -x assembler-with-cpp rock-5b-radxa-25w-poe.dts | dtc -I dts -O dtb -o rock-5b-radxa-25w-poe.dtbo # Install device tree overlay mkdir -p /boot/overlay-user mv rock-5b-radxa-25w-poe.dtbo /boot/overlay-user echo 'user_overlays=rock-5b-radxa-25w-poe' >>/boot/armbianEnv.txt