Active threads

Very weird HDMI is not functional in both armbian and multitool: they use very different kernels. Multitool uses the 4.19 vendor kernel, which should be supposed to provide "best" compatibility. The dmesg error is highly related to the missing HDMI, but in a way I can't recognize. About the VFD driver, I guess you're using OpenVFD driver. Latest kernels (both 6.12 and >= 6.16) come with tm16xx driver which is by far much much better and candidate to be upstreamed in the mainline kernel. Here is the github project reference; the driver is already compiled in the kernel, but you may need to edit a device tree overlay by yourself to let it work with your board. To try some debugging, the complete dmesg output and the original device tree of the stock android firmware would be very useful.

Ecco una risposta adeguata per il forum in inglese, considerando il tuo aggiornamento: Hello everyone, I’ve reviewed all the connections carefully using the reference manual to ensure everything is correctly wired. Unfortunately, while the display powers on and stays brightly lit, I still don’t see any output on the screen. Here are a few thoughts and tests I’ve tried: Initialization Problem? I’m unsure if the issue is related to the initialization sequence. I don’t know how to create one tailored to this display. Perhaps this could be due to the fact that it’s an ST7735S, while the driver is designed for the ST7735R? Could this be causing incompatibility issues with the current driver? GPIO Changes: I’ve also experimented with changing the GPIO configurations, specifically: dc-gpios = <&pio 2 6 1>; /* changed the 1 to 0 */ r eset-gpios = <&pio 2 9 1>; /* changed the 1 to 0 */ However, this had no effect. Kernel Compatibility: When I use a kernel version 5.x, the display works correctly. But with the current configuration and the newer kernel, I can’t seem to get it to work. This might be a kernel-level issue, or perhaps something changed in how the driver is initialized. Temporary Workaround: I’ve ordered another display to rule out any potential hardware issues, but it will take a while to arrive. At this point, I’m unsure of how to proceed. If anyone has advice on adapting the driver for ST7735S or creating a compatible initialization sequence, I’d greatly appreciate it. Thanks in advance for your help!

Some manufactures change the wifi and lan controllers to keep prices down on new BOM of materials: @WINEDS got experience with thos problems https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/page/16/#comment-210825 https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/#findComment-217289 https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g/#findComment-216154

Please share your .desktop file... with sensitive information redacted.

@MartinB Official DXVK won't work, because it requires some Vulkan extension/features that Mali drivers don't have. So, I build the stripped versions that remove most of the requirements. You can download it here https://github.com/khanh-it/dxvk/actions https://github.com/pythonlover02/DXVK-Sarek/actions Just extract it into the game's folder and allow dlls overrides in wine.

Hello. Sorry to be late. I succeed, I find the image to be installed. I think it was debian-12.11.0-arm64-netinst.iso.

Hi @Nick A Please help me. I have H96 MAX H313 and Armbian-unofficial_25.05.0-trunk_X96q-lpddr3-v1-3_bookworm_edge_6.12.11 work well, but no wifi I tried several times to compile with your instuctions, but every time during compilation I get a lot of warnings and eventually a compilation error. What I was doing: I don't understand all this very well, but I see that there is a way to solve the problem. If it's not too much trouble, may I ask you to describe step by step what I should do? I would be very grateful. I attach a log file and a photo of my board. build logs.md

hi, Compilation error, I also decompiled the dts available for Android for reference output.dts @Nick A

A known issue with the Odroid XU4, HC1, and HC2 is that it (uboot?) does not properly park the hard disk heads before/during shutdown or power cycle/off. So, the disk drive is forced to emergency hard retract the heads when power is shutdown/cycled. This is of course a violent action for the HDD and should be avoided. Use this odroid.shutdown script and install into /lib/systemd/system-shutdown/. https://wiki.odroid.com/odroid-xu4/troubleshooting/shutdown_script Recommend adding to armbian for XU4 distros.

Just a note the download of latest release Armbian_25.8.1_Odroidxu4_noble_current_6.6.102.img works fine, so something in the build system.

Hi again Werner. Please excuse the long waiting time. It's taken me a long time to place back the device at its intended location. Here's the requested output. https://paste.armbian.com/alefaladep At the moment I've got it running on a realtek usb-ethernet dongle at full speed (confirmed throughput up to about 300Mbit). Last year when I created the thread we were using the Nanopi Neo4's onboard realtek ethernet port. No matter what we did it wouldn't run at speeds over 10Mbit. And no, the port isn't faulty. It's happening on ALL armbian devices (official and unofficial) on current distributions still to this day. Bookworm/Trixie/Noble/Jammy, with kernels 6.12, 6.6, 6.1 and 5.15 tested. On x86 debian it works right out of the box at full speed and we're talking much weaker hardware (Intel z8350). Thanks for your work. Armbian is definitely the future IMO.

Yeah fan working on :- https://github.com/radxa-build/rock-5b-plus/releases/download/rsdk-b2/rock-5b-plus_bookworm_kde_b2.output.img.xz

An `armbian-plymouth-theme` package must be installed to make it worked in the latest (6.x ???) kernels. Steps: 1. `sudo nano /boot/armbianEnv.txt` and adjust/add following line `bootlogo=true` 2. `sudo apt install armbian-plymouth-theme` 3. sudo reboot 4. Check plymouth or/and armbian-plymouth-theme documentation for more customizations

