All Activity

Why? Will cause recompilation on every build This does not exist anymore IIRC. Non-standard docker image can cause rebuild since it is now based on Noble. This is not needed since it is default behavior. Also unneeded since default is yes already.

You know one can have multiple DE's installed and select which one to use at login? sudo tasksel kde-desktop lets you add KDE Plasma for every Debian based install. Important note is that RK3588 needs a pretty new mainline kernel otherwise forget KDE. With vendor kernel it should be no issue. So if you want to use KDE Plasma, no new image or install is needed. But maybe you only want to build an image and not use it.

I apologize if this is a basic question. I'm trying to make a minimal Orange Pi Zero 3 Trixie image with a btrfs file system and NetworkManager for the networking stack using Docker without having to compile a new kernel (i.e., I just want to use the precompiled kernel found in the CSC version). I created a `config-myimage.conf` file under `build/userpatches`: BOARD=orangepizero3 BRANCH=current RELEASE=trixie CLEAN_LEVEL=cache KERNEL_CONFIGURE=no BUILD_KSRC=no BUILD_MINIMAL=yes NETWORKING_STACK=network-manager DOCKER_ARMBIAN_BASE_IMAGE=ubuntu:jammy ROOTFS_TYPE=btrfs BTRFS_COMPRESSION=zlib CONSOLE_AUTOLOGIN=yes #BOOTSIZE=96 # need larger boot size to prevent 'disk out of space' # on kernel upgrade BOOTSIZE=256 COMPRESS_OUTPUTIMAGE='sha,xz' EXTRAWIFI=yes function user_config__010_modify_package_list() { # adds additional packages to the package cache add_packages_to_rootfs btrfs-progs neovim pmount nmap tmux # edit this list to remove packages from cache remove_packages nano } I then ran `./compile.sh myimage`, but it launches into kernel compilation. I did this once before uisng bookworm, but I can't remember how....

I found the dts setting about "ethernet@5020000" was different between kernel 5.15.93 and kernel 6.1.47. We need to make sure the following things are correct: 1. Ethernet driver uses the correct clock/reset 2. GPIO reset can be pulled up 3. MDIO can correctly go to PHY 4. Pinmux correctly sets Ethernet pins #Kernnel 5.15.93-sunxi64 ethernet@5020000 { compatible = "allwinner,sun50i-h6-emac\0allwinner,sun50i-a64-emac"; syscon = <0x31>; reg = <0x5020000 0x10000>; interrupts = <0x00 0x0c 0x04>; interrupt-names = "macirq"; resets = <0x04 0x21>; reset-names = "stmmaceth"; clocks = <0x04 0x54>; clock-names = "stmmaceth"; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <0x32>; phy-mode = "rgmii-id"; phy-handle = <0x33>; phy-supply = <0x34>; phy-io-supply = <0x35>; allwinner,rx-delay-ps = <0xc8>; allwinner,tx-delay-ps = <0xc8>; phandle = <0x78>; mdio { compatible = "snps,dwmac-mdio"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x79>; ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0x01>; reset-gpios = <0x1f 0x03 0x0e 0x01>; reset-assert-us = <0x3a98>; reset-deassert-us = <0x9c40>; phandle = <0x33>; }; }; }; #Kernel 6.1.47-current-sunxi64 ethernet@5020000 { compatible = "allwinner,sun50i-h6-emac\0allwinner,sun50i-a64-emac"; syscon = <0x32>; reg = <0x5020000 0x10000>; interrupts = <0x00 0x0c 0x04>; interrupt-names = "macirq"; resets = <0x06 0x21>; reset-names = "stmmaceth"; clocks = <0x06 0x54>; clock-names = "stmmaceth"; status = "okay"; pinctrl-names = "default"; pinctrl-0 = <0x33>; phy-mode = "rgmii-id"; phy-handle = <0x34>; phy-supply = <0x2e>; phy-io-supply = <0x35>; allwinner,rx-delay-ps = <0xc8>; allwinner,tx-delay-ps = <0xc8>; phandle = <0x79>; mdio { compatible = "snps,dwmac-mdio"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x7a>; ethernet-phy@1 { compatible = "ethernet-phy-ieee802.3-c22"; reg = <0x01>; reset-gpios = <0x1e 0x03 0x0e 0x01>; reset-assert-us = <0x3a98>; reset-deassert-us = <0x9c40>; phandle = <0x34>; }; }; };

To troubleshoot this thing I would just boot from another sd card with a fresh bookworm image leaving your system on emmc or on another sd untouched. In 'sudo ethtool -i <interface>' the name of your 2.5G interface has to be inserted - 'ifconfig' will reveal it (I renamed mine to end1). If the rtl_nic firmware is recognized correctly it will display: root@grid:~# sudo ethtool -i end1 driver: r8152 version: v1.12.13 firmware-version: rtl8156a-2 v2 04/27/23 ...

