[OpenWrt-Devel,v2,2/2] ramips: Add support for ZBT WE1026-H
diff mbox series

Message ID 20190924104712.19812-3-kristian.evensen@gmail.com
State Changes Requested
Delegated to: John Crispin
Headers show
Series
  • Add support for the ZBT WE1026-H
Related show

Commit Message

Kristian Evensen Sept. 24, 2019, 10:47 a.m. UTC
This commit adds support for the ZBT WE1026-H, an outdoor AP with
support for adding an internal LTE modem. The detailed specs are:

* CPU: MT7620A
* 2x 10/100Mbps Ethernet (LAN port has passive PoE support).
* 16/32 MB Flash.
* 128/256 MB RAM.
* 1x USB 2.0 port.
* 1x mini-PCIe slot (only USB2.0 bus).
* 1x SIM slot (standard size).
* 1x 2.4Ghz WIFI (rt2800).
* 1x button.
* 6x LEDS (4 GPIO-controlled).
* 1x micro-SD reader.

The following have been tested and working:
- Ethernet switch
- Wifi
- Mini-PCIe slot + SIM slot
- USB port
- microSD slot
- sysupgrade
- reset button

Installation and recovery:

In order to install OpenWRT the first time or ito recover the router,
you can use the web-based recovery system. Keep the reset button pressed
during boot and access 192.168.1.1 in your browser when your machine
obtains an IP address. Upload the firmware to start the recovery
process.

Notes:

* The LED labeled "USB" is used as the power LED. When binding this LED
to a usbport, the LED is switched on all the time due to the presence of
an internal hub. Thus, it does not really signal any USB-information.

* I only have the 32MB version and have only added support for this
device. However, the files are structured so that adding support for the
16MB version should be easy.

* Only the LAN port is accessible from the outside of the casing and LEDs
are not visible.

v1->v2:
* Rebased on top of master.
* Read correct WAN address from flash (thanks Adrian Schmutzler).

Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
---
 .../ramips/base-files/etc/board.d/01_leds     |  5 +++
 .../ramips/base-files/etc/board.d/02_network  |  6 ++-
 .../dts/mt7620a_zbtlink_we1026-h-32m.dts      | 14 +++++++
 .../ramips/dts/mt7620a_zbtlink_we1026-h.dtsi  | 42 +++++++++++++++++++
 target/linux/ramips/image/mt7620.mk           | 12 ++++++
 5 files changed, 78 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi

Comments

Adrian Schmutzler Sept. 24, 2019, 11:28 a.m. UTC | #1
Hi,

first of all:
Naming scheme for ZBT devices is mixed in ramips. Some include the ZBT in model name, some don't. In your case, this means the following options:
zbtlink,zbt-we1026-h    corresponding to model    ZBT-WE1026-H
or
zbtlink,we1026-h    corresponding to model    WE1026-H

I do not know what's correct here (if there is right/wrong for this at all), but just want you to decide about this intentionally. Even if the existing WE1026-5G proves to have the wrong scheme then, I'd use the correct one for the WE1026-H.

