All Activity

Hi, No sure if this is the place to post this but here it goes. I use the Debian distro for my armbian deployments. Every time I deploy, and the system comes with systemd-resolved it gives me problems. I always have to remove it and use the /etc/resolv.conf file by it self. I would suggest removing this, it's not necessary or useful. -Cheers

Sorry for my late reply (been very busy in the last couple of days). No, reboot does not work either: same freeze. Anyway it's a software issue and that's unfortunate for Armbian, because shut down and reboot for my device work flawlessly with CoreElec. I hope in a future improvement.

Thanks for the advice.

How do you make it work on the original OS? I have the same screen and the same Orange Pi, but I haven't been able to make it work.

"ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+aes128-cbc -oMACs=+hmac-sha1 -vv root@xyz" Let's try again, but this will be my last time typing this: The normal way to use ssh, is to type: "ssh user@xxx.xxx.xxx.xxx" where x is the ip number. So for Armbian first login, it's "ssh root@xxx.xxx.xxx.xxx", NOTHING ELSE. Just glancing at the few first lines in that log: OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2 debug2: resolve_canonicalize: hostname xyz is address debug1: Connecting to xyz [xyz] port 22. debug1: Connection established. debug1: identity file C:\\Users\\sebas/.ssh/id_rsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_rsa-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa_sk type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519 type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519_sk type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_ed25519_sk-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_xmss type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_xmss-cert type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_dsa type -1 debug1: identity file C:\\Users\\sebas/.ssh/id_dsa-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_for_Windows_9.5 debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6.0 debug1: compat_banner: match: OpenSSH_6.6.0 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000002 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to xyz:22 as 'root' debug1: load_hostkeys: fopen C:\\Users\\sebas/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen __PROGRAMDATA__\\ssh/ssh_known_hosts2: No such file or directory As I suspected, it looks like it is somehow trying to use keys and whatnot. Since you refuse to listen, yeah, this might be frustrating and "bad for morale". If you instead listen and do what is suggested, your morale would likely not suffer at all.

I'm back Asking for help on Radxa discord i got the answer to check for the FPC ("Flexible Printed Circuit") cable pin orientation and run lspci next. Turns out it was the cable all along, lspci returned: # lspci 00:00.0 PCI bridge: Rockchip Electronics Co., Ltd Device 3576 (rev 01) 01:00.0 SATA controller: ASMedia Technology Inc. ASM1062 Serial ATA Controller (rev 02) and lsblk shows: # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 4.5T 0 disk └─sda1 8:1 0 4.5T 0 part sdb 8:16 0 223.6G 0 disk └─sdb1 8:17 0 223.6G 0 part mtdblock0 31:0 0 16M 0 disk mmcblk1 179:0 0 59.5G 0 disk ├─mmcblk1p1 179:1 0 16M 0 part /config ├─mmcblk1p2 179:2 0 300M 0 part /boot/efi └─mmcblk1p3 179:3 0 59.2G 0 part / zram0 253:0 0 1.9G 0 disk [SWAP] So now it works and i can carry on with making my NAS 😇

Probably the easiest way to assess chances is to submit PR.

Support for Rockchip’s VDPU381 and VDPU383 decoders is now upstream in Linux, bringing mainline H.264/HEVC decode support, robust IOMMU-reset recovery, and new HEVC V4L2 UAPI controls aligned with Vulkan Video. View the full article

Hello ik316q-emcp_v6.0 full dump please

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 edit: i put that sd card into another SBC (odroid hc4), mounted that card, chroot, gave a passw to root, created another superuser etc. no change - ssh does not recognize any of these users. This is bad for morale.. 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.

booting from sd should work even with proper mtd in place. Get usb uart adapter and provide boot logs.

@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!

Stop providing false information, I disproved your theory earlier, please stop. On Armbian, the way to do it via ssh IS TO LOGIN AS ROOT on first run, SSH has logging in as root ENABLED BY DEFAULT on Armbian. This works, and is the way I have ALWAYS done it on Armbian, for years. Here is a link to documentation: https://docs.armbian.com/User-Guide_Getting-Started/#first-login I quote: "The first boot will log you in automatically if you have connected a display via HDMI or if you are connected to the serial console. For SSH, you need to login as root and use the password 1234." If OP refuses to listen to recommendation and keep using putty, OP will have to take this up with the devs of putty, there is nobody here that can/will help with that.

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?

Downloaded Debian 13 (Trixie)Minimal / IOT kernel 6.18 onto SD and had it working 24/7 for about 2-3 days with no problems. I selected the option to copy the content of the SD card to an NVME, updated the MTD flash and set it as first boot option and now the device wont boot from nvme, SD or USB. How can I recover the unit?

@maxsub: the sad truth is: nearly any non-primitive hardware component needs some sort of firmware these days, you should live with that... Anyhow, as I told earlier, just replace the FW for the bcmdhd. Here's how (make sure do disabled any /etc/netplan/wifi-this-and-that.yaml, my device has inet via eth) apt-get install hostapd cat > /etc/hostapd.conf << EOF interface=wlan0 driver=nl80211 ssid=test channel=1 EOF wget -O /lib/firmware/fw_bcm43456c5_ag.bin https://github.com/orangepi-xunlong/firmware/raw/refs/heads/master/fw_bcm43456c5_ag.bin hostapd -d /etc/hostapd.conf This works, tested on the Forky-minimal linked above. HTH // Sven-Ola

you cannot login as root via ssh using password, it is disabled by default for years already you need a normal user first or prepare the image/sd-card to use ssh keys/ids

Thanks @sven-ola! You have been of amazing support here. My worry about using the closed source binary firmware is that it opens up a security hole (no patches for vulnerabilities, etc). Same for OpenWrt - the xunlong code is a fork from OpenWrt and not being updated as far as I can tell. That's why I went the Armbian route, with your code in mainstream, it will get continuously updated. The WiFi is definitely underpowered, and CPU overpowered. I am using an R2S with a USB Wireless adapter (realtek): Panda wireless PAU0B. However, the 6.6 kernel seems to not allow AP mode.

Hello @maxsub! The RV2 is a bit overpowered CPU-wise for an access point while underpowered Wifi-wise. I am pretty sure, that AP mode works with 6.6 if you overwrite fw_bcm43456c5_ag.bin from https://github.com/orangepi-xunlong/firmware As a note: to build a Wifi-Router/AP, you can use OpenWrt which is available for the RV2 and may be better up to the task... HTH // Sven-Ola