All Activity

Hi, Is it appropriate to raise this at https://github.com/armbian/build/issues, since the Headphone Jack audio is available on older version of the kernels and not available in the latest kernels? Thanks for your guidance.

Thanks @bschnei. I tried for a while to figure out what to do, but couldn't really understand.. not sure if i should be trying to set it to thumb or arm mode at that point, even. I did fallback to earlier binutils, and the build went fine. However, trying to boot from the flash-image.bin with mox-imager results in incomplete load and reset back to mmc/spinor ... any ideas? -- /mox-imager/mox-imager -D /dev/ttyUSB0 -t -E /srv/development/espressobin-ultra/2026-03-bschnei/built-on-old-bb/flash-image-20260401-bb.bin TIM version 3.6.00, issue date 2026-04-01, non-trusted, 3 images, 0 keys, boot flash sign SPI NOR Reserved area packages: CRV2 (size 20) CIDP (size 32) Consumer TBRI, packages: GPP1 GPP2 DDR3 GPP1 (size 852) Ignore timeouts in instructions: 0 GPP2 (size 456) Ignore timeouts in instructions: 0 DDR3 (size 2024) Initialize DDR memory: 1 Term (size 8) Found TIMH, hash sha-256, encryption none, size 3780, load 0x20006000, flash 0x00000000 Found WTMI, hash sha-256, encryption none, size 24336, load 0x1fff0000, flash 0x00004000 Found OBMI, hash sha-256, encryption none, size 1140712, load 0x64100000, flash 0x00015000 Going to send images to the device Sending escape sequence, please power up the device Received sync reply Sending escape sequence with delay Detected BootROM command prompt Sending wtp sequence Received ack reply Sending clearbuf sequence Initialized UART download mode GetVersion response: version 3.4.01, date 2016-05-15, CPU ARMA Sending image type TIMH 100% sent in 00:00 TIM-1.0 mv_ddr-devel-g7bcb9dc DDR4 16b 1GB 1CS Sending image type WTMI 100% sent in 00:02 Sending image type OBMI 100% sent in 01:40 [Type Ctrl-\ + c to quit] WTMI-devel-18.12.1-a3e1c67 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.213V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware v2024.04.15-6-gd6d9646 (Apr 1 2026 16:32:36) Running on ESPRESSObin Ultra NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL1: Built : 16:32:41, Apr 1 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL2: Built : 16:32:51, Apr 1 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL31: Built : 16:32:56, Apr 1 2026 U-Boot 2026.04-rc5-00019-gc704af3c8b0f (Apr 01 2026 - 17:08:14 -0400) DRAM: 1 GiB "Synchronous Abort" handler, esr 0x96000044, far 0xd5380000aa1e03fd elr: 0000000000036a08 lr : 0000000000036a64 (reloc) elr: 000000003ff4aa08 lr : 000000003ff4aa64 x0 : 0000000000000098 x1 : d5380000aa1e03fd x2 : 0000000000000000 x3 : 000000003fb07b00 x4 : 0000000000000000 x5 : 0000000000000000 x6 : 0000000000000000 x7 : 000000003fb07b20 x8 : 000000003faff64c x9 : 000000003fb00034 x10: 0000000000000000 x11: 0000000000000600 x12: 000000003faff70c x13: 000000003faff9b0 x14: 000000003faff9b0 x15: 0000000000000000 x16: 0000000000000000 x17: 0000000000000000 x18: 000000003fb03e10 x19: 0000000000000000 x20: 000000003fb07780 x21: 000000003fb077a0 x22: 0000000000000000 x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 000000003faff7a0 Code: f9405261 f9005274 f81e02a0 f9000681 (f9000034) Resetting CPU ... resetting ... TIM-1.0 WTMI-devel-18.12.1-1a13f2f WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.213V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL1: Built : 22:43:22, Mar 4 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL2: Built : 22:43:25, Mar 4 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL31: Built : 22 U-Boot 2020.10-6.0.0-g29a6ea5c-dirty (Mar 28 2026 - 21:49:54 -0400) Model: gti cellular cpe board DRAM: 1 GiB Comphy chip #0: Comphy-0: USB3_HOST0 Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link up MMC: sdhci@d8000: 0 Loading Environment from SPIFlash... unrecognized JEDEC id bytes: 61, 12, 9b *** Warning - spi_flash_probe_bus_cs() failed, using default environment Net: Error: neta@30000 address not set. mdio_register: non unique device name 'neta@30000' No ethernet found. starting USB... Bus usb@58000: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb@5e000: USB EHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb@5e000 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Marvell>>

