All Activity

Yeah fan working on :- https://github.com/radxa-build/rock-5b-plus/releases/download/rsdk-b2/rock-5b-plus_bookworm_kde_b2.output.img.xz

Nicely done 👍 I remember dealing with similar problems when I upgraded my desktop to an nvme drive. I transferred the partition to the new drive but the OS would not boot from it due to nvme modules being missing.

@Igor @belegdol I was able to get it working, but maybe this can be fixed in the build? Fix: Odroid XU4 – Armbian-unofficial_25.11.0-trunk_Noble_6.6.108 fails to boot from SATA after nand-sata-install Problem After running nand-sata-install on an Odroid XU4 (kernel 6.6.108), the system copies to SATA correctly but fails to boot afterward, dropping into the initramfs shell. Checking the loaded modules shows only: usbhid meaning no USB or SCSI drivers are available to detect /dev/sda1. Inspecting the initramfs with: lsinitramfs /boot/initrd.img-6.6.108-current-odroidxu4 | grep usb reveals that usb-storage.ko, uas.ko, and other USB mass-storage modules are missing. Root Cause The file /etc/initramfs-tools/initramfs.conf already had: MODULES=most so the base configuration was fine. However, Armbian’s initramfs build process did not automatically include the USB/SCSI modules, because the system was booted from SD and those drivers were not "in use" during image generation. As a result, the cloned SATA system lacked the drivers needed to mount its root filesystem. Solution Fix the SD card initramfs before running nand-sata-install. This ensures the SATA copy inherits a working image with all required modules. 1️⃣ Boot from SD and verify Confirm you are booted from SD: df -h / You should see /dev/mmcblk0p* as /. 2️⃣ Verify initramfs configuration Open /etc/initramfs-tools/initramfs.conf and confirm it contains: MODULES=most 3️⃣ Add required USB and SCSI modules Create or edit /etc/initramfs-tools/modules: USB host + storage + SCSI stack for SATA boot usbcore usb-common ehci-hcd ehci-platform ehci-fsl fsl-mph-dr-of xhci-hcd xhci-pci xhci-plat-hcd scsi_mod sd_mod sg uas usb-storage 4️⃣ Rebuild the initramfs and regenerate uInitrd sudo update-initramfs -c -k $(uname -r) cd /boot sudo mkimage -A arm -O linux -T ramdisk -C none -n uInitrd -d initrd.img-$(uname -r) uInitrd sync 5️⃣ Verify the new initramfs lsinitramfs /boot/initrd.img-$(uname -r) | grep usb/storage Expected output (partial): .../usb-storage.ko .../uas.ko .../ums-*.ko 6️⃣ Reboot from SD to confirm it works sudo reboot If it boots normally, the rebuilt initramfs is valid. 7️⃣ Run nand-sata-install sudo nand-sata-install Select your SATA target. Because the SD image is now fixed, the SATA copy will contain a working initramfs. 8️⃣ Update boot.ini Edit /media/mmcboot/boot.ini and set: setenv rootdev "UUID=<your SATA UUID>" 9️⃣ Reboot and verify SATA root df -h / Expected result: /dev/sda1 → / /dev/mmcblk0p1 → /media/mmcboot Result ✅ SATA boots successfully ✅ Kernel loads usb-storage, uas, sd_mod, scsi_mod early ✅ / mounts from SATA cleanly — no initramfs prompt ✅ nand-sata-install works correctly on Odroid XU4 (Noble 6.6.108) Summary Even though MODULES=most was already set, the USB/SCSI stack was not automatically included in the initramfs when booting from SD. Manually listing the required modules in /etc/initramfs-tools/modules before rebuilding ensures the image contains usb-storage.ko, uas.ko, and related drivers. Once rebuilt, both SD and SATA boots work reliably.

ls /lib/modules/$(uname -r)/kernel/ arch block crypto drivers fs kernel lib mm net sound Not sure why @belegdol stuff is under usr/lib/modules?

@IgorI'm back from the brink. New job, new house build 3 hurricanes. I'm still working on my 1 acre lot to clean up the vines and stuff, but I'm starting to have more time for this kind of stuff. I need to get all my old boards up to date, hahaha

@belegdol This is from an image I built, but even the downloaded one wouldn't work with nand-sata-install. lsinitramfs /boot/initrd.img-6.6.108-current-odroidxu4 | grep usb usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/hid/usbhid usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/hid/usbhid/usbhid.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/host usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/host/ehci-fsl.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/host/fsl-mph-dr-of.ko usr/lib/systemd/network/73-usb-net-by-mac.link usr/lib/udev/rules.d/50-usb-realtek-net.rules

