Werner

Stop providing false information, I disproved your theory earlier, please stop.
 
On Armbian, the way to do it via ssh IS TO LOGIN AS ROOT on first run, SSH has logging in as root ENABLED BY DEFAULT on Armbian.
This works, and is the way I have ALWAYS done it on Armbian, for years.
 
Here is a link to documentation: https://docs.armbian.com/User-Guide_Getting-Started/#first-login
I quote: "The first boot will log you in automatically if you have connected a display via HDMI or if you are connected to the serial console. For SSH, you need to login as root and use the password 1234."
 
If OP refuses to listen to recommendation and keep using putty, OP will have to take this up with the devs of putty, there is nobody here that can/will help with that.

Good news: this is merged in Armbian main now, many thanks to  @c0rnelius and @Igor for reviewing this. So no more need to grab my fork, just clone Armbian/build:main. I was able to build and quick-test orangepirv2/edge-kernel and this looks fine including Wifi. 
 
There are of course unsolved quirks currently. With edge-kernel, Wayland does not work, we need to use Xorg. And with the current bcmdhd Wifi driver, AP mode is not possible. This is caused by outdated file in armbian-firmware for bcmdhd and may be the same on OrangePi5. There is a mechanism to load a different fw_bcm43456c5_ag.bin (the one downloadable from github/xunlong seems to work).
 
LG // Sven-Ola 

Will check it when i back to PC, will be away from pc for around a week

Boards that've tested:
 
NanoPC T6 LTS:
Kernel: Vendor (6.1) - Current (6.18) Variant: Desktop - Gnome What was tested:
GPU works as expected WI-FI Card works as expected NVME, eMMC, SPI and SD Card works as expected Ethernets: 2x 2.5GbE works as expected HDMI both works as expected AUDIO: HDMI & via jack works as expected HDMI-IN video works as expected NanoPi M5:
Kernel: Vendor (6.1) Variant: Desktop - Gnome What was tested: Image not boot, i have to investigate more, The previous image works without any problems.
 
I will check soon and maybe migrate it to mainline uboot
 
@Igor Can you do a double check if your board have the same issue?
 
 
What was tested with the new build:
GPU works as expected WI-FI Card works as expected NVME, SPI and SD Card works as expected UFS: I have to working on it, maybe with new mainline patches that will add the support on it Ethernets: 2x 1GbE works as expected HDMI both works as expected AUDIO: HDMI & via jack works as expected  
NanoPi R76S:
Kernel: Vendor (6.1) Variant: Desktop - Gnome What was tested:
GPU works as expected WI-FI Card works as expected eMMC and SD Card works as expected Ethernets: 2x 2.5GbE works as expected HDMI both works as expected AUDIO: HDMI works as expected  

 

no clue. needs testing. perhaps it just works. kernel sources are the same as rpi os.

You can switch to beta to get faster updates, though they're untested autobuilds, so if something breaks, you have to unbrick yourself.
 

We don't have intention to support this board without funding. However anyone from the community can step up and add support for it.

The boot partition presence doesn't depend directly on the Armbian version—it's determined by the board configuration. Some configs enable an extra boot partition, especially for boards using older U-Boot versions that can't boot directly from ext4. As a result, even for the same board and Armbian version, different branches (e.g., legacy, vendor, current, edge) may behave differently. Vendor branch might use an old BSP U-Boot requiring the extra partition while mainline branch uses newer U-Boot that boots straight from ext4.

You can switch to beta to get faster updates, though they're untested autobuilds, so if something breaks, you have to unbrick yourself.
 

Actually not really strange but a measure for spam prevention.

Alright, well, such things can happen when attempting to fix a bug and not having hw to test on hand
I'll leave it to Cornelius to send a fix since he can directly verify if it works.

If I have the time I'll do a PR. I also ended up modifying and compiling a new hciattach_opi binary, to get bluetooth to come up.
 

Small guide for fixing Ethernet on the latest Armbian.
1. Make sure you have the correct device: cat /proc/device-tree/model → OrangePi 3 LTS
2. Decompile the dtb to dts: dtc -I dtb -O dts /boot/dtb/allwinner/sun50i-h6-orangepi-3-lts.dtb -o ./sun50i-h6-orangepi-3-lts.dts
3. Check the correct pins (yours may differ): grep -i reset-gpio sun50i-h6-orangepi-3-lts.dts | head -n 1 → reset-gpios = <0x1e 0x03 0x0e 0x01>;
4. Create the file sun50i-h6-ethernet.dts. Use the provided template and substitute your pin values.
My file for example:
/dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h6"; fragment@0 { target = <&emac>; __overlay__ { snps,reset-gpio = <0x1e 0x03 0x0e 0x01>; snps,reset-delays-us = <0 10000 1000000>; snps,reset-active-low; mdio { ethernet-phy@1 { reset-gpios; reset-assert-us; reset-deassert-us; }; }; }; }; }; 5. Add your overlay: armbian-add-overlay sun50i-h6-ethernet.dts
6. Reboot and enjoy working Ethernet: reboot

Duplicate
 
 

mirrors/repo are degraded at the moment. We're aware and working on it.

mirrors/repo are degraded at the moment. We're aware and working on it.

mirrors/repo are degraded at the moment. We're aware and working on it.

Looks like stuff got lost due to force-push. Check this how it looked before: https://github.com/rvdr/build/activity?ref=spi-nvme-patches

standard baud rate for rockchip socs is 1500000. And for the other your cp2102 is no good for this high speed since it cannot handle it. And instead of failing it will output garbage. get ft232r, cp2104 or pl2303 based adapter.

https://forum.armbian.com/topic/16976-status-of-armbian-on-tv-boxes-please-read-first/#comment-199170

Good morning

@Werner  Thanks for the patch. I'll probably wait for the new kernel and test it. The project is long-term. For the first answer "to address myself" :). I think I understand what you're saying. Thanks :).
If I find a solution to this, I'll share it with the community, as I've been doing so far  
@usual user Thanks for the answer.
Today is the 31st and I'm thinking of not working on servers, happy new year and may the next one be fruitful for all of us.

Best regards,
A.H.

Are you sure you don't mean BSP which stands for Board Support Package??

Didn't warn ffmpeg from a guts feel years ago that they will issue a takedown if no action is taken? So I'm not surprised. Kind of.

@JuanEsf sunxi-edge is now on 6.18. You can add your patches for t527 there.