@alexc Thanks for all your hard work! I’ve put together an Armbian build using your kernel—you can check it out here: https://github.com/NickAlilovic/build/tree/Radxa-mainline-WIP

So, I went through this recently on an NVidia device, and device tree overlays really aren't that hard. But there's a few things you'll need to get set up first, and not having an M5 to check, you'll probably have to do some reading / verification. I make no claim this will work out of the box for you. But I imagine this will save you a lot of reading. There's an example .dtbo at https://github.com/KF0ARE/i2c0-rtc.dtbo/blob/main/i2c0-rtc.dtbo you should look at, and you can decompile it with the following: dtc -O dts -o i2c0-rtc.dts i2c0-rtc.dtbo Which contains a fragment you'll be interested in, explicitly for the DS3231 ... /dts-v1/; / { compatible = "brcm,bcm2708"; ... snip ... fragment@3 { target = <0xffffffff>; __dormant__ { #address-cells = <0x01>; #size-cells = <0x00>; status = "okay"; ds3231@68 { compatible = "maxim,ds3231"; reg = <0x68>; status = "okay"; phandle = <0x04>; }; }; }; ... snip ... }; But you can't use this directly, because "compatible" doesn't include your M5, and "target" doesn't point anywhere useful in your DT. But it does call out the ds3231, and that it's at I2C address 0x68, so you can use that to find where the kernel thinks your RTC is. Take a look at where your I2C buses are (/dev/i2c-*) and just scan each of them like this to see if you can find it: tparys@pebble:~$ sudo i2cdetect -y -r 0 # NOTE: I2C bus #0 is /dev/i2c-0 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: UU -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- In the above, address 0x10 is unusable as there's something else bound at that register. But check your buses to see if you can find 0x68. If you see something other than "--" or "UU" there, that's probably it. If you can't find it, double check that it's connected, powered on, and that your I2C bus has been enabled (might need to enable via DTB). Once you find it, you should be able to register it by doing something similar to the below as root (driver and I2C bus may be different): echo ds3231 0x68 > /sys/bus/i2c/devices/i2c-0/new_device If that works, and creates a /dev/rtc0 device, test that it's working with "hwclock". Once it's working, it's time to make your .dtbo. You'll probably want to dump your main .dtb with the same dtc command above, and look for i2c-0 (or whatever other bus you found), as well as a .dtbo or two for your M5 to find text to enter for "compatible". And you'll end up with something like this, saved as "m5-ds3231.dts" (or whatever): /dts-v1/; /plugin/; / { compatible = "brcm,bcm2708"; // <---- Change this fragment@0 { target = "i2c-0"; // <---- Change this __overlay__ { #address-cells = <0x01>; #size-cells = <0x00>; status = "okay"; ds3231@68 { compatible = "maxim,ds3231"; reg = <0x68>; status = "okay"; phandle = <0x04>; }; }; }; }; And you'll compile it like this: dtc -@ -O dtb -o m5-ds3231.dtbo m5-ds3231.dts And check it against your M5's DTB like below. Note that "target" or "target-path" has some odd syntax requirements. Quotes with a leading slash is a full path to your I2C device. Quotes without a leading slash is an alias. And angle brackets with an ampersand is a label (not everything has an explicit label). Worst case scenariou, call out the whole path in "target-path" with a leading slash, and call it a day. I beat my head against a wall for a while here before I realized I could test this without rebooting ... fdtoverlay -i /path/to/your/used.dtb -o modified.dtb m5-ds3231.dtbo And then add it to your overlay directory (/boot/dtb/CHIPNAME/overlays), enable it armbianEnv.txt, and give it a go? There's also two kernel build configs that may be of interest as well: CONFIG_RTC_HCTOSYS_DEVICE="rtc0" CONFIG_RTC_SYSTOHC_DEVICE="rtc0" The first triggers the kernel to load time from a given RTC when it first shows up. The second will tell the system to update RTC when locked against NTP. FYI, it seems that you can change these only with a new kernel build.

I am glad that it's possible to use a different ffmpeg version than what the distribution expects. (it gives me hope of installing it in Trixie, instead of changing over to the newest Ubuntu) Did you install the locally compiled ffmpeg at OS level, or did you keep it in a folder within your /home/username/...?

@andrey.lobov try to upgrade the kernel or pick a fresh image from the github repository. The tm16xx driver has been reenabled recently after having being disabled due to partial kernel upstream.

@Mohammad Adel AW869A and AIC8800 are the same WiFI chips. You should have WiFi working.

After I closed the lid of my chromebook Armbian decided to die even across reboots. https://drive.google.com/file/d/1gkEzVoY5QkNcWq3MOKYUSc8nkFYg91p-/view?usp=sharing Video of what I see https://drive.google.com/file/d/17yhnIjzkiYkkVohFrLf7MKDtYyb0xfOL/view?usp=sharing

I finally successfully got Armbian installed on my Pinebook Pro's eMMC. That should be giving it its best possible performance. I thought you may all be interested in compiling a list of games that work at least reasonably well on it given its restrictions of being ARM64 architecture, 1.8GHz CPU & 4GBs RAM. So to start here is a list of the ones I currently have on mine. I may try more later but for now I'm limited by the stock 64GB eMMC that the PCP came with... 0AD - 3D RTS Cave Story - Pixel Art Metroidvania Dr Robotnik's Ring Racers - Kart Racer Dune Legacy - RTS Endless Sky - Space Sandbox Flare - Fantasy RPG Freeciv - Strategy Freecol - Strategy GZDoom - Doom Engine for Mods & Total Conversions Hedgewars - Worms "Homage" Neverball - Monkeyball "Homage" Neverputt - Miniputt Golf Game Open Fodder - FOSS Engine for "Cannon Fodder" OpenRA - FOSS RTS Engine for "Tiberian Dawn", "Red Alert" & "Dune 2000" Open TTD - Transit Management Sim OpenTyrian - FOSS Engine for Top-Down Shmup "Tyrian" Perfect Dark - PC Port of N64 Game with Keyboard/Mouse Support Pico-8 - Indie Pixel Art Gaming & Development Platform Pingus - Lemmings "Homage" ScummVM - FOSS Engine for Classic Point & Click Games Sonic Robo Blast 2 - 3D Platformer The Ur-Quan Masters - FOSS Port of Space Sandbox "Star Control II" Xonotic - Arena Shooter FPS There are other games I have not yet personally tried like OpenHV, SuperTuxKart, other emulators etc but if anyone can confirm they work reasonably well on the Pinebook Pro then please let the rest of us know. All ScummVM games I've tried from King's Quest I to Grim Fandango work perfectly. However GZDoom will struggle with especially demanding modern Doom mods like Trenchfoot, Auger Zenith, Inquisitor III, Godless Nite etc. but most like Aliens: Eradication, Ashes 2063/Afterglow, Brutal Doom, Castlevania: Simon's Destiny, Irontusk's Diablo 3D, Revenge of the Triad etc run just fine.

Welcome to the latest Armbian Newsletter: your source for the latest developments, community highlights, and behind-the-scenes updates from the world of open-source ARM and RISC-V computing. The past two months have been particularly active for the embedded ecosystem. At EMBEDDED WORLD 2026, developers, hardware vendors, and open-source communities gathered to showcase the latest innovations shaping the future of embedded computing. In parallel, the Armbian project continues to evolve with new releases, expanded board support, and ongoing improvements to the build framework driven by the contributions of its global community and the growing demand for reliable Linux on ARM and RISC-V platforms. SPONSORED Join us in making open source better! Every donation helps Armbian improve security, performance, and reliability — so everyone can enjoy a solid foundation for their devices. Github HighlightsThis week in Armbian development saw a significant expansion of hardware support, including new board images and compatibility for devices such as the Ariaboard Photonicat 2, SpacemiT MUSE Book, NanoPC T6 Plus, and Mekotronics R58S2. Kernel patches were updated across multiple platforms, notably for Rockchip and Sunxi families, enhancing stabilityArmbian blogMichael RobinsonMy First embedded world and I Already Can’t Wait for the NextI’d been putting this off for years. Every March, I’d read someone else’s embedded world recap, tell myself “next year”, and go back to my terminal. This year I actually went and I’m still processing everything I saw. First things first: the team Before I talk about any stand orArmbian blogDaniele BriguglioArmbian Q1 2026: Technical Milestones and the Road to Embedded WorldThe first quarter of 2026 has been a period of significant technical consolidation for the Armbian project. Driven by the v26.02 (Goa) release cycle, the project has focused on three core pillars: aggressive framework refactoring, the stable rollout of the Linux 6.18 LTS kernel, and the maturation ofArmbian blogMichael RobinsonView the full article

The first quarter of 2026 has been a period of significant technical consolidation for the Armbian project. Driven by the v26.02 (Goa) release cycle, the project has focused on three core pillars: aggressive framework refactoring, the stable rollout of the Linux 6.18 LTS kernel, and the maturation of the Armbian Imager utility. Core Framework RefactoringA primary objective this quarter was the reduction of technical debt within the armbian/build repository. The development team initiated a systematic cleanup to improve build reliability and maintenance. Toolchain Optimization: Through a series of pull requests, including #9218, #9252, and #9256, significant "dead code" was removed from the internal toolchain. This refactoring simplifies the logic required to support a diversifying array of ARM and RISC-V architectures.mmdebstrap Transition: The framework has officially transitioned to mmdebstrap as the exclusive engine for rootfs creation (#9512). By deprecating the legacy debootstrap method, the project ensures faster, more consistent, and reproducible builds across varied host environments.Bash Modernization: Internal build scripts have been transitioned from POSIX to Bash syntax to leverage modern shell features and enhance overall script reliability.Kernel and Hardware IntegrationQ1 marked the broad adoption of the Linux 6.18 LTS kernel series, providing improved driver support and hardware abstraction for tier-1 platforms. Linux 6.18 LTS Rollout: Stable support for the 6.18.y kernel was merged for major families, including meson64, rockchip64, and UEFI targets (#9069, #9086).Hardware Support Expansion:SpacemiT MusePi Pro: Full integration and kernel patching were completed (#9422).Orange Pi RV2: Initial support and nightly build availability were established for this RISC-V target.Radxa Rock 4D & ODROID M2: These boards were elevated to the stable support tier within the 26.02 release.Firmware Updates: U-Boot was bumped to v2026.01 for several platforms. Notably, boot delays on the Orange Pi 5 series were addressed via updated U-Boot candidates (#9450).Ecosystem Tools: Armbian ImagerThe Armbian Imager has transitioned from a utility to a cornerstone of the project’s user experience, with a focus on security and onboarding efficiency. Cross-Platform Security: Code signing was implemented for both macOS and Windows artifacts to reduce installation friction for non-Linux users (imager#87).Performance Improvements: The utility now features optimized image decompression and enhanced device disconnect detection (imager#28).Automated Reporting: A new AI Actions Report workflow (armbian.github.io#165) was implemented to automate development highlights, providing greater transparency into the commit history for the community.Strategic Industry AlignmentThe technical trajectory of Q1 was intentionally aligned with Armbian’s presence at Embedded World 2026 in Nuremberg. By showcasing the framework and Imager as guests of Seeed Studio, the project demonstrated its readiness for industrial-scale deployment. The shift toward mainline kernel and U-Boot support—specifically targeting the retirement of vendor-specific bootloaders—remains a priority for long-term security and professional-grade stability. Contributors & Credits The progress in Q1 2026 is the result of sustained contributions from the Armbian Dev team and the wider community. Detailed changelogs and commit histories are available at github.com/armbian/build. View the full article

I'd been putting this off for years. Every March, I'd read someone else's embedded world recap, tell myself "next year", and go back to my terminal. This year I actually went and I'm still processing everything I saw. First things first: the teamBefore I talk about any stand or chip, I need to tell you what made this trip different from anything I've done before. There were five of us from the Armbian team at the show: Igor, Werner, Meko, amazingfate, and me. Five people. Four countries. Some of us had worked together for years and never met in person. You know how it is in open-source, you collaborate through GitHub, you argue about patches on the mailing list, you review each other's code at odd hours. But you don't always know the face behind the username. Meeting those people for real, shaking their hand, having a coffee together, that's something no pull request can replicate. And honestly, it was worth the trip on its own. The show itself: I wasn't ready for thisArriving at the Nuremberg Messe for the first time is a genuine shock. I knew embedded world was big. I did not know it was this big. Enormous halls, thousands of exhibitors, tens of thousands of attendees. On day one I got genuinely lost between the pavilions spent a solid half hour wandering with no idea where I was. I'm told this is a rite of passage. What surprised me most about the atmosphere is how concrete everything felt. This isn't a conference where people pitch vaporware from behind polished booths. Engineers and developers everywhere, talking about real problems, showing real hardware. You can walk from a giant like Qualcomm to a small team doing something fascinating with a handful of sensors and both conversations feel equally substantive. What we saw on the floorRockchip was a mandatory stop for us, and they didn't disappoint. On their stand: the RK3572 EVB an evaluation board we hadn't seen in person before. Reading specs in a datasheet is one thing. Seeing the board running, understanding its real-world size, its connectors, how it behaves, that's a completely different kind of knowledge. The kind you can only get by showing up. Rockchip Employees (Most left and right) and Jianfeng Liu, Mecid Urganci & Igor PecovnikSeeed Studio had live demos of AI Vision and AI Sound, and the one that genuinely impressed me was their AI camera with a built-in NPU doing real-time object recognition. I'm not talking about laggy, stuttering inference, it was smooth. Fluid. The kind of performance that makes you stop walking and just stare for a minute. Seeing that level of real-time AI running on a compact edge device was one of those moments where the future stops feeling abstract. Seedstudio x Armbian (Maximilian Riedl , Igor Pecovnik, Jianfeng Liu, Daniele Briguglio)Qualcomm brought the Arduino Ventuno Q, and this is where things got interesting and a little funny. meko had already run his benchmarks on the board when amazingfate noticed something: Chromium's hardware acceleration wasn't enabled. So he enabled it. Right there. Directly on the board. In front of the stand staff. The reaction from the Qualcomm team? Complete, genuine astonishment. They didn't see it coming. That's what happens when you bring a group of Armbian developers to a trade show, we don't just look at things, we poke at them. Armbian at the Foundries.io boothCollabora was present at the show, and amazingfate got to meet some of the team. Their kernel and GPU driver work is always relevant to what we do, so that conversation mattered even if I wasn't there for it personally. The moment that hit hardest: Armbian on the BeagleBadgeDuring a meeting with the BeagleBoard.org team inside the show, they showed us their brand new project: the BeagleBadge. Launched right there at embedded world 2026, it won Best in Show in the Wearables category; a Linux-powered wearable badge with a 4.2" ePaper display, dual-core ARM Cortex-A53, Wi-Fi 6, LoRa, and more sensors than I can list here. Built around the Texas Instruments AM62L32, manufactured by Seeed Studio. Impressive hardware. But here's the part that actually stopped me in my tracks: Armbian was running on it. There's an official "Armbian BeagleBadge demo for EW2026" image — Debian Trixie, Linux 6.12 — listed right on the BeagleBoard.org site. Our OS. On a Best-in-Show winning badge. At the world's biggest embedded show. That's not a small thing. That's the community's work showing up exactly where it matters. What embedded world taught me about where this industry is goingThree days of walking, talking, and observing gives you a pretty clear picture of the currents moving through the embedded world right now. Edge AI is not a trend anymore, it's infrastructure. Every major vendor had something running inference locally, without cloud, on modest hardware. This is real, it's shipping, and it's going to reshape what we expect embedded systems to do. Open-source has earned its seat at the table. I half-expected it to be the hobbyist corner of the show. It wasn't. Companies are building on Linux, on open stacks, on ecosystems maintained by communities like ours. That's not charity, it's strategy. And it means the work we do in Armbian matters more than we sometimes give ourselves credit for. The line between prototype and product is razor thin. At most stands you'd see a mix: shipping products, reference designs, things that will exist in six months. That gap is where the interesting information lives; what's coming, which platforms are getting serious investment, which vendors are committed to mainline Linux support. You don't learn that from a datasheet. You learn it by being there. Would I go back?Without a second thought. If you're an Armbian community member who's been putting this off the same way I was stop putting it off. The technical exposure is valuable. The networking is real. And meeting the people you build things with, face to face, is something that doesn't have a substitute. The show runs every year in Nuremberg. I'll be there. See you in 2027. 🇩🇪 View the full article

X98H PRO ------ WIFI AW869A ------ WIFI 6

https://drive.google.com/file/d/1--FlGP4JIjmdrjR9El9vB_rbIbIKM0IM/view?usp=sharing

https://drive.google.com/file/d/1DF7qvYoCEwVHuPMI3v9M9vvotq5hwlca/view?usp=sharing

mirror.aarnet.edu.au is still listed on that page

@Mohammad Adel I need to know the physical WiFi and Ethernet chip model number on your board. If you can take a high resolution picture or just tell me the model number. https://openwrt.org/toh/xunlong/orange_pi_zero_3 is the closest model. But you need to edit the device tree. (dts) and u-boot defconfig.

I know this might get ignored, but honestly, I don’t really mind. I just want to report something I noticed a few days ago, which I initially thought was caused by my previous setup. I was running a Radxa CM5 with a Waveshare CM4 Nano-C board, using an Armbian image for the Rock 5A. This was the only way I could get it working with mainline support. I’m aware this setup is far from standard I’m essentially using the wrong image but that’s because the Radxa CM5 IO board isn’t compatible with the Waveshare Nano board. On top of that, Armbian doesn’t officially support the CM5 RPi-CM4 IO board provided by Radxa (which does work with the Waveshare Nano, but their image is extremely unstable updating it to Trixie bricks the system). The main issue I noticed was with Wi-Fi (using a USB Wi-Fi AC dongle). By default, it’s broken. I managed to restore it using armbian-config and network setup, but even then, the system doesn’t show any Wi-Fi options in Network Manager, despite being connected and working. I didn’t report this earlier because my setup is quite unusual, and I couldn’t be sure if the issue was specific to me. However, today I tested something else. I revived my MSI GS73VR (a 2017 x86 laptop with a GTX 1060) and tried several Linux distributions. I ended up installing Armbian UEFI (the x86 version of Armbian Trixie). As a side note, the Trixie download link on the website is broken you have to dig through the internal download pages to find it. After installing it on an NVMe drive and completing the setup, everything initially worked fine. But after one reboot, I encountered the same Wi-Fi issue: freezing and inconsistent behavior. This time, I hadn’t used armbian-config or any network tweaks. The system doesn’t properly detect or display Wi-Fi in GNOME settings, even though it is actually connected and working in the background. So this seems to be a broader issue, not just related to my ARM setup. I don’t know exactly what’s wrong with Armbian, but my main criticism has always been Wi-Fi support—especially for USB dongles. It feels poorly maintained and lacks consistency. I was told years ago that mainline support would resolve these issues, but Armbian UEFI on x86 should already be at that stage, shouldn’t it? Something clearly isn’t right here. It’s frustrating because this feels like the last missing piece for an otherwise solid system. Despite my criticism, I’ll admit Armbian has grown on me. On x86, there are better alternatives like Fedora, but on ARM, Armbian is still one of the best options. Anyway, apologies if this is posted in the wrong place. The official channels require logs, and I don’t feel like rebuilding my old broken setup just to gather them. If no logs means no help, then so be it. Maybe I’m the only one experiencing this—but I doubt it. Most people probably just plug in Ethernet and avoid dealing with Wi-Fi altogether. It is what it is.

Hey! i saw you guys advanced a lot in this. I tried to re-solder the wires to see if i could get RX/TX, but no dice.

How do I display information from a Linux server

Hi all, I have an RK3318 TV box (A95X R2_V20). The front panel controller is TM1628. I’m running Armbian 23.11.1 with kernel 6.19.0‑edge‑rockchip64. Problem: tm16xx is not enabled in this kernel (CONFIG_TM16XX_* not set), and there is no rk3318x-config in this image. I tried to locate tm16xx sources in current Armbian kernel trees and mainline, but the driver is missing, so I can’t build it from the local headers. I have active Docker projects (avito-bot) on this box and don’t want to reinstall the system, and previous two reinstalls ended with apt issues, so I’d prefer to avoid a fresh image. Question: Is there a known external tm16xx driver repo (or patch) that can be built as an out‑of‑tree module for RK3318? If yes, could you point me to the source and any required device‑tree overlay/pin mapping for TM1628? I already posted board photos and dtb above (my post is still unanswered), so please refer to that if needed. Thanks!

The flashing guide points to a github repo which mentions only xiaomi but not oneplus. Can I follow that?

I'm a complete novice in the area of Linux on phones. I want to use Linux on my oneplus 8t and I am excited to find that armbian has official support for this. But before I install armbian on my phone, I am wondering if I can restore to android after I install armbian. I have another question which may be a bit offtopic: how hard is it to add support for oneplus 8t to Mobile NixOS? Thanks in advance.

Mirrors come and go. Check https://docs.armbian.com/Mirrors/#current-mirrors for an up to date list of active mirrors and its status.

I don't know. I don't maintain this board. Perhaps the maintainer knows which is alexl83. I don't know if he has a forums account though. Try via Github