eselarm

I thought you made a typo with HACS but it seems you mean this https://www.hacs.xyz/docs/use/ I guess, look there Armbian is not HA support or so. Or else ask som eAI tool for hints (and make sure you understand how to avoid hallucinations of such AI tooling).

OK, I did not look into further details, I don't have any of this HW. I only have same experience 10 years ago, 4G module works in USB adapter, did not get it to work in mPCIE slot. I am not sure if a DeviceTree patch/change can fix it, don't know enough of that description principles. As indicated, SeeedStudio can read this, it is their HW, maybe they should fix it for you.

My thinking is that with a standard example tool from libgpiod (gpioset) it should be possible to toggle a GPIO line. I see 'P05' that seems a pad number of the RK3576. I remember I had to dig deep in internet fora for something similar for BananaPi M1 to see what to put in armbianEnv.txt. Or NanoPi-NEO. The later I use with those example gpioset to toggle a GPIO to switch some own electronics on/off. You could also use lgpio (rpigpio successor or any other that can toggle pin states). Note that formally, you need to threat a GPIO line like a file, claim, open, close etc. After that state is undefined, but most SBC kernels keep the state, but formally undefined. See many many discussions on wiringpi etc. W.r.t. this combPHY: the RK3576/RK3588: those can act as several SerDes, it is sort of multiplexed, so cannot be all at the same time. But you need to look in schematics. I use the SATA<> PCIE2x1 swap (on E-key slot on ROCK5B and ROCK3A) but it very much depends on what firmware/bootloader and DTB(O) and kernel. For the ROCK3A for example, I still don't have it working according to I wish with mainline based U-Boot+kernel. Only vendor 6.1 and legacy U-Boot. I see on the SeeedStudio page: preloaded with Armbian, so this topics is a sort of test-case IMO: is that claim with mainline based or vendor/legacy Rockchip; I guess the latter, so maybe list versions of various system software. 'Forky' is not released, so a moving target or rolling release, others don't know what versions you use so not possible to reproduce the issue(s).

A quick diff scan: 'kompare config-6.18.34+rpt-rpi-v8 config-6.18.35-current-bcm2711' about 700 differences, no clue if this is reason for no detection. I made Debian Sid running, currently kernel 7.0.13+deb14-arm64, cam -l finds no CSI cameras, simple USBcam works fine. But is upstream_kernel=1 and there is no overlays for CSI cameras. Then copied 6.18.34+rpt-rpi-v8 kernel+initrd+dtb(o)+firmware from a running latest RPi Trixie (so 64-bit Debian based, not Raspbian re-compiled for armv6) and commented config.txt line upstream_kernel=1 and also set console to ttyS0, not ttyS1 otherwise hang at serial console. So with waveshareH NoIR (=ov5647 sensor) attached: 'cam -c 1 -C1 --file=raspicam.jpg' run as root works, however the picture is just black and white vertical lines. Then swap 6.18.34+rpt-rpi-v8 kernel+initrd+dtb(o) with the ones from 6.18.35-current-bcm2711: cam -l does not see a camera although ov5647 overlay is loaded If I use a faulty configuration, like upstream_kernel=1 the ov5647 overlay is loaded, but fails to initilize due to some i2c-csi-dsi mismatch. So it seems a typical vendor/downstream works, but upstream not. At least for upstream, the camera/sensor needs to be created and in addition, userspace might need changes. Might not only be in libcamera/rpicam, but there are potentially 10s or 100s or more changed debian packages, the most obvious 1 is NetworkManager, see RPi forum.

This is not NVME, but SATA. No surprise it does not work. It might be that the M.2 slot of the OPi5pro is such that with an overlay, you could map SATA signals to that slot and then it should work. Look in rockchip overlays folder for any .dtbo file with name like *rk3588*sata* But you should check HW circuit diagram maybe first, might also be that this is only for the normal OPi5 Maybe search a bit, I found Is old topic, but the principles are still the same.

ubuntu nor gnome is not relevant what matters is u-boot and kernel (and powersupply and type of nvme ssd ) u-boot logs can be seen via serial console cable

