**** BEGIN LOGGING AT Sat Apr 03 02:59:57 2021 Apr 03 03:40:00 aparcar[m]: Thanks for the libelf/libdw update, Paul! I think there's nothing now stopping review/merge of https://github.com/openwrt/openwrt/pull/3855, correct? Apr 03 03:50:45 guidosarducci: the buildbots need to update first Apr 03 03:59:36 Build [#19](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/12/builds/19) of `oxnas/ox820` failed. Apr 03 04:02:32 Build [#20](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/60/builds/20) of `armvirt/64` failed. Apr 03 04:05:24 Build [#20](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/17/builds/20) of `ipq40xx/mikrotik` failed. Apr 03 04:08:21 Build [#19](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/49/builds/19) of `bcm53xx/generic` failed. Apr 03 04:11:53 Build [#19](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/46/builds/19) of `ath79/nand` failed. Apr 03 04:15:18 Build [#19](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/30/builds/19) of `x86/generic` failed. Apr 03 04:38:45 anyone know how to get the build system to use homebrew binaries instead of local ones? Apr 03 10:37:54 Hauke: I wonder if PHY auto polling might not work for some PHYs: https://brpaste.xyz/rVwaUA/raw - this is from a AR8030 RMII (10/100) PHY which has 1000Base-X and 1000Base-T in the extended status register (0xf). symptoms seen: the port seems completely deaf Apr 03 10:38:52 Hauke: the old driver was not using auto polling but configuring the PHY/MAC settings individually - so I wonder if that's something we should do as well. Doing that will probably also get us support for fixed-links at the same time without any extra code Apr 03 11:12:08 xdarklight: could you check the status registers of the auto polling Apr 03 11:12:11 for such a phy Apr 03 11:13:42 xdarklight: the diagramm "Auto Polling FSM - Main Loop" inducates that auto polling is deactivated when REG0 is 0xffff Apr 03 11:15:36 Hauke: that would be GSWIP_MAC_PSTATp(port) I assume? Apr 03 11:15:49 Hauke: (which is something like: (0x900 + ((p) * 0xC)) ) Apr 03 11:18:31 yes Apr 03 11:19:35 I was wrong it just stops the current loop when it reads 0xffff Apr 03 11:19:39 not the polling over all Apr 03 11:19:51 but GSWIP_MAC_PSTATp(port) is interesting Apr 03 11:24:20 I mean MMDIO_STAT_(port) Apr 03 11:26:31 I think there's different names for the same thing. in lantiq/target/linux/ltqcpe/files/include/switch_api/VR9_switch.h from the TD-W9980 UGW it's called VR9_MAC_PSTAT_* and has similar bits than MMDIO_STAT in the GSW140 datasheet Apr 03 11:26:43 ok Apr 03 11:27:58 I think AR8030 is detected as a gigabit phy Apr 03 11:29:09 at least when I do the same thing as described in the state machine of the PHY polling Apr 03 11:29:12 that's what I thank as well and I believe it's GSW's fault since BMSR_ESTATEN for the PHY is 0 (so I think it should not be trying to read reg15 / 0xf) Apr 03 11:29:58 what is BMSR_ESTATEN? Apr 03 11:30:51 https://elixir.bootlin.com/linux/v5.11.11/source/drivers/net/phy/phy_device.c#L2498 Apr 03 11:31:20 if set to 1 then the MII_ESTATUS register (reg15 / 0xf) is read and used Apr 03 11:32:57 thanks Apr 03 11:36:24 BMSR_ESTATEN is set to 1 in your paste Apr 03 11:36:39 REG1== 0x796d Apr 03 11:37:37 If BMSR_ESTATEN is set the polling assumes a GE PHY Apr 03 11:38:01 oops, your're right. I was off-by-one Apr 03 11:41:09 Hauke: so conclusion is: for some PHYs which are probably (slightly) out-of-spec we need to switch from auto polling to software configuration? Apr 03 12:03:40 xdarklight: this could be a solution Apr 03 12:03:47 at least for some values Apr 03 12:04:17 xdarklight: what is in the GSWIP_MAC_PSTATp register? Apr 03 12:05:06 Hauke: I'm waiting for the user to re-build and check for me. all of my devices are working fine, so that's why I need to wait Apr 03 12:05:34 ok Apr 03 12:11:41 how is the advertising result from the mii-tool calculated? Apr 03 12:12:03 I do not understand why it only shows 10 and 100 MBit/s Apr 03 12:14:27 Hauke: I *think* it's because of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/net/dsa/lantiq_gswip.c?id=3545454c7801e391b0d966f82c98614d45394770 Apr 03 12:15:47 Hauke: AFAIK phylink takes the info from the PHY and the MAC -> only what both have in common is considered supported. and there we don't advertise the Gbit/s modes on the MAC side, so I assume that's where they are filtered out Apr 03 12:20:11 xdarklight: I was just confused beacsue linux has defines the same bits multiple times in ADVERTISE_ Apr 03 12:21:55 heh, I never noticed these duplicates Apr 03 12:22:49 the AR8030 datashaeet says they are using the 10 and 100 MBit/s here Apr 03 12:26:15 xdarklight: I added this extra debug logging some time ago: https://git.kernel.org/linus/20d8bb0d172d87dcc52727cb7174ae9994de8978 Apr 03 12:26:37 this should be printed when MAC and PHY have no common settings Apr 03 12:27:21 xdarklight: what device shows this problem? Apr 03 12:28:22 Hauke: FritzBox 7360v2 is showing the problem on the two RMII ports (both are completely deaf: traffic sent by another device is not showing in ethtool -S at all and vice versa. checked also with tcpdump) Apr 03 12:34:02 does anybody know how to configure a bridge with the router ports using vlan filtering? each time i try something, either the bridge is not configuring the ports, or vlans, or lan ports are down... in the end I don't get a simple base config that stays when I reboot it Apr 03 12:37:41 xdarklight: I will just order one it is 20€ and I do not have a device with FE ports Apr 03 12:41:17 Hauke: jwh is not in this channel but he can probably provide you access to his Apr 03 12:41:49 Hauke: I already asked him to apply https://pastebin.com/iAubzkkq and show me the output of "ethtool -d lan4" (one of the non-working ports) Apr 03 12:43:32 xdarklight: ok lets wait for that Apr 03 12:43:49 I found the device for 17€ including shipping Apr 03 12:44:04 if you buy 4 you get a discount ;-) Apr 03 12:45:07 Hauke: I decided not to buy one since I already have too many devices... Apr 03 12:45:38 xdarklight: I am tring to get a remote controlled lab working Apr 03 12:45:43 with labgrid Apr 03 12:45:54 but I also hav a lot of devices here Apr 03 12:49:18 Hauke: nice. I bought an 8 port relay and stuffed some devices in the free areas of a PC case. then I'm using https://github.com/xdarklight/arduino_pdu_rly together with pdudaemon to control power to the boards Apr 03 12:49:35 Hauke: the relays are taking 5V or 12V from the PC' Apr 03 12:49:41 PC's power supply Apr 03 12:55:32 xdarklight: does a normal PC power suppy prove 5V and 12V without problems like some controlls from the PC? Apr 03 12:56:56 Hauke: so far I had zero problems with this but mostly I am running Amlogic SoC based boards in there which are typically designed to run off 5V 2A USB. 12V should be no problem at all because PC PSUs provide most power on the 12V rail(s) Apr 03 12:57:27 ok Apr 03 12:57:53 is there power just there when you switch on the PC power supply? Apr 03 12:58:18 it does not want to talk some special protocol with the PC mainboard Apr 03 12:59:28 Hauke: yes and no. you need to short two pins or get one of these ATX power supply breakout adapters which come with a power-on switch/button (which does just connects the two pins together) Apr 03 12:59:51 similar to this for example: https://www.amazon.com/Tangxi-Supply-Breakout-Adapter-Computer/dp/B07TV6GYTB (I don't have this one, just taking it as general example) Apr 03 13:03:14 thanks Apr 03 13:35:04 xdarklight: the xrx200 documentation says for MIIRATE: IN RMII mode, 50 MHz must always be selected Apr 03 13:36:00 for MII, TMII PHY and RGMII you can select Apr 03 13:38:17 Hauke: what can be selected for != RMII? Apr 03 13:44:12 xdarklight: please try this: https://brpaste.xyz/8jT6GQ/raw Apr 03 13:51:09 Hauke: jwh has not replied back on the debug registers yet (I think he's in a different timezone, somewhere across the pond from us). currently I am trying to fix what I believe is a reset GPIO problem for the IP101 RMII PHY on my O2 6431 Apr 03 13:59:54 xdrcould you try this: https://brpaste.xyz/4R1vUw/raw Apr 03 14:05:38 xdarklight: https://brpaste.xyz/wokfIw/raw Apr 03 14:46:10 Hauke: I still don't have any feedback from jwh. as soon as he replies I'll ask him to test it Apr 03 14:46:18 ok Apr 03 15:17:49 Hauke: first update from my HH5A: your patch doesn't break anything ;-) Apr 03 16:33:38 xdarklight: are there any other problems with the lantiq DSA driver except the problems with some external PHYs? Apr 03 16:47:16 Hauke: a) some 7412 user is reporting random disconnects b) fixed-links are not working yet but required for adding support on the Fritz 7490 (and others) c) RGMII RX/TX delays need to be configurable for Fritz 7490 (and others) support Apr 03 16:47:46 Hauke: a) is a bit strange because it's just the internal PHY22F. the others are "new features" so nothing that I am too worried about right now Apr 03 16:48:23 Hauke: also I got the debug registers from jwh on his 7360v2: https://brpaste.xyz/6qsruA/raw - that loks like it detected a Gbit/s connection. I'll ask him to apply your other patch now Apr 03 16:53:49 it's seeing 0x0d38 in the MAC_PSTAT register -> my understanding is: BIT(11) means that it detected the PHY, BIT(10) means that it thinks that there should be a Gbit/s link Apr 03 17:03:53 0x0d38: BIT(6): PHY status active, it looks like the PHY is not detecetd as active Apr 03 17:04:41 the rest looke like garbage, links is up, but speed is set to reserved Apr 03 17:05:40 Hauke: according to the TD-W9980 and Fritz 7490 source code BIT(6) is TXPAU (Transmit Pause Status) Apr 03 17:06:31 Hauke: maybe the bit meanings have changed between the xRX200/xRX300 GSWIP and GSWIP120/GSWIP140? Apr 03 17:06:50 BIT(9) and BIT(10) are not avalibale on xrx200 Apr 03 17:08:35 Hauke: weird. these are the offsets that I can see in the TD-W9980 and 7490 sources: https://github.com/paldier/d7000v2/blob/master/ugw/target/linux/x86/files/drivers/net/ethernet/lantiq/switch-api/ltq_flow_reg_switch.h#L2260 Apr 03 17:09:37 I am talking about this register: #define GSWIP_MDIO_STATp(p) (0x16 + (p)) Apr 03 17:10:34 ah, and I am talking about #define GSWIP_MAC_PSTATp(p) (0x900 + ((p) * 0xC)) Apr 03 17:10:52 ah sorry this is a diffeernt register Apr 03 17:12:30 let me add that to the debug output and check the values on my HH5A Apr 03 17:15:17 MAC_PSTAT: 0x0d38: 1GBit/s, phy active Apr 03 17:16:12 Hauke: yep, that's the one I meant earlier on. let me also check MDIO_STAT Apr 03 17:18:37 could you also read MAC_CTRL_(port) #define GSWIP_MAC_CTRL_2p(p) (0x905 + ((p) * 0xC)) Apr 03 17:19:33 no Apr 03 17:19:34 #define GSWIP_MAC_CTRL_0p(p) (0x903 + ((p) * 0xC)) Apr 03 17:20:12 these two I am already reading Apr 03 17:20:47 what is the value of GSWIP_MAC_CTRL_0p of for the RMII port? Apr 03 17:20:59 GSWIP_MAC_CTRL_0p = 0x0180 and GSWIP_MAC_CTRL_2p = 0x005 Apr 03 17:22:27 I'd say that the value for GSWIP_MAC_CTRL_0p looks appropriate: everything on AUTO, FCS enable and PADEN enabled (same as the old out-of-tree driver configured) Apr 03 17:22:28 looks good, speed is set to auto Apr 03 17:32:43 xdarklight: makeing it possible to configure the RGMII RX and TX delay is not hard Apr 03 17:32:46 I can add it Apr 03 17:33:42 the problem with the 7412 looks strange to me too Apr 03 17:36:26 Hauke: if the GSW120/140 documentation is also valid for xRX200/xRX300 then indeed it's easy to implement the GSWIP driver bits. but I am not sure if that is something which should come through gswip_phylink_mac_config (in struct phylink_link_state) or if the driver needs to parse the .dts itself and then do it's own magic Apr 03 17:37:08 xdarklight: yes the part is the same Apr 03 17:37:46 I think we have to parse this manually, when I grepped to code it looks like we haev to parse the dtb manually Apr 03 17:42:55 Hauke: for the existing code you are right but I think this is something that will be added to phylink sooner or later. but I'm not sure about the plans for the phylink maintainers Apr 03 17:45:01 yes Apr 03 17:46:27 xdarklight: is there already a discussion? Apr 03 17:46:39 Hauke: I haven't checked Apr 03 17:49:58 where can I find some documentation on procd_open_validate/procd_close_validate/procd_add_validation ? I don't seem to find any commits regarding it. Apr 03 19:55:06 Hauke: the user with issues on the 7412 gave an update (with a workaround) for his issue: https://github.com/openwrt/openwrt/pull/3085#issuecomment-812847728 Apr 03 20:10:04 xdarklight: hmm still strange Apr 03 20:10:17 but it could be a similar problem Apr 03 20:10:29 like the otehr FE PHY problem Apr 03 21:36:19 hurricos: hey, i have a P2041RDB on the way. hopefully it works. i will test out https://github.com/openwrt/openwrt/pull/3731 to start. Apr 03 22:18:02 Hauke: hmm, I'd be surprised if it's related to the 7360v2 problem because there two external RMII PHYs are involved, whereas 7412 uses the internal PHY22F GPHY Apr 04 01:01:27 Does anyone know where uci_load_validate() is defined at? Apr 04 01:01:52 I can't find it in include or scripts, I'm not sure where else to check Apr 04 01:07:49 Build [#18](https://buildbot.openwrt.org/openwrt-21.02/images/#builders/29/builds/18) of `mpc85xx/p1010` completed successfully. Apr 04 01:20:35 Grommish: https://github.com/openwrt/openwrt/blob/master/package/system/procd/files/procd.sh#L539-L554 Apr 04 01:21:10 Package/xxxx/postinst reads like it's going to be run after the ipk is installed on the device, but it tries to run it at build. Just use a uci_defaults file? Apr 04 01:21:55 m4t: Thank you! Apr 04 01:22:23 Oo.. and ot sets the local for me Apr 04 01:22:27 Just appreciated **** ENDING LOGGING AT Sun Apr 04 03:00:03 2021