Active threads

Any chance of the above commit being adopted in future releases? It could make multichannel PCM hdmi audio work correctly.

bedna, that is not a "putty only" behavior. Attached the verbose output using the Win11 ssh client - same same I see only to pull the SD card, mount it on another linux system and then have a look at the ssh server and general system settings ssh1.txt

Hello. After burning Efuse to the Nanopi Neo Core, I can't boot from emmc. It works from the SD card, so I try loading everything into emmc: spl, uboot. But spl doesn't find u-boot, as far as I understand. I'm using the u-boot and dts config from the Nanopi Neo, with some edits to mmc2, since it's not available in the Neo. U-Boot SPL 2024.07 (Feb 25 2026 - 15:51:42 +0300) DRAM: 512 MiB Trying to boot from MMC1 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:8 ARG 0x000001aa RET -110 CMD_SEND:55 ARG 0x00000000 RET -110 CMD_SEND:0 ARG 0x00000000 MMC_RSP_NONE CMD_SEND:1 ARG 0x00000000 RET -110 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 SPL: failed to boot from all boot devices ### ERROR ### Please RESET the board ###

Well don't know exactly how the board got bricked, but I would guess the armbian-config did not flash the SPI right and somehow my SD card got screwed too. armbian-install did it right. I was able to get it back by using the rkdeveloptool tool from my mac mini. For whoever runs into this problem this is what I had to do: Get a usb-c cable connected to the "DP Display Port" and connect to another machine to troubleshoot, disconnect the power source before you do this. Before you connect the cable, press the Maskrom button. This should allow you to access the SPI from your troubleshooting machine. I played around with the windows tool RKDevTool with no luck. I ended up compiling rkdeveloptool in my mac mini m4 and this one did work. Anywho, once you have the board hooked up and in Maskrom mode, you need to get your hands on the SPI Loader *.bin. It's somewhere in the resources page of radxa. The one I used is rk3588_spl_loader_v1.15.113.bin. After this you flash the board with the following commands: The following command should show you the board info and confirm it's connected in Maskrom mode. ./rkdeveloptool ld ./rkdeveloptool db rk3588_spl_loader_v1.15.113.bin ./rkdeveloptool ef ./rkdeveloptool rd This allowed me to boot aging from SD, even though I had to reflash the SD because somehow it also went bad. Not sure if it was because of all the testing or armbian-config screwed it up. After all this, I was booting again, and I did an armbian-install to move again the content of the SD to the nvme. I again, did an install/update MTD flash and boot from MTD first and this time around it all worked. I'm able to boot from SD first and if not SD is present it boots from NVME.

@Nick A Thank you very much. Newbies will try. 😅

Hello! Are there any plans for a stable minimal/IOT release for the Rock 4D, and if so, what’s the timetable? Thanks!

Sorry for filling this thread with my issues. I'm calling it quits on this one and I'll just put up with it. It seems the v4l2request/drmprime stuff is a slow moving beast with ffmpeg/mpv and I have no interest in dealing with the dependency rabbit hole building my own versions. I found some references on the mpv github mentioning possible frame size issues so that's probably what causing my problems. I don't expect it will be fixed until ffmpeg upstream is sorted out. Going by current progress rates that's probably 2 years away.... I did find using --hwdec=drm-copy will play the files without producing the driver error but the green issue is still there. Using drm-copy with 1080p videos would be a little choppy though. I did a grep search on the mpv and mesa driver source code and couldn't find any reference to the "rejecting image due to unsupported offset" error so that must be coming from an external library. I did have a small win as installing the backported Mesa driver did fix some slight screen tearing issues I was encountering on 1080p content.

Thanks @sven-ola. I will give that a try. The standard Armbian is unable to connect to an WPA3 access point in basic client mode (no AP). It connects fine to WPA2-Personal.

I have installed fresh Armbian IOT community image for Orangepi 5 Max on my Opi5Ultra. Generally works fine, but connected camera (OV13850) not properly works. Via gst-launch I got dark images. Only flashlight or lamp can see on image. In original Orangepi 5 Ultra OS image this issue can be fixed by disabling docker and containerd services and sockets. But Armbian system has not any docker or contanerd services. Can you help me fix this issue? I am going try other cameras - OV9281 and IMX415 and I not have overlays for it. Can somebody publish .dtbo files for those cameras?

@DaBo no, sorry, no progress on my side. But I also have to admit that I did not had the time to mess around with it some more.

ok thanks.

