diff mbox series

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

Message ID 20190321154327.3872-1-markus.scheck1@gmail.com
State Accepted, archived
Delegated to: Petr Štetiar
Headers show
Series [OpenWrt-Devel,v2] ath79: add support for OCEDO Ursus | expand

Commit Message

markus.scheck1@gmail.com March 21, 2019, 3:43 p.m. UTC 
From: Markus Scheck <markus.scheck1@gmail.com>

SOC:   Qualcomm Atheros QCA9558
RAM:   128MB
FLASH: 16MB (Macronix MX25L12845EMI-10G)
WLAN1: QCA9558 2.4GHz 802.11bgn 3SS
WLAN2: QCA9880 5GHz 802.11ac 3SS
LED:   Power, LAN1, LAN2, 2.4GHz, 5GHz
Serial:Next to SPI Flash,
       Pinout is 3V3 - GND - TX - RX (Square Pin is 3V3)
       The Serial setting is 115200-8-N-1

INSTALLATION:

1. Serve an OpenWrt ramdisk image named "ursus.bin".
   Set your IP-address to 192.168.100.8/24.
2. Connect to the serial. Power up the device and interrupt
   the boot process.
3. Set the correct bootcmd with
   > setenv bootcmd run bootcmd_1
   > saveenv
4. Run
   > tftpboot 0x81000000 ursus.bin
   > bootm 0x81000000
5. Wait for OpenWrt to boot up.
6. Transfer OpenWrt sysupdate image and flash via sysupgrade.

Signed-off-by: Markus Scheck <markus.scheck1@gmail.com>
---
 .../ath79/base-files/etc/board.d/02_network   |   3 +-
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   3 +-
 .../linux/ath79/dts/qca9558_ocedo_ursus.dts   | 148 ++++++++++++++++++
 target/linux/ath79/image/generic.mk           |   9 ++
 4 files changed, 161 insertions(+), 2 deletions(-)
 create mode 100644 target/linux/ath79/dts/qca9558_ocedo_ursus.dts

Comments

Petr Štetiar April 1, 2019, 10:19 p.m. UTC | #1 
markus.scheck1@gmail.com <markus.scheck1@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@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?

> +	phy2: ethernet-phy@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>;

what is expected phy-mode here?

> +&eth1 {
> +	status = "okay";

add newline here

> +	mtd-mac-address = <&art 0x12>;

	mtd-mac-address = <&art 0xc>; ?

> +	phy-handle = <&phy2>;
> +	pll-data = <0x3000101 0x101 0x1313>;

what is expected phy-mode here?

	pll-data = <0x0300000 0x101 0x1313>;

1. https://github.com/openwrt/openwrt/pull/1016/commits/6bc138ec46ce956783aba7f8c83608982030a8be

-- ynezz
David Bauer April 2, 2019, 7:47 p.m. UTC | #2 
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@gmail.com <markus.scheck1@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@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@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@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
>
Petr Štetiar April 3, 2019, 7:35 a.m. UTC | #3 
David Bauer <mail@david-bauer.net> [2019-04-02 21:47:23]:

Hi,

> I've tried your suggenstions

well, it was rather copy&paste from that ancient PR to just make the
difference obvious at first sight, and why I was wondering about the
difference.

> 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.

ok, I'll add this little detail to the commit message.

> >> +	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.

thanks for the verification.

> >> +	mtd-mac-address = <&art 0x12>;
> > 
> > 	mtd-mac-address = <&art 0xc>; ?
> 
> 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.

ok.

> >> +	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.

ok, so it seems like this patch is fine with you and you've already tested it
as it is, so can I add your Tested-by or Reviewed-by as well?

-- ynezz
David Bauer April 6, 2019, 3:50 p.m. UTC | #4 
Hello Petr,

sorry for the late reply, I was very busy last week.

On 03.04.19 09:35, Petr Štetiar wrote:
> ok, so it seems like this patch is fine with you and you've already tested it
> as it is, so can I add your Tested-by or Reviewed-by as well?

Tested-by: David Bauer <mail@david-bauer.net>

Maybe you can alter the LED names and the newline issue on your side
avoiding a v2 :)

Best wishes
David

> 
> -- ynezz
>
Petr Štetiar April 8, 2019, 10:30 a.m. UTC | #5 
David Bauer <mail@david-bauer.net> [2019-04-06 17:50:55]:

Hi,

> Tested-by: David Bauer <mail@david-bauer.net>
> 
> Maybe you can alter the LED names and the newline issue on your side
> avoiding a v2 :)

Thanks, merged it into my staging tree.

-- ynezz
diff mbox series

Patch

diff --git a/target/linux/ath79/base-files/etc/board.d/02_network b/target/linux/ath79/base-files/etc/board.d/02_network
index 62318ee232..69b5c265b4 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -65,7 +65,8 @@  ath79_setup_interfaces()
 			"0@eth0" "1:lan:1" "3:lan:4" "4:lan:3" "5:lan:2" "2:wan"
 		;;
 	devolo,dvl1200e|\
