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