Active threads

That seems to have gone away. ? SNILMERG... Now using very small but 1920x1080 screen, xfce terminal text is about 7 microns tall, way too small for my ancient eyes, Simplified keyboard. ctrl&shift&+ magnify's text but when big enough to read, bottom of xfce4 terminal is offscreen below bottom of screen, so cannot see command line. Is there a keycode combo that expands text independently from terminal window size? Thank you.

The most interesting thing is that everything works fine for joshua-riek Ubuntu 24.04 with the 6.1 kernel https://joshua-riek.github.io/ubuntu-rockchip-download/boards/orangepi-5-plus.html

Armbian kernel and BSP Debian/Ubuntu userland

You are still using an old Linux. You need Linux 6.13 or newer. You need to build your own Armbian OS. Also, don't forget the cma=256M kernel argument

I was just wondering if there would be an issue because of different U-Boot and kernel combination in the 2 tests, but that does not seem to be the case. I think there might be some issue with the controller in the eMMC module that is starting to reveal when wear-level is or is getting higher. What fsck commands are done? So how is it fixed and is it fixed or is only metadata corrected and might there be corrupted data-blocks still without knowing. I don't use Ext4, I use Btrfs for rootfs and all other storage devices. In doubt, I use DUP profile for meta data, that is more for HDDs. As said Btrfs allows adhoc or regular scrubs, you will be able to detect where corrupt blocks are if that is the issue. It also might be that there is an issue in the 6.6 kernel that reveals itself when higher write delays or so, maybe update the OS. Maybe mmc-utils can show some issue (I have no experience with it).

reopening after moving to "Software / Applications / Userspace"

You realized the wrong thing: the topic is actual but this is not a forum where to discuss about Android or stock firmwares

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

@Nick A thank you.

Hi @dale What is your DTS node for your display? My first guess is that your DT node is not being picked up/inexistent since the module loads but the display device is not present. You can use dtc /proc/device-tree to see your loaded DT and find your display node, if any. Then, have you checked dmesg for any tm16xx kernel message? Then, you can ls /sys/class/leds to see if any device were created. The display-service/display-utils scripts expect /sys/class/leds/display. That should not be your issue here, but I'm not sure that aip1688 is the same as tm1628 variants. Googling aip1688 list it besides aip1618, so that would be the tm1618 variant. Whatsoever, I think you should have partial working display if using tm1628. To be 100% of which compatible string to use, we would need the aip1688 datasheet but I couldn't find it online. Good luck with your experimentation! Let me know how you results.

Anyone an idea?

Yup, I opened a bug report about this on his github, I have yet to receive an answer. I'm having trouble figuring out if it's a hardware issue or a software issue, since I don't have a second bug to test at the same time. When I try the Makerbase OS on this same board, I don't have connectivity either, but at least, the link led turns on and off with the cable connect/disconnect.

Did you try to build the image with compile.sh and this following setting? INCLUDE_HOME_DIR=yes See https://docs.armbian.com/Developer-Guide_Build-Switches/#advanced

Yeah, also on my laptop (Arch with upstream 6.16 kernel) this problem does not happen, so it shouldn't be because of specific patches to the rtw88 kernel in the RPi kernel repo. It only happens when I use the kernel built with Armbian build system. I am completely clueless about what could be causing this 🤷‍♂️

Sorry that was resolved 2 days ago, but I don't see and never seen this long list. Only 3 options vendor 6.1, 6.12 and edge (6.16), This morning I also seen the u-boot wasn't the good one. I downloaded for rock5-itx, but had linux-u-boot-cyber-aib-rk3588-edge instead of linux-u-boot-rock-5-itx-edge, changed it, rebooted (on 6.16) worked, tried again 6.12, still no display. I needed to arch-chroot on the armbian to take a screenshot (but I've the same dispay on armbian itself): I seen 6.16.4 is now available and work, after /boot/config-6.16.4-edge-rockchip64, gcc 13.3.0 is now again used instead of old 11.x :). Debian Trixie has GCC 14.2.0 CONFIG_CC_VERSION_TEXT="aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0" And after changelog on kernel.org, patch for AV1 acceleration had been applied on this version: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.16.4 Fixes: 003afda97c65 ("media: verisilicon: Enable AV1 decoder on rk3588") Sorry I maybe mix too much subjects in the same post, but: I also seen a minimal IoT version of Trixie for Rock5-itx. Can I made safely a debian os upgrade from apt? Or is it better to wait release for desktop version ? Another point. On armbian, only LLVMpipe is used, I compiled last mesa git on arch, will try to do this for debian too. and some application that need to use EGL+dri (wings3D, blender, obs) report broken DRI2 access. I'm not sure if it's due to some kernel patchs (I reuse the armbian 6.16 kernel on arch), or to the current state of mesa-git. They all works with llvmpipe. Othere applications like PPSSPPSDL work fine without it. Ex, with wings3d + forced zink: MESA_LOADER_DRIVER_OVERRIDE=zink GALLIUM_DRIVER=zink wings3d WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance libEGL warning: egl: failed to create dri2 screen WARNING: Some incorrect rendering might occur because the selected Vulkan device (Mali-G610) doesn't support base Zink requirements: feats.features.fillModeNonSolid feats.features.shaderClipDistance

Easiest way is to use the customize-image.sh file in userpatches. Stuff there gets executed within chroot on the sdcard just before its closed and assembled. More advanced way is using extensions. Check extensions folder for examples.

You can either experiment with the CLEAN_LEVEL switch or use kernel-patch or uboot-patch (depending on what you want to modify) to create proper patch files from the diff.

Did you download stretch already, before I remove it to put up Bionic?

Hello, everyone. I'm using Armbian_25.5.2_Orangepizero3_bookworm_current_6.12.30-homeassistant_minimal on 4GB OpiZero3. When booting from sd, the bluetooth controller is initialized correctly. I made a boot from usb-ssd via armbian-config: everything works fine, but the bluetooth controller is not initialized. /sys/class/bluetooth is empty. Switch back to sd - it works again. Boot from ssd - no. I compared whether it transferred the distribution correctly from sd to ssd - all files are the same. What could be the problem?

This looks normal. Most of those boards have bootloaders at locations prior to boot partition. Boot loop. This can be many things - i would guess kernel crash and watchdog issue restart. Why that happens? Hard to tell. This way? sudo screen /dev/ttyUSB0 115200 It should prompt out something.

Thank you @Werner, for letting us know and for your efforts

it appears to be a useful application is there a way to use it without a network

@Nick A it has same issue. I thik it is related to the device tree declaration. Should it be something like this? https://github.com/LYU4662/aic8800-sdio-linux-1.0

I looked a little closer and the included cpufrequtil init script is totally unaware of SoC clustering. If you put in a max value for the A76, it won't work for the A55. So I threw the problem into AI and asked for a flexible SoC solution (I'm of course simplifying it). This is what it gave me. Lightly tested: per cluster governors, per cluster min/max speed, ability to specify "min" and "max" rather than numeric values. cpufrequtils-default -> /etc/default/cpufrequtils cpufrequtils -> /etc/init.d/cpufrequtil YMMV. cpufrequtils cpufrequtils-default

Yes. Installing this package on Debian-based build hosts fixed the issue. I don't think we have any developers using Arch so there aren't much tests of any other distros to ensure compatibility. Main focus is on Noble. If there is an equivalent package for arch try installing on the host machine and retry. Having it inside the docker container may not be enough.