An `armbian-plymouth-theme` package must be installed to make it worked in the latest (6.x ???) kernels. Steps: 1. `sudo nano /boot/armbianEnv.txt` and adjust/add following line `bootlogo=true` 2. `sudo apt install armbian-plymouth-theme` 3. sudo reboot 4. Check plymouth or/and armbian-plymouth-theme documentation for more customizations

Both Debian 12 and Debian 13 use Wayland by default for the GNOME desktop environment. However, X11 also remains an available option in the login manager, allowing you to choose between the two. Wayland is a communication protocol that specifies the communication between a display server and its clients. A display server using the Wayland protocol is called a Wayland compositor, because it additionally performs the task of a compositing window manager. The aim of Wayland is replacing the X Window System (Also known as X11, or Xorg) with a modern, secure, and simpler windowing system xrandr is used on top of X.org, that's why it doesn't work on a debian that uses Wayland.

Seeking SKW (SWT6621 / EA6521) SDIO Wi-Fi driver source or Linux 6.x port Hi all, I’m running Nick's Armbian-unofficial_25.05.0-trunk_Tanix-tx6s-axp313_bookworm_edge_6.12.11_server.img.xz on a TV box that originally shipped with Android using kernel 5.15 AIDA64 run on Android gives: System Device Type: TV Manufacturer: Oranth Model: TX68 Brand: ADT-3 Board: exdroid Device: adt3 Hardware: sun50iw9p1 Platform: apollo Product: adt3 Installed RAM: 4 GB Total Memory: 3891 MB Available Memory: 2512 MB Internal Storage Total Space: 54.22 GB Internal Storage Free Space: 52.57 GB Bluetooth Version: 4+ Wi-Fi works perfectly under Android, but not under Armbian — the onboard Wi-Fi chip (connected over SDIO) is a SeekWave SWT6621, also known as SKW or EA6521. From the Android side, I can see the driver is provided in binary form via: /vendor/bin/hw/android.hardware.wifi-service-lazy /vendor/etc/init/init.wlan.common.rc /vendor/etc/firmware/SWT6621*_SDIO.bin and the kernel logs show active skw_scan and skw_dump_survey messages when Android is running. However, when booting Armbian, wlan0 never appears — only eth0 and virtual interfaces. This strongly suggests that the SKW SDIO driver needs to be rebuilt or ported for kernel 6.x. What I’m looking for: Has anyone already ported or rebuilt the SKW (SWT6621 / EA6521) SDIO driver for Linux 6.x / Armbian? If so, could you please share your source, patches, or build instructions? If the work is in progress, I’d be very happy to help or test — I have the Android image and full /vendor contents available for reference. Any leads on SeekWave source releases, OEM SDKs, or community ports would be greatly appreciated. Thanks in advance for any guidance — I’d rather reuse or help finish existing work than start from scratch if someone has already begun tackling this. Best Regards John

Hi @Igor, I was looking at configng repo and I found this issue: https://github.com/armbian/configng/issues/225. I think that's why I could not find a place to create the sway section in the desktop. In the same I found this in not being planned yet to be made, if ever. Should I look at the Armbian build and try there instead?

What does lsinitramfs say? Is the usb_storage in? This is how it looks here: $ lsinitramfs /boot/initrd.img-6.6.108-current-odroidxu4 | grep usb usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/hid/usbhid usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/hid/usbhid/usbhid.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/i2c/busses/i2c-tiny-usb.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/aqc111.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/asix.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/ax88179_178a.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/catc.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/cdc_eem.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/cdc_ncm.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/ch9200.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/dm9601.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/int51x1.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/kaweth.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/lan78xx.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/mcs7830.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/pegasus.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/rndis_host.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/rtl8150.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/smsc75xx.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/smsc95xx.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/sr9700.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/net/usb/sr9800.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/host usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/host/ehci-fsl.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/host/fsl-mph-dr-of.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/uas.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-alauda.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-cypress.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-datafab.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-eneub6250.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-freecom.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-isd200.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-jumpshot.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-karma.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-onetouch.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-realtek.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-sddr09.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-sddr55.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/ums-usbat.ko usr/lib/modules/6.6.108-current-odroidxu4/kernel/drivers/usb/storage/usb-storage.ko usr/lib/systemd/network/73-usb-net-by-mac.link usr/lib/udev/rules.d/50-usb-realtek-net.rules

