All Activity

@c0rnelius is the maintainer of the board. Maybe he has something to say.

When I did apt upgrade and didn't encounter any problems, I suspected that it was related to a bug in a specific version.

So essentially it is about adding/fixing analog audio (3.5mm plug) es83xx in mainline kernel. I am maybe lucky that there is another analog chip in Radxa ROCK5B, but I have also noticed strange (too high too low) volume levels initially, but cannot reproduce anymore as 1 of the distros is Opensuse Tumbleweed and the specific snapshot version is already deleted. It worked fine a month ago (Opensuse Tumbleweed on top of EDK2-UEFI v1.1 in SPI-flash ), but runs Armbian Trixie/Testing now as server, don't know about audio. I use pulseaudio via network normally, but that is broken? in Debian/Ubuntu for 3 years or so as pipewire is default and pipewire-pulse is not native pulseaudio. But I haven't looked into it the last 2 years or so. I had it working in bullseye and upgraded to bookworm needed removing all pipewire stuff to keep it working. New bookworm/Armbian I never got it working. In the end, it is Xunlong I guess selling the HW and not delivering mainline kernel features. Some cheap N100 boards use a well supported USB audio chip, RPi5 removed 3.5mm audio completely, the workaround is to buy a cheap USB audio dongle. So see for yourself how you fulfill your audio requirements. When I bought my ROCK5B, the OPI5plus was about 25 euros cheaper, but it is the onboard power supply circuit and SATA options that made me buy from Radxa and also that the ROCK5B is used by Collabora. It is long time (decade) ago I did some (local) changes to kernel sources, that was torwalds or mainline tree, for Armbian, look in latest build docs options. It is something with kernel-config, you can then pause things and change sources. But better to see if you can manage to fix directly on mainline kernel git.

H618 Orange Pi Zero2 – SPI/I2C/UART overlays not working after armbianEnv.txt edit I’m using Orange Pi Zero2 (H616) with Armbian. I edited /boot/armbianEnv.txt to enable SPI/I2C/UART, but GPIO pins for SPI/I2C/UART are not working. gpio readall shows OFF or wrong ALT modes. overlay_prefix=sun50i-h616 overlays=spi-spidev spidev1_1 uart5 i2c3-ph 229 SDA.3 ALT5 228 SCL.3 ALT5 231 MOSI.1 OFF 232 MISO.1 OFF 230 SCLK.1 OFF ... sun50i-h616-bananapi-m4-spi1-cs0-cs1-spidev.dtbo sun50i-h616-bananapi-m4-spi1-cs0-spidev.dtbo sun50i-h616-bananapi-m4-spi1-cs1-spidev.dtbo sun50i-h616-i2c3-ph.dtbo sun50i-h616-uart5.dtbo ... Copy dtbo to /boot/dtb/allwinner/overlay/ Reboot Which overlays are correct for SPI/I2C/UART on H616? How to check if dtbo is actually loaded? If copying dtbo doesn’t help, what should I do? Thanks!

Thank you for your help. I attached log of first minute console log of original Android. Hope this can clarify things. It states some important info like [00.495]PMU: AXP1530, voltage levels and other hardware details. To clarify boot process with mniarch: It also shows mmc data error, however it does not stop there. androboot.txt

Yes, validation always succsess. I tried even different SD cards (brand new Sandisk). After Armbian fails to boot I write stock friendlyelec image by the same tool and stock image always properly boot

I never used RKDevTool because I'm on Linux. I understand the instructions as follows: Download RKDevTool, Wipe_part and Clear_EMMC_yy3568.zip from the links in the original post. The zip contains the config for RKDevTool from Nicolas. The included file path will not work on your system. You have to adjust these that uboot.img, miniloader.bin and parameter.txt from the Clear_EMMC_yy3568 are used and the separately downloaded wipe_part. I assume that at the next boot some partitions on EMMC are cleared and in consequence booting from SDcard is activated.

Armbian's archives can be uncompressed with 7-Zip on Windows, Keka on OS X and 7z on Linux. Images shall only be written with imaging tools that validate burning results. This saves you from corrupted SD card contents. Approved Tools: USBImager a lightweight cross-platform imaging tool Balena Etcher an electron / node.js based cross-platform imaging tool (may contain spyware) Did the validation of you burning the image succeed?

Etcher is broken on big images. It is out of our power to fix that. Use USB imager or something else.

