**** BEGIN LOGGING AT Fri Jul 05 02:59:56 2019 Jul 05 04:46:31 mangix: pong Jul 05 04:46:55 anon^_^: better graphing... if someone builds it. I don't think I'll have time for that in the forseeable future Jul 05 04:47:27 so why latest mt76 changes not in 04 Jul 05 04:55:12 jow i think tomato is gpl2 Jul 05 04:55:37 not sure how difficult it would be to port code Jul 05 04:56:15 mt76 evolve a lot since 2019-03-23 Jul 05 05:01:49 anon^_^: would require time too. If someone ports it and integrates into luci Jul 05 05:02:12 however luci is apache/mit license, not sure how much gplv2 in there would taint it Jul 05 05:02:14 yeah, i'm nowhere qualified to take on that project Jul 05 05:02:20 what qualifies as linking etc. Jul 05 05:02:37 pretty sad too, nice ui, dead project Jul 05 05:04:11 ds_shadof: I think the answer is because nbd decided not to :) Jul 05 05:06:35 waited 04 for mt76 recent stuff and now it 4 month behind Jul 05 05:06:39 yeah doesn't look like the ui is under gpl2 Jul 05 05:06:44 so much for that idea Jul 05 05:07:49 jow, may be he just forgot Jul 05 05:07:56 I think he's busy Jul 05 05:08:09 ds_shadof: I see no reason to not bump mt76 for 18.06.5 Jul 05 05:08:17 someone has to test it though Jul 05 07:21:28 jow: now that i've backed out the tx skb alignment patches, mt76 master should be compatible to the 18.06 branch again Jul 05 07:21:45 so we can do a full update next timer Jul 05 07:23:12 nbd: ah great - so it should be as simple as compile testing and updating the hash? Jul 05 07:23:27 better update the full makefile (to get the mt7615 driver over as well) Jul 05 07:25:11 in wait state again :) Jul 05 10:24:30 what is the difference between openwrt and dd-wrt? why don't they merge? Jul 05 10:40:48 aparcar[m]: different licensing models, different code bases, different mindsets Jul 05 10:45:27 jow: very diplomatic Jul 05 10:50:48 :) Jul 05 10:51:21 blogic: :D Jul 05 11:07:49 something else very diplomatic https://github.com/openwrt/packages/pull/9399 Jul 05 11:46:23 aparcar[m]: thanks for taking care of that Jul 05 11:47:12 net/ or routing/ jow ? Jul 05 11:49:49 net/ Jul 05 11:49:55 personally I'd rather go for net, the distinction would be artifical and of historical use only down the road Jul 05 11:50:01 +1 Jul 05 11:50:10 +1 Jul 05 11:50:17 if you introduce routing then only when reorganizing other packages as well Jul 05 11:50:28 which is outside of the merge scope I'd say Jul 05 11:53:24 nbd: I think something is wrong in the latest mt76 Jul 05 11:53:30 nt/ramdisk/koen/firmware/builds/xback/build_dir/target-arm_mpcore+vfp_musl_eabi/linux-cns3xxx/mt76-2019-06-25-d680ab01/mt7603/mac.c: In function 'mt7603_fill_txs': Jul 05 11:53:31 /mnt/ramdisk/koen/firmware/builds/xback/build_dir/target-arm_mpcore+vfp_musl_eabi/linux-cns3xxx/mt76-2019-06-25-d680ab01/mt7603/mac.c:1001:17: error: implicit declaration of function 'ACCESS_ONCE'; did you mean 'READ_ONCE'? [-Werror=implicit-function-declaration] Jul 05 11:53:33 rate_set_tsf = ACCESS_ONCE(sta->rate_set_tsf); Jul 05 11:53:34 ^~~~~~~~~~~ Jul 05 11:53:36 READ_ONCE Jul 05 11:53:37 cc1: all warnings being treated as errors Jul 05 11:54:53 I think we will need reorganization of other packages as well when you would like to move nearly all packages from openwrt repo to packages repo Jul 05 11:58:31 who said that? :) Jul 05 11:59:15 from my point of view it's just a few packages, not "nearly all" Jul 05 12:07:42 so stick with the PR? Jul 05 12:08:33 However, it will be good if we can have a conversation about it only in one place than on two. Because not many people are actually on the IRC. Jul 05 12:10:24 I'll discuss on GitHub then Jul 05 12:11:53 aparcar[m] what about the email list? Jul 05 12:12:15 I don't know witch would be best for you. Jul 05 12:12:25 may be both? Jul 05 12:12:55 Third place, nice. :-D Jul 05 12:16:30 I'll write a quicke note on the mailing list... Jul 05 12:16:45 blogic: didn't you propose an annouce list? (not related) Jul 05 12:27:05 Tapper: mail send, let's see how they like it Jul 05 12:50:57 xback: the mt76 error is related to a change which happend between k4.14 and k4.19 Jul 05 12:56:51 xback, for this error I make this dirty patch : https://github.com/Ysurac/openmptcprouter/raw/master/root/package/kernel/mt76/patches/access_once.patch Jul 05 13:44:14 Anyone got an idea where ath79 pll values are derived from? https://git.openwrt.org/?p=openwrt/openwrt.git;a=blob;f=target/linux/ar71xx/files/arch/mips/ath79/mach-rb922.c;h=1c1cae1e7632ea2636cf10b2ad405ff963d56115;hb=HEAD#l322 Jul 05 13:45:33 xback: that's not the latest mt76 :) Jul 05 13:45:42 the latest is 2019-07-04 Jul 05 13:48:03 nbd: ah .. just noticed you bumped 19 hours Jul 05 13:48:08 will rebase my staging and try again Jul 05 13:51:09 xback: dump those values from factory firmware/u-boot or try if values from a similar router works :) Jul 05 13:52:07 gch981213: I dumped the values from all partitions on a working & supported mikrotik device, but can't find this bitpattern match Jul 05 13:54:31 xback: Ah... That's in driver code. by saying "dump" I mean using some tool to read the register values. Jul 05 13:56:41 e.g. force ethernet link to 10m/100m/1000m, start a tftp request in u-boot, terminate it, and use md command to read 0xb805002c (This is xMII configuration reg address for ar9344) Jul 05 13:57:35 the device is running routerboot as bootloader :( Jul 05 13:58:20 then initramfs with io Jul 05 13:59:14 io -4 0x1805002c Jul 05 13:59:48 (or devmem2) Jul 05 14:00:04 with ethernet init disabled in boardfile? Jul 05 14:00:04 io is in packages feed Jul 05 14:00:32 xback: You can just try values from other routers using the same SoC and switch/PHY. It usually works. Jul 05 14:00:46 gch981213: I did, and it does work Jul 05 14:01:00 but once or twice a day, the device stops TX Jul 05 14:01:02 ehrm, yeah, good point, you need to dump it under RouterOS which is quite hard Jul 05 14:01:28 tcpdump over uart shows received packets, and the device tries to send them back .. but they dont arrive Jul 05 14:01:31 so TX seems stuck Jul 05 14:01:32 you can simply dump the regs from the kernel before reset Jul 05 14:01:41 if they're set correctly in the bootloader Jul 05 14:02:07 also, I've found the ar9344 datasheet containing all registers and found the eth control register Jul 05 14:02:34 the values seems to match up for tx/rx delay, but the bits dont seems to match logically for gbe operation Jul 05 14:03:25 I found an ealier commit altering these PLL values and point to that specific register name, but the bits don't match logically Jul 05 14:06:21 nbd: confirmed that this compile issue does not happen in the latest state (2019-07-04). thanks Jul 05 17:47:24 jow: still around? Jul 05 20:40:08 just got target/linux/mediatek/* updates to v4.19 + new switch drivers from MTK Jul 05 20:40:30 and *drumroll* they actaully upstream the whole flipping lot, incl DRM/video foo Jul 05 20:40:48 * blogic pads MTK/WCN on the back for their great upstream work Jul 05 20:41:40 Cool! Jul 05 20:41:41 s/mediatek/ramips/ ? :p Jul 05 20:46:33 ynezz: i would expect that some, but not all, upstreaming of target/linux/mediatek/* may be adapted to target/linux/ramips/* Jul 05 20:58:17 ynezz: ramips is ralink, which was bought by MediaTek and turned into the BU WirelessConnectivityNetworking (MTK/WCN) Jul 05 20:58:41 and this is for the 32bit(mt7623) and 64bit (mt7622) ARM silicon Jul 05 20:59:03 and the new MT7531 switch fabric for which they built a swconfig driver Jul 05 20:59:16 and its all on the banana PI64R Jul 05 20:59:36 so you can run a bpi64r with wifi and video on full uostream code since v4.19 Jul 05 20:59:50 ... well the mt7531 driver and 8 (?) patches are pending Jul 05 21:00:00 but the other ~200 patches went upstream Jul 05 21:01:14 I am a bit disappointed, the mt7623 used the mtk-net ethernet driver which i spent 4 months on to get uopstream, inc the hw flow table offload and now they switched to DW/stmac for mt7622+ Jul 05 21:01:27 so that work was essentially for the bucket Jul 05 21:02:19 DonkeyHotei: next to none i would say Jul 05 21:02:59 DonkeyHotei: most of the legacy IP cores were replaced over the years Jul 05 21:03:00 some of the existing drivers are eerily similar Jul 05 21:03:16 mt7621 was the first MTK silicon that did the IP transition Jul 05 21:03:36 mt7623 then only shared the ethernet with legacy ramips IP Jul 05 21:03:47 and since mt7622 its all different to ramips Jul 05 21:04:33 so mt7621 might benefit a little but none of the other ramips will Jul 05 21:07:14 well, shame on me, I wasn't aware about this mediatek target Jul 05 21:07:49 on the other hand and to defend myself, I don't remember any recent contribution to this target :p Jul 05 21:08:04 also mt7530 driver works on both mt7621 and mt7623 Jul 05 21:08:09 ynezz: my bad, I was busy with foo Jul 05 21:08:17 Rene__: and mt7620 Jul 05 21:09:41 the transition really began with mt76x8 Jul 05 21:10:51 DonkeyHotei: no it did not Jul 05 21:10:58 mt7620 Jul 05 21:11:10 mt76x8 is actaully a special case in this whole thing Jul 05 21:11:21 specially with the MoM version for RTOS Jul 05 21:11:56 I sended an RFC for adding PHYLINK and port 5 support for MT7530 driver. https://patchwork.ozlabs.org/patch/1121368/ Jul 05 21:12:14 Rene__: saw that Jul 05 21:12:27 mt76x8 is like pieces of mt7620 shoehorned into an old ramips chip Jul 05 21:14:54 DonkeyHotei: yes, it is special Jul 05 21:15:02 Also working on the ethernet driver so it used PHYLINK. But writing a driver for hardware I don't own is not easy. Jul 05 21:15:22 Rene__: what HW is required ? Jul 05 21:15:35 SGMII part is what I can't test Jul 05 21:15:36 i have the ubnt mt7621 with sfp here, i can mail it to you Jul 05 21:15:58 I also have that device Jul 05 21:16:11 SFP port is working on that one. Jul 05 21:16:36 I even can disable SFP so port 0/4 can talk to 2nd GMAC Jul 05 21:17:16 I mis MT7623 and MT76xx with SGMII port. Jul 05 21:19:08 I currently rely on a guy how tests my code, he has a bpi-R2 and the first bpi-r64 Jul 05 21:38:48 does mt76x8 also have mt7530 switch inside? Jul 06 00:06:45 Rene__: No. mt76x8 uses switch/ethernet IP in rt305x/rt5350. mt7530 is made by econet, not ralink. Jul 06 00:25:47 Rene__, blogic, are you saying I should be able to gget second gmac working on Mediatek AP-MT7621A-V60 EVB ? **** ENDING LOGGING AT Sat Jul 06 02:59:56 2019