eselarm

I also saw that both apt and beta repo's do not contain recent rockchip64 kernels at the moment. There is only a recent generic arm64 one. So it is not only my rock3a, also my nanopi-r6c would be affected, but I use own/other/vendor kernels as well, so specific 6.18.8 is not an issue for me. I use extlinux or grub to select a certain kernel (6.19 flavor on nanopi-r6c for example). For my rock3a, I need vendor kernel, but if you use mainline based, you could use standard Debian backports kernel: https://packages.debian.org/trixie-backports/linux-image-arm64 You need to get the .dtb manually and I just assume most features are supported when the rock3a has mainline U-Boot in SPI. You need of course add that to sources.list and specifically select it. You could also use Armbian build framwork to build a 6.18.x yourself, you will also get a header files package then. For Debian14 I see there is: /usr/lib/linux-image-6.18.15+deb14-arm64/rockchip/rk3568-rock-3a.dtb But as indicated, this is total DIY, I have not tested it. I only know that on rock5b I could run standard distro since quite some months, but use 6.1.115 vendor one as I need all RK3588 HW to work.

Maybe see https://wiki.postmarketos.org/wiki/Medion_Chromebook_S2015_(google-veyron-mighty) It is RK3288, so an Armbian Rockchip kernel might do something, but I have no clue about DeviceTree and/or bootloader. Alpine is quite different from Armbian/Debian but maybe with that bootloader+kernel+DTB and Armbian rootfs it might do something, but make sure you have seril debug cable. In general might need to find solder points on motherboard/PCB or some specific resistor value on OTG ID pin.

No need to thank me in this case. You don't even read or understand or act upon it from the start; I mentioned essentially twice earlier what the problem is and now that I again opened that ssh log and you don't seem to understand how to handle ssh links. Is trivial for decades, you need to read docs or maybe ask an AI-bot, else forget about Linux and stay with Windows only.

AFAIR Windows uses other files/objects/regkeys when ssh admin/root I just remember it from other place on internet, test also with Linux only.

you cannot login as root via ssh using password, it is disabled by default for years already you need a normal user first or prepare the image/sd-card to use ssh keys/ids

in the root of the rootfs do: find . -name platform_install.sh find . -name u-boot-sunxi-with-spl.bin essentially construct correct dd arguments somethings else might be wrong though, so make sure you have a serial console/debug able with loglevel=7

The paste armbian URL displays nothing (anymore?) so without any (new) info from you, no-one can help you. AFAIR, 4K via HDMI connector is only recently available (on RK3588, not sure about RK3399), so make sure you can manage various combinations of U-Boot, kernel, rootfs. So sort of act like a developer, als make sure you have a serial console (debug) cable, else you cannot get any step further. Use a 26.2 based U-Boot and 6.19 rockchip64 kernel I would say, then see what happens.

If I understand you correctly: root via ssh is not allowed by default I usually setup (new) SBC's in a different way, but last time testing 2 of my boards with 26.2 minimal/IoT fresh image was via serial console, have not used ssh and certainly not putty. If no (serial) console, you might also have sme networking firewall issues somewhere in Windows or so, although would be vary rare. Have you setup a normal user first via (serial) console first?

You should also consider the bootloader (type and version), in principle you do not need the dtb- package as the dtb files are also in the kernel package (enough when doing own extlinux). U-Boot philosophy is to provide just enough so that the kernel/initrd/DTB can load and started. Audio is not part of that I think. LE certainly used other bootloader and as you already showed has more non-upstreamed patches. See my experience:

then this topic is not applicable

What hardware do you have? What exactly is in the M.2 slot?

What is in armbianEnv.txt then? Anyway you need to load and edit it such that you make sure loglevel=7 Then there will be more text after Starting kernel ... You also seem to have a power and/or reliability problem w.r.t. cables as characters are missing in your debug log text.

High chance this uses some proprietary hardware for 3.5mm audio jack. It has been like that for decades and you probably need to find some firmware blob somewhere maybe. I have also a similar situation, most part s of the computer work fine with Debian Trixie etc, but it took ages to get sound working and still buggy, endless beep or crash occasionally. If you are lucky is it maybe only a mute setting or so, use aumix etc to look what is going on. Not something Armbian specific I guess, but up to you to figure out. Then also mention various versions, what BIOS/UEFI version the computer is loaded with, what Armbian kernel and also specific image release (if it is an unmodified image writer based installation).

You should pipe the output from a serial console cable to another computer where you store it. Make sure kernel cmdline loglevel=7 AFAIR the OPI5+ can only use 5V as input supply power. Your 100W PSU might be a standard spec one so it does only deliver 3A at 5V. This might be a perfect 5.000V, but an extra cable in between will drop that a bit and the risk is then that short higher power drap will either make the 5V goo too low and/or the PSU will cut the power because more than 3A drawn during a short peak. You will need to look at powering first. Usually 5V only SBC's can be powered via other input then the USB-C input. You need to read the instruction for your OPI5+, and also OPi5, those might be different. OPI5+ and also OPi5 should transcode at more or less the same speed, large amount of memory does not really matter as it is just HW processing blocks doing the work in a rather limited memory space. You should do a manual CLI jellyfin-ffmpeg based transcode, see /var/log/jellyfin how commandline arguments for that specific video look like (and simplify it, output to 1 file instead of chunks m3u8). And or search this forum, I at least have posted examples for check/test earlier. You might also try to reproduce it with a publiclicy know video, look for big buck bunny test vids or so.

