SvOlli

New image build worked for me, update did break system, as previously mentioned.

I had the same problem with a Jammy setup on a 5 plus. Does the image build "./compile.sh" already include the new kernel setup, or is there even a prebuild image to download?

This might be the thing to get you going: try flatpak/flathub. Command line version, since this is the quickest (run as root): apt-get install -y flatpak-builder flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo flatpak install flathub moonlight Installation works, but during start I got the message: "No functioning hardware accelerated video decoder was detected by Moonlight." Since Moonlight is containered, it might be not having access to the driver of the host system. It might be that I was running it on Wayland. Between daytime job and other duties, I'm lacking the time to come up with a full solution, but one option I see is to for the original moonlight in an own hub, where it also depends on the libraries required for accelerated video. Hope this helps, SvOlli Edit: reading the second post, which I missed somehow, I see this doesn't help. Sorry.

Here's a quick and dirty way to get the deb packages: Step 1: install debhelper sudo apt-get install debhelper Step 2: get the wiringOP source code from the google drive and unpack it Step 3: unfortunately, the source code needs two fixes in debian/wiringpi.install remove the following lines: debian/tmp/usr/man usr/share README.TXT usr/share/doc/wiringpi in devLib/Makefile change the following line: INCLUDE = -I. to INCLUDE = -I. -I../wiringPi Step 4: build the binary packages: from within the "wiringOP" folder run dpkg-buildpackage -b This will give you the following files in the ".." folder: libwiringpi2_2.26~iwj_arm64.deb libwiringpi-dev_2.26~iwj_arm64.deb wiringpi_2.26~iwj_arm64.deb Step 5: install those using dpkg dpkg -i libwiringpi2_2.26~iwj_arm64.deb libwiringpi-dev_2.26~iwj_arm64.deb wiringpi_2.26~iwj_arm64.deb This is a quick hack to get you the packages you need. With python I can't help you, since it lacks the debian folder and Python and me are not on friendly terms. 😉 Also: I did not test, if the packages works in any way. And the way the packages are built is definitely not for distribution, as they lack the proper cleanroom build.

Going back through this thread you will find that this was implemented after the stable release. More recent images can be found on GitHub: https://github.com/armbian/build/releases. Another tip: using nand-sata-install didn't work for me, but writing the image direct to NVMe did. This can be done using an NVMe-to-USB3.0 adapter or by running the Orange Pi 5 from SD card and then dd'ing the image to /dev/nvme0n1 directly (just use "bs=1M" to specify a blocksize that larger then the sector side of the SSD).

I advise that you do it the other way round: take a look at the download sections for stable distributions and buy one of those boards. A stable version of Armbian for the Orange Pi 5 might take months, years or never appear at all. All work here is done by voluntaries in their spare time, so don't expect anything, except you might have to learn how to do it yourself. If you want something stable now, it might be worth taking a look at the official Orange Pi 5 software releases. I tested their Debian image and it worked so far, even transfer to and booting from NVMe. Didn't test graphics acceleration, though.

I'd like to know if this is faster than the ~350MB/s of the Gen3x1 NVMe/PCIe interface. SATA is capable of running at ~500MB/s. Could you run "hdparm -t --direct /dev/sda" (or whatever interface you SATA SSD is) and post the result?

Thanks for pointing me out in the right direction. They are there, if you know where to look: root@odroid-c2:~# grep -e J2 -e ^gpio /sys/kernel/debug/gpio gpiochip1: GPIOs 378-496, parent: platform/c8834000.bus:pinctrl@4b0, periphs-banks: gpio-456 (J2 Header Pin35 ) gpio-460 (J2 Header Pin36 ) gpio-461 (J2 Header Pin31 ) gpio-466 (J2 Header Pin32 ) gpio-467 (J2 Header Pin26 ) gpio-470 (J2 Header Pin29 ) gpio-471 (J2 Header Pin24 ) gpio-472 (J2 Header Pin23 ) gpio-473 (J2 Header Pin22 ) gpio-474 (J2 Header Pin21 ) gpio-475 (J2 Header Pin18 ) gpio-476 (J2 Header Pin33 ) gpio-477 (J2 Header Pin19 ) gpio-478 (J2 Header Pin16 ) gpio-479 (J2 Header Pin15 ) gpio-480 (J2 Header Pin12 ) gpio-481 (J2 Header Pin13 ) gpio-482 (J2 Header Pin8 ) gpio-483 (J2 Header Pin10 ) gpio-489 (J2 Header Pin11 ) gpio-491 (J2 Header Pin7 ) gpiochip0: GPIOs 497-511, parent: platform/c8100000.bus:pinctrl@14, aobus-banks: Notice that the mapping is not 1:1 to a Raspberry Pi. The pin 40, that I wanted to use, for example is an ADC input only. Maybe I can change the circuit to use pin 7 instead.

Is there any chance to get access to the gpios on the pin header again? In /sys/class/gpio only two "banks" are listed "gpiochip378" and "gpiochip497". From searching around the net, I think that gpiochip378 is for configuring HDMI and gpiochip497 only has 15 entries. I'd also expected to find the gpios in "gpiochip0" as on other platforms. Was this just an oversight in the device tree, when moving to a newer kernel or is it left out on purpose? P.S.: for me it's not required to access the gpios via /sys/class/gpio, any method to write to pin 40 (aka RasPi gpio21) would work for me.

Nope. 2G is used for all voice transmission in 3G and 4G/LTE. It's also used for services like automated emergency calls after a car accident. If something gets migrated for the use of 5G, it's rather 3G.

Because the kernel is running from the same RAM is used, but not counted. And also some RAM has been reserved for graphics. Using a buildroot similar to Squonk42's setup I've got ~56M of RAM available and ~40M free with just logging, a dhcp client and dropbear running.

The changes by "Squonk42" have been integrated into mainline buildroot something like two weeks ago. So if you checkout the current git, you can just build it. I also did something similar using the external layer feature of buildroot. This keeps custom changes separated from the "official" buildroot, so hacking is a bit more straight forward and migration to a new version of buildroot is easier. It's available at: https://git.h8u.de/Allwinner_V3s/buildroot-v3s I can also create a mirror on github if anyone is interested in joining in.

Would you mind sharing your configuration for building? A friend of mine is building his own board based upon the V3s and we're about to bring it up. To have something that can be built in a defined and reproducible way would really help.