Werner

https://github.com/armbian/build/blob/main/config/boards/bigtreetech-cb2.conf
Config is there. If there is no pre-made build available use the framework to create your own. This is what it's made for.

Alright. Yes, there seems to be some issue with the naming of the overlays which required editing armbianEnv by hand. It is hard to keep up with the continously changing world of SoCs and kernels where latter, especially on mainline, often even lacking basic overlays since close to nobody deals with this.

Seems indeed broken for H61*
H6 is fine.

Available images are here:https://www.armbian.com/orangepi3b/
If your desired flavor and kernel combination isn't available build your own:https://github.com/armbian/build

Well on the bright sight both max and ultra are very similar.
Though overlays might differ but that would need investigation. Easiest route is the one you actually already got on by checking the vendor source. Maybe they also provide a handful of matching overlays for this board. Maybe they can be ported.

Well on the bright sight both max and ultra are very similar.
Though overlays might differ but that would need investigation. Easiest route is the one you actually already got on by checking the vendor source. Maybe they also provide a handful of matching overlays for this board. Maybe they can be ported.

I suggested to split 5 and 5B again since one works well, the other not. If it cannot be fixed consequence will be dropping it to csc or eos.

At this time I bet it will work better with vendor kernel since it is close to feature-complete while mainline is still under heavy development. But well, worth a try I guess.

This isn't something specific Armbian, so I even would say it is good that armbian contributors don't waste time on it to have it in armbian-config. You just type:
'How to change default window manager'
in your favorite search engine and then pick what is listed for Ubuntu or Debian.

Unless OP is using EDKII there is no bios on RK3588 boards in general.
 
  
We include this driver already?
https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh#L292

I noticed it is applied somewhere between the existing patches. Have you tried to rename it to something like zzzz_yourpatchfile.patch so, since they are ordered alphabetically, it is applied at the very end, just like your chances have been made with all the previous patches already applied.

There are multiple lines starting with overlay=
Put all in one line like overlays=uart1 uart2 uart3 uart4 i2s i2c whatever
Make sure the enabled overlays don't share same GPIO pins. Check your boards datasheet/manual.

There should only be an issue when someone use boot firmware intended for a different board.
 
Please read the patch thread, the patch was partially rejected.
 
If you want to do a custom patch just replace ethernet-phy-ieee802.3-c22 with ethernet-phy-id001c.c916 in Linux device tree.

I noticed it is applied somewhere between the existing patches. Have you tried to rename it to something like zzzz_yourpatchfile.patch so, since they are ordered alphabetically, it is applied at the very end, just like your chances have been made with all the previous patches already applied.

Debian has some weird behaviour when using "su" because $PATH lacks /sbin for whatever reason. /sbin/chroot instead of chroot might work

This design decision has been around from the early days of Armbian and SBC's.  If you think about Armbian as a firmware for your board instead of a general operating system like on your PC, that makes some sense as to why originally that would have made the most sense (you install new firmwares, you don't upgrade them in place).  Also, all those early boards were limited on the amount of internal emmc storage they may have had, if any, and SD cards were also much smaller in storage capacity at that time.  So wasting space with an entire extra kernel wasn't really an option.
 
Now move forward 10 years and most of those limitations are lessened.  So it could be supported today for most build targets.  But the current approach would likely still be needed for some boards.  So while it would be feasible to support having multiple kernels installed it would take a lot of effort to implement (across all the different booting scenarios, u-boot scripts, extlinux, uefi, etc).  Also in many of these scenarios it doesn't really help as you need an interactive boot (i.e. with hdmi and keyboard/mouse input) to present a menu to the user to select an alternate boot target, and that interactive boot environment isn't common on SBC's (unlike the PC world).  If you have to solder and hookup a USB-UART connector to monitor the debug output to be able to switch your boot kernel, is that better/easier then just popping in a different SD card?
 
So ultimately like a lot in the open source world, this change while possible, hasn't attracted the interest/need for any developer out there to want to undertake this effort.  Which leads me to the inevitable next comment, PRs are always welcome for contributions to the project 🙂
 
(Personally this is something I would also like to see, but in looking into the effort it would take, I know I personally don't have the time to implement, and the workarounds are good enough for me)

That's what you get with bleeding edge.
Use vendor if you need stuff working.
Here is great overview of what is working in mainline: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

I guess the patch has not been carried over to 6.12 since the folder is empty: https://github.com/armbian/build/tree/main/patch/kernel/archive/imx6-6.12
 
 

Thanks for your help, the OMV7 installation went smoothly.

It does work. The issue I referred to relates to the rsync bug. Seems solution is to update rsync and update for 22.04 was just released: https://bugs.launchpad.net/bugs/2095004

glxinfo -B

The kernel checks a few places for firmware blobs. https://docs.kernel.org/driver-api/firmware/fw_search_path.html
 
You can also set a firmware path in cmdline. This usually isn't needed though.
firmware_class.path=/lib/firmware/updates/brcm  
The kernel checks /lib/firmware/updates before /lib/firmware, allowing us to be able to test new firmware without removing the old.
 

I can't even imagine the amount of work involved on both sides of the (debian) development fence, as well as the admins, mods, community contributors, ..., here, that help make Armbian a viable SBC (ARM) whatever OS. -and here's to RISC-*, and let it not be too encumbered.
My "Armbian_24.11.1_Odroidc4_noble_current_6.6.60-kisak.img" works very well on my lowly Odroid-C4.
I don't know your names, but
Thankyou all.
 

That's probably what I'll do - I'm fairly sure it's broadcom related - I have another pi 5 with raspbian installed  (which has wlan0 present by default) so I can probably glean some info there - wish me luck

Just checked and it seems like their Release file on the repo is still marked with ovm6 while the package you get when installing is omv7.

Tried to build an image with omv pre-installed, but throw a bunch of errors, so no idea if it works. https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Rockpro64_bookworm_current_6.12.9-omv.img.xz

If not grab a standard rockpro image ( https://dl.armbian.com/rockpro64/Bookworm_current_minimal ) and proceed according omv docs:  https://docs.openmediavault.org/en/stable/installation/on_debian.html
Keep in mind that omv heavily messes with the system, so if anything breaks after installation (like network access or even boot) we cannot help. This is userspace.