Igor

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

Orangepizeroplus tested success:
Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93.img.xz
Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93_minimal.img.xz
Armbian_23.02.1_Orangepizeroplus_jammy_current_5.15.93.img.xz
 
All images tested and working as expected.
Iperf performance is as expected in both directions on ethernet and wifi ports simultaneously.
2 images listed on RC testing form (minimal build left off).

Tested:
- Armbian_23.02.1_Orangepi5_jammy_legacy_5.10.110_minimal.img
- Armbian_23.02.1_Orangepi5_jammy_legacy_5.10.110_cinnamon_desktop.img
 
USB-A ports, HDMI, ethernet port and sound seem working properly.

Orangepi-r1plus-lts tested success:
Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93.img.xz
Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93_minimal.img.xz
Armbian_23.02.1_Orangepi-r1plus-lts_jammy_current_5.15.93.img.xz

All images tested and working as expected. 
Iperf performance is as expected in both directions on both ports simultaneously.
2 images listed on RC testing form (minimal build left off).

1. Checking the progress of Armbian-next
 
Video:
https://us06web.zoom.us/rec/share/ly7gbgZBTY1M4eiumUk6Gp357Jl0RV0h7usdUEGN5WcNKXNIwsOoNHbtoLbBeEje.KCku4wdAigfEI7pB
 
Armbian Next Jira:
https://armbian.atlassian.net/browse/AR-1451
 
@Contributor/Maintainer

Just additional measure to divide kernel and user land packages update. If you want to update kernel packages go to armbian-config -> system -> unfreeze (freeze back after) ... do update & upgrade.

We are trying to put together an automated test system for various (WiFi) USB devices. Hardware is in place, but software part is in early design phase:
 
 

We are trying to put together an automated test system for various (WiFi) USB devices. Hardware is in place, but software part is in early design phase:
 
 

I have been building this project for a long time.
And at the moment, I don't see an alternative for the ARM architecture for real-time core operation with short response times.
@Igor The Xenomai4 project is already working well for sunxi today.
 
 
 
lsdiff patch-6.2-rc3-rt1.patch These are some basic changes. I don't see the necessary changes specific to rockchip, meson or sunxi files here.
In order for this patch to work, you need to add a lot of additional changes yourself.
 
And this is for working only in user space.
In any case, you will have to reassemble the entire chain for industrial production. kernel -> lib & modules -> linuxcnc

I am sure there will be! We even played with idea to present armbian-next build framework, but I guess next year or at another conference. I'll have to skip it this year. Somehow too busy.

After two years of taking place exclusively online, FOSDEM 2023 is back in Brussels, Belgium with thousands expected to attend the 2023 version of the “Free and Open Source Developers’ European Meeting” both onsite and online. FOSDEM 2023 will take place on February 4-5 with 776 speakers, 762 events, and 63 tracks. As usual, I’ve made my own little virtual schedule below mostly with sessions from the Embedded, Mobile and Automotive devroom, but also other devrooms including “Open Media”, “FOSS Educational Programming Languages devroom”, “RISC-V”, and others. FOSDEM Day 1 – Saturday February 4, 2023 10:30 – 10:55 – GStreamer State of the Union 2023 by Olivier Crête GStreamer is a popular multimedia framework making it possible to create a large variety of applications dealing with audio and video. Since the last FOSDEM, it has received a lot of new features: its RTP & WebRTC stack has greatly improved, Rust [...]
The post FOSDEM 2023 schedule – Open-source Embedded, Mobile, IoT, Arm, RISC-V, etc… projects appeared first on CNX Software - Embedded Systems News.
View the full article

1. Checking the progress of Armbian-next
 
Video:
https://us06web.zoom.us/rec/share/vq04OFykxpw7nGp8wJxKME7w8uNf1kMrwHRLldQLTCLJCT-zsZY8KP76aCknhBfN.JyvzRmfR9qulexM2
 
Slides:
https://github.com/rpardini/armbian-build/blob/extensions/README.armbian-next.slides.md#update-feb-1st-armbian-next---general-changes

