All Activity

Can you try if any of the H3 images from libre-elec would get you video acceleration? https://libreelec.tv/downloads/allwinner/ i once tried the orange pi pc image in my orange pi zero lts (h3) and it worked

Hi friends, back to the Gnome version which works incredibly well It works so well that I put my big desktop tower away and have been getting by strictly on this Armbian Gnome environment. I will be donating to Armbian soon However, I am curious, does anybody know how to fix the resume from suspend? For me, the computer goes into suspend mode just fine, but when I tap a keyboard key, the LED's will light on the keyboard indicating they have power, but the system never comes back. If I press the power button on the Orange Pi 5 itself, the system resumes perfectly -- no crashes, everything works as intended I just need it to work from a keyboard press instead! Thanks!

Exactly -- this is the same symptom I experience as well, plasmashell window popups with error reporting. Some retry buttons and so on, none of which do anything significant

Those specific patches only apply to the H61X SOCs. Very Strange that hardware decoding is apparently slower. Out of interest if you run something like glxgears to see what the reported screen refresh rate is. Not impossible to be the VPU but I suspect it is more likely to be the dma-buf transfers which could be a potential bottleneck. Could you provide a more detailed log by --log-file=test1.txt When working with the framebuffer, try drm-copy instead of drm.

That issue was just dealt with by disabling cruft instead. If you want to test a newer uboot with a reenabled cruft you will again need to go into building and testing, followed by a PR.

It seems that the problem has been under consideration since mid-May, so we are waiting for a bootloader update. https://github.com/armbian/build/issues/8197

@Nick A 👍

@laibsch It seems that if you set the pixel clock or refresh rate too high that you can shorten its lifespan. But when you use extreme values and the display doesn't have any protection in rare cases you can even damage it. A bigger chance is driver instability or a distorted display.

Device: Orange-Pi-5-Plus Armbian-KDE-Neon After update this morning, KDE-Neon no longer boot up successfully to Plasma Desktop. Error "plasmashell" crash handle pop-up. Able to get into tty session by "ctrl+alt+F3" but not able to boot up successfully to KDE Plasma Desktop after the update/upgrade this morning.

Maybe upstream regression. KDE is using upstream testing branch.

@Nick A could you help me get the dram settings??? My box don't have root access, on aida64, it says my box has root, but the tv info (https://play.google.com/store/apps/details?id=com.saksham.developer.tvinfo&hl=en&pli=1) says it is not rooted?

pinging maintainer @Efe Çetin

@Nick A To be honest i don't really think about debug my box, but i sure will do more research after getting all settings done.

close investigation it seems to use grub, not bootp, card written does not show any activity of green led even after 10 minutes from powerup. Do you have some of the magic twanger needed to boot a pi? Thank you, gene1934

@royk What is the risk of doing that? Can you do actual hardware damage this way or would it be a case of reflashing in the worst case?

adding COMPRESS_OUTPUTIMAGE to your call will compress your image. $ ./compile.sh build BOARD=rockpi-s BRANCH=current BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=trixie COMPRESS_OUTPUTIMAGE=xz [...] $ ls -lh output/images/*.xz -rw-rw-r-- 1 user root 342M Aug 15 01:03 output/images/Armbian-unofficial_25.11.0-trunk_Rockpi-s_trixie_current_6.12.41_minimal.img.xz

There is no overlay for that, but at your own risk you can edit the current overlay with some help of AI. But it will need the exact data of the data sheet. Just upload the data sheet, overlay and relevant dts/dtsi files (some of the includes and includes of the includes of rk3588/rk3588s) and ask to make an overlay for this display for Armbian.

Compiling your own image may sound dauting but is actually fairly easy. Help is also available, just ask. https://docs.armbian.com/Developer-Guide_Building-with-Docker/ https://evilolaf.github.io/docupreview/Developer-Guide_Build-Preparation/ https://www.youtube.com/watch?v=kQcEFsXEJEE

Orange Pi 5 user here, got a new NVMe and decided to try the KDE Neon image for a first time, as it's reported that it's been tested and works: And it does -- until you do an apt update and reboot. Upon reboot, the graphical client and cursor appear but keeps popping up a bunch of error reporting windows, because KWin has crashed Just curious if anyone else wants to try it and confirm because you might want to remove that blurb Gnome image works great though, I've been running it full-time as a desktop with excellent stability and long long uptime

I wonder if the ENOENT at around line 493 of your log has anything to do with this. Maybe @schwar3kat has a comment?

Bookworm is going to remain as an armbian-build option, right?

The uncompressed minimal image is about 1.5GB. How large is your trixie based image after you compress it with xz ?

Hi, trying to get a bit deeper into Armbian, I tried to create my own minimal Trixie-based image for the RockPI-S. I'm using a Ubuntu Noble VM and I managed to run a successfull build following the quick start guide. However, creating an image using ./compile.sh build BOARD=rockpi-s BRANCH=current BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=trixie leads to an image with a size around 1.5GB. Compared to the downloadable minimal images, which have 200MB-300MB, this is quite large. Does anyone has any hints on how to proceed in order to self-build images comparable to the ones offered for download? Cheers,

@mdidis do non secure boot images show any output. The one posted is an android uboot output.