Re: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT WE1026-H
Hi, On Sun, Nov 3, 2019 at 3:14 PM wrote: > Okay, if it's not visible I do not think it's worth to deviate from normal > procedure here. > > I've remove the power_led label and aliases. > > Feel free to test and provide an updated solution for the use as USB LED. > > Despite, note that the first word after "ramips:" should be lower-case in > commit title for future submissions. Thanks a lot for you help and feedback. When I have some time, I will take look and see if I can come up with a solution for USB LED. Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT WE1026-H
> -Original Message- > From: Kristian Evensen [mailto:kristian.even...@gmail.com] > Sent: Sonntag, 3. November 2019 14:35 > To: Adrian Schmutzler > Cc: OpenWrt Development List > Subject: Re: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT > WE1026-H > > Hi Adrian, > > On Sun, Nov 3, 2019 at 12:36 PM wrote: > > > > Hi Kristian, > > > > > -Original Message- > > > From: openwrt-devel [mailto:openwrt-devel- > boun...@lists.openwrt.org] > > > On Behalf Of Kristian Evensen > > > Sent: Samstag, 2. November 2019 15:19 > > > To: openwrt-devel@lists.openwrt.org > > > Cc: Kristian Evensen > > > Subject: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT > > > WE1026-H > > > > I've already pulled your patches into my staging tree, but then stumbled > over the USB LED as Power LED thing: > > > > https://git.openwrt.org/openwrt/staging/adrian.git > > > > I personally don't like that very much, and it also doesn't strictly match > > the > policy of sticking to the vendor's use of LEDs. However, we also do not > strictly > follow that policy for other devices, e.g. the TP-Link CPE devices where one > of the WLAN strength indicators are used for signaling. > > Still, if the LED is assigned to USB it will at least irritate some users. > > > > Despite that, I remember that for TP-Link WDR3600/WDR4300 a nested > setup was required to get USB hub working: > > > > > https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ > > ar9344_tplink_tl-wdr4300.dtsi > > > > Maybe you can get USB LEDs working as USB LEDs with that. > > > > Since you seem to keep track on your devices, I'd also be okay with > removing the power_led alias for now, merge the device support, and then > address the USB issue in a separate patch. > > I have no strong opinion either way, as the device is inside an enclosure and > no LEDs are visible on the outside. So feel free to remove the alias. > > BR, > Kristian Okay, if it's not visible I do not think it's worth to deviate from normal procedure here. I've remove the power_led label and aliases. Feel free to test and provide an updated solution for the use as USB LED. Despite, note that the first word after "ramips:" should be lower-case in commit title for future submissions. Thanks for your work. Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT WE1026-H
Hi Adrian, On Sun, Nov 3, 2019 at 12:36 PM wrote: > > Hi Kristian, > > > -Original Message- > > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > > On Behalf Of Kristian Evensen > > Sent: Samstag, 2. November 2019 15:19 > > To: openwrt-devel@lists.openwrt.org > > Cc: Kristian Evensen > > Subject: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT > > WE1026-H > > I've already pulled your patches into my staging tree, but then stumbled over > the USB LED as Power LED thing: > > https://git.openwrt.org/openwrt/staging/adrian.git > > I personally don't like that very much, and it also doesn't strictly match > the policy of sticking to the vendor's use of LEDs. However, we also do not > strictly follow that policy for other devices, e.g. the TP-Link CPE devices > where one of the WLAN strength indicators are used for signaling. > Still, if the LED is assigned to USB it will at least irritate some users. > > Despite that, I remember that for TP-Link WDR3600/WDR4300 a nested setup was > required to get USB hub working: > > https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi > > Maybe you can get USB LEDs working as USB LEDs with that. > > Since you seem to keep track on your devices, I'd also be okay with removing > the power_led alias for now, merge the device support, and then address the > USB issue in a separate patch. I have no strong opinion either way, as the device is inside an enclosure and no LEDs are visible on the outside. So feel free to remove the alias. BR, Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT WE1026-H
Hi Kristian, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Kristian Evensen > Sent: Samstag, 2. November 2019 15:19 > To: openwrt-devel@lists.openwrt.org > Cc: Kristian Evensen > Subject: [OpenWrt-Devel] [PATCH v3 2/2] ramips: Add support for ZBT > WE1026-H I've already pulled your patches into my staging tree, but then stumbled over the USB LED as Power LED thing: https://git.openwrt.org/openwrt/staging/adrian.git I personally don't like that very much, and it also doesn't strictly match the policy of sticking to the vendor's use of LEDs. However, we also do not strictly follow that policy for other devices, e.g. the TP-Link CPE devices where one of the WLAN strength indicators are used for signaling. Still, if the LED is assigned to USB it will at least irritate some users. Despite that, I remember that for TP-Link WDR3600/WDR4300 a nested setup was required to get USB hub working: https://github.com/openwrt/openwrt/blob/master/target/linux/ath79/dts/ar9344_tplink_tl-wdr4300.dtsi Maybe you can get USB LEDs working as USB LEDs with that. Since you seem to keep track on your devices, I'd also be okay with removing the power_led alias for now, merge the device support, and then address the USB issue in a separate patch. I've already done rebase (base-files!) etc., so it would be enough if you post your desired changes/decision and I apply them locally. Note that I've not been granted admin rights in Patchwork yet, so if you have an account there you might update the status of both patches to "Under Review". Best Adrian openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3 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.
Signed-off-by: Kristian Evensen
---
v2->v3:
* Rebase on top of master.
* Added label mac (thanks Adrian Schmutzler).
* Fix consistent naming (thanks Adrian Schmutzler).
v1->v2:
* Rebased on top of master.
* Read correct WAN address from flash (thanks Adrian Schmutzler).
---
.../ramips/base-files/etc/board.d/01_leds | 5 +++
.../ramips/base-files/etc/board.d/02_network | 6 ++-
.../dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts | 14 +++
.../dts/mt7620a_zbtlink_zbt-we1026-h.dtsi | 40 +++
target/linux/ramips/image/mt7620.mk | 11 +
5 files changed, 74 insertions(+), 2 deletions(-)
create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts
create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_zbt-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 662bf6b6cd..7b2310bc6f 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-we1026-5g-16m)
ucidef_set_led_netdev "lan" "LAN" "we1026-5g:green:lan" "eth0"
set_wifi_led "we1026-5g:green:wifi"
;;
+zbtlink,zbt-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 373651e64e..b2bfc91ebe 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -275,7 +275,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,zbt-we1026-h-32m)
ucidef_add_switch "switch0" \
"3:lan" "4:wan" "6@eth0"
;;
@@ -594,7 +595,8 @@ ramips_setup_macs()
zyxel,keenetic-start)
# This empty case has to be kept for devices without any MAC
address adjustments
;;
- cudy,wr1000)
+ cudy,wr1000|\
+ zbtlink,zbt-we1026-h-32m)
wan_mac=$(mtd_get_mac_binary factory 0x2e)
label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
;;
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts
new file mode 100644
index 00..87430a9a6f
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a_zbtlink_zbt-we1026-h.dtsi"
+
+/ {
+ compatible = "zbtlink,zbt-we1026-h-32m", "zbtlink,zbt-we1026-h",
+"zbtlink,zbt-we1026","ralink,mt7620a-soc";
+ model = "Zbtlink ZBT-WE1026-H (32M)";
+};
+
+ {
+ reg = <0x5 0x1fb>;
+};
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h.dtsi
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h.dtsi
new file mode 100644
index 00..0aa41dc5da
--- /dev/null
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-h.dtsi
@@ -0,0 +1,40
