All Activity

Don't concern yourself with the LED light color and whether it flashes or not. It will flash with some kernels and say red with others. And FYI, kernel 6.12 seems to boot, but it has no video output. This is why I suggest starting with 6.1 (vendor).

A 1 GB SSD... don't you mean a 1 TB? I wouldn't start with questioning your bootloader. From what you said, that makes no sense to me. It sounds like that part of your system is already working. From what you said, I would begin with an Armbian image instead of Xunlong (official Orange PI) image - as Xunlong really doesn't do a good job with OS support. https://www.armbian.com/orange-pi-5-plus/ Don't download a 6.12 image because they don't work. 6.1 is does work. Here is a specific Armbian Ubuntu Gnome image for the Orange PI 5 Plus 0 click on this and the download will begin: https://dl.armbian.com/orangepi5-plus/Noble_vendor_gnome You were right to use dd in Linux instead of some fancy piece of software. The images from Armbian are compressed to .xz. To decompress the image, after you download it: unxz [FILENAME] After you decompress it, dd the. .img file to your uSD. Remember to dd it to the device itself, not to a partition on it. This assumes there's nothing on the drive you want to keep, because this will overwrite its GPT (partition) table if it has one. Then verify your image: cmp -l [FILENAME] [DEVICE] If the verification is a success, it will not list any differences between the two files. It will just say EOF on your FILENAME. If it lists differences, it's a failure. Then simply dd again and verify again. I've had occasional instances where I've had to dd something twice from another computer. Then place the uSD in the Orange PI 5 Plus, and power it up. Everything should go well. It'll ask you a few easy questions. Then take you to your (Gnome) desktop. Then of course, do an update and reboot. Then run armbian-config. They have an installer program I've never really used so I can't speak to it. But it's supposed to let you install it on another device (i.e. your SSD). Whenever the uSD card is present in the Orange PI 5 Plus, it will take precedence in boot. So after you do the install onto your SSD drive, shut down and power off the Orange PI 5 Plus, then remove the uSD .Then power it on. Hopefully it will boot from your SSD.

Thanks for the input, CryBaby. First off - I'm a total dummy when it comes to the OrangePi - no idea where to start, so any help is appreciated. I think my PSU is OK - it (apparently) was supplied with the OPi (I was given it as well), and it is rated at 4 amperes. I measured the voltage when loaded, and it is 5.12 volts, so I guess it is OK. After the problems with the SD card, - I tried again installing Balena Etcher on my Linux Mint PC, but when I tried to burn an image (I tried several, not just Ubuntu), it appears to do this, then fails just as the verification process ends. I then tried the AppImage version of Etcher from the OrangePi downloads, and this did the same thing - failure at the end of verification. So, as you suggest, I suspected a dud SD card, but I had no spare, so just tried what I had (I know ....sorry!), and this is when I get the splash image and nothing further. I now have a new SD card, and the image burn/verification appears to be OK - no errors. But now the OPi board does not appear to switch on - The LED remains red, and I can feel that the components on the board are getting warm, but no video output. If there is a bootloader, where is it located? and can I reload it it to be sure it is there (I understand your comment about getting a flash screen, but I have my doubts about the integrity of any of the software after what I was told about the OPi) Thanks for your help, Keith.

Thanks for the reply @hexdump , the thing I don't understand is that in the thread I mentioned in my first message to this thread : the person claims to have successfully installed the OS on the internal eMMC on my very same box. Why running from eMMC wouldn't be possible on mine? What I am afraid of is that maybe there is some information / log which might be important in the outputs I provided in my pictures in the first message which I fail to recognize. About the message from @SteeMan I don't understand what he means by "and patch and apply it to a newer u-boot and build a newer u-boot"... In the /boot/build-u-boot/readme.txt file the instructions only have 3 different u-boots possible (s905x, s905x2 and s905x3) and all of them are like "git clone, run make" and that's it. Could you please be more explicit in what I should do or point me to some useful documentation? Thanks a lot for your help.

Sounds to me like a bad SD card. If you get a splash screen there must be some sort of bootloader. Another possibility is an inadequate power supply. Try one with more amps.

This build has disabled ffmpeg, I don't know it is possible to build with it for wayland client. I recommend x11 client because it is the most usable client with the most features. FreeRDP developers is developing a new sdl client for all platforms: linux, mac, wayland, x11, but that is still at an early stage. If you run xfreerdp, make sure to use gfx:AVC444 so that server sends h264 stream to you, then freerdp will use ffmpeg to decode it. You can check /proc/mpp_service/ to see if mpp hardware decoder is used. But don't expect the cpu will be extremely low, freerdp is decoding two avc420 streams and then combine them into one yuv444 frame, and then use cpu to convert yuv444 to rgb, then render it to x11, hardware decoder can only off-load few of the cpu load.

