Hi, just a quick question. There was some issue with AX6 (associated with the kernel version, from what I remember?), right? Is it still still there? Is it a critical error making the router(wifi) unusabe? Any testing needed?
Thanks.
Hi, just a quick question. There was some issue with AX6 (associated with the kernel version, from what I remember?), right? Is it still still there? Is it a critical error making the router(wifi) unusabe? Any testing needed?
Thanks.
As I am using an AX6 for quite some time now, I have not seen any issues. Our current problem is that the AX6 seems to be the only device not cooperating with the new 2.7 firmware versions, but you cannot really help with this.
Ok that is good to know.
Thanks alot.
How newbie friendly is robimarko's version or should I use another fork (another trusted source etc. ?) Anything to keep an eye on to report here?
Maybe important to know, what setup I have:
I have a cable Gigabit Internet with only 50 Mbit UL connection and a Technicolor TC4400 Modem.
So far I get the same DL and UL speeds like the stock FW.
The AX3600 handles everything router related.
I have some smart devices at home (plugs and displays) on 2,4Ghz and Phones, TV or gaming related devices are either wired or on 5 Ghz.
Dont know if there are any forks, which are more perfomance optimized ( I know that it is possible to change the CPU governor, but don't know what benefits I would get and dont know how to do it, but I am willing to read and learn)
I had some older version (May/June) on AX6 and it was fine (still on the older fw versions). What is the manifestation? You say it works fine, so where is the problem now?
FW 2.7 is not yet integrated due to this (and some other) issues,so you cannot help testing with this. The firmware is crashing on AX6 during load. The likely reason is that the AX6 uses some custom parts in the BDF apparently no other devices are using, probably related to FEM control. Trust me, you cannot help with this.
Just like range of any other WiFi device with similar antennae, radiating max allowed power (which is usually 200mW for 5GHz or 100mW for 2.4GHZ). There are no great differences.
interesting ...
" Qualcomm has hit back at Arm with explosive allegations that the British chip designer has threatened to phase out CPU design licenses for semiconductor companies and instead charge device makers royalties for using Arm-compliant processors"
Hm.... How exactly Qualcomm's licensing works towards the OEM vendors? Quite interesting that Qualcomm does not feel comfortable with the same licensing applied to itself, what they apply to their customers since 3G....
Is it possible to return to the stock firmware via luci?
precisely!!!
As we are already off the topic anyway, this will be my last QCA device for a while at least. Robi is doing a tremendous job in trying to get this thing running but the situation regarding drivers and firmware is absolutely unbearable.
Mediatek has some nice chips coming up and I feel mainline support there is a lot better so that's what I'm aiming for and QCA can go to where ever they want.
I can only suggest everybody to do the same unless you want to support this kind of attitude of QCA.
I agree to a point, but remember that 3 years ago when this started, these router (AX6 and AX3600) were the only 4 ARM core, decent AX capable units for an affordable price. And MediaTek was far behind. And I have a feeling that besides HW offload and wifi drivers, the SoC itself is still more powerful than anything on the MeditaTek domain for generic processing. Maybe the new chips will change that, but for now I would rather buy a higher end ipq807x based unit then a mediatek one. And the firmware issues are only limited to the AX6, the rest of the devices are running the 2.7 version FW just fine. And the ipq807x platform has support up to 10gig on the wired side. So getting ipq807x pushed to mainline would provide benefits on device support for a long time...
Undoubtedly it's a nice piece of hardware but without proper software support it's not worth much. You might have the regdb required by 2.7 but who knows if and when QCA will ever make it publicly available so it can legally be redistributed.
Also I think robi was told more than half a year ago by QCA that they're aware of the issue with initializing ahb and pci together and they're working on a fix but iirc nothing ever happened since then. Same with the issues posted on Bugzilla. No response and no support from QCA at all.
And can you even saturate the 10G link without offloading?
Upstream just picked a bunch of long(Since August) patches for IPQ8074, so now CPU scaling finally via mainline drivers, DTS for the PMIC also got merged.
I have also figured out a generic fix for AHB and PCI concurrency, its a QRTR instance ID issue but luckily its programmable.
I am now extending MHI to offer a trigger to fix that dynamically, but I discovered Gen3 PCI got broke upstream again, luckily Ansuel and I figured it out.
@Crect To be honest, getting support from any vendor for upstream kernel can be considered winning on lottery, MTK was incredibly horrible with regards to upstream just 2 years ago.
Even now their Filogic stuff is half-broken upstream and open source community is fixing it up based on the SDK.
That is true but as I understand it, it's still in better shape than QCA stuff is and even with mainline support for offloading etc? I don't regret having bought my AX3600 but I feel it's too complicated with QCA to buy another device until they maybe put more effort into mainline support. They're a billion dollar company but apparently their customers don't care about mainline and are happy with their ancient BSP.
I'm very thankful that the OpenWrt Developers are trying to provide a broad support of devices even if it means the that the support is not 100% perfect. For me it is more important to have a "free" device.
ATM I'm quite happy with the state of this particular unit. It is running stable and Wifi (ax) is a bit "snappier" and a bit faster than on my AX3200 (MTK).
So I would not go along to drop everything in favor for MTK.
But overall I can understand the frustration of the Developers and users who want a almost "perfect" supported device like the Netgear R7800 was/is.
Well honestly it's oem fault for accepting to run network device with ancient kernel... it's strange that with new ath12k they are doing the change and are thinking of actually using offload feature the right way instead of having everything running in the nss black box... That is for sure a hint that they notice things became unmaintainable to the level that even qca devs are having problems in implementing stuff... and are facing the reality that doing things properly in the first place would have saved them tons of effort...
Just to remember something qcom works with oem and accomplish request... if nobody care or even ask for better things then why bother to fix them...
Just watch what happen on android before the treble stuff... if it wasn't for google and the intention of having thing running near upstream kernel version we would have the same exact situation with custom stuff all around the kernel... (the situation there is still bad but much better than before) (problem is that sooner or later we will have router with spammed container all over the place and this is already happening with nss fw that is at this point an entire system running in parallel and ath11k that is probably a defective arm chip running a custom system)
But sorry, i got off tracked ahahha
(and even r7800 wasn't and is not perfect considering the trash krait cpu (that is known to be buggy and decide to crash with some very rare condition) and the fact that is working at half the speed as nss core doesn't work)
Well, to be fair to QCA, the offload framework was non-existence in the Linux kernel initially, which resulted in them developing the SFE POC driver. Broadcom have something similar in the form of CTF/FA. Both are the result of the Linux kernel being developed mainly for x86/x64 where it has enough CPU power to offset the overhead of netfilter while the MIPS/ARM SoCs are woefully underpowered for the Linux kernel when it comes to pushing packets thru 1Gbps line.
I think the offload framework in the Linux kernel we have now was born off the work of QCA and Broadcom.
@dimfish: Can you tell me where you repository is? So I can build it myself?