All Activity

Update — eMMC now detected (workaround found) After significant debugging, I have identified and worked around the issue. Here's what I found: What the shipped DTB is missing for the eMMC controller (/mmc@fe310000): vmmc-supply / vqmmc-supply — voltage regulator references pinctrl-0 / pinctrl-names — pin muxing for the 8-bit eMMC data bus, clock, command, and data strobe lines cap-mmc-highspeed, mmc-hs200-1_8v, no-sd, no-sdio — eMMC capability flags Interestingly, the PMU IO domains (syscon@fdc20000/io-domains) are already correctly configured with vccio2 = 1.8V, and the pinctrl groups (emmc-bus8, emmc-clk, emmc-cmd, emmc-datastrobe) exist under /pinctrl/emmc/. The board-level wiring is all there in the DTB — it's just not connected to the eMMC controller node. Root cause: The Armbian Trixie vendor kernel (6.1.115) ships only rk3566-radxa-zero3.dtb (generic Zero 3), not the 3W-specific rk3566-radxa-zero-3w.dtb that the upstream Linux kernel has. The upstream DTS includes all of the above for the 3W model. Additional finding — deferred probe timing issue: Even after patching all missing properties via a device tree overlay, the eMMC still doesn't appear on first boot. The SDHCI driver (sdhci-dwcmshc) probes before the overlay's regulators are registered, receives dummy regulators instead of deferring, and initializes the controller without real power. A manual unbind/rebind of the driver after boot causes immediate detection: mmc0: new HS200 MMC card at address 0001 mmcblk0: mmc0:0001 8GTF4R 7.28 GiB I have a working fix (overlay + early-boot driver rebind) that I testing before publishing. The proper long-term solution would be for Armbian to ship the rk3566-radxa-zero-3w.dtb from the upstream kernel, or merge its board-level eMMC configuration into the existing rk3566-radxa-zero3.dtb.

I also saw that both apt and beta repo's do not contain recent rockchip64 kernels at the moment. There is only a recent generic arm64 one. So it is not only my rock3a, also my nanopi-r6c would be affected, but I use own/other/vendor kernels as well, so specific 6.18.8 is not an issue for me. I use extlinux or grub to select a certain kernel (6.19 flavor on nanopi-r6c for example). For my rock3a, I need vendor kernel, but if you use mainline based, you could use standard Debian backports kernel: https://packages.debian.org/trixie-backports/linux-image-arm64 You need to get the .dtb manually and I just assume most features are supported when the rock3a has mainline U-Boot in SPI. You need of course add that to sources.list and specifically select it. You could also use Armbian build framwork to build a 6.18.x yourself, you will also get a header files package then. For Debian14 I see there is: /usr/lib/linux-image-6.18.15+deb14-arm64/rockchip/rk3568-rock-3a.dtb But as indicated, this is total DIY, I have not tested it. I only know that on rock5b I could run standard distro since quite some months, but use 6.1.115 vendor one as I need all RK3588 HW to work.

Ok, after doing more tests the issue was the boot switch on the board. It must be switched to boot from SD/eMMC and not SPI (BIOS). Then reboot works fine.

ha extension is not a part of the framework. Copy from here https://github.com/armbian/os/tree/main/userpatches/extensions

If you’re thinking about running Armbian on the OnePlus 8T, basic functionality like calls, SMS, and mobile data will really depend on how well the device drivers are supported in the current build. From what most community discussions suggest, Wi-Fi and some hardware features may work, but cellular, camera, and other components can still be hit-or-miss compared to more mature options like Sailfish OS or Ubuntu Touch on officially supported devices. It’s a good idea to check active developer threads and user reports before installing.

Hi @maxsub, two annotations. Firstly, it's not the Wifi driver but the firmware. Thus echo "options bcmdhd firmware_path=brcm/ nvram_path=brcm/" > /etc/modprobe.d/orangepirv2.conf will get you going. And secondly no, there is no GPU change currently. GPU not working in "current" but may work with dirty tricks using "legacy". That's why it may pay to do some maintenance on the ancient 6.6 kernel.

Hello, I'm getting an error when building the kernel.

Ah I didn't know about that. I just created a systemd service that runs cpupower at boot.