Both Debian 12 and Debian 13 use Wayland by default for the GNOME desktop environment. However, X11 also remains an available option in the login manager, allowing you to choose between the two. Wayland is a communication protocol that specifies the communication between a display server and its clients. A display server using the Wayland protocol is called a Wayland compositor, because it additionally performs the task of a compositing window manager. The aim of Wayland is replacing the X Window System (Also known as X11, or Xorg) with a modern, secure, and simpler windowing system xrandr is used on top of X.org, that's why it doesn't work on a debian that uses Wayland.

Hi @Igor, I was looking at configng repo and I found this issue: https://github.com/armbian/configng/issues/225. I think that's why I could not find a place to create the sway section in the desktop. In the same I found this in not being planned yet to be made, if ever. Should I look at the Armbian build and try there instead?

Hey! So, when i enter the multitool link it says 404 not found... Is there any new link or smth?

Great! That worked. Do I need to do anything else after that?

I can confirm this is still broken as of 10/18/2025 Currently attempting the overwrite armbian uboot with vendor uboot solution The solution did work. The spl loader files can be found here https://dl.radxa.com/rock5/sw/images/loader/rock-5b/release/ All of the files need to be gathered together, or the file paths adjusted when you run the commands. I pulled the rkdeveloptool from git and built it and put everything else the folder with it. ❯ ./rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x350b,LocationID=101 Maskrom ❯ sudo ./rkdeveloptool db rk3588_spl_loader_v1.15.113.bin Downloading bootloader succeeded. ❯ sudo ./rkdeveloptool wl 0 armbian.img Write LBA from file (100%) ❯ sudo ./rkdeveloptool wl 64 idbloader.img Write LBA from file (100%) ❯ sudo ./rkdeveloptool rd Reset Device OK.

I finally installed Postmarket OS (Alpine Linux) using Pmbootstrap., I close this topic. Thanks to all of you for your comments and suggestion.

I had to enter all of this on my Orange Pi 5 Max: https://gist.github.com/default-writer/6ca5f1f05e88c9c51e2e1b09147ad23e

I have been experimenting with trying to get video acceleration working on the A83T. I can see from /proc/device-tree/soc/... that there is already a video-engine node within the current A83T device tree. It appears to be applied as one of the megous patches ARM-dts-sun8i-a83t-Add-cedrus-video-codec-support-to-A83T-untes.patch. Admittedly this is noted as being untested. In my initially created build via the build framework, Cedrus was not present at all among the list of loaded modules. I addressed this by creating an entry in the Cedrus compatibility table for the sun8i-a83t-video engine drv-sun8i-a83t-cedrus-add-variant.patch It now appears to load but complains about being unable to allocated an SRAM: [ 10.046406] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.046490] cedrus 1c0e000.video-codec: Failed to probe hardware [ 10.091215] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.091339] cedrus 1c0e000.video-codec: Failed to probe hardware [ 10.419296] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 10.419597] cedrus 1c0e000.video-codec: Failed to probe hardware [ 20.193058] cedrus 1c0e000.video-codec: Failed to claim SRAM [ 20.193114] cedrus 1c0e000.video-codec: Failed to probe hardware [ 20.193322] platform 1c0e000.video-codec: deferred probe pending: (reason unknown) Using both sun8i-a23-a33.dtsi and sun8i-h3.dtsi as points of reference, I attempted to make an SRAM allocation under the system controller but this still appears to fail with the same failure messages. I have double checked in the user manual and VE memory should definitely exist at 0x01D0 0000. arm-dts-sun8i-a83t-add-ve-node.patch I would be grateful for any pointers. Thanks Ryzer

root@rk3318-box:~/tm16xx-display# make module make EXTRA_CFLAGS="-DCONFIG_TM16XX -DCONFIG_TM16XX_KEYPAD -DCONFIG_TM16XX_I2C -DCONFIG_TM16XX_SPI" -C /lib/modules/6.16.4-edge-rockchip64/build M=/root/tm16xx-display modules make[1]: Entering directory '/usr/src/linux-headers-6.16.4-edge-rockchip64' make[2]: Entering directory '/root/tm16xx-display' CC [M] line-display.o /tmp/cc8iv0mf.s: Assembler messages: /tmp/cc8iv0mf.s:8: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:9: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:10: Error: junk at end of line, first unrecognized character is `L' /tmp/cc8iv0mf.s:11: Error: junk at end of line, first unrecognized character is `L' make[4]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/scripts/Makefile.build:290: line-display.o] Error 1 make[3]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/Makefile:2003: .] Error 2 make[2]: *** [/usr/src/linux-headers-6.16.4-edge-rockchip64/Makefile:248: __sub-make] Error 2 make[2]: Leaving directory '/root/tm16xx-display' make[1]: *** [Makefile:248: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-6.16.4-edge-rockchip64' make: *** [Makefile:46: module] Error 2 fresh install, box T9 rk3328

this board appears to have effervesced from your repo in this commit, just a few weeks ago. is it maintained elsewhere?

Hello, is BPI-6202/6204 supported? It should have A40I CPU, like the M2 Ultra (which is actually supported)

./compile.sh BOARD=orangepizero3 BRANCH=current RELEASE=trixie BUILD_MINIMAL=yes KERNEL_CONFIGURE=no https://docs.armbian.com/Developer-Guide_Build-Preparation/ replace BRANCH with edge if you prefer more recent kernel. replace RELEASE with noble if you prefer Ubuntu flavour. remove BUILD_MINIMAL=yes to get the choice to build a standard cli image instead of minimal/iot.