**** BEGIN LOGGING AT Tue Apr 07 02:59:57 2020 Apr 07 03:30:33 Hauke: thanks so much!! Apr 07 03:30:39 DonkeyHotei: yeah, was guessing something like that Apr 07 04:38:36 Hauke: so in the end, I guess my ethernet ports are connected to external GPHYs. I can see that even from vendorsource code, and some GPIOs are speciried in there. How may i arrange that in the DTS? I end up in linux-4.19.108/drivers/net/phy/phy_device.c - line 1645 where master/slave resolution fails. Apr 07 04:51:43 OMG - I am mentioned in the wiki for Archer D2... guys, we should get this thing up and running... Apr 07 04:53:51 downloading Archer D2 stuff Apr 07 05:23:32 oh... pretty old Apr 07 06:26:50 mkresin: ping Apr 07 08:14:49 5.4.30 kernel bump just landed my staging tree Apr 07 08:14:56 s/my/in my/ Apr 07 09:06:18 gch981213: ok, I saw the mail from Andre Valentin about problems with mt7621 5.4 port... I didn't expect problems with qmi-wwan itself Apr 07 09:08:13 LTE modems should be in usb-only mini pcie slots or things like that, do you think still the new / updated PCI driver may influence? Apr 07 09:17:28 Rene__: gch981213: mangix: PaulFertser: blogic: can someone give me a short summary of mtk_nand (upstream), mtk_nand2 (downstream) and what efforts have been made recently on that topic? Apr 07 09:18:59 rmilecki: We are currently using this driver: https://patchwork.ozlabs.org/patch/1264889/ Apr 07 09:19:30 Weijie Gao from MTK was bored last week and wrote this driver using latest kernel nand APIs last weekend. Apr 07 09:19:46 wow, it sounds great Apr 07 09:20:23 so I understand it can replace our unmaintanable mtd_nand2.c from OpenWrt Apr 07 09:21:33 upstream mtk_nand is currently using legacy APIs and has no support for mt7621. This new driver was rejected by upstream because upstream think it should be merged with existing mtk_nand and Weijie has no interest in rewriting it again. Apr 07 09:22:17 rmilecki: Correct. At least this new one has way clear code. Apr 07 09:22:56 that still imrpoves things for us, great Apr 07 09:25:47 but it's a pity Apr 07 09:28:00 mrkiko: Whay LTE problem were you talking about a moment ago? LTE modems goes through USB2.0 and it shouldn't be affected by upstream PCIE driver. Apr 07 09:28:07 *what Apr 07 09:31:49 gch981213: http://lists.infradead.org/pipermail/openwrt-devel/2020-April/022670.html this kernel trace Apr 07 09:34:29 mrkiko: probably some ports are using the internal and some ports are using an external phy Apr 07 09:40:57 ynezz: 5.4.30 for what target? Apr 07 09:45:37 aparcar[m]: it doesn't work that way. bump to 5.4.30 means *every* target that has support for 5.4 is now on 5.4.30 Apr 07 09:47:45 oh okay Apr 07 10:03:41 gch981213: oh, so hackpascal works now at MTK? Apr 07 10:06:22 * karlp tears hair out why things don't work, discover was missing source tree override in the config :) Apr 07 10:12:51 PaulFertser: thanks Apr 07 10:13:04 Hauke: yes... Apr 07 10:13:22 Hauke: EVA is able to talk over gigabit, don't know if it does also over the FE ports; Apr 07 10:13:31 Hauke: but I am kinda stuck ... Apr 07 10:14:30 Hauke: i am looking around for similar devices but ... I would need guidance to focus ona specific part of the system. Currently I am running out of ideas Apr 07 10:22:35 ynezz: Yes. In fact you could find his sign-off in many upstream u-boot commits on mediatek router soc Apr 07 10:33:44 Is that the author of Breed proprietary bootloader? Apr 07 10:39:45 gch981213: to merge the two drivers, you would need basically to rewrite the in-kernel mtk_nand to port it to new APIs, and then add mt7621 support... Apr 07 10:39:55 PaulFertser: yes he is Apr 07 10:40:24 mrkiko: easier said that done :P Apr 07 10:41:01 mangix: haha, that kinda resonates with the bootloader "discussion" yesterday. Apr 07 10:44:37 what was the discussion over? Apr 07 10:47:01 mangix: mediatek being able but not willing to make their bootloaders and probably some other essential code under GPLv3 to prevent tivoization. Some people claim that it's not up to MTK to have any influence over. Apr 07 10:48:47 There's an ATF partition on mt7622 now. It seems that some nasty vendors asked mediatek to roll their android secureboot thing on routers. Apr 07 10:48:59 o_O Apr 07 10:50:39 PaulFertser: if android is anything to go by, that's an outdated idea. Apr 07 10:51:22 vendors are very interested in locked bootloaders Apr 07 10:51:36 Luckily Banana Pi makes open-source mt7622 development boards and we could still have fun with this powerful SoC Apr 07 10:53:03 * mangix googles Apr 07 10:54:18 wonder what sata controller that is Apr 07 10:55:16 in any case, I have no idea what I'd do with that Apr 07 10:57:09 board looks neat Apr 07 10:57:29 * mangix would not use OpenWrt on it Apr 07 10:57:30 and MT7615 WiFi by default :) Apr 07 10:58:03 although I'd probably need to... Apr 07 11:01:36 aliexpress calls it a MocroSD slot. lol. Apr 07 11:02:26 Sounds like "WetSD" in russian :) Apr 07 11:04:07 LOL. Didn't think of that Apr 07 11:04:31 similar in Bulgarian, but did not think of that either Apr 07 11:05:02 stintel: it's the same. Apr 07 11:07:33 in dutch 'mocro' is a derogatory shortened form of 'moroccan' Apr 07 11:15:37 gch981213: I have a VLAN patch from Mediatek, not really sure what type of VLAN issue it fixed but maybe it is useful and related with your latest email. https://github.com/vDorst/linux-1/commit/fd1a8c99b2670d778e05b1302f819720c7af2516. Apr 07 11:32:21 Rene__: He does not need to create a separate bridge for vlan 20, frames with vlan tags should pass through the bridge as-is when vlan_filtering is disabled. Apr 07 11:59:19 build #258 of layerscape/armv7 is complete: Success [build successful] Build details are at http://buildbot.openwrt.org/master/images/builders/layerscape%2Farmv7/builds/258 Apr 07 11:59:34 ok Apr 07 12:06:46 mangix, gch981213: yeah, sorry guys, it was meant to be a question ... Apr 07 13:18:35 https://lore.kernel.org/netdev/E1jEB0y-0006iF-5g@rmk-PC.armlinux.org.uk/ Apr 07 13:19:10 mrkiko: is there required to rewrite to new API before adding more chipsets support? I don't think it may be the case Apr 07 13:21:39 Rene__: Currently, set vlan_filtering to 1 immediately blocks all traffic in the bridge. With this patch, the 2 if statements removed, and "ds->vlan_bridge_vtu = 1;" in mt7530_setup(), it is fixed Apr 07 13:22:30 rmilecki: of course you're right, I was thinking it may a good idea to do so just to avoid the pain of doing it later... Apr 07 13:22:45 oh, sure, that would be nice Apr 07 13:23:53 rmilecki: I was taking a look at the new driver and try to grasp the basics of it... the new driver seems pretty clean and self-contained ... to say. Apr 07 13:24:21 anyway I don't have the hardware to test this - the boards I have with mtk nand have no serial console access Apr 07 13:27:06 mrkiko: i'd love to look at it, but probably won't have enough time anytime soon Apr 07 13:28:10 if I am able to get something that compiles, will you be a reviewer ? :D :D Apr 07 13:29:15 dengqf6: great Apr 07 13:29:56 Rene__: I saw your SFP pull request; very nice! So with that device you're able to connect to fiber in an allopenwrt solution, right? I know very little about SFP Apr 07 13:33:13 gch981213: oh - i see mediatek mt7622 nand driver in upstream supports PM ops!! What atou MT7621 here? Apr 07 13:35:55 Rene__: GPIO base number in 5.4 has changed, have you taken a look at /sys/kernel/debug/gpio and /etc/board.d/03_gpio_switches of your ER-X-SFP? Apr 07 13:36:25 mrkiko: All it does is gating clocks if I remember correctly. Apr 07 13:36:55 mrkiko: And we need a clock driver for mt7621 for that purpose. Apr 07 13:38:58 gch981213: so for the moment being I should find a way to "dn nothing" when device is mt7621 Apr 07 13:40:07 mrkiko: Just supply a fixed clock for it in device-tree and it will be doing nothing :) Apr 07 13:47:55 ynezz: before I send out a v2 for my config update patch with the pre-built C files, should I resend my huge text in the cover page, or is a changelog enough? Apr 07 13:49:48 cotequeiroz: changelog should be enough Apr 07 13:51:10 gch981213: thanks, I will try it out. maybe i can understand more than Lantiq ar10 :D Apr 07 14:03:18 dengqf6: not yet, but I shall fix those POE gpio Apr 07 14:10:07 mrkiko: yes you can. Apr 07 14:14:35 * ldir lol - oh dear - I've really, really, really, bricked my ancient Asus 1015BX netbook thing. BIOS replacement gone bad. Apr 07 14:28:34 ldir: sounds like a new doorstop. Apr 07 14:29:57 Rene__: I tried using gmac1 as wan port on newifi d1 bit it didn't work. The link was up but no rx packets. Apr 07 14:30:31 *but Apr 07 14:31:17 f00b4r0: it is, well it could probably be recovered by removing the bios chip and doing lots of clever things but quite frankly it isn't worth the bother. Apr 07 14:36:26 dengqf6: did you remove "rgmii2" in the default gpio mode node? Apr 07 14:37:33 Rene__: https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/dts/mt7621_lenovo_newifi-d1.dts Apr 07 14:37:52 Only jtag and uart2 Apr 07 14:40:14 Is your dts look like this example? https://github.com/torvalds/linux/blob/81160dda9a7aad13c04e78bb2cfd3c4630e3afab/Documentation/devicetree/bindings/net/dsa/mt7530.txt#L134 Apr 07 14:42:47 Rene__: yes Apr 07 14:44:19 is in the switch0 node, port4 disable or removed? Apr 07 14:45:21 removed (disabled by default in dtsi) Apr 07 14:46:24 are RGMII2 (GPIO 22-33) not used / connected to anything? Apr 07 14:49:17 Rene__: dts diff: https://pastebin.com/FLfhDU8V Apr 07 14:50:46 I remember using Padavan on newifi d1 and checking vlan table, port 5 and 4 is in vlan 2 (wan) so it can be used Apr 07 14:56:11 dengqf6: dts look good. Apr 07 14:56:53 do you have a util to look in the registers? like 'io Apr 07 14:57:28 do you have a util to look in the registers? like 'io' or 'devmem2'? Apr 07 14:59:24 you can readout register 0x1e000060, bit 15 should be 0 Apr 07 15:00:07 Rene: Do I need to add "pinctrl-0" to gmac1 node? Apr 07 15:01:55 I never used that. Normally remove "rgmii2" from the default_state is enough. Apr 07 15:08:58 this gives a bit more information, I think: cat /sys/kernel/debug/pinctrl/pinctrl-rt2880-pinmux/pinmux-pins Apr 07 15:12:45 You can enable this debug to see if the driver sets port 5 correctly. https://github.com/torvalds/linux/blob/master/drivers/net/dsa/mt7530.c#L687 Apr 07 15:18:38 Rene__: blogic: I think the best solution is connect port5 to 2nd gmac (P5_INTF_SEL_GMAC5), and use it as 2nd CPU port in DSA Apr 07 15:24:12 in /sys/kernel/debug/pinctrl/pinctrl-rt2880-pinmux/pinmux-pins Apr 07 15:24:25 GPIO 22~33 are unclaimed Apr 07 15:28:00 dengqf6: It is a nice option. Apr 07 15:28:13 Feels to me that RGMII2 pins are still in GPIO mode. Apr 07 15:30:32 If you have a util to modify registers, than you can set bit 15 to zero in register 0x1e000060 Apr 07 15:31:40 then try fixing the DTS so RGMII2 is set in the right modes. Apr 07 15:31:50 Rene__: Tried with: pinctrl-names = "default"; pinctrl-0 = <&rgmii2_pins>; in gmac1 node, still nothing Apr 07 15:34:47 dengqf6: ok, I have to go. I hope you can find the issue. bye Apr 07 15:56:49 is it just me, or does package/boot/uboot-sunxi (and probably other uboot-xxx) not respect the git-src symlinks to a u-boot git repo? Apr 07 15:59:31 karlp: that could be possible, e.g. when the Build/Prepare recipe is overridden Apr 07 16:03:17 Rene__: I ended up adding a separate rgmii2 node in &state_default and it worked Apr 07 16:28:30 dengqf6: great! Apr 07 16:29:26 Rene__: so why does pinctrl-0 not work? Apr 07 16:32:31 don't know, dts stuff is still a bit magic for me Apr 07 16:32:42 Rene__: you're not alone Apr 07 16:33:13 Are devices with supported SFP rare in general? Apr 07 16:33:27 Rene__: thanks for the reply Apr 07 16:35:41 Rene__: I remember blogic has mt7530 DSA multi CPU ports patch Apr 07 16:40:51 mrkiko: thwr Apr 07 16:41:18 mrkiko: there are not that many Apr 07 16:41:29 dengqf6: yup Apr 07 16:48:22 dengqf6: this not the patch but based on that on https://patchwork.kernel.org/patch/10724573/ Apr 07 17:09:13 Rene__: turns out I should add that in ðernet node Apr 07 17:21:20 ðernet { Apr 07 17:21:21 pinctrl-names = "default"; Apr 07 17:21:21 pinctrl-0 = <&rgmii1_pins &rgmii2_pins &mdio_pins>; Apr 07 17:21:21 }; Apr 07 17:21:47 Rene__: I think rgmii1_pins and mdio_pins should be added to mt7621.dtdi Apr 07 17:21:51 *dtsi Apr 07 17:49:35 ynezz: your 5.4.30 bump running ok on my apu2 Apr 07 17:55:23 yep, 5.4.30 is fine on ipq806x and ipq40xx as well Apr 07 18:13:12 snapshot x64 squashfs efi (w/o efi bios) Apr 07 18:13:13 7.952433] Can't allocate a compression stream[ 7.953249] zram: Cannot initialise lzo-rle compressing backend Apr 07 18:13:53 lzo-rle appears to be a new thing in linux 5.1 Apr 07 18:55:57 dengqf6: I will note thay at least 2 devices have a WAN port that currently does not work (connected to 2nd GMAC). Apr 07 18:56:20 not that they ever have. But it shoild be possible witb DSA Apr 07 19:05:48 guys how does the buildroot's mirror logic work? Apr 07 19:06:27 lately i am just looking at make waiting for ages on curl to pull something from a dog slow mirror (i'm in europe and curl wants to grab gcc 9.3 from a Canadian mirror...) Apr 07 19:11:01 Borromini: do you mind testing my patch that uses a CDN which is fairly fast everywhere? Apr 07 19:11:22 it uses sources.cdn.openwrt.org as first mirror Apr 07 19:11:30 aparcar[m]: i don't, bring it. Apr 07 19:11:43 https://patchwork.ozlabs.org/patch/1266827/ Apr 07 19:11:46 just let me know how i should check if it's working :D Apr 07 19:12:35 Well run something like make package/gcc/{clean,compile} Apr 07 19:12:48 and remove dl/gcc* before Apr 07 19:13:02 this should re download the sources and should work much faster Apr 07 19:14:09 sure, will keep you posted Apr 07 19:16:43 Borromini: thanks Apr 07 19:17:39 happy to help Apr 07 19:18:18 dito Apr 07 19:18:50 aparcar[m]: i just need to apply the patch and rerun make clean/compile right; no need to fiddle with make menuconfig or anything else? Apr 07 19:19:10 no it's all automagic Apr 07 19:19:19 lovely. Apr 07 19:24:36 aparcar[m]: thanks a lot. i ran a make on gcc, it wanted binutils and even that it wouldn't pull in from that Canadian mirror. Apr 07 19:24:49 just a few seconds with the CDN patch :) Apr 07 19:25:22 jow: a happy CDN user more, please consider a merge :) Apr 07 19:25:32 weeee Apr 07 19:25:56 applied it to my 19.07 tree as well :) Apr 07 19:31:30 mangix: which devices? Apr 07 23:15:36 mangix: Is transmission working for you with enabled seccomp in 19.07? Apr 07 23:40:48 Is Imre sometimes here at the IRC? Apr 08 00:00:53 aparcar[m]: [Tue 2020-04-07 05:00:10 PM PDT] * [Kaloz] idle 52:11:07, signon: Sun Apr 5 12:49:05 Apr 08 00:01:01 from /whois Apr 08 00:34:42 DonkeyHotei: thank you Apr 08 00:37:46 yw Apr 08 01:47:20 Pepe: I don't use seccomp. @dangole did all of that work. Apr 08 01:47:53 Rene__: MQMaker WiTi and GnuBee PC2 Apr 08 01:48:32 the latter was made to work by NeilBrown, but it seems he never upstreamed his patches. Apr 08 01:50:27 Pepe: this fixes it: https://github.com/openwrt/packages/commit/3724ed3d6888705c64cb38f8f66aad5486d192ae#diff-02cda4ca9f4cfa879a9f0d9e452ab356 **** ENDING LOGGING AT Wed Apr 08 03:00:04 2020