Active threads

@Morales Morales

Excellent. Thank you so much. I will try the newer brcm driver today. So the GPU change is now in main?

Note that I believe Armbian will reset the max CPU frequency on boot. There is code in /usr/lib/armbian/armbian-hardware-optimization that uses the values defined in /etc/default/cpufrequtils to initialize the governor, min and max frequencies at boot time. So even though cpufrequtils is no longer an installed set of tools, Armbian is still doing some of the same work based on its old configuration files. So assuming this works as it used to, all you should need to do is set the max speed you want in /etc/default/cpufrequtils

Bug Description eMMC is not detected on Radxa Zero 3W when booting Armbian Trixie from SD card. The eMMC controller initializes but fails to find power supply regulators, resulting in no block device being created. Hardware Board: Radxa Zero 3W (4GB RAM / 8GB eMMC) Boot media: SD card Image Armbian Trixie (current kernel) for Radxa Zero 3 DTB: rk3566-radxa-zero3.dtb Symptoms WiFi and SD card work fine eMMC does not appear in lsblk dmesg shows the SDHCI controller at fe310000.mmc loading but failing regulator lookups: sdhci-dwcmshc fe310000.mmc: Looking up vmmc-supply property in node /mmc@fe310000 failed sdhci-dwcmshc fe310000.mmc: Looking up vqmmc-supply property in node /mmc@fe310000 failed mmc0: SDHCI controller on fe310000.mmc [fe310000.mmc] using ADMA No mmcblk0 device is created. Only the SD card (mmcblk1) appears. Expected Behavior eMMC should appear as /dev/mmcblk0 in lsblk. Notes The DTB (rk3566-radxa-zero3.dtb) appears to be missing vmmc-supply and vqmmc-supply regulator definitions for the eMMC node (/mmc@fe310000) A rk3566-radxa-zero-3w.dtb (with proper 3W-specific regulators) does not exist in the image — only rk3566-radxa-zero3.dtb and rk3566-radxa-zero3-ap6212.dtb are present Related: #8776 (wrong DTB filename for Zero 3W) This causes me to not be able to install to EMMC using armbian-install

Issues for the actual image (no UI): no HDMI; Ethernet got address with DHCP, but cannot connect with SSH, even ping (ICMP) is not stable. Wifi works fine. The board is OK - tested with official debian image.

i also added a hp now: https://langerma.github.io/dumpstore/

I am extremely excited! This really worked! Successfully booted into the system from NVMe! Thx!!!! 😘😘

UPDATE I was able to figure out what was happening. The board initially boots with the LEDs enabled. Because of this, applying the device tree overlay alone did not seem to disable them, even across reboots. However, after manually turning the LEDs off once using: echo 0 | tee /sys/class/leds/blue_led/brightness echo 0 | tee /sys/class/leds/green_led/brightness and then enabling the overlay, the LEDs remained disabled, and the overlay appeared to work as expected. So it seems the LEDs needed to be turned off once manually before the overlay behaviour became consistent. Everything now works as intended. It appears that when overlay_prefix is either not defined or is empty, the system behaves unexpectedly during overlay lookup. In such cases, the loader seems to attempt resolving overlays starting with -, rather than correctly resolving the overlay name.

Related to Again, you are using the wrong image. You cannot assume an image for the opi5+ works for the opi5b. Those are different boards.

wrong image. you cannot simply use an image for board X and assume it works on board Y

Can someone pull request this to have it working myself as well please?

The reboot issue seems to be fixed with latest Armbian 26.2.1 Thanks!

I managed to disable heartbeat. I am running HA based on debian trixie and my it was only led i could change to off echo 0 | sudo tee /sys/class/leds/state-led/brightness

I can't install mpd on Armbian v26.2 rolling for NanoPi Air running Armbian Linux 6.12.76-current-sunxi Packages: Ubuntu stable (noble) user@nanopiair:~$ sudo apt install mpd Reading package lists... Done Building dependency tree... Done Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: mpd : Depends: libavcodec61 (>= 7:7.0) but it is not installable Depends: libavfilter10 (>= 7:7.0) but it is not installable Depends: libavformat61 (>= 7:7.0) but it is not installable Depends: libavutil59 (>= 7:7.0) but it is not installable Depends: libflac14 (>= 1.5.0) but it is not installable Depends: libfmt10 (>= 10.1.1+ds1) but it is not installable Depends: libicu76 (>= 76.1-1~) but it is not installable Depends: libiso9660-12 (>= 2.2.0) but it is not installable Depends: libsidplayfp6 (>= 2.12.0) but it is not going to be installed Depends: libjs-sphinxdoc (>= 8.1) but it is not going to be installed Depends: sphinx-rtd-theme-common (>= 3.0.2+dfsg) but it is not going to be installed E: Unable to correct problems, you have held broken packages. What is the issue with missing packages ? Edit: Solved by adding trixie repositories.

