Active threads

I have found, what is an old issue, first noted long ago in https://stackoverflow.com/questions/45813755/linux-8250-rs485-rts-troubleshooting The user has noted, what it possible misuse of TEMT\THRE IRQs. Looking at 6.12 kernel 8250 drivers, i have found it was changed in the part what was the topic in stackoverflow post. https://github.com/torvalds/linux/commit/b54f7a922d334014071ddaea313a045781024f4d I am novice linux user and have lack of understanding many things, including tty to phys architecture and it settings. Maybe im been able to try fix driver itself (have experience to write baremetal IRQ driver rs485 & uart drivers and modbus stack), but i have really big issues with linux modules building and etc.

There a more important things to do (first). Like even creating a package for the OPI5 as a quick scan reveals there is none. So currently an option is to compile U-Boot yourself with added Btrfs support. And/or also do that on github and make pull request. Over time, more U-Boot will support Btrfs I guess, so how do you think people should spent their time. I did look into armbian-install but it is not according to my wishes/methods. It should work, but more work for me to revert/change than just use manual rsync and btrfs options as I want it. I have some backup/cloning scripting that fits Opensuse methods, not Debian. Your other option is to simply install/copy manually and maintain an extra boot/1st partition, FAT formatted. Several old installs do it like that and it is anyway you have to deal with for 'normal' UEFI computers. So that is why I do that. For simple/cheap/headless SBCs, just U-Boot and single partition is very much preferred I think, as that means less objects to maintain and also it allows seamless systemd-nspawn startup/run. That is very handy method of doing things with images. As with multiple partition you need losetup first and select/mount rootfs partition as well manually. I also use extra 1stFAT so it is easier to experiment and switch bootloader and various boot methods/files. Or build your own image with Armbian build, then 1 linux commandline, 'push-button', if you would select /dev/mmcblk0 as image target and have your buildhost running from NVME. Also note that there is the tool btrfs-convert, it works on various SBC images, if you also change/fix boot settings. For Armbian, I think only change is the rootfstype= line in armbianEnv.txt And what works for several UEFI machines is that you add the boot partitions at the end, so you can just shrink rootfs partition a bit, no complete recreate, that might save time when full 4TB HDD. It must have the correct type then so 0xEF00 (ESP), so Windows oriented users will easily get in trouble. Not sure if that also works for Linux only method, seems 0xEA00, but would expect that. Anyway, this is all fixing afterwards options, it of course won't play nice with Ext4 auto expand filesystem method in every SBC image nowadays (eating your SD-card, you never manage to undo).

Sounds a bit like with My ROCK3A. Bought it last yer and with a SATA breakout board. That breakout board was a newer HW version with a but flatter and simpler (and cheaper of course) SATA connector, such that I could get a SATA cable connected as the MIPI DSI conector was in the way, just slightly too high. So for the 3 euros that it costed I thought, time to warm up the soldering iron and lift it a bit so a SATA cable fits. Radxa apologized and I think the idea was that I would get some new SATA thingy or so for free. Yeah right, trust is gone. That proved a second time as they did not take any further initiative. For example how do they think they can reach me (being at the at the other side of the world). Also now that combination is is just removed from the products page. Indeed they sell now own ASM1166 M.2 M-key modules, of course at a higher price that the generic ones on Aliexpress. No surprise form a Chinese a company, they just throw new boards on the market and hope someone will be their guinea-pig. Also your ROCK4C (non-plus) is not listed anymore. Also note it has no PCIE, so my guess is it uses some USB3 connection. I personally avoid it like a plague. Maybe it can save you in this case, maybe try to get a schematics of the PCB, then the whole thing might work with the HAT off and just GND+5V with own soldering/wiring. Else sell it befor it is too late. That is what also have advised a RPi5 + SATA HAT user who had trouble. As separate components, loss it not too big maybe. My ROCK3A+breakout board was 40 euros, great for replacing old PC for 1 SATA HDD. That those HATs are covering all GPIO, I know, that is why I never will buy a HAT again, also not a Raspberry I think who 'invented' it. I soldered extra wires on top. In your case I would solder the USB console cable on the underside, drop of hotglue and done. Faster than I can write this message. Or else look for a PUKE (Peripheral Under Kernel Environment module that is meant for debugging low-level U-Boot and kernel issues).

