Werner

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.

Feel free to use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ./compile.sh BOARD=nanopineoplus2notsurehowitsnameis BRANCH=current kernel-config and then build a kernel packages with the adjustments. Once installed and tested, you can PR to these kernel config here: https://github.com/armbian/build/tree/main/config/kernel

I suggest to ask directly at kali forums/chat/whatever they provide. We offer Armbian images with Kali tools pre-installed. However about their usage we cannot help

moved to staging

The max clock is most likely limited via opp table in the dts. H6 should clock up to 1.8ghz, yes, but there might be a reason why this board does not.

Hi, this might be prohibited until you made a few manually approved posting to be moved from Validating to Members group. This measure is necessary to keep the forum clean from spamers who try to spread their bs here on daily basis. So I suggest to stick around for a while, this should resolve itself.

Module name is "ip_tables"

logs are incomplete. dmesg is missing completely which would be the most relevant. moved to staging

https://github.com/armbian/build/blob/b8eab09ef561f2d03956098d26351d323a3b2d7b/config/kernel/linux-meson64-current.config#L355 Check your /lib/modules directory if it is present. It should be.

Why would you use an image for the Zero 3 for the 5B? You cannot simply shove an image for a random board into yours and assume it works...

just tested with a clean image, featuring 6.18.y and works just fine. This may be an issue if your setup is quite old, because at some point upstream changes caused Armbian kernel to break IIRC and this was worked around. The warning is persistent but doesn't actually matter. Please verify that a clean system boots normally.

hard to tell without any logs whatsoever

[ 5.092655] CPU1: failed to come online [ 5.092666] CPU1: failed in unknown state : 0x0 [ 10.217311] CPU2: failed to come online [ 10.217324] CPU2: failed in unknown state : 0x0 [ 15.341948] CPU3: failed to come online [ 15.341961] CPU3: failed in unknown state : 0x0 Yes we're aware of this, since it affects all H5 and H6 devices. We have a few ideas about what could be the cause like added logging (yes, sounds odd but..oh well) or certain ATF version. https://github.com/armbian/build/issues/9555

moved to off-topic since not directly related to armbian.

seems like openwrt already figured this and the fix is actually upstream: https://github.com/torvalds/linux/commit/c3fe7071e196e25789ecf90dbc9e8491a98884d7 (also see https://github.com/immortalwrt/immortalwrt/commit/7ef19bb9cd59f5018fc96b01a5465ed84038cfe8) This may tell that one or more Armbian patches make things worse , no clue though which one if any.

moved

Another attempt, again check https://testing.armbian.de/r4s/?C=M&O=D for most recent debs. This time adding an artificial bus scan delay into the r4s dts. Another poke in the dark but perhaps...

See inline comments. Dirty SPI may cause this but without logs from serial console this is just a guess

Hm. Well. Im out of ideas. Perhaps openwrt will find something when they're going to work on 6.18. Unmarked the old solution for now since it no longer applies.

https://testing.armbian.de/r4s/?C=M&O=D Check for the more recent files. This has a different attempt to fix it by reverting some stuff to be more like 6.12

While waiting for new info, first poke in the dark. rk3399-fix-pci-phy.patch disabled https://testing.armbian.de/r4s/ feel free to test

Perhaps a hardware defect? At least that would be my guess from what it sounds.