Yeah, but I don't think that WAV600 stuff has anything in common with the Intel AX200 or AX210 which you likely refer to by good feature/stability experience. Unfortunately, those are client only as far as I know so not useful to build any OpenWrt traditional AP like device.
Hauke Mehrtens once posted a patch for GRX350, but it was not accepted . OpenWRT only accepts patches accepted upstream for lantiq . If you want to add GRX350 support you should discuss upstream the patches. I have Phicomm K3C and BTSmart Hub Type B (xRX350) and I can provide some testing.
while your efforts are to be commended targa, it's more about performance and functionality than just functionality.
i too am looking at 4.9. i am hoping my efforts will not be in vein. today is what i call "patch day". i have applied approximately 65 out the 317, so i'm hoping it will get quicker once i get near the tail end.
very high hopes for this platform. i suspect if it's patched right, there will not need to be much initialisation/mac address assignment at boot. almost like an x86 machine.
all 317 patches cleanly applied. looks like today may be "make a build day" :>
it's the best having a single multilib compiler for different variants of the same architecture.
i don't think i've ever been this excited for a platform.
if the kernel compiles cleanly i'm very confident this is going to really blow the doors off existing builds and probably most existing routers.
IT'S INTEL AND THEY MADE DRIVERS AND NO ONE CARED LOL.
IT HAS TO BE GOOD!!
edit: when i think more about why "no one cared" i think it's because if this platform is actually good, then the ARM hype story dies. and everyone knows i think ARM sucks, even though people here swear by their 300 compilers for 300 different variants of the same architecture, complete with 300 DTS files that feel more like assembly than they do an abstraction.
o boy am i excited
edit2: i also think the lack of support is motivated by a similar disdain for intel that many in the open source community harbour for M$. but the founders of M$ (minus ballmer) are my heroes, so i take a different view. i think that has a part to play in this as well.
helping intel is no different than helping M$, and "we all know they don't need our help"
edit3: in my view, "open source" is useless when ARM spins so many variants with different compilers. it makes participating a chore. the community overlooks this incredible nuisance, which hasn't improved and will never ever have a retrospective remedy.
to sacrifice the interaptiv platform to abide by the old ideology, at the expense of a convenient abstraction (MIPS) and probably great performance, is cutting thy nose to spite thy face.
edit4: just in case you're stupid... no, my hero hasn't changed "in spite of recent events", since it should be obvious he saw the risk of being photographed with a pedo. why would he put himself in a position? unless he had to... but "he's rich, he's free", right? or am i ruining the fantasy? my apologies.
apparently intel just sold this division off last year too.. so you may be right that it sucks
just a question since you chimed in borro:
if i compiled my libc with a kernel-version of 4.14, where the resulting binaries say "for GNU/Linux 4.14.0", since this is simply a string that i enteered when compiling glibc, it should still run on a 4.9 system right?
i know anything after 4.8.x glibc adds the hardened stack, so i'm hoping i don't have to re-cross-compile my toolchain for a lower string value.
who did you hear from about the spotty AP performance?
i've heard nightmare stories about stock firmware. and i think it's just one guy making all of the third party firmware (a guy named paldier). he's a pretty sharp guy, but i would like more information.
i'm hoping this is just a case of people running suboptimal kernel builds and then getting the resultant (poor) performance
edit: sort of. all glibc does is check the headers for the version. usually it is ABI-related, yes. but in my experience all this equates to is a failed compilation if your header subversion is lower than what is specified. i don't think the libc (glibc in this case) is any different unless it's pre/post 4.8.0 (where they require stack hardening afterwards, but not before).
or so i think that's how ti works.
silly me. i had older programs (built for, say GNU LINUX 3.x) on my squash where the libraries say 4.14 and they run fine.
There are plenty of stories to go around about Intel WiFi working well on Linux as a client (laptops, ...) but they're seldom used in APs (and nobody recommends them for that; if people ask). When people ask why not, the answer invariably is that the drivers don't allow for reliable operation as an access point. If Intel's drivers were up to snuff there would be more vendors offering them I reckon. After all there is some hardware around that comes with wireless as add-in cards (mPCIe etc.).