The abandonment of LANTIQ (WAV300/600 Intel InterAptiv)

For Developers
1

could i get any insight as to why the openwrt abandoned support for this platform?

i think it supported the SoC in 4.9, correct?

i just would like to learn whether it's worth the investment to tackle this platform.

from what i've seen, intel provides a complete set of patches for the ethernet, wifi and architecture files needed to compile the kernel. i've compiled the WAV600 driver as a module.

however the lack of openwrt support makes me wonder if there was a good reason they did not continue supporting this platform.

i would like to get any information as to the nuisances/difficulties associated with supporting this platform to better guide my decision-making.

2

This is likely related to no upstream drivers being available. While OpenWrt could carry downstream drivers maintaining any such is usually quite painful.

2 Likes
3

in a tough spot.

there seems to be a huge appetite (leechers, of course) for this platform.

of course you cannot fault openwrt because you guys are often using the latest kernel, which is not possible for this platform.

i am seriously considering dumping, what seems to require, many hours.

i am extremely curious about the performance of the WAV6xx on a properly built kernel. all of the customer reviews for the TP-LINK AX50 (as an example) are horrific nightmares.

it's intel wifi. it has to be good... or so i want to believe.

1 Like
4

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.

5

nah it doesn't, you're right.

even still, the fact they made all of these drivers for the platform and it is withering away...

i may try to integrate the nightmare-volume of patches and see what happens -_-

1 Like
6

@blogic any input here?

i see that you toyed with adding the RAX40. i would appreciate your insight, given your significant experience with this architecture.

many owners of the LANTIQ SoC are quite upset and frustrated. i feel this platform is a gem that needs some polishing.

what do you think? did your team abandon support because it required a kernel below the minimum of 4.14 (at that time, i think. could have been 4.9)?

7

Hauke Mehrtens once posted a patch for GRX350, but it was not accepted [1]. OpenWRT only accepts patches accepted upstream for lantiq [2]. 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.

[1] https://patchwork.kernel.org/project/linux-clk/cover/20180803030237.3366-1-songjun.wu@linux.intel.com/
[2] http://lists.openwrt.org/pipermail/openwrt-devel/2021-April/034639.html

1 Like
9

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.

10

yeah, understood that after reading, thus deleted my comment.

11

it's okay.

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.

12

got a little greedy and patched 4.14 with the 4.9 stuff. it looks good actually.

gonna flash my dir882 with the modified kernel to ensure everything is operating normally.

kernel compiled cleanly for config_soc_type_grx500_tep=y. hoping the usb/spi/etc won't cause any added nuisance.

my general observations are that there is a lot of offloading like the RALINK proprietary driver, where intel/lantiq call it the "ppa" instead of "ppe". was interesting to see that.

sorta nervous but what can ya do. i backed up my original kernel directory just in case. :stuck_out_tongue:

edit: PHEW, that was a close one. patches are in and clean compilation, DIR-882 is FINE. had a kernel panic because i didn't assign a NULL like the patch here (had to do some manual insertions):

who'd have thought the missing NULL assignment would have caused something as catastrophic as this:

***********QDMA_GLO_CFG=80100465
device eth2 entered promiscuous mode
CPU 1 Unable to handle kernel paging request at virtual address 00000000, epc == 805beb90, ra == 805bee18
Oops[#1]:
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 4.14.232 #4387
task: 87c2e000 task.stack: 87c56000
$ 0   : 00000000 00000001 80905cc2 0000dd86
$ 4   : 00000e9f 80905cb0 00000000 00000000
$ 8   : 00000000 80768150 0048ba2f ffffffff
$12   : 00000000 00000008 87e3a060 00000000
$16   : 00000081 00000000 858ad460 80905cb0
$20   : 87cff850 87c0dda8 87c0dda8 00000000
$24   : 81125dd8 80030fd0                  
$28   : 87c56000 87c0dcf0 87c0ddb0 805bee18
Hi    : 00000000
Lo    : 00000030
epc   : 805beb90 __skb_flow_dissect+0xf7c/0x1148
ra    : 805bee18 __skb_get_hash+0xbc/0x208
Status: 11007c03        KERNEL EXL IE 
Cause : 40800008 (ExcCode 02)
BadVA : 00000000
PrId  : 0001992f (MIPS 1004Kc)
Modules linked in: crypto_hw_eip93 authenc
Process swapper/1 (pid: 0, threadinfo=87c56000, task=87c2e000, tls=00000000)
Stack : 00000001 00000001 87c0dd18 00000000 00000000 00000001 87c30f80 0000010d
        00000000 00000000 00000412 00000013 00000001 00000001 190a3ab2 00000000
        00000000 00000000 00000000 808a90ac 00000009 00000000 00000002 80900000
        00000000 00000000 809055f8 87c0de74 858ad460 858ad460 80900000 87c0dda8
        00000003 87c0de68 00000046 a59a0040 05be5840 805bee18 0000010d 87c0de74
        ...
Call Trace:
[<805beb90>] __skb_flow_dissect+0xf7c/0x1148
[<805bee18>] __skb_get_hash+0xbc/0x208
[<805c13e8>] get_rps_cpu+0xe4/0x3d0
[<805ca79c>] netif_rx_internal+0x14c/0x1bc
[<8036fc5c>] rt2880_eth_recv+0x44c/0x5cc
[<8036fe10>] ei_receive_tasklet+0x34/0x12c
[<8003ff1c>] tasklet_hi_action+0x110/0x1dc
[<80771654>] __do_softirq+0x354/0x368
[<80040a08>] irq_exit+0xb4/0x134
[<807712ec>] do_IRQ+0x24/0x34
[<802a67f8>] plat_irq_dispatch+0xe0/0x12c
[<80010bc8>] except_vec_vi_end+0xb8/0xc4
[<800ac6e8>] sched_clock+0x4/0xf8
[<80585b78>] cpuidle_enter_state+0x368/0x428
[<80076500>] do_idle+0x1c4/0x270
[<800767f0>] cpu_startup_entry+0x24/0x2c
[<8001ec80>] start_secondary+0x2f8/0x3bc
Code: 00608825  00021040  02621021 <94c50000> 94420004  7c0528a0  02a21021  30a5ffff  94440000 

---[ end trace d3deb93d022a96f2 ]---
Kernel panic - not syncing: Fatal exception in interrupt

anyways, break time and back at it!

conclusions: don't waste your time with 4.14 porting, since the mips-irq-gic changes will make it useless. however, 4.9 builds pretty cleanly with this template:

13

@targa targs, what are your kernel configuration settings?

i need to get a good feel of what cpu features i need. some files i've seen have CONFIG_GRX_BOOTCORE, others not. they seem to be independent code paths.

14

I currently wouldn't give a shit on my own config -
I'm not a developer, only integrator kind of guy :wink:

15

getting excited.

it compiles with CONFIG_PPA, i assume is the hardware acceleration that (from what i'm told) no builds currently have enabled (3.x or 4.x).

hoping to get something i can flash done by the end of tonight so i can give it to SWIM and they can go get an AX50 to test it out.

16

From what I gathered, Intel's wireless stuff is like their Linux GPU drivers: good enough. Don't expect Intel radios to work reliably in AP mode. Apparently that's hit and miss.

And then there's the difference between their in-house wireless and what they acquired when they bought Lantiq. The latter is what seems to be used in recent Intel based wireless hardware.

1 Like
17

apparently intel just sold this division off last year too.. so you may be right that it sucks :frowning:

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.

18

I have no idea if that would be backwards compatible, sorry. Doesn't that have to do with the kernel ABI?

19

no problem.

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.

20

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.).

21

from what this guy told me, the open source driver is different from the closed source (as you noted), but it seems iwlwav is solely for APs. is that wrong? it's for both clients and APs?

i thought they pretty much mustered this effort for the interAptiv platform. the pplwrt effort seems to be for interAptiv, that's for sure.