## Description After a fresh installation of Armbian for Rockchip64 (Rock 3A), the system ships with `linux-image-current-rockchip64` version **26.2.1** (kernel 6.18.8), but the corresponding `linux-headers-current-rockchip64` package for version 26.2.1 is **not available** in the public APT repositories. This prevents installation of kernel headers required for DKMS modules, out-of-tree drivers, or any kernel module compilation. ## Steps to Reproduce 1. Flash the latest Armbian image for `rock-3a` (branch: `current`) from the official download page. 2. Boot the device and connect to the network. 3. Run `apt update` with any standard mirror (e.g., `mirrors.tuna.tsinghua.edu.cn`, `mirror.yandex.ru`). 4. Check installed kernel version: ```bash uname -r # Output: 6.18.8-current-rockchip64 ``` 5. Check available headers: ```bash apt policy linux-headers-current-rockchip64 ``` ## Actual Behavior - Installed image packages: ``` linux-image-current-rockchip64 26.2.1 [installed,local] linux-dtb-current-rockchip64 26.2.1 [installed,local] armbian-bsp-cli-rock-3a-current 26.2.1 [installed] ``` - `apt policy` output for headers: ``` linux-headers-current-rockchip64: Installed: (none) Candidate: 25.11.2 Version table: 25.11.2 500 500 http://<mirror>/armbian noble/main arm64 Packages ... (no 26.2.1 available) ``` ## Expected Behavior - The `linux-headers-current-rockchip64` package version **26.2.1** should be available in the `current` branch repository, matching the kernel shipped in the image. - Alternatively, the image should ship with packages that are already published and synchronized in the public repository. ## Impact - Users cannot install DKMS modules (ZFS, VirtualBox, WiFi drivers, etc.). - Development workflows requiring kernel headers are blocked. - Confusion for users performing a "clean install" who expect a consistent system. ## System Information - **Board:** Radxa Rock 3A - **Armbian version:** 26.2.1 (from image filename/release) - **Kernel:** 6.18.8-current-rockchip64 - **APT branch:** `current` - **Distribution:** Ubuntu Noble (24.04) - **Mirrors tested:** - `http://mirrors.tuna.tsinghua.edu.cn/armbian` - `http://mirror.yandex.ru/mirrors/armbian/apt` - `http://apt.armbian.com` (redirector) ## Possible Causes (hypothesis) 1. **Publishing race condition:** The image was built after `linux-image-26.2.1` was compiled but before `linux-headers-26.2.1` was published to the public repository. 2. **Branch mislabeling:** Version 26.2.1 may have been moved to `edge` after the image was built, but the image metadata was not updated. 3. **Mirror sync delay:** The master repository has the package, but mirrors have not yet synchronized (though multiple mirrors were tested over several days).

@Morales Morales

Hi, sorry to interrupt, but could you tell me how to do hardware acceleration? I have an Allwinner H313 v5.1

Read post on October 27 2024 Worked for me but with a couple extra steps burn .iso cfcard boot into device dd mmblk to nvme edit UUID for nvme -- Request new UUID for NVME (when dd I had the same UUID for cf card and nvme) edit orangpiEnv.txt in the armbian-config /System/Kernel/Edit Boot Env and apply the new UUID to the rootdev="New UUID" Edit fstab to add this line: /dev/mmcblk1p1 /boot vfat defaults 0 2 itd

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

Status Update: There is already a suitable FW file for Wifi AP mode. It's located in the /lib/firmware/brcm subdir: the newer fw_bcm43456c5_ag.bin can be used by adding firmware_path=brcm/ nvram_path=brcm/ when loading the bcmdhd.ko kernel module. The necessary change is now in Armbian::main. Also, the RV2 legacy 6.6.99 kernel has an advantage: with the Xunlong Ubuntu userspace (from Xunlong image downloads) it supports Wayland and thus GPU when applying the following hack: diff --git a/drivers/gpu/drm/spacemit/spacemit_drm.c b/drivers/gpu/drm/spacemit/spacemit_drm.c index da25ec8b3f..073de3c7ca 100644 --- a/drivers/gpu/drm/spacemit/spacemit_drm.c +++ b/drivers/gpu/drm/spacemit/spacemit_drm.c @@ -23,7 +23,7 @@ #include "spacemit_dmmu.h" #include "spacemit_gem.h" -#define DRIVER_NAME "spacemit" +#define DRIVER_NAME "rvdisplay" #define DRIVER_DESC "Spacemit SoCs' DRM Driver" #define DRIVER_DATE "20231115" #define DRIVER_MAJOR 1 For that reason, we added the LOAD fix also to the legacy/6.6 kernel (thus the uptime output shows a reassuring 0.00). Wayland support for current/6.18 kernel is still under investigation. Also, the edge/7.0 kernel does not boot on the RV2 currently.

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.

using cpupower to limit the max cpiu frequency to 1.61Ghz fixed the thermal issues. Default was 1.8Ghz. I'll might even reduce the max to 1.42, because USB hard disk mount drops when CPU usage is too high.

I suggest to get a better heatsink and/or thermal paste/glue. Next I would at the device tree if there are thermal points defined. Perhaps they are missing. You can use the dtc tool to decompile the device tree from /boot. Output values might be in hex instead of decimal, so just in case you wonder.

I have a RK3588 (Radxa Rock 5C) system running Armbian Debian Trixie. I have the heatsink and the fan installed as well. I set the fan PWM to 255 as soon as temperature reaches 50 degrees via a systemd service. When using all 8 cores, the system overheats (>110 degrees) and eventually shuts down. For example, when compiling ffmpeg, it works fine with 'make -j6', but 'make -j8' results in a shutdown before compilation is complete. Likewise I had thermal issues when using llama.cpp. Shouldn't the OS throttle the CPU when temperature reaches high levels? I think that is not happening at the moment. Online search referred me to cpufrequtils to set a conservative governor, but it looks like cpufrequtils does not exist for Trixie. Any suggestions on how I should approach this?

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.

Applying kernel provided DT overlay rockchip-rk3588-orangepi-5-pro-disable-leds.dtbo Meaning the overlay was applied successful. If it does not work, perhaps this means some pin definitions or whatever differ from opi sources vs ours.

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.