**** BEGIN LOGGING AT Fri Jun 28 02:59:57 2019 Jun 28 06:26:11 hey Jun 28 06:26:21 jow: is there something like PROVIDES for host packages? Jun 28 06:26:27 i'm trying to avoid: WARNING: Makefile 'package/feeds/luci/luci/Makefile' has a build dependency on 'lua/host', which does not exist Jun 28 06:26:41 it's after renaming lua to lua51 Jun 28 06:32:29 rmilecki: I don't think so Jun 28 07:29:37 i pushed some lua patches, let's see it anything blows up Jun 28 07:29:51 i didn't push rename yet Jun 28 07:32:50 :) Jun 28 07:36:39 xback: https://pastebin.com/wHJCuQqZ - this *is* an improvement in that my macbook doesn't need to turn wifi off/on to get back on the network. Jun 28 07:39:31 I noticed that we're on a Busybox version now which is recent enough to include our nslookup_lede applet upstream Jun 28 07:39:57 so we can theoretically drop our patches and switch from nslookup_lede to nslookup_big in busybox Jun 28 07:40:18 \o/ Jun 28 07:42:40 jow seems to be humble, he also took care of fixing upstream nslookup to handle RR/SRV corner cases ;) Jun 28 07:43:15 isn't he always? :) Jun 28 07:56:28 xback: actually no it isn't an improvement - just broken mrs ldir's iphone. Jun 28 07:56:51 xback: I wonder if the last ath10k-ct firmware bump should be reverted. Jun 28 08:13:42 slaps jokingly slaps rmilecki with a trout for breaking builds on macOS with his lua update Jun 28 08:14:10 ldir: really? Jun 28 08:14:14 how... Jun 28 08:14:21 I'll pastebin Jun 28 08:15:11 https://pastebin.com/LvJmPG9u Jun 28 08:16:04 i'd say it may require some magic make */clean Jun 28 08:16:53 * ldir does a make clean Jun 28 08:26:43 ldir: you may try: find build_dir/hostpkg/lua-5.1.5/src/ -executable Jun 28 08:27:02 you should have there lua5.1 and luac5.1 Jun 28 08:30:59 ok, will look once I have latest errors.... Jun 28 08:33:01 I have lua & luac, not lua5.1 or luac5.1 Jun 28 08:34:29 ldir: can you pastebin a complete output of following commands, please? Jun 28 08:34:32 make package/utils/lua/host/clean V=s Jun 28 08:34:35 make package/utils/lua/host/compile V=s Jun 28 08:34:45 {clean,compile} would work too probably Jun 28 08:40:44 * ldir eyes his macbook suspiciously - the error appears to have gone away. Hmmmmmm. Jun 28 08:41:45 what's the difference between say 'make package/utils/lua/host/clean' and 'make package/lua/host/clean' ? Jun 28 08:41:52 that's weird... in my commit i bumped PKG_RELEASE to make sure OpenWrt/buildroot recompiles the package Jun 28 08:42:03 ldir: none I believe Jun 28 08:42:09 i just always use full path Jun 28 08:42:34 that's what I thought... just checking. Hmmm. Jun 28 08:42:48 let's see if I get to the end of the build :-) Jun 28 08:43:00 jow: KanjiMonster: any idea why changing PKG_RELEASE from 3 to 4 didn't trigger host package recompilation for ldir? Jun 28 08:43:05 he needed a manual make package/utils/lua/host/clean V=s Jun 28 08:43:42 rmilecki: buildroot bug I guess Jun 28 08:43:48 a perfectly valid response is "because ldir is weird' :-) Jun 28 08:44:00 i'd blame buildroot first ;) Jun 28 08:45:06 lol - is 'make clean' supposed to clean hostpkg ? Jun 28 08:45:42 it doesn't clean everything I believe Jun 28 08:45:53 there is one more powerful ;) it's "dirclear" I think Jun 28 08:45:58 or was that "realclean"? Jun 28 08:46:23 dirclean Jun 28 08:46:43 does (nearly) everything, including the toolchain Jun 28 08:47:10 it does do the menuconfig stuff lurking in scripts as I occasionally fall over and remind myself on a annual basis Jun 28 08:47:16 doesn't do Jun 28 08:47:47 :P Jun 28 08:50:08 does a make clean and rm -rf build_dir/hostpkg / nuke from orbit just to be sure & make -j4 Jun 28 08:52:59 at $some_point I'll finally get around to looking at solving building linux k4.19 on macOS - currently have an awful hack to make sure HAVE_STACK_VALIDATION is forced off. Jun 28 08:54:27 oh dear - it failed again. Jun 28 08:54:52 what the hell :| Jun 28 08:55:22 ldir: what about those binaries? are they there? find build_dir/hostpkg/lua-5.1.5/src/ -executable Jun 28 08:58:27 They are! Jun 28 08:59:03 I wonder if this is a 'parallel build' issue Jun 28 09:01:01 nope = https://pastebin.com/sDWmyY33 Jun 28 09:02:37 gfind build_dir/hostpkg/lua-5.1.5/src/ -executable Jun 28 09:02:39 build_dir/hostpkg/lua-5.1.5/src/ Jun 28 09:02:39 build_dir/hostpkg/lua-5.1.5/src/luac Jun 28 09:02:39 build_dir/hostpkg/lua-5.1.5/src/lua Jun 28 09:03:25 oops - anyway if it *really* is looking for lua5.1 & luac5.1 then it's right, they don't exist. Jun 28 09:04:01 cd src && install -p -m 0755 lua5.1 luac5.1 /Users/kevin/wrt/staging_dir/hostpkg/bin Jun 28 09:05:27 ldir: for you make executes: Jun 28 09:05:28 cd src && install -p -m 0755 lua5.1 luac5.1 $(OPENWRT)/staging_dir/hostpkg/bin Jun 28 09:05:38 for me its: Jun 28 09:05:39 cd src && install -p -m 0755 lua luac $(OPENWRT)/staging_dir/hostpkg/bin Jun 28 09:06:30 oh, nevermind Jun 28 09:06:36 i'm in wrong directory now... Jun 28 09:06:43 let me try again Jun 28 09:07:39 now I think about it... lua's Makefile has different code for MacOS Jun 28 09:07:44 maybe that's a problem Jun 28 09:07:51 maybe I didn't update lua's Makefile properly Jun 28 09:09:38 Sadly I have work to do now so can't focus on this at the moment, hopefully a bit later Jun 28 09:37:25 heisenbug make package/utils/lua/host/{clean,compile} fails. make package/utils/lua/host/{clean,compile} V=s works. Jun 28 09:39:06 ldir: just a sec, i have a patch to try Jun 28 09:39:07 commiting it now Jun 28 09:39:12 (not pushing) Jun 28 09:41:20 ldir: can you try my patch? Jun 28 09:41:26 (e-mailed) Jun 28 09:42:21 https://patchwork.ozlabs.org/patch/1124073/ Jun 28 09:44:12 will do - just a sec - family crisis Jun 28 09:44:24 sure Jun 28 09:56:29 confirm fixed! Jun 28 09:57:21 oh, great, thanks! Jun 28 09:58:02 I have no idea how you worked that out. Jun 28 09:58:34 i checked what part of Makefile is responsivle for the version suffix Jun 28 09:58:38 and then I cheated Jun 28 09:58:41 lol Jun 28 09:58:45 and I checked distributions patches Jun 28 09:58:59 https://build.opensuse.org/package/view_file/openSUSE:Factory/lua51/lua-build-system.patch?expand=1 ;) Jun 28 09:59:48 that's not cheating, that's using your skills wisely :-) Jun 28 10:00:07 :) Jun 28 10:07:59 ldir: you may sit back down now Jun 28 10:11:23 blogic: you'll need to explain that one. Jun 28 10:12:05 you stood up in class for a comment with out raising your hand ;) Jun 28 10:12:33 lol Jun 28 10:12:39 ;) ;) Jun 28 10:18:37 Get super soaker and target the teacher Jun 28 13:03:22 would appreciate if someone could take a look at https://github.com/openwrt/openwrt/pull/2156 Jun 28 13:03:30 seems it'd be a good thing to have working for 19.07 Jun 28 14:31:55 my device's uboot tells me there are two gpio pins 5G_RF_ON_OFF and 2G_RF_ON_OFF Jun 28 14:32:16 i tried toggling them but that didn't seem to have any effect on the wireless radio Jun 28 16:00:06 are they inputs from switches? Jun 28 16:00:35 as opposed to outputs for enabling/disabling the RF device ? Jun 28 16:22:39 ldir: i tried, but i couldn't get their value to change either Jun 28 18:38:46 hi there Jun 28 18:39:54 Hauke, please review github.com/openwrt/openwrt/pull/2178 Jun 28 18:47:20 Trying to debug a (missing) `- config restore -` issue -- Is `[ 12.463249] jffs2_scan_eraseblock(): End of filesystem marker found at 0x10000` coming from `mount_root` or somewhere else? Jun 28 18:48:16 it's the jffs2 code in the kernel Jun 28 18:49:44 OK, thanks -- will dig in there -- trying to figure out why it's "late" with one kernel compared to another Jun 28 18:50:37 (~30 seconds later with the one that doesn't work) Jun 28 18:51:17 the problem is far more likely in your image generation code Jun 28 18:52:18 what target is this? Jun 28 18:54:48 WIP on GL-AR300M/-AR750S with NAND-aware kernel -- I can see `Appending jffs2 data from /tmp/sysupgrade.tgz to firmware..` and hexdump seems to show it sitting there on NOR, but it's not being seen when 80_mount_root runs Jun 28 18:55:30 does the device have nand, or nor? Jun 28 18:55:47 Call is to `default_do_upgrade` Jun 28 18:55:51 Both Jun 28 18:56:11 Dual-firmware device Jun 28 18:56:29 it boots from either-or? Jun 28 18:56:35 Can boot NOR or NAND, yes Jun 28 18:58:07 "Pure NOR" kernel is OK; adding CONFIG_MTD_stuff and CONFIG_UBI_FS_stuff seems to "break" detection of /sysupgrade.tgz in init/early procd Jun 28 18:58:53 Knowing its in the kernel at least gives me a place to look Jun 28 19:01:32 jeffsf: https://github.com/openwrt/openwrt/blob/master/target/linux/generic/pending-4.19/532-jffs2_eofdetect.patch Jun 28 19:01:45 oh, i see: the stock fw has the kernel on nor and the rootfs on nand Jun 28 19:02:43 AR-300M has two, independent, can boot kernel from NOR or from NAND; AR750S U-Boot presently always boots NOR-resident kernel, then mounts root from NOR or NAND depending on how built. Jun 28 19:03:28 i was looking at ar750s Jun 28 19:03:48 for ar750s, nand could be an extroot Jun 28 19:03:50 "Silly me" wanting to be able to have NOR-based as a "safety" the same way that dual-NAND firmware can be used on a Linksys Jun 28 19:04:24 I've got the NAND versions working well and the couple of drivers needed through, or mainly through Linux-MTD Jun 28 19:04:48 ar300m could do the linksys thing, but it'll take some hacking Jun 28 19:04:59 ;) "done" Jun 28 19:06:00 Even have the ability to flash NOR from NAND and vice versa -- just this "minor" detail of /sysupgrade.tgz on the NOR boot Jun 28 19:06:51 I've got the "pure NOR" code running too, so I can start moving over kernel config and see if that triggers the failure Jun 28 19:07:24 I'll also look at the on-media format for JFFS2 and confirm that it is being written properly Jun 28 19:08:39 (though I haven't touched `mtd -j /tmp/sysupgrade.tgz - ${PART_NAME}` at all) Jun 28 19:11:22 jeffsf: does it do proper bad block management, or does it just load the kernel raw from nand and hopes bits never flip (or rather never more than one)? Jun 28 19:12:22 I'm assuming/hoping that the U-Boot handles bad-block management for the kernel Jun 28 19:12:38 I haven't (yet) dug into the source code yet. Jun 28 19:13:10 does it cp.b when loading the kernel, or does it mount some kind of filesystem or ubi to load the kernel from? Jun 28 19:13:59 Qualcomm Atheros SPI NAND Driver, Version 0.1 (c) 2014 Qualcomm Atheros Inc. Jun 28 19:14:07 does a bad-block check Jun 28 19:14:22 that's not what I'm talking about Jun 28 19:14:27 Still looking Jun 28 19:14:51 the bootcmd for loading the kernel from nand should tell you Jun 28 19:15:21 One of these days I'm gonna get smart and make the timeout longer than 2 seconds in U-Boot Jun 28 19:19:13 bootm 0x9f050000 Jun 28 19:19:31 Nothing in U-Boot environment to make it clear what `bootm` is Jun 28 19:21:51 so I'm assuming it's "stock" U-Boot bootm, so at the mercy of bad blocks Jun 28 19:22:28 jeffsf: this was ath79? then 0x9f050000 is the memory mapped nor flash; not nand Jun 28 19:22:54 Ah Jun 28 19:23:40 nboot 0x81000000 is the other branch Jun 28 19:24:33 bootcmd=if nand bad; then nboot 0x81000000 0 || run blf # which leads to bootm 0x9f050000 Jun 28 19:26:04 so the nboot command then is what's interesting Jun 28 19:26:14 So it branches on "nand bad" then tries nboot, if it fails tries mboot; or tries mboot directly Jun 28 19:27:02 Seems like it, yes -- haven't dug into U-Boot source yet Jun 28 19:28:21 "if nand bad" still twisting in my mind, perhaps just because my head wants to interpret a "true" response there as "tested the nand and it was bad" Jun 28 19:29:50 `Bank # 1: The hell do you want flinfo for??` Jun 28 19:30:05 LOL Jun 28 19:30:57 `nand bad - show bad blocks` -- OK, so it *is* backwards when used as a logical test Jun 28 19:35:46 The SPI NAND (Paragon or GigaDevice) will correct up to 8 bit-flips, so not so bad Jun 28 19:36:04 (up through 8) Jun 28 19:56:49 ynezz: Thanks for pulling 2165 Jun 28 21:48:20 mangix: I updated my mac80211 branch, the tar.gz file is now also uploaded Jun 28 22:19:50 What does this message mean? "The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header." Jun 28 22:21:29 it means email is a shitstorm Jun 28 22:21:44 lmao!! Jun 28 22:22:01 I'd like to think the message is relatively self explantory though? Jun 28 22:22:03 Well, at least we have a lot of nitrates.... Jun 28 22:22:04 Funkiness / feature of mail authentication -- since the sender's domain "signs" all its outgoing messages, they can just be resent by another domain (like a mail reflector) Jun 28 22:22:26 I mean, ignore the acronymn you don't know, just go, "there's a policy" then read the next line which says what has been done ot the message. Jun 28 22:22:37 I need better vision -- two days of missing #!/bin.sh Jun 28 22:23:30 karlp: not in the slightest. I sent an email to two lists and 4 other individual addresses. It attached the message. Did everybody in the list get it in that form? Jun 28 22:23:49 jeffsf: what's wrong with #1/bin/sh? Jun 28 22:23:53 if you're the sender, then yes. Jun 28 22:23:59 that's what I end up typing Jun 28 22:24:04 dansan look carefully Jun 28 22:24:23 jeffsf: yeah, it was a joke. I usually end up with #1 instead of #! Jun 28 22:24:27 LOL, yeah Jun 28 22:24:31 ;D Jun 28 22:24:34 I just saw that -- FU2 Jun 28 22:24:39 lmao!!! Jun 28 22:24:55 perfect response!! Jun 28 22:25:35 I'm really starting to not like MediaTek. What do you have to do to get datasheets out of these people? Jun 28 22:25:53 Same thing as Qualcomm -- NDA and $$$$ Jun 28 22:26:05 wow Jun 28 22:26:15 Trust me, I'd love to have an IPQ4019 data sheet Jun 28 22:26:54 blogic: Hey, do you know anything about all of the magic registers inited in mt7620_hw_init? Jun 28 22:28:16 I don't suppose Felix or Micheal Lee are hanging out in here are they? Jun 28 22:28:34 "State Accepted" -- woo hoo! Jun 28 22:28:54 Time to get this tree cleaned up and a PR Jun 28 22:29:27 ndb: Hey Felix. Do you know anything about all those magic registers touched in mt7620_hw_init? Jun 28 22:34:47 nbd: ^ Jun 29 00:03:37 Hate when you rebase and lose a logical commit Jun 29 00:04:18 it's likely still somewhere in your local repo Jun 29 00:04:37 Yes, I've got the un-munged branch, but... Jun 29 00:43:20 dansan: I guess those are just copied from SDK code. Jun 29 00:45:58 dansan: As for datasheet... Leaked ones can be found with Google but it mentions nothing about those registers. Jun 29 00:51:43 gch981213: well I've yet to find a "programming guide" specifically for the mt7530, which *should* be the ethernet switch inside the mt7620. I have found an "approval datasheet", wtf ever that is, but it doesn't document any registers. Of course, the mt7620 programming guide doesn't mention these aside from claiming that 0x7800 to 0x7fc is WAPI PN table (WAPI being the Chinese security standard that ieee rejected) Jun 29 00:51:53 oh, btw, which SDK code? :) Jun 29 00:52:50 i did see a leaked mt7530 sheet but it wasn't terribly useful Jun 29 00:53:10 the "Approval Datasheet"? Jun 29 00:53:36 i don't recall the title, but it was for a discrete mt7530 chip Jun 29 00:53:46 I dread the idea of having to do an NDA with these guys :( So hopefully I can figure it out another way Jun 29 00:53:49 ok Jun 29 00:54:22 you're not likely to be able to Jun 29 00:54:28 why is that? Jun 29 00:54:51 I've never had to work this closely with a Tiwanese company before Jun 29 00:55:04 they only deal with manufacturers, and even they don't get full sheets, apparently Jun 29 00:55:10 *Taiwanese Jun 29 00:55:31 Well I'm actually doing this for a manufacturer, global satellite engineering Jun 29 00:56:11 ordering directly from mtk? Jun 29 00:56:19 Actually, GSE hires another company to make the boards Jun 29 00:56:23 So indirectly Jun 29 00:56:38 tenuous Jun 29 00:56:44 Maybe I should try that company, but they are Taiwanese too and they don't respond to requests in a very timely manner, lol! Jun 29 00:57:23 I'm starting to wonder if we would be better using some ARM µC, but I guess the value of Mediatek is how much you get on a single chip for the price Jun 29 00:57:25 "Epoch -- Noun -- The time that elapses between a GPL request and getting accurate, buildable code" Jun 29 00:57:38 lol! Jun 29 00:57:52 jeffsf: nice! Jun 29 00:58:13 jeffsf: Is mediatek violating gpl? Jun 29 00:59:02 Unlikely Jun 29 00:59:03 I thought they only made the chips Jun 29 01:00:42 jeffsf: i think it was noted somewhere that they are Jun 29 01:00:50 eew Jun 29 01:01:05 maybe not Jun 29 01:01:42 Hadn't heard/read that myself -- more a comment on how quickly many companies respond to requests for information Jun 29 01:02:00 mtk does arm too, btw Jun 29 01:02:12 e.g. mt7623 Jun 29 01:02:50 Well I'm just a programmer, so I don't control much on the board designs. But if it's this hard to get the information needed to fix drivers and such then the cost of that starts to add up. Jun 29 01:04:05 I was mostly thinking of other manufacturers who better support their hardware. I'm also not touching anything Microchip after experiencing their support. I couldn't even get a silicone errata report made because the poor "engineer" couldn't figure out how to reproduce the problem. Jun 29 01:04:36 that was on the mpc2210, very crappy product Jun 29 01:19:34 dansan: Their openwrt sdk. Extract the kernel under /dl and this piece of code can be found in /driver/net/raeth/raether.c : https://paste.ubuntu.com/p/CNm5fZ7GmJ/ Jun 29 01:20:46 gch981213: oh my! Jun 29 01:21:17 compare that to the driver in openwrt Jun 29 01:21:30 Well I remember a lot of it, I can see the similarities Jun 29 01:21:36 but this has more comments! Jun 29 01:21:57 slightly Jun 29 01:22:08 I see a patch coming to comments soon :) Jun 29 01:22:25 gch981213: Thank you! This answers much mystery! Jun 29 01:23:30 gch981213: do you know what the original location of their openwrt sdk was? Jun 29 01:26:56 hmm, the rt5350 datasheet has more functional information than the mt7620 datasheet. I presume much of this is the same hardware. Jun 29 01:33:12 dansan: Ah... They put these things on MTK DCC where you'll get an account if you sign a NDA with them. Jun 29 01:33:26 ahhhhh!!! Jun 29 01:33:35 I see, thank you! Jun 29 01:35:12 dansan: Found the same piece of code here: https://bitbucket.org/padavan/rt-n56u/src/master/trunk/linux-3.4.x/drivers/net/raeth/ra_esw_mt7620.c Jun 29 01:35:45 Thank you! <3 Jun 29 01:36:54 this project even has MTK's proprietary wireless drivers in it. Not sure how it lasts so long without getting taken down. Jun 29 01:37:12 interesting Jun 29 01:37:51 nabbing it while I have the chance! Jun 29 01:39:07 https://github.com/openwrt/openwrt/blob/master/target/linux/ramips/files-4.14/drivers/net/ethernet/mediatek/gsw_mt7620.c#L127 Jun 29 01:40:53 Yeah, I've been hacking away in this file for the last 3 or 4 weeks :) Jun 29 01:41:05 So many sins in the design of this driver :( Jun 29 01:41:11 Oh well, I have to go eat Jun 29 01:41:38 And the sad part is that all of the swconfig stuff is deprecated now. I have a lot of improvments for it, but it's only until DSA is done in the mainline Jun 29 01:41:49 but I have to make it work Jun 29 01:41:52 bbl!! Jun 29 01:41:57 and thanks again for the help here! **** ENDING LOGGING AT Sat Jun 29 02:59:57 2019