-	devolo,dvl1750e)
+	devolo,dvl1750e|\
+	ocedo,ursus)
 		ucidef_set_interface_lan "eth0 eth1"
 		;;
 	dlink,dir-825-b1)
diff --git a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8651c97099..661008da8f 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -119,7 +119,8 @@  case "$FIRMWARE" in
 		ath10kcal_extract "art" 20480 2116
 		ath10kcal_patch_mac_crc $(mtd_get_mac_text board_data 2176)
 		;;
-	ocedo,koala)
+	ocedo,koala|\
+	ocedo,ursus)
 		ath10kcal_extract "art" 20480 2116
 		ath10kcal_patch_mac $(mtd_get_mac_binary art 12)
 		;;
diff --git a/target/linux/ath79/dts/qca9558_ocedo_ursus.dts b/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
new file mode 100644
index 0000000000..ddd6e3047e
--- /dev/null
+++ b/target/linux/ath79/dts/qca9558_ocedo_ursus.dts
@@ -0,0 +1,148 @@ 
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include <dt-bindings/gpio/gpio.h>
+#include <dt-bindings/input/input.h>
+
+#include "qca9557.dtsi"
+
+/ {
+	compatible = "ocedo,ursus", "qca,qca9557";
+	model = "OCEDO Ursus";
+
+	chosen {
+		bootargs = "console=ttyS0,115200n8";
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+
+		wifi2 {
+			label = "ursus:green:wlan2";
+			gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "phy1tpt";
+		};
+
+		wifi5 {
+			label = "ursus:green:wlan5";
+			gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+			linux,default-trigger = "phy0tpt";
+		};
+
+	};
+
+};
+
+&pcie1 {
+	status = "okay";
+};
+
+&uart {
+	status = "okay";
+};
+
+&pll {
+	clocks = <&extosc>;
+};
+
+&spi {
+	status = "okay";
+	num-cs = <1>;
+
+	flash@0 {
+		compatible = "jedec,spi-nor";
+		reg = <0>;
+		spi-max-frequency = <25000000>;
+
+		partitions {
+			compatible = "fixed-partitions";
+			#address-cells = <1>;
+			#size-cells = <1>;
+
+			uboot: partition@0 {
+				label = "u-boot";
+				reg = <0x000000 0x040000>;
+				read-only;
+			};
+
+			partition@40000 {
+				label = "u-boot-env";
+				reg = <0x040000 0x010000>;
+			};
+
+			partition@50000 {
+				compatible = "denx,uimage";
+				label = "firmware";
+				reg = <0x050000 0x740000>;
+			};
+
+			partition@790000 {
+				label = "vendor";
+				reg = <0x790000 0x740000>;
+				read-only;
+			};
+
+			partition@ed0000 {
+				label = "data";
+				reg = <0xed0000 0x110000>;
+				read-only;
+			};
+
+			partition@fe0000 {
+				label = "id";
+				reg = <0xfe0000 0x010000>;
+				read-only;
+			};
+
+			art: partition@ff0000 {
+				label = "art";
+				reg = <0xff0000 0x010000>;
+				read-only;
+			};
+		};
+	};
+};
+
+&wmac {
+	status = "okay";
+
+	mtd-cal-data = <&art 0x1000>;
+	mtd-mac-address = <&art 0x06>;
+};
+
+&mdio0 {
+	status = "okay";
+
+	phy1: ethernet-phy@1 {
+		reg = <1>;
+	};
+
+	phy2: ethernet-phy@2 {
+		reg = <2>;
+	};
+};
+
+&eth0 {
+	status = "okay";
+	mtd-mac-address = <&art 0x00>;
+	phy-handle = <&phy1>;
+	pll-data = <0xa6000000 0x80000101 0x80001313>;
+
+	gmac_config: gmac-config {
+		device = <&gmac>;
+
+		rxdv-delay = <3>;
+		rxd-delay = <3>;
+		txen-delay = <0>;
+		txd-delay = <0>;
+		rgmii-enabled = <1>;
+	};
+};
+
+&eth1 {
+	status = "okay";
+	mtd-mac-address = <&art 0x12>;
+	phy-handle = <&phy2>;
+	pll-data = <0x3000101 0x101 0x1313>;
+};
diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk
index ddf0e62898..042a342034 100644
--- a/target/linux/ath79/image/generic.mk
+++ b/target/linux/ath79/image/generic.mk
@@ -468,6 +468,15 @@  define Device/ocedo_raccoon
 endef
 TARGET_DEVICES += ocedo_raccoon
 
+define Device/ocedo_ursus
+  ATH_SOC := qca9558
+  DEVICE_TITLE := OCEDO Ursus
+  DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct
+  IMAGE_SIZE := 7424k
+  IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata | check-size $$$$(IMAGE_SIZE)
+endef
+TARGET_DEVICES += ocedo_ursus
+
 define Device/openmesh_om5p-ac-v2
   ATH_SOC := qca9558
   DEVICE_TITLE := OpenMesh OM5P-AC v2