Long time no see! This doesn't look right. I checked docents of commits and so far couldn't find anything that would stand out. nand-sata-install only copies / rsync file-system, recreate boot scripts and flash boot-loader if necessary. If usb_storage is missing from initird, its normal that it doesn't boot. Its as module: https://github.com/armbian/build/blob/main/config/kernel/linux-odroidxu4-current.config#L1274 I would say its something to do with initird generation. Could be on the build / distro tools side. @belegdol perhaps knows something?

I've had an OrangePi4 LTS with a 7-inch IPS LCD HDMI jRP7007 external display for three years. Always used it with the stock OrangePi operating system: Debian Bullseye xfce (2022). I had Home Assistant installed and used a desktop client to view cameras and control lights from the touchscreen. Always looked good, and the only problem I had was that Debian didn't have power options, so I couldn't turn off the display; I had to do it manually with a button. The October Home Assistant update completely broke my H.A., it stopped running completely, and when I tried to reinstall it, it threw up errors due to broken dependencies. I tried to repair them, but nothing worked. I simply started looking for a newer version, since the current requirements for H.A. are at least Debian 12. I decided to try Harmony 13 with the XFCE desktop. Everything works great. I installed H.A., Plex, Samba, etc. It took me three days straight to get my entire home automation system back up and running in H.A. H.A.'s encrypted backups took me hours until I found where the key was stored. It later turned out that the full backup wasn't much use since all the sensors had a different ID, and 90% of the things were broken, and the add-ons weren't even in the backup. After a week of struggling, I managed to get everything 100% working. Debian 13 can turn my screen off and back on by touching it with a finger. This is great for quickly interacting with H.A. The screen looks terrible and there are no resolution modes. By default, Debian boots at 1024x768@60Hz. On the Orangepi OS, it runs perfectly at this resolution and everything looks great. It also has another 16:9 resolution mode at 848x480@60Hz. But in Armbian, I only have two modes: 1024x768@60 800x600@60 The first mode, which looks great on OrangePi OS, here has a shaky, blurry image. The second mode, 800x600, looks perfect, but it's too small. The monitor displays signal information. In Armbian, when it boots at 1024x768@60, it appears to be in a different resolution: 987x768@57Hz. That's why it looks so bad. When running at 57Hz, the image shakes, and when rescaling, the screen loses all detail. I followed many tutorials and none of them worked: Use cvt to calculate different resolutions and xrandr to create them. However, any resolution created results in an error when trying to use it. sudo apt install xrandr cvt 1024 600 60 # 1024x600 59.85 Hz (CVT) hsync: 37.35 kHz; pclk: 49.00 MHz Modeline "1024x600_60.00" 49.00 1024 1064 1168 1312 600 603 613 624 -hsync +vsync xrandr --newmode "1024x600_60.00" 49.00 1024 1064 1168 1312 600 603 613 624 -hsync +vsync xrandr --addmode HDMI-1 "1024x600_60.00" xrandr --output HDMI-1 --mode "1024x600_60.00" Use CVT and GTF to calculate the resolutions. I've tried countless resolutions, and it always fails and reverts to the previous one. I can't find a way to make the screen look the way it should. Does anyone have any ideas on how to fix this? I suspect this is a kernel-level issue. Sorry, but I'm using Google Translate. ------------------------------------------------------------------------------------ v25.11 rolling for Orange Pi 4 LTS running Armbian Linux 6.12.53-current-rockchip64 Packages: Debian stable (trixie) Support: for advanced users (rolling release) Containers: addon_491eb00d_hamh, addon_core_duckdns, addon_core_mosquitto, hassio_multicast, hassio_audio, hassio_dns, hassio_cli, homeassistant, hassio_observer, hassio_supervisor Performance: Load: 2% Uptime: 15:06 Memory usage: 56% of 2.90G Zram usage: 7% of 1.45G CPU temp: 38°C Usage of /: 23% of 57G RX today: 184 MiB -------------------------------------------------------------------------------------

Hey! So, when i enter the multitool link it says 404 not found... Is there any new link or smth?

Great! That worked. Do I need to do anything else after that?