One option is to start a crowdfunding campaign. You can review how previous campaigns were structured here: https://forum.armbian.com/crowdfunding/ As a rough estimate, bringing a new board or image to a sustainable level typically requires around $5,000 just to cover the initial development effort - when dealing with something simple. Running a campaign also gives a clear picture of how challenging it is to secure funding for this type of work. However, initial development is only part of the cost. To avoid creating another long-term maintenance burden (a “support black hole”), an additional $5,000–$10,000 is usually needed to cover ongoing maintenance, updates, CI resources, testing, and long-term support. It’s also important to emphasize a general principle: you should ideally choose hardware that is already officially supported, rather than expecting support to be built around hardware after purchase. Supporting embedded devices sustainably requires planning, funding, and long-term commitment — it doesn’t happen automatically. In short - it’s possible, but it requires realistic budgeting and shared responsibility.

Can't figure how to copy putty terminal output messages, the terminal sent more messages but I can't find how to copy to a text file.

@jock The schematic is maybe was a wrong example (I just search for rk3399 schematic, and take the first) in this case Leez P710, but I also look at the RK3399_Design_Guide and find a interesting point, UART2 based on the sd card pins!!! I already read a bit regarding the ddrbin_tool.py (which is part of the rkbin), which one could be used to manipulate the rockchip boot loader, but until now I not really understood how this work, then I find this in the Rockpi4 schematic I became enlightened. In the ddrbin_tool_user_guide is the following: * UART info uart id: uart number. 0 for uart0, 1 for uart1, 2 for uart2..., 0xf will disable uart. uart iomux: uart iomux info, 0 for uartn_m0, 1 for uartn_m1, 2 for uartn_m2...(like uart2_m0, uart2_m1,uart2_m2), or 1 for uartn_a, 2 for uartn_b, 3 for uartn_c.(like uar2a, uart2b, uart2c). uart baudrate: uart baudrate should be 115200 or 1500000. I still don't understanding what the iomux (io multiplexing) is, but in theory if I change the uart iomux parameter to 1 then this should means that UART2A is used, which is SD card D0,D1 pins. (Similar concept I see in Amlogic SoCs. ) So I read out the ddrbin parameters from rk3399_ddr_800MHz_v1.27.bin ./tools/ddrbin_tool.py RK3399 -g ddrbin_param.txt ./bin/rk33/rk3399_ddr_800MHz_v1.27.bin then I change the UART parameters in the file ddrbin_param.txt like this: uart id=2 uart iomux=1 uart baudrate=115200 then I write the parameters back ./tools/ddrbin_tool.py RK3399 ddrbin_param.txt ./bin/rk33/rk3399_ddr_800MHz_v1.27.bin Then I build a new loader based on the rk3399_ddr_800MHz_v1.27.bin ./tools/boot_merger ./RKBOOT/RK3399MINIALL_1.27.ini Content of the ./RKBOOT/RK3399MINIALL_1.27.ini [CHIP_NAME] NAME=RK330C [VERSION] MAJOR=1 MINOR=30 [CODE471_OPTION] NUM=1 Path1=bin/rk33/rk3399_ddr_800MHz_v1.27.bin Sleep=1 [CODE472_OPTION] NUM=1 Path1=bin/rk33/rk3399_usbplug_v1.26.bin [LOADER_OPTION] NUM=2 LOADER1=FlashData LOADER2=FlashBoot FlashData=bin/rk33/rk3399_ddr_800MHz_v1.27.bin FlashBoot=bin/rk33/rk3399_miniloader_v1.26.bin [OUTPUT] PATH=rk3399_loader_v1.27.126.bin The result was uploaded in the emmc rkdeveloptool db rk3399_loader_v1.27.126.bin rkdeveloptool ul rk3399_loader_v1.27.126.bin the I connected my microsd sniffer and after some praying I reset the device ... Then the magic is happened 🤩 DDR Version 1.27 20211018 In channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 MHz, current 856MHz OUT Boot1 Release Time: May 29 2020 17:36:36, version: 1.26 CPUId = 0x0 ChipType = 0x10, 645 SdmmcInit=2 0 BootCa Yes, is working, I have debug output 😁 this is maybe not the best solution but I could start working running Armbian on this device. The key point was: So thanks again the advise.

I don't have a working board to add yet. I followed the documentation on creating a ~/build/config/boards/sv06ace.csc file but got lost about how to bring in the rk-kernel.dts values into the build. I started a new https://forum.armbian.com/topic/58141-rk3308b-build-using-sysfirmwareftb-on-sovol-sv06-ace/ since the question could apply to other 3D printer boards.

I’m using an Orange Pi 3B running Armbian Trixie Minimal as a headless SBC. It has been working fine for a couple of months, but after a recent reboot, it failed to connect to the network. After connecting an HDMI cable to troubleshoot, I realized the system is no longer auto logging in; it gets stuck at the login screen. Once I log in manually, I found that the wired network (Ethernet) isn't working at all, though wireless is functioning fine. I even tried flashing the latest image from the website, but the issues persist. To summarize, I have two main problems: - Wired connection (Ethernet) is not working. - The system no longer auto-logs in after booting. Has anyone else encountered this with the recent Trixie builds?

