All Activity

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 v1.6.1 ~60fps@720p Need For Speed Most Wanted

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-9.22-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/9.22) + dgVoodoo2 (https://github.com/dege-diosg/dgVoodoo2/releases) + DXVK-stripped v1.6.1 ~40fps@720p (Ultra High settings) Oblivion

https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first/#comment-199170

Hey i am looking for a suitable armbian distro for my tv box with the allwinner h313, 2gb ram and 8bg emmc.

I have the following (maybe stupid) question, what needs to be done to be able to use all the features of the RK3588 by adding the dts file. Example: there used to be /dev/tpm0 which has been missing for several versions. As I said earlier, the latest dts is much shorter. My question is not an attempt to nitpick, but a serious question. And what can I help with. As in my case, there is a peculiarity. I have a FriendlyElec NanoPC-T6 and it is used in "production" in my network. And I do not have the opportunity to reinstall it. I would like to make a dts file that allows using the full functionality of the RK3588. Again, I want to say, I do not want to blame anyone or nitpick, but to find a solution, and whether I can help with anything and if Yes, how and with what. P.S. Since today is the 31st, if you want we can postpone the discussion until January 1st or 2nd

Okay, didn't bother checking beforehand

Hello SteeMan, Thank you I am going to look for a usb a to usb a cable Maybe ik can make one myself Happy New Year 🎉🎉🎉

I have an old MXQ Pro 4K (based on the original S905, not S905X or S905D, the original S905) which I tried to install armbian on, but I didn't know extra things were needed to set up uboot and dtb correctly, so I just flashed the image, put the SD card in my box, ran `reboot update` from Android to boot to the SD card, it showed the MXQ Pro logo, rebooted, went back to the MXQ Pro logo, and I can't get it to go past that. My box has a weird firmware issue (started immediately after a firmware restore so I don't think it's hardware damage) where the button in the headphone jack just... doesn't work, even when holding it, it still tries to boot to the eMMC, and now I have no way of getting back into Android, and I can't boot from the SD card due to the button not working, so, is there any hope for my box here? Or have I effectively hard bricked it? I don't have a USB-A to USB-A cable for USB burning tool, and I will not be purchasing one, this was a spare box I've had laying around for eons and I don't think it's worth spending any money on -- I could probably get a much better box for the same money.

Armbian is carrying it for quite some time. So no excuse to not just use it already.

@usual user In essence, I'm not waiting for someone to do the work for me. Realistically, if I knew exactly how to do it, I would have done it and described it here. If I make something that could be useful for someone or the community, I share it. I rarely write because in most cases I use standard things and there's not much to write about, or I use quite non-standard solutions that for most people aren't solutions.

I think this patch can also be backported to 6.18.y in Armbian if @rpardini didn't plan to do anyway.

http://blog.armbian.com/content/images/2025/12/githubhighlights-2.pngThis week in Armbian development saw a series of refinements and maintenance updates across the build and configuration repositories. Contributors focused on workflow standardization, cosmetic improvements such as board name adjustments, and documentation enhancements. Several technical fixes addressed typos, property mispellings, and package issues, while platform support was expanded with kernel and boot improvements for devices like the Mekotronics R58-4x4 and MusePi Pro. Notable changes also included vendor reorganization and the addition of fallback logic for Ubuntu LTS releases. Overall, the activity reflects ongoing efforts to streamline processes and bolster hardware compatibility. Adjusting board names - cosmetic issue. by @igorpecovnik in armbian/build#9116chore: cleanup mirror_to_codeberg.yml workflow. by @igorpecovnik in armbian/build#9133chore: standardize workflow names. by @igorpecovnik in armbian/build#9130chore: update copyright years to 2026. by @igorpecovnik in armbian/build#9129Create mirror_to_codeberg.yml. by @EvilOlaf in armbian/build#9131docs: improve README and add Armbian Imager promotion. by @igorpecovnik in armbian/build#9128dts: orangepi-4-lts: fix mispelled disable properites. by @EvilOlaf in armbian/build#9123Fix dialog typo. by @SergeantSerk in armbian/configng#716fix(apt-utils): add fallback for Ubuntu LTS releases without -updates suffix in JSON. by @adeepn in armbian/build#9117fix(rootfs): unset GIT_FIXED_WORKDIR after debootstrap/mmdebstrap clone. by @QwaSeeK in armbian/build#9132Genio: Change INSTALL_ARMBIAN_FIRMWARE to 'yes'. by @HeyMeco in armbian/build#9134gha: check-pr-pictures: allow declare -g BOARD_VENDOR=. by @rpardini in armbian/build#9142mekotronics-r58-4x4: enable edge branch with mainline kernel & u-boot. by @rpardini in armbian/build#9127Missing upstream package mousetweaks. by @igorpecovnik in armbian/build#9143Move boards with vendor intel_amd under generic vendor. by @igorpecovnik in armbian/build#9122SpacemiT: Fixup eMMC boot on the MusePi Pro "SPINOR". by @pyavitz in armbian/build#9141sunxi: backport A523/T527 related patches from 6.19-rc1 and #8831. by @EvilOlaf in armbian/build#9106View the full article

Waiting for others to do the work is a good strategy. If everything goes well, it will land at the earliest in 6.20, if improvements are needed, 7.x is probably more likely. When the corresponding kernel will be included in the chosen distribution is the next data point. You are clearly aware of what you have to wait for. Until then, I will simply continue using the necessary modifications as a self-written DTBO, which I have been doing for some time. But maybe you'll get lucky and someone else takes the burdon to apply the patches as an early adaptation, so you can just sit back and do nothing and still enjoy the upcoming availability.

Good morning @Werner Thanks for the patch. I'll probably wait for the new kernel and test it. The project is long-term. For the first answer "to address myself" :). I think I understand what you're saying. Thanks :). If I find a solution to this, I'll share it with the community, as I've been doing so far @usual user Thanks for the answer. Today is the 31st and I'm thinking of not working on servers, happy new year and may the next one be fruitful for all of us. Best regards, A.H.

