QCA9984 is sorted, it required custom BDF.
Now I am working on getting GMACs working properly.
Since now WAN port wont work but setting WAN to port 4 works
1 Like
Yeah, I saw your email to ath10k 
. But knowing Kalle, they will rot there for a while 
Hm, that's odd. From past experience with the FB4040/AC58U/NBG6617, the uci_ network stuff in 02_networks together with the standard setup for the QCA8075 should just work for the Orbi too.
(But no, I wouldn't be surprised if netgear added more secret sauce there as well)
I know that they will sit there for a month or two until the pile stacks up and then Kalle will do it in one go.
Its good that I checked the latest 2.1.4.16 firmware for BDF file differences and there actually was a different file for 5GHz radio,that matches the Netgear changelog as the 2.1.3.32 version befor 2.1.4.16 was terrible.
Radios would stop passing packets completely.
I tried to borrow the configuration from others with QCA8075 "switch" and change it to mark port1 as WAN since that is what is printed on the device.
But then port would not work,changing it to port4 it works fine.
From DTS differences Netgear swapped gmac0 and gmac1
I tried to replicate it but then ess driver would print that link rate is 0 and port would not work.
Ahh, its just hacks on hacks.
Hm, maybe this works (or at least isn't far off):
in the dts:
@gmac0 {
vlan_tag = <1 0x2e>;
};
@gmac1 {
vlan_tag = <2 0x01>;
};
in 02_networks
ucidef_set_interfaces_lan_wan "eth0" "eth1"
ucidef_add_switch "switch0" \
"0u@eth0" "2:lan" "3:lan" "4:lan" "5:lan"
or
ucidef_set_interfaces_lan_wan "eth0" "eth1"
ucidef_add_switch "switch0" \
"0u@eth0" "1:lan" "2:lan" "3:lan" "4:lan"
Qualcomm skimmed on the ethernet MACs on the IPQ40XX series. There is only one real GMAC.
The whole gmac0 and gmac1 stuff that we know from IPQ806x, AR71xx etc. is just "emulated" by a "clever" integrated switch (based on the QCA8337 - but with only one CPU port and 5 PHY-like phys) and some built-in vlan-handling offloadly features of the MAC hardware.
Will give it a go tommorow.
It looks like QCA decided to shorten R&D on stuff like that and to save some cash on not too much external expansion possible due to lack of stuff like RGMII interface on IPQ4018 so you really cant even connect a traditional switch.
As far as I know VLANs really dont work in OpenWrt under IPQ40XX.
I have been thinking of a simplest way to solve this EFI.c and MMC Test mess Netgear uses.
It looks like it aint gonna get simpler than a custom kernel module and even that is gonna require patching EFI.c to append the correct rootfs to the kernel.
Even in this state where most of the stuff works in a hardcoded way, OpenWrt is running way better than stock firmware.
Especially as configuration and even radio performance goes, I feel like there is less buffering.
No idea, the IPQ40XX are supposed to have 2.5GN-BASE-T support though. So maybe there will be a small update in the future and it will make sense then. As for RGMII: the MR33 uses a "good old" AR8035 single-phy which is connected with RGMII. But again, it's neither here or there:
They could, if the device was honest about the built-in switch and would disable the vlan stuff. I had this patch for a while:
This worked reasonably well, it will also allows you to remap the WAN/LAN ports to your heart's content . But it was never accepted, because John is preparing a "new" DSA based switch driver someday that will do away with all of it... or not.
Hm, I know that feeling.
I also have WAs for the RT-AC58U:
https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/patches-4.14/400-mtd-ubi-add-quirk-to-autoload-ubi-on-rt-ac58u.patch
In a way, I had the dumb luck that quirks/hacks where easy to "hide" or already established code.
But in your case, you should ask around what the preferred method could look like. Otherwise, you could be stuck in review hell.
Well, I remember reading about 2.5G interface from the datasheet.
From what I remember its TRGMII and its traditionaly used for SFP module altough to use it you need something like AR8033 since SFP is serial based so SGMII is needed.
Hm, your patch looks interesting as current state of having VLAN-s that arent really userland configurable is not perfect.
I wish that Netgear provided a cmdline from the bootloader,but it does not.
At least by default, they have commands in the bootloader which check which partition is used since dual firmware is utilized but if you dont invoke it manually bootloader would not pass it.
Take a look at the current EFI.c patch to get the thing booting with a really weird 34 partition custom layout.
This way they are wasting so much space as kernel+rootfs currently have only 70MB alocated for each of firmwares.
In the end 1860MB gets wasted as "reserved" partition which from what I saw does not contain anything.
Not to mention that the rest of partition also usually contains stuff that has no real connection to the device.
The following patch will append the custom partition layout,but somehow appending the desired partition as a MAJOR(ROOT_DEV) does not get the kernel actually mounting that partition.
I gotta ask on the mailing list,otherwise this wont get upstreamed ever
Are you sure about that TRGMII interface? Since from what I know "Turbo RGMII" is a MediaTek "innovation". And the IPQ40XX SoC supports a single PHY with either PSGMII, QSGMII or RGMII. This is supported by this QCA8075 document that lists support for PSGMII and QSGMII.
Well, there's the blkdevparts command line parameter that allows "Manual partition parsing of block device(s) for embedded devices based on command line input." This might do the
might do the job. (Although, specifying all partitions is not going to be fun).
https://www.kernel.org/doc/Documentation/block/cmdline-partition.txt
Looked at the datasheet again and you are right.
There is no mention of TRGMII, only RGMII, and PSGMII.
I gotta take a look at that blkdevparts
I have to add:
The blkdevpart needs CONFIG_BLK_CMDLINE_PARSER (currently its not enabled, but I think nobody would complain about it).
And the ipq40xx-target already comes with the "bootargs-append" hack.
https://github.com/openwrt/openwrt/blob/master/target/linux/ipq40xx/patches-4.14/997-device_tree_cmdline.patch
so, in case netgear's bootloader does something horrible to the bootargs, you can just pass the blkdevparts in the bootargs-append overwrite.
blkdevparts is really a part of what I was looking for.
It allows not having a custom partition table hardcoded in some driver.
But I still dont have a clue how to read which firmware is active from MMC and then append that as rootfs.
Netgears U-boot does not pass any bootargs at all
Tested blkdevparts and they have no effect since the EMMC already has a partition table.
Hm, there is an issue with the QCA9984.
Even with custom BDF loaded its firmware crashes after couple of minutes and takes down the ath10k driver.
I gotta test out couple more firmware version and CT one too.
This is really weird
Tested out even the latest version of 3.6.0.1 and it crashes it after couple of minutes regardless whether it has load on it or not.
If not crashed it takes load without an issue.
I now used CT version of firmware and even that crashes the driver
Never had the chance to get a QCA9984. But I do know that they are having issues with VHT160. Maybe your crash is caused by a VHT160 client?
Well, it cant be due to VHT160 as I only configured it to do VHT40.
It can, in theory, do VHT160 but I don't think that it ever worked in ath10k.
It's weird that it works fine for a couple of minutes and then simply crashes regardless of load.
hm, I do wonder why there isn't a "firmware has crashed" message though. Since you could post that to the ath10k ML (and wait for a non-answer ).
But given that you said:
I wouldn't be surprised if there was more secret netgear sauce in their QSDK for this 9984.
Yeah, its really weird.
I will post it to ath10k mailing list, but chance of an answer is non existent.
I havent checked if BDFs for QCA9984 differ in 2 versions, I only checked for IPQ4019 BDFs and those differ.
Atleast for 5GHZ IPQ4019 radio.
There could easily be some more hidden hardcoded hacks.
But there could some fixes in the never version of ath10k that were never backported.
One more (maybe) problem, I just noticed: The ath10k-ct driver does not say which board-variant it is using. This info should be available on the serial console though. (If you installed 9984-fw-ct on top of QCA's 9984-fw, the custom board-2.bin will be gone since the 9984-fw-ct comes with a board-2.bin file as well. So it could be that you are testing the -ct driver with the QCA reference board data that does not belong to the 9984 in this Orbi)
you mean that coconut codeaurora branch?
https://source.codeaurora.org/quic/qsdk/oss/system/feeds/wlan-open/tree/mac80211/patches/?h=coconut
Hm, well stock ath10k driver and firmware combo also did not display the variant.
Its displayed only if the board file cant be found.
I am not using the ath10k-ct driver, just the drop in compatible CT firmware.
But I can easily check which board file is there.
I was talking about backports from ath10k version is never kernels, for say 4.18
Checked and the board-2.bin there is my custom one
robimarko@builder-temp:~/qca-swiss-army-knife/tools/scripts/ath10k$ ./ath10k-bdencoder -i board-2.bin
FileSize: 12176
FileCRC32: d2427183
FileMD5: 8aab000a31a094e4a5d426789e32f7bf
BoardNames[0]: 'bus=pci,bmi-chip-id=0,bmi-board-id=6,variant=Netgear-Orbi-Pro-SRK60'
BoardLength[0]: 12064
BoardCRC32[0]: 083fd651
BoardMD5[0]: 1725321919ee4dac521db1b3253c8f8d