Werner

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
 

The automated script  has been updated to support GUID partition table (GPT) images
 
Tested on the Radxa Rock 5B, with the Debian trixie minimal (rolling release) image
 
The tutorial will be updated shortly with instructions for GPT
 

What images are you using? Armbian ships armbian-config while orangepi-config is a copycat.
 
Edit: Just tested with mine, it powers on automatically.

I was thinking of asking the same question.
 
Personally my feeling is if you are planning on helping Armbian by working to incorporate your efforts back into Armbian then I strongly encourage your efforts.  But I would recommend working with the Armbian developers on how you plan to do this, as it can be frustrating for you if you put in a lot of work into something, only to find disagreement from the Armbian community about how you are implementing something that might prevent it from being accepted.
 
If your intention isn't to incorporate your work back into Armbian, then you are creating just another fork (like the many that already exist), which you are entitled to do since this is open source.  But in that case I would request that you not use the limited Armbian resources to do that (i.e. our developers and infrastructure like these forums).  These forums are for Armbian developers and users, not for use by forks of Armbian that just attempt to take from Armbian without contributing back.

This will be a fork that will return the code to the parent project https://github.com/armbian/build ?
Or is it planned to be developed as an independent project based on this branch?

We don't know if it works perfectly. We cannot afford doing extensive testing. We rely on user feedback in that matter.

bad sdcard isn't uncommon. One of the two first aid things to check if something is weird is switch sdcard to a known good one. The other is switch psu