https://patchwork.kernel.org/project/linux-rockchip/patch/20251230-arm64-dts-rockchip-rk3588-npu-enablements-v1-1-d38b182a59e3@pardini.net/ fyi

The rk3588 NPU support has been working as expected for me for some time now, but I don't use legacy software. $ ./classification Loading external delegate from /usr/lib64/libteflon.so with args: {} INFO: Created TensorFlow Lite XNNPACK delegate for CPU. 0.901961: military uniform 0.023529: Windsor tie 0.011765: mortarboard 0.007843: bulletproof vest 0.003922: cornet time: 15.706ms $ ./classification INFO: Created TensorFlow Lite XNNPACK delegate for CPU. 0.901961: military uniform 0.023529: Windsor tie 0.007843: bulletproof vest 0.007843: mortarboard 0.003922: cornet time: 70.607ms versus

From what I hear, that could a long time coming for trixie and the a5e.

You are community. Contact yourself As there is no maintainer for this board everyone and nobody the same time is responsible for it. If nobody cares, functionality will fall apart over time.

The userspace is behind, that's not an issue. Hardware support is a kernel thing. If its not there an up-to-date userspace like Forky or Sid means nothing.

Greetings, H96 Max V56 developers, I got 1Gb Ethernet, basic WiFi6, and the full Bluetooth5.4 suite of capabilities from the new H96 hardware, running my 6.12.44 kernel, Home Assistant OS port. Thanks especially @WINEDS for the stellar foundation, and to @GmP for the final piece of the Bluetooth puzzle. GBEM 👽

A lot of things can go wrong, so depending on what goes wrong in a copy from SD to emmc, what steps would be needed to recover could differ. But flashing back to the original android firmware will generally always get you back to the starting point.

Hello, I think the problem with not seeing /dev/rknpu is that it is not defined in the rk3588-nanopc-t6.dtb file. In earlier versions, there was no fan control and with each update I made corrections. I have a saved dts file from 14.01.2025 206220 Dec 28 21:12 rk3588-nanopc-t6.dts 341802 Jan 14 2025 rk3588-nanopc-t6.dts.14.01.2025 There is a big difference between the two. I know that NanoPC-T6 is Community maintained, who can I contact to see what the problem is? It is possible that I am also making a mistake in trying to run an LLM model. Best regards, A.H.

I forget if WiFi is supported yet for this board in Armbian. I know that PCIe/NVME is not, as well as USB3. Not sure if 2nd Ethernet nic and WiFi is supported yet. From what I hear, it may be quite some time until a trixie build can be made to support the hardware on this board. Radxa's os is still on Bullseye (which is ridiculous, IMHO)

Hello SteeMan I mean bricking when trying to install the system to EMMC memory My memory is SDINADF4-16G

Alright, partial success rfkill. Hm perhaps wifi trouble?