Search the Community

SBC and embedded world is an absolute jungle, take for instance Orange Pi Zero 3 (just as an example) , it has an on board flash chip which can store a boot rom. the kernel bootloader u boot https://en.wikipedia.org/wiki/Das_U-Boot can either: boot from a normal sd card (and this depends on the vendor's boot rom, which loads the first few sectors on the sd card (which is u-boot itself) and jumps to u-boot which in turns boots linux (no uefi) u-boot can be installed in that boot rom become the BIOS ! itself, and u-boot can boot linux *directly* u-boot can practically emulate any kind of booting scheme (including the vendor's original, uefi etc) but that requires u boot to replace the vendor's boot rom (deemed a risky activity, it may brick the board) and that every different board can have different hardware configuration (a LED on a different pin or configuration (e.g. pull up or pull down) make a different board (with everything else being the same) !) the above already constitute M different boot configurations and N different boards, with just 8 pins for LEDs you can make a combination of 8! 8x7x6x5x4x3x2x1 permutations x 2 configurations (pull up or pull down) ~ 80640 different boards for the same board. so for sanity and practicality, a device tree overlay is made for a *fixed* board. e.g. Orange Pi Zero 3 and that this project is practically supporting M socs x N boards x X configurations x Y distributions (debian / ubuntu to name just 2, wrong not just 2 within that 2 there are different *releases* ) x Z kernels (legacy / stable / bleeding edge) and that is not just 3 versions, oh and just UEFI alone has another N different versions https://uefi.org/specifications 😛 btw u-boot practically achieved the *holy grail* (look ma no BIOS) http://www.haifux.org/hebrew/lectures/111/img0.html it is as hard core and bare metal as one can be. it isn't about OS being 'portable' per se, than it is about what you see in each figment (i.e. a particular board with a particular config) is just one single very narrow endpoint in the sea of infinite permutations.

Hi, okay, your workflow regarding creating an own OS image is definitely beyond my knowledge 😅. Maybe I will give it a try to create an image for the N2 via the Armbian build system. That looks quite straight forward. Maybe I just screwed up something on my system when I can not get clinfo to detect my GPU, so there is a chance that it works OOTB after fresh install... Here is the output of the command you requested: $ sudo RUSTICL_ENABLE=panfrost clinfo 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

@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,

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

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

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.

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.. ? ?

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

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

