All Activity

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

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

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

ref. to Igor: I think the system runs fine because i can ping and because there is actually a ssh server active. Due to that I have a Odroid HC2 and not the XU4, I have no console and have to rely on ssh. I used putty and the ssh client in the "advanced IP scanner" - www.advanced-ip-scanner.com: both seem to connect but 1234 just does not work. In that Debian raspberry I used the normal ssh client and in WIN10/11 also the ssh client from the command line. All of these three ssh clients were not able to connect to the Odroid due to a different level of keystrength and procedure. I try the WIN11 ssh client to accept the situation and will come back edit: I needed to use these command options to connect to the ssh server from the WIN11 ssh client: ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-dss -oCiphers=+aes128-cbc -oMACs=+hmac-sha1 That is a pile of ancient security settings! Anyway - even now the 1234 did not work. in verbose mode I got no alarms from the ssh connection

Might be because at first login, you enter 1234, it then asks for you to change that, create a user and whatnot. Not so sure putty will have any idea of what to do with those prompts. When you wrote: "once more: tried ssh through a raspi in the network. the raspi cannot connect to the armbian:" What do you mean by that? You logged in to a rpi OS with putty, and you then tried to connect to this device via the rpi? Was this before or AFTER you already tried logging in to it using putty? In your log: ### [firstrun] Recreated SSH keys (entropy: 256 256) I don't know what this means, but sounds like keys are enrolled and maybe assumed to be used in future. You will have to look into putty (and ask the devs of putty) to learn what is happening, unless you are willing to use a "normal" ssh client that will tell you what is going on by providing STDOUT & STDERR to your monitor. With a NORMAL ssh client, type "ssh root@xxx.xxx.xxx.xxx" (the ip to the device) and it will ask for passw, it will then require you to CHANGE passwd etc. Seems very likely putty has no idea how to deal with that and are doing some strange things at first login, witch then probably leads to it borking your system.

Is it possible to build against a current kernel (6.18 for example)? I am trying to build an access point on Armbian but 6.6 does not support AP mode on most adapters.

ok thanks.

Moved to off-topic as this isn't Armbian related