**** BEGIN LOGGING AT Tue Oct 27 02:59:57 2020
Oct 27 04:22:40 <mangix> sigh
Oct 27 04:22:45 <mangix> the SDK is still broken
Oct 27 04:22:54 <mangix> this is quite frustrating
Oct 27 04:44:17 <mangix> actually wait a minute...CircleCI is succeeding and GitHub Actions is failing
Oct 27 04:44:27 <mangix> aparcar[m]: ping
Oct 27 04:49:06 <aparcar[m]> mangix: pong
Oct 27 04:49:13 <aparcar[m]> I'll have a look
Oct 27 04:51:18 * mangix expects an influx of complaints regarding transmission
Oct 27 04:55:07 <aparcar[m]> context?
Oct 27 04:56:18 <mangix> i got rid of the mbedtls and openssl variants
Oct 27 04:56:29 <mangix> now it's only wolfssl.
Oct 27 04:58:05 <aparcar[m]> brave
Oct 27 04:58:13 <aparcar[m]> I thought mbedtls is the secret cool kid
Oct 27 04:58:25 <aparcar[m]> I triggered a snapshot builds
Oct 27 04:58:34 <aparcar[m]> *a docker snapshot build
Oct 27 04:58:49 <aparcar[m]> maybe the new sdk containers fix the problem
Oct 27 04:59:26 <mangix> the goal was to avoid installing two separate libssl
Oct 27 04:59:46 <mangix> transmission depends on libcurl which depends on wolfssl
Oct 27 04:59:50 <mangix> might as well match it
Oct 27 05:05:41 <aparcar[m]> sounds smart
Oct 27 05:28:51 <aparcar[m]> mangix: new snapshot images available
Oct 27 05:28:56 <aparcar[m]> please rerun some tests
Oct 27 05:43:57 <aparcar[m]> mangix: also feel free to check the generic test approach here https://github.com/openwrt/packages/pull/13785
Oct 27 06:14:42 >KGB-1< https://tests.reproducible-builds.org/openwrt/openwrt_ath79.html has been updated. (99.1% images and 100.0% packages reproducible in our current test framework.)
**** BEGIN LOGGING AT Tue Oct 27 06:45:16 2020
**** BEGIN LOGGING AT Tue Oct 27 06:48:07 2020
Oct 27 09:16:28 <karlp> mangix: so.. you made it depend on libcurl then, rather than explicitly depending on wolfssl right?
Oct 27 09:16:37 <karlp> libcurl already has selectable ssl libs.
Oct 27 09:25:47 <rsalvaterra> Wait… so now I have to have libcurl installed to have transmission, even though I already need openssl or wolfssl?
Oct 27 09:27:26 <rsalvaterra> Ah, it already depended on libcurl.
Oct 27 09:27:36 <rsalvaterra> Oh, well…
Oct 27 09:34:41 <mangix> karlp: yes. transmission does as well. i matched the tls Libs
Oct 27 09:35:14 <mangix> rsalvaterra: libcurl is a dependency yes.
Oct 27 09:35:47 <mangix> it's used for downloading torrents and HTTP trackers
Oct 27 09:36:36 <mangix> tls lib is just used for sha1 and rc4
Oct 27 09:44:56 <rsalvaterra> I just resent my zstd patch. I noticed it was still catering for Linux 4.14, but it's been dropped since then (thank God). :P
Oct 27 09:47:13 <Borromini> damex: ping
Oct 27 09:47:21 <damex> Borromini: pong?
Oct 27 09:49:50 <Borromini> hi! wondering if you had some numbers to compare to https://forum.openwrt.org/t/comparative-throughput-testing-including-nat-sqm-wireguard-and-openvpn/44724
Oct 27 09:49:54 <Borromini> for the er 4 :)
Oct 27 09:56:20 <Borromini> i'm weighing the er4 against the gl.inet brume 1000 as a new edge router
Oct 27 09:56:34 <Borromini> brume is mvebu 88F3720
Oct 27 09:59:35 <damex> i don't use openvpn on that device and it will be rather complicated to test with
Oct 27 09:59:52 <damex> lemmi: could you help providing some numbers for wireguard?
Oct 27 10:00:02 <lemmi> damex: er-4?
Oct 27 10:00:07 <damex> lemmi: yeah
Oct 27 10:00:26 <Borromini> damex: i'm mostly interested in wan to lan with and without sqm :)
Oct 27 10:01:24 <lemmi> with iperf3 running on the thing: towards er-4 400-450mbps single connection, from er-4 250mbps single and about 400mpbs multiple connections
Oct 27 10:02:01 <Borromini> but whatever numbers you guys can produce, i'll take. there's a 40 EUR difference between both devices. i'd like to weigh whether the er-4 is worth the extra money
Oct 27 10:02:02 <rsalvaterra> The EdgeRouter 4 looks similar to the APU2C4…
Oct 27 10:02:13 <Borromini> lemmi: thanks, is that wan to lan?
Oct 27 10:03:13 <Borromini> sorry, you said on the er-4. so i assume that's just lan?
Oct 27 10:03:28 <damex> i was able to get with iperf (multiple connections mode) lan -> wan (nat, no offload) with sqm - 520Mbit, without 942Mbit (line rate)
Oct 27 10:03:57 <damex> depends on circumstances - using no bridge let me get up to 600Mbit at times
Oct 27 10:04:03 <damex> with sqm ofcourse
Oct 27 10:04:08 <Borromini> damex: cool, that sounds pretty neat. so definitely more headroom than the 88F3720
Oct 27 10:04:41 <damex> i still use one core for irq
Oct 27 10:05:03 <damex> we could probably get more out of it if we manage to balance queues across cores
Oct 27 10:05:53 <Borromini> :)
Oct 27 10:07:05 <rsalvaterra> damex: Have you tried irqbalance?
Oct 27 10:07:16 <damex> rsalvaterra: yeah, does not help
Oct 27 10:08:09 <rsalvaterra> I have the same problem on mvebu. I think only the PCIe interrupts can be moved, the other ones are fixed.
Oct 27 10:08:26 <lemmi> Borromini: since iperf3 was running on the thing, it's possible that the forwarding speed is actually higher.
Oct 27 10:08:46 <lemmi> Borromini: everything else i tested: gre/gre6/vxlan was doing linerate
Oct 27 10:09:25 <Borromini> lemmi: neat, thanks a lot.
Oct 27 10:09:55 <lemmi> and there might still be some performance lying on the table as the cpu wasn't fully utilized
Oct 27 10:10:12 <Borromini> :)
Oct 27 10:10:43 <lemmi> but a quick renumbering of the interrupts and receive packet steering didn't help
Oct 27 10:12:07 <damex> thats because of octeon-ethernet driver
Oct 27 10:42:28 <damex> probably such tests are not as consistent as one you would do with that flent tool
Oct 27 11:21:23 <nitroshift> nbd, are you around?
Oct 27 12:20:06 <rsalvaterra> I finally bit the bullet and ordered another AR5418 card (AzureWave AW-NE770)…
Oct 27 12:20:43 <rsalvaterra> The one I got before doesn't have an EEPROM and is basically useless without it.
Oct 27 12:32:19 <Namidairo> did it just assume you would pull caldata out of the nether
Oct 27 12:35:26 <rsalvaterra> Nah, it's just one of those cards which fetches the caldata from elsewhere (it's Apple branded).
Oct 27 12:36:23 <rsalvaterra> If I had known it didn't have an EEPROM, I wouldn't have bought it (it was very cheap, though).
Oct 27 12:44:23 <nbd> nitroshift: pong
Oct 27 12:48:56 <nitroshift> nbd, based on your work on kernel 5.9 i have updated mvebu target to 5.9 too
Oct 27 12:49:33 <nitroshift> is there an e-mail address where i can send you the patches?
Oct 27 12:49:54 <nitroshift> i have 2 left hands when it comes to doing pull requests
Oct 27 12:50:07 <nbd> you can send it to nbd@nbd.name
Oct 27 12:50:20 <nbd> i usually prefer git send-email as well
Oct 27 12:50:42 <nitroshift> also, there was a regression in mvebu-pcie.c, patch 407 fixes it
Oct 27 12:51:38 <nitroshift> message sent
Oct 27 12:52:03 <nitroshift> i'm running it on both my wrt3200acm's since yesterday
Oct 27 12:52:28 <nitroshift> everything is working as expected
Oct 27 12:52:51 <nitroshift> proof: https://forum.openwrt.org/uploads/default/original/3X/5/4/54a5334661f09aa17141805211b8a2af86289f01.png
Oct 27 13:01:29 <nbd> nitroshift: nice, thanks
Oct 27 13:01:37 <nitroshift> nbd, here's the orginal bug report on mvebu-pcie: https://www.spinics.net/lists/arm-kernel/msg848013.html
Oct 27 13:08:08 >KGB-0< https://tests.reproducible-builds.org/openwrt/openwrt_omap.html has been updated. (0% images and 99.7% packages reproducible in our current test framework.)
Oct 27 13:11:18 <nbd> nitroshift: can you make a git patch for me with your signed-off-by, patch description, etc?
Oct 27 13:12:14 <nitroshift> nbd, for the pci-mvebu regression?
Oct 27 13:12:21 <nbd> for the 5.9 support
Oct 27 13:12:25 <nitroshift> oh
Oct 27 13:12:27 <nbd> openwrt tree
Oct 27 13:12:40 <nitroshift> i'll try my best
Oct 27 13:12:47 <nbd> thanks
Oct 27 13:13:22 <nitroshift> nbd, master or your branch?
Oct 27 13:14:43 <nbd> against my branch
Oct 27 13:15:11 <nitroshift> ok
Oct 27 13:23:17 <nitroshift> nbd, got as far as git commit, don't know what commit message should say :|
Oct 27 13:40:42 <nitroshift> i managed to pass the commit phase, what next?
Oct 27 13:40:51 * nitroshift is an idiot
Oct 27 13:45:33 <rsalvaterra> nitroshift: What do you need to know?
Oct 27 13:46:58 <nitroshift> rsalvaterra, i need to make a git patch against nbd's staging tree and send it to him
Oct 27 13:47:36 <rsalvaterra> Ok, you cloned his staging tree, created a new branch and made your commit against this new branch, right?
Oct 27 13:48:09 <nitroshift> ummm... nope
Oct 27 13:48:37 <nitroshift> i cloned his tree and done all work directly there
Oct 27 13:49:05 <rsalvaterra> Hmm… is it a one-off patch? If so, it's probably alright.
Oct 27 13:49:47 <nitroshift> it's a set of patches
Oct 27 13:50:03 <rsalvaterra> So, it's a series of commits, right?
Oct 27 13:50:04 <nitroshift> i'm cloning the tree again and create a new branch
Oct 27 13:50:57 <owrt-snap-builds> build #311 of ath79/mikrotik is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/ath79%2Fmikrotik/builds/311  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Roman Kuzmitskii <damex.pp@icloud.com>, Leon Maurice Adam <leon.adam@aol.de>
Oct 27 13:50:59 <rsalvaterra> You don't need to clone again, you could just branch from where you were, but ok. :)
Oct 27 13:51:55 <rsalvaterra> But don't sweat it, I was exactly where you are about two years ago. Git was a complete mystery to me (and some parts still are).
Oct 27 13:52:46 <nitroshift> rsalvaterra, thanks for helping!
Oct 27 13:52:56 <rsalvaterra> My pleasure. ;)
Oct 27 13:53:03 <nitroshift> right, i got the clone and a new branch
Oct 27 13:53:34 <nitroshift> rsalvaterra, can we go in pm so i don't spam the main channel?
Oct 27 13:54:05 <rsalvaterra> Sure, bring it on! :)
Oct 27 14:59:49 <damex> http://buildbot.openwrt.org/master/images/builders/ath79%2Fmikrotik/builds/311 how does it even decide that tiny octeon change affects ath79/mikrotik ?
Oct 27 15:00:32 <damex> probably not even related, just need a blamelist fixup
Oct 27 15:04:39 <f00b4r0> adrianschmutzler: ping?
Oct 27 15:05:52 <adrianschmutzler> pong
Oct 27 15:06:07 <f00b4r0> adrianschmutzler: I'll reply here instead of on GH for reasons that will be obvious in a sec:
Oct 27 15:06:44 <f00b4r0> kernel2minor is absolute garbage. It's "documented" in cyrillic, the code is buggy as hell and it's a plague to the mikrotik target that I would very much find the time to get rid of ;P
Oct 27 15:07:39 <f00b4r0> tl;dr: I'm not interested in reviewing any change to it and I'd recommend that updates be only accepted if they _fix_ anything
Oct 27 15:08:12 <karlp> aren't you the same person who just wants to remove mikrotik support? :) are you entirely neutral?
Oct 27 15:09:03 <f00b4r0> karlp: I don't want to remove support per se.
Oct 27 15:09:34 <f00b4r0> karlp: if you want to convince yourself, by all means please take a look at https://github.com/adron-s/kernel2minor/blob/master/kernel2minor.c
Oct 27 15:09:43 <adrianschmutzler> okay, then I'll just leave it be
Oct 27 15:10:20 <f00b4r0> adrianschmutzler: that's my 2c, others may disagree :)
Oct 27 15:11:22 <f00b4r0> but that piece of code really is an abomination, I think most will agree on that. I know for a fact that the firmware-minor splitter (which I wrote) needs to work around some of its bugs.
Oct 27 15:12:07 <f00b4r0> it's also the reason why we no longer properly handle mikrotik NAND devices
Oct 27 15:14:50 <f00b4r0> adrianschmutzler: for full context, the upstream author ('adron-s') is the same one who butchered the uboot sources as a 'loader' to boot mikrotik ipq devices in current PRs.
Oct 27 15:15:03 <f00b4r0> Hopefully, john-tho's work will make that irrelevant soon enough.
Oct 27 15:29:45 <ynezz> damex: it simply builds batch of commits, if it fails, all are to blame, no bisecting is done to find offending commit
Oct 27 21:12:59 <Borromini> stintel: ping
Oct 27 21:13:45 <stintel> Borromini: pang
Oct 27 21:14:53 * Borromini grabs his bulletproof vest
Oct 27 21:21:48 <owrt-snap-builds> build #607 of mediatek/mt7623 is complete: Failure [failed updatefeeds]  Build details are at http://buildbot.openwrt.org/master/images/builders/mediatek%2Fmt7623/builds/607  blamelist: Adrian Schmutzler <freifunk@adrianschmutzler.de>, Leon Maurice Adam <leon.adam@aol.de>
Oct 27 21:35:21 <svanheule[m]> Borromini: ping
Oct 27 21:37:12 <Borromini> svanheule[m]: pong
Oct 27 21:37:33 <svanheule[m]> ah, you're still alive :D
Oct 27 22:18:15 <anon^_^> hi
Oct 27 22:18:31 <anon^_^> anyone have updates on 18.06.9?
Oct 27 22:19:02 <anon^_^> there was August discussion of a new point release 18.06.9 in September with 19.07.4
Oct 27 22:19:32 <anon^_^> 19.07.4 was released in early sept
Oct 27 22:19:48 <anon^_^> https://openwrt.org/releases/18.06/notes-18.06.9
Oct 27 22:20:04 <anon^_^> releases/18.06/notes-18.06.9.txt · Last modified: 2020/08/30 17:09 by zorun
Oct 27 23:11:47 <eduardas> hello, I am trying to cross-compile Qualcomm's u-boot from QSDK sources on CodeAurora on Ubuntu 18.04 with the arm-linux-gnueabihf-gcc pre-packaged toolchain and failing
Oct 27 23:12:03 <eduardas> specifically the configuration for the IPQ6018 chip
Oct 27 23:13:17 <eduardas> failure is like this: https://pastebin.com/RwUgTthM
Oct 27 23:14:37 <eduardas> sources are actually publicly available: https://source.codeaurora.org/quic/qsdk/oss/boot/u-boot-2016/log/?h=NHSS.QSDK.11.2
Oct 27 23:15:15 <eduardas> config used is ipq6018_defconfig
Oct 27 23:18:21 <russell--> eduardas: /me vaguely recalls similar ... maybe need to specify the c standard the code adheres to or find an older gcc or build host
Oct 27 23:19:55 <m4t> not positive but you might want to use e.g. arm-none-eabihf-gcc instead as it's bare metal
Oct 27 23:21:26 <eduardas> m4t: will do... was not aware it exists.... did not really want to use crosstool-ng as I'm on a weak laptop right now
Oct 27 23:22:35 <russell--> we built upstream u-boot recently for mt7628 and used the openwrt toolchain
Oct 27 23:23:45 <eduardas> russell--: can the OpenWrt toolchain be used standalone somehow?
Oct 27 23:24:45 <eduardas> just so you know, I'm not specifically doing OpenWrt, so I know little about it.... I actually tried to put together a Yocto-based BSP
Oct 27 23:25:08 <eduardas> I just thought people here know more about vendor-u-boot-forks
Oct 27 23:26:20 <pkgadd> the corresponding QSDK toolchain 'should' be able to build it, on an adequately old Ubuntu(?) version (i'd venture something from 2014 or 2015)
Oct 27 23:27:02 <pkgadd> but yes, OpenWrt toolchains can be re-used for other purposes - if you integrate correctly, which isn't necessarily easy
Oct 27 23:27:07 * russell-- looks for what i did
Oct 27 23:29:34 <pkgadd> that doesn't mean the QSDK u-boot will actually be functional on a real-world OEM device (you can expect -always- that the vendor has made changes to the source), so make sure to have a reliable fallback (I don't know of any method to fix an ipqxxxx device with a shot pbl or sbl, if you're very lucky it comes with api-nor and can be flashed externally, for NAND you'd be …)
Oct 27 23:29:37 <Hauke> I used the OpenWrt toolcahin to successfully build U-Boot for other boards, but mostly mainline U-Boot
Oct 27 23:31:03 <eduardas> pkgadd: I am aware there are more problems ahead... just trying to do one little step at a time :)
Oct 27 23:31:42 <m4t> actually tools/sysupgrade.c seems to be built with HOSTCC so the arm toolchain shouldn't be the issue i think
Oct 27 23:32:40 <eduardas> m4t: yes, I noticed that too, but was not 100% sure
Oct 27 23:32:54 <m4t> i wonder if there is a way to get u-boot to output gcc cmd being used
Oct 27 23:32:58 <m4t> like V=s on openwrt
Oct 27 23:33:24 <pkgadd> beyond u-boot, mainline kernel and ath11k are still missing a lot for ipq60xx (and even more for ipq50xx) - expect a lot of work in front of you
Oct 27 23:34:01 <eduardas> pkgadd: is basic ipq60xx support in mainline at all?
Oct 27 23:34:35 <eduardas> i.e. at least to get serial login
Oct 27 23:34:38 <pkgadd> incomplete and still in the process of getting merged (which doesn't mean that it will ever be complete)
Oct 27 23:34:51 <m4t> 'make V=1' seems to work on 2019
Oct 27 23:35:25 <eduardas> m4t: thank you, it gives me something
Oct 27 23:35:29 <m4t> 2019.07*
Oct 27 23:36:06 <m4t> eduardas: then you could run the identical cmd and play with cflags like -std= and -l... until maybe it works :D
Oct 27 23:36:21 <eduardas> m4t: the output: https://pastebin.com/2KwnPAU5
Oct 27 23:38:14 <russell--> export CROSS_COMPILE=mipsel-openwrt-linux- ; export PATH=<my-openwrt-staging_dir/bin-path>:$PATH
Oct 27 23:38:52 <m4t> supposedly those are provided by -lbsd (libbsd-dev pkg on ubuntu)
Oct 27 23:39:04 <m4t> strlcat and strlcpy
Oct 27 23:40:39 <m4t> tools/sysupgrade.c was added and is part of the codeaurora fork it seems https://source.codeaurora.org/quic/qsdk/oss/boot/u-boot-2016/log/tools/sysupgrade.c?h=NHSS.QSDK.11.2
Oct 27 23:41:32 <eduardas> m4t: oh dear... such a mess... thanks a lot for finding that
Oct 27 23:41:58 <eduardas> m4t: though not sure how I am supposed to correctly use that
Oct 27 23:42:14 <m4t> do you have libbsd-dev installed?
Oct 27 23:42:27 <eduardas> m4t: yes, does not help
Oct 27 23:42:37 <eduardas> m4t: result is the same
Oct 27 23:42:54 <eduardas> m4t: perhaps the linking flag is necessary
Oct 27 23:43:02 <eduardas> and I don't really provide it
Oct 27 23:44:30 <m4t> might need to add -lbsd then, could edit Makefile and add -lbsd to the end of the HOSTCFLAGS = line. but it doesn't seem those are applied to the final 'cc' cmd in that paste
Oct 27 23:47:48 <m4t> or possiblly add it to 'HOSTLOADLIBES_dumpimage' in tools/Makefile
Oct 27 23:51:55 <m4t> eduardas: okay i got it to compile (cloned it locally)
Oct 27 23:52:26 <m4t> added: HOSTLOADLIBES_mkimage += -lbsd
Oct 27 23:52:33 <m4t> but spoiler, the build then fails elsewhere :P
Oct 27 23:52:48 <m4t> added to line ~138 in tools/Makefile
Oct 27 23:53:11 <eduardas> m4t: thanks a lot
Oct 27 23:53:28 <m4t> it might be that i'm trying to compile for x86 and they have stuff hard-coded for the qualcomm crap
Oct 27 23:53:40 <m4t> (kinda seems that way, based on the errors)
Oct 27 23:55:21 <eduardas> m4t: I don't know, it kinda did not error out for me :)
Oct 27 23:56:08 <m4t> yeah. must be compiling for the sandbox/x86 target then
Oct 27 23:56:27 <eduardas> m4t: I have both u-boot.bin and u-boot files now
Oct 27 23:56:39 <m4t> well hopefully they work and don't just brick your board
Oct 27 23:56:40 <m4t> hehe
Oct 27 23:57:04 <eduardas> file command gives u-boot: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
Oct 27 23:57:16 <eduardas> m4t: this is hopefully correct?
Oct 27 23:58:06 <m4t> well u-boot.bin is the one you'd normally want i think
Oct 27 23:58:11 <eduardas> sadly, I don't have equipment now... it's actually 1:58 here
Oct 27 23:58:31 <m4t> one of the few times i built u-boot myself i ended up bricking the board and had to get a jtag
Oct 27 23:58:52 <eduardas> file says u-boot.bin is u-boot.bin: COM executable for DOS... lol ...why? :D
Oct 27 23:59:05 <m4t> iirc it had a different env location in flash compared to what was already on the board, so 'saveenv' corrupted the executable
Oct 27 23:59:24 <m4t> probably because 'file' only goes by a few bytes and it randomly matches it
Oct 27 23:59:55 <m4t> probably more often it'd just say 'data'
Oct 28 00:01:20 <eduardas> a colleague got some cheap Chinese routers, don't really remember the brand
Oct 28 00:01:40 <eduardas> said they have u-boot-2016 on them
Oct 28 00:01:49 <eduardas> which is probably a fork of this
Oct 28 00:02:29 <eduardas> not sure how we're gonna get an u-boot onto it, though
Oct 28 00:06:11 <eduardas> if anyone knows any hacker-friendly Wi-fi 6 hardware one can buy, please let me know :)
Oct 28 00:07:21 <pkgadd> mediatek should be easier (but still only very few devices - and not really interesting ones). ipq807x is much further ahead than ipq60xx or ipq50xx (by at least 2 years)
Oct 28 00:09:27 <pkgadd> but you should consider if you really need to work on the u-boot side - or if just working on kernel+rootfs is enough
Oct 28 00:09:55 <eduardas> pkgadd: is ipq807x Wi-fi 6 capable?
Oct 28 00:10:12 <pkgadd> yes
Oct 28 00:10:46 <eduardas> pkgadd: that is really useful to know, thanks... I have not really looked into mainline support much yet
Oct 28 00:11:20 <pkgadd> things like xiaomi ax3600, redmi ax6, netgear rax120, asus rt-ax89x
Oct 28 00:12:19 <pkgadd> neither of them is supported officially by OpenWrt yet, but there seems to be a lot of interest behind the ax3600 (and some initial efforts which appear to work to quite some extent)
Oct 28 00:12:58 <pkgadd> https://forum.openwrt.org/t/ipq807x-soc-investigation-status-wip/70534
Oct 28 00:17:34 <eduardas> I also find it weird that the defconfig for IPQ6018 is for 32-bit ARM even though the SoC is 64-bit
Oct 28 00:17:50 <eduardas> anyone have any ideas why that might be the case?
Oct 28 00:18:14 <pkgadd> many ipq60xx devices seem to be quite short on RAM, so running a 32 userland wouldn't really surprise me
Oct 28 00:19:33 <pkgadd> the emphasis is on cheap, not performance
Oct 28 00:20:18 <eduardas> pkgadd: ok, the what do you consider the luxurious ferrari of wireless SoCs? :D
Oct 28 00:20:32 <pkgadd> ipq8074a
Oct 28 00:23:26 <eduardas> both ipq8074a and ipq6018 are 4x ARM Cortex A53
Oct 28 00:23:37 <eduardas> what are the crucial differences?
Oct 28 00:24:25 <eduardas> I see ipq8074a has DDR4 support
Oct 28 00:24:30 <pkgadd> SOC support (mainline), I/O, wifi combination, performance (ipq8074a clocks at 2.2 GHz)
Oct 28 00:25:52 <pkgadd> ipq60xx is limited to 2x2, ipq8074 with qcn5024+qcn5054+qcn5054 can do 8x8
Oct 28 00:26:47 <pkgadd> (or rather 4x4 for 2.4 GHz, 8x8 for 5 GHz)
Oct 28 00:32:31 <eduardas> that's one really expensive devboard: https://techship.com/products/compex-hk01-embedded-board/
Oct 28 00:33:12 <eduardas> seems mainline Linux has dtb specifically for this one
Oct 28 00:33:48 <pkgadd> that's why the ax3600 is rather interesting, at around 90 USD
Oct 28 00:36:22 <eduardas> dts commits in mainline signed off with codeaurora.org and Linaro addresses... Qualcomm is paying Linaro for upstreaming?
Oct 28 00:36:48 <pkgadd> (ipq8071a vs ipq8074, only 4*1.4 Ghz instead of 4*2.2, only qcn5024+qcn5054, 4x4 instead of 8x8)
Oct 28 00:40:01 <eduardas> pkgadd: is ath11k on mainline actually known to work or is it just a work-in-progress?
Oct 28 00:40:40 <pkgadd> don't ask me, it should cope with ipq807x (but not ipq60xx or ipq50xx yet)
Oct 28 00:45:55 <pkgadd> looking at the ipq807x, you will have to maintain non-mainline patches for the time being
Oct 28 00:45:59 <pkgadd> *target
Oct 28 00:58:58 <eduardas> pkgadd: understandable, thanks again for the very useful info
Oct 28 01:40:45 <russell--> anybody seen a ubiquiti bullet ac up close?
Oct 28 01:41:29 <russell--> where is wikidevi when you need it
**** ENDING LOGGING AT Wed Oct 28 02:59:57 2020