[PATCH v2] ramips: add support for Wavlink WL-WN578A2
From: Thomas Aldrian
This commit adds support for the Wavlink WL-WN578A2 dual-band wall-plug
wireless router. This device is also sold under the name SilverCrest
SWV 733 A2.
Device Specifications:
- CPU: MediaTek MT7628AN (580MHz)
- Flash: 8MB
- RAM: 64MB
- Bootloader: U-Boot
- Ethernet: 2x 10/100 Mbps
- 2.4 GHz: 802.11b/g/n SoC
- 5 GHz: 802.11a/n/ac MT7610E
- Antennas: internal
- 4 green LEDs: WPS/Power, LAN, WAN, wifi-low, wifi-med, wifi-high
- Buttons: Reset, WPS
- Sliding mode switch: AP, repeater, client
- Small sliding power switch
Flashing instructions:
U-Boot launches TFTP client if WPS button is pressed during power-on.
Configure as follows:
- Server IP: 192.168.10.100
- Filename (rename sysupgrade file to this): firmware.bin
Flashing should not take more than a minute, device will reboot
automatically.
Signed-off-by: Thomas Aldrian
---
.../dts/mt7628an_wavlink_wl-wn578a2.dts | 166 ++
target/linux/ramips/image/mt76x8.mk | 10 ++
.../mt76x8/base-files/etc/board.d/01_leds | 3 +-
.../mt76x8/base-files/etc/board.d/02_network | 6 +-
4 files changed, 182 insertions(+), 3 deletions(-)
create mode 100644 target/linux/ramips/dts/mt7628an_wavlink_wl-wn578a2.dts
diff --git a/target/linux/ramips/dts/mt7628an_wavlink_wl-wn578a2.dts
b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn578a2.dts
new file mode 100644
index 00..d7238e17c6
--- /dev/null
+++ b/target/linux/ramips/dts/mt7628an_wavlink_wl-wn578a2.dts
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7628an.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "wavlink,wl-wn578a2", "mediatek,mt7628an-soc";
+ model = "Wavlink WL-WN578A2";
+
+ aliases {
+ led-boot = _wps;
+ led-failsafe = _wps;
+ led-running = _wps;
+ led-upgrade = _wps;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = < 43 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = < 38 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ ap {
+ label = "ap";
+ gpios = < 41 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ linux,input-type = ;
+ };
+
+ repeater {
+ label = "repeater";
+ gpios = < 42 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ linux,input-type = ;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ wifi-high {
+ label = "green:wifi-high";
+ gpios = < 37 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi-med {
+ label = "green:wifi-med";
+ gpios = < 11 GPIO_ACTIVE_LOW>;
+ };
+
+ wifi-low {
+ label = "green:wifi-low";
+ gpios = < 44 GPIO_ACTIVE_LOW>;
+ };
+
+ lan {
+ label = "green:lan";
+ gpios = < 40 GPIO_ACTIVE_LOW>;
+ };
+
+ wan {
+ label = "green:wan";
+ gpios = < 39 GPIO_ACTIVE_LOW>;
+ };
+
+ led_wps: wps {
+ label = "green:wps";
+ gpios = < 4 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+_default {
+ gpio {
+ groups = "i2c", "wdt", "wled_an", "p0led_an", "p1led_an",
+ "p2led_an", "p3led_an", "p4led_an", "refclk", "gpio";
+ function = "gpio";
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ wifi@0,0 {
+ reg = <0x 0 0 0 0>;
+ mediatek,mtd-eeprom = < 0x8000>;
+ ieee80211-freq-limit = <500 600>;
+ };
+};
+
+ {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <4000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "u-boot-env";
+ reg = <0x3 0x1>;
+ read-only;
+ };
+
+
Re: [PATCH] package: openssl: Enable built engines per default
> >> How about if we create a uci default script and check on the running
> >> system what is installed?
> >> And then we could generate a file and add or remove an include line
> >> form
> >> the openssl.cnf [1]?
> >
> > I think we can manage something like that. The .include option can
> > load all files in a directory (/etc/ssl/engines.d/), and won't fail if
> > there aren't any files--the directory itself must exist. Each engine
> > package can install its own file there, ahd have a post-install script
> > that adds a line to an "engines.cnf" file if there isn't any:
> >
> > add_engine() {
> > # $1 = engine name (engine .so file without the .so extension)
> > grep -q "$1=$1" /etc/ssl/engines.d/engines.cnf && return
> > echo "$1=$1" >> /etc/ssl/engines.d/engines.cnf
> > }
> >
> > /etc/ssl/engines.d/engines.cnf would start out with just the [engines]
> > header and some comments explaining its use and warning not to edit
> > something that would break things.
> >
> > What do you think?
>
> The plan sounds good :+1:
>
Hi
I'm testing that proposal, and it's almost ready. I've expanded it to
use uci to enable/disable the engines, but I'm still running tests to
catch corner cases. I am not able to test the padlock engine, but its
usage should be like devcrypto. Afalg is more complicated if built
into the library, because openssl does not initialize it like other
builtin engines. There's no way to configure it for general use when
built that way.
Cheers,
Eneas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] iwinfo: add 802.11ax HE rate information
This adds 802.11ax HE specific rate information to iwinfo.
Add fields for HE status of a STA as well as DCM and guard interval
fields specific to HE operation.
Signed-off-by: David Bauer
---
api/nl80211.h| 12
include/iwinfo.h | 3 +++
iwinfo_cli.c | 14 ++
iwinfo_lua.c | 19 ---
iwinfo_nl80211.c | 14 +-
5 files changed, 58 insertions(+), 4 deletions(-)
diff --git a/api/nl80211.h b/api/nl80211.h
index 3d252e4..22a709e 100644
--- a/api/nl80211.h
+++ b/api/nl80211.h
@@ -2353,6 +2353,13 @@ struct nl80211_sta_flag_update {
* @NL80211_RATE_INFO_5_MHZ_WIDTH: 5 MHz width - note that this is
* a legacy rate and will be reported as the actual bitrate, i.e.
* a quarter of the base (20 MHz) rate
+ * @NL80211_RATE_INFO_HE_MCS: HE MCS index (u8, 0-11)
+ * @NL80211_RATE_INFO_HE_NSS: HE NSS value (u8, 1-8)
+ * @NL80211_RATE_INFO_HE_GI: HE guard interval identifier
+ * (u8, see nl80211_he_gi)
+ * @NL80211_RATE_INFO_HE_DCM: HE DCM value (u8, 0/1)
+ * @NL80211_RATE_INFO_RU_ALLOC: HE RU allocation, if not present then
+ * non-OFDMA was used (u8, see nl80211_he_ru_alloc)
* @__NL80211_RATE_INFO_AFTER_LAST: internal use
*/
enum nl80211_rate_info {
@@ -2369,6 +2376,11 @@ enum nl80211_rate_info {
NL80211_RATE_INFO_160_MHZ_WIDTH,
NL80211_RATE_INFO_10_MHZ_WIDTH,
NL80211_RATE_INFO_5_MHZ_WIDTH,
+ NL80211_RATE_INFO_HE_MCS,
+ NL80211_RATE_INFO_HE_NSS,
+ NL80211_RATE_INFO_HE_GI,
+ NL80211_RATE_INFO_HE_DCM,
+ NL80211_RATE_INFO_HE_RU_ALLOC,
/* keep last */
__NL80211_RATE_INFO_AFTER_LAST,
diff --git a/include/iwinfo.h b/include/iwinfo.h
index 1956abe..3fc414b 100644
--- a/include/iwinfo.h
+++ b/include/iwinfo.h
@@ -110,6 +110,9 @@ struct iwinfo_rate_entry {
uint8_t is_short_gi:1;
uint8_t is_ht:1;
uint8_t is_vht:1;
+ uint8_t is_he:1;
+ uint8_t he_gi;
+ uint8_t he_dcm;
uint8_t mhz;
uint8_t nss;
};
diff --git a/iwinfo_cli.c b/iwinfo_cli.c
index 82b409c..8691f31 100644
--- a/iwinfo_cli.c
+++ b/iwinfo_cli.c
@@ -322,6 +322,20 @@ static char * format_assocrate(struct iwinfo_rate_entry *r)
l = sizeof(buf) - (p - buf);
}
}
+ else if (r->is_he)
+ {
+ p += snprintf(p, l, ", HE-MCS %d, %dMHz", r->mcs,
r->mhz);
+ l = sizeof(buf) - (p - buf);
+
+ p += snprintf(p, l, ", HE-NSS %d", r->nss);
+ l = sizeof(buf) - (p - buf);
+
+ p += snprintf(p, l, ", HE-GI %d", r->he_gi);
+ l = sizeof(buf) - (p - buf);
+
+ p += snprintf(p, l, ", HE-DCM %d", r->he_dcm);
+ l = sizeof(buf) - (p - buf);
+ }
}
return buf;
diff --git a/iwinfo_lua.c b/iwinfo_lua.c
index 9935a8d..e49e454 100644
--- a/iwinfo_lua.c
+++ b/iwinfo_lua.c
@@ -268,6 +268,9 @@ static void set_rateinfo(lua_State *L, struct
iwinfo_rate_entry *r, bool rx)
lua_pushboolean(L, r->is_vht);
lua_setfield(L, -2, rx ? "rx_vht" : "tx_vht");
+ lua_pushboolean(L, r->is_he);
+ lua_setfield(L, -2, rx ? "rx_he" : "tx_he");
+
lua_pushnumber(L, r->mhz);
lua_setfield(L, -2, rx ? "rx_mhz" : "tx_mhz");
@@ -282,7 +285,7 @@ static void set_rateinfo(lua_State *L, struct
iwinfo_rate_entry *r, bool rx)
lua_pushboolean(L, r->is_short_gi);
lua_setfield(L, -2, rx ? "rx_short_gi" : "tx_short_gi");
}
- else if (r->is_vht)
+ else if (r->is_vht || r->is_he)
{
lua_pushnumber(L, r->mcs);
lua_setfield(L, -2, rx ? "rx_mcs" : "tx_mcs");
@@ -290,8 +293,18 @@ static void set_rateinfo(lua_State *L, struct
iwinfo_rate_entry *r, bool rx)
lua_pushnumber(L, r->nss);
lua_setfield(L, -2, rx ? "rx_nss" : "tx_nss");
- lua_pushboolean(L, r->is_short_gi);
- lua_setfield(L, -2, rx ? "rx_short_gi" : "tx_short_gi");
+ if (r->is_he) {
+ lua_pushnumber(L, r->he_gi);
+ lua_setfield(L, -2, rx ? "rx_he_gi" : "tx_he_gi");
+
+ lua_pushnumber(L, r->he_dcm);
+ lua_setfield(L, -2, rx ? "rx_he_dcm" : "tx_he_dcm");
+ }
+
+ if (r->is_vht) {
+ lua_pushboolean(L, r->is_short_gi);
+ lua_setfield(L, -2, rx ? "rx_short_gi" : "tx_short_gi");
+ }
}
}
diff --git a/iwinfo_nl80211.c b/iwinfo_nl80211.c
index aeff778..eea521e 100644
--- a/iwinfo_nl80211.c
+++ b/iwinfo_nl80211.c
@@ -1869,7 +1869,19 @@ static void nl80211_parse_rateinfo(struct nlattr **ri,
else if (ri[NL80211_RATE_INFO_BITRATE])
re->rate =
Re: Brokenness of the OpenWrt "packages" repo
On Mon, 26 Apr 2021, Alberto Bursi wrote: Date: Mon, 26 Apr 2021 21:58:23 From: Alberto Bursi To: openwrt-devel@lists.openwrt.org Subject: Re: Brokenness of the OpenWrt "packages" repo On 26/04/21 16:01, Daniel Golle wrote: On Mon, Apr 26, 2021 at 03:28:22PM +0200, Enrico Mioso wrote: ... I know you won't like this. But in the end, I guess D-Bus, glib2 and in the end all of MM dependencies will have to be incorporated in the core. A stac, of big big software, I know. But supporting 4G/5G in the end will required that. ModemManager is not the only way to use 4G/5G modems. You can use umbim or uqmi for most tasks. In my experience their ability to handle device-specific bugs or "perks" is limited, unless your modem is 100% perfect and never crashes ever and can actually handle the autoreconnect on its own, you will end up in situations where you need to just set up a script that pings Google and reboots the router if network fails. They also don's support a lot of new LTE features like band lock, band aggregation and more, they are way too simple. I have bought a consumer modem/router that is like 3 times faster while using the same type of CAT6 modem due to band aggregation and the reconnect sequence if the connection drops is very fast because I have set the only 2 LTE bands it can use. MM is so much better than that. But my main issue with MM is that both maintainers (package and upstream MM maintainers) have not found a way to integrate it well enough with OpenWrt's internals so that when the modem disconnects there is nothing that notices this issue and nothing that reacts to it. So I had to cobble together a script to do this missing link, but it's far from a decent solution. (see the issue thread I opened about this) That's why in the end, admittedly for different reasons, we ended up writing our own software to do so. It included an ubus script that tried to match MM bearers with network configurations. In the end it somewhat works, but the integration layer between MM and openwrt is still little bit fragile. It was enough to add a WireGuard interface to the system to stop MM from starting up. Setting the interface to not auto-start was enough to fix the isue. If you know me, you know I try to avoid absolute statements in general, and I absolutely don't mean to criticise other people's work here. The problem is the 5G modems out there are simply too complex to be handled e.g.: statelessly. I don't like to have this big stack of software on my devices as well, but there are times where you need to compromise. Once it was enough to use AT commands by hand, now its not the case anymore, at least for modern QMI-based modems. Bring in the multi-bearer dual-stack scenario and you have such a complexity growth... In general, uqmi and umbim are extremely clean and well-done. I estimate all of you a lot folks. But modems' firmware is a strange world. :) If you're under the impression a 5G modem might be an over-complicated gigantic piece of software / hardware complexity, I would second you. That requires scaling of complexity in the host side as well. Sudden resets and other characteristics, lets you having to be careful to stay consistent with modem state even when MM is behind you, doing it's great amount of work. This time it's not useless complexity. But well yes - it's a lot of complexity. Trying to trust the Modem firmware to do things like auto-connecting is very smart and appropriate - if you knw it's going to work. but we're going to face lots of different hardware with different bugs. So unfortunately we should handle all of them. Hence why I eventually bought an actual self-contained modem with web interface and all, it's just so much better speed and is less painful to use. -Alberto Both projects are straight forward, well documented code, easy to extend in case you miss anything. Depending on half of the Freedesktop universe in order to initialize a network interface or receive an SMS in a very complicated way doesn't feel justified to me. On Mon, 26 Apr 2021, Bjørn Mork wrote: Date: Mon, 26 Apr 2021 07:51:51 From: Bjørn Mork To: Etienne Champetier Cc: Rosen Penev , OpenWrt Development List Subject: Re: Brokenness of the OpenWrt "packages" repo Etienne Champetier writes: Are you trying at the same time to complain about not run-tested updates and possibly having packages not up to date ? No. The package was fine before the version was changed. In fact, it was in much better shape before it was changed to a development version by the very same non-maintainer. If you don't care enough to even install the package, then please don't touch the package. I would personally mark it as broken or remove it instead of making it work again, but it means removing some other packages. I'd be all for that, if you apply that rule to all the unmaintained packages in the repo. It's a much better solution than having
[PATCH v2] mvebu: LS421DE: improve pin configuration
The CLK125 output pin at the ethernet PHY is connected via capacitor to
GND and nowhere else. Disable it. Also tune the LED masks.
The MPP56 and MPP60 pins at the SoC are conected to the μPD720202 USB3.0
chip:
- MPP56: wired to PCIe CLKREQ# (out)
- MPP60: wired to PCIe RESET# (in)
Configure the pcie pinmux for these pins.
Signed-off-by: Daniel González Cabanelas
---
Change in v2: fix commit log.
.../arm/boot/dts/armada-370-buffalo-ls421de.dts | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git
a/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls421de.dts
b/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls421de.dts
index 4e176554c6..59400839a7 100644
--- a/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls421de.dts
+++ b/target/linux/mvebu/files/arch/arm/boot/dts/armada-370-buffalo-ls421de.dts
@@ -266,15 +266,19 @@
ethphy0: ethernet-phy@0 { /* Marvell 88E1518 */
reg = <0>;
- marvell,reg-init = <0x3 0x10 0x1 0x1991>, /* LED function */
- <0x3 0x11 0x1 0x4401>, /* LED polarity */
- <0x3 0x12 0x1 0x4905>; /* LED timer */
+ marvell,reg-init = <0x2 0x10 0x 0x0006>, /* disable CLK125
*/
+ <0x3 0x10 0x 0x1991>, /* LED function */
+ <0x3 0x11 0x 0x4401>, /* LED polarity */
+ <0x3 0x12 0x 0x4905>; /* LED timer */
#thermal-sensor-cells = <0>;
};
};
{
status = "okay";
+ pinctrl-0 = <_pcie>;
+ pinctrl-names = "default";
+
/* Connected to uPD720202 USB 3.0 Host */
pcie@1,0 {
status = "okay";
@@ -436,4 +440,9 @@
marvell,pins = "mpp55", "mpp57", "mpp62";
marvell,function = "gpio";
};
+
+ pmx_pcie: pmx-pcie {
+ marvell,pins = "mpp56", "mpp60";
+ marvell,function = "pcie";
+ };
};
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02-rc1
On 21-04-21, Perry wrote: > Now that openwrt-21.02-rc1 is tagged, would it be possible to have an > "openwrt-21.02" section for the Reported Version on bugs.openwrt.org? > While at it, why is it still possible to file bug reports for lede-17.01? Good catch, thanks. I have just added openwrt-21.02 to the bug tracker and disabled the possibility to use 17.01 and 18.06 for new bugs. Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] package: openssl: Enable built engines per default
Hello Eneas
How about if we create a uci default script and check on the running
system what is installed?
And then we could generate a file and add or remove an include line
form
the openssl.cnf [1]?
Hi Florian, Daniel
I think we can manage something like that. The .include option can
load all files in a directory (/etc/ssl/engines.d/), and won't fail if
there aren't any files--the directory itself must exist. Each engine
package can install its own file there, ahd have a post-install script
that adds a line to an "engines.cnf" file if there isn't any:
add_engine() {
# $1 = engine name (engine .so file without the .so extension)
grep -q "$1=$1" /etc/ssl/engines.d/engines.cnf && return
echo "$1=$1" >> /etc/ssl/engines.d/engines.cnf
}
/etc/ssl/engines.d/engines.cnf would start out with just the [engines]
header and some comments explaining its use and warning not to edit
something that would break things.
What do you think?
The plan sounds good :+1:
Cheers,
Eneas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