I can confirm this is still broken as of 10/18/2025 Currently attempting the overwrite armbian uboot with vendor uboot solution The solution did work. The spl loader files can be found here https://dl.radxa.com/rock5/sw/images/loader/rock-5b/release/ All of the files need to be gathered together, or the file paths adjusted when you run the commands. I pulled the rkdeveloptool from git and built it and put everything else the folder with it. ❯ ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=101 Maskrom ❯ sudo ./rkdeveloptool db rk3588_spl_loader_v1.15.113.bin Downloading bootloader succeeded. ❯ sudo ./rkdeveloptool wl 0 armbian.img Write LBA from file (100%) ❯ sudo ./rkdeveloptool wl 64 idbloader.img Write LBA from file (100%) ❯ sudo ./rkdeveloptool rd Reset Device OK.

I finally installed Postmarket OS (Alpine Linux) using Pmbootstrap., I close this topic. Thanks to all of you for your comments and suggestion.

You seem to have the older obsolete special RPI5 build, that doe not exist anymore, it is just 1 RPI build called 'rpi4b' So remove armbian-bsp-cli-rpi5b-current as well apt update dpkg --remove --force-all libraspberrypi0 armbian-bsp-cli-rpi4b-current armbian-bsp-cli-rpi5b-current apt --fix-broken install apt install armbian-bsp-cli-rpi4b-current

So, I have now tried to solve the problem using the instructions. But unfortunately, it didn't work and I am getting an error message again. I ask for further assistance.

I had to enter all of this on my Orange Pi 5 Max: https://gist.github.com/default-writer/6ca5f1f05e88c9c51e2e1b09147ad23e

OK, good thing I don't give up easily. I found the cause, but now I need to figure out a fix. Using Armbian_23.11.1_Odroidxu4_jammy_current_6.1.63.img I changed the setenv rootdev to a bad UUID. I get the same error as latest image, but cat /proc/modules shows what's happening. Armbian_23.11.1_Odroidxu4_jammy_current_6.1.63.img initramfs loads: Module Function ------------------ ------------------------------------------------------------- scsi_mod Core SCSI subsystem. (Crucial) sd_mod SCSI disk driver (used for all block devices like SD, USB, SATA). (Crucial) t10_pi T10 Protection Information (disk data integrity). crc64_rocksoft_generic CRC algorithm. crc64_rocksoft CRC algorithm. sg SCSI Generic (raw access to SCSI devices). uas USB Attached SCSI (Driver for USB-to-SATA adapter). (Crucial) usb_storage Generic USB Mass Storage driver. (Crucial) scsi_common Common SCSI routines. zram Compressed RAM block device. zsmalloc ZRAM memory allocator. sch_fq_codel Network queue scheduler. Armbian-unofficial_25.11.0-trunk_Odroidxu4_noble_current_6.6.108.img initramfs only loads usbhid. Not sure how nand-sata-install works, but I'm assuming the something is hosed in initrd.img. Maybe @Igor knows where to look. I'm going to see if I can get the SD initrd.img on the SSD.

I have been experimenting with trying to get video acceleration working on the A83T. I can see from /proc/device-tree/soc/... that there is already a video-engine node within the current A83T device tree. It appears to be applied as one of the megous patches ARM-dts-sun8i-a83t-Add-cedrus-video-codec-support-to-A83T-untes.patch. Admittedly this is noted as being untested. In my initially created build via the build framework, Cedrus was not present at all among the list of loaded modules. I addressed this by creating an entry in the Cedrus compatibility table for the sun8i-a83t-video engine drv-sun8i-a83t-cedrus-add-variant.patch It now appears to load but complains about being unable to allocated an SRAM: [ 10.046406] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.046490] cedrus 1c0e000.video-codec: Failed to probe hardware [ 10.091215] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.091339] cedrus 1c0e000.video-codec: Failed to probe hardware [ 10.419296] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.419597] cedrus 1c0e000.video-codec: Failed to probe hardware [ 20.193058] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 20.193114] cedrus 1c0e000.video-codec: Failed to probe hardware [ 20.193322] platform 1c0e000.video-codec: deferred probe pending: (reason unknown) Using both sun8i-a23-a33.dtsi and sun8i-h3.dtsi as points of reference, I attempted to make an SRAM allocation under the system controller but this still appears to fail with the same failure messages. I have double checked in the user manual and VE memory should definitely exist at 0x01D0 0000. arm-dts-sun8i-a83t-add-ve-node.patch I would be grateful for any pointers. Thanks Ryzer

