c0rnelius

@twwn Add to rk3566-radxa-zero-3.dtsi --> snps,usb2-lpm-disable; https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.12/dt/rk3566-radxa-zero-3.dtsi#L495 &usb_host0_xhci { dr_mode = "peripheral"; + snps,usb2-lpm-disable; status = "okay"; }; See if it makes a difference. Information: https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/dwc3.txt

Ur welcome.

Try this overlay /dts-v1/; /plugin/; / { fragment@0 { target = <&ehci0>; __overlay__ { status = "okay"; }; }; fragment@1 { target = <&ohci0>; __overlay__ { status = "okay"; }; }; fragment@2 { target = <&usbotg>; __overlay__ { dr_mode = "host"; }; }; }; sunxi-usb-host-mode.dts

Ok. So I think what I am getting out of this, is you are trying to use the designated PWR / OTG port as a HOST port. I'm not sure that is possible? I would need to investigate. Also I would be interested in knowing what ur u-boot log looks like powering it with that Waveshare.

@Samor140 I think, I'm missing a piece of the puzzle. I built a fresh Armbian IMG and I'm getting the same results as before. So maybe I don't understand exactly what you are trying to do? Which USB-C port are you trying to use here?

@Samor140 I just ran a basic test with a little hand held wireless keyboard+mouse combo and I can't replicate this. lsusb Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 006 Device 002: ID 0413:0308 Leadtek Research, Inc. Bus 007 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub cat /proc/device-tree/soc/usb*/dr_mode; echo host I made some recent changes to the DTS, but I doubt that would be the issue here. Plus I've never heard anyone complain about it before. Could always see if there is a kernel update available or try the EDGE kernel. Most of the recent work I've been doing is related to EDGE "Bluetooth" and U-Boot. What are you powering the unit with? I haven't seen issue with this unit, but on other h618's I have had USB issues when not using a proper PSU.

@-jk- Yeah.... Well I've seen that before. Download, extract and put the debs you need on either a usb stick or sdcard. You can install with `sudo dpkg -i *.deb` Reboot and that should put you back to where you were. From there if you want functional BT, try the edge kernel. https://github.com/pyavitz/binary/releases/download/images/linux-image-current-sunxi64.zip EDIT: I attached the "Fix?" to this PR: https://github.com/armbian/build/pull/8454

Nice work. Looks good.

@-jk- Try the latest stable `edge` kernel.

I also have a personal preference. I don't like my fans just spinning to spin. I prefer them to trigger under heavy load and then cut off once that load has passed. You are more than welcome though, to make adjustments to it and submit them via PR.

That is exactly what it does. It would take a lot more work to make it gradually speed up, if it even could be done? Hence why I wrote it simply. The one I linked is the one you are using.

It is set to kick on at 55*C. You can review the dtso in the patch dir; https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.12/overlay/meson-g12-pwm-gpiox-5-fan.dtso

Brave browser supports arm64 and has a "New private window with Tor" option. Might be worth checking out.

Have you tried the meson-g12-pwm-gpiox-5-fan overlay?

For sure, no. It's a S905X5M https://www.hardkernel.com/shop/odroid-c5/ The C4 is a S905X3

HOST /dts-v1/; /plugin/; / { fragment@0 { target = <&usbotg>; __overlay__ { dr_mode = "host"; }; }; }; OTG /dts-v1/; /plugin/; / { fragment@0 { target = <&usbotg>; __overlay__ { dr_mode = "otg"; }; }; }; By default it is set to peripheral.

Chromium is not the best for playing videos. Try mplayer or mpv or something alike. I doubt you'll get great performance beyond 720p though. Might not even get it in some cases with 720p? If I wanna use an SBC as a media player, I either use LibreELEC or CoreELEC and don't use Alllwinner, but Amlogic. Good luck.

The DRM / GPU patches are from mainline. I'm sure there are or will be some updates, hacks and tweaks that eventually come down the road. But that's beyond the scope of bringing up the board.

@ScoreABSM https://github.com/armbian/build/pull/8394 I enabled gpu via overlay. Looking fine on my end. Tested using Chromium and Youtube. Still not sure about that audio dmesg error. Audio does work though. Image I ran test with: https://github.com/pyavitz/binary/releases/download/images/Armbian-unofficial_25.08.0-trunk_Bananapim4zero_bookworm_current_6.12.35_xfce_desktop.img.xz dmesgandmisc.txt

@ScoreABSM I have no clue what the HDMI audio errors are in the dmesg. I noticed them before as well. I know mainline doesn't actually have HDMI audio support yet. I'm not sure where these HDMI audio patches originated, but I assume the OrangePI repo. Of course, I could just be doing something wrong here on a DTS level? Strange your getting chanspec errors. This was resolved on my end by updating the wireless-regdb. You can try resolving it with this: "Put in your COUNTRYCODE" extraargs=cfg80211.ieee80211_regdom=US or this echo "options cfg80211 ieee80211_regdom=US" > /etc/modprobe.d/cfg80211.conf I'll disable the gpu by default. No. I don't see how removing those RTC patches would be creating these errors. The chanspec one is well known. Also happens on RPI's. I have a HACK patch that disables the error, but thats not really a fix. When I ran tests with the GPU before I never saw those errors and that GPU patch was pulled from mainline. I believe? Pretty sure it is the same patch I use in my personal builds. II'll say this. This is becoming endless. I'm getting ready to toss this SBC in the garbage

@ScoreABSM https://github.com/pyavitz/binary/releases/download/images/Armbian-unofficial_25.08.0-trunk_Bananapim4zero_trixie_current_6.12.35.img.xz

You could attempt to recover ur current install by adding the required DTB to the SDCARD and see if the unit boots. Once booted, mount the eMMC and again copy the DTB to the required dir. DTB DIR: /boot/dtb/rockchip/ rk3566-nanopi-r3s-lts.dtb

According to ur log. It's pulling down an older kernel. This kernel does not have the DTB required so it's failing to boot. After purging the kernel on the current IMG available and installing the kernel from apt. https://paste.armbian.com/orokufexik The result is a missing DTB. root@nanopi-r3s-lts:~# ls /boot/dtb/rockchip/rk3566-nanopi-* /boot/dtb/rockchip/rk3566-nanopi-r3s.dtb

Yeah it applies. [🔨] ├───────────────────────────┼─────────────────────┼───────────────── [🔨] │ REVERT-clk-meson-g12a-Fix │ (+6/-6)[1M] g12a.c │ Martijn van Deve [🔨] │ -kernel-warnings-when-no- │ │ clk: meson: g12a [🔨] │ display-attached │ │ kernel warnings [🔨] │ │ │ display attached [🔨] ├───────────────────────────┼─────────────────────┼─────────────────

I've seen this HDMI issue on some SM1 units, "TV Boxes". There is a REVERT floating around which resolves it, but was not accepted. https://lore.kernel.org/linux-arm-kernel/001401db8ed4$392ef030$ab8cd090$@martijnvandeventer.nl/T/ I've been currently using it on 6.12.y. I have no clue if the current STABLE kernel also has this problem. REVERT-clk-meson-g12a-Fix-kernel-warnings-when-no-display-attached.patch