Not sure whether is specific to Opi5-Plus, on Arch Linux mpv-0.40.0 somehow also did not support --hwdec=v4l2request as such had to resort to the mpv-full-git which supports --hwdec=v4l2request. Debian-Trixie's repo mpv-0.40.0 also doesn't seems to support --hwdec=v4l2request.

##O#O## OS: Armbian 25.8.1 noble aarch64 ####### Host: Orange Pi 5 Plus ########### Kernel: 6.1.115-vendor-rk35xx ############# Uptime: 1 day, 8 hours, 17 mins ############### Packages: 1852 (dpkg), 5 (snap) ################ Shell: bash 5.2.21 ################# Resolution: 3840x2160 ##################### DE: GNOME 46.0 ##################### WM: Mutter ################# WM Theme: Adwaita Theme: Adwaita [GTK2/3] Icons: Adwaita [GTK2/3] Terminal: x-terminal-emul CPU: (8) @ 1.800GHz Memory: 7245MiB / 15957MiB FreeRDP client: freerdp2-wayland: Инсталирана: 2.11.5+dfsg1-1build2 Кандидат: 2.11.5+dfsg1-1build2 Таблица с версиите: *** 2.11.5+dfsg1-1build2 500 500 http://ports.ubuntu.com noble/universe arm64 Packages 100 /var/lib/dpkg/status --------------------------------------------------------------------------------------------------------- This is Build configuration: BUILD_TESTING=OFF BUILTIN_CHANNELS=ON HAVE_AIO_H=1 HAVE_EXECINFO_BACKTRACE=1 HAVE_EXECINFO_BACKTRACE_SYMBOLS=1 HAVE_EXECINFO_BACKTRACE_SYMBOLS_FD=1 HAVE_EXECINFO_H=ON HAVE_EXECINFO_HEADER=1 HAVE_FCNTL_H=1 HAVE_GETLOGIN_R=1 HAVE_GETPWUID_R=1 HAVE_INTTYPES_H=1 HAVE_JOURNALD_H=TRUE HAVE_MATH_C99_LONG_DOUBLE=1 HAVE_PIXMAN_REGION=OFF HAVE_POLL_H=1 HAVE_PTHREAD_MUTEX_TIMEDLOCK=ON HAVE_PTHREAD_MUTEX_TIMEDLOCK_LIBS= HAVE_PTHREAD_MUTEX_TIMEDLOCK_SYMBOL=1 HAVE_SYSLOG_H=1 HAVE_SYS_EVENTFD_H=1 HAVE_SYS_FILIO_H= HAVE_SYS_MODEM_H= HAVE_SYS_SELECT_H=1 HAVE_SYS_SOCKIO_H= HAVE_SYS_STRTIO_H= HAVE_SYS_TIMERFD_H=1 HAVE_TM_GMTOFF=1 HAVE_UNISTD_H=1 HAVE_XI_TOUCH_CLASS=1 WITH_ALSA=ON WITH_CAIRO=ON WITH_CCACHE=ON WITH_CHANNELS=ON WITH_CLANG_FORMAT=ON WITH_CLIENT=ON WITH_CLIENT_AVAILABLE=1 WITH_CLIENT_CHANNELS=ON WITH_CLIENT_CHANNELS_AVAILABLE=1 WITH_CLIENT_COMMON=ON WITH_CLIENT_INTERFACE=OFF WITH_CUPS=ON WITH_DEBUG_ALL=OFF WITH_DEBUG_CAPABILITIES=OFF WITH_DEBUG_CERTIFICATE=OFF WITH_DEBUG_CHANNELS=OFF WITH_DEBUG_CLIPRDR=OFF WITH_DEBUG_DVC=OFF WITH_DEBUG_KBD=OFF WITH_DEBUG_LICENSE=OFF WITH_DEBUG_MUTEX=OFF WITH_DEBUG_NEGO=OFF WITH_DEBUG_NLA=OFF WITH_DEBUG_NTLM=OFF WITH_DEBUG_RAIL=OFF WITH_DEBUG_RDP=OFF WITH_DEBUG_RDPDR=OFF WITH_DEBUG_RDPEI=OFF WITH_DEBUG_RDPGFX=OFF WITH_DEBUG_REDIR=OFF WITH_DEBUG_RFX=OFF WITH_DEBUG_RINGBUFFER=OFF WITH_DEBUG_SCARD=OFF WITH_DEBUG_SND=OFF WITH_DEBUG_SVC=OFF WITH_DEBUG_SYMBOLS=OFF WITH_DEBUG_THREADS=OFF WITH_DEBUG_TIMEZONE=OFF WITH_DEBUG_TRANSPORT=OFF WITH_DEBUG_TSG=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF=OFF WITH_DEBUG_TSMF_AVAILABLE=0 WITH_DEBUG_URBDRC=OFF WITH_DEBUG_WND=OFF WITH_DEBUG_X11=OFF WITH_DEBUG_X11_CLIPRDR=OFF WITH_DEBUG_X11_LOCAL_MOVESIZE=OFF WITH_DEBUG_XV=OFF WITH_DSP_EXPERIMENTAL=OFF WITH_EVENTFD_READ_WRITE=1 WITH_FAAC=OFF WITH_FAAD2=OFF WITH_FFMPEG=OFF WITH_GFX_H264=OFF WITH_GPROF=OFF WITH_GSM=OFF WITH_GSSAPI=OFF WITH_ICU=ON WITH_INTERNAL_MD4=OFF WITH_INTERNAL_MD5=OFF WITH_IPP=OFF WITH_JPEG=ON WITH_KERBEROS=ON WITH_LAME=OFF WITH_LIBRARY_VERSIONING=ON WITH_LIBSYSTEMD=ON WITH_MACAUDIO=OFF WITH_MACAUDIO=OFF WITH_MACAUDIO_AVAILABLE=0 WITH_MANPAGES=ON WITH_MBEDTLS=OFF WITH_OPENCL=OFF WITH_OPENH264=OFF WITH_OPENSLES=OFF WITH_OPENSSL=ON WITH_OSS=ON WITH_PAM=ON WITH_PCSC=ON WITH_PROFILER=OFF WITH_PROXY=OFF WITH_PULSE=ON WITH_SAMPLE=OFF WITH_SANITIZE_ADDRESS=OFF WITH_SANITIZE_ADDRESS_AVAILABLE=1 WITH_SANITIZE_MEMORY=OFF WITH_SANITIZE_MEMORY_AVAILABLE=1 WITH_SANITIZE_THREAD=OFF WITH_SANITIZE_THREAD_AVAILABLE=1 WITH_SERVER=ON WITH_SERVER_CHANNELS=ON WITH_SERVER_INTERFACE=ON WITH_SHADOW=ON WITH_SMARTCARD_INSPECT=OFF WITH_SOXR=OFF WITH_SSE2=OFF WITH_SWSCALE=OFF WITH_THIRD_PARTY=OFF WITH_VALGRIND_MEMCHECK=OFF WITH_VALGRIND_MEMCHECK_AVAILABLE=1 WITH_VERBOSE_WINPR_ASSERT=ON WITH_WAYLAND=ON WITH_WINPR_TOOLS=ON WITH_X11=ON WITH_XCURSOR=ON WITH_XDAMAGE=ON WITH_XEXT=ON WITH_XFIXES=ON WITH_XI=ON WITH_XINERAMA=ON WITH_XKBFILE=ON WITH_XRANDR=ON WITH_XRENDER=ON WITH_XSHM=ON WITH_XTEST=ON WITH_XV=ON WITH_ZLIB=ON Hi guys, I am using `wlfreerdp` to access remote Win 11 but the client I have installed does not support hwacc and is laggy on 4K monitor. Network is 1G LAN. I have already built Moonlight with ffmpeg/rkmpp hwacc and it works amazing. Can anyone advice if I can do the same, building the FreeRDP client with hwacc? CC:@amazingfate (I know u know how to do it ;) )

