laibsch

Armbian 25.8.1 Noble XFCE (BSD Kernel: 6.1.115)
 + PanVk - mesa 25.3 (https://launchpad.net/~kisak/+archive/ubuntu/kisak-mesa)
 + box64 3.9 (https://ryanfortner.github.io/box64-debs/)
 + wine-10.19-staging-tkg-amd64-wow64 (https://github.com/Kron4ek/Wine-Builds/releases/tag/10.19)
 + DXVK-sarek-stripped v1.11.0 (https://github.com/pythonlover02/DXVK-Sarek/actions)
~60fps@1080p 
 
Cat Quest II

I would always go RPi, as I have been burned going with a different board in the past. This may not be a fair reflection on the Orange Pi, as I can only speak for having purchased an Odroid C1+ many years ago.
 
The C1+ was a very capable board, and definitely more capable than the RPi offering at the time. However, there just is no substitute for the support and community around the RPi. I now have 3, and even my original RPi 1 Model B+ is still supported by the RPi foundation, and still gets modern kernel and OS updates. This is a board running off just 512MB RAM, A 700 MHz single-core 32-bit processer and released over 11 years ago. No one could complain if they had dropped support long ago, but they didn't, and they still show no signs of dropping support any time soon.
 
Hardkernel, on the other hand, pretty much dumped support for the Odroid C1+ as soon as it released, so it is stuck on a 3.x kernel and a uBoot from 2011. If it wasn't for the Armbian project this board just would not be useable, and even then, we are still stuck on a 15 year old uBoot solution.
 
None of this may be important to you, and like I say, my experience is not likely a like-for-like comparison with the Orange Pi, but the long term support you get from the RPi foundation and the wider community around it is not even close to being matched by any other vendor, and (personally) I don't like supporting vendors who effectively manufacture e-waste.

Submitted the PR:
https://github.com/armbian/build/pull/8882

Debian 12 and 13 have trouble establishing the correct EDID for the monitor, which is why it doesn't recognize resolutions correctly.
I spent two weeks reading and testing everything until I found the solution.
You need to connect the monitor to a Windows PC, install and run the CRU program.
This program correctly reads the monitor's EDID. Simply export the data and save it as a BIN file.
Then, reconnect the monitor to your Orange Pi device. Copy the exported .bin file to this directory: /lib/firmware/edid/
Next, you need to load the parameters into the kernel:
Edit the armbianEnv.txt file and add:
extraargs=drm.edid_firmware=HDMI-A-1:edid/you_file.bin video=HDMI-A-1:1024x600@60
Set your chosen resolution.
Restart and verify: `cat /proc/cmdline`
Check that the string loading your custom EDID appears.

Okay I gave up on it and done a fresh install.. Took me 5 hours to get it back up and running, to reconfig x11vnc and samba stuff.

Starting a freshly baked image proved to be a nightmare - for whoever is interested I share my story;
For some reason it did not detect wireless dongle for keyboard. So I could see it over hdmi but no input was possible. Did not have a wired keyboard at hand. at first run it did not became accessible over ssh. but an ip address was assigned to it by dhcp router; I could see a new ip when I'd start it up. but it would not respond to ssh requests. But serial connection saved the day. Luckily I did have a serial adapter. Created username/password and then it was accessible over ssh and I could ditch the crappy tv screen I was using
 
Selected wrong locale on setup, was unable to get rid of it without commenting wrong locale lines in ~/.bashrc
 
Then I spent some few hours to get vnc up and running with lightdm and crapload of other dependencies, packages. Thanks AI for assistance. When asking quality questions and sharing messages/outputs it was super useful (I dont keep anything confidential there)
Manually created /home/domas/startxfve_headless.sh script, made it executable, the whole orderal

Not to mention xfce was not installed by default on this debian/minimal image. It was fun one too.
https://docs.armbian.com/User-Guide_Armbian-Software/Desktops/ - armbian-config --cmd XFCE01 just ran the script and nothing happened without any error
Had to do it manually but I think it worked the first or second time.

And the most fun one since it included multimeter and soldering iron: then it did not detect my disk over sata no matter what I do.
Apparently measured 0v at hdd power connector. Not sure how I killed it.
After some fiddling around I connected jst connector's for hard drive 5V power to one of gpio pins that supply 5v. HDD spins up - YAAAY.
It was short-lived. Disk Still undetected. Probably usb to sata controller is not powered on since 5v regulator fried. (thanks AI for ideas)
So then I jumped a wire from said gpio 5v pin to the back of what used to be 5V connector for hard drive so it both feeds the disk and backfeeds the boards 5v regulator with the needed usb to sata controller. I don't use gpio.

ITS ALIVE. No, I did not believe it would work. But at this point I had nothing to lose.

Sketchy? Yes. Have I ever pulled worse? Sure. Proud of myself? You bet.

 

Thank you for that patch.  Do you know how to use git and github?  You don't necessarily need to open an issue first.  You can go straight to pushing a PR.  Just explain yourself enough so that a reviewer who may not understand your board can see why your patch should be merged in.

Hello,
 
I have two Orange Pi Zero 2 for two years, I didn't know what to do with it.
 
Yesterday I  have installed Armbian_25.5.1_Orangepizero2_noble_current_6.12.23.
 
The serial was a bit buggy during installation (display + key press), I have used option -L with screen:

 
screen -L /dev/ttyUSB0 115200
Thank you for your great work !

No disagreement @Igor. I wouldn't recommend any distro attempt to maintain device-specific support for this family of devices. Especially because there is a pathway to UEFI booting which does allow these devices to be supported by generic kernel packages. I also feel that it shouldn't land on any Linux distribution to be expected to provide support for bootloaders. As a result, I was impressed by the amount of effort I saw around this device and sympathize with how you and the Armbian team must feel.
 
I would, however, caution against letting that frustration spill over into resentment of your user base (or potential user base). I'm not familiar with Armbian's philosophy and what the expectations are between users and maintainers/developers. At Arch Linux the philosophy and expectation is extremely DIY/self-support oriented and those expectations are made very clear. However, that can come across as rude/off-putting to people who show up looking for help. And when you have a volunteer effort (which by definition means you are chronically under-resourced), that kind of philosophy/approach can scare away potential future volunteers/contributors. And obviously if a volunteer project can't attract/retain new contributors then it's just a matter of time before it's dead. Anyone considering Arch Linux ARM for this family of devices would be wise to read this thread: https://bbs.archlinux.org/viewtopic.php?id=290931
 
Personally, I throw most of the blame for the state of these devices on Globalscale and Marvell. The CPU frequency scaling debacle that seems to actually be related to an improperly configured bootloader all along seems to have burnt everyone out so people moved on to other devices. The one silver lining is the open source bootloader. With frequency scaling no longer an issue and UEFI supported, there really is no technical reason these devices can't be supported:
 
ben@ebu-dev:~$ sudo hostnamectl Static hostname: ebu-dev Icon name: computer-embedded Chassis: embedded Operating System: Arch Linux ARM Kernel: Linux 6.9.9-1-a3700 Architecture: arm64 Hardware Vendor: globalscale Hardware Model: Globalscale Marvell ESPRESSOBin Ultra Board Firmware Version: 2024.04-dirty Firmware Date: Mon 2024-04-01 Firmware Age: 3month 2w 3d  
It is, as you correctly note, a question of time/effort.
 
I'm not super familiar with this distribution and community and don't want to step on anyone's toes. If the generic kernel packages provided here are still being configured to support these devices and the only obstacle is how to fix/configure the bootloader, then that's where I am offering to share my experience. But anyone that wants to get Armbian running on their mvebu device is going to have to be willing to put in the work to at least get their hands dirty messing with U-Boot and potentially even building/flashing a more modern bootloader.

I had some difficulties to make my sata disk work and found out that the regulator had to be switched on. So here a dtbo and source to make it hopefully a bit easier for some others.
Easiest way to install is "sudo armbian-add-overlay orangepi-5-sata.dts"
orangepi-5-sata.dtbo orangepi-5-sata.dts

It would make more sense to send a PR to fix this so it is included in all upcoming images/releases.

Sige5 is community supported and those boards receive automatic generated images only - once per week. Since GitHub introduced additional limitations few months ago, we can't (auto)produce desktop images anymore - only one Debian stable minimal per CSC build target. However, this might change in the future.

The mmcblkXbootX partitions are hardware defined partitions on eMMC storage device and can be used by 
storing boot firmware.

What? Sharing various gaming experiences with RK3588 (Orange Pi 5) on Armbian.
Why? Because RK3588 is a capable gaming chipset, Armbian is a good OS; Vulkan on RK3588 is getting better over time (PanVk)
How? Posting your gaming results here (preferably with setup and screenshots/videos) so people can learn more.

SOLD

This is severely outdated. Use this one instead: https://docs.armbian.com/Developer-Guide_Build-Preparation/

I'd say let's wait at least until it lands in Debian

I'll provide some background on what you are experiencing.
6.1 is the vendor kernel.  This is what comes from rockchip and is a hacked together set of code that they release to board builders.  Armbian doesn't have really any interest in maintaining this code base.  6.12 is mainline Linux directly from kernel.org with some additional.patches applied.  It often tales years for the open source community to get new CPU variants incorporated into the mainline kernel code base, as the vendors (rockchip and OrangePi in this case) don't generally contribute.
So 6.12 is actually far behind in feature support for your board.  The edge kernel, 6
16 would be better.  But if you want a feature complete kernel.for your board, the 6.1 vendor kernel is best.  If you want security updates but can deal with lack of some features, then the edge kernel should be your choice (at least until early next year when Armbian current moves to the next Linux LTS release).
 
Also, from the perspective of best boards under Armbian, you probably are better off with Armbian supported boards, not a community supported board which by definition doesn't have anyone maintaining it.
 
Final note, is that Orange Pi as a company does nothing to support the open source community.  I'd say their main goal is to pump out new hardware as fast as possible and not supporting older hardware in any way to force people to spend more money with them. In general support and software is a huge cost and doesn't provide any profit for them, so they choose not to provide it.

Something like
git clone https://github.com/armbian/build.git -b main cd build git remote add -f imx8mp-build https://github.com/OLIMEX/imx8mp-build.git git remote update git fetch origin git fetch imx8mp-build git checkout main git rebase imx8mp-build/bookworm # fix conflict vi VERSION git add VERSION git rebase --continue # fix conflict vi .github/dependabot.yml git add .github/dependabot.yml git rebase --continue git log  

Let's say the world has been extra certain to bring me IRL problems 😄, as far as a bootloader being present, the Libre Computer Tritium boards are as barebones as can be possible, so any issues should be shared across any/all other H5 boards and really not board specific.

I searched the github.com looking for possible answers to my problem. WendySanarwanto published a few scripts under the title arm-cpu-temp.  I just looked for the one dedicated to Banana Pi M3 and it turned out that the folders are about the same as for the RPI5B. For anyone interested, I have included a sample bash script below:
#!/bin/bash echo 'Temperature: '$((`cat /sys/class/thermal/thermal_zone0/temp` /1000)) ' °C' echo "CPU-0 Frequency: "$((`sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq` /1000)) ' Mhz' echo "CPU-1 Frequency: "$((`sudo cat /sys/devices/system/cpu/cpu1/cpufreq/cpuinfo_cur_freq` /1000)) ' Mhz' echo "CPU-2 Frequency: "$((`sudo cat /sys/devices/system/cpu/cpu2/cpufreq/cpuinfo_cur_freq` /1000)) ' Mhz' echo "CPU-3 Frequency: "$((`sudo cat /sys/devices/system/cpu/cpu3/cpufreq/cpuinfo_cur_freq` /1000)) ' Mhz'  

Well, I don't even own a RPi, but here are some suggestions:
You mention several OS'es, but not Armbian. Have you tried Armbian? If not, that would be the first thing to do, specially since you asked here :) In your video, you show RISC OS, and apparently it is running a armv7 version. Could it be that 32-bit ARM OS's are working, but 64-bit are not? If this is the issue, then maybe you can try to build 32-bit Armbian image and see if it works. It could also be a device tree issue. Maybe you can extract the DTB from some of the OS's that are working, and try to use it with an Armbian image.

Alright, let's give  a real quick overview where the code for A20 comes from. Let's focus on current.
 
First stop. Board config: https://github.com/armbian/build/blob/main/config/boards/bananapipro.csc -> BOARDFAMILY="sun7i"
Next stop. Family config: https://github.com/armbian/build/blob/main/config/sources/families/sun7i.conf -> No sources defined. However there are includes.
Next stop. Includes: https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc -> No kernel source URL defined. Therefore kernel comes from mainline (kernel.org to say). However a version is tagged: v6.12.43
So we know: Linux source comes from unmodified mainline and the version is 6.12.43
 
Next stop. Patches: https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.12 ->  vendor family = sunxi, kernel major.minor is 6.12
All these patches are applied on top of the kernel source from kernel.org. And yes, that's a lot. I think sunxi is the worst family regarding number of additional patches to make stuff work.
 
Next component is u-boot.
https://github.com/armbian/build/blob/main/config/sources/families/include/sunxi_common.inc -> BOOTBRANCH:-"tag:v2024.01" so uboot is tagged to this version.
So we know: U-Boot source comes from unmodified mainline and the version is v2024.01.
And BOOTPATCHDIR="${BOOTPATCHDIR:-"u-boot-sunxi"}" which means here we find the patchset put on top of that version. Let's check.
https://github.com/armbian/build/tree/main/patch/u-boot/u-boot-sunxi -> folders starting with board_ are applied only if the target board is being built. All remaining paches are always applied.
 
There are more definitions of stuff appling for multiple families, whole architectures or even all boards regardless of architecture but in this case they are not important. Just including for the sake of completion/information:
https://github.com/armbian/build/blob/main/config/sources/armhf.conf
https://github.com/armbian/build/blob/main/config/sources/common.conf
 
 
Good luck.
 

Hi again,
 
It took some time but finally I was able to take a look at it myself.
It seems to me that the original kernel patch from @brentr is still a working solution as the affected kernel code didn't change in the current kernel. So by applying the original patch, 10mpbs Ethernet started working again on my Rockpi S. I'm not able
 
I created PR #8575 - Fixes regression of failing 10Mbit built-in Ethernet in Rockpi S to add the patch again. I hope, that's ok as I'm lacking experience in this field so please apologize if I missed something, I just want to help and improve 🙂
 
Cheers,

Oh, sorry, I didn't notice the non-existent 6 and read it as Helios64.
Of course, my description of the boot method is not limited to Rockchip devices; it works on all for which a mainline U-Boot is available. I have used it on iMX6, LX2160A and S922X devices, but my remaining devices are all based on Rockchip.
 
The solutions are too varied to present a turnkey solution here. However, I am sure that only a corresponding configuration for implementation is required to achieve the desired behavior, but for that, the U-Boot documentation must be consulted to decide which solution should be chosen.

Since the RK3399 U-Boot can use an HDMI display and a USB keyboard, I would simply configure a jumpstart option in the boot flow that mounts a different root filesystem. When booting, you just have to select this option.
If interacting with the firmware console is too complicated, the recovery system can be placed on a removable storage device. In this way, in case of need, only the rescue media needs to be connected and the system restarted; no firmware console access is required.
A completely firmware-controlled fallback mechanism is also possible, but it requires further special configuration of the firmware.
 
Read this thread to understand what I mean by my statement.