OpenWrt Support for Armor G5 (NBG7815)

For Developers
791

Yes, this approach is not going to work, same problem as with cal data. In order to properly fix it, ath11k needs to read the mac from dts via of_get_mac_address, in ath10k this was already added. In ath11k mac.c there is already device_get_mac_address(ab->dev, mac_addr);

after that function this should be added:

mac = of_get_mac_address(ar->dev->of_node);
if (!IS_ERR(mac))
ether_addr_copy(ar->mac_addr, mac);

like in this commit:

https://patchwork.kernel.org/project/linux-wireless/patch/20200927192515.86-1-ansuelsmth@gmail.com/

Then add the definition to dts that reads mac from nvmem.

3 Likes
792

You can use a function from this PR to modify MAC address in pre-caldata.

1 Like
793

Hmm. You guys think I should withdraw my PR if there is another PR dealing with it in progress? I do not insist on it.

I mean for me this is not really an issue because I can fix this by myself with this script. But in my opinion this is bad for other users. Because the client is going for BSSID too. If its not there or different then the client is asking for a password respectivley it is identifying a new network and doing nothing. Which is annyoing if you just reboot or turn your device on/off.

EDIT: I just saw it is for certain devices only in this PR. And it does just remove regdom to make it possible to change the MAC for those devices.

794

You don't need to remove regdomain. You can set only MAC addresses like this:

	zyxel,nbg7815)
		caldata_extract "0:art" 0x1000 0x20000
		label_mac=$(get_mac_label)
		ath11k_patch_mac $(macaddr_add $label_mac 3) 1
		ath11k_patch_mac $(macaddr_add $label_mac 2) 2
		ath11k_patch_mac $(macaddr_add $label_mac 4) 3

I'm not sure about the order.

1 Like
795

Y, that is what my PR is about. But the more elegant way is to use the driver and the DTS file instead of a userland script. Which has to be triggered every time I change sth. in wifi settings.

EDIT:

The hack for MX4200 and RAX120v2 will elminate the 11_fix_wifi_mac script for this devices and will use the 11-ath11k-caldata script instead. Which would run once only.

We could also try to push ours into this script too.

But I don't know which is the correct way to do it. Because they made this fix script for a reason I think.

I would need input from others here what to do ...

EDIT2:

I've looked into this PR from testuser7 and tried to mimick it on my running system and I failed. ;D
If I understand it correct. They basically patch the board.bin with the MAC's. Therefor you need the offset were the MAC's are within the extracted board.bin and generate a new valid csum for the file to then (re-)load it via driver.

They operate with what is within extracted board.bin. We have here:
1st three octets are 00:03:7F (typical Atheros MAC). The following octets are 12 34 56-5B.

I don't know if the offset where the MAC's are is individual for each board.bin. Maybe I will do a build with this patch and find out.

@KONG

While I think this would be the best path forward how would a valid entry look like (given the few lines within the driver would be sufficient)? I've tried this approach in the past and failed because I didn't know that the driver was lacking support for it.

For this device we have:

			partition@600000 {
				compatible = "u-boot,env";
				label = "0:appsblenv";
				reg = <0x600000 0x10000>;

				macaddr_lan: ethaddr {
					#nvmem-cell-cells = <1>;
				};
			};

If I look for other devices (IPQ806x) I would come up with sth. like this:

&wifi0 {
	status = "okay";
	nvmem-cells = <&macaddr_lan 2>;
	nvmem-cell-names = "mac-address";
	qcom,ath11k-calibration-variant = "Zyxel-NBG7815";
};

&wifi1 {
	status = "okay";
	nvmem-cells = <&macaddr_lan 3>;
	nvmem-cell-names = "mac-address";
	qcom,ath11k-calibration-variant = "Zyxel-NBG7815";
};

&wifi2 {
	status = "okay";
	nvmem-cells = <&macaddr_lan 4>;
	nvmem-cell-names = "mac-address";
	qcom,ath11k-calibration-variant = "Zyxel-NBG7815";
};

But we do not have three wifi device paths. There is only one. I would guess that this is not working this way. Because the driver is not supporting it for whatever reason. I would guess it's the the implementation of the hardware.
I would also argue that noone would push patching the board.bin if it would be an easy task with DTS.

1 Like
796

I think the best solution would be to find the actual bug, that prevents cal data extraction through hotplug. I have done some debugging yesterday to see how the whole process works from the driver call to fecth the calibration data down to the actual hotplug call.
This all looks okay. But when blockd hotplug action runs it triggers something that causes an hw issue.