I had the same problem when trying this directly on my Banana PI M5. But when I connected from my notebook via ssh everything worked fine and I could create the root and user password. Afterwards login was also possible directly on the machine.

Hi, I guess this happens because of the "-x" option in rsync which tells rsync to not cross the filesystem hierarchy. /var/log is typically a mount (/dev/zram1) so it will not be synced.

I suggest booting from µSD and then making a copy of eMMC to somewhere and reinstall after that. You can then restore whatever you need from your eMMC backup. Most likely that will be vastly less headache and much higher chances of success.

@pochopsp - as you contacted me via message directly, let me respond here: i can only repeat what @SteeMan already said - you can either do your own research and experiments if you get some newer u-boot built and working (which will be a lot of learning and effort and can also fail in the end) or you accept that running from emmc will not work on your box and continue to use an sd card (which should work nearly as good as running from internal storage) - there is no easy tutorial to get it working, either it works out of the box (as the box is closer to one of the supported and tested ones) or you have to find your own way to get it working with those tv boxes ...

Can I just follow the Debian rescue chroot tutorial ? (with appropriate partitions) https://wiki.debian.org/RescueLive

"Regular" mpv coming in Debian Bookworm works perfectly fine, as Bullseye did also. There should be no need for custom mpv builds, unless some features have been removed.

The rsync instruction copies the files using an exclude list. However that list does not explain why folders other than /var/log/journal are missing in /var/log. # cat /usr/lib/armbian-install/exclude.txt /boot/* /dev/* /proc/* /sys/* /media/* /mnt/* /run/* /tmp/* /ddbr/* /var/log/journal