I am trying to downgrade to kernel 5.15.93-sunxi64 and found the eth0 is worked. pi@orangepi3:~$ dmesg | grep eth0 [ 18.467932] dwmac-sun8i 5020000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211E Gigabit Ethernet] (irq=POLL) [ 18.468969] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 18.469701] dwmac-sun8i 5020000.ethernet eth0: No Safety Features support found [ 18.469727] dwmac-sun8i 5020000.ethernet eth0: No MAC Management Counters available [ 18.469734] dwmac-sun8i 5020000.ethernet eth0: PTP not supported by HW [ 18.475463] dwmac-sun8i 5020000.ethernet eth0: configuring for phy/rgmii-id link mode [ 20.510690] dwmac-sun8i 5020000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx [ 20.510735] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

See https://github.com/canonical/netplan/pull/456#discussion_r1569065581 The way the netplan + networkd integration is designed requires all the network devices (wlan0 in particular) to exist at /sbin/init time - otherwise, the netplan generator disables `systemd-networkd-wait-online.service` which also causes `network-online.target` to be reached early. In particular, this breaks any network FS mounts on boot. Of note, I tried logging in to file the bug via the dev contribution platform, but it looks I'm blocked from JIRA access, so am filing it here instead.

My log : https://paste.armbian.com/idomububex I find the phy issue stiil happened in OranpePi3 when using Kernel 6.1.47-current-sunxi64 and 6.12.20-current-sunxi64. @Jack07 @JohnnyLaw Do you still have same issue when using 6.X.X verion kernel?

@Werner I will close this Topic and discuss the issue in the old one.

@Werner Yes, My SBC model is "OrangePi3", not LTS.

Great. Just to avoid cross-contamination. You are sure you have the Orange Pi 3 and not the Orange Pi 3 LTS model? Background: OrangePi naming scheme is kind a ridiculous, makes no sense often enough and introduces confusion. In this particular case they switch to a different PHY chip which I think was migitated by Armbian but not sure if they still have separate images. Seems like a similar topic already exists: https://forum.armbian.com/topic/34024-cannot-attach-to-phy-after-upgrade-to-202381/

Now I am trying to downgrade Kernel back to 5.51.X and figure out it.

@Werner Got it! Thank you for your help. https://paste.armbian.com/idomububex Provided the link.

Hi KDE Plasma is not an officially supported DE, therefore hidden behind code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } EXPERT=yes switch. May work, maybe not. No support for it, just like for any user-built image. Example without interactive menu including all available app groups: ./compile.sh build BOARD=orangepi5-plus BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED='browsers chat desktop_tools editors internet multimedia office programming remote_desktop' DESKTOP_ENVIRONMENT=kde-plasma DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base EXPERT=yes KERNEL_CONFIGURE=no RELEASE=bookworm

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

moved

The eth0 device does not work when using 6.1.47-current-sunxi64 and 6.12.20-current-sunxi64 kernels. There will be the following errors in the kernel log. pi@orangepi3:~$ dmesg | grep eth0 [ 16.997431] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 16.998219] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 19.284111] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 19.284754] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 19.308140] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 19.308738] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 19.334063] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 19.334754] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 19.358727] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 19.359417] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 151.380407] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 151.381105] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 157.928629] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 157.929360] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 320.009515] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 320.010271] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 320.037458] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 320.038169] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 320.062716] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 320.063428] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19) [ 320.082662] dwmac-sun8i 5020000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 320.083389] dwmac-sun8i 5020000.ethernet eth0: __stmmac_open: Cannot attach to PHY (error: -19)

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

moved