Armbian Next Jira:
https://armbian.atlassian.net/browse/AR-1451
 
2. Moving development related topics to GitHub

Summed here:
https://armbian.atlassian.net/browse/AR-1529
 
3. Questions around upcoming release
 
Today is the code freeze. Actions:
 
notify maintainers and prepare them to be ready on testings in two weeks from now notify developers: their code gets into release log only if exists in Jira. Minimum requirement is Jira issue or Jira story with Name, short description and field "Fix versions" set to 23.02 that code freeze is a milestone when we change our focus into code stabilisation and fixing bugs. It is not expected to drop existing work in progress at once but gradually close it. in the code freeze period, there is additional restriction on code merge: pull requests approval from 1 person to 2 persons  
@Contributor/Maintainer

Many of us are using Armbian not just on ARM single board computers but also on servers (bare metal & virtual). We use our builds since we trust it more then Debian, Ubuntu, not to mention other distributions that are recklessly updating and one ends up as an OS tester and not OS user. Personally I use Armbian Jammy on Ryzen 9 workstation with great success. My primary use case is development / productivity. For the road I used to have 13" Dell notebook which recently suddenly died. It was out of warranty so I had to get something new. After some testings of various devices I settled with 12th Gen Intel i5-1240P powered Lenovo. Then I tried many general purpose distros to see how well they work and all had some (minor) troubles ... 

We are having UEFI images (common image) since some time, but UEFI nor desktops were fine tuned nor ready for such performance daily driver desktop usage. We were close, but not close enough to just run it. Past two weeks we have been lifting general UEFI support, fixed many bugs and what came out is "Armbian ultimate developers desktop build".
 

 
- improved support in GRUB (armbian wallpaper) & HiDPI GRUB support
- all preinstalled applications are normal apt packages
- current 5.15.y kernel, Jammy userland (5.19.y has some strange issues)
- snapd is not installed (user can install it)
- HiDPI support (automated adjustments on big screen resolutions)
- NVIDIA graphics acceleration with proprietary driver (x86 only)
- Intel graphics acceleration also works out of the box
- preinstalled Google Chrome (x86 only)
- preinstalled Microsoft Visual Studio Code (x86 only)
- ZFS 2.1.5 ready (apt install zfsutils-linux zfs-dkms)
- face unlock works perfectly fine on this laptop
- installation to SSD drive to dual boot with Windows 10/11 is supported Armbian classical way by transferring actual live image to the prepared partition via nand-sata-install. All you need to do is prepare spare space on your drive, Windows 10/11 or Linux, UEFI support (most if not all hardware for past 10 years has it).
 
I have tweaked images (XFCE, Gnome, Cinnamon) a bit to my personal needs, but making changes is welcome.
 
Nice to have: disk encryption within nand-sata-install, small bug fixing, additional DEs. Currently we have CLI, XFCE, Gnome and Cinnamon. Others are too buggy.
 
https://www.armbian.com/uefi-x86/
https://www.armbian.com/uefi-arm64/
 
Please report where it works and how (well)!

It might not work at all as PD is borked on this hardware.

In order to have such functionality in open source, where anyone can integrate code from another, this will be a lot harder. For example - our user / you covers us only 0.5% of costs of this project https://docs.armbian.com/User-Guide_FAQ/ Manjaro on ARM is a lot smaller project and basically only builds mainline kernel for you. Official builds - they are patching stock kernel, where such functions might be glued together in some proprietary way, with blobs. Linux distributions usually don't go that way since that would mean support can be tied to one (and those very similar) hardware only.
 
What you are asking for is expensive to develop and I am not aware if there are any usable common ways. https://en.wikipedia.org/wiki/Mozilla_Foundation has 1000+ volunteers and around 100 full-time staff and yearly revenue of 500+ million dollars. If they can't provide this functionality OOB within their budget, few people certainly can't. This problem is also not Radxa specific. They integrate SoCs and sell it. We are focused into a build framework, so you can use this HW for something. For full potential, you need to look into different price range.