Find some comments below.

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org] On Behalf Of Kristian Evensen
> Sent: Dienstag, 24. September 2019 12:47
> To: openwrt-devel@lists.openwrt.org; dev@kresin.me; monkeh@monkeh.net; musashino.open@gmail.com; ynezz@true.cz
> Cc: Kristian Evensen <kristian.evensen@gmail.com>
> Subject: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H
> 
> This commit adds support for the ZBT WE1026-H, an outdoor AP with
> support for adding an internal LTE modem. The detailed specs are:
> 
> * CPU: MT7620A
> * 2x 10/100Mbps Ethernet (LAN port has passive PoE support).
> * 16/32 MB Flash.
> * 128/256 MB RAM.
> * 1x USB 2.0 port.
> * 1x mini-PCIe slot (only USB2.0 bus).
> * 1x SIM slot (standard size).
> * 1x 2.4Ghz WIFI (rt2800).
> * 1x button.
> * 6x LEDS (4 GPIO-controlled).
> * 1x micro-SD reader.
> 
> The following have been tested and working:
> - Ethernet switch
> - Wifi
> - Mini-PCIe slot + SIM slot
> - USB port
> - microSD slot
> - sysupgrade
> - reset button
> 
> Installation and recovery:
> 
> In order to install OpenWRT the first time or ito recover the router,
> you can use the web-based recovery system. Keep the reset button pressed
> during boot and access 192.168.1.1 in your browser when your machine
> obtains an IP address. Upload the firmware to start the recovery
> process.
> 
> Notes:
> 
> * The LED labeled "USB" is used as the power LED. When binding this LED
> to a usbport, the LED is switched on all the time due to the presence of
> an internal hub. Thus, it does not really signal any USB-information.
> 
> * I only have the 32MB version and have only added support for this
> device. However, the files are structured so that adding support for the
> 16MB version should be easy.
> 
> * Only the LAN port is accessible from the outside of the casing and LEDs
> are not visible.
> 
> v1->v2:
> * Rebased on top of master.
> * Read correct WAN address from flash (thanks Adrian Schmutzler).
> 
> Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
> ---
>  .../ramips/base-files/etc/board.d/01_leds     |  5 +++
>  .../ramips/base-files/etc/board.d/02_network  |  6 ++-
>  .../dts/mt7620a_zbtlink_we1026-h-32m.dts      | 14 +++++++
>  .../ramips/dts/mt7620a_zbtlink_we1026-h.dtsi  | 42 +++++++++++++++++++
>  target/linux/ramips/image/mt7620.mk           | 12 ++++++
>  5 files changed, 78 insertions(+), 1 deletion(-)
>  create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
>  create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
> 
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 46202b4117..3e12c2a947 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -461,6 +461,11 @@ zbtlink,zbt-we826-16m|\
>  zbtlink,zbt-we826-32m)
>  	set_wifi_led "zbt-we826:green:wifi"
>  	;;
> +zbtlink,we1026-h-32m)

If you keep this name (without zbt), then you should sort it appropriately, i.e. "we" before "zbt" ...

> +	set_wifi_led "we1026-h:green:wifi"
> +	ucidef_set_led_switch "lan" "lan" "we1026-h:green:lan" "switch0" "0x8"
> +	ucidef_set_led_switch "wan" "wan" "we1026-h:green:wan" "switch0" "0x10"
> +	;;
>  zbtlink,zbt-we1226)
>  	set_wifi_led "$boardname:green:wlan"
>  	ucidef_set_led_switch "lan1" "LAN1" "$boardname:green:lan1" "switch0" "0x01"
> diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network
> index 63644331e5..d94cd5fa98 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -272,7 +272,8 @@ ramips_setup_interfaces()
>  		ucidef_add_switch "switch0" \
>  			"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
>  		;;
> -	buffalo,wcr-1166ds)
> +	buffalo,wcr-1166ds|\
> +	zbtlink,we1026-h-32m)
>  		ucidef_add_switch "switch0" \
>  			"3:lan" "4:wan" "6@eth0"
>  		;;
> @@ -721,6 +722,9 @@ ramips_setup_macs()
>  		wan_mac=$(mtd_get_mac_binary factory 0xe006)
>  		label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
>  		;;
> +	zbtlink,we1026-h-32m)
> +		wan_mac=$(mtd_get_mac_binary factory 0x2e)
> +		;;

Depending on how the label MAC address discussion below ends, you might merge this with the node for cudy,wr1000.

