ath79: add support for COMFAST CF-E313AC#1942
ath79: add support for COMFAST CF-E313AC#1942rogerpueyo wants to merge 1 commit intoopenwrt:masterfrom
Conversation
ynezz
added
RFC
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
from
06dedc7 to
9028a62
Compare
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
from
9028a62 to
b24695d
Compare
|
Sorry for bugging you, @ynezz . I made the required changes so that the commit does not have conflicts with master. Would you please be so kind as to remove the "needs changes" tag, to see if the PR gets more attention? Thanks! |
From my point of view this PR still needs changes and it doesn't mean, that PRs without
I would say, that this is correct behavior. Add
Although being marketed as 16M, it's using just the first half of the memory, maybe it's for some reason? It could be defective memory or some other issues, who knows. |
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
2 times, most recently
from
450d689 to
d0532b0
Compare
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
2 times, most recently
from
a5b007c to
333f40a
Compare
rogerpueyo
changed the title
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
from
333f40a to
5229234
Compare
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
4 times, most recently
from
9f50e95 to
6f47862
Compare
|
Dear @adrianschmutzler, Thank you very much for reviewing this pull request. I've made the changes you suggested, rebased master and also fixed the eth0/eth1 wan/lan assignation (a recent patch in ath79 had swapped them). |
|
You're welcome. Note that I did only a selective review, so there are parts I have not checked. |
|
Dear @ynezz , I am sorry but I did not have access to the device for a few weeks; now it's back on my desk.
Here are the dmesg outputs:
In both cases I am be able to use the interface in equal terms, but the MAC address in the latter one is autogenerated, instead of using the appropriate one. |
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
3 times, most recently
from
8c03d7e to
f7e00fe
Compare
|
I'm currently working on a PR to store the label-mac-address in the DTS (#2159). I would appreciate if you could provide information about your device: Now check which of those returned MAC addresses matches the one on the label/sticker/case of your device and tell me the device-tree path leading to it. Note that you do not have to post your MAC addresses here, but just a statement about which match, e.g. like There may be one, two or no paths giving the correct address. It may also happen that the |
|
Unfortunately, my description is slightly incorrect. The MAC addresses are stored binary, so you can't read with The include is obviously only required once. Sorry. |
|
And you need another rebase, unfortunately ... |
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
2 times, most recently
from
9730fd7 to
2d3bf1c
Compare
There was a problem hiding this comment.
The decimal values in the two lines above should be updated to hex values (this has been changed treewide recently, just have a look at the other devices in the file now).
There was a problem hiding this comment.
True. I hadn't seen this changes, it makes sense. Fixed and rebased master.
There was a problem hiding this comment.
Please also change the second line: 4098 -> 0x1002
There was a problem hiding this comment.
Sorry, I should have checked more carefully myself.
There was a problem hiding this comment.
BTW: Have you checked that there actually is a (correct) MAC address in this location? I'm just asking because this location normally is used by &wmac, which you do not have here. So it looks odd that the vendor would put the address there.
Just want to make sure ...
There was a problem hiding this comment.
Hmm, it's even more complicated:
ucidef_set_interfaces_lan_wan "eth0" "eth1" is referring to ethX on the running device, so what I wrote refers to the running device, too:
eth0 0x0 (=lan)
eth1 0x1002 (=wan)
wlan 0x6
In DTS, eth0/eth1 are swapped, so we have
ð0 0x1002 (=wan)
ð1 0x0 (=lan)
So, based on your current commit state, you need to change ð0 to 0x1002 and the WiFi setup to 0x6 ...
(This still assumes that your ports are correctly assigned to WAN and LAN...)
There was a problem hiding this comment.
Thank you very much for your detailed analysis.
Thank you for reviewing the PR! 🤗
No matter what I'd like to say about people like the developers at this vendor, I would do the following:
1. The ports (!) should keep the same state (i.e. wan/lan) as in stock firmware.
👍 That's for granted, specially since they're labeled as LAN and WAN.
2. We cannot easily change what's eth0 and eth1 on the running device, so the assignment to wan and lan is determined by 1.
Well, kind of. I can use either the current configuration in the DTS file:
ð0 {
status = "okay";
phy-handle = <&swphy0>;
mtd-mac-address = <&art 0xXXX>;
gmac-config {
device = <&gmac>;
switch-phy-swap = <1>;
};
};
ð1 {
status = "okay";
mtd-mac-address = <&art 0xYYY>;
};
or this one which also works and does not swap eth0 and eth1:
ð0 {
status = "okay";
phy-handle = <&swphy4>;
mtd-mac-address = <&art 0xZZZ>;
};
ð1 {
status = "okay";
mtd-mac-address = <&art 0x0>;
mtd-mac-address = <&art 0xTTT>;
};
(then, of course, setting XXX/YYY/ZZZ/TTT to the correct values, and also 01_leds and 02_network).
Both work; which one is preferred? I'd rather stick with the first one because I like the "default" eth0=>LAN eth1=>WAN, but I have no other reasoning than that.
3. I would slightly prefer to base MAC assignment on what the ports are doing. This means the address found on the stock WAN port should be the address set for the OpenWrt WAN port. The port modes will be what most of the user care about, while the internal assignment of eth0/eth1 is hidden to the typical user. However, note the word "slightly" here, we could also have thrown a coin to decide.
👍 Same MACs on the physical ports as the stock firmware, I agree, is a must. Beyond that... I flipped a coin already in 2. 😃
So, assuming that the current ucidef_set_interfaces_lan_wan "eth0" "eth1" sets the port modes > correctly, I think this would be:
eth0 0x0
eth1 0x1002
wlan 0x6Hmm, it's even more complicated:
ucidef_set_interfaces_lan_wan "eth0" "eth1"is referring to ethX on the running device, so what I wrote refers to the running device, too:
eth0 0x0 (=lan)
eth1 0x1002 (=wan)
wlan 0x6In DTS, eth0/eth1 are swapped, so we have
ð0 0x1002 (=wan)
ð1 0x0 (=lan)So, based on your current commit state, you need to change ð0 to 0x1002 and the WiFi setup to 0x6 ...
(This still assumes that your ports are correctly assigned to WAN and LAN...)
That's right. Anyway, whatever ends up regarding point 2, I'll make sure the stock Ethernet port - MAC assignment is maintained.
And BTW: Have you checked what happens if you do not set the MAC address in 11_ath10k_caldata?
Normally, if you read caldata from 0x5000, it might automatically read the the MAC address from 0x5006 (which is present). So, as for the ethernet, it might be the case the radio is initialized with a valid address which is then overwritten by another one ...
(You do not need to check that, unless you are curious...)
It gets the mac at 0x5006 (40:A5:EF:2E:45:43) which, :open_mouth: surprise!, it's not the one used by the stock firmware :smile:
There was a problem hiding this comment.
If you swap eth0 and eth1 with switch-phy-swap, are you sure that both ports work in both cases? From my experience, only one of the settings made it possible to have both ports working, while with the other one only one port worked. So, in the end there was only one possible case.
There was a problem hiding this comment.
If you swap eth0 and eth1 with switch-phy-swap, are you sure that both ports work in both cases? From my experience, only one of the settings made it possible to have both ports working, while with the other one only one port worked. So, in the end there was only one possible case.
Hmmm... I'll double check and report.
There was a problem hiding this comment.
If you swap eth0 and eth1 with switch-phy-swap, are you sure that both ports work in both cases? From my experience, only one of the settings made it possible to have both ports working, while with the other one only one port worked. So, in the end there was only one possible case.
If I'm not doing anything wrong, https://github.com/rogerpueyo/openwrt/tree/ath79-cf-e313ac and https://github.com/rogerpueyo/openwrt/tree/ath79-cf-e313ac-no-swap are equivalent. In the first one I get eth0 for LAN, eth1 for WAN. In the second one I get eth0 for WAN, eth1 for LAN.
In both cases I'm able to use LAN/WAN correctly, iperf3 bandwidth is the same (~95 Mbps) so, unless if I'm missing something, I can't tell any practical difference.
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
3 times, most recently
from
56f635d to
e259d2d
Compare
On this device, it looks like we can arbitrarily choose whether we have switch-phy-swap enabled or not (with corresponding phy-handle adjustments). (I we can choose freely, I would prefer having the same order for eth0/eth1 on the running device as in DTS. Note that we still have to exploit 02_network to correct port modes here, as this is not relevant for the test.) |
|
@rogerpueyo If it comes out that we can choose freely, I would prefer the noswap path, as this one would have eth0/eth1 at runtime match the DTS ð0/ð1... |
|
@rogerpueyo One other thing: If we have sorted out which way to go, you should comment on the MAC address setup in the commit message, so our findings are preserved for anyone looking at this years later. I would put something like: In OPENWRT, this has been implemented to have the same MAC addresses as in stock firmware based on the device ports: |
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
from
e259d2d to
0d9825a
Compare
I think I prefer the swap one, I've pushed the two versions, with their corresponding commit notes, to the following branches: @adrianschmutzler, if you merge this PR into your staging tree, please add yourself as a contributor to the commit 🙏 |
|
@rogerpueyo I'm not a core-developer, I do not have commit-access. |
It's preferred to use the first gmac which is directly connected to a PHY as wan port because we can't get port link status from the second one connecting to switch. We don't care about link status on lan ports but this is helpful when the port is used as wan (e.g. restart DHCP negotiation when we re-plug wan cable.) |
Hmm, but it looks like this will still allow both versions, if we set WAN/LAN correctly in 02_network? So, this PR should be ready for review now... |
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
2 times, most recently
from
15c7dd5 to
9b2f94a
Compare
Thanks for your comments, that makes complete sense. To achieve this behaviour, I've got to use: which allows detecting link changes on the WAN port: Instead, using @adrianschmutzler now comes the funny part.
The is the one that really works. Setting it to <0> (i.e., not setting it) and using the appropriate
I think so too. I've rebased master and pushed. Thank you for your help! :) |
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
from
9b2f94a to
f9e22a8
Compare
|
Rebased master. |
|
@blocktrron @981213 @ynezz Maybe have a look at this one, it's lying around for a long time already and should be in a good state. |
This patch adds support for the COMFAST CF-E313AC, an outdoor wireless CPE with two Ethernet ports and a 802.11ac radio. Specifications: - QCA9531 SoC - 650/400/216 MHz (CPU/DDR/AHB) - 1x 10/100 Mbps WAN Ethernet, 48V PoE-in - 1x 10/100 Mbps LAN Ethernet, pass-through 48V PoE-out - 1x manual pass-through PoE switch - 64 MB RAM (DDR2) - 16 MB FLASH - QCA9886 2T2R 5 GHz 802.11ac, 23 dBm - 12 dBi built-in antenna - POWER/LAN/WAN/WLAN green LEDs - 4x RSSI LEDs (2x red, 2x green) - UART (115200 8N1) Flashing instructions: The original firmware is based on OpenWrt so a sysupgrade image can be installed via the stock web GUI. Settings from the original firmware will be saved and restored on the new one, so a factory reset will be needed. To do so, once the new firmware is flashed, enter into failsafe mode by pressing the reset button several times during the boot process, while the WAN LED flashes, until it starts flashing faster. Once in failsafe mode, perform a factory reset as usual. Alternatively, the U-boot bootloader contains a recovery HTTP server to upload the firmware. Push the reset button while powering the device on and keep it pressed for >10 seconds. The device's LEDs will blink several times and the recovery page will be at http://192.168.1.1; use it to upload the sysupgrade image. Note: Four MAC addresses are stored in the "art" partition (read-only): - 0x0000: 40:A5:EF:AA:AA:A0 - 0x0006: 40:A5:EF:AA:AA:A2 - 0x1002: 40:A5:EF:AA:AA:A1 - 0x5006: 40:A5:EF:AA.AA:A3 (inside the 5 GHz calibration data) The stock firmware assigns MAC addresses to physical and virtual interfaces in a very particular way: - eth0 corresponds to the physical Ethernet port labeled as WAN - eth1 corresponds to the physical Ethernet port labeled as LAN - eth0 belongs to the bridge interface br-wan - eth1 belongs to the bridge interface br-lan - eth0 is assigned the MAC from 0x0 (*:A0) - eth1 is assigned the MAC from 0x1002 (*:A1) - br-wan is forced to use the MAC from 0x1002 (*:A1) - br-lan is forced to use the MAC from 0x0 (*:A0) - radio0 uses the calibration data from 0x5000 (which contains a valid MAC address, *:A3). However, it is overwritten by the one at 0x6 (*:A2) This commit preserves the LAN/WAN roles of the physical Ethernet ports (as labeled on the router) and the MAC addresses they expose by default (i.e., *:A0 on LAN, *:A1 on WAN), but swaps the position of the eth0/eth1 compared to the stock firmware: - eth0 corresponds to the physical Ethernet port labeled as LAN - eth1 corresponds to the physical Ethernet port labeled as WAN - eth0 belongs to the bridge interface br-lan - eth1 is the interface at @wan - eth0 is assigned the MAC from 0x0 (*:A0) - eth1 is assigned the MAC from 0x1002 (*:A1) - br-lan inherits the MAC from eth0 (*:A0) - @wan inherits the MAC from eth1 (*:A1) - radio0's MAC is overwritten to the one at 0x6 This way, eth0/eth1's positions differ from the stock firmware, but the weird MAC ressignations in br-lan/br-wan are avoided while the external behaviour of the router is maintained. Additionally, WAN port is connected to the PHY gmac, allowing to monitor the link status (e.g., to restart DHCP negotiation when plugging a cable). Signed-off-by: Roger Pueyo Centelles <[email protected]>
rogerpueyo
force-pushed
the
ath79-cf-e313ac
branch
from
f9e22a8 to
92e3a2b
Compare
|
Merged into my staging tree at: https://git.openwrt.org/?p=openwrt/staging/981213.git |
4 participants
This patch adds support for the COMFAST CF-E313AC, an outdoor wireless
CPE with two Ethernet ports and a 802.11ac radio (see patch below).
Everything is working fine but there are two issues for which I'd like to get some advise:
target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
I had to add "rm /lib/firmware/ath10k/QCA9888/hw2.0/board-2.bin", since
the driver tries to load board-2.bin (the default calibration data from the firmware package) first and, only when that file is not found, falls back to board.bin (the calibration data read from the flash).
I haven't seen this on any other device, so I guess there must be a more elegant way to deal with it. Any idea?
target/linux/ath79/dts/qca9531_comfast_cf-e313ac.dts
The device is equipped with a "w25q128" flash chip (16384 Kbytes) but the stock firmware image only used half of it (nvram partition finishes at 0x000000800000, i.e., 8192 Kbytes):
*** stock firmware bootlog ***
[...]
[ 0.730000] 0x000000000000-0x000000010000 : "u-boot"
[ 0.740000] 0x000000010000-0x000000020000 : "art"
[ 0.740000] 0x000000020000-0x0000001a0000 : "kernel"
[ 0.750000] 0x0000001a0000-0x0000007e0000 : "rootfs"
[ 0.760000] mtd: device 3 (rootfs) set to be root filesystem
[ 0.760000] 1 squashfs-split partitions found on MTD device rootfs
[ 0.770000] 0x0000006c0000-0x0000007e0000 : "rootfs_data"
[ 0.780000] 0x0000007e0000-0x0000007f0000 : "configs"
[ 0.780000] 0x0000007f0000-0x000000800000 : "nvram"
[ 0.790000] 0x000000020000-0x0000007e0000 : "firmware"
[...]
Is there a way to use the remaining half of the flash?
Any comments regarding these or other issues will be highly appreciated.