All Activity
- Today
-
Please report here https://github.com/armbian/imager/issues
-
Thank you to everyone who spent time reading my post, and contributing to it. Having had some free days I decided to give it another try and experimented my helios64 with some of the newer images, none of which worked perfectly (my main requirement is OMV plus its miniDLNA, and couldn't get this installed on noble or trixie, although they were booting and working just fine), eventually running now some bookworm from eMMC and while it seems stable there are some performance issues* (need to re-read that bookworm issues thread again as I did not try all the fixes yet, including the dtb one). *By performance issues I mean some apparently slow reading/writing to eMMC, and network performance on 2.5gb, which I know were thoroughly discusses on that thread, just need to spend more time on trying them out I guess. I'm still a newbie into all this stuff and I was reading a lot again before the new tests. Would anyone be able to recommend some version of an archived bookworm image that I should start from? My device is connected to the router via the 1gb interface, and I have a second cable going directly to my desktop via the 2.5gb interface that lands into a 2.5gb USB-c network card. I don’t have the 2.5gb hardware fix done as when I installed it years ago it was working fine on buster with this layout and my router is 1gb only anyway. In any case, I still have the SD card with the prior setup untouched, so can revert back to it, was just thinking it makes more sense to try something new. Happy new year all of you!
-
@Thermitenjoyer You should be able to just flash it with balena etcher. https://mega.nz/fm/z3w0BTra I uploaded my radxa and orangepi image to mega, im working on NVMe support for orangepi currently, but I dont have the board on hand so im unable to test my kernel-patches. My changes are on github too: https://github.com/rvdr/build/tree/spi-nvme-patches Booting via NVMe works fine when using the sd card for the bootloader, but for some reason I get Kernel panics (not syncing: hung_task: blocked tasks) when using the spi flash for the bootloader.
-
modprobe parameter should be crystal=1, not crystal_26M_en anymore (see here) Otherwise you could try led-conf6 overlay (but I don't know if it fits your board...) which has the attribute esp,crystal-26M-en = <1> in the device tree to set the crystal to 26 MHz
-
By the way, the "tag" says "solved", but that is not true. A tag was required for submission and "solved" was the only selection available in the drop down and the text box was not editable.
-
I have a Orange Pi Zero 2W and want to install a headless ( minimal ) OS. I have tried Armbian 25.5.1. I have an Ubuntu box and I have attempted to write to the SD card using Armbian ImagerImager, by selecting an image from the app as well as downloading an image to use. In both instances, I get a FLASH failure. See the attached image for the diag link. Can anyone give me some insight?
-
Efforts to develop firmware for H96 MAX M9 RK3576 TV Box 8G/128G
Werner replied to Hqnicolas's topic in Rockchip CPU Boxes
standard baud rate for rockchip socs is 1500000. And for the other your cp2102 is no good for this high speed since it cannot handle it. And instead of failing it will output garbage. get ft232r, cp2104 or pl2303 based adapter. -
How to compile a UFS image that can be written using sudo dd?
-
Efforts to develop firmware for H96 MAX M9 RK3576 TV Box 8G/128G
Z1ldj1an replied to Hqnicolas's topic in Rockchip CPU Boxes
Hello all, I've read most of the posts in this topic and see that noone has encountered any problems with TTL interface. My issue is: I soldered 3 pins to the contacts shown in the picture (see title). No mods or special prefs used. 115200 8N1 as standard on all devices used before. Connected CP2102 UART/TTL interface. Result - the interface either gave me nothing or gibberish ASCII symbols with PC speaker crackling crazy. Remedies tried: 1) Tested the CP2102 with already known to work devices (routers mainly). Result - all tried devices display readable text with no gibberish stuff. Conclusion - interface is working properly. 2) Resoldered wires instead of pins (the pins were a bit soft and thin, presuming a bad contact) and added some thicker pins to the ends. Also, used nearest screw hole as GND. Result - even more gibberish with sounding PC speaker at often times. 3) Switched thew wire connections on the RX/TX pins. Result - output stops, nothing shows up. Conclusion - the pins were connected correctly. 4) Joggled the wires and pins while connected (old experience, usually helped to determine RX/TX faulty or mixed connection). Result - the PC speaker doesn't beep anymore but the gibberish didn't stop. It even pulses untouched. Conclusion - applied remedy doesn't affect anything. At this point I've given up and re-read a lot of posts again.. maybe I missed something. Or, maybe there is a way to turn the interface ON/OFF in device preferences (not necessarily Settings). The device came with RZX.V01.20241108.1455 firmware on it. I tried ADB over network (since I don't yet own a USB-A to USB-A v3.0 cable). ADB enters SHELL as root already and I had to check the parameters in build.prop to make sure it dev release (which it is). Strange, I thought, but it's OK. I've managed to make a backup (all images except user data) with ADBDumper. I've made a USB-A to USB-A v2.0 cable figuring it could work but the device is not detected on connection and abandoned that. Any help or constructive advice would be much appreciated. Also, maybe someone mapped the TTL pins to somwere else and a more "comfortable" connection can be made. Thanks P.S. I am no newbie to soldering or SERIAL/TTL connected and programmed devices. Understandably sometimes there are nuances and other times I might miss things. No issue with that. -
Gaming experience with Orange Pi 5 (RK3588) on Armbian
KhanhDTP replied to KhanhDTP's topic in Orange Pi 5
Armbian 25.11.2 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + box64 3.9 (https://ryanfortner.github.io/box64-debs/) + proton-10.0-3-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/download/proton-10.0-3/wine-proton-10.0-3-amd64-wow64.tar.xz) + dgVoodoo2 (https://github.com/dege-diosg/dgVoodoo2/releases) + DXVK-stripped v2.6.2 30~60fps@720p box64 environment variables: Need for Speed Hot Pursuit -
This is my wifi. On legacy image, wifi works if I edit /etc/modprobe.d/esp8089.conf to crystal_26M_en=1.
-
fast search found that 8089 use 40Mhz not 26 so its ignored https://lists.infradead.org/pipermail/linux-arm-kernel/2016-August/447345.html was a talk on kernel developer , some 8089 ignore also 40Mhz some need also 8622 need some 26Mhz or not
-
Hi, Anyone can help me? My chip is rk3229, wifi is esp8089 26Mhz, running 6.12.63 trixie. I followed most of the instructions here without hope. My dmesg said "esp8089: unknown parameter 'crystal_26M_en' ignored" for: options esp8089 crystal_26M_en=1 and "esp8089: unknown parameter 'config' ignored" for: option esp8089 config=crystal_26M_en=1
-
Open hardware is growing faster than ever and breaking in new ways.http://blog.armbian.com/content/images/2025/12/New_review1.png2025 has been a productive year for the Armbian project. As the Single Board Computer ecosystem continues to fragment and expand, Armbian has consolidated its position as the universal glue holding the open-source hardware world together. Our mission remains clear: providing a consistent, reliable build framework that generates operating system for an increasingly diverse hardware landscape. Hardware diversity and development velocityThe most visible metric of our growth is hardware support. This year, the team successfully integrated 61 new boards into the ecosystem. This represents thausands of engineering hours dedicated to debugging, kernel patching, and testing to ensure a stable experience for the end user, regardless of the underlying silicon. The heartbeat of this activity remains our build Framework, which saw 1,946 commits this year. This framework is the engine that allows Armbian to scale across architectures. Our specialized repositories also saw significant contributions: 795 commits to Rockchip Linux, 304 commits to Armbian Config, and 88 commits to the Armbian Imager. Repository2025 CommitsPrimary RoleBuild Framework1,946Core image generation engineRockchip Linux795Kernel support for Rockchip SoCsArmbian Config304System management and TUIArmbian Imager88Cross-platform flashing utility The CI/CD powerhouse: 9.2 years of compute!To maintain quality across hundreds of supported boards, our automated workflows are essential. In 2025, Armbian’s infrastructure ran for a total of 4,885,668 minutes. To put that in perspective, our servers performed the equivalent of 9.2 years of continuous compute time in a single calendar year. This massive undertaking involved 1,510,771 individual job runs, ensuring that every code contribution was properly assembled and tested and every image was built to specification before reaching your SD card. Community: more than just codeArmbian is a community-first project that thrives on shared expertise. While code is our foundation, documentation and education are what empower our users. Newsletter team is seeking contributors to create technical documentation, share practical experience, and write clear instructions and tutorials. If you have a unique project, a "how-to" guide, or an interesting Armbian use case, we encourage you to share your knowledge with the community via the Armbian Forum. Support the MissionMaintaining the infrastructure required for millions of job runs is a significant financial undertaking. If Armbian provides value to your business, research, or hobby, please consider supporting us. Contribute Expertise: Visit our Get Involved Guide to help with development or testing.Financial Support: You can donate via PayPal, Liberapay, or BTC or become a GitHub Sponsor.Every contribution directly funds build infrastructure, CI runners, mirrors, development tools, and hardware enablement, ensuring Armbian remains reliable and up to date. View the full article
-
Good afternoon. Sorry for my English. Happy New Year!!!! Can you change the current theme to MYD-lt527m-16e2d-180-e-sx? I think that's clear now. Thank you. By the way, I've made some progress. Using Android logs, I finally configured, launched, and tested two network interfaces. The iperf3 program showed an average throughput of 90 megabytes per second. Unfortunately, I can't yet extract the device tree using standard tools.
-
Gaming experience with Orange Pi 5 (RK3588) on Armbian
KhanhDTP replied to KhanhDTP's topic in Orange Pi 5
Armbian 25.11.2 Noble XFCE (BSP Kernel: 6.1.115) + PanVk - mesa 26.0 (https://launchpad.net/~ernstp/+archive/ubuntu/mesaaco) + box64 3.9 (https://ryanfortner.github.io/box64-debs/) + wine-10.20-staging-tkg-ntsync-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.20) + dgVoodoo2 (https://github.com/dege-diosg/dgVoodoo2/releases) + DXVK-stripped v1.6.1 ~60fps@720p (Medium settings) box64 environment variables: Prince of Persia - The Forgotten Sands -
[Bug]: Ethernet rarely connecting successfully in Orange Pi 3 LTS
Werner replied to iMagz's topic in Allwinner sunxi
May have found something. Perhaps https://lists.openwall.net/linux-kernel/2025/09/17/618 causes issues. Here is a test image that works around this by adjusting device tree a bit. Please test and report https://testing.armbian.de/Armbian-unofficial_26.02.0-trunk_Orangepi3-lts_trixie_current_6.12.63_minimal.img.xz -
[Bug]: Ethernet rarely connecting successfully in Orange Pi 3 LTS
Werner replied to iMagz's topic in Allwinner sunxi
logs? - Yesterday
-
What happened? Orange Pi 3 LTS rarely recognize ethernet connection. How to reproduce? Flash Orange Pi 3 LTS with an image of the latest version of Armbian. Extra Info The latest images tested which worked flawlessly was: Armbian_community_25.11.0-trunk.437_Orangepi3-lts_trixie_current_6.12.47_minimal.img Armbian_23.8.3_Orangepi3-lts_jammy_current_6.1.53_minimal.img Images tested which didn't worked: Armbian_community_26.2.0-trunk.151_Orangepi3-lts_trixie_current_6.12.63_minimal.img Armbian_community_26.2.0-trunk.100_Orangepi3-lts_trixie_current_6.12.63_minimal.img
-
Standard Debian; select what you want when you run: sudo tasksel
-
Edit ArmbianEnv.txt when machine is unable to boot?
CryBaby replied to Myriade's topic in Rockchip CPU Boxes
If there is nothing in /boot at all then its content is probably in another partition which gets mounted while booting. You will need to find that partition and mount it in your PC to modify it. -
PHC support for NanoPi R76S
Carol-5673 replied to muetzekoeln's topic in Framework and userspace feature requests
Yeah, it makes sense, sadly. The NanoPi R76S has Realtek NICs, but PHC support isn't included into the mainline kernel. The out-of-tree r8125 driver is... let's just say it's not very stable. The in-kernel driver doesn't display PHC at all, so it's not surprising that ethtool -T doesn't show anything. If you're noticing missing MACs and PHC vanishing after a reboot with r8125-9.016.01, it's generally because the driver and kernel versions don't match. That driver is quite sensitive to the internals of the kernel, and things become strange very quickly if udev or the DT bindings don't match up. It's also important to note that even when PHC works with Realtek, it's frequently not fully developed. For example, timestamping could be there, but it won't sync well with ptp4l, particularly when the system is under a lot of demand. So, for PHC accuracy and stability, this board was never meant to be used for serious time sync. In short: No PHC support for mainline kernel out-of-tree r8125 is unstable and breaks easily R76S hardware isn't very good for precise timing. If PHC is a must, Intel i210/i225-based NICs will work considerably better for you. Realtek + PHC is like being in agony mode. -
Same problem here except there's no Desktop option. Only these: - Kernel - Storage - Access - User - Updates Got any other solutions?
-
Helios64 - Unable to transfer install from eMMC to SDCard
Marru_678 replied to unfnknblvbl's topic in Rockchip
You can't truly "force" the boot sequence on Helios64 since U-Boot already checks SD, eMMC, and SATA. The SD card isn't bootable if the eMMC is still booting. Things to check quickly: SD must contain a properly written raw Armbian image (dd / balenaEtcher). You can't copy files. Check that it contains a bootloader and not simply an ext4 partition. Before starting, turn off the power completely (warm reboots might disregard SD). Once the computer has started, use lsblk -f to inspect the layout of the devices. On Helios64, the mmc numbering does change, therefore tools may conceal devices to save the live rootfs from being destroyed. If you want to be 100% sure, unplug the eMMC for a short time. If it boots, the SD is OK. The boot sequence isn't the problem; the SD image is. - Last week
-
It said "archlinux" because I took something from my notes for my Arch Linux images. It was only an example command and you can put there anything on how you named the image. I did not include image creating and bootrapping an OS into the image. I mainly wanted to show you how you can build and flash your custom u-boot. You get these "idbloader.img" and "u-boot.itb" files from the steps I laid out. If you download u-boot, bl31, ddr and compile it, you will see the files in the folder. I am sure you will understand this pretty fast. :-) Create an empty img file Create a rootfs partition (should start at 16MB) Bootstrap Debian or Ubuntu into the image Then start with the u-boot stuff above. By the time 6.19 drops, you will be a master in building images. :-)