Hi all, and thanks for your incredible work I just received an "X98k pro" tvbox (sold as rk3566 4gb/32gb ) from T*** The box arrives already rooted. Outside : blue info lcd display --> Sdcard ; usb2.0/OTG ; usb2.0 ; usb 3.x --> Optical SPDIF, HDMI , hole marked "UPDATE" , power (5v 2A); external antenna female. -> EMPTY SIDE What's Inside the black box SOC : Rockchip RK3566 RAM : 8 Micron Technology (MT) D9QBJ memory chips Wireless : RTL8822cs Ethernet : RTL8211F eMMC : SanDisk China 32G Front lcd display controller : AIP1628 TTL rx tx gnd Device Info HW 5.23 and CPU-z confirm it's a rk3566 4/32, mali g52 Other infos from Device info HW : Device : rockchip X98k PRO ; Platform rk30board Android 11 , Wifi rtl88x2cs, kernel 4.19.232 (ubuntu...) CPU : Rockchip RK3566 BOX DEMO V10 ANDROID Board After installing termux I tried to find this box's dtb, but the only dtb file I found until now is /sys/firmware/fdt (no .dtb extension just "fdt") I don't know if it's the right one. Anyway, I de-compiled it using dtc to "X98k_pro_4g-32g_from_fdt.dts". I'd like to try armbian on this box If u wanna know something else let me know. Update 1)pressing the hole with a pin + power on takes to Android recovery (see photo) seems I can just boot froom sd from there ... 2) Trying to make Rockchip Driverassistant (modified 4.2 or 4.5) work to connect the box to a PC via usb2.0/otg. But nothing. 3) after trying to start with generic armbian for arm64 and then Station M2 (both just gave blank screen), I had a first success with a miniarch image (20240715-6.17.1-board-rk3566.x96_x6), hdmi and usb keyboard works, but ethernet is not working. Lets see what comes next. X98k_pro_4g-32g_from_fdt.dts

root@rk3318-box:~/tm16xx-display# make module make EXTRA_CFLAGS="-DCONFIG_TM16XX -DCONFIG_TM16XX_KEYPAD -DCONFIG_TM16XX_I2C -DCONFIG_TM16XX_SPI" -C /lib/modules/6.16.4-edge-rockchip64/build M=/root/tm16xx-display modules make[1]: Entering directory '/usr/src/linux-headers-6.16.4-edge-rockchip64' make[2]: Entering directory '/root/tm16xx-display' CC [M] line-display.o /tmp/cc8iv0mf.s: Assembler messages: /tmp/cc8iv0mf.s:8: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:9: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:10: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:11: Error: junk at end of line, first unrecognized character is `L' make[4]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/scripts/Makefile.build:290: line-display.o] Error 1 make[3]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/Makefile:2003: .] Error 2 make[2]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/Makefile:248: __sub-make] Error 2 make[2]: Leaving directory '/root/tm16xx-display' make[1]: *** [Makefile:248: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.16.4-edge-rockchip64' make: *** [Makefile:46: module] Error 2 fresh install, box T9 rk3328

I'm not sure it's related to your issue, but on some pi's I've seen Ethernet bandwidth issues accumulating over uptime. It was related to only to a part of specific hardware models, so suspect might be related to either hardware or kernel/driver version/implementation. After some tests I've found that the issue affects only per TCP connection downlink bandwidth - UDP does not have limits, as well as uplink TCP, multiple downlink TCP connections bandwidth stacks linearly. The worst bw case I've seen is ~2Mbps per TCP conn. Reboot fixes the issue for a random time (briefly from a few hours to a few months). Sometimes(?) the issue disappears on its own. So far I've not found a fault-proof fix except a reboot, but changing tcp congestion algo is worth to try: # sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = reno bic cubic westwood highspeed hybla htcp vegas nv veno scalable lp yeah illinois bbr # sysctl net.ipv4.tcp_congestion_control net.ipv4.tcp_congestion_control = cubic # sysctl net.ipv4.tcp_congestion_control=bbr net.ipv4.tcp_congestion_control = bbr For tests you may use iperf3 varying -C/-P/-R/..., e.g.: # iperf3 -4 -f m -P 1 -i 0 -t 5 -c IPERF3_SRV_IP --bind LAN_IP -R -b 100M -u # Single connection DL UDP up to 100Mbps for 5 sec # iperf3 -4 -f m -P 1 -i 0 -c IPERF3_SRV_IP --bind LAN_IP -R -C bbr # Single TCP conn DL using BBR as a congestion algo ... # iperf3 -4 -f m -P 50 -i 0 -c IPERF3_SRV_IP --bind LAN_IP -R # 50 TCP conns DL