Igor

@amazingfate can tell that. https://github.com/armbian/build/blob/main/config/boards/oneplus-kebab.conf#L3

That should be O.K. too.

tl;dr; This "only" difference is huge - modern kernel hw specific code is pretty much written from scratch, feature by feature. Not to mention differences in general areas between kernel 6.1 and 6.12, low level boot loader is also usually different. Further reading: https://docs.armbian.com/User-Guide_FAQ/#why-things-stop-working

Vendor kernel 6.1.y with mesa-vpu extension https://github.com/armbian/os/blob/main/userpatches/targets-extensions.map#L58 (with patched Chromium) is the only way to come close to what you want. Only this:

Here also ok: root@uefi-x86:/etc/apt/sources.list.d# LC_ALL=C apt update Get:1 https://download.docker.com/linux/debian bookworm InRelease [47.0 kB] Hit:2 http://deb.debian.org/debian bookworm InRelease Hit:3 http://security.debian.org bookworm-security InRelease Hit:4 http://deb.debian.org/debian bookworm-updates InRelease Hit:5 https://github.armbian.com/configng stable InRelease Hit:6 http://deb.debian.org/debian bookworm-backports InRelease Hit:7 https://repos.azul.com/zulu/deb stable InRelease Hit:9 https://openhab.jfrog.io/artifactory/openhab-linuxpkg stable InRelease Hit:8 https://netcup-01.armbian.com/apt bookworm InRelease Fetched 47.0 kB in 1s (67.4 kB/s) Reading package lists... Done Building dependency tree... Done Reading state information... Done 33 packages can be upgraded. Run 'apt list --upgradable' to see them. Perhaps some mirror is not in good shape, but that is automatically removed - in a cronjob.

That is over-optimism for most if not all of those chips - unless additionally cooled. I haven't played with exact this board much, so I am unaware of cooling specific for this board, but this is powerful SoC on a small board + every SoC needs some cooling in order to keep temp low. Do you have a (proper) heat sink? https://blog.armbian.com/stay-cool/ This looks quite normal: ### Boot system health: Time CPU load %cpu %sys %usr %nice %io %irq Tcpu C.St. 01:42:36 1800 MHz 0.30 52% 32% 17% 0% 1% 0% 61.1 °C 0/6 01:42:36 1800 MHz 0.30 35% 8% 26% 0% 0% 0% 59.4 °C 0/6 01:42:37 1800 MHz 0.30 32% 5% 25% 1% 0% 0% 59.4 °C 0/6 01:42:37 1800 MHz 0.30 32% 4% 25% 1% 0% 0% 59.4 °C 0/6 01:42:38 1800 MHz 0.30 30% 4% 25% 0% 0% 0% 59.4 °C 0/6 Also worth mentioning that here we only have Rockchip provided kernel. No modern kernel yet - which usually brings less aggressive performance / voltage settings.

I am running 6.12.37-current-x86 (with those changes) on my desktop and laptop, bare metal. Everything seems to work, multiple monitors, HDMI audio, acceleration, suspend / resume, BT, BT suspend, ... I would suggest you to use current kernel. I use this https://docs.armbian.com/User-Guide_Armbian-Software/Management/#cockpit for running VMs. That's for arm64 cloud image only.

Those were the days I remember compiling Linux 0.9 something .... it took a day and often nothing worked LOL. In embedded Linux, compiling kernel is nothing unusual, which is the reason why our build framework is focused into making this job easier. For tacking this parameter, you don't need to recompile everything. DTB can be recompiled on a device following by reboot https://www.google.com/search?q=recompile+device+tree+blob Device tree is just a hardware configuration that is provided to the kernel when it boots. This was the only possible related quick, cheap and easy way that I could come up with. Changing the value should have some effect - like (sometimes/always) not detecting PCI when going with weird numbers. More serious debug require a lot more time carefully checking code changes on areas that might have impact alongside with https://www.google.com/search?q=how+to+debug+pci+bus+on+signal+level Which is of course not cheap nor simple.

Welcome / Witaj! Plenty of options for quick and easy start: https://docs.armbian.com/User-Guide_Armbian-Software/ Those small things can do big things

