laibsch

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.

Overlay was renamed at some point to just uart5 `/boot/dtb/allwinner/overlay/sun50i-h616-uart5.dtbo` (without `ph5`), so `overlays=uart5` works and is available at /dev/ttyS1

Hi @Vodalex,
Write down the MAC address of the interface you want to use to wake up the Helios4.
ip link show You would need to put the Helios4 in suspend, by either:
sudo pm-suspend or:
echo 'suspend' | sudo tee /sys/power/state  
To wake it up, from another system, make sure that wakeonlan is installed. Then:
wakeonlan ${HARDWARE_ADDRESS} That should be it.
Groetjes,

Thank you for having a look and catching my mistake.  I have marked the PR as still work-in-progress for now while I look into where to patch this correctly in Armbian itself.

Anybody here with the Opi 5 Pro?  Does it need the same change?
 
https://github.com/armbian/build/pull/8568

Wow, that is awesome and thank you so much for sharing your findings.  Let's get this applied in our repo for the benefit of all Armbian users.

As per documentation, run on a compatible host:

git clone https://github.com/armbian/build
cd build
./compile.sh

Follow screen menus.
Build system will download necessary toolchain, sources, patches, etc and build an image.

Whether or not it will work depends on whether sources/patches for a particular board deviated from the hardware due to time or bugs. If someone is regularly testing then image likely will be ok, if not then image might work or not.

If the board has community maintained status, then it is up to its users to test/develop/send patches in GitHub.

If necessary, it is possible to play with sources, configs, develop and place extra patches, etc. At times it looks not that straightforward, so there will be a learning curve.

It's worth noting that you don't have to necessarily change anything in the build process. As long as you plan to not insert partitions in the middle, you can:
write the image to the card with parted, resize the root partition to whatever you want make a new partition If you want to have more than 4 partitions total, this works best with GPT partition table, but legacy msdos works too with a little more effort `fsck.ext4 -f /dev/foo` where foo is the root partition `resize2fs /dev/foo` after you have the machine booted, you can then mkfs the new partition [you could probably do it in advance of booting the system too] I do this regularly, b/c I typically only partition about 1/2 or 1/4 of the SD card to leave the rest for wear-leveling.
 
Are you trying to do this as a one-off or are you trying to do it for a dozen or more SBCs of the same type?

Wow, I didn't know those command and mechanism even exist...  Thank you for your tip!
Any ideas regarding main (mmcblk2boot) topic question, perhaps?

I Did It! I Got It Working!!
 
ES8388 Analog Audio Output
 
Here's How (this is very easy to do):
It just involves making one simple modification to the devicetree.
 
Note: I did this with the Edge kernel. My guess is that it will also work with the Current kernel. You can also try the Vendor kernel if its devicetree has the same code.
Update: I've addressed the Current and Vendor kernels in this comment below:
https://forum.armbian.com/topic/52118-hdmi-audio-and-analog-audio-do-not-work-on-opi5plus/#findComment-225009
 
 
I manually applied this patch:
https://patchwork.kernel.org/project/linux-rockchip/patch/20250823-orangepi5-v1-1-ae77dd0e06d7@hotmail.com/
 
If you scroll to the bottom where it gives the patch, the GPIO_ACTIVE_LOW needs to be changed to GPIO_ACTIVE_HIGH in the given section of the devicetree.
 
Here's the simple / quick way to fix it, without having to go through any lengthy (re)builds.
Modify the already installed devicetree file (/boot/dtb/rockchip/rk3588-orangepi-5-plus.dtb).
 
1. Install the package: device-tree-compiler
2. Backup the original, and convert to .dts format as follows:
 