This PR enables kernel modules for various USB Gadget applications for rockchip 32 bit platforms (rk322x, rk3288) for both current 6.6 and edge 6.7 kernels. Also provides a bunch of patches to address issues with rk322x, whose peripheral mode does not really well with dwc2 driver yet. A couple of patches are self-produced after trial-and-error sessions, another pair are imported from rockchip 5.10 kernel and substitutes an older patch with a bit more refined code (see the "debounce" patch). edit: the patches addressing the rk322x issues probably are worth also for rk3318 and rk3328, since the controller is the very same with similar issues. During my tests, I quickly checked an rk3318 device and found it has the same behaviour (disconnection, system freeze, ...). I will do further tests and, in case, import the same patches for rockchip64 too. Jira reference number AR-2096 How Has This Been Tested? [x] Installed on live rk322x system, tested mass storage :heavy_check_mark:, ethernet :heavy_check_mark:, uac1/2 :negative_squared_cross_mark: [x] Installed on live rk3288 system in OTG mode, tested mass storage :heavy_check_mark:, uac1/2 :heavy_check_mark: For sake of curiosity, iperf3 run on rk322x in ethernet gadget mode: 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 [x] I have made corresponding changes to the documentation [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

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 The idea is to generate output/git_sources.json file that will contain url, branch and commit hash combo. The easiest way to generate file for all devices is to run ./compile.sh targets. Then at the time of release we will copy the output/info/git_sources.json file to config/sources/git_sources.json. Once the file is copied, the hash information from the file will be used to fetch resources for git repositories where branches are specified instead of tags or commits. There can be other ways to do this as well. I am just too tired to experiment more on the same. Raising it to be a communication starter. Jira reference number AR-2087 Based on: https://github.com/armbian/build/pull/6272 How Has This Been Tested? [ ] Tested output/git_sources.json file generation using ./compile.sh targets command [ ] Copied generated file to config/sources and modified it to use a different commit hash for 6.6 kernel. Then tested that kernel is being built from that hash instead of the latest available 6.6 kernel. 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

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

Description Add support for "i.MX8M Plus" boards from TQ-System. Use atf and uboot from https://github.com/tq-systems Add BSP packages for the tqma8mpxl family Add kernel patches (6.1 and 6.6) for the tqma8mpxl family Supported mainline kernels: current = 6.1.71 and edge=6.6.10 Supported boards: mba8mp-ras314 mba8mpxl How Has This Been Tested? [x] Build images for mba8mp-ras314 and mba8mpxl with current and edge kernel [x] Boot test "bookworm_current" and "bookworm_edge" mba8mp-ras314 [x] Boot test "jammy_current" and "bookworm_edge" mba8mpxl [x] HDMI, WLAN, USB test's mba8mp-ras314" bookworm_edge" with xfce image [x] HDMI, WLAN, USB test's mba8mpxl" bookworm_edge" with xfce image 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 [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

So I was messing around with my new OrangePi-5+ and installed the EDK2 UEFI firmware for Rockchip RK3588 platforms onto the SPI flash (/dev/mtdblock0). After which I tried all sorts of images and kernels with varying success, only the 5.10.160-legacy-rk3588 kernel would really have a working display. Until I tried a generic UEFI arm64 image (Jammy-CLI on a USB stick) which gave a working display, albeit at 1080p max. (my monitor is 4K) with no acceleration (after the extra steps), and installed the Mate desktop (just my preference). The big caveat is that it does not recognize the SD-card, EMMC or SPI-flash, just regular drives (e.g. sda/nvme0n1 etc) and I'm sure a lot of other hardware isn't properly recognized either. But all of that was fixed by simply installing the old legacy kernel with apt, making a symbolic link to the correct dtb in /boot and updating grub, and a reboot later everything worked fine, the desktop popped up in 4K with acceleration and all. In the end I installed the whole thing to an NVME with armbian-config, which didn't create the separate EFI partition, so I had to corrected it manually, but that is another story. What surprises me is that the UEFI-arm64 kernel does not seem to need a Device-Tree-Blob, in fact it doesn't even boot with its own rk3588-orangepi-5-plus.dtb. Anyway if anyone want's to try this I'd suggest using Balena etcher to write the ED2K firmware onto an SD-card, and a generic UEFI armbian to an USB stick so you won't have to mess up anything permanently. Plug the stick in a USB2 port as it chokes during boot on the USB3 (blue) ports. And you will need a lot of patience as booting from a USB2 stick will be rather slow to say the least. Install legacy kernel: sudo apt update sudo apt install linux-image-legacy-rk35xx Create the symbolic link: (If you try this on another board or with another kernel version, you will need to adjust the link for the appropriate DTB instead) sudo ln -s /usr/lib/linux-image-5.10.160-legacy-rk35xx/rockchip/rk3588-orangepi-5-plus.dtb /boot/dtb-5.10.160-legacy-rk35xx Bonus tip, set the legacy kernel as a GRUB's default: (optional, adjust for different kernels) sudo echo 'GRUB_DEFAULT="Armbian GNU/Linux, with Linux 5.10.160-legacy-rk35xx"' > /etc/default/grub.d/99-legacy.cfg GRUB should now automatically pick up on the DTB after updating: sudo update-grub So far the only downside I have found is that the audio outputs are all labeled "Built-in Audio Stereo", which was easy to solve by adding some udev-rules as the Armbian build system does when building a regular OrangePi-5+ image.

It's the memory. You'll notice that the machine with the Armbian kernels can't access more than 8-9 gigabytes. I have the same issue. The Ubuntu 5.10 kernels published by Joshua Riek work fine, not sure about Radxa's 6.1 yet. Type this into a file called test.cpp: #include <iostream> #include <vector> int main() { std::vector<unsigned char> test(29ull * 1024 * 1024 * 1024); std::cin.get(); return 0; } then launch htop in a session and type in a different session: g++ test.cpp ./a.out and watch the kernel die after 2-3 seconds when the vector gets to zeroing past the 8-9 gigabyte mark. 3 posts under this one -

Hello sugatam, I have tried all edge kernels, and built my own 6.8-rc4 kernel, but these patches does not seem to have made it into those branches yet. No cigar! I have not tried collaboras kernel yet, but that would be interesting. About your stability problems, I have only tried things like wifi, I might have observed instability, but did not connect it with the USB, but rather with wifi. I will check logs next time I observe it.... Regards, Gullik

Yeah, I tried that. The very same card works with older Linux kernels. By adding some debugging to the kernel itself, I found that MMC host never initializes fully (mmc@4020000 in device tree). All 5 attempts end after this line in the "drivers/mmc/host/sunxi-mmc.c": ret = mmc_regulator_get_supply(host->mmc); Which gets "-EPROBE_DEFER" on all 5 attempts. It looks like VMMC voltage regulator does not get initialized, not sure why. This is what I get when I check the debugfs for deferred devices: (initramfs) cat /sys/kernel/debug/devices_deferred 4020000.mmc

Dear Armbian community, We’re excited to announce the latest Armbian release,24.2, codename: Kereru! This update comes with a plethora of changes, making the Armbian experience even better. Highlights of Completed Actions Closed Projects In recent developments, we’re proud to announce the completion of several projects geared towards refining the Armbian experience. Notably, we’ve resolved DNS resolution issues associated with Debian Bookworm, ensuring smoother connectivity for users. Furthermore, our team has optimized the performance of HDMI consoles on Khadas VIM1S and VIM4 devices, alleviating previous sluggishness. Additionally, we’ve successfully tackled the complexities of Rockchip patch maintenance, streamlining operations for enhanced stability. Moreover, our hardware compatibility has been expanded with the inclusion of Xiaomi Mi10, Orangepi Zero3 and ASUS Tinker-Edge-R, broadening the range of potentially maintained devices. Lastly, users of Khadas VIM1S & VIM4 can now benefit from the latest kernel advancements with the implementation of the latest Amlogic kernel 5.15.y drop. Closed Tasks In our ongoing commitment to improving Armbian’s functionality, we’ve achieved significant milestones in various tasks. Among these accomplishments is the introduction of a new feature enabling the convenient display of download links, enhancing user accessibility. Furthermore, we’ve seamlessly integrated Odroid M1 into the rockchip64 family, ensuring a cohesive user experience across devices. Additionally, the integration of Ubuntu 24.04 Noble into our build framework provides users with expanded options for operating systems. Moreover, we’ve prioritized kernel updates, ensuring that all current kernels have been upgraded to 6.6 LTS, incorporating the latest enhancements. Furthermore, the addition of Home Assistant extensions further enriches Armbian’s functionality, while security measures such as LVM support, CRYPTROOT, and enhanced system configurations bolster system integrity. Lastly, the introduction of Cloud-init support underscores our commitment to user convenience and choice, while the inclusion of support for Radxa Rock S 0 expands device compatibility options. Solved Bugs In our ongoing efforts to provide a seamless user experience, we’ve diligently addressed various bugs and issues. Notable resolutions include rectifying network interface card failures on Orangepi One+, ensuring consistent connectivity for users. Additionally, we’ve successfully resolved issues with Edge Kernel disrupting WiFi and Bluetooth support for RockPI-S devices, restoring functionality. Furthermore, errors related to package removal and systemd unit enablement have been rectified, minimizing potential disruptions during system maintenance. Moreover, desktop compatibility issues with the Cinnamon desktop on Vim4 have been resolved, ensuring a smooth user experience across devices. Additionally, optimizations have been made to reduce image loading times on Khadas VIM1S/VIM4 Bookworm, enhancing overall system performance and responsiveness. The complete list of actions have be accessed here. Remarkable Contributors, Supporters and Partners We extend our heartfelt appreciation to the individuals who have contributed immensely to the growth and success of Armbian. Remarkable Contributors: @adeepn, @alex3d, @amazingfate, @belegdol, @brentr, @chainsx, @efectn, @EvilOlaf, @glneo, @h-s-c, @hzyitc, @iav, @igorpecovnik, @lanefu, @msdos03, @paolosabatino, @prahal, @pyavitz, @rpardini, @schwar3kat, @SteeManMI, @tdleiyao, @Tonymac32, @viraniac, @xlazom00 Support Staff: Didier, Lanefu, Rafal, Adam, Werner, and many others have dedicated their expertise and time to provide support and guidance. We also extend our gratitude to our esteemed partners. Find out more about them here. Your contributions and support are invaluable in shaping the Armbian community and its success. Thank you for your continuous support to the Armbian community! The Armbian team View the full article

Try a different SD card. I've seen with recent kernels that a lot of SD cards that I have are no longer are working, especially 64G and larger cards. It you have a high quality 16G or 32G SD card try that. I don't have this board so my suggestion may be completely wrong but it would be interesting to hear your results.