I want to know that too

Oh yea, my trust with Radxa was gone a few months after purchasing two of these. It was a mini NAS kit. The 4c has it's CPU on the bottom side. Making it difficult to use it anywhere else. Not to mention they stopped developing for the 4c after Bullseye. You can't even find it in their new docs page lesson learned. If I ever go SoB again it'll have to be a Raspberry Pi. Which I feel is overpriced when compared to other options.

@martinayotte Hello. Seems once you was dig into this problem too.

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 are also another evidence about RTS\RS485 issues on 8250 in links below. And mention of some "RS485" state machine, "RS485 software emulation" what "may be buggy" in topic i cant find now.

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