Igor

armbian-firmware = minimal blobs that are needed that on-board wireless function + few popular ones = https://github.com/armbian/firmware 
- full = + everything else https://kernel.googlesource.com/pub/scm/linux/kernel/git/firmware/linux-firmware.git
 
You can install one of those, while source package, headers and armbian-config are optional. Also armbian-firmware if your will not be running any wireless.

Kernel = image + dtb package. Those are the core.

Nothing strange. All software has bugs  and I don't fully exclude there is a problem with Armbian, just for this, I would say its probably on their side ... things are complex and is difficult to be sure without a research.

This means that OMV, which anyway completely changes OS, somehow breaks networking.
 
OMV was working well for many years, Armbian was even official partner ... As we didn't change anything in this regard, I would assume they changed something so try also to find this answer on their forums. 

Those are developers preview builds, where you can check what works and at some point it will be good enough for some uses cases. In a couple of years, it will be functional on the level of kernel 5.10.y. 
 
Download is possible from CI pipeline: https://github.com/armbian/build/releases
 

 
Boot log:
 
This board is looking for maintainer(s) and (this) forum moderator (contact @Werner).

I tryed fresh build today and there was no errors, so it looks that build system is fixed.

Interview with @rpardini.
 

Then apologise. People usually wants to change boot logo on commercial deployments. 
 
 
But we don't need that, as we have bugs on the list for several years already.

@vitor  Have you paid for support?  Armbian is composed of volunteers who donate their time.  If no volunteer desires to work on any particular board/feature/bug, no one is getting paid to be told to add such board/feature/bug.  This is open source so anyone can go in and make changes/fixes/improvements and then hopefully submit them back for others to benefit from.  First and foremost Armbian provides a place (forums, frameworks, source code) for anyone to join the volunteer community and help support the wide variety of boards that are out there.

@madade  Why do you ask for help again when you haven't provided the information that Igor asked of you.
He asked you for four things:
You only provided an answer to one request.
 
Which hardware revision (picture please)?
Where does booting end? (capture of the console output of the boot)
Try another sd card.  (Just because a card works in some circumstances, doesn't mean it will work for this purpose, sbc's are finicky when it comes to sd cards at times)

added:
console=both now I have a shell!
 
Thanks!

With working PCI
https://github.com/armbian/os/releases (look for Rock5 "midstream")
 

With working PCI
https://github.com/armbian/os/releases (look for Rock5 "midstream")
 

With working PCI
https://github.com/armbian/os/releases (look for Rock5 "midstream")
 

It has been silent for a year  Anyone has thoughts or tried to merge Asahi Linux into Armbian?
 
Apple mini could serve as a nice small Armbian build machine or just general purpose workstation. Well, compilation runs on MacOS, but running native Armbian Linux would be a lot cooler. The task of bringing Asahi family into Armbian https://docs.armbian.com/Developer-Guide_Adding-Board-Family/ probably should not be very difficult anymore https://github.com/AsahiLinux/docs ?
 
Anyone with a strong enough wish & ability?

I can assure you ZFS from Arbmian repo works perfectly fine. We are using it on two production grade servers.
 
odroidhc4:~:# modinfo zfs filename: /lib/modules/6.0.12-meson64/updates/dkms/zfs.ko.xz version: 2.1.6-0york1~22.04  

https://www.armbian.com/newsflash/armbian-23-02/
 
 
Changelog: https://docs.armbian.com/Release_Changelog/

Armbian_23.02.1_Odroidc2_jammy_current_6.1.14.img.xz (from imola.armbian.com/dl/odroidc2/ )
boots from SD, but still no reboot

I tested the 23.02.1 aml-s9xx-box builds against all the amlogic TV boxes I have and they worked as expected.

Change bionic to jammy in /etc/apt/sources.list.d/armbian.list and it should probably be fine.

@Contributor/MaintainerTomorrow (Saturday 18th, we will start moving armbian-next into main). @rpardini and me will be around whole (our) day as there is some work and troubles are expected. We need to adjust and test CI and in case someone has no other plans for Saturday, welcome for assistance. Thanks.

probably a post bragging of my christmas gifts, but mostly just documentation because it really confused and stumbled me from the get go

so, my setup was powering tinkerboard (the first revision, without the new fangled eMMCs) via GPIO because it confused the hell out of me how to power this beast. this was powered through the XL4015 buck converter 12.1/12.2 V on input, with ammeter and voltmeter included on the board. (the board was current limited to 5A, because why not? the rk808 is 6A tops)
ok from the get go the board powers (not load tested, just power through and run kodi-gbm UI) from 3.4V to 6.2V. undervolting or overvolting it doesnt shuts itself down (no red light), then bringing back to operating voltages boots the board up