Per the title, I was able to extract an ftb file and convert it to dtb and dts file. I would like to use the community build framework and build Armbian for SV06 Ace. The initial plan was to base the new board/*csc files on other rk3308b boards; sakurapi and rock-s0 and then pull configuration values from the OEM dts file. I'm confused about the dts structure in Community builds and the proper locations for defconfig, dts and dtsi files. I've worked with the files in OpenWRT where they are rigidly structured - something that would be a monumental task for Armbian community builds. The OEM dts file does not use any includes/dtsi files. If successful, I would like to publish on github similiar to @Torte https://github.com/torte71/armbian-mksklipad50 Can someone point me to the relevant documentation for Armbian dts files?

If you installed the Armbian 25.11.1 Edge Image the earlier post fixed the HDMI audio issue. However, if you upgrade with the command sudo apt update && sudo apt upgrade you will break both HDMI audio and WiFi. Here is the new fix: 1. The Wi-Fi Fix (Rebuild DKMS) Since the kernel updated, we just need to force the system to recompile the missing Wi-Fi driver for the new kernel version. Run this command in your terminal: Bash sudo dpkg-reconfigure aic8800-usb-dkms Wait a minute or two for it to finish compiling. Your Wi-Fi will be restored upon your next reboot. 2. The HDMI Audio Fix (Restore Qualcomm Configs) The HDMI audio broke because the system is now missing the Use Case Manager (UCM) profiles for the QCS6490 chip. We need to pull the newest configurations directly from the ALSA project repository and put them in the right folders. Run these commands one by one: Bash # Install the base UCM configurations sudo apt install -y alsa-ucm-conf # Download the latest master branch configs to your temporary folder cd /tmp curl -sL "https://github.com/alsa-project/alsa-ucm-conf/archive/refs/heads/master.tar.gz" | tar xz # Copy the specific Qualcomm configs and dependencies to your system sudo cp -r alsa-ucm-conf-master/ucm2/Qualcomm/qcs6490 /usr/share/alsa/ucm2/Qualcomm/ sudo cp -r alsa-ucm-conf-master/ucm2/conf.d/qcs6490 /usr/share/alsa/ucm2/conf.d/ sudo cp -r alsa-ucm-conf-master/ucm2/lib /usr/share/alsa/ucm2/ sudo cp -r alsa-ucm-conf-master/ucm2/codecs /usr/share/alsa/ucm2/ # Restart your audio server to apply the changes systemctl --user restart pulseaudio Once you've run those, give your board a quick sudo reboot.

poweroff doesn't work on any of my boxes either. Does reboot work correctly for you? It does on my boxes, and I usually issue a reboot and then time a power disconnect when the drives have spun down and before they restart.

If you installed the Armbian 25.11.1 Edge Image the earlier post fixed the HDMI audio issue. However, if you upgrade with the command sudo apt update && sudo apt upgrade you will break both HDMI audio and WiFi. Here is the new fix: 1. The Wi-Fi Fix (Rebuild DKMS) Since the kernel updated, we just need to force the system to recompile the missing Wi-Fi driver for the new kernel version. Run this command in your terminal: Bash sudo dpkg-reconfigure aic8800-usb-dkms Wait a minute or two for it to finish compiling. Your Wi-Fi will be restored upon your next reboot. 2. The HDMI Audio Fix (Restore Qualcomm Configs) The HDMI audio broke because the system is now missing the Use Case Manager (UCM) profiles for the QCS6490 chip. We need to pull the newest configurations directly from the ALSA project repository and put them in the right folders. Run these commands one by one: Bash # Install the base UCM configurations sudo apt install -y alsa-ucm-conf # Download the latest master branch configs to your temporary folder cd /tmp curl -sL "https://github.com/alsa-project/alsa-ucm-conf/archive/refs/heads/master.tar.gz" | tar xz # Copy the specific Qualcomm configs and dependencies to your system sudo cp -r alsa-ucm-conf-master/ucm2/Qualcomm/qcs6490 /usr/share/alsa/ucm2/Qualcomm/ sudo cp -r alsa-ucm-conf-master/ucm2/conf.d/qcs6490 /usr/share/alsa/ucm2/conf.d/ sudo cp -r alsa-ucm-conf-master/ucm2/lib /usr/share/alsa/ucm2/ sudo cp -r alsa-ucm-conf-master/ucm2/codecs /usr/share/alsa/ucm2/ # Restart your audio server to apply the changes systemctl --user restart pulseaudio Once you've run those, give your board a quick sudo reboot.

Sorry for the late reply to your request. I still have the image; let me know where to upload it if you're still interested.

Hi, eselarm. i did not have time to delete the topic. Somehow it started working. Thank you for your time.

https://github.com/armbian/linux-rockchip/pull/448 Was able to reproduce this issue and get it fixed.

I managed to do it thanks

Hello averyone I'm trying to download the multitool.img.xz can someone please help me find it or share a valide link?