What is your plan with that camera? My latest try with raspbian (armv6) trixie based failed w.r.t. V4L2. So that is with start.elf, not start_x.elf. The latter works fine on bookworm based raspbian for camara v1. Camera v3 never worked with legacy firmware mode (start_x=1), so needs libcamera. For easy handling, the latest RPL variant of libcamera named rpicam should work, but then you'll be essentially back to RaspberryPiOS. If you have standard Debian Trixie based, all that modified libcamera is not there and more important, you will have other firmware files (bootcode.bin start.elf fixup.dat). Armbian takes the version from Ubuntu AFAIK, Debian is yet another version as is the latest from RaspberryPiOS (64-bit patched Debian or 32-bit patched and re-compiled Raspbian). The package name is raspi-frmware, check which versions there are with sudo apt list -a raspi-frmware and in addition, the 3 files themselves, I did timestamp or suffix them with sha256sum in the past on order to keep track of the various ones delivered for various OSses and images. I assume the Armbian kernel is compiled from same RPi kernel tree as RaspberryPiOS, so overlays for the v3 camera should be there and functionally the same. I currently have 1 camera v1 base RPI3B+ running, still bookworm, but I might boot it with Debian Trixie/Sid and see what mainline libcamera does. Probably then Armbian bcm2711 edge kernel, at least something that provides overlays as Debian kernels have almost none, at least not for camera sensors.