mainline support for rk3588 is still incomplete. If you need vpu stuff mostly work you need to use vendor kernel which is based on rockchip bsp.

Should be resolved

HI. We cannot support 3rd party images, therefore please refrain from asking further questions about other images. Though Armbian should work just fine with this board. https://docs.armbian.com/User-Guide_Getting-Started/ There are some pitfalls that might cause issue. This board comes with a spi flash memory which, when containing a poor/bad boot loader, can prevent proper boot of any OS. In this case rkdevtool might be necessary to erase via USB if possible.

It would be great, if you could post results of all your findings here, so that someone else could save a few hours on this problem and rather spend them on another one;)

Device: Opi5-Plus. Have the same issue on Debian-Trixie kernel-6.16.8-edge-rockchip64 mpv (0.40.0_ deos not support vpu hardware acceleration. mpv --hwdec=v4l2request-copy is too slow to decode 4K/60 video, very high dropped frames. mpv --hwdec=v4l2request '/media/jfl/writable/home/jfl/Videos/Two Steps From Hell - Unleashed-15ZqpVOjZEc.mp4' ● Video --vid=1 (h264 1920x1080 60 fps) [default] ● Audio --aid=1 --alang=eng (aac 2ch 44100 Hz 128 kbps) [default] AO: [pipewire] 44100Hz stereo 2ch floatp VO: [gpu] 1920x1080 yuv420p AV: 00:00:04 / 00:05:41 (1%) A-V: 0.000 Exiting... (Quit) The is a mpv-full-git version @junari had build for arch linux which support v4l2request. The PKGBUILD https://github.com/iuncuim/manjaro-h616/blob/main/mpv-v4l2request/PKGBUILD Don't have experience to compile or build packages for Linux. Experience Armbian users and developers might be able to build the mpv-full-git for Debian Trixie.

Well I'm glad you found a way to get what you really needed and now have something that works : )

Many thanks for the reply! Good news is that with your guideline and a bit more information from qwen-code, I managed to chroot to it. It's a bit more complicated to do from a Ryzen Linux machine. A translation layer called "qemu-aarch64-static" is required. It's far more straightforward on a PineBook Pro due to the same architecture. Not so good ones is that reinstalling the old RPi5 specific 6.6 kernel still fails to boot. update-intramfs was automatically run during reinstalling the old kernel and uinitrd in /boot was updated by some scripts(according to last modified time stamp), with symlink as described in armbianEnv.txt. Everything seems to be at the right place and wired in the expected way. Quite confused. Great news is that despite the unsuccesful to restore the kernel, the chroot provide me an enough environment to utilize calcardbackup to extract the personal data from NextCloud database. Better news is that I took this opportunity to start fresh with Armbian 25.8.1 Debian Trixie with Kernel 6.12.44. So far it works beautifully on RPi5.

Ok, figured it out My first mistake was not copying the proper u-boot file to the /boot folder cause the folder didn't exist when I flashed it with Balena Second, this box has a weird set of hardware that had issues with CoreELEC and even the Official Android upgrade, hence bricking into the Android dead robot and allowing me to force an upgrade with the official Android that fixed the partitions so I could run Armbian Third, the correct DTB for this box was meson-gxm-q200.dtb that makes everything works (attached a hw info file for future references) As of the moment, the Armbian is working perfectly. SSH works and it's displaying everything correctly. Not going to mess with Wi-Fi cause I don't really care about it. Again, thank you so much SteeMan for the help, the instructions and everything. I'll upload the hw_info and the URL for both "official" Android 7.1.1 upgrades (PC and SD flash images) for anyone to find cause it took me around a week to find those. Official MeCool BB2 Pro Android: https://www.geekbuying.com/geekgiz/2018/06/mecool-bb2-pro-s912-3gb16gb-tv-box-firmware-update-20180202/?admitad_uid=b4ee2a23c13552c70bd97fdfc0371b76&utm_source=4pda.ru&utm_medium=referral&utm_campaign=ilia hw_info.log

OK, thank you... was looking for the script on google...😁 I can confirm that the entries marked after "openmediavault" in the original /etc/fstab on the SD were not copied to /rootfs/etc/fstab in emmc. After copying them manually, and reboot, OMV and docker started correctly. Only two disks appear as missing from OMV, but all services seem ok, so I will post this question on the OMV forums, as I think it is best suited there.

@JaydenWithaWhy ok ,the source is right. The multitool should leave a dmesg log in the MULTITOOL partition of the sdcard; that log could be handy to understand what's wrong. Also you can access via SSH and run the multitool from there, so you may get some clearer output and some more details about the error. A last note, I never tested it with a 128gb sdcard; it should work but bugs are around the corner...