That's surprising. All I knew so far was that modules need to be present, either built-in or as dynamically loaded modules. Do you have a reference for this anomaly?

Hey. I have no idea whether this will work for the H313 but I got my H713 Projector rooted using the following method. I'm assuming you at least have the stock firmware, but if not, it seems you can grab it here: https://androidpctv.com/firmware-android-tv-box-h96-max-h313 I dislike Windows so I was irritated that PhoenixSuit only seemed to run well on that platform, and ImgRePacker wasn't great either but then I found this project on GitHub: https://github.com/uictorius/imagewty-tool I'm unsure how you'd do this on Windows and I assume you know of a way to flash your box with a custom img file, but this was my work flow: 1. Back up your original img somewhere safe. Don't play around with this file. 2. Grab the latest available version of Magisk from https://github.com/topjohnwu/Magisk/releases. You want the APK file. 3. Go to this Project on GitHub. CircleTeam provide a browser based method of doing this here: https://circlecashteam.github.io/MagiskPatcher/ 4. Using imagewty-tool you first want to grab your boot partition. Run this against your copy of your firmware img. Let's say it's called update.img: imagewty-tool extract update.img 5. This will extract a bunch of FEX files to a directory called update.img.dump. You want to find the file called "boot.fex" 6. Now copy that file and rename it to "boot.img". Go to the MagiskPatcher site. 7. Upload the "boot.img" file at "Upload boot image" and the Magisk APK at "Upload Magisk APK". 8. Select armeabi-v7a radio button, then check every box below except "Recovery Mode" and click "Patch". 9. After a minute or two, the program will download a new patched boot.img to your Downloads folder. 10. Let's say it's called "new-boot.img", you'll want to rename it as "boot.fex" and overwrite the original boot.fex file in the update.img.dump directory. 11. Run imagewty-tool again, but this time: imagewty-tool repack update.img.dump new-image.img The beauty of this is that repacking recalculates all V-file checksums automatically. 12. Flash new-image.img to your box whatever way you're used to doing it with PhoenixSuit or whatever. However, you're not done. 13. Hopefully the box boots up. Get to adb, grab the Magisk APK again and run: adb install Magisk*.apk Once installed, open the Magisk app up and it will say it needs to complete installation, so go ahead and allow that install. Select the Recommended radio button to install and then reboot. 14. Assuming all went well it should boot back up for you. Run this to check root: adb shell su whoami If all went well it should say "root" in your terminal rather than "shell". A dialogue will pop up on the Android screen asking to allow root privileges so go ahead and allow those.

Check out the learning experience in this thread: https://forum.armbian.com/topic/27457-connecting-banana-pi-m2-zero-with-ili9341-display-over-spi-on-latest-armbian-image/#comment-162359 In an ssh session, do this: $ tail -f /var/log/Xorg.0.log And see what happens when the X11 server crashes

Armbian monitor https://paste.armbian.com/sakicoqowe

Here are fix.

actually did some more digging and i think this describes the same issue that i am seeing with these newer sd cards in uboot spl. https://lore.kernel.org/u-boot/20251031145951.535376-1-c.stoidner@phytec.de/

T95 imin-EMCP-V1.0 Board

Hi, how do you mount the share? It might be that systemd manages the mount in newer systems, then, to umount you have to simply systemctl stop your-share.mount You can check with: systemctl list-units --type=mount --all To see if the mount is systemd managed

