Werner

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.
 

https://debug.armbian.de

Easiest is probably to build a custom set of packages including headers.
With the build framework this is quite simple.
Clone repo https://github.com/armbian/build/
code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BOARD=odroidn2 BRANCH=current KERNEL_CONFIGURE=no kernel
 
Copy the debs from output/debs folder to the board and install them via code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } dpkg -i

Have you tried with the image I linked above? This is based around updated rockchip sdk kernel.

So I finally got a working solution.  I just replaced the dab file with the one from this post: https://forum.armbian.com/topic/44964-wifi-setup/#findComment-201441 in the Armbian_24.11.1_Bananapim4zero_bookworm_current_6.6.60_xfce_desktop package.
 
This got my wifi device to show up.  Then I struggled with getting a connection to my WiFi.  I kept trying to connect to my IOT network and couldn't get it to connect.  Then decided to try and connect to my main network and was able to connect.  My main broadcasts on both 5 and 2.4 but IOT only on 2.4.  It appears that the above patch ONLY connects to 5ghz networks and not either as is stated to be supported by the device.  SO I turned on both bands for my IOT network and it then connected.
 
AND my display is now correct, too!
 
Hopefully all these issues will be worked out soon on a stable package with proper wlan support.  However, in the short term, this gets me where I need.  
 
Thank you, @Werner for directing me back to that thread and getting me to try all kind of iterations.

Hi,
 
regardless of the image you are going to use we at this forum can only support Armbian images downloaded here: https://www.armbian.com/bigtreetech-cb1/
 
If you miss fixes or features that should already be included in Armbian you can also try pre-release images from here: https://github.com/armbian/os/releases

Everything is here: https://github.com/armbian/build/

Everything is here: https://github.com/armbian/build/

Change title to reflect the real question and moved to the appropriate forum

best chances to get an idea what happens inside is using debug console:
https://debug.armbian.de