Werner

moved to staging

Well if you want to live on the edge, then use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } egde as branch instead of code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } current

Newer kernel packages may not have hit apt repo yet. Use the build framework to generate a set of kernel packages to be installed via dpkg -i by yourself: https://docs.armbian.com/Developer-Guide_Overview/ code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BOARD=rpi4b BRANCH=current kernel

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Our resources are limited so we cannot provide images for each board with each kernel and each desktop environment. Feel free to use the framework to build the combination you want by yourself. https://docs.armbian.com/Developer-Guide_Overview/

moved to staging

Armbian does not have things like "vendor-lockin" or something and descriptions like "does not work" aren't much helpful as well. Either way, we cannot help with 3rd party OS since we neither know them nor deal with them, so I suggest to ask at the place where you got the image you are attempting to use get from, like http://friendlyarm.com/

Ah, this board has n out of tree dt as well which most likely overwrites the patch. Try adjusting this file: ~/build/patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts

Hm, the sub-folder in userpatches might be wrong, not sure though. If in doubt just copy your patch directly into patch/kernel/archive/rockchip64-6.18/ Then it should be applied

At the very end of each compile.sh run there is a "curl" command which allows to upload the full build log to a paste service. This can also be done automatically by adding "SHARE_LOG=yes" to the command line. The URL is present at the very end of the process.

Full build logs?

https://github.com/armbian/build/pull/9724

Confirmed. From first glance it looks like dts files are missing.

Okay so then we have some issues here This is clearly wrong since these packages come from upstream Debian and cannot/will not work with Armbian kernels. This shall be reported here: https://github.com/armbian/configng/ Then you were lucky some working headers were present https://docs.armbian.com/Developer-Guide_Build-Preparation/ Or in very short: git clone the repo ./compile.sh BOARD=rockpi-4bplus BRANCH=current kernel Check output/debs for your packages Install via dpkg -i on the target board

We don't ship headers for each and every trunk image. Way too much data. Simplest solution is to use the framework to create a complete set of kernel deb packages. Those will include matching headers.

moved to staging

Upstream support for rk3588 is still wip. For desktop usage I suggest to either try "edge" which may have the feature you want already merged in or try "vendor" kernel which is based on Rockchip BSP.

We neither deal with nor do we support 3rd party images/OS.

You are not using Armbian. This is a fork of Armbian which uses our name without permission and they do not contribute to the core development process. They trick you into thinking that you will get some sort of support at this place which isn't the case. We do not support 3rd party forks.

https://paste.armbian.com/hicilanono Works just fine

moved

Booting from mtd/nvme should just work. Most common problems: - dirty mtd/emmc. vendor/unmatching boot loader can cause issues. - mixup between m.2 sata and actual nvme. Correct overlay/dt must be used - wrong rootfs uuid in armbianEnv.txt after running armbian-install (after done, do not reboot but mount freshly written nvme to a random folder and check if the uuid is correct)

moved

moved to tvboxes

Since we do not add any Intel drivers this regression may come from upstream. You could test nightly build which have kernel 7.0. Also total random guess: Perhaps more recent kernels expect more recent firmware blobs, perhaps the ones on the board are outdated (or are expected to be on a different place)? No clue though through which package those are shipped though. Seems like the files have been touched last around 7 month ago: https://git.kernel.org/pub/scm/linux/kernel/git/iwlwifi/linux-firmware.git/tree/intel/iwlwifi