Continuing to dig into this. Updated the Armbian images - available via the same links above (md5sum mismatch): How to add the module to an already working system (so you don't have to reinstall from scratch): 1. Download the archive ws2801-1.0.tar.gz with the dkms source code for the ws2801 module. 2. Extract the source folder to /usr/src/ : sudo tar -xzvf ~/ws2801-1.0.tar.gz -C /usr/src/ (here ~/ is the /home directory of my user) 3. Install the module step-by-step via dkms: sudo dkms add ws2801/1.0 sudo dkms build ws2801/1.0 sudo dkms install ws2801/1.0 4. To avoid rebooting, you can load the module immediately: sudo modprobe ws2801 By default, Red should start blinking as a "heartbeat" trigger. Description of dts and demo:

A long time ago, that I started the question, but a few days ago, I started again to solve it. And with the help of several AI, I found a working solution. This is the working overlay: /dts-v1/; /plugin/; /* * NanoPI Neo2 H5 - OTG USB with switchable VBUS * Allows SD-Card as USB device on OTG port with GPIO-controlled power * * Key points: * - fragment 0: dr_mode "otg" enables dual-role (host+device detection) * - fragment 1: Removing usb0_id_det-gpios prevents "External vbus detected" error * - fragment 2: Removing gpio property from regulator keeps GPIO 354 (PR2) free for manual control * - fragment 3: GPIO 354 is controlled via usb.sh script (echo 1/0 to /sys/class/gpio/gpio354/value) * * GPIO 354 (PR2) state: * 1 = VBUS ON (USB device recognized) * 0 = VBUS OFF (USB device disconnected) */ / { compatible = "allwinner,sun50i-h5"; fragment@0 { target = <&usb_otg>; __overlay__ { dr_mode = "otg"; status = "okay"; }; }; fragment@1 { target = <&usbphy>; __overlay__ { usb0_id_det-gpios; }; }; fragment@2 { target-path = "/usb0-vbus"; __overlay__ { gpio; status = "okay"; }; }; fragment@3 { target = <&r_pio>; __overlay__ { usb0_vbus_pin: usb0_vbus_pin { pins = "PR2"; function = "gpio_out"; output-high; }; }; }; }; This allows the standard GPIO controls using sysfs in /sys/class/gpio. I'm using the kernel Linux nanopineo2 6.6.75-current-sunxi64 on Armbian 25.11.2 bookworm (32 bit userland). Hope this helps everybody trying to achive the same 😉

Since the hardware support for Rockchip SoCs in the mainline kernelis generally already very outstanding and their further development is also being actively pursued, I only have SBCs with integrated NPUs that are based on them. Among them are ODROID-M2, NanoPC-T6, and ROCK-5-ITX. But since the NPU is an integral part of the SoC, the board manufacturer and the design of the SBC are not necessarily of importance. As far as I understand, edge-class NPUs are best suited for computer vision tasks. I am therefore engaged in object detection: and super-resolution:

I'm having a problem with my Raspberry Pi 5, which I describe below. I have a DVR connected to it via Ethernet. If I connect both at the same time, dmesg reports a failure and I can't ping the DVR to establish a connection; I have to run `ifconfig eth0 down` and `ifconfig eth0 up`. Can anyone help or know if there's a bug in the kernel version? I'm using Ubuntu 22.04. jammy root:~# dmesg | grep eth0 [ 1.312167] macb 1f00100000.ethernet eth0: Cadence GEM rev 0x00070109 at 0x1f00100000 irq 108 (2c:cf:67:81:d6:2a) [ 3.237493] systemd[1]: Found device /sys/subsystem/net/devices/eth0. [ 3.453483] systemd[1]: Started ifup for eth0. [ 3.573655] macb 1f00100000.ethernet eth0: PHY [1f00100000.ethernet-ffffffff:01] driver [Broadcom BCM54213PE] (irq=POLL) [ 3.573668] macb 1f00100000.ethernet eth0: configuring for phy/rgmii-id link mode [ 6.441950] macb 1f00100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [ 11.560707] macb 1f00100000.ethernet eth0: Link is Down [ 13.605678] macb 1f00100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off root:~# ping 192.168.200.201 PING 192.168.200.201 (192.168.200.201) 56(84) bytes of data. ^C --- 192.168.200.201 ping statistics --- 6 packets transmitted, 0 received, 100% packet loss, time 13305ms root:~# ifconfig eth0 down root:~# ifconfig eth0 up root:~# dmesg | grep eth0 [ 1.312167] macb 1f00100000.ethernet eth0: Cadence GEM rev 0x00070109 at 0x1f00100000 irq 108 (2c:cf:67:81:d6:2a) [ 3.237493] systemd[1]: Found device /sys/subsystem/net/devices/eth0. [ 3.453483] systemd[1]: Started ifup for eth0. [ 3.573655] macb 1f00100000.ethernet eth0: PHY [1f00100000.ethernet-ffffffff:01] driver [Broadcom BCM54213PE] (irq=POLL) [ 3.573668] macb 1f00100000.ethernet eth0: configuring for phy/rgmii-id link mode [ 6.441950] macb 1f00100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [ 11.560707] macb 1f00100000.ethernet eth0: Link is Down [ 13.605678] macb 1f00100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off [ 147.034711] macb 1f00100000.ethernet eth0: Link is Down [ 151.855860] macb 1f00100000.ethernet eth0: PHY [1f00100000.ethernet-ffffffff:01] driver [Broadcom BCM54213PE] (irq=POLL) [ 151.855871] macb 1f00100000.ethernet eth0: configuring for phy/rgmii-id link mode [ 152.869842] macb 1f00100000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off root:~# ping 192.168.200.201 PING 192.168.200.201 (192.168.200.201) 56(84) bytes of data. 64 bytes from 192.168.200.201: icmp_seq=1 ttl=64 time=1.01 ms 64 bytes from 192.168.200.201: icmp_seq=2 ttl=64 time=1.01 ms ^C --- 192.168.200.201 ping statistics --- 2 packets transmitted, 2 received, 0% packet loss, time 1001ms rtt min/avg/max/mdev = 1.007/1.007/1.007/0.000 ms

On RK3568 the Panfrost driver needs the clk-scmi kernel module to be loaded. But is not build in 6.18 / 6.19 otherwise we get [ 13.370681] panfrost fde60000.gpu: get clock failed -517 [ 13.370717] panfrost fde60000.gpu: clk init failed -517 [ 13.485723] panfrost fde60000.gpu: get clock failed -517 [ 13.485761] panfrost fde60000.gpu: clk init failed -517 [ 13.503876] panfrost fde60000.gpu: get clock failed -517 [ 13.503918] panfrost fde60000.gpu: clk init failed -517 Thanks !

use the images in this thread

I started down this path and realized that the patches are applied to downloaded linux kernel source. Normally, the kernel source is "cleaned" even if the build fails. I then found the sakura pi github page and the page has more recent commit than the Rock-s0, incorporates the kernel.dtsi while adhering the the u-boot requirements for rockpi's. U-boot for Rockpi. I'd like to base my build on the more up-to-date code. The easist way to do this is set CLEAN_LEVEL="" but I'm running into issues with the patches in GitHub: Sakura-Pi failing to apply. Essentially, I would iike to have the patches apply, not necessarily build and have the files generated by the patches remain. I have a large dtb file, extracted from Sovol's OEM firmware, that I would like to copy/paste into the generated *.dtb file, rename the *csc file and the defconfig file, and then generate a patch against clean source. Conceptually, this should work and I'm suprised it is this difficult to generate a new board for an existing family. Alternatively, a script could generate a file from a highlited portion of a patch and generate a file. Or is is possbile to run ./compile.sh a step at a time? It would be helpful in this setting, very instructive about the process and would narrow down build failures. Am I on the right path? Any step-by-step examples and or links to helpful scripts?

As champions of open source development in the embedded community, Collabora will be at Booth 4-404 with an impressive lineup of live demonstrations spanning graphics, machine learning, continuous testing, and real-world applications. View the full article

Thank you very much. Unfortunately, Trixie won't start. BootROM - 1.73 Booting from MMC BootROM: Bad header at offset 00000200 … BootROM: Bad header at offset 02E00000 BootROM: Bad h Trying Uart

I need you to understand something very important: the manufacturer is infecting the boards with Java botnet software. All the software you should use is developed by the Armbian community. Welcome to the Armbian community! Now that you are a member, you must develop software that schedules the board's power-on.

Maybe see https://wiki.postmarketos.org/wiki/Medion_Chromebook_S2015_(google-veyron-mighty) It is RK3288, so an Armbian Rockchip kernel might do something, but I have no clue about DeviceTree and/or bootloader. Alpine is quite different from Armbian/Debian but maybe with that bootloader+kernel+DTB and Armbian rootfs it might do something, but make sure you have seril debug cable. In general might need to find solder points on motherboard/PCB or some specific resistor value on OTG ID pin.