Werner

You should check uboot logs if the dtbo is loaded correctly. You can get those using a debug serial console. If you don't know what that is or how to connect: https://debug.armbian.de

https://github.com/armbian/build/blob/main/config/boards/retroidpocket-rp5.csc https://github.com/armbian/build/blob/main/config/boards/retroidpocket-rpmini.csc You can build images on your own. https://docs.armbian.com/User-Guide_Board-Support-Rules/#community-maintained

Armbian does not have a config for this board nor is it supported in some way.

The logs you can aquire this way: https://debug.armbian.de

@TonyMac32

That's an interesting question. The chip itself seems to communiate via spi or i2c. Since USB cannot do that they put a raspberry microcontroller (RP2040) on it to handle this. The communication then uses a simple serial connection with the ch341 chip. I assume the klipper thingies can handle this by themselves automatically while when connecting this to a different device, you have to come up with some way to communicate with this board.

Which of these boards are you refering to? https://github.com/armbian/build/tree/main/config/boards

The rk3588 soc has a fixed boot order which is spi, emmc, microsd, other I think. So if there is a boot loader found on spi it will ignore other options and try to boot from that. While Armbian uboot binaries on spi are instructed to check if there is a microsd card inserted and boot from that, vendors can (ab)use this circumstance to make it harder for other operation systems being used because tools like rkdevtool are necessary to get rid of it. If the spi is pre-flashed with crap, I guess that's why the step is necessary.

If you have patience, CEC may work at some point with mainline kernel. There is not fast solution.

didn't even realize you were on beta repo. Well when you use bleeding edge, you have to be prepared for breakage since it is expected ;).

I'm not sure bit IIRC there should be a 1 second delay which would allow interaction but again, not sure...

We don't deal with android. I suggest to ask at xda developer forums or similar.

Just a wild guess: The code from orangepi wiringpi is old and no longer compatible with newer python which is shipped in Trixie.

No clue

Nothing strange there. The wireguard package comes from trixie which has dependency to debian's own kernel packages. The package cannot know that there is wireguard kernel-wise already in place or even know about Armbian kernel packages. So this is kind of expected. However I think at some point Armbian kernel packages included a apt information that it provides wireguard. Not sure about the status there.

merged. forum tag added.

There is no need to install "wireguard" as all Armbian images come with this kernel module by default. All you need is the userspace tools (if not installed already) from "wireguard-tools". If necessary try installing with "--no-install-recommends".

Different soc and even different soc family. This most likely will not work on h618.

zero2 != 2w moved to staging

Even though current is an LTS kernel it probably makes more sense to focus on vendor an edge. vendor because its rockchip bsp and close to being feature-complete. And edge for likely becoming the next LTS kernel which ultimately become current at some point. You can try to see what actually works on current at this time. You can ignore 6.15-6.17 since those patches, if still present, are for archival purposes only and will be remove at some point. In theory it could be re-used but may introduce confusion. If in doubt, copy and rename. Edit: Seems like lots of stuff has been mainlined already. So I suggest shifting your primary focus on edge.

If you need an image without desktop, there is always the build framework which allows you to build any combination of kernel and userspace and desktop you want.

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

Yes, that's correct. Didn't pay attention. Thanks.

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

Have you installed the proprietary mali blobs? https://github.com/tsukumijima/libmali-rockchip/releases/download/v1.9-1-2131373/libmali-valhall-g610-g24p0-gbm_1.9-1_arm64.deb