This is putting some sort of warning flag for myself. 'pretty sure', 'chatGPT', a Rockchip board v.s. Allwinner board.

OK, so the URL I posted is not correct. If those devices are there, your only option is to use dd with correct offsets on SPI/MTD or eMMC ( or SD-card) to write a U-Boot binary. An lsblk should show those devices, else maybe the armbian-install tool is likely correct with its error message.

see: https://radxa.com/products/network-computer/e25#techspec Only SD-card for this device, hence boot order is something fixed, just hardware. On software level it depends on how U-Boot it configured and compiled and on higher level, what partitions are found, can also be USB-stick, and what is on those partitions. Can be Armbian standard boot.scr or own extlinux or even EFI if you want. So minimum is SD-card with U-Boot on it, else nothing will happen unless maskROM is entered, see Radxa docs.

armbian-config submenu STO001

Armbian_26.2.1_Rock-3a_trixie_current_6.18.8_minimal.img.xz (ROCK3A) - system has NVME inserted and SATA M.2 E-key adaptor where HDD is connected to - SPI has Armbian legacy U-Boot, but that is skipped as SD-card with new image is inserted - further only power, ethernet and serial console cable connected: 1st boot and user creation all fine - network up, WAN IP shown - NVME is available (but OS is running from SD-card for the test) - SATA is not available as not supported mainline based kernel (and needs adding overlay manually when vendor kernel) - reboot does not reboot (but 'echo 1 > /proc/sys/kernel/sysrq ; echo b > /proc/sysrq-trigger' works) - also poweroff is only shutdown, no powerdown (and HDD keeps also spinning)

Armbian_26.2.1_Bananapi_trixie_current_6.12.68_minimal.img.xz (Bananapi M1) - only power, ethernet and serial console cable connected: 1st boot and user creation all fine - network up, WAN IP shown - then connecting a SATA SSD ('hotplug'), pops up in dmesg, so recognized OK

I would first check the link, what is on the other side, etc. Also do a flood ping with large enough packages. Or UDP flood, not sure how to do that. Iperf3 might be easier. I have no clue about Radxa OS, never really used it. Maybe also do test boot with mainline based kernel, 6.19 edge I think. And what U-Boot version is used. I use Tianocore EDK2 UEFI v1.1, that might also have effect.

already in the first dmesg part I see: [54475.779558] r8169 0004:41:00.0 eth0: Link is Down [54479.115749] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [54479.115748] r8169 0004:41:00.0 eth0: Link is Up - 2.5Gbps/Full - flow control off [55390.928391] br-ce724241dce3: port 1(veth1664549) entered disabled state [55390.928949] veth6932af4: renamed from eth0 [55391.020157] br-ce724241dce3: port 1(veth1664549) entered disabled state [55391.021811] device veth1664549 left promiscuous mode [55391.021831] br-ce724241dce3: port 1(veth1664549) entered disabled state [55391.493933] br-ce724241dce3: port 1(veth1a65439) entered blocking state [55391.493954] br-ce724241dce3: port 1(veth1a65439) entered disabled state [55391.494085] device veth1a65439 entered promiscuous mode [55391.500502] br-ce724241dce3: port 1(veth1a65439) entered blocking state [55391.500519] br-ce724241dce3: port 1(veth1a65439) entered forwarding state [55391.539757] eth0: renamed from vethb9b9ca0 [55391.561925] IPv6: ADDRCONF(NETDEV_CHANGE): veth1a65439: link becomes ready Which means to me that you use containers/docker or so and something on that networking level goes wrong. I think it had nothing specifically to do with Armbian nor ROCK5B. You should figure out what is running on your computer and what is done to networking in general. I do not use containers like seems to be done here, so cannot really help here. I have no clue about your networking setup and plans. I use various bridges and VLANs on my ROCK5B (Armbian Trixie), but all strict manually done by myself, only own files in /etc/NetworkManager/system-connections/

A month ago when doing test boots and power measurements, see I discovered that when using the RPL 27W 'Pi5' PSU, the NanoPi-R6C with the indicated bootloader(s) and kernel(s) sticks to 5V. But when using a 45W USB-C PD PSU from a HP laptop or 60W USB-C PD PSU white-label, switch is made I saw on a USB-C PD power measurement device that was also in the chain. More detailed USB-C PD protocol analysis seems to be needed in order to figure out what happens. One could guess 3A is requested at highest possible voltage as with the 45W PSU, I saw 15V. 9V or 12V would also be OK, but the PD handler cannot be 100% sure I think, depends also what is inserted in USB type-A ports on device etc.

That is the correct one. Then I do not know anymore why yours does not work with recent Armbian images/installation.

Which microUSB connector of the bananapi do you use for powering the bananapi itsef?