37

That said, after playing around with the various build chains for the ipq6018 in both the Flint and Slate AX (both the infra-builder and elsewhere), I am not encouraged about the short term stability or long term software support for either platform. The qsdk everyone is using is very picky in terms of it’s build environment. It’s telling that everyone is using the 4.4.60 kernel in releases, as far as I’ve seen, and even then running in armv7 compatibility mode. You can (sort of) get the 5.4 build to compile, but it’s slower (by about 30% in my testing) than the 4.4. Not a good sign.

Given the lack of interest in porting the 8000 series code to the 6000 series in OpenWRT main, and given that many other manufacturers skipped the 6000 series in their product lines, I suspect it’s going to be a long road before that chipset is supported, and even when it is supported I doubt it will match the raw speed of the accelerated qsdk builds, at least while the hardware remains relevant.

(and to be very clear, this is not a reflection on GL-iNet or their developers - I am certain they’d like to fix these issues. At the same time, what a lot of consumers don’t realize about bugs like these is that the developers often can’t fix them. They exist in someone else’s code, and it’s either not possible to fix, or it would cost more to fix than the company would make fixing it. It’s not a bad business decision to select X chip for a product, but if the company that makes X chip more or less abandons that product line because they’ve moved on to the newest thing, there may not be anything you can do about it.)

3 Likes