All Activity

I was successful in compiling mpv-0.3.9 + the 2 patches from PR14690. I downloaded the release mpv as a tar.gz, expanded it, and applied the 2 patches. One hunk failed but it wasnt needed A 720p h264 video played with 10% CPU: (note that the options are --hwdec=v4l2request --drm-drmprime-video-plane=primary --drm-draw-plane=overlay -v Next, I tried with a 1080p h264... in this case, I needed the extraargs=cma=256M line in armbianEnv.txt. Result, low CPU usage, but dropped frames (choppy video) I didn't need to install mpv, because I ran it from within the build directory Removing the --drm-drmprime-video-plane=primary --drm-draw-plane=overlay from the options didn't make any positive or negative difference I repeated the test with mpv-0.4.0 and the result was the same. I am using linux 6.15.4... tomorrow I will re-test with linux 6.16.8 and again with labwc (wayland)

@emor acid can you post your full dmesg.

I experienced the same you did, but with an M2 (and some custom build kernel). The "quick" solutions: - switch to one of the main windowmanagers, say Gnome or Plasma (perhaps the Gnome or QT-tools works better, "not-tested!") - switch to Wayland (while the window-setup-tool did not work in lxqt/x11 it worked from the start with lxqt/wayland) The third option would be to re-implement the windows-setup-tools to fit your hardware, but I guess that won't be quick. The problem as I see it: X11 is getting on in years and while tools exist to solve the problem, the support is lacking. Especially when running a minimal X11-windowmanager with a "non-standard GPU", the accompanying tools are getting more and more obsolete. Mali support is "recent" (here I count both G52 Panfrost from 2020 and G610 Panthor support from 2023). From Panfrost on the drivers seem to have been developed with Wayland in mind, X11 being included only for compatibility. You might find X11 to be still more stable right now, for performance and functionality Wayland is a already step forward. I expect X11 to fall behind more and more on stability as well. For the RK3588 I found redshift and dual screen failing to work as intended. Redshift does nothing where it should change colors. I could not switch dual screens from mirroring to extended screens in X11, while with Wayland it works from the start with an extended screen. That leaves 2 options: the display-setting-tools are lacking or the implementation is of mesa/panthor/X11 is incomplete. So the question is what do you think the way to go for the user interface is: Wayland or X11? PS As for the M2 with dualscreen over DP1.2-altmode: support is there for 6.17 and a lot of patches. If you wait for 6.18 most important patches should be mainlined (the DTS-patches being the exception). At least, I think I'll skip 6.17 in favour of 6.18-rc1.

Thanks. I build kernel yesterday. Quite long building process. It's simple with your steps but only what worry me is a size of kernel image as I got 1.3GB kernel file at the end as I assume that kernel is build with all available options selected (but this is only my assumption). Is there any kernel config from current kernel which I could use to build new kernel to make it smaller ?

@Meestor_X Please check the following: on a running device. It seems that we have a more reliable way to determine the block device SD or eMMC

After compiling and testing, the wired network is still invalid

Use them as command line switches, like code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BUILD_MINIMAL=yes FULL_DESKTOP=no ... Used by CI only which kernel to do automatic build tests.

I don't have IR device to test. While in kernel driver code there is pm_ops defined: https://github.com/armbian/linux-rockchip/blob/rk-6.1-rkr5.1/drivers/input/remotectl/rockchip_pwm_remotectl.c#L1063-L1066

output.txt output.txt is my android img dts, can you help me ? which one i need change? @Nick A

To keep the forum updated: I closed my PR to downgrade all NanoPC-T6 boards to use HS200 mode, since there are other folks who do have the NanoPC-T6 and can successfully use HS400 mode. @SuperKali opened up a PR to downgrade all NanoPC-T6 boards to use HS400 mode without enhanced strobe as "This should maintains the same ~400MB/s throughput while eliminating I/O errors under load.". I tried applying the patch on my board, but unfortunately still hit I/O errors. @SuperKali had suggested on my original PR to try reducing the eMMC frequency from the default 200000000 to 150000000. I created an overlay for this... and it worked! I'm going to prepare a PR tomorrow to add that overlay as a kernel overlay, so that others who are experiencing this issue can opt-in to it without needing to find this thread and copy the overlay file.

@JohnTheCoolingFan I tested a Debian Trixie image from the website ( Armbian_25.8.1_Bigtreetech-cb1_trixie_current_6.12.35_minimal.img.xz ) and it seems to be stable even with the default configuration that uses systemd-networkd.

Using Armbian_25.8.1_Odroidxu4_noble_current_6.6.102.img I can boot off SD. Then when I run nand-sata-install it sharts and comes up with initramfs prompt. I'll try to fix it there next time, but I'm just using a 3.5" SATA laptop disk with USB controller.

http://armbian.lv.auroradev.org/beta bookworm/main armhf armbian-bsp-cli-bananapim2ultra-current armhf 25.11.0-trunk.302 [434 kB] http://armbian.lv.auroradev.org/beta bookworm/main armhf armbian-firmware all 25.11.0-trunk.302 [100 MB] http://armbian.lv.auroradev.org/beta bookworm/main armhf linux-dtb-current-sunxi armhf 25.11.0-trunk.302 [211 kB] http://armbian.lv.auroradev.org/beta bookworm/main armhf linux-image-current-sunxi armhf 25.11.0-trunk.302 [41.8 MB] http://armbian.lv.auroradev.org/beta bookworm/main armhf linux-u-boot-bananapim2ultra-current armhf 25.11.0-trunk.302 [271 kB] after update fastfetch: Armbian 25.11.0-trunk.297 bookworm armv7l

Recently, first when updating the OrangePi 3B, and now the BananaPi M2 Ultra, the /ect/os-release file, *PRETTY_NAME=*trunk.XXX*, has stopped updating correctly. XXX doesn't change and doesn't match the current value. (rolling release)

Thank you for the answer. Yes I will try the various dts, so far I have found that librelec - despiite not running at all, is crashing giving a visible prompt on the HDMI. I will try to compare that dtb/dts to the default rk3318-box and be back.

Try the 'minimal-iot' flavor, I think that's the only one that boots from the current images. You can then add the desired packages and even switch to the 'edge' kernel from armbian-config.

Ok, that makes sense. Is there an edge build for this or does one have to compile "edge" builds? Sry, I'm just a little confused.

If you don't mind, just a few points of confirmation. Reading the documentation and the info on the GitHub page for boards, I gather I can probably expect to use ./compile.sh cubox-i However looking in the cubox-i.csc file, which at this moment looks like: # Freescale / NXP iMx6 dual-quad core 1GB/2GB RAM SoC Wifi/BT GBE BOARD_NAME="Cubox i2eX/i4" BOARDFAMILY="imx6" BOARD_MAINTAINER="" BOOTCONFIG="mx6cuboxi_defconfig" KERNEL_TARGET="current,edge" KERNEL_TEST_TARGET="current" FULL_DESKTOP="yes" BOOT_LOGO="desktop" PACKAGE_LIST_BOARD="rfkill bluetooth bluez bluez-tools" I suspect I want to add/change (at least) the following build switches BUILD_MINIMAL="yes" FULL_DESKTOP="no" since I (think I) want the minimal Ubuntu 24.04. The build switches page doesn't talk about the KERNEL_TARGET nor the KERNEL_TEST_TARGET switches. I'm puzzled why there are two kernel targets but only one test target. Also, is there somewhere I can read up on the differences between targets, especially "current" and "edge"? Same sort of question about BOOT_LOGO - are those listed / explained somewhere? Given that I'm looking for a minimal / non-desktop configuration, I still guess I can build from either a server or a desktop Ubuntu running in a VM (or bare metal) as per @Werner's comment. Does that sound correct? Finally I'm guessing this should generate a u-boot based image, given that the Cubox uses u-boot; is that correct? Thanks very much in advance for any clarification.

@NiTr0 Armbian doesn't use $fdtfile because U-Boot carries the same DT already, in memory. If you want to use a different DT, add fdtfile=yourdt to the /boot/armbianEnv.txt. I haven't tried this method. I don’t remember if I tested orange pi 2w. It’s been awhile since I released the image. I think someone has. I have a board laying around somewhere. I'll try it when I'm not busy.

thanks. also, did you test orange pi 2w armbian release with h618 dtb? and how to specify dtb in proper way? how it's specified in armbian images? I didn't see "fdtfile=<something>" in images.

Maybe another important data point to consider – are both of you running the same firmware?

Thank you very much. You are my superman.

@emor acid This was discussed before in this thread. Here are the links. Hope they help. 1) https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/page/4/#findComment-187672 2) https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/page/21/#findComment-218004 @NiTr0 You need to freeze kernel updates in the armbian-config tool. The images I released use kernel version 6.12. Linux version 6.15.4-edge-sunxi64 (build@armbian)

I didn't test eMMC, whilst the bug occurred (it definitely impacted the SD card), but I did try using a USB drive and I can confirm (for me at least) the issue went away (the issue impacts the MMC stack, specifically), so if you have a spare USB drive hanging around, and you want an easier interim "fix" you can try putting the rootfs on a USB drive in the meantime. To be clear, the bug still did occur, but as it only impacted the SD card (which was for boot only), it only spammed my log files, but did not impact my day to day running (which with rootfs on SD, it definitely did. Made the device completely unusable pending a hard reset). I'll put the build instructions here too, because it's very simple (This was using a Debian Bookworm/Trixie host): sudo apt install git git clone --depth=1 https://github.com/armbian/build.git cd build ./compile.sh \ BOARD=odroidc1 \ BRANCH=current \ RELEASE=trixie \ BUILD_MINIMAL=yes \ BUILD_DESKTOP=no \ CLEAN_LEVEL= \ PREFER_DOCKER=no \ KERNEL_CONFIGURE=no \ COMPRESS_OUTPUTIMAGE=sha,gpg,img And that's it. Image is saved in: ./output/images