>  	*)
>  		wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 1)
>  		;;
> diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-
> 32m.dts
> new file mode 100644
> index 0000000000..ca62ccfc84
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
> @@ -0,0 +1,14 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "mt7620a_zbtlink_we1026-h.dtsi"
> +
> +/ {
> +	compatible = "zbtlink,we1026-h-32m", "zbtlink,we1026-h",
> +		     "zbtlink,we1026","ralink,mt7620a-soc";
> +	model = "ZBT WE1026-H (32M)";
> +};
> +
> +&firmware {
> +	reg = <0x50000 0x1fb0000>;
> +};
> diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
> new file mode 100644
> index 0000000000..fed79c2809
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
> @@ -0,0 +1,42 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/dts-v1/;
> +
> +#include "mt7620a_zbtlink_we1026.dtsi"
> +
> +/ {
> +	compatible = "zbtlink,we1026-h", "zbtlink,we1026",
> +		     "ralink,mt7620a-soc";
> +
> +	aliases {
> +		led-boot = &led_power;
> +		led-failsafe = &led_power;
> +		led-running = &led_power;
> +		led-upgrade = &led_power;
> +		label-mac-device = &wmac;

This won't work, as wmac uses ralink,mtd-eeprom without mtd-mac-address (so you do not have access to the mac address via /proc/device-tree).

Current policy is to keep label-mac-device here anyway (for future use), but to include a line like the following in the mac setup section of 02_network to actually have label MAC address set:
label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
You have to evaluate whether phy0 or phy1 is correct for your device.
If phy0 is, you can just add the device(s) to the cudy,wr1000 case.

If you have access to the WE1026-5G, too, the cleanest way would be to check label MAC address on it and then add label MAC address for all WE1026-* in 02_network, and move the label_mac_device alias to the parent DTSI where wmac is set up.

> +	};
> +
> +	leds {
> +		compatible = "gpio-leds";
> +
> +		led_power: usb {
> +			label = "we1026-h:green:usb";
> +			gpios = <&gpio2 2 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		lan {
> +			label = "we1026-h:green:lan";
> +			gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		wan {
> +			label = "we1026-h:green:wan";
> +			gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
> +		};
> +
> +		wifi {
> +			label = "we1026-h:green:wifi";
> +			gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
> +		};
> +	};
> +

Remove this empty line.

> +};
> diff --git a/target/linux/ramips/image/mt7620.mk b/target/linux/ramips/image/mt7620.mk
> index 320d4abd1f..3011e08af7 100644
> --- a/target/linux/ramips/image/mt7620.mk
> +++ b/target/linux/ramips/image/mt7620.mk
> @@ -973,6 +973,18 @@ define Device/zbtlink_we1026-5g-16m
>  endef
>  TARGET_DEVICES += zbtlink_we1026-5g-16m
> 
> +define Device/zbtlink_we1026-h-32m
> +  MTK_SOC := mt7620a
> +  DTS := WE1026-H-32M

This line (DTS) can be dropped. DTS name is constructed automatically from node name and mtk_soc ...

> +  IMAGE_SIZE := 32448k
> +  DEVICE_VENDOR := Zbtlink
> +  DEVICE_MODEL := ZBT-WE1026-H

If you choose that name, then you have to use zbtlink_zbt-we1026-h-32m.
Otherwise, put "WE1026-H" here.

Best

Adrian

> +  DEVICE_VARIANT := 32M
> +  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-sdhci-mt7620 \
> +		     kmod-ledtrig-netdev
> +endef
> +TARGET_DEVICES += zbtlink_we1026-h-32m
> +
>  define Device/zbtlink_zbt-ape522ii
>    MTK_SOC := mt7620a
>    IMAGE_SIZE := 15872k
> --
> 2.20.1
> 
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Kristian Evensen Sept. 24, 2019, 3:15 p.m. UTC | #2
Hi,

On Tue, Sep 24, 2019 at 1:28 PM Adrian Schmutzler
<mail@adrianschmutzler.de> wrote:
>
> Hi,
>
> first of all:
> Naming scheme for ZBT devices is mixed in ramips. Some include the ZBT in model name, some don't. In your case, this means the following options:
> zbtlink,zbt-we1026-h    corresponding to model    ZBT-WE1026-H
> or
> zbtlink,we1026-h    corresponding to model    WE1026-H
>
> I do not know what's correct here (if there is right/wrong for this at all), but just want you to decide about this intentionally. Even if the existing WE1026-5G proves to have the wrong scheme then, I'd use the correct one for the WE1026-H.

I prefer consistency, so my preference would be staying with the
initial naming scheme used for this "family" of devices.

> > diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds
> > index 46202b4117..3e12c2a947 100755
> > --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> > +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> > @@ -461,6 +461,11 @@ zbtlink,zbt-we826-16m|\
> >  zbtlink,zbt-we826-32m)
> >       set_wifi_led "zbt-we826:green:wifi"
> >       ;;
> > +zbtlink,we1026-h-32m)
>
> If you keep this name (without zbt), then you should sort it appropriately, i.e. "we" before "zbt" ...

True, thanks for spotting that.