# Go to your devicetree directory cd /boot/dtb/rockchip/ # Make a backup of your original devicetree: sudo cp rk3588-orangepi-5-plus.dtb rk3588-orangepi-5-plus.dtb.bak # Use device-tree-compiler to convert the file from the binary .dtb format to source (text) .dts format (ignore the warnings) sudo dtc -I dtb -O dts -o rk3588-orangepi-5-plus.dts rk3588-orangepi-5-plus.dtb # Safety-Check Part 1: Convert right back to .dtb format (another filename), ignore the warnings. sudo dtc -O dtb -I dts -o rk3588-orangepi-5-plus-test.dtb rk3588-orangepi-5-plus.dts # Safety-Check Part 2: Compare the newly converted file with the original. They should be identical (this command should produce no output) cmp -l rk3588-orangepi-5-plus-test.dtb rk3588-orangepi-5-plus.dtb  
3. Using a text editor in sudo mode, edit the source (text) file:
rk3588-orangepi-5-plus.dts
 
Search for this phrase: simple-audio-card,hp-det-gpios
I should appear exactly once in the file.
 
# Here is what that line looks like (for me): simple-audio-card,hp-det-gpios = <0x133 0x1b 0x01>; # This is that same line before original compilation simple-audio-card,hp-det-gpios = <&gpio1 RK_PD3 GPIO_ACTIVE_LOW>;  
4. Notice between the brackets, there are 3  values, separated by spaces. The third value is the value to modify from GPIO_ACTIVE_LOW to GPIO_ACTIVE_HIGH, or for us, from 0x01 to 0x00.
 
5. Convert your modified .dts file to a .dtb file (ignore the warnings):
sudo dtc -O dtb -I dts -o rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dts # Optional: Quick Comparison Check (this should output exactly 1 line with 3 numbers: [big number] 0 1) cmp -l rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dtb  
6. Copy the new fixed file to (overwriting) your original:
sudo cp rk3588-orangepi-5-plus-fixed.dtb rk3588-orangepi-5-plus.dtb  
7. Reboot (and have ES8388 analog audio out).
 
Note: Whenever you do a kernel change or update, you will need to repeat this process until the Armbian kernel updates catch up with this patch.
 
 
Here's the lengthier explanation (this is repeatable if you want to check it out yourself)
1. I downloaded the source code for version 25.8.1:
https://github.com/armbian/build/releases/tag/v25.8.1
 
2. I extracted the archive and started the building process (./compile.sh) with the edge kernel (and a desktop image).
It would not build because it rejected two of the kernel patches, but it did download everything into the cache.
 
3. I then found the file described in the patch:
./build-25.8.1/cache/sources/linux-kernel-worktree/6.16__rockchip64__arm64/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5-plus.dts
 
4. In that file, I searched for the line indicated in the patch, just prior to the line to modify:
simple-audio-card,aux-devs = <&speaker_amp>, <&headphone_amp>;  
...and found the appropriate section. I confirmed the line that followed matched the original (incorrect) version mentioned in the patch entry.
 
5. I then scrolled to the top of the .dts file and looked at the files #included, to find where the GPIO_ACTIVE_LOW macro was defined. I figured dt-bindings/gpio/gpio.h was a reasonable place to look first. I found it here:
./build-25.8.1/cache/sources/linux-kernel-worktree/6.16__rockchip64__arm64/include/dt-bindings/gpio/gpio.h
 
Near the top of the file were these #defines:
/* Bit 0 express polarity */ #define GPIO_ACTIVE_HIGH 0 #define GPIO_ACTIVE_LOW 1  
6.  See the simple fix above for the rest.
 
Tags:
@Werner, @Igor, @laibsch
@dimaxus, @EricaLina, @ricardo_brz, @eselarm

you just overwrote all your data. sorry for the bad news.

So it just boots directly to oowow.
There is a menu item for shutdown or reboot.  Reboot tells you to remove any sdcards beforehand. So I didn't. 
And the sdcard booted. 
It has installed, and reboot works. 
I installed to emmc and nvme. 
So far so good.  
 
Tried the ts1040 screen once. It might ve not been plugged correctly.  Dead computer. 
I need to try the other direction.
Copper down. 
 

Could this be a power supply issue?
 
Unfortunately, there is no official maintainer for your board.  None of the core devs will be able to verify your issue.

Great! Thank you. I will try it.

a fix was just merged for Rockchip, update your repo and try again, maybe you are lucky

Yes, I am fairly confident you were experiencing one of these two
 
https://github.com/armbian/build/pull/8554 
https://github.com/armbian/build/pull/8555