also take not that operating voltages for RK808 was 2.7V to 5.5V. the missing 0.7V was probably the diode drop people are talking about. maybe? without a multimeter (only using the power supply's voltmeter-ammeter) i can't check it that much. but i'm fine that it has wide range of operating voltages. on all observed voltages, 3A seems to be the max current. it needs to be sustained though. also full load without peripherals (and HDMI, HDMI seems to be active than passive) is observed 2.3-2.5A. booting up the board needs about 0.7A to keep on going

this would probably contradict as well the "increase voltage to 5.25 or smthing" given that no matter how many volts you put into it, it would only use 3A. weirdly (since this contradicts the block schematics from tinkerboard), #1 and #2 are observed in both USB and GPIO with no difference (significant or not) under load.

it's weird since
3.1. if USB lines were protected, there should be a diode drop *only* on USB lines. but this was seen on GPIO as well.
3.2. some claims microUSB only has max 2.5A but this is not seen in this case: the setup sustained 2.7A going 2.9A.

also, powering both GPIO and USB with the same power block doesnt seem to affect stability at all (still hard limits at 3A.)
so with that, there are few suggestions for powering the board as well (and minor observations. opinionated parts ahead)
people talking about overvolting or undervolting the power rails doesnt really help at all at slightest. it'll still top at 3A. what overvolting could help were powering via USB peripherals, but i wouldnt recommend it plugging straight given the fact that 2.5A on full load? you only have 0.5A to spare on heavy load.

get a usb y splitter (tape over the USB power lines to the board. idk why but i have usb resets whenever i dont have them. then again plugging a hard drive in there shouldnt be happening in the first place) the raspberry pi 3B+ adaptor (5.25V, 2.5A)? good enough actually! as long as it can deliver 5V across the device, AND as long as you dont have power heavy devices on it. it doesnt matter that much so long as your USB cable can handle phone-charger level of amps. rk3288 was designed with mobile phones in mind. it'll always power at 3.7V. i always having issues when im using a cable that can only do 0.5A across it. no can do.

probably for me, but this is why you dont need to be hung with the minor details. starting from this, im wracking my brain around if tinkerboard was sensitive to power drops (like 5.1v or 5.2v would show stability improvements) but nope! just chuck it right in, it'll be fine. just check your connections and stuff. powering through the GPIO pins is recommended of course, but it's an overkill. probably the reason for it was most USB chargers only go 2A max and that would underpower the tinkerboard, doing  boot loops instead of starting correctly. then again YMMV: my place has 3A or 5A chargers everywhere. and with the introduction and interests of fast chargers, you'll find chargers (and cables) that can deliver more than you expect. on sidenote on powering through the GPIO: PLEASE GET YOUR GAUGES RIGHT. i powered it via the ATX FDD (remember those?) connector, with 12V pin removed. it turns out for some reason its max current is 1A and its just thin flimsy as hell. get a thicker wire.

it didnt drop the current (thankfully) but the wire became so warm to touch, it's weird. i wouldnt wanna run this on full load. at least i didnt get burned wires. cooling fan helps a lot also you cant bypass that 3A limit. that's 3A total, both GPIO and USB inputs. even powering both USB and GPIO (like that one person suggested) doesnt really do anything. you wouldnt get that much power in, but at least you can protect your wires?

which is weird since block schematics shows GPIO and USB has different lines? so it should have different protections and stuff. a multimeter can help see if those inputs are shorted (GPIO vs microUSB vs peripherals) but i dont have one at the moment

i would also like to measure the voltage across the peripherals if any load situations will lead to undervolting the outputs, but i dont have a USB tester at the moment. RK808 seems to be programmable but interfacing with it is outside of my skill set. any help would do  
i hope this post helps everyone well. no one uses these boards anymore except for niche use cases but i still enjoy it. i hope in the future i can get myself a huge NAS server with an RK3588S on it. kinda lonely to be honest

Tested OrangePi 4 LTS:
Armbian_23.02.1_Orangepi4-lts_jammy_current_5.15.93_xfce_desktop.img.xz Armbian_23.02.1_Orangepi4-lts_bullseye_current_5.15.93_minimal.img.xz Bluetooth adapter is detected, but this time I was unable to pair with the usual audio speaker
The rest seems to work pretty well

Although I have not yet tested the Moonlight-QT build on the Orange Pi 5, I plan to do so tonight.  I will be contacting amazingfate regarding the bounty. I consider this to be the best $1000 I have ever spent, and I hope it marks the beginning of a long-term relationship between Maximumsettings and the Orange Pi 5 Armbian community. The Pi 5 will provide us with  one the most affordable and superior streaming device available in the market.

Just so you know, our organization has many ideas, but we lack the internal resources to implement them. I am optimistic that we can create a situation where everyone benefits, a win-win scenario.  I am hopeful  that the approach of offering bounties for adding new features and fixing bugs will be successful within the Armbian community.

Tested:
Armbian_23.02.1_Bananapim64_jammy_current_5.15.93_minimal.img
The first start, boot, reboot is normal.
Found not included in the fix for "armbianmonitor" for one cluster.
Corrections here

Orangepi-r1 tested success:
Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93.img.xz
Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93_minimal.img.xz
Armbian_23.02.1_Orangepi-r1_jammy_current_5.15.93.img.xz
 
All images tested and working as expected.
Iperf performance is as expected in both directions on both ethernet ports simultaneously.
Wifi works.
2 images listed on RC testing form (minimal build left off).