[OpenWrt-Devel] [PATCH v2] ath79: add support for OCEDO Ursus

David Bauer mail at david-bauer.net
Tue Apr 2 15:47:23 EDT 2019


Hello,

I've tried your suggenstions on my unit (and try to provide some
information from my work with the other two APs from OCEDO/Riverbed).

On 02.04.19 00:19, Petr Štetiar wrote:
> markus.scheck1 at gmail.com <markus.scheck1 at gmail.com> [2019-03-21 16:43:27]:
> 
> Hi,
> 
>> +			label = "ursus:green:wlan2";
>> +			label = "ursus:green:wlan5";
> 
> could we please make it wlan2g and wlan5g in order to stay consistent?
> 
> I found this old PR[1] for ar71xx, which makes me wonder if the stuff bellow
> is correct.
> 
>> +&mdio0 {
>> +	status = "okay";
>> +
>> +	phy1: ethernet-phy at 1 {
>> +		reg = <1>;
>> +	};
>> +
> 
> In that ar71xx code it seems, that phy2 is connected through GMAC1/SGMII. Can
> you please explain in your commit message what is connected where in more
> details?

The OCEDO Ursus / Riverbed AP5r is a bit odd here as the MDIO lines for
the GMAC1 PHY is connected to the MDIO interface of GMAC0 (nothing
connected to GMAC1 MDIO). This is also how it's interfaced in the ar71xx
PR from last year ago.

> 
>> +	phy2: ethernet-phy at 2 {
>> +		reg = <2>;
>> +	};
>> +};
>> +
>> +&eth0 {
>> +	status = "okay";
> 
> add newline here
> 
>> +	mtd-mac-address = <&art 0x00>;
>> +	phy-handle = <&phy1>;
>> +	pll-data = <0xa6000000 0x80000101 0x80001313>;
> 
> 	pll-data = <0xae000000 0xa0000101 0xa0001313>;

I'm experiencing low throughput with this. The PLL-values from the PR
also match the ones i get via devmem from the vendor SteelWrt.

> 
> what is expected phy-mode here?

This information seems to be redundant to me as QCA9558 only supports
RGMII/SGMII and this information is already present in the inherited
qca9557.dtsi. While we could (theoretically) use the mux to switch the
interfaces between the GMACs i don't see support for it currently
neither in ar71xx nor ath79.

> 
>> +&eth1 {
>> +	status = "okay";
> 
> add newline here
> 
>> +	mtd-mac-address = <&art 0x12>;
> 
> 	mtd-mac-address = <&art 0xc>; ?

It seems the original firmware derives the MAC addresses for the
interfaces from the local OCEDO/Riverbed gateway the AP is connected to
(note the devices are not intended to be used independently). The device
itself has 4 unique addresses stored in the ART partition. The first one
used for eth0 (only MAC address matching the original firmware), the
other ones seem to be for IPSec tunnels but they are also device-unique.

Because of that, I've decided to distribute the 3 i had for the Raccoon
and Koala across eth0/wlan0/wlan1. This patch seems to match the scheme
of the existing two, adding the forth IP address to eth1, which i would
also aim for.

> 
>> +	phy-handle = <&phy2>;
>> +	pll-data = <0x3000101 0x101 0x1313>;
> 
> what is expected phy-mode here?
> 
> 	pll-data = <0x0300000 0x101 0x1313>;

I get around ~2% of packet-loss with these. I know they are used in the
ar71xx PR, but as the ones currently used in this patch are matching the
ones from SteelWrt I'm more confident with whats present here.

Best wishes
David

> 
> 1. https://github.com/openwrt/openwrt/pull/1016/commits/6bc138ec46ce956783aba7f8c83608982030a8be
> 
> -- ynezz
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel at lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> 

_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list