If hotplug cal data extraction works as expected, then @lytr approach would be the best way. I have not checked if removing regdomain from caldata fixes the regdomain issues on the armor.

@asvio told me, that it does not happen on the nss builds, so next step is to compare the nss dts to the one without nss. Maybe there is some difference in hw configuration around usb, bus etc., that is not nss specific

Update: The wifi not starting bug also affects other units, e.g. one of the reports among others I found:

So it looks like the armor is not the only one that gets hit by this and blockd with it's hotplug actions just changes timing, which then leads to this. With nss pacthes it is pure luck, that it gets not triggered.

1 Like
797

Sorry for my ignorance, but what is the purpose of having 2 of the qcn5054 4x4 wifi chips? Is it so that they can be combined into a 8x8 mimo setting in the original firmware?

Is there a (software/hardware) solution to achieve something similar from OpenWRT side? I guess the question applies to other ipq807x routers as well.

798

Not possible with ath11k.

The combining of 2 QCA5054 only works with proprietary QCA-WIFI (afaik)

1 Like
799

Regarding the random MAC issue: I've dealt with the PR from testuser7. It is working with this PR. I did only test vanilla 6.6. No blockd or sth. else involved.

zyxel,nbg7815)
       caldata_extract "0:art" 0x1000 0x20000
       label_mac=$(get_mac_label)
       ath11k_patch_mac $(macaddr_add $label_mac 2) 0 
       ath11k_patch_mac $(macaddr_add $label_mac 3) 1 
       ath11k_patch_mac $(macaddr_add $label_mac 4) 2 
       ath11k_fix_caldata
       ;;

EDIT: The order in the patch got aglined to standard like ten hours ago. So it's not 1 2 3 anymore. Now its 0 1 2. I've changed it accordingly.

2 Likes
800

Thank you! So we can use this code in 11-ath11k-caldata file or in 11_fix_wifi_mac?

801

Well. ATM there is only one valid way to fix random MAC using 11_fix_wifi_mac file (for official builds). For dropping this file and using 11-ath11k-caldata file you would have to do your own build and pull the commits from testuser7's PR: https://github.com/openwrt/openwrt/pull/14512

1 Like
802

I forgot to say that i build myself the qosmio nss wifi version with some additions from asvio repository. So i'll try to build including the #14512 PR. Thank you.
Last thing, if i build with #14512 PR i need always the "precal loading" patches from here https://github.com/ricsc/openwrt/commit/77b9bee97696ef4342befde530b4d8fb3234d634 and here https://github.com/ricsc/openwrt/commit/6d71eba4bb5b79a7af95d2cc48114448a11ce911
Thanks again

803

I know this two commits. They are meant to circumvent the "no-wifi-after-first-boot" issue. I have no clue how this would interfere with the PR from testuser7.
But I have a guess:

As caldata is accessed directly by via nvmem (declared within DTS) the extracted and patched calibration file will never be in play. So you have to decide by your own. If you use the normal builds and using those 2 commits I would stick to the old approach using 11_fix_wifi_mac file.

For NSS builds I don't know. I've read that there is no 1st boot bug. Which would mean you would not even need those two commits. But that's sth. others doing NSS builds have to answer.

2 Likes
804

If your are using qosmio's nss build you can add first @pwned commit that it is working well for me.

1 Like
805

I have withdrawn/closed this PR for now. In favor for the PR from testuser7. If this is merged I will open a new PR for this device. Because it does not make much sense to push this now if it is supposed to change. I have no clue how long such a closed commit will linger around on github.

806

The bug exists but it affects the loading of the nss firmware and the problem is transferred to another site

1 Like
807

thank you @asvio @pwned
now i'm building qosmio's nss with #14512 PR and editing the ath11-k-caldata file, without the "precal loading" patches. I'll let you know if it works.
Otherwise i'll build editing the 11_fix_wifi_mac as @asvio said and tested.

UPDATE: just flashed qosmio's nss wifi branch with #14512PR and modified athk11-caldata file with nbg7815 entries, without "precal" patches. The system is up from only 15 minutes but all seems working fine. No problem with wifi at boot and mac address is ok.

1 Like
808

does 160mhz work with these patches?

810

i just patched my build with those 2 commits.

patched fine, installed fine, adapters both came up.

still no 160mhz.

i did not check if my wifi mac was changing before / is consistent now but no negative effects after an hour of uptime.

1 Like
811

Did you include blockd package on your build?