**** BEGIN LOGGING AT Wed Mar 06 02:59:57 2019 Mar 06 03:48:03 gch981213: any experience with breed for QCA devices? Mar 06 03:57:35 question, any specific reason why 4.19.x isn't the kernel version for x86_64? Mar 06 04:00:03 uberushaximus: why do you want 4.19? Mar 06 04:00:28 the actual answer is that there has been limited testing Mar 06 04:02:58 cool, I built 4.19 for x86_64 and it seems ok insofar Mar 06 04:03:08 was curious if there was a specific reason to hold it back Mar 06 04:03:58 I suspected it was related to something of that nature Mar 06 04:04:24 i believe the plan is to ship the next version with everything on 4.14 Mar 06 04:05:09 In my experience, 4.19 is slower than 4.14 when it comes to throughput. The great struct rework seems to benefit mainly x64 Mar 06 04:05:30 or 10G and above devices Mar 06 04:06:44 I seem to remember a specfic feature I wanted but I've since forgotten :D Mar 06 04:52:00 mangix: I've replaced bootloaders on almost all my QCA routers with breed. Mar 06 05:46:41 gch981213: I got breed on one of my devices. I had to change the format of the firmware to tp-link style. regular denx,uimage doesn't seem to work. do you know what formats breed accepts? Mar 06 07:15:15 ugh these random reboots are getting annoying Mar 06 09:29:40 mangix: breed for those tp-link routers (which are named as breed-[SoC name].bin) supports tp-link and LSDK firmware. LSDK firmware is the layout used in original QCA LSDK/QSDK with a small fixed uimage kernel partition after rootfs. Mar 06 09:35:22 jow: ping? Mar 06 10:09:29 gch981213: ah ok that makes sense. I get 384k extra flash space this way. I won't complain. Mar 06 11:00:34 aparcar[m]: pong Mar 06 11:12:34 jow: could be add *-dev packages including headers so building packages would be speeded up by dozens of times? Mar 06 11:14:34 aparcar[m]: thats an extremely complicated endeavour Mar 06 11:14:44 so the short answer is "no" Mar 06 11:14:46 :( Mar 06 11:20:49 could you explain what you mean by "building packages would be speeded up by dozens of times" ? Mar 06 11:21:40 karlp: avoid the need to build all direct and transient dependencies of a package when compiling a single package using the sdk Mar 06 11:22:56 that's a pretty specific usecase. Mar 06 11:23:09 but aparcer is doing all the image on demand cloud service stuff right? Mar 06 11:23:37 karlp: building a single and not all packages more than once is pretty specific? Mar 06 11:24:02 building single packages via the sdk is, yeah, IMO. Mar 06 11:24:26 because you're assuming you woudl never ever have to have build the deps anywhere else before in that buildroot Mar 06 11:33:33 introducing dev packages is very complex, requires strong abi tracking, very good (library) packaging discipline, quite some maintainer effort etc. Mar 06 11:33:51 even if we were to start with this now, it'll probably take a year or so to reach a suitable state Mar 06 11:34:08 assuming that all package maintainers adjust their workflows accordingly Mar 06 11:35:03 on a high level the approach is more or less straight forward, "simply" somehow turn "define Build/InstallDev" sections into packages Mar 06 11:35:32 but its not clear which format these pacakges should have, in which repo they should be organized, how to track their dependencies, generate the metadata etc. Mar 06 11:35:58 we're also lacking almost the complete tooling for this to become useful Mar 06 11:37:09 I don't see this happening anytime soon, especially considering the extreme scarcity of developers being deeply familiar with buildroot Mar 06 11:58:59 For the interested: new kernel bumps pushed to my staging Mar 06 12:11:22 jow: thanks for the clarification! Mar 06 15:11:45 jow: ping Mar 06 15:12:31 jow: do you know by heart where to fix this one? Latest master shows this: feeds/packages/net/openconnect/Config.in:6:error: recursive dependency detected! Mar 06 15:22:21 xback: I think the issue is in libp11 Mar 06 15:24:38 DEPENDS:=+libopenssl @OPENSSL_ENGINE Mar 06 15:24:56 this is mixing a selecting dependency with a nonselecting dependency Mar 06 15:25:57 CONFIG_OPENSSL_ENGINE is eventually, through a series of transient sub-dependencies, depending on CONFIG_PACKAGE_openssl (without selecting it) Mar 06 15:27:02 it should be either DEPENDS:=+libopenssl +@OPENSSL_ENGINE or DEPENDS:=@OPENSSL_ENGINE Mar 06 15:28:12 however in the latter case, no opkg binary dependency wiull be generated so this is likely not usable Mar 06 15:28:35 the only way to fix this is to turn @OPENSSL_ENGINE into a selecting dep Mar 06 15:32:18 jow: adding the "+" solves it indeed :) DEPENDS:=+libopenssl +@OPENSSL_ENGINE Mar 06 15:56:01 jow: thanks for merging that :) Mar 06 15:56:40 yw Mar 06 17:15:43 these days you can easily find an ISP offering its internet through DHCP. Sometimes is difficult to get IP; what I'm experiencing with vyos and edgemax is that dhcp at certain time fails. is openwrt handling better this kind of situation? thanks Mar 06 17:17:48 why is it faiing? Mar 06 17:17:55 also #openwrt Mar 06 17:19:00 is like the dhcp server requires lot of tries Mar 06 17:19:16 so I don't know openwrt can handle a situation of a permanent requesting dhcp client Mar 06 17:19:28 it fails to get a lease from the isp? Mar 06 17:19:39 if they aren't responding openwrt isn't going to help Mar 06 17:20:59 the problem with vyos-edgemax is that I cannot set the timeout to zero; to a situation of always requesting IP Mar 06 17:21:36 well, that's what I think... Mar 06 17:21:46 do anyone faced a similar situation? Mar 06 17:23:55 jwh: joining #openwrt :P Mar 06 20:59:21 jeffsf: medium term, the easiest way for VLANs on ipq40xx might be a DSA based switch driver (I'm not sure if there is something under preparation) Mar 06 21:24:35 pkgadd: Thanks -- will look into that. I'm going to try de-fang-ing the default VLAN by setting it to 0 in the DTS, once I check that it isn't going to break anything else Mar 06 21:25:54 Wish I had an understanding of just what is inside the chip -- I'm hoping the data bus between the switch and whatever the driver connects to isn't limited to 1 Gbps Mar 06 21:26:28 Haven't found a meaningful data sheet, just the promo "pull sheet" on the chip. Mar 06 21:31:37 I've got about three too many routers in pieces on my bench right now! Mar 06 21:38:14 ;) Mar 06 22:02:39 pkgadd: @chunkeey just replied on the forum. At least it isn't a "solved" problem! Mar 06 22:03:47 (meaning the IPQ40xx switch and VLANs) Mar 06 23:27:15 gch981213: for qca9531, is it possible to have two SPI flash chips? I bricked two of my boards while converting to breed and noticed two SPI flash chips on board Mar 06 23:29:07 both w25Q128 Mar 07 00:12:14 I'll be happy the day that git can read my mind on merge and rebase and give me a "clean" set of changes on top of `master` or what have you Mar 07 00:18:30 mangix: There are 3 hardware chip select available so it can be done if you don't mind that breed doesn't support the second flash. You'll need to figure out which GPIO is used for the other CS though. Any GPIO can be used as hw cs by setting pinmux registers. Mar 07 00:51:34 What's the "right" way to (locally) update `target/linux/ipq40xx/config-4.19` when the kernel sources change? Mar 07 00:52:06 (early testing repo, not OpenWrt) Mar 07 00:52:18 (not OpenWrt _repo_) Mar 07 00:56:03 Ugh, bounced, back Mar 07 01:07:41 mangix: BTW breed will switch all pins to GPIO which makes CS for the other SPI flash get pulled low. Both flashes share the same SPI bus and this made both of them inaccessible by the router. I guess this is the reason why you bricked your boards :) Mar 07 02:39:19 gch981213: wow you're right. all my bricks have two flash chips Mar 07 02:40:21 That's useful of it. Mar 07 02:41:29 i thought i bricked them because i ran mtd write without the -r parameter and that the -r parameter dealt with some race condition Mar 07 02:42:27 i also have no flash backups. my spi programmer doesn't work either. oh well. dust bin it is. Mar 07 02:51:54 in any case, breed works great. i underclocked my units to 300/200MHz CPU/DDR Mar 07 02:52:34 no reduction in ethernet speed surprisingly Mar 07 02:53:41 gch981213: wait a minute. the other non-bricked units have an empty slot where the second spi flash chip would go. I wonder if that would fix everything... Mar 07 02:59:19 On a 4.19 kernel -- has anyone run across `symbol value 'm' invalid for NF_NAT_REDIRECT` **** ENDING LOGGING AT Thu Mar 07 02:59:57 2019