Active threads

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.

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

Should be resolved

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

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

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

No one has ever submitted this for inclusion in Armbian. This is a community supported board. If anyone were to submit this as a PR it would almost certainly be included as the approval process for community supported boards is a low bar, basically that it doesn't break the build.

I am using :- [ Ubuntu 24.04 (Noble)](https://dl.armbian.com/rock-5b-plus/Noble_vendor_server) from :- [Radxa Rock 5B Plus - Armbian](https://www.armbian.com/rock-5b-plus/) Trying to turn fan on on Radxa Rock 5B+ selecting the device using armbian-config actually makes it disappear I am getting `line 3: echo: write error:Device or resource busy`

@rpq399 HI! Can you share links to firmware and usb modules and the way to reinstall before the reboot, please?

duplicate

I have tried A lot of ROMs and they do not work. The device is not working now. Please help. Thank you.

No clue, sorry. Maybe the driver might be optimized to work best with wayland. Maybe there is a fix pending or already merged into newer Linux version.

Addendum: An Easy Way To Bypass Grub's Self-Centric Orientation & Eliminate The Need For OS-Prober 1. Assuming you already have your EFI partition set up, for any OS that's mounting the EFI partition, stop that. In the /etc/fstab file, comment out (with a #) the line where it's mounted (i.e. as /boot/efi/). 2. Install grub on each OS. You can keep the /boot/grub/ directory on the same partition as root. Each installed OS will just update its own grub.cfg whenever it's needed. # If the your OS doesn't have a /boot/efi/ directory, create one. mkdir /boot/efi # Install grub. This will force it to install even though it won't detect a genuine EFI. grub-install --efi-directory /boot/efi --force Remember if you need to disable os-prober (recommended), just comment-out its line in /etc/default/grub. 3. Optional: Eliminate the pesky EFI Firmware menu entry in each OS this way: cd /etc/grub.d mkdir skip.d mv 30_uefi-firmware skip.d/ 4. Update Grub with your current kernels update-grub 5. Create a small partition for grub. 64 MB will suffice. 6. Choose an OS's grub, and copy all files from /boot/grub/ to that small grub partition. 7. On that grub partition, create a new grub.cfg. Here is a sample: set timeout=10 # Load Modules insmod all_video insmod part_gpt insmod ext2 insmod png # Setup Background loadfont unicode terminal_output gfxterm background_image /grub-16x9.png set color_normal=white/black set color_highlight=black/white # Menu Entries menuentry 'Orange PI Bookworm' { search.fs_uuid df078711-12a0-4637-9264-bac72ee25e4c root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } menuentry 'Debian Trixie' { search.fs_uuid 1b6add1b-05ac-4568-bf54-1f920a6f8e3e root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } menuentry 'Armbian 25.8.1 Bookworm' { search.fs_uuid ecb0ae86-8f5c-477e-bcd0-bc77ee5ebee9 root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } menuentry 'Armbian 25.8.1 Trixie' { search.fs_uuid 6f2d1972-8868-4fb2-bde4-e14325ea4d31 root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } menuentry 'Armbian 25.8.1 Noble (Ubuntu 24.04)' { search.fs_uuid d974e989-b201-48c6-b74b-f9ab5dfdfdae root set prefix=($root)'/boot/grub' configfile $prefix/grub.cfg } Of course, change the menu entry titles and UUIDs to your own. 8. Copy the background image you'd like to use to your grub partition. On Debian, background images for grub are typically stored some place like this: /usr/share/desktop-base/emerald-theme/grub Note in the sample grub.cfg file, grub-16x9.png is the background image named. If you want to use a .jpg instead of a .png, change the insmod png to insmod jpeg. 9. In your EFI partition, modify the grub.cfg to be as follows: search.fs_uuid 3D53-E216 root set prefix=($root)'/' configfile $prefix/grub.cfg ...changing the UUID to that of your grub partition. Usage Select the OS you want. That will take you to the OS's own grub menu, which will likely show you two options, the main boot option and "Advanced" boot options. If you select an operating system and wish to change your mind, the ESCAPE key will return you to your previous menu. Problems I did this and everything worked well except the Armbian Noble (Ubuntu) entry. I coped Debian Bookworm's grub to my grub partition, and either Ubuntu's grub is buggy or apparently Ubuntu's grub used language in its grub.cfg that Debian's grub didn't like. It boots into Ubuntu automatically, but it doesn't show any boot menu. I set its timeout for 10 seconds, so it sits with a blank screen for 10 seconds before it boots. Update: I replaced the grub files on my grub partition with those from Debian Trixie. Same results with Armbian Noble (Ubuntu).

Hi there, I ran octoprint and klipper on a orangepi zero (not at the same time). Octoprint from docker and klipper I cannot remember. Octoprint ran fine but it did have some issues when the CPU got overloaded with loading a new gcode file while printing for example. If you do things one by one it should be OKish. Btw i ran octoprint in a 512MB version, not on the 256MB one. Groetjes,

So I looked into this, and unfortunately, no dice. I am happy to investigate further, if you so wish, but I'm happy enough with the way it works currently (auto patching the dtb after a kernel update) so am unlikely to go exploring further on my own. To let you know what I did: copied the dtbo to /boot/dtb/amlogic/overlay/meson-gxl-s905w-tx3-mini-openvfd.dtbo Added to /boot/extlinux/extlinux.conf: fdtoverlays /dtb/amlogic/overlay/meson-gxl-s905w-tx3-mini-openvfd.dtbo (I also tried with /boot prepended to the path as well, but same issue) note: I assume FDTOVERLAYS is a typo from the armbianEnv.txt days, so I went with the lowercase as that is standard for extlinux The device would not come up on the network. I plugged in an HDMI monitor and found that it would hang at: ethernet end0: renamed from eth0 Which is.... odd. I suspect one of 2 things: My entry in extlinux.conf is incorrect (entirely plausible, I'm struggling to find documentation, I've just gone on what you've said, and also changed the capitalisation!) U-Boot overlays are applied differently than fdtoverlay in Linux. It’s possible U-Boot leaves something unaligned or adds an unexpected property, and the kernel hits a corner case. I realise that the above is noway near enough information, however, connecting directly to serial is not realistic at this stage, but I can attach a netconsole if needs be, as we are reaching the kernel, and provide further output. Like I say though, I will only do this if you think there is value in it. Whilst my method might not be the preferred way, it does work, at least.

@DiplDi I was doing some experiments on Armbian 25.8.1 Trixie, and I decided to do a quick try of installing the XFCE desktop (along with some others): sudo apt-get -o APT::Install-Recommends="true" install task-xfce-desktop It works under X, but not under Wayland. I found out that its Wayland support is experimental, and that if you install the labwc package, that will get it running (very very badly) under Wayland. But it does work well under X. It's possible a different wayland compositor (than labwc) will work better? I also tried with the Vendor kernel (with the Panthor GPU overlay), and the edge kernel. Edge GPU performs seemingly not at all under X, but vendor with Panthor overlay performs well in X. I initially logged in via the SDDM display manager, but I switched to LightDM, and that worked as well, although with a hiccup.

That change is already merged into Armbian for the orange pi zero LTS. It was such a long time ago, I don't remember how to use it right now. https://github.com/armbian/build/blob/9ef5b99b220c5e77b55514136e025008c16ccbfd/patch/kernel/archive/sunxi-6.12/patches.armbian/enable-TV-Output-on-OrangePi-Zero-LTE.patch#L8 https://github.com/armbian/build/commit/41260ac309b487d241fec97ffbdeced730bc2d04 Partial progress log https://forum.armbian.com/topic/22226-orange-pi-zero-lts-tv-out-in-2022/#findComment-162035

Is it the 128x160 1.8" red screen? Combine the knowledge of https://forums.raspberrypi.com/viewtopic.php?t=380704&hilit=ST7735S#p2275556 and https://forum.armbian.com/topic/47971-driving-the-ili9488-lcd-40-inch-cheap-chinese-clone/ To use the panel-mipi-dbi-spi driver, which is more universal for SPI screens Warning: you will not get the spidev, and the linux OS will handle all the rendering. Also, X11 may have a problem with Linux 6.14, unless someone fixes a bug

Abandoned vendor-provided BSP roadblocks can be overcome when mainline Open Source projects like the Linux kernel are integrated directly. Get your upstreamed BSPs from day one. View the full article

I tested the upstream Debian and I only got 4GB as well, I don't know if that was stable or not. Actually some upstream Debian images I tried didn't work at all at first. Then I upgraded the firmwares on my board, following these instructions: https://forum.rvspace.org/t/visionfive-2-debian-image-released/994/75 Bu I was more precise than that, first I used the sdcard image and fimware files from 2.6.0 (said to work in that page): https://github.com/starfive-tech/VisionFive2/releases/tag/VF2_v2.6.0 Note: I had no display, I ran the firmware update commands over SSH. Then I rebooted, using the sdcard image from 2.11.5 (arbitrary chosen): https://github.com/starfive-tech/VisionFive2/releases/tag/VF2_v2.11.5 But I used the latest (5.11.3) firmware files to update the firmware: https://github.com/starfive-tech/VisionFive2/releases/tag/JH7110_VF2_515_v5.11.3 After that, I flased the latest image (202409), for sdcard: starfive-jh7110-202409-SD-minimal-desktop-wayland.img The whole 8GB is displayed and everything looks stable, the board is running since 9 hours without problem. But one problem is that this Debian image is based on an now-old Debian Trixie/Sid snapshot, which is painful to deal whit. I'll try again the Armbian image later to see if the firmware update fixed the memory size problem and the stability.