08:11 <warpme> guys: i'm adding support for rk3576 in my appliance. 6.15 mainline seems well supporting this soc (with some patches i got sd, usb, eth, hdmi, audio, gpu) working well. I'm trying now with Detlev vdpu383 decoder code but with this board hangs. So now i want to: first cleanup boot without vdpu383 then try vdpu383 again. So - when cleaning boot - in dmesg have issue with rockchchip-pm-domain like this: https://termbin.com/grqq I'm not sure how to

08:11 <warpme> fix this. Any hints here?

11:37 <mmind00> macromorgan: detlevc has done that back in 2024: https://lore.kernel.org/dri-devel/20241115162120.83990-1-detlev.casanova@collabora.com/

11:37 <mmind00> macromorgan: if I interpret past mails correctly, we're hanging on https://lore.kernel.org/dri-devel/3346283.VqM8IeB0Os@diego/

13:03 <CounterPillow> >Debian GNU/Linux 13 fratti-rock2a ttyS0

13:03 <CounterPillow> there we go, that was surprisingly easy once I found the right patches \o/

13:47 <CounterPillow> does anyone have the RK3528 TRM?

14:21 <macromorgan> okay cool, thanks Heiko

14:24 <CounterPillow> Kwiboo: ok, hwrng driver on rk3528 will need some adjustments. Right now half the trng registers it's reading are 0. I'll need to look into whether that's something we can enumerate in hardware or whether the driver needs to handle the new DT compatible. reg 0x0, 0x4, 0x8 and 0xc all read as 0 for me at the moment so if there's some hardware config stuff stored there I can't get at it seemingly, but that may be clock/power related

14:24 <CounterPillow> maybe?

15:08 <user21> hi, questions on getting the network to work on the rk3888, kernel is 6.14 CONFIG_PHYLIB=y

15:08 <user21> CONFIG_DWMAC_ROCKCHIP=y

15:08 <user21> CONFIG_REALTEK_PHY=y

15:08 <user21> CONFIG_DWMAC_GENERIC=y

15:08 <user21> CONFIG_NET_VENDOR_REALTEK=y

15:08 <user21> CONFIG_WLAN_VENDOR_REALTEK=y

15:11 <user21> the device tree is identified with https://github.com/Ken-Vamrs/kernel/blob/linux-5.10-gen-rkr3.4-zaku/arch/arm64/boot/dts/rockchip/rk3588-zaku2.dts#L132

15:11 <phh> rk3888 is fire *_*

15:12 <qschulz> user21: port the device tree to 6.14 for starters

15:12 <user21> I see the eth0 interface but there it refuses to get configured with dhclient

15:12 <qschulz> make it pass the CHECK_DTBS=y check

15:12 <user21> I did

15:12 <user21> ah 1 sec

15:30 <user21> I do see this in the dmesg: "rk_gmac-dwmac fe1c0000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0"

15:30 <user21> and the eth0 shows in the list, but how do I tell what is missing ?

15:31 <user21> the driver seems to be "rtl8211fs", suspecting this one is in the kernel already

15:42 <qschulz> user21: what's providing the clock to the PHY? if it's coming from a pin on the SoC, you may be missing some pinctrl maybe (we have eth0_pins on Jaguar for example_

15:42 <qschulz> then check also which driver is supposed to match the ID of your PHY and make sure it's built

15:43 <qschulz> check also your reset gpio for the PHY is muxed into a GPIO and not something else

15:43 <user21> I got this in the dmesg: "rk_gmac-dwmac fe1c0000.ethernet eth0: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=POLL)"

15:44 <user21> let check the gpio stuff

15:44 <qschulz> seems reasonable then

15:44 <qschulz> do you get a link at least?

15:45 <qschulz> (see LEDs and or whatever ip-utils/ethtool reports)

15:45 <qschulz> could be an issue with the RGMII delays for example

15:55 <user21> it says eth0 is up

15:55 <qschulz> is there a link :)

15:55 <user21> but when it refuses to get an IP

15:55 <qschulz> the network interface being up != the ethernet PHY having a link

15:55 <user21> ah, sorry, how do I check ?

15:56 <user21> and how to do I check for some diagnostics for reasons why

