Dear Ryzer, Alas, the device tree updsate didn't change anything. Here is the process that uses a lot of CPU: 13.0 0.0 0:05.51 kworker/0:14+events_freezable_power_ Google says it is related to power state changes, and from kernel 6, power saving settings have been more aggressive in Linux, so that's why I am trying to set up a Buster-based system.

Ryzer, Thank you for your suggestions. I will try the update for the device tree, but with otg as value, the board will be a storage device for my dashcam. I am trying to get a Buster release with kernel 6.6.75 to compile under armbian build, but so far, the compilation fails because there is no availale package for base-files. I did put the file in the cache/sources folder (which worked for a bullseye version), but nothing works for the buster version. So far, the biggest progress was achieved by commenting out or adding the following in armbianEnv.txt (no updates in modules.conf, config.txt or cdmline.txt). With those updates, the drive and folders show up instantly upon activating hte gadget, I can navigate the folders, but writing is a hit and miss (using libcomposite, not g_mass_storage) #overlay_prefix=sun7i-a20 param_usb_device_mode=otg overlays=dwc2 (instead of the usual dtoverlays) With those parameters, Windows file explorer and Windows Explorer no longer crash. The top command shows 13% CPU usage for a kworker process related to power. A google search found that this may be due to a device/driver continuously requesting a power state change (conflict between drivers?). No errors in dmesg regarding dwc2. Here are the final line: [ 75.627225] loop0: detected capacity change from 0 to 83886080 [ 75.628674] loop0: p1 [ 76.067022] loop0: detected capacity change from 0 to 83884032 [ 76.519886] FS-Cache: Loaded [ 76.784125] Key type cifs.spnego registered [ 76.784185] Key type cifs.idmap registered [ 76.787080] CIFS: Attempting to mount //192.168.0.1/Tesladrive [ 76.893017] CIFS: decode_ntlmssp_challenge: authentication has been weakened as server does not support key exchange [ 78.023297] loop0: detected capacity change from 0 to 83886080 [ 78.023757] loop0: p1 [ 78.568262] loop0: detected capacity change from 0 to 83884032 [ 79.642716] Mass Storage Function, version: 2009/09/11 [ 79.642755] LUN: removable file: (no medium) and usb related lines: [ 4.097675] musb-hdrc musb-hdrc.1.auto: MUSB HDRC host driver [ 4.097739] musb-hdrc musb-hdrc.1.auto: new USB bus registered, assigned bus number 5 [ 4.115390] usb usb5: Manufacturer: Linux 6.6.75-legacy-sunxi musb-hcd [ 4.115403] usb usb5: SerialNumber: musb-hdrc.1.auto [ 20.084995] systemd[1]: Reached target usb-gadget.target - Hardware activated USB gadget.

@billymore The "Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)" error indicates that the Linux kernel could not locate or mount the root file system during startup. . This is commonly caused by a missing or corrupted initial RAM filesystem (initramfs), an incorrect root= boot parameter write 0x4ff00000 rootfs.cpio.lzma.uboot

@Jain Ziad I'm currently working on hardware acceleration, though I can't say yet if it will outperform the official Radxa builds since it uses the same drivers. I'll keep the community updated on the results.

Hello Armbian-Community! TL;DR I've successfully enabled the Rockchip RK3568 NPU (0.8 TOPS INT8) on the ODROID-M1 with 8GB RAM running Armbian 6.18.9-current-rockchip64. The only thing needed to make this work for everyone is a 1-line kernel patch in Armbian build that I've already submitted: https://github.com/armbian/build/pull/9403 Once this patch is merged into Armbian, the DKMS modules will work out-of-the-box on all RK3568 boards. The Problem 1. Hardkernel and Rockchip provide NPU patches for quite old kernel versions: rockchip <= 6.6 hardkernel <= 5.10 2. IOMMU page table allocation bug — On systems with >4GB RAM, the kernel's IOMMU allocates page tables above 4GB, but the NPU can only access the first 4GB of physical memory, causing DMA mapping failures and inference timeouts The Solution 1. Kernel Patch (1 line!) - .gfp_flags = 0, + .gfp_flags = GFP_DMA32, This forces IOMMU page tables to be allocated below 4GB, fixing NPU operation on 8GB boards. 2. DKMS Driver Package I've created a complete DKMS package that: - Includes DT overlays for NPU, IOMMU, power-domain, and clock configuration - Supports dynamic frequency scaling (100 MHz - 1000 MHz) - Provides `/dev/dri/renderD129` (DRM/GEM interface) for RKNN Runtime - Would compile against Armbian's stock kernel headers with the above patch merged The Questions 1. What would be the best way to provide those modules for installation in the armbian system? 2. Has someone a 4 GB version of the M1 and could test the modules?