Only with kernel versions 6.1.x am I able to apply the static network config for RTL8211F interface (but sometimes it'll fail), but with newer kernel versions (v6.6.16/v6.6.63/v6.12.22/v6.14.0-rc4/v6.15.0-rc1), trying to apply the network config with `netplan apply` always fails with `Failed to reset the dma` error.

Hardware H264 encoding on the F3 is failing with a firmware binary error. ffmpeg command ffmpeg -y -v 99 -f lavfi -i testsrc -pix_fmt nv12 -g 15 -c:v h264_v4l2m2m out.264 dmesg error [ 4834.438234] MVX if: Failed to load firmware binary. filename=linlon-v52_v76-80-2/h264enc.fwb. [ 4834.450002] MVX if: Firmware binary was loaded with error. [ 4834.450020] MVX session: ffffffd905a1a0f8 send event error. error=-22 ffmpeg Gets some way into initialising. It detects the Linlon H264 encoder, checks images are NV12 format, but then fail with this error [h264_v4l2m2m @ 0x2abf834870] Failed to set gop size: Invalid argument Where do I find this .fwb file, and should it be shipping with Armbian? System Banana Pi F3 Uname Linux bananapif3 6.1.15-legacy-spacemit #1 SMP Sat Sep 7 13:08:45 UTC 2024 riscv64 riscv64 riscv64 GNU/Linux /etc/os-release PRETTY_NAME="Armbian 25.5.0-trunk.451 noble" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.armbian.com/" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" PRIVACY_POLICY_URL="https://www.armbian.com" UBUNTU_CODENAME=noble LOGO="armbian-logo" ARMBIAN_PRETTY_NAME="Armbian 25.5.0-trunk.451 noble" apt-update/apt-upgrade did this first

During build compile, set kernel config as: Device Drivers -> USB Support -> xHCI HCD (USB 3.0) support N Device Drivers -> USB Support -> OHCI HCD (USB 1.1) support N Device Drivers -> USB Support -> DesignWare USB3 DRD Core N should alleviate most usb issues on a OdroidC2

* Manufacturer: Allwinner * Model: TV BOX * Brand: Allwinner * Board: exdroid (H3Q44_V4.0_20200602) * Device: dolphin-fvd-p1 * Hardware: sun8iw7p1 * Platform: dolphin * Product: dolphin_fvd_p1 * Serial number: 95e0783000d314000085 * Total Memory: 4096 MB * Available Memory: 441 MB * Internal Storage - Total Space: 4665 MB * Internal Storage - Free Space: 3174 MB * Bluetooth Version: 4+ Hi everyone, I could really use some help with a project that's getting quite frustrating. I'm a beginner with Linux and embedded systems (actually just starting to learn programming now), and for the past two weeks or so, I've been trying to install a Linux distribution on an Allwinner TV Box, but haven't had any luck so far. I managed to run neofetch (via Termux on the original Android system) and it reported the following hardware details: * Host: Allwinner TV BOX * CPU: sun8iw7 @ 1.008GHz (Apparently an Allwinner H3) * Kernel (Android): 4.4.55 * Memory: ~4GB RAM (Detected as 4896MiB) * Architecture: armv7l (32-bit) The Problem: I managed to boot a specific Linux image from a USB drive / SD card (specifically, Armbian_20.05.0-trunk-sunvell-r69-buster-current_5.4.33_minimal.img, which uses Kernel 5.4.33), but the system doesn't recognize the TV Box's internal storage. The internal storage itself seems fine, as the original Android OS (Kernel 4.4.55) boots up normally when I remove the USB drive / SD card. What I've Tried: * Image Used: Booting with the image mentioned above (Armbian_20.05.0-trunk-sunvell-r69-buster-current_5.4.33_minimal.img / Kernel 5.4.33). * Internal Memory Issue: The main blocker is that after booting Linux, the internal storage (eMMC, I assume) isn't detected or mounted. * Other Methods: I also tried messing around with a USB-A connection for flashing, but didn't get anywhere and honestly, I wasn't really sure what I was doing. * DTB File: I attempted to replace the DTB (Device Tree Blob) file within the Armbian image, guessing it might be the cause of the hardware detection issue (especially the eMMC), but I did this without really knowing the procedure, and it didn't work. * Research & AI: I've done a fair bit of research and used AI to try and guide me. It was helpful up to a point, but then the information became confusing and didn't solve the core problem. My Question: Given this seems to be an Allwinner H3 box running Android with Kernel 4.4.55, could anyone shed some light on this? Could the issue be the Linux Kernel version (5.4.33) being incompatible? Is it the specific Armbian image (Armbian_20.05.0-trunk-sunvell-r69...) or the wrong DTB for this board/eMMC combination? Is there a more reliable method or a recommended image/DTB for generic Allwinner H3 TV Boxes? I'm almost at my wit's end and was hesitant to ask for help, but I'd really like to get this working. Any tips, tutorials, or pointers you could provide would be greatly appreciated. Thanks!

I switched back to actual kernel 6.12.22 and if I need to transfer from NAS to Client I'll just use another LAN-cable with 1Gbit and have around 100mb/s And you are right, installing a new image would be the best. But configering OMV again and can't use a simple settings-backup is a nightmare for me I upgraded from Debian11 to 12 (Bullseye) and the upgrading process worked without issues, but maybe that upgrading could bring up the speed issue. sudo ethtool -i end1 Cannot get driver information: No such device In /lib/firmware/rtl_nic/ are all firmware versions... Is ther anything I need to fix?

To troubleshoot that you could boot off a fresh Armbian 24.11.1 Bookworm image (6.6.62) and add rtl_nic firmware, replace dtb, setup rc.local. If transfer rates are still low something may be wrong with your client or with your helios64 or with the network itself. Did you launch 'htop' so that you can see what is going on during the data transfer? Are there any cores fully utilized ? Is nic offloading enabled ? etc. 'systemctl disable armbian-hardware-optimize.service' I am automatically calling that shell script while mounting helios64 as a remote drive on macOS clients (using netatalk). The names of the processes (afpd|cnid|iperf3|netatalk) need to be replaced by the processes involved in the data transfer on your helios (iperf3, smb? etc. ). root@grid:~# chmod +x /usr/local/bin/make_nas_processes_faster.sh root@grid:~# sh /usr/local/bin/make_nas_processes_faster.sh pid 21358's current affinity list: 4 pid 21358's new affinity list: 4 pid 21359's current affinity list: 4 pid 21359's new affinity list: 4 pid 21360's current affinity list: 4 pid 21360's new affinity list: 4 pid 21367's current affinity list: 4 pid 21367's new affinity list: 4 pid 21368's current affinity list: 4 pid 21368's new affinity list: 4 pid 21700's current affinity list: 4 pid 21700's new affinity list: 4