Werner

I have an odroid xu4 and want to thank you for the great work ...
 
_ _ _ /_\ _ _ _ __ | |__(_)__ _ _ _ / _ \| '_| ' \| '_ \ / _` | ' \ /_/ \_\_| |_|_|_|_.__/_\__,_|_||_| v25.2.2 for Odroid XU4 running Armbian Linux 6.6.75-current-odroidxu4 Packages: Debian stable (bookworm) IP addresses: (LAN) IPv4: 192.168.178.24 IPv6: fd0b:5278:d32e:0:1d4d:933a:afcc:c02 (WAN) 188.136.105.135 Performance: Load: 1% Up time: 27 days 5:26 Memory usage: 4% of 1.94G CPU temp: 47°C Usage of /: 5% of 29G storage/: 3% of 234G Tips: Support our crowdfunding project https://forum.armbian.com/crowdfunding/project/16-help-armbian-grow-support-joi n-our-team/ Commands:  
Danke ...

We can discuss including this into CLI/desktop images. Not for minimal.

This is more or less expected for current since the HDMI implementation in this LTS version is very basic/incomplete. Features were and still are in development and did not make it into this version. If you need desktop use edge or vendor.

If there are no pre-built version available, use the build framework to create your own: https://docs.armbian.com/Developer-Guide_Build-Preparation/

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