I see no clear error, only something with hdmi-audio-codec, but that is somehow expected AFAIK with mainline based rockchip64 kernel. I think Xfce is X11 and others default to wayland. You can try KDE in X11. 4K is not fully mainlined AFAIK, but you need to check yourself. You can try an edge kernel, is 7.1.x based, maybe it fixes things. I have seen many such issues (RK3588 SoC) in the past, but thing are remarkably fine with 'latest Linux' (KDE6 1080p60, don't have a 4K monitor/TV).

I see several time the following log line: rk-pcie fe180000.pcie: PCIe Linking... LTSSM is 0x2 I do not know what it means, but the fact that is is listed quite often is a hint I would say. There is also an earlier failure w.r.t. PCIE Usually is it power of some incompatibility of the NVME SSD in conjunction with the RK3588 based board. OrangePi5 Pro has questionable device-tree support, that is what I remember. It might be better nowadays, but I guess you will need to try an see if you can get any OS working/recognizing the SSD.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed. and/or lspci output it might also be a power issue or just that you specific nvme does not work with non-vndor kernel also kernel is already at 6.18.35 for current rockchip, maybe see if that fixes something w,r,t, yiour nvme

If 2 images don't work, I start thinking that the images are OK, but something goes wrong after extracting/decompressing, writing to SD-card, and reading at power by the bootROM/maskROM and U-Boot. I have various images downloaded and checked the past months, only for topics like this and I remember only 1 being wrong (there was no rootfs, only bootloader). I do not have a BPI-M2S, so cannot really test on hardware. And hardware might be the issue. Quite often nowadays it is fake or counterfeit SD-card. Those should work OK for writing the image and even verifying, but after that all sorts of strange errors and corruption can happen. It might be something with MBR or GPT failing, but this is rare. You simply need to check much more, check the SD-card in other Linux computer with fdisk etc. And connect serial console cable, so you can seen U-Boot and kernel logs and also interrupt U-Boot and do manual scan commands. Ultimately, you might need to build an image yourself and use Btrfs instead of Ext4. Might also make U-Boot understand Btrfs. Then any block-level corruption will be detected as Btrfs has checksums on all storage blocks. I use it for more than a decade and it really helps catching issues, even after years the same Btrfs root filesystem. And bad SD-cards are easily detected. Note that there is also btrfs-convert, allows converting existing images or SD-cards, but is a bit tricky as you need to do a few other things w.r.t. bootloader.

There is only this overlay for vendor kernel: /usr/lib/linux-image-6.1.115-vendor-rk35xx/rockchip/overlay/radxa-zero3-rpi-camera-v1.3.dtbo The mainline based kernel, what you use, there is none. So you would need to port it, from this radxa03 SBC or look at other devicetree overlay files, maybe from RadxaOS, maybe from RPiOS See 'man dtc' as a start, it might be a complete renaming of a lot of the .dtso file is needed, maybe it is just an enable line.

I have a few of those and when connected to RPi5 PSU and set to 12V, it can power my Rock5B with NVME SSD and some other peripherals as well.

The (standard) Armbian images for Rock5b use boot.scr, not efi/boot/bootaa64.efi from an extra FAT/ESP partition. So no surprise. If you use the EDK2 UEFIv1.1 in the SPI-flash, you should use a generic UEFI ARM64 image. 1 such is Armbian for UEFI ARM64, look at the download options. I don't know, but make sure it is one with latest mainline kernel 7.0.x. What I have used is a Debian Sid nocloud image just as a quick test (testing that image on a NanoPi-R6C, should also work on Rock5b, not the UEFI/bootloader behavior. See https://cloud.debian.org/images/cloud/sid/daily/latest/debian-sid-nocloud-arm64-daily.tar.xz As I mentoined earlier, I use fixed 12V for ROCK5B, else no success. For NanoPi-R6C it works with 5V 3A (27W RPI5 PSU).

You will have to make a choice which bootloader firmware you use. And then also which boot method and/or bootmanager. Armbian images for Rockchip SBC's are as simple as possible, so only 1 OS, no ad-hoc kernel selection. That means 1 partition for rootfs, no others. Different methods have different advantages and disadvantages. If you want other boot method and/or bootmanager, you will need to add a boot partition yourself, usually FAT formatted and type 0xEF00 (called ESP). The Armbian rockchip64 supports it all, no problem. Especially the Rock5B, which is more or less the blue-print of high-end ARM64 SBC. But all this own custom action also make it not Armbian anymore, but just a generic UEFI ARM64 computer. Where you could also boot from a CD-ROM .iso image and run a traditional Linux distro installer like used on x86 PC's.

Another option is to wipe the U-Boot from the SD-card and just use the SD-card only, no USB-adaptor needed. Then the only U-Boot in the system is the one in SPI-flash. I have done that once on an SBC with no SPI-flash but eMMC where the bootloader is stored. And that also involves GPT partitions and so on, not independent like SPI-flash. But as Werner says, backup is easy. For old 32-bit Armbians, I made some function in my unattended backup scripting to do that, so that after a year(s) or so, I can restore to get exactly the same system (when SD-card gets bad/broken for example).

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

OK, good that you see the higher voltage selected. I have also seen it, but was on a NanoPi-R6C, although it did not work with RPi5 27W PSU, but OK with HP tablet 45W PSU. The rest is then a matter of kernel and DTB. My ROCK5B runs fine with rolling release/latest Linux kernels (Debian Sid, Opensuse Tumbleweed), currently 7.0.10 version. Don't know about NixOS (on aarch64), but maybe first get some basic stability with standard Armbian Trixie image (mainline based). It gets tricky when you mix vendor and mainline/distro based. Also vendor (6.1.115) can show various issues if you try/use various external HW. Like an mt9721u USB stick of mine causes a failure in paging on ROCK3A, so need reboot, then it works, but don't know for how long (weeks or months)

this means bootloader in SPI-flash is used if armbian is booted from sd-card slot, the armbian bootloader from sd-card it used, at least that is what i think so you can wipe spi-flash or wriie a working bootloader in there

I was curious and looked into your script, I see parted uses sizes like 32MiB instead of sector numbers I tend to do when using gdisk or fdisk It is only the function write_uboot_platform_ufs() in the image that deals with 512/4k and then it is no issue for Btrfs as this is not related to CPU page-size issues I hinted earlier. So also older kernel is no issue and also RK3576 cannot do e.g. 16k page-size.

this I cannot remember I have experienced on my ROCK5B, it was indeed boot-loop when power 'was not good enough'; with fixed 12V power everything worked, even 3.5mm audio I remember. Now I have EDK2 UEFIv1.1 for the ROCK5B in the SPI-flash and it is like a PC, so even stores boot entries for several OSses (what is on the ESP). My ROCK3A showed similar behavior as your ROCK5B, that went away when fixed 12V power and Armbian legacy U-Boot and 6.1.115 (I use SATA overlay) At sector 64 the binary u-boot.bin is written, the terminology I am not sure of. You can look up all addresses the ROM uses at rock-chip.com or so. You might want to build/compile an as pure as possible and as latest as possible mainline U-Boot for ROCK5B, I saw kernel 6.17 or later should have fusb302 support, but it might be too late in the power-on process. EDK2 UEFIv1.1 has no fusb302 support.

root@nanopi-m5:~# grep BTRFS /usr/lib/u-boot/nanopi-m5-rk3576_defconfig # CONFIG_CMD_BTRFS is not set # CONFIG_FS_BTRFS is not set So no direct Btrfs rootfs support. It is image Armbian_26.5.1_Nanopi-m5_trixie_current_6.18.33_minimal.img run as container quick test. # gdisk -l Armbian_26.5.1_Nanopi-m5_trixie_current_6.18.33_minimal.img GPT fdisk (gdisk) version 1.0.10 Partition table scan: MBR: protective BSD: not present APM: not present GPT: present Found valid GPT with protective MBR; using GPT. Disk armbian.img: 3252224 sectors, 1.6 GiB Sector size (logical): 512 bytes Disk identifier (GUID): 1F37D403-5DE7-4F81-AB22-D9825AE1EFEB Partition table holds up to 128 entries Main partition table begins at sector 2 and ends at sector 33 First usable sector is 2048, last usable sector is 3252190 Partitions will be aligned on 2048-sector boundaries Total free space is 32735 sectors (16.0 MiB) Number Start (sector) End (sector) Size Code Name 1 32768 3250175 1.5 GiB 8305 rootfs There is no 4K sector 'awareness', that is the whole reason I ran this testing; If that is an issue with the M5, I don't own and don't know, but I have encountered quite some issues in Linux in general w.r.t. that, so I would for sure scan armbian-install script to see what is done. Risk with 6.1.115 kernel is that is messes up 512/4k things when Btrfs as kernel 6.7 or later is needed to handle it transparently. Check all yourself, as is long time ago I checked it and I use mostly latest Linux, so kernel > 6.18 currently.

My ROCK5B was ordered as a 'blue one' on Aliexpress a year ago; I got a 'green one' and as with included case the price was > 150 euro, it got stuck at customs for quite some time. It was with blank/empty SPI flash and endless boot-loop. That was already known by me, so I had fixed 12V soldered to a male USB-C connector. Same story for ROCK3A, although that one booted most of the time but then while running al sorts of strange errors and or crashes. So I think you have to assume USB-C PD negotiation is not working with the Armbian images you tested. Only the U-Boot starting at sector 64 does matter, rest (Linux) is don't care. If a stable U-Boot or UEFIv1.1 form SPI-flash or SD-card, you have already a very extensive commandline interface or text menu's in the EDK2. But lock up might simply happen because the PSU does not do 65W, instead max 15 W (only up to 3A) and the 5V might drop way too low, just very short dip that is not measurable without good oscilloscope or so. The Radxa image might have a bootloader variant that does do USB-C PD, although I haven't seen proof anywhere that it correctly handles and does operate the FUSB302, but that might simply be because my ROCK3A and ROCK5B came out of the box with empty SPI and for ROCK5B I have ignored Radxa images anyway after the big troubles with ROCK3A, so do not really know what happens with those. So I have no other advice then use fixed higher voltage, formally it is >= 9V according to Radxa wiki/docs AFAIR, but I remember the powertree design actually better than those quick facts and my conclusion was : forget about 5V, use 12V and it was easy decision for me as I use 12V UPS and 3.5inch HDD that also needs 12V anyway.

Here your debugging activity will need to start. There is an awful lot of things unknown, to others on this forum but more important, also to yourself. It could already be that your server (Armbian) has nothing to do with it, but that it is the info in your router (even caching stuff) that has refreshed, simply because you probably restarted, so something was not 'reset proof'. I have seen many of such things myself in my house/home networking and in conjunction with various ISP's (also mobile4G). Which made me use my own (open-source) router instance for example, so I can at least check all what is needed in such case as you have. But it might be simple, you can use wget (do 'man wget' first to see all options) to mimic browser behavior and that should already say something. If docker etc is involved, make sure you understand all (virtual) networking, it can get very complex. I haven't seen potentially disturbing things from Armbian 26.2.1, but I removed/blocked also several things, like no netplan.io, that at least works on Debian Trixie based installs. There have been lots of security related updates in Debian recently, so make sure you log and see changes to packages (edit listchanges.conf)

This topic is 2 years old and HA formally does not support supervised anymore. And doing 2 such modifications and then hoping all will be fine is false hope IMO. If you don't have a serial console cable to watch kernel en journal log etc to see what your system is doing, maybe it is time now to get one. I have an old supervised inatsllation (not use for many months, but it is plain Debian and a VM so I have free/easy CLI console.