15:56 <qschulz> unplug and replug the cable, is there some event in the kernel output?

15:56 <qschulz> do you have an LED on your Ethernet connector showing link status maybe?

15:57 <qschulz> (could be that it shows only after speed negociation happened so not sure)

15:57 <user21> 1 sec

15:58 <qschulz> [ 23.775579] rk_gmac-dwmac fe1b0000.ethernet end0: Link is Down

15:58 <qschulz> is what I get when I remove my ethernet cable

15:58 <qschulz> end0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000

15:58 <qschulz> end0 (eth0) is UP but the link is DOWN

15:59 <qschulz> (output of ip addr show end0)

15:59 <qschulz> (also NO-CARRIER is probably relevant there)

15:59 <qschulz> [ 98.528100] rk_gmac-dwmac fe1b0000.ethernet end0: Link is Up - 1Gbps/Full - flow control off

15:59 <qschulz> when plugging in

15:59 <qschulz> end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000

15:59 <qschulz> when connected

16:04 <user21> need to reboot and flash a new image

16:31 <user21> I guess there is no signal like that for me, the back plane is a custom one and has hot pluggable ethernet

16:37 <user21> this how it looks like https://snipboard.io/yA54FB.jpg

16:38 <user21> but eth0 won't get an ip

16:38 <user21> I'm missing something

16:51 <robmur01> looks the phy thinks it doesn't have anything connected (NO-CARRIER)

16:56 <user21> you are right, tried also to config it manually, and seems link is down, @qschulz suspicion is true also https://snipboard.io/Ohru04.jpg

16:57 <user21> seems like the network is not powered ? bad device tree setup ?

16:59 <robmur01> if you've specified a phy interrupt, check the GPIO/polarity/pinctrl is correct (I'd first try removing it to force polling and see if it detects the link then)

16:59 <user21> ok let me check

17:19 <user21> I'm still checking, but learning at the same time

17:19 <user21> I got the network part from this device tree https://github.com/Ken-Vamrs/kernel/blob/linux-5.10-gen-rkr3.4-zaku/arch/arm64/boot/dts/rockchip/rk3588-zaku2.dts#L131

17:20 <user21> that device tree file is the one running for current board on 5.10 kernel, I moved it to 6.14, but need the get the network working again

17:20 <user21> in theory I need the whole file, but I want to isolate the exact parts I need for the network, driver, power delivery, buses etc

17:21 <user21> I tried to drop-in the whole file, but was a bad idea, so now trying in steps

17:26 <user21> I was told the driver must be rtl8211fs , but not sure if this needs some kernel config flags as well

17:27 <CounterPillow> rtl8211fs should be covered by the realtek phy config you've already enabled

17:30 <CounterPillow> mainline device tree bindings will differ from what vendor kernels use, so it's probably easiest to reference what other device trees in mainline with the same combination of SoC and ethernet PHY did. ODROID M2 for example uses an RTL8211F which is probably pin-compatible

17:32 <robmur01> bleh, I should have paid more attention - it already says "irq=POLL", so never mind that then

17:50 <user21> got it thank you, checking my DT for any power delivery issues

19:16 <user21> ok so on a working system after the "rk_gmac-dwmac fe1c0000.ethernet eth0: configuring for phy/rgmii link mode" I get a message "rk_gmac-dwmac fe1c0000.ethernet eth0: Link is Up - Unknown/Unknown - flow control off"

19:16 <user21> and the network card is usable

19:16 <user21> on the system that does not work there is nothing after "rk_gmac-dwmac fe1c0000.ethernet eth0: configuring for phy/rgmii link mode"

19:17 <user21> basically seems like the interface is not responsive

19:28 <user21> https://snipboard.io/CewOPc.jpg

22:56 <TahomaSoft> Got the LinkStar H68K (rk3568) running on all eight cylinders (4 eth + 1 wifi +3 USB).

22:57 <TahomaSoft> Links and stuff at https://forum.openwrt.org/t/wip-support-for-linkstar-h68k-rk3568/233527

22:57 <TahomaSoft> Am working towards integrating into mainline Openwrt and then submit kernel patches.

22:59 <CounterPillow> \o/

23:02 <TahomaSoft> Indeed! Thank you CounterPillow!