Continuing the tradition (1, 2) of micro-optimizations for single-board computers that come into my hands. This time I optimized or rather fixed the wake-up function via USB/WoL/WWoL on the Orange Pi 5 Plus. Also got the WiFi adapter RTW8852BE/RTW8852CE working (at least those are the ones I tested). I tested exclusively on the Vendor 6.1.x kernel since the main wake-up features via USB/PCIE/GPIO1-GPIO4 only work in it. I don't currently have the ability to test the new current kernel and I doubt that Power Management will work fully there. Armbian for Orange Pi 5 Plus from the official website, Vendor kernel (kernel 6.1.115-vendor-rk35xx), what does NOT work by default: 1. No WiFi modules that insert into the PCI-E M.2 socket E-Key work - fixed in dts below 2. Wake-up from USB (mouse/keyboard/even Bluetooth dongle) doesn't work - fixed in dts below 3. WoL via Ethernet (on two ports) - fixed in dts below I also conducted power consumption measurements in all these wake-up modes. Let's start with Ethernet ports (WoL won't work by default due to incomplete dts profile). You need to create an overlay file, links I've attached it to this message. To apply this overlay, you need to copy it somewhere on the single-board computer and execute the command: cd <path to rk3588-orangepi-5-plus-Wakeup-GPIO-RTC-USB-WoL-fixes.dts> sudo armbian-add-overlay rk3588-orangepi-5-plus-Wakeup-GPIO-RTC-USB-WoL-fixes.dts Reboot. (if it doesn't boot at all with it or something doesn't work, you can remove these changes from the /boot/overlay-user/ folder) Wake-up Timer Test: sudo sh -c "echo 0 > /sys/class/rtc/rtc0/wakealarm" sudo sh -c "echo `date '+%s' -d '+ 1 minutes'` > /sys/class/rtc/rtc0/wakealarm" sudo systemctl suspend (here we set wake-up in 1 minute from current time, you can choose seconds/minutes/hours and so on, maybe even days - haven't tested. Installing a battery on RTC is not necessary, Type-C power is sufficient) Power Consumption: Testing was performed on Imax B6 Evo / OWON HDS242S. Please note, power consumption of m.2 SSD, SD-card, eMMC is not accounted for here (ideally they should be powered off in sleep mode), but USB devices were not used, bare single-board computer was tested, each module will have its own consumption, especially USB-connected devices, add your values to the sleep mode consumption. Wake-up only via GPIO0 (this includes power button), RTC In this power-saving mode only the rk3588-orangepi-5-plus-Wakeup-GPIO0-RTC-only-fixes.dts profile is used, keep this in mind, it's not compatible with other dts, you need to choose only one option. I got these values: sudo shutdown -h now | 5.4V | 0.005W | 0.001A sudo systemctl suspend | 5.4V | 0.14W | 0.027A Wake-up via GPIO0, GPIO1-4, RTC, USB, WoL In this power-saving mode only the rk3588-orangepi-5-plus-Wakeup-GPIO-RTC-USB-WoL-fixes.dts profile is used, keep this in mind, it's not compatible with other dts, you need to choose only one option. sudo systemctl suspend | 5.4V | 0.25W | 0.046A RTL8125B (eth0 or eth1, can even be both): sudo ethtool -s eth0 wol g && sudo systemctl suspend | 5.4V | 0.33W | 0,061A RTW8852BE (external rtw8852be driver (rtw89 doesn't support WWoL for RTW8852BE in vendor 6.1 kernel)): sudo iw phy0 wowlan enable any && sudo systemctl suspend | 5.4V | 0.30W | 0,055A RTW8852CE (built-in rtw89 driver in the build): sudo iw phy0 wowlan enable magic-packet && sudo systemctl suspend | 5.4V | 0.27W | 0,051A (I want to note that the Ethernet ports on Orange Pi 5 Plus in WoL mode don't light up and don't show link activity, you can only find out if the link is working on the router or on the device to which the single-board computer is connected. In magic-packet standby mode the link switches to 10Mbit and for example on the router loses the assigned IP address, you can find out if the device is alive only by ARP scanning on the router itself or by the link light indication on the router itself. The same applies to WWoL (WiFi) - only on the router or device to which the single-board computer is connected can you check in active clients mode or ARP scan for the presence of MAC address) My Armbian build from the official website on Vendor 6.1 kernel where rtw89 (WiFi) modules are already compiled and pre-installed in the kernel has a peculiarity that this driver supports WWoL function only for RTW8852CE - this is a slightly different chip than the official proprietary WiFi module for Orange Pi 5 Plus which uses RTW8852BE. For WWoL to work on RTW8852BE you need to install a third-party driver, for example I recommend from this source. How to use WoL, WWoL: For wired network use ip and ethtool utilities, for wireless network iw. WoL over LAN WWoL over WiFi External Drivers: For RTW8852BE/RTW8852CE and others there are fairly recent drivers (at the time of writing this manual), here's a brief instruction on how to install them on Orange Pi 5 Plus. Issues: File: rk3588-orangepi-5-plus-Wakeup-GPIO-RTC-USB-WoL-fixes.dts File: rk3588-orangepi-5-plus-Wakeup-GPIO0-RTC-only-fixes.dts Original Link 4PDA

https://zuckerbude.org/armbian-using-kernel-config/

Once this is merged, more recent SoC code can be rebased on top:https://github.com/armbian/build/pull/9049

I am talking about hdmi audio. Analog audio works fine on both kernels. HDMI-Audio doesn't work in 6.16.8 kernel. I'll keep using v25.11.0-trunk.190 with kernel 6.15.4 for now since HDMI works there. I might experiment with those configs later, or perhaps it will get fixed in a future version. Thanks.

@Octavio Cuatrochio, you need root privileges to modify any partition at runtime. If you want to modify firmware, get update.zip to your PC, modify it, and flash using android's Settings->About->Local update.

Thanks for the suggestion, but it didn't work for me. Both /var/log/postgresql and /var/log.hdd/postgresql reverted to their pre-intervention ownership and permissions when I rebooted.

I am glad you made the LCD work with a DRM driver Three clarifications: the driver panel-mipi-dbi is provided in the OS image you write in the microSD. The DTS is something you get from this thread, and install it with armbian-add-overlay. Kungfupancake provides a txt or a bin file that defines the configuration sent to the LCD, when the kernel driver starts, and instructions on how to install it. The panel-mipi-dbi driver (the recent versions I tried) does not support X11, and you need 100% Wayland, and 0% X11 See my thread to install rpi-greeter (one of the 2 login managers that work with Wayland), and Labwc:

Those are super cheap maybe a dollar if shipped from Asia and an absolute essential tool for debugging. Get yourself one. http://debug.armbian.de

Hello and thank you for the problem report. What solution did orangepi.org provide for you? As you can see, nobody in the Armbian community was interested to step up and support this board and from what I have heard through the grapevine this is because of the poor support that orangepi.org gives to FOSS projects and communities such as armbian.com. Armbian has already pushed another update for Sunxi64. Maybe you are in luck and the problem is already fixed. If not, we are happy to accept a PR once orangepi.org has published a solution.

I find the lack of GRUB via HDMI too problematic, so I put EDK2-UEFI v1.1 in eMMC again. I needed to wipe it completely, just writing the part without partition table normally done for U-Boot kept using the 2025.10 U-boot that was written there. I do not know how that comes. I know EDK2-UEFI v1.1 will divert to SD-card, so I though I use that to test U-Boot again. - blkdiscard SD-card - write U-Boot SPL 2026.01-rc2_armbian-2026.01-rc2-S365a-Pb445-He3cc-V062a-Bbf55-R448a (Dec 03 2025 - 04:31:42 +0000) to it - type reboot After restart and desktop login no HDMI audio. Kernel log showed long series of audio driver related errors - shutdown and pull USB-C powerplug - plug it in again and let it boot - then no audio error and also hear a 'plop' in the monitor that means the audio is enabled/working So it seems something does not reset correctly, so powercycle needed, while HDMI monitor is kept powered and HDMI cable stays connected all the time. What is different now: - kernel 6.18.0-edge-rockchip64 - eMMC contains EDK2-UEFI v1.1 and passes control/boot to SD-card U-Boot But I think it is the powercycle that is the key thing. An interesting new feature of the 2026.01-rc2 U-Boot is that the CPU clock go down to 480 MHz when mainline kernel, was 1GHz. Is not lowering idle power though, is 3 W, is 1.5 W with vendor kernel. Not clear why that is.

@Malay Your board isn't a board supported by Armbian. It is status "Community Support" which means there is no maintainer for the board and it is people like you from the user community submitting PRs that keep it active.

@MMorales@mmie4jbcu i have the same x88 pro 20 clone like you guys, on the pcb is written "x88pro-rk3566-4d32-v1.0", which should state for 4gb ddr and 32gb rom i guess? I installed latest armbian for station m2 with image-included demo-box.dtb, everything is working so far, despite bluetooth (CDtech-208821C=RTL8821CS). installed armbian-firmware-full but bt still doesn't work. Maybe usefull for just Linux-Users (i don't have a windows pc): original loader didn't allow me to boot from sd-card, rkdeveloptool (or xrock or rdeveltool-gui) didn't work for me, so i used proprietary upgrade_tool for linux from rockchip: https://docs.radxa.com/en/zero/zero3/low-level-dev/upgrade-tool I downloaded this loader from radxa https://dl.radxa.com/rock3/images/loader/rk356x_spl_loader_ddr1056_v1.12.109_no_check_todly.bin and flashed it with: sudo ./upgrade_tool wl 0x0 rk356x_spl_loader_ddr1056_v1.12.109_no_check_todly.bin After that i put in the sdcard and it bootet straight (wait for min. 5 seconds) to armbian!

Made some progress today. For debugging, I built my own image with the Edge kernel (6.18). However, this time, the board did not even boot up and there was also no signal on HDMI. The last idea I had was to downgrade the kernel using armbian-config. But since the Ethernet is not working, I was trying to setup WiFi because armbian-config was trying to load apt cache but without internet, I cannot load anything. After multiple reboots, I slowly cached the apt. Then the armbian-config loaded. I downgraded the kernel from 6.12.60 to 6.6.63 and then the Ethernet started working fine! ☺️ Current version: $ uname -a Linux rockpi.dev.com 6.6.63-current-rockchip64 #2 SMP PREEMPT Fri Nov 22 14:38:37 UTC 2024 aarch64 GNU/Linux $ lsb_release -a Distributor ID: Debian Description: Armbian_community 26.2.0-trunk.44 trixie Release: 13 Codename: trixie I am now confident that somewhere after Kernel 6.6, the Ethernet is broken in Rockpi 4B.

That's not really possible either. The only thing that is possible is using my kernel build in Armbian environment to see how it is performing for you. With my jumpstart image, this is actually quite easy to implement. For this, both root filesystems just need to be mounted and extlinux/prepare-jump-start ${target-rootfs-mount-point} needs to be executed in the jumpstart rootfs. If the target system is now being booted with firmware that uses mainline U-Boot as the payload, nothing stands in the way of booting with my kernel. And don't worry, prepare-jump-start only adds files to the target rootfs. Nothing will be overwritten or deleted. If you want to give it a whirl, speak up and I will upload a current image. But you will be disappointed, because the stock kernel only provides the functionalities available with the officially released kernel. Both Armbian and my kernel build have already applied patches that may appear in a future official release. I doubt that you will succeed, because even the fedora organization only does a full rebuild once per release cycle. There is no advantage in rebuilding a component unmodified that leads to the same result as the package already provided. It only makes sense to do this when branching off the release version in order to create a synchronized basis for further development. Only modified packages will be replaced or upgraded. My weekly upgrade gives me several gigabytes of new packages each time because I'm on Rawhide. Somehow, I can no longer manage to stick to any official release versions.