> > @@ -721,6 +722,9 @@ ramips_setup_macs()
> >               wan_mac=$(mtd_get_mac_binary factory 0xe006)
> >               label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
> >               ;;
> > +     zbtlink,we1026-h-32m)
> > +             wan_mac=$(mtd_get_mac_binary factory 0x2e)
> > +             ;;
>
> Depending on how the label MAC address discussion below ends, you might merge this with the node for cudy,wr1000.
>
> >       *)
> >               wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 1)
> >               ;;
> > diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-
> > 32m.dts
> > new file mode 100644
> > index 0000000000..ca62ccfc84
> > --- /dev/null
> > +++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
> > @@ -0,0 +1,14 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +/dts-v1/;
> > +
> > +#include "mt7620a_zbtlink_we1026-h.dtsi"
> > +
> > +/ {
> > +     compatible = "zbtlink,we1026-h-32m", "zbtlink,we1026-h",
> > +                  "zbtlink,we1026","ralink,mt7620a-soc";
> > +     model = "ZBT WE1026-H (32M)";
> > +};
> > +
> > +&firmware {
> > +     reg = <0x50000 0x1fb0000>;
> > +};
> > diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
> > new file mode 100644
> > index 0000000000..fed79c2809
> > --- /dev/null
> > +++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
> > @@ -0,0 +1,42 @@
> > +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> > +/dts-v1/;
> > +
> > +#include "mt7620a_zbtlink_we1026.dtsi"
> > +
> > +/ {
> > +     compatible = "zbtlink,we1026-h", "zbtlink,we1026",
> > +                  "ralink,mt7620a-soc";
> > +
> > +     aliases {
> > +             led-boot = &led_power;
> > +             led-failsafe = &led_power;
> > +             led-running = &led_power;
> > +             led-upgrade = &led_power;
> > +             label-mac-device = &wmac;
>
> This won't work, as wmac uses ralink,mtd-eeprom without mtd-mac-address (so you do not have access to the mac address via /proc/device-tree).

Ok, thanks for letting me know. I got confused because I saw other
devices assigning the same value to label-mac-device. I will remove
label-mac-device from the DTS then, as I do not see the point of
having something around that may or may not be used in the future. The
assignment can rather be added when label-mac-device is properly
supported.

> Current policy is to keep label-mac-device here anyway (for future use), but to include a line like the following in the mac setup section of 02_network to actually have label MAC address set:
> label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
> You have to evaluate whether phy0 or phy1 is correct for your device.
> If phy0 is, you can just add the device(s) to the cudy,wr1000 case.

Ok, thanks.

> If you have access to the WE1026-5G, too, the cleanest way would be to check label MAC address on it and then add label MAC address for all WE1026-* in 02_network, and move the label_mac_device alias to the parent DTSI where wmac is set up.

I will that a look.

> > +define Device/zbtlink_we1026-h-32m
> > +  MTK_SOC := mt7620a
> > +  DTS := WE1026-H-32M
>
> This line (DTS) can be dropped. DTS name is constructed automatically from node name and mtk_soc ...

Thanks for spotting this.

>
> > +  IMAGE_SIZE := 32448k
> > +  DEVICE_VENDOR := Zbtlink
> > +  DEVICE_MODEL := ZBT-WE1026-H
>
> If you choose that name, then you have to use zbtlink_zbt-we1026-h-32m.
> Otherwise, put "WE1026-H" here.

The DEVICE_MODEL for the other 1026-devices all start with
"ZBT-WE1026", so I prefer to remain consistent.

BR,
Kristian
Adrian Schmutzler Sept. 24, 2019, 4:21 p.m. UTC | #3
Hi,

> I prefer consistency, so my preference would be staying with the initial
> naming scheme used for this "family" of devices.

I'm all about consistency. I just scanned the image definitions in ramips:

define Device/zbtlink_zbt-we1226
  DEVICE_VENDOR := ZBTlink
  DEVICE_MODEL := ZBT-WE1226

define Device/zbtlink_we1026-5g-16m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE1026-5G

define Device/zbtlink_zbt-ape522ii
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-APE522II

define Device/zbtlink_zbt-cpe102
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-CPE102

define Device/zbtlink_zbt-wa05
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WA05

define Device/zbtlink_zbt-we2026
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE2026

define Device/zbtlink_zbt-we826-16m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826
  DEVICE_VARIANT := 16M

define Device/zbtlink_zbt-we826-32m
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826
  DEVICE_VARIANT := 32M

define Device/zbtlink_zbt-we826-e
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WE826-E

define Device/zbtlink_zbt-wr8305rt
  DEVICE_VENDOR := Zbtlink
  DEVICE_MODEL := ZBT-WR8305RT

define Device/zbtlink_zbt-we1326
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WE1326

define Device/zbtlink_zbt-we3526
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WE3526

define Device/zbtlink_zbt-wg2626
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG2626

define Device/zbtlink_zbt-wg3526-16m
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG3526
  DEVICE_VARIANT := 16M

define Device/zbtlink_zbt-wg3526-32m
  DEVICE_VENDOR := ZBT
  DEVICE_MODEL := ZBT-WG3526
  DEVICE_VARIANT := 32M

The only device deviating from the pattern "zbtlink_zbt-something" is zbtlink_we1026-5g-16m.

So, IMO the correct solution _in terms of consistency_ would be to rename zbtlink_we1026-5g-16m to zbtlink_zbt-we1026-5g-16m and then adjust your device support for the -H to that scheme.

Do you agree? If yes, you could either implement all changes within or before your patch 1/2. Or I could send a patch for that and you rebase on it.

What do you think?

(I will send a separate patch to unify the device vendor....)

Best

Adrian
Kristian Evensen Sept. 26, 2019, 9:36 a.m. UTC | #4
Hi Adrian,

On Tue, Sep 24, 2019 at 6:22 PM <mail@adrianschmutzler.de> wrote:
> I'm all about consistency. I just scanned the image definitions in ramips:
>
> ...
>
> The only device deviating from the pattern "zbtlink_zbt-something" is zbtlink_we1026-5g-16m.
>
> So, IMO the correct solution _in terms of consistency_ would be to rename zbtlink_we1026-5g-16m to zbtlink_zbt-we1026-5g-16m and then adjust your device support for the -H to that scheme.
>
> Do you agree? If yes, you could either implement all changes within or before your patch 1/2. Or I could send a patch for that and you rebase on it.
>
> What do you think?

I am fine with either approach. I will not have time to look at this
device again before the weekend, so I will take whatever is in the
tree then and rebase + apply fixes. If you patch has not been
accepted/merged, I will change the naming of the 1026-devices.

BR,
Kristian
Adrian Schmutzler Sept. 26, 2019, 12:52 p.m. UTC | #5
Hi Kristian,

I've just sent two patches on which you could rebase if you like.

Since I do not have the device, I cannot test, so they most probably won't be merged soon.

Best

Adrian

> -----Original Message-----
> From: openwrt-devel [mailto:openwrt-devel-bounces@lists.openwrt.org]
> On Behalf Of Kristian Evensen
> Sent: Donnerstag, 26. September 2019 11:36
> To: Adrian Schmutzler <mail@adrianschmutzler.de>
> Cc: Alex Maclean <monkeh@monkeh.net>; OpenWrt Development List
> <openwrt-devel@lists.openwrt.org>; Mathias Kresin <dev@kresin.me>;
> musashino.open@gmail.com; Petr Štetiar <ynezz@true.cz>
> Subject: Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT
> WE1026-H
> 
> Hi Adrian,
> 
> On Tue, Sep 24, 2019 at 6:22 PM <mail@adrianschmutzler.de> wrote:
> > I'm all about consistency. I just scanned the image definitions in ramips:
> >
> > ...
> >
> > The only device deviating from the pattern "zbtlink_zbt-something" is
> zbtlink_we1026-5g-16m.
> >
> > So, IMO the correct solution _in terms of consistency_ would be to rename
> zbtlink_we1026-5g-16m to zbtlink_zbt-we1026-5g-16m and then adjust your
> device support for the -H to that scheme.
> >
> > Do you agree? If yes, you could either implement all changes within or
> before your patch 1/2. Or I could send a patch for that and you rebase on it.
> >
> > What do you think?
> 
> I am fine with either approach. I will not have time to look at this device again
> before the weekend, so I will take whatever is in the tree then and rebase +
> apply fixes. If you patch has not been accepted/merged, I will change the
> naming of the 1026-devices.
> 
> BR,
> Kristian
> 
> _______________________________________________
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Patch
diff mbox series

diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds b/target/linux/ramips/base-files/etc/board.d/01_leds
index 46202b4117..3e12c2a947 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -461,6 +461,11 @@  zbtlink,zbt-we826-16m|\
 zbtlink,zbt-we826-32m)
 	set_wifi_led "zbt-we826:green:wifi"
 	;;
+zbtlink,we1026-h-32m)
+	set_wifi_led "we1026-h:green:wifi"
+	ucidef_set_led_switch "lan" "lan" "we1026-h:green:lan" "switch0" "0x8"
+	ucidef_set_led_switch "wan" "wan" "we1026-h:green:wan" "switch0" "0x10"
+	;;
 zbtlink,zbt-we1226)
 	set_wifi_led "$boardname:green:wlan"
 	ucidef_set_led_switch "lan1" "LAN1" "$boardname:green:lan1" "switch0" "0x01"
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network b/target/linux/ramips/base-files/etc/board.d/02_network
index 63644331e5..d94cd5fa98 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -272,7 +272,8 @@  ramips_setup_interfaces()
 		ucidef_add_switch "switch0" \
 			"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
 		;;