I hope you have realistic expectations - I can only share tips and ideas - fixing is common problem in best effort way. This is most likely related to PCI driver. Which was done badly, its fragile since the day one. Try alternative kernels - and if you find a stable one, report back to forums. This might help nail down this problem.

https://docs.armbian.com/Process_CI/

Try to experiment with this value: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.6/board-rockpro64-0001-Add-pcie-bus-scan-delay.patch As this is pulled to DT, you only need to recompile DT - on board.

We might lost WSL2 compatibility, which is experimental ... I tried same command on my Ubuntu Noble bare metal ... and it works as expected. I suggest you to use some VM to complete what you want to achieve and open a bug at https://github.com/armbian/build so this gets eventually fixed.

I assume you didn't change your power supply or add more things to USB? This could trigger crash. It would help if you could catch the crash. Enable more verbosity (loglevel) might give some clues, otherwise this can represent more serious debug / not easy to catch and resolve.

In the past we had dedicated image for rpi5 ... It could be added here: https://github.com/armbian/build/blob/main/packages/bsp/common/usr/lib/armbian/armbian-firstrun#L112-L122

If boot from USB works, you don't need to install anything, just do 1st login config as described here: https://docs.armbian.com/User-Guide_Getting-Started/#first-login If boot from USB is not supported by this hardware (I don't recall if it works on N2+ or not), you need to start with SD card, conduct previous steps following by https://docs.armbian.com/User-Guide_Getting-Started/#installation

If you plan to start from scratch and you don't want to wait hours until repository is updated, yes, rather download and use latest image. Upcoming fix will solve this problem for everyone that still use old image.

Packages are in the update process - few hours from now it will be ok. It fails only on first images, which were avail for few days.

Some chips used in those usb2sata adaptors have issues combined with issues that are present on USB3 stack on some SoCs = troubles. Generally, USB3 storage solutions are to be avoided if possible.

Board usually shuts down in case it reached critical temperatures. Can you add a heatsink?

- there are several revisions of Rock64 and not all work so the problem is similar to cheap TV boxes, which are assembled from random hardware parts - released images (at least Debian minimal) work on my revision, however I didn't test HDMI output Try attaching serial console to see where it stops, check if it gets up on the network ... perhaps its "just" broken HDMI.

Once PR is merged, automated nightly beta repository has this kernel within hours.

Sadly no. https://github.com/armbian/build/tree/main/config/boards There are (too) many boards in the system, added by random people (this is build system and we accept anything that builds, but we don't maintain those boards as we can't afford associated costs / there are not enough resources), but only supported / .conf are recognized until there is someone willing to maintaining them and fits condition of "supported" board. When we find out that conditions are not met anymore, they are "un-recognized". Support is defined under those rules: https://docs.armbian.com/User-Guide_Board-Support-Rules

Welcome to custom hardware / division exotics / subdivision retro It is hard already when its new custom hardware and main division. If nobody ported HW to mainline Linux and keep it operational, its usually quite a long path. Armbian provides build framework, that helps in the process, but hard work is still on the one that will deal with the SoC - here you can hope to find someone on forum(s) to share some specific ideas. Adding is fairly straightforward https://docs.armbian.com/Process_Contribute/#adding-a-new-board but if there are sources for boot loader, sources for kernel, or better - support in the mainline kernel. Even when you have all this, it can still be quite challenging. Each such board usually require more people, a team. When I recall how many months we lost on one of Marvell's 🤔 Espressobin is an example how board support can be made super complicated - check history from day one. If board support package is on that level ... its worse out of all we have seen here. And now its an old hardware, not interesting so much. And remain broken as we don't have anyone to deal with it / its not worth.

Feature regressions are expected - Linux kernel is complicated machinery and without spending hours, a day or a week investigating, it's usually not possible to tell. We don't touch Rpi kernels much. We have our own kernel config, but we use official Rpi sources, so I guess 1st step would be looking if someone reported something similar https://github.com/raspberrypi/linux/issues By newer you mean 6.12.y, 6.16.y ... or 6.6.63 ->