I know this sounds strange, but I cannot get any of the images to boot. I have an R3S non-LTS + SD card. It works well with the stock images from FriendlyElec, but none of the Armbian images I tried will boot. I tried different tools to write the SD (BalenaEtcher, USBImager, Rufus), but nothing changed. When I tried to read the SD card with Armbian on my x86 laptop running Debian, the system didn’t recognize any proper partitions (maybe that’s normal, maybe not—I don’t know). But when I write an Armbian image for Allwinner NanoPi, the partitions are detected correctly. And finally, I can’t connect to the debug UART, so I can’t get any logs. I feel the solution should be simple, but I need help with this.

This is a sidebar/urgent request for help. I was previously able to install Armbian noble on my YY3568 board thanks to instructions from these forums (https://forum.armbian.com/topic/49775-board-bring-up-youyeetoo-yy3568-rockchip-rk3568/). I now need to use the board for a Debian project to help a friend that lost their backup, and am unable to reproduce the instructions in that post to empty the eMMC and enable SD boot. The poorly written/flawed instructions in this post involve loading a config file into RKDevTool, writing loader, parameters and uboot, then there is a line about "destroying partitions by writing wipe_part" (a file you can download in the post), with no clarity or description of how to do this. The steps then move onto flashing another loader to the board. I have done all of these steps in MANY different adaptions and versions and it is always unsuccessful because whatever portion involving the "wipe_part" is missing from the original steps. I am hoping that someone else whose board uses similar procedure sees this and can correct the instructions and make SD boot possible again. It's really aggravating that my board is being held hostage to this - the person who wrote the instructions has worked on other projects with similar steps and others have had the same issue with their incomplete/incorrect instructions in those posts, and so far will not reply regarding this. I've tried 4 different versions of RKDevTool and worked for around 7 hours on this so far with no success. I'm hoping someone else can come save me!

Reply from the company that makes Cubox: the SOC of the MiiPC is the same family as the Dove based SOC that was in the original Cubox device. We're getting closer.

Hello, everyone. I'm using Armbian_25.5.2_Orangepizero3_bookworm_current_6.12.30-homeassistant_minimal on 4GB OpiZero3. When booting from sd, the bluetooth controller is initialized correctly. I made a boot from usb-ssd via armbian-config: everything works fine, but the bluetooth controller is not initialized. /sys/class/bluetooth is empty. Switch back to sd - it works again. Boot from ssd - no. I compared whether it transferred the distribution correctly from sd to ssd - all files are the same. What could be the problem?

Thanks for sharing, Nick A This image is working on my device. Now I want to know more about how to create this image. Can you plz share with me any tutorial or documentation on this. Thank a lot

Hello everyone, I am creating a custom Armbian build for OPI5 && OPI5b. The task is as follows: install several packages in the system and fully configure it. While there are no issues with installing packages and configuring the network, there is a peculiarity with the login and password. Specifically, sometimes after writing the image to the emmc opi5b or SD card, the system allows me to log in with my pre-configured credentials, but other times, when flashing the same image, the system simply rejects my pre-set data and displays the message “Login Incorrect.” How I set the initial settings for the system: In /root there is a file called .not_logged_in_yet, from which data is pulled when you first log in to the system, thanks to which it is automatically configured (this method was tested on nanopi m6 and RPI 3b+) and everything worked fine, but for some reason, it is with orangepi 5 && orangepi 5b that I get such artifacts. My .not_logged_in_yet looks like this: # Network settings PRESET_NET_CHANGE_DEFAULTS="1" PRESET_NET_WIFI_ENABLED="1" PRESET_NET_WIFI_SSID="MyWiFi" PRESET_NET_WIFI_KEY="MyWiFiPassword" PRESET_NET_WIFI_COUNTRYCODE=“RU” PRESET_CONNECT_WIRELESS="n" PRESET_NET_USE_STATIC="1" PRESET_NET_STATIC_IP="192.168.1.100" PRESET_NET_STATIC_MASK=“255.255.255.0” PRESET_NET_STATIC_GATEWAY="192.168.1.1" PRESET_NET_STATIC_DNS="8.8.8.8 8.8.4.4" # System settings SET_LANG_BASED_ON_LOCATION="n" PRESET_LOCALE="ru_RU.UTF-8" PRESET_TIMEZONE="Europe/Moscow" # Root settings PRESET_ROOT_PASSWORD="mysecretrootpass" # User creation PRESET_USER_NAME="user1" PRESET_USER_PASSWORD="mypassword" PRESET_DEFAULT_REALNAME="User One" PRESET_USER_SHELL="bash" For my Armbian image, I use the VENDOR 6.1 kernel - ubunu 22.04 jammy. What could be the problem?

@Nick AI don't think it's the same issue.Later, I entered the Android system and used the dd command to flash the x96q tvbox IMG file into the mmcblk. It successfully ran the armbian via eMMC.Next, I will try the x98h Wi-Fi chip driver.Thanks

@buzz89 never heard of it. If you have root access you probably can.

@prahal thank you so much for explaining that. I tried downloading the https://fi.mirror.armbian.de/incoming/prahal/rock-5-itx/archive/Armbian_25.8.1_Rock-5-itx_bookworm_vendor_6.1.115_xfce_desktop.img.xz but Balena Etcher would fail at the end of the validation process. However ... from RoobiOS I can enter that path and it successfully downloads the image and appears to write it successfully to the NVMe drive and then reboots but only gives a single flash of blue SATA III lights and no display. I erased the NVMe partition and tried the Armbian_25.8.1_Rock-5-itx_noble_vendor_6.1.115_minimal.img.xz image with the same result. Same with Armbian_25.8.1_Rock-5-itx_bookworm_vendor_6.1.115_minimal.img.xz - no joy. Eventually I just went with the RADXA OS. It installs KDE Plasma so I've booted to command line and removed KDE and associated packages. Hopefully that effectively gives me a CLI image. Now to work through the error messages in the bootup and remove any unnecessary steps... after I manage to set the default font-size to something that doesn't have me squinting like Mr Magoo 🤣🤣

@Randlin

@Piotr si guess this problem doesn’t exist with miniarch. I’ll have to update my build to 6.16 kernel with warpme patches. I’m busy right now so it might take awhile.

@ARx8 try miniarch. https://github.com/warpme/miniarch/releases/tag/f3b14fbae071 I think this box is having the same issue as yours?

Hello everyone, i somehow compiled u-boot for x96q with 1.5Gb DRAM, and i created "instruction", how i managed to compile it: https://gist.github.com/VMTestik/257c836f1602a64fea8c05ecedc650b0 Maybe it will be helpful or useful

@laibsch thank you. @TonyMac32 any ideas? Update: The Bookworm minimal image does fully boot. Just not Trixie.

above PR is merged

Board: ODROID HC4 Kernel: 6.12.42-current-meson64 Issue: PWM fan control completely non-functional despite software appearing to work Problem Summary: The HC4's PWM fan runs at constant speed regardless of PWM settings. Manual PWM control has zero effect on fan speed, even when setting PWM to 0 (fan should stop/slow) or 255 (full speed). What I've Tried: Hardware Testing: Verified fan wiring with schematic (Pin 1=+5V, Pin 2=GND, Pin 3=TACHO, Pin 4=PWM) Tested with Noctua NF-A4x10 5V PWM fan (confirmed working on other systems) Swapped PWM/TACHO wire positions - no change Software Testing: Manual PWM control: echo 0|50|255 > /sys/class/hwmon/hwmon2/pwm1 - no response Direct PWM chip control: /sys/class/pwm/pwmchip0/pwm0/ - no response Tested different PWM chips (pwmchip0, pwmchip1) and channels Stopped fancontrol service to avoid conflicts Verified PWM files exist and accept values Overlay Testing: Tried existing Armbian overlays: meson-g12-pwm-gpiox-5-fan Copied PWM overlays from official ODROID Ubuntu image: fanspeed-full.dtbo, pwm_a-pwmfan.dtbo, etc. Overlays present in filesystem but show no loading errors or effects System Status: PWM driver loaded: meson-pwm ff802000.pwm: using obsolete compatible PWM devices detected: /sys/class/pwm/pwmchip0, /sys/class/pwm/pwmchip1 Device tree shows: cat /proc/device-tree/pwm-fan/compatible = pwm-fan Fan gets power and runs, but zero PWM response Research Findings: Found GitHub discussion showing HC4 PWM was broken in Armbian (August 2023 merge/revert cycle) where "PWM pulse reading was removed from HC4." This appears to be an ongoing regression in 6.x kernels. Similar issue documented in forum post about ODROID C2 where user had PWM files working but "nothing happen" until they manually patched device tree. What I Want to Contribute: I'd like to properly fix HC4 PWM fan control and contribute the solution back to Armbian. This affects anyone wanting quiet operation or proper thermal management. Need Guidance On: I'm relatively new to device tree development and embedded Linux, but I'm motivated to learn and contribute a proper fix. I'd appreciate guidance on: Where to start - What's the best approach for a beginner to debug device tree PWM issues? Learning resources - Any recommended documentation for understanding Amlogic PWM/device tree development? Debugging methodology - How to compare current vs. working device tree for PWM routing? Development workflow - What tools should I learn for creating/testing HC4-specific overlays or patches? Contribution process - How do device tree fixes typically get submitted and reviewed in Armbian?