Werner

Then it should not be an issue to find somebody from the community to come up with support. From official POV we do not add new boards without some sort of funding. Our resources are simply too limited.

No official plans. However anyone from the community can step up and add support for new boards

reverse engineered npu driver (called ROCKET) is upstreamed since 6.17 I believe. So kernel-wise it is there. Everyhing else necessary (like libraries) is out of scope for Armbian.

moved

First: https://forum.armbian.com/terms Second: Provide full logs

If an pre-made image is not there, just DIY. https://docs.armbian.com/Developer-Guide_Build-Preparation/

Nobody knows, nobody tried. Give it a shot. There is only one way to find out.

moved to tvboxes

closed for off-topic

We don't deal with OpenWRT. I suggest to ask at some place where OpenWRT is distributed/supported.

No, I let LLM poking at the problem.

Mirrors come and go. Check https://docs.armbian.com/Mirrors/#current-mirrors for an up to date list of active mirrors and its status.

I don't know. I don't maintain this board. Perhaps the maintainer knows which is alexl83. I don't know if he has a forums account though. Try via Github

duplicate

Nick explained above how to create such an image on your own.

We don't deal with other OS than Armbian. If you need Android, I suggest to ask at xda developers or similar place.

That's not an issue. These fixup scripts are only there to allow dt overlays being configurable via parameters rather than having hard-coded pins for example. About the actual issue, no clue. I suggest to try 7.0 kernel from "edge".

There were changes merged fairly recently. Perhaps try this: https://github.com/armbian/build/pull/9600

None I am aware of. neither do I have this board nor do I maintain it.

I think there is an option somewhere in armbian-config to edit the device tree. How to diff: https://www.perplexity.ai/search/create-a-short-and-shareable-e-8cKctYlWQJO8jKY0vDOKgg I don't think so but you can try reverting this pr and do a test build.

The output still seems truncated. Perhaps leave the device running for a while with the broken kernel (I suggest to build your own kernel package for either "current" or "edge" to rule out that this hasn't been solved in the mean time by something else) to catch multiple of these connection drops. Also add verbosity=8 to your /boot/armbianEnv.txt to catch as much data as possible.

Hi, could you try the following addition in the device tree? diff --git a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5.dtsi index 3bceee948458..e58d7e69e8e8 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-orangepi-5.dtsi @@ -273,9 +273,9 @@ es8388: audio-codec@11 { reg = <0x11>; /* On RK3588 (not RK3588S), MCLK output is gated and must use TO_IO variant */ clocks = <&cru I2S0_8CH_MCLKOUT_TO_IO>; - assigned-clocks = <&cru I2S0_8CH_MCLKOUT>; + assigned-clocks = <&cru I2S0_8CH_MCLKOUT_TO_IO>; assigned-clock-rates = <12288000>; AVDD-supply = <&vcc_3v3_s0>; DVDD-supply = <&vcc_1v8_s0>; If this doesn't work, try the following. daicpu: simple-audio-card,cpu { sound-dai = <&i2s0_8ch>; system-clock-frequency = <12288000>; + system-clock-direction-out; }; There isn't much information so its a bit of poking in the dark

Some sort of logs would be great, otherwise very hard to track down

Example for adding a new board with already existing board family: https://github.com/armbian/build/pull/9456/changes

Maybe. Trunk are untested auto-builds and support for this board is from the community. Its functionality is unknown to the Armbian team. Get serial console logs. This makes investigation way easier.