Werner

I have sent a new pr. basically you do something like this: code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BOARD=orangepioneplus BRANCH=edge kernel-config This will spawn a kernel menuconfig where you can modify the kernel config. This menu also takes all necessary dependencies into account. Once everything is done the kernel config file in config/kernel is modified. If you use a tool like vscode this will automatically visualize. If you manually change the kernel config file and want to check if your settings are persistent to rewriting you can use the code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } rewrite-kernel-config command similar to the one above.

hehe, yes. because on every new major kernel version the same stuff occurs: rollover and adjust the (huge) patchset to the new version. Because patches were copied, this resulted in these large line numbers. in any case, kernel rewrite addresses things like unmet dependencies, hence throwing stuff out which would not work this way anyway. to make sure it is persistent, use kernel-config to spawn a menu config and enable the necessary options. The resulting kernel config should persist.

I'd check all "edge" configs for the presence of usbip. at one of those at least a build test should occur

feel free to send pr

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

It doesn't even attempt to load which is odd. usually it tells you that it (at least) attempts to load in both success and failure cases. Everything else looks pretty normal.

attach serial console to check uboot log if the overlay is actually loaded

moved to tvboxes

If you plan to add this to the Armbian framework to have it included, I suggest to bring the drive in a dkms compatible state and create an extension (https://github.com/armbian/build/tree/main/extensions) to add this driver to specific boards. I know that other out-of-tree wifi drivers are added here (https://github.com/armbian/build/blob/main/lib/functions/compilation/patch/drivers_network.sh), however this is already a huge mess and I won't allow any more additions, rather than looking forward to some point in the future when this is dissolved in to individual extensions which make things hopefully more maintainable. AI will probably a huge help in this matter.

If this is really the case, then this must be an upstream issue since Armbian does not touch this file AFAIK. Picked a random userspace from armhf (since you did not state which you are using) ~/build/cache/rootfs/bin# file su su: setuid ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=b24ceef58082e181650b17e52819559be2d3a97b, for GNU/Linux 3.2.0, stripped

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

Well as you see, I am not Again, just use dd to grab a backup (dd if=/dev/mtdblock0 of=/somewhere/to/store/spi.backup)

Then wipe spi and retry. You can also pull a backup, simply via dd

Hi, It depends on what you want to do with your device. You should check this sheet if the features you depend on are actually available in mainline linux: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md Also take note that you may run into trouble booting when switching kernels. The reason is that vendor kernel images may (I don't know for this particular board) also come with (from guts feel from the stoneage) 2017 vendor uboot which may have issues booting an up to date mainline kernel. Fixing can be a bit of a pain if you don't have a second arm64 device which you could plug your microsd (via usb adapter for example) into, chroot into and fix this.

Yes, true. Meaning dirty spi Yes and no. If SPI is detected and valid it is used. However if this one detects a microsd card with a boot loader it will chain-load this one to ultimately load the os from microsd. Having mixups between vendor and mainline u-boot and/or mixed blobs (like ddr training) this will much likely cause issues.