-	buffalo,wcr-1166ds)
+	buffalo,wcr-1166ds|\
+	zbtlink,we1026-h-32m)
 		ucidef_add_switch "switch0" \
 			"3:lan" "4:wan" "6@eth0"
 		;;
@@ -721,6 +722,9 @@  ramips_setup_macs()
 		wan_mac=$(mtd_get_mac_binary factory 0xe006)
 		label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
 		;;
+	zbtlink,we1026-h-32m)
+		wan_mac=$(mtd_get_mac_binary factory 0x2e)
+		;;
 	*)
 		wan_mac=$(macaddr_add "$(cat /sys/class/net/eth0/address)" 1)
 		;;
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
new file mode 100644
index 0000000000..ca62ccfc84
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h-32m.dts
@@ -0,0 +1,14 @@ 
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a_zbtlink_we1026-h.dtsi"
+
+/ {
+	compatible = "zbtlink,we1026-h-32m", "zbtlink,we1026-h",
+		     "zbtlink,we1026","ralink,mt7620a-soc";
+	model = "ZBT WE1026-H (32M)";
+};
+
+&firmware {
+	reg = <0x50000 0x1fb0000>;
+};
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
new file mode 100644
index 0000000000..fed79c2809
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-h.dtsi
@@ -0,0 +1,42 @@ 
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a_zbtlink_we1026.dtsi"
+
+/ {
+	compatible = "zbtlink,we1026-h", "zbtlink,we1026",
+		     "ralink,mt7620a-soc";
+
+	aliases {
+		led-boot = &led_power;
+		led-failsafe = &led_power;
+		led-running = &led_power;
+		led-upgrade = &led_power;
+		label-mac-device = &wmac;
+	};
+
+	leds {
+		compatible = "gpio-leds";
+
+		led_power: usb {
+			label = "we1026-h:green:usb";
+			gpios = <&gpio2 2 GPIO_ACTIVE_LOW>;
+		};
+
+		lan {
+			label = "we1026-h:green:lan";
+			gpios = <&gpio2 3 GPIO_ACTIVE_LOW>;
+		};
+
+		wan {
+			label = "we1026-h:green:wan";
+			gpios = <&gpio2 4 GPIO_ACTIVE_LOW>;
+		};
+
+		wifi {
+			label = "we1026-h:green:wifi";
+			gpios = <&gpio3 0 GPIO_ACTIVE_LOW>;
+		};
+	};
+
+};
diff --git a/target/linux/ramips/image/mt7620.mk b/target/linux/ramips/image/mt7620.mk
index 320d4abd1f..3011e08af7 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -973,6 +973,18 @@  define Device/zbtlink_we1026-5g-16m
 endef
 TARGET_DEVICES += zbtlink_we1026-5g-16m
 
+define Device/zbtlink_we1026-h-32m
+  MTK_SOC := mt7620a
+  DTS := WE1026-H-32M
+  IMAGE_SIZE := 32448k
+  DEVICE_VENDOR := Zbtlink
+  DEVICE_MODEL := ZBT-WE1026-H
+  DEVICE_VARIANT := 32M
+  DEVICE_PACKAGES := kmod-usb2 kmod-usb-ohci kmod-sdhci-mt7620 \
+		     kmod-ledtrig-netdev
+endef
+TARGET_DEVICES += zbtlink_we1026-h-32m
+
 define Device/zbtlink_zbt-ape522ii
   MTK_SOC := mt7620a
   IMAGE_SIZE := 15872k