Re: [PATCH 0/6] backport fixes and improvements for MT7530

[Kristian Evensen]

Hi,

On Sun, Feb 6, 2022 at 9:52 AM Arınç ÜNAL  wrote:
>
> On 06/02/2022 00:15, Arınç ÜNAL wrote:
> > On 05/02/2022 21:23, Hauke Mehrtens wrote:
> >> On 2/5/22 19:21, Rosen Penev wrote:
> >>> On Sat, Feb 5, 2022 at 10:12 AM Hauke Mehrtens  wrote:
> 
>  On 2/3/22 13:06, DENG Qingfang wrote:
> > Hi,
> >
> > This series backports some patches from upstream to address the
> > current
> > MT7530 DSA driver's problems.
> >
> > Thanks.
> >
> > DENG Qingfang (6):
> > kernel: backport MediaTek jumbo frame support
> > kernel: backport MT7530 ageing time support
> > kernel: backport MT7530 VLAN fix
> > kernel: backport MT7530 MDB operations
> > kernel: backport MediaTek Ethernet PHY driver
> > kernel: backport MT7530 IRQ support
> >
>  Hi,
> 
>  The last two patches are breaking the Linksys e8450 (mt7622) for me.
> 
>  I am getting these errors:
> >>> Note the commentary in
> >>> https://github.com/openwrt/openwrt/commit/3f4301e123f29348b4ad87578d62b7d1f5f210c6
> >>>
> >>>
> >>> The message in dmesg is harmless. It just says the functionality in
> >>> this patch needs dts bindings, which were only provided for ramips.
> >>
> >> The following error messages are a bigger problem:
> >
> > There was nothing wrong with that commit to revert it. But you could've
> > reverted the series as a whole since, technically, this patch series
> > broke the process so I guess it's better than nothing.
> >
> > I wonder if the PHY driver even works at its current state on upstream
> > for mt7531 or, more specifically, the built-in mt7531 on the MT7622X chips.
>
> Correction:
> MT7622X chips do not have a built-in mt7531 switch, there's a Fast
> Ethernet switch which is different.

When I applied the patches, I experienced the same issue as Hauke on a
custom mt7622 board (but with same switch setup). My "fix" was to add
the following to the mt7622 kernel-config to disable the PHY driver (I
have never experienced any of the issues reported on mt7621 without
the PHY driver):

# CONFIG_MEDIATEK_GE_PHY is not set

Otherwise, the patches included in this series turned out to be the
missing pieces of my performance analysis puzzle. My ISP gives a
non-standard (< 1500) MTU, so without the possibility to change MTU I
experienced fragmentation, etc.

Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Reduced throughput with mt7621 and DSA

[Kristian Evensen]

Hi,

On Tue, Dec 21, 2021 at 6:34 PM Kristian Evensen
 wrote:
> Since the only change between my sets of tests is the software,
> something has clearly improved in either the kernel or OpenWrt (as
> would be expected :)). Are there any particular commits/patches that
> would be worthwhile trying to backport to 21.02/5.4, or is the
> difference to master/5.10 so big that there is no point and the best
> is to wait for the next release? I guess one thing that hopefully
> shouldn't be too hard is be to combine 21.02 userspace with the 5.10
> kernel. That will be on the top of my todo-list for tomorrow.

Backporting 5.10 to 21.02 was straight forward and restored
performance to 19.07-levels. Since I anyway compile and run my own
images, backporting 5.10 works for me and performance issue is
resolved :)

Thanks for all the hard work.

Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: Reduced throughput with mt7621 and DSA

[Kristian Evensen]

Hello again,

On Sun, Dec 19, 2021 at 12:29 PM Kristian Evensen
 wrote:
> Based on my measurements, the throughput is reduced by ~50% going from
> 19.07 and to 21.02/master (~450Mbit/s vs. ~900Mbit/s). I do not have a
> particular commit I can point to, but I believe the regressions is
> caused by the introduction of DSA. Restoring the old swconfig driver,
> brings my 21.02/master throughput up to roughly the same level as
> 19.07.

I kept working on this issue today and went through my previous setup
and results. It turns out that I had mixed my 21.02 and master
results, leading to an incorrect observation. After cleaning up my
mess and repeating my tests, I get roughly the same result for master
(with DSA) as with 19.07.8. With an adequate number of parallel
connections (eight seems to be a good number), I am able to reach
900Mbit/s-1Gbit/s. 21.02.1 peaks at around 500 Mbit/s.

Since the only change between my sets of tests is the software,
something has clearly improved in either the kernel or OpenWrt (as
would be expected :)). Are there any particular commits/patches that
would be worthwhile trying to backport to 21.02/5.4, or is the
difference to master/5.10 so big that there is no point and the best
is to wait for the next release? I guess one thing that hopefully
shouldn't be too hard is be to combine 21.02 userspace with the 5.10
kernel. That will be on the top of my todo-list for tomorrow.

Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reduced throughput with mt7621 and DSA

[Kristian Evensen]

Hello,

I am currently performing some performance measurements, comparing the
(wired) routing throughput (WAN <-> LAN) of 19.07, 21.02 and master on
mt7621 (ZBT WG-3526). I have connected one client to my LAN and one to
the WAN, and use iperf3 to measure. I create parallel flows (in order
to take advantage of the multiple CPU cores), use TCP and let iperf3
run for 30 sec. per test.

Based on my measurements, the throughput is reduced by ~50% going from
19.07 and to 21.02/master (~450Mbit/s vs. ~900Mbit/s). I do not have a
particular commit I can point to, but I believe the regressions is
caused by the introduction of DSA. Restoring the old swconfig driver,
brings my 21.02/master throughput up to roughly the same level as
19.07.

I am able to alleviate the reduction in throughput by enabling flow
offloading, but there are several cases where flow offloading does not
have an effect. When performing a similar measurement to the one above
over a Wireguard-tunnel, I see a similar reduction in performance (and
no help from flow offloading).

Does anyone know what could be the reason and if there is anything
that can be done to improve the performance when using DSA? Are there
for example any out of tree/not yet accepted patches that I should
try?

Thanks in advance for any help,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: MT7621 Flow Control

[Kristian Evensen]

Hello,

On Thu, Aug 6, 2020 at 1:44 PM Jaap Buurman  wrote:
> However, on this mailing list a user by the name of Kristian claims
> that disabling flow control helps fix this problem, as can be read
> here: 
> https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html

My patch unfortunately does not solve the problem, as I can still see
the timeout error. However, by disabling flow control, the frequency
of the error is decreased to the point where it almost never happens
(even on devices where I would frequently see the error). In order to
deal with the remaining timeout cases, I wrote a small watchdog script
that checks syslog for the timeout message and restarts networking if
the error occurs. A restart has always been able to recover networking
(at the cost of a small interruption).

Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH] netifd: Ensure custom MTU is respected for bridges

[Kristian Evensen]

When an interface is added or removed from a bridge, the kernel updates
the MTU to ETH_DATA_LEN or the minimum MTU of the ports (see
br_min_mtu() in net/bridge/br_if.c). netifd already works around this
behavior by updating the MTU when an interface is added to a bridge.
However, remove is not handled.

This commit introduces a new callback in the device-struct named
update_mtu. If the callback is set, it is called from cb_rtnl_event for
devices with a custom MTU.

The bridge code has been extended to make use of this callback. If the
MTU received from the kernel differs from the custom MTU, the MTU of the
bridge device is update. The callback covers both the case when a device
is added and removed (NEWLINK events are received in both cases), so the
old work-around is removed.

Signed-off-by: Kristian Evensen 
---
 bridge.c   | 22 +-
 device.h   |  2 ++
 system-linux.c |  3 +++
 3 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/bridge.c b/bridge.c
index c1f4ffa..8421366 100644
--- a/bridge.c
+++ b/bridge.c
@@ -304,15 +304,9 @@ bridge_member_cb(struct device_user *dev, enum 
device_event ev)
 
if (bst->n_present == 1)
device_set_present(>dev, true);
-   if (bst->dev.active && !bridge_enable_member(bm)) {
-   /*
-* Adding a bridge member can overwrite the bridge mtu
-* in the kernel, apply the bridge settings in case the
-* bridge mtu is set
-*/
-   system_if_apply_settings(>dev, >dev.settings,
-DEV_OPT_MTU | DEV_OPT_MTU6);
-   }
+
+   if (bst->dev.active)
+   bridge_enable_member(bm);
 
break;
case DEV_EVENT_REMOVE:
@@ -710,6 +704,14 @@ bridge_retry_members(struct uloop_timeout *timeout)
}
 }
 
+static void
+bridge_update_mtu(struct device *dev, uint32_t mtu)
+{
+   if (dev->settings.mtu != mtu || dev->settings.mtu6 != mtu)
+   system_if_apply_settings(dev, >settings, DEV_OPT_MTU |
+ DEV_OPT_MTU6);
+}
+
 static struct device *
 bridge_create(const char *name, struct device_type *devtype,
struct blob_attr *attr)
@@ -735,6 +737,8 @@ bridge_create(const char *name, struct device_type *devtype,
bst->set_state = dev->set_state;
dev->set_state = bridge_set_state;
 
+   dev->update_mtu = bridge_update_mtu;
+
dev->hotplug_ops = _ops;
 
vlist_init(>members, avl_strcmp, bridge_member_update);
diff --git a/device.h b/device.h
index 5f3fae2..382af81 100644
--- a/device.h
+++ b/device.h
@@ -25,6 +25,7 @@ struct device_hotplug_ops;
 struct interface;
 
 typedef int (*device_state_cb)(struct device *, bool up);
+typedef void (*device_mtu_cb)(struct device *, uint32_t mtu);
 
 enum {
DEV_ATTR_TYPE,
@@ -213,6 +214,7 @@ struct device {
 
/* set interface up or down */
device_state_cb set_state;
+   device_mtu_cb update_mtu;
 
const struct device_hotplug_ops *hotplug_ops;
 
diff --git a/system-linux.c b/system-linux.c
index 3b09bbb..54a35d0 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -597,6 +597,9 @@ static int cb_rtnl_event(struct nl_msg *msg, void *arg)
 
device_set_link(dev, link_state ? true : false);
 
+   if (nla[IFLA_MTU] && (dev->settings.flags & DEV_OPT_MTU) &&
+   dev->update_mtu)
+   dev->update_mtu(dev, nla_get_u32(nla[IFLA_MTU]));
 out:
return 0;
 }
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] netifd: Improve handling of device rename

[Kristian Evensen]

Hi,

On Wed, Mar 11, 2020 at 2:13 PM Kristian Evensen
 wrote:
>
> After an interface has been renamed on a "fast" device (for example
> x86_64), the interface is sometimes not handled correctly by netifd.
> Looking in the logs, I see the following messages when renaming fails:
>
> Wed Mar 11 08:52:44 2020 kern.info kernel: [68383.522038] igb :03:00.0 
> nlw_1: renamed from eth2
> Wed Mar 11 08:52:44 2020 daemon.err netifd[2739]: __device_add_user(710): Add 
> user for device 'nlw_1', refcount=2
> Wed Mar 11 08:52:44 2020 daemon.err netifd[2739]: device_claim(413): Claim 
> Network device nlw_1, new active count: 2
> Wed Mar 11 08:52:44 2020 daemon.err netifd[2739]: device_claim(432): claim 
> Network device nlw_1 failed: -1
>
> Instrumenting netifd further reveals that there is a race between the hotplug
> "@move" event and ioctl(SIOCGIFINDEX). When the above error happens, the
> ioctl-call fails with ENODEV. Looking closer at the kernel code, it seems the
> hotplug-event is triggered before the renaming is completed. The easiest way 
> to
> trigger the race, is if an interface name with the old name is not handled by
> netifd and an interface with the new name is. If only the old name is handled,
> or both names, I was not able to provoke the race.
>
> When the renaming is complete, a NEWLINK-message is generated. This patch
> modifies the logic surrounding renaming, so that we wait for the
> NEWLINK-message before marking an interface as present. The changes made are:
>
> * We only handle move-events for interfaces we know, and we return after
> device has been set as not present.
> * When we receive a NEWLINK message for an interface managed by netifd,
> we call device_set_present. device_set_present is guarded by the same
> checks as the add hotplug-event.
>
> After these changes, renaming works properly on both "fast" and "slow"
> devices. Removing a device is also handled correctly.
>
> Signed-off-by: Kristian Evensen 

I was wondering if anyone has had time to look at this patch and have
any opinions? I've been running the change in production since the
change was submitted, and all my renaming issues have been resolved
(and no new ones have appeared :)).

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] netifd: Improve handling of device rename

[Kristian Evensen]

After an interface has been renamed on a "fast" device (for example
x86_64), the interface is sometimes not handled correctly by netifd.
Looking in the logs, I see the following messages when renaming fails:

Wed Mar 11 08:52:44 2020 kern.info kernel: [68383.522038] igb :03:00.0 
nlw_1: renamed from eth2
Wed Mar 11 08:52:44 2020 daemon.err netifd[2739]: __device_add_user(710): Add 
user for device 'nlw_1', refcount=2
Wed Mar 11 08:52:44 2020 daemon.err netifd[2739]: device_claim(413): Claim 
Network device nlw_1, new active count: 2
Wed Mar 11 08:52:44 2020 daemon.err netifd[2739]: device_claim(432): claim 
Network device nlw_1 failed: -1

Instrumenting netifd further reveals that there is a race between the hotplug
"@move" event and ioctl(SIOCGIFINDEX). When the above error happens, the
ioctl-call fails with ENODEV. Looking closer at the kernel code, it seems the
hotplug-event is triggered before the renaming is completed. The easiest way to
trigger the race, is if an interface name with the old name is not handled by
netifd and an interface with the new name is. If only the old name is handled,
or both names, I was not able to provoke the race.

When the renaming is complete, a NEWLINK-message is generated. This patch
modifies the logic surrounding renaming, so that we wait for the
NEWLINK-message before marking an interface as present. The changes made are:

* We only handle move-events for interfaces we know, and we return after
device has been set as not present.
* When we receive a NEWLINK message for an interface managed by netifd,
we call device_set_present. device_set_present is guarded by the same
checks as the add hotplug-event.

After these changes, renaming works properly on both "fast" and "slow"
devices. Removing a device is also handled correctly.

Signed-off-by: Kristian Evensen 
---
 system-linux.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/system-linux.c b/system-linux.c
index d533be8..aff67d6 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -590,6 +590,11 @@ static int cb_rtnl_event(struct nl_msg *msg, void *arg)
if (!system_get_dev_sysctl("/sys/class/net/%s/carrier", dev->ifname, 
buf, sizeof(buf)))
link_state = strtoul(buf, NULL, 0);
 
+   if (dev->type == _device_type &&
+   !system_if_force_external(dev->ifname) &&
+   !dev->present)
+   device_set_present(dev, true);
+
device_set_link(dev, link_state ? true : false);
 
 out:
@@ -652,13 +657,15 @@ handle_hotplug_msg(char *data, int size)
 move:
dev = device_find(interface_old);
if (!dev)
-   goto found;
+   return;
 
if (dev->type != _device_type)
goto found;
 
device_set_present(dev, false);
 
+   return;
+
 found:
dev = device_find(interface);
if (!dev)
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: gsw_mt7621: disable PORT 5 MAC RX/TX flow control by default

[Kristian Evensen]

Hi everyone,

I am sorry for my late reply to this thread. My email provider flagged
it as spam, so I only saw the conversation now. It seems that you have
reached a conclusion on how to proceed, but I thought I should anyway
share my notes/observations on this issue (in case they can be
useful).

My employer has a large number of Mediatek-based (mt7620 and mt7621)
routers in production. Most routers have a minimum of two internet
connections - one fixed and one using mobile broadband. Some time in
2017 we started receiving reports from a few customers that the switch
would stop working. The link was up, but no data would go through.
Looking at the logs, we could always see the "TX timeout" error
message and we started to look for a cause.

We quickly ruled out any kind of crash, as the LTE was still up and
wifi worked fine. After getting a few of these reports, we started
looking for things that were common between the different
installations. We struggled to find any, there were all sorts of
devices connected to the different ports on the routers. The only
thing the different cases had in common, was that the problem
disappeared when whatever was connected to the WAN port was
disconnected. However, again, the equipment that provided the fixed
connection came from all sorts of vendors.

After scratching our heads for a while and not getting anywhere, I
asked here on the mailing list and was told that restarting networking
should at least make the switch works fine again. We added a watchdog
doing exactly that when the TX timeout message would appear.
Restarting networking improved the situation considerably, but the
switch would still sometimes get stuck and never recover.

This triggered us to make a second attempt at recreating the problem.
Our test was the same as what Rene described. We assumed the problem
had something to do with sending large amounts of traffic and at a
high speed, so we used iperf3 as a traffic generator and sent traffic
between different machines connected to the switch. One of these
machines were quite unstable and prone to crash, and we noticed that
whenever that machine would crash the TX timeout issue would trigger
and no traffic would pass through the switch.

A normal packet capture didn't reveal anything interesting, but
connecting a network tap did. Looking at the packets captured from the
tap, we could see a flood of pause frames from the crashed machine.
When this flood occurred, the switch stopped transmitting packets on
all the ports and not just the one that the crashed machine was
connected to. This caught us by surprise, but doing some research it
seems to be a common behavior among "normal" switches. Also, if we
waited long enough, the switch would never recover.

After discovering that pause frames seemed to be at least one trigger
for TX timeout, we added support to the driver for enabling/disabling
flow control on each of the ports + an init script that does the
disabling. Since we deployed this change on our routers, we have not
had a single report about switches that stop working. We do sometimes
still see the "TX timeout" error, but it is no longer critical.

We never tried to disable flow control on the CPU-port only, which
seems like a more elegant approach than disabling each port
individually. I do agree that disabling pause frames is more a
work-around than a solution, but it has at least eradicated the
problem for us. I never got around to submitting our patch, but if
anyone would find it useful I can do it quite soon.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] nftables: Update nftables & clean up dependencies

[Kristian Evensen]

Hi,

On Tue, Feb 11, 2020 at 2:04 PM Petr Štetiar  wrote:
> > * Cleans up the nftables-dependencies in netfilter.mk. All targets are
> > not at 4.14+, so there is no need to specify for example "ge 4.9.0" or
> > keep "lt 4.9.0" around.
> > * Fix building support for nftables sets. In 4.18 the configuration
> > symbol changed from CONFIG_NFT_SET_RBTREE and CONFIG_NFT_SET_HAS, to
> > CONFIG_NF_TABLES_SET.
>
> Some of these has been probably fixed in 0e05093b12ef, can you check again?
> Thanks.

Thanks for your feedback. I will try to find some time to work with
nftables in the not too distant future :)

Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ipq40xx: u4019: use reset-gpios instead of phy-reset-gpio

[Kristian Evensen]

Use reset-gpio instead of the custom phy-reset-gpio property to do phy
reset on the U4019. phy-reset-gpio was incorrectly introduced when we
added support for the U4019, and will be deprecated.

Signed-off-by: Kristian Evensen 
---
 .../arch/arm/boot/dts/qcom-ipq4019-unielec-u4019.dtsi  | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019.dtsi
 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019.dtsi
index cf67fddd2b..c768e25ca0 100644
--- 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019.dtsi
+++ 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019.dtsi
@@ -17,7 +17,8 @@
status = "okay";
pinctrl-0 = <_pins>;
pinctrl-names = "default";
-   phy-reset-gpio = < 47 0>;
+   reset-gpios = < 47 GPIO_ACTIVE_LOW>;
+   reset-delay-us = <2000>;
};
 
ess-psgmii@98000 {
-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 1/2] base-files: always store label MAC address in uci system config

[Kristian Evensen]

Hi,

On Mon, Nov 4, 2019 at 4:36 PM Adrian Schmutzler
 wrote:
> However, I'm not aware of a case where board.json is used for anything else 
> than setting up config files, like in a script with user-interaction etc.

While I agree that those are the most common use-cases for board.json,
board.json is used by for example luci to determine which parts of
network configuration to display.

> So, if I want to bring the label MAC address to users updating to 
> 20.xx/master, I'd either have to use board.json in get_mac_label, or add 
> label_macaddr for those not having it even though /etc/config/system already 
> exists. One could still think about providing a label_macaddr option in uci 
> only for _overwriting_ the provided value.

I am not overly familiar with them, but I think this problem can be
resolved by a uci-defaults script. As far as I have understood, those
scripts are run once and then remove. You could create a script that
checks board.json/device tree (basically a combination of the changes
in your patch) and update system-config accordingly.

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

[Kristian Evensen]

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 v2 1/2] base-files: always store label MAC address in uci system config

[Kristian Evensen]

Hi Adrian,

On Mon, Nov 4, 2019 at 11:44 AM Adrian Schmutzler
 wrote:
>
> If set, label MAC address is available from one of two sources,
> device tree or board.json. So far, the function get_mac_label
> was meant for retrieving the address, while an option in uci
> system config was specified only for case 2 (board.json).
>
> Since this has been perceived as counter-intuitive, this patch
> changes front-end access to the label MAC address:
> During first-boot, the label MAC address will be written to uci
> system config file for both cases, no matter whether is was
> specified in DT or in board.json (via 02_network). A user of
> the label MAC address will then read the value from
> system.@system[0].label_macaddr, which is easier and more intuitive
> than using a function and still have an uci value set.
>
> Since this is only changing the access to the label MAC address, it
> won't interfere with the addresses stored in the code base so far.
>
> Signed-off-by: Adrian Schmutzler 

I am not an authority on anything, but I don't think a "runtime" value
like the label mac should be stored in a persistent configuration
file. For example, if someone makes a mistake with the label MAC, you
would need a uci-default script for fixing up the config. You also
have the issue of devices that have already been installed, without a
uci-defaults script they will not have a label mac in UCI.

Instead, I would keep board.json as the source for label MAC and have
get_mac_label parse the JSON-file. I guess you might also have to
patch the generation of board.json to include the device tree. At
least I think that board.json is as easy to work with as uci from
scripts, Luci, etc.

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

[Kristian Evensen]

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 1/2] ramips: Update ZBT WE1026 DTS-files

[Kristian Evensen]

Hi,

On Sat, Nov 2, 2019 at 3:18 PM Kristian Evensen
 wrote:
> Acked-by: Mathias Kresin 
> Acked-by: Alex Maclean 
> Acked-by: INAGAKI Hiroshi 
> Acked-by: Petr Štetiar 

I was a bit too fast when sending this patch and forgot to add the
ones who have ACKed the proposed change to the recipient list. Sorry
about that.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3 0/2] Add support for the ZBT WE1026-H

[Kristian Evensen]

This patch series adds support for the ZBT WE1026-H, an outdoor AP with support
for adding an internal LTE modem. The first patch restructures the DTS files for
the WE0126-5G slightly and adds a WE1026 DTSI-file, containing descriptions of
the components that are shared between the WE0126-5G and the WE1026-H. The
second patch adds support for the WE1026-H.

The main change between v1 and v2 is the addition of acked-bys on the first
patch, triggered by the re-licensing of the DTS'. The changes between v2 and v3
are mostly related to ensuring consistent naming.

Signed-off-by: Kristian Evensen 

Kristian Evensen (2):
  ramips: Update ZBT WE1026 DTS-files
  ramips: Add support for ZBT WE1026-H

 .../ramips/base-files/etc/board.d/01_leds |   5 +
 .../ramips/base-files/etc/board.d/02_network  |   9 +-
 .../dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts |  77 +
 .../dts/mt7620a_zbtlink_zbt-we1026-5g.dtsi|  93 +---
 .../dts/mt7620a_zbtlink_zbt-we1026-h-32m.dts  |  14 +++
 .../dts/mt7620a_zbtlink_zbt-we1026-h.dtsi |  40 +++
 .../dts/mt7620a_zbtlink_zbt-we1026.dtsi   | 103 ++
 target/linux/ramips/image/mt7620.mk   |  11 ++
 8 files changed, 189 insertions(+), 163 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
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026.dtsi

-- 
2.20.1


___
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

[Kristian Evensen]

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",&quo

[OpenWrt-Devel] [PATCH v3 1/2] ramips: Update ZBT WE1026 DTS-files

[Kristian Evensen]

This commit makes the following changes to the WE1026 DTS-files:

* The parts that are unique to the -5G-version (LED and 5GHz wifi)
are moved to a separate file, so that WE1026.dtsi can be referenced also
by the DTS for the -H version.
* Changed button from polled to interrupt.
* Use the generic "flash"-name for the spi-nor node.
* Add label MAC.

All changes have been tested on the WE1026-5G-16M and work fine. I.e.,
the device works as before the DTS-changes.

Signed-off-by: Kristian Evensen 
Acked-by: Mathias Kresin 
Acked-by: Alex Maclean 
Acked-by: INAGAKI Hiroshi 
Acked-by: Petr Štetiar 
---
v3->v2:
* Rebase on top of recent changes.
* Add label MAC (thanks Adrian Schmutzler)

v1->v2:
* Added missing acked-bys.
---
 .../ramips/base-files/etc/board.d/02_network  |   3 +
 .../dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts |  77 +
 .../dts/mt7620a_zbtlink_zbt-we1026-5g.dtsi|  93 +---
 .../dts/mt7620a_zbtlink_zbt-we1026.dtsi   | 103 ++
 4 files changed, 115 insertions(+), 161 deletions(-)
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026.dtsi

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 480726a870..373651e64e 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -729,6 +729,9 @@ ramips_setup_macs()
lan_mac=$(mtd_get_mac_binary factory 0xe006)
label_mac=$lan_mac
;;
+   zbtlink,zbt-we1026-5g-16m)
+   label_mac=$(cat /sys/class/ieee80211/phy1/macaddress)
+   ;;
zbtlink,zbt-we1326)
wan_mac=$(mtd_get_mac_binary factory 0xe006)
label_mac=$(cat /sys/class/ieee80211/phy0/macaddress)
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts
index feba29763b..c5e630b1be 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_zbt-we1026-5g-16m.dts
@@ -1,81 +1,14 @@
-/*
- *  BSD LICENSE
- *
- *  Copyright(c) 2017 Kristian Evensen .
- *  All rights reserved.
- *
- *  Redistribution and use in source and binary forms, with or without
- *  modification, are permitted provided that the following conditions
- *  are met:
- *
- ** Redistributions of source code must retain the above copyright
- *  notice, this list of conditions and the following disclaimer.
- ** Redistributions in binary form must reproduce the above copyright
- *  notice, this list of conditions and the following disclaimer in
- *  the documentation and/or other materials provided with the
- *  distribution.
- ** Neither the name of Broadcom Corporation nor the names of its
- *  contributors may be used to endorse or promote products derived
- *  from this software without specific prior written permission.
- *
- *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
 /dts-v1/;
 
 #include "mt7620a_zbtlink_zbt-we1026-5g.dtsi"
 
 / {
-   compatible = "zbtlink,zbt-we1026-5g-16m", "ralink,mt7620a-soc";
+   compatible = "zbtlink,zbt-we1026-5g-16m", "zbtlink,zbt-we1026-5g",
+"zbtlink,zbt-we1026", "ralink,mt7620a-soc";
model = "Zbtlink ZBT-WE1026-5G (16M)";
 };
 
- {
-   status = "okay";
-
-   en25q128@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <1000>;
-
-   partitions {
-   compatible = "fixed-partitions";
-   #address-cells = <1>;
-   #size-cells = <1>;
-
-   partition@0 {
-   label = "u-boot";
-   reg = <0x0 0x3>;
-   read-only;
-   };
-
- 

Re: [OpenWrt-Devel] [RFC] firewall3: zones: Use ipsets instead of interfaces in zone rules

[Kristian Evensen]

Hi all,

On Wed, Aug 28, 2019 at 7:37 PM Kristian Evensen
 wrote:
>
> firewall3 currently creates one rule for each interface that is a member of a
> zone. On for example devices with multiple interfaces, the current firewall3
> behavior quickly leads to a lot of rules. In order to reduce the number of
> rules, this patch replaces the per-interface rules with ipset matches (if 
> ipset
> is available). Since 2011, ipset has supported the set type "hash:net,iface".
> By adding (and matching on) on pairs consiting of the v4/v6 any-address and an
> interface name, we get the same behavior as the current interface-rules.
>
> After applying this patch (and assuming ipset is available), the following
> actions are performed when a zone is created:
>
> * We creates (allocate) an ipset of type "hash:net,iface" for each zone. The
> name follows the following format: zone__<4/6>_set.
> * If creating a set fails, then we ignore the zone. This is something we can
> change, but my reason for this behavior is to have consistent firewall rules.
> I.e., zone-rules either match on ipset or interface names, and not a mix.
> * Each set is populated with pairs consisting of the IPv4/IPv6 any-address and
> an interface name, for example "0.0.0.0/0, eth0.2".
> * Instead of one rule per device, a single rule is created matching on the
> ipset.
> * The check used to select the OUTPUT/PREROUTING-chain when adding rules to 
> the
> raw-table has been moved to print_interface_rules_{default,set}. The 
> motivation
> behind this move was to avoid changing print_interface_rule() too much. As far
> as I can see (and have tested), the logic for selecting chain/creating the
> rules is the same as before.
>
> Because the change introduced by this patch is quite intrusive and I am sure
> there will be comments/disagreements/suggestions, I have sent this patch as an
> RFC. One thing that I am aware of and will fix before the final submission, is
> to add support for printing ipsets. Right now "fw3 print" prints per-interface
> rules.

I have had the chance to run this patch in production for a while, and
thought I should share my experiences. All in all, switching to ipsets
seems to work well and, with one exception, I have not found any
configurations or configuration steps that break. Also, in some of my
setups, the number of iptables rules are greatly reduced. While I
haven't measured any performance improvements, fewer rules makes the
rule set easier to work with. The need to reload the firewall on ifup
is also removed (it is sufficient to update the set), which removes an
annoying gap or interruption in traffic on some of the devices I am
running.

What (currently) breaks is wildcard interface names, ipset currently
has no wildcard-support. I have submitted a patch upstream adding
support for wildcard naming, and have received positive feedback but
no final decision.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ipq40xx: Add support for Unielec U4019

[Kristian Evensen]

Hi,

On Mon, Oct 21, 2019 at 6:07 PM Robert Marko  wrote:
>
> Merging this today has caused a regression in ipq40xx.
> PHY reset patch was is the issue, it now forces devices to have GPIO
> for PHY reset which most devices don't have and if it's missing it
> will make the driver panic and probing will fail.
> So please revert this until its properly resolved.

I am very sorry for this mistake, making phy-reset optional completely
slipped my mind. I will not have access to an ipq40xx device before
some time next week, so I am fine with reverting for now (unless
someone else can take a look).

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

[Kristian Evensen]

Hi Adrian,

On Tue, Sep 24, 2019 at 6:22 PM  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

Re: [OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

[Kristian Evensen]

Hi,

On Tue, Sep 24, 2019 at 1:28 PM Adrian Schmutzler
 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-hcorresponding to modelZBT-WE1026-H
> or
> zbtlink,we1026-hcorresponding to modelWE1026-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 00..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)";
> > +};
> > +
> > + {
> > + reg = <0x5 0x1fb>;
> > +};
> > 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 00..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 = _power;
> > + led-failsafe = _power;
> > + led-running = _power;
> > + led-upgrade = _power;
> > + label-mac-device = 
>
> 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 

[OpenWrt-Devel] [PATCH v2 0/2] Add support for the ZBT WE1026-H

[Kristian Evensen]

This patch series adds support for the ZBT WE1026-H, an outdoor AP with support
for adding an internal LTE modem. The first patch restructures the DTS files for
the WE0126-5G slightly and adds a WE1026 DTSI-file, containing descriptions of
the components that are shared between the WE0126-5G and the WE1026-H. The
second patch adds support for the WE1026-H.

The main change between v1 and v2 is the addition of acked-bys on the first
patch, triggered by the re-licensing of the DTS'.

Signed-off-by: Kristian Evensen 

Kristian Evensen (2):
  ramips: Update ZBT WE1026 DTS-files
  ramips: Add support for ZBT WE1026-H

 .../ramips/base-files/etc/board.d/01_leds |  5 +
 .../ramips/base-files/etc/board.d/02_network  |  6 +-
 .../dts/mt7620a_zbtlink_we1026-5g-16m.dts | 77 +--
 .../ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi | 90 +
 .../dts/mt7620a_zbtlink_we1026-h-32m.dts  | 14 +++
 .../ramips/dts/mt7620a_zbtlink_we1026-h.dtsi  | 42 
 .../ramips/dts/mt7620a_zbtlink_we1026.dtsi| 99 +++
 target/linux/ramips/image/mt7620.mk   | 12 +++
 8 files changed, 186 insertions(+), 159 deletions(-)
 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
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026.dtsi

-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2 2/2] ramips: Add support for ZBT WE1026-H

[Kristian Evensen]

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 
---
 .../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)
+   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 00..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)";
+};
+
+ {
+   reg = <0x5 0x1fb>;
+};
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 10

[OpenWrt-Devel] [PATCH v2 1/2] ramips: Update ZBT WE1026 DTS-files

[Kristian Evensen]

This commit makes the following changes to the WE1026 DTS-files:

* The parts that are unique to the -5G-version (LED and 5GHz wifi)
are moved to a separate file, so that WE1026.dtsi can be referenced also
by the DTS for the -H version.
* Changed button from polled to interrupt.
* Use the generic "flash"-name for the spi-nor node.

All changes have been tested on the WE1026-5G-16M and work fine. I.e.,
the device works as before the DTS-changes.

v1->v2:
* Added missing acked-bys.

Signed-off-by: Kristian Evensen 
Acked-by: Mathias Kresin 
Acked-by: Alex Maclean 
Acked-by: INAGAKI Hiroshi 
Acked-by: Petr Štetiar 
---
 .../dts/mt7620a_zbtlink_we1026-5g-16m.dts | 77 +--
 .../ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi | 93 +
 .../ramips/dts/mt7620a_zbtlink_we1026.dtsi| 99 +++
 3 files changed, 108 insertions(+), 161 deletions(-)
 create mode 100644 target/linux/ramips/dts/mt7620a_zbtlink_we1026.dtsi

diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts 
b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
index e2eb5b6329..0bb6812fcf 100644
--- a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
+++ b/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g-16m.dts
@@ -1,81 +1,14 @@
-/*
- *  BSD LICENSE
- *
- *  Copyright(c) 2017 Kristian Evensen .
- *  All rights reserved.
- *
- *  Redistribution and use in source and binary forms, with or without
- *  modification, are permitted provided that the following conditions
- *  are met:
- *
- ** Redistributions of source code must retain the above copyright
- *  notice, this list of conditions and the following disclaimer.
- ** Redistributions in binary form must reproduce the above copyright
- *  notice, this list of conditions and the following disclaimer in
- *  the documentation and/or other materials provided with the
- *  distribution.
- ** Neither the name of Broadcom Corporation nor the names of its
- *  contributors may be used to endorse or promote products derived
- *  from this software without specific prior written permission.
- *
- *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
 /dts-v1/;
 
 #include "mt7620a_zbtlink_we1026-5g.dtsi"
 
 / {
-   compatible = "zbtlink,we1026-5g-16m", "ralink,mt7620a-soc";
+   compatible = "zbtlink,we1026-5g-16m", "zbtlink,we1026-5g",
+"zbtlink,we1026", "ralink,mt7620a-soc";
model = "ZBT WE1026-5G (16M)";
 };
 
- {
-   status = "okay";
-
-   en25q128@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <1000>;
-
-   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;
-   };
-
-   factory: partition@4 {
-   label = "factory";
-   reg = <0x4 0x1>;
-   read-only;
-   };
-
-   firmware: partition@5 {
-   compatible = "denx,uimage";
-   label = "firmware";
-   reg = <0x5 0xfb>;
-   };
-   };
-   };
+ {
+   reg = <0x5 0xfb>;
 };
diff --git a/target/linux/ramips/dts/mt7620a_zbtlink_we1026-5g.dtsi 
b/target/linux/ramips/dts/mt7620a_zb

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files

[Kristian Evensen]

Hi Petr,

On Fri, Sep 20, 2019 at 9:56 AM Petr Štetiar  wrote:
> could you please rebase to series to the current state of the tree? I would
> like to apply it, thanks!
>
> BTW don't forget to include the license change ACKs.

I will do it during or right over the weekend. Btw, can I consider
this your ACK of the licensing change as well?

Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] ipq40xx: Add support for Unielec U4019

[Kristian Evensen]

This commit adds support for the 32MB storage/512MB RAM version of the U4019
IPQ4019-based board from Unielec. The board has the following specifications:

* Qualcomm IPQ4019 (running at 717MHz)
* 512MB DDR3 RAM (optional 256MB/1GB)
* 32MB SPI NOR (optional 8/16MB or NAND)
* Five gigabit ports (Qualcomm QCA8075)
* 1x 2.4 GHz wifi (QCA4019 hw1.0)
* 1x 5 Ghz wifi (QCA4019 hw1.0)
* 1x mini-PCIe slot (only USB-pins connected)
* 1x SIM slot (mini-SIM)
* 1x USB2.0 port
* 1x button
* 1x controllable LED
* 1x micro SD-card reader

Working:
* Ethernet
* Wifi
* USB-port
* mini-PCIe slot + SIM slot
* Button
* Sysupgrade

Not working:
* SD card slot (no upstream support)

Installation instructions:

In order to install OpenWRT on the U4019, you need to go via the
initramfs-image. The installation steps are as follows:

* Connect to board via serial (header exposed and clearly marked).
* Interrupt bootloader by pressing a button.
* Copy the initramfs-image to your tftp folder, call the file C0A80079.img.
* Give the network interface connected to the U4019 the address
192.168.0.156/24.
* Start your tftp-server and run tftpboot on the board.
* Run bootm when the file has been transferred, to boot OpenWRT.
* Once OpenWRT has booted, copy the sysupgrade-image to the device and run
sysupgrade to install OpenWRT on the U4019.

Notes:

- Since IPQ4019 has been moved to 4.19, I have not added support for kernel
4.14.

- There is a bug with hardware encryption on IPQ4019, causing poor performance
with TCP and ipsec (see for example FS#2355). In order to improve performance,
I have disabled hardware encryption in the DTS. We can enable hw. enc. once/if
bug is fixed.

- In order for Ethernet to work, the phy has to be reset by setting gpio 47
low/high. Adding support for phy reset via gpio required patching the
mdio-driver, and the code added comes from the vendor driver. I do not know if
patching the driver is an acceptable approach or not.

v1->v2:
* Do not use wildcard as identifier in the board.d-scripts (thanks
Adrian Schmutzler).

Signed-off-by: Kristian Evensen 
---
 .../ipq40xx/base-files/etc/board.d/02_network |   5 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   6 +-
 .../dts/qcom-ipq4019-unielec-u4019-32m.dts|  79 +++
 .../boot/dts/qcom-ipq4019-unielec-u4019.dtsi  | 223 ++
 target/linux/ipq40xx/image/Makefile   |  13 +
 .../700-net-add-qualcomm-mdio.patch   |  80 ++-
 .../901-arm-boot-add-dts-files.patch  |  15 +-
 7 files changed, 410 insertions(+), 11 deletions(-)
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019.dtsi

diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network 
b/target/linux/ipq40xx/base-files/etc/board.d/02_network
index e5ba7260f3..f036dc842f 100755
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -61,6 +61,11 @@ ipq40xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0u@eth0" "3:lan" "4:lan" "0u@eth1" "5:wan"
;;
+   unielec,u4019-32m)
+   ucidef_set_interfaces_lan_wan "eth0" "eth1"
+   ucidef_add_switch "switch0" \
+   "0u@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "0u@eth1" 
"5:wan"
+   ;;
*)
echo "Unsupported hardware. Network interfaces not initialized"
;;
diff --git 
a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index be57646128..ee1e899fae 100644
--- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -161,7 +161,8 @@ case "$FIRMWARE" in
openmesh,a42 |\
openmesh,a62 |\
qxwlan,e2600ac-c1 |\
-   qxwlan,e2600ac-c2)
+   qxwlan,e2600ac-c2 |\
+   unielec,u4019-32m)
ath10kcal_extract "0:ART" 0x1000 0x2f20
;;
engenius,ens620ext)
@@ -222,7 +223,8 @@ case "$FIRMWARE" in
openmesh,a42 |\
openmesh,a62 |\
qxwlan,e2600ac-c1 |\
-   qxwlan,e2600ac-c2)
+   qxwlan,e2600ac-c2 |\
+   unielec,u4019-32m)
ath10kcal_extract "0:ART" 0x5000 0x2f20
;;
engenius,ens620ext)
diff --git 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
new file mode 100644
index 00..606ac165ba
--- /dev/

[OpenWrt-Devel] [RFC] firewall3: zones: Use ipsets instead of interfaces in zone rules

[Kristian Evensen]

firewall3 currently creates one rule for each interface that is a member of a
zone. On for example devices with multiple interfaces, the current firewall3
behavior quickly leads to a lot of rules. In order to reduce the number of
rules, this patch replaces the per-interface rules with ipset matches (if ipset
is available). Since 2011, ipset has supported the set type "hash:net,iface".
By adding (and matching on) on pairs consiting of the v4/v6 any-address and an
interface name, we get the same behavior as the current interface-rules.

After applying this patch (and assuming ipset is available), the following
actions are performed when a zone is created:

* We creates (allocate) an ipset of type "hash:net,iface" for each zone. The
name follows the following format: zone__<4/6>_set.
* If creating a set fails, then we ignore the zone. This is something we can
change, but my reason for this behavior is to have consistent firewall rules.
I.e., zone-rules either match on ipset or interface names, and not a mix.
* Each set is populated with pairs consisting of the IPv4/IPv6 any-address and
an interface name, for example "0.0.0.0/0, eth0.2".
* Instead of one rule per device, a single rule is created matching on the
ipset.
* The check used to select the OUTPUT/PREROUTING-chain when adding rules to the
raw-table has been moved to print_interface_rules_{default,set}. The motivation
behind this move was to avoid changing print_interface_rule() too much. As far
as I can see (and have tested), the logic for selecting chain/creating the
rules is the same as before.

Because the change introduced by this patch is quite intrusive and I am sure
there will be comments/disagreements/suggestions, I have sent this patch as an
RFC. One thing that I am aware of and will fix before the final submission, is
to add support for printing ipsets. Right now "fw3 print" prints per-interface
rules.

Signed-off-by: Kristian Evensen 
---
 ipsets.c  |  38 ++-
 ipsets.h  |   7 ++
 main.c|   8 +-
 options.c |   3 +-
 options.h |   4 +
 zones.c   | 291 +++---
 zones.h   |  15 ++-
 7 files changed, 347 insertions(+), 19 deletions(-)

diff --git a/ipsets.c b/ipsets.c
index 280845b..e052278 100644
--- a/ipsets.c
+++ b/ipsets.c
@@ -81,6 +81,8 @@ static struct ipset_type ipset_types[] = {
  OPT_FAMILY | OPT_HASHSIZE | OPT_MAXELEM),
T(HASH,   NET,  PORT,   UNSPEC, 0,
  OPT_FAMILY | OPT_HASHSIZE | OPT_MAXELEM),
+   T(HASH,   NET,  IFACE,   UNSPEC, 0,
+ OPT_FAMILY | OPT_HASHSIZE | OPT_MAXELEM),
T(HASH,   IP,   PORT,   IP, 0,
  OPT_FAMILY | OPT_HASHSIZE | OPT_MAXELEM),
T(HASH,   IP,   PORT,   NET,0,
@@ -247,7 +249,7 @@ check_ipset(struct fw3_state *state, struct fw3_ipset 
*ipset, struct uci_element
return false;
 }
 
-static struct fw3_ipset *
+struct fw3_ipset *
 fw3_alloc_ipset(struct fw3_state *state)
 {
struct fw3_ipset *ipset;
@@ -611,3 +613,37 @@ fw3_ipsets_update_run_state(enum fw3_family family, struct 
fw3_state *run_state,
ipset_run->reload_set = ipset_cfg->reload_set;
}
 }
+
+void
+fw3_ipset_add_devices(struct list_head *devices, enum fw3_family family,
+ const char *set_name)
+{
+   struct fw3_device *dev;
+   bool exec = false;
+   const char *addr;
+
+   fw3_foreach(dev, devices) {
+   if (!dev)
+   continue;
+
+   if (!exec) {
+   exec = fw3_command_pipe(false, "ipset", "-exist", "-");
+
+   if (!exec)
+   return;
+   }
+
+   if (family == FW3_FAMILY_V4) {
+   addr = "0.0.0.0/0";
+   } else {
+   addr = "::/0";
+   }
+
+   fw3_pr("add %s %s,%s\n", set_name, addr, dev->name);
+   }
+
+   if (exec) {
+   fw3_pr("quit\n");
+   fw3_command_close();
+   }
+}
diff --git a/ipsets.h b/ipsets.h
index 76078d4..19528e9 100644
--- a/ipsets.h
+++ b/ipsets.h
@@ -41,6 +41,13 @@ void
 fw3_ipsets_update_run_state(enum fw3_family family, struct fw3_state 
*run_state,
struct fw3_state *cfg_state);
 
+struct fw3_ipset *
+fw3_alloc_ipset(struct fw3_state *state);
+
+void
+fw3_ipset_add_devices(struct list_head *devices, enum fw3_family family,
+ const char *set_name);
+
 static inline void fw3_free_ipset(struct fw3_ipset *ipset)
 {
list_del(>list);
diff --git a/main.c b/main.c
index 7ad00b4..7b9c9e3 100644
--- a/main.c
+++ b/main.c
@@ -266,6 +266,9 @@ start(void)
continue;
}
 
+   if (!print_family)
+   fw3_fill_zone_ipsets(family, cfg_state);
+

[OpenWrt-Devel] [PATCH] ipq40xx: Add support for Unielec U4019

[Kristian Evensen]

This commit adds support for the 32MB storage/512MB RAM version of the U4019
IPQ4019-based board from Unielec. The board has the following specifications:

* Qualcomm IPQ4019 (running at 717MHz)
* 512MB DDR3 RAM (optional 256MB/1GB)
* 32MB SPI NOR (optional 8/16MB or NAND)
* Five gigabit ports (Qualcomm QCA8075)
* 1x 2.4 GHz wifi (QCA4019 hw1.0)
* 1x 5 Ghz wifi (QCA4019 hw1.0)
* 1x mini-PCIe slot (only USB-pins connected)
* 1x SIM slot (mini-SIM)
* 1x USB2.0 port
* 1x button
* 1x controllable LED
* 1x micro SD-card reader

Working:
* Ethernet
* Wifi
* USB-port
* mini-PCIe slot + SIM slot
* Button
* Sysupgrade

Not working:
* SD card slot (no upstream support)

Installation instructions:

In order to install OpenWRT on the U4019, you need to go via the
initramfs-image. The installation steps are as follows:

* Connect to board via serial (header exposed and clearly marked).
* Interrupt bootloader by pressing a button.
* Copy the initramfs-image to your tftp folder, call the file C0A80079.img.
* Give the network interface connected to the U4019 the address
192.168.0.156/24.
* Start your tftp-server and run tftpboot on the board.
* Run bootm when the file has been transferred, to boot OpenWRT.
* Once OpenWRT has booted, copy the sysupgrade-image to the device and run
sysupgrade to install OpenWRT on the U4019.

Notes:

- Since IPQ4019 has been moved to 4.19, I have not added support for kernel
4.14.

- There is a bug with hardware encryption on IPQ4019, causing poor performance
with TCP and ipsec (see for example FS#2355). In order to improve performance,
I have disabled hardware encryption in the DTS. We can enable hw. enc. once/if
bug is fixed.

- In order for Ethernet to work, the phy has to be reset by setting gpio 47
low/high. Adding support for phy reset via gpio required patching the
mdio-driver, and the code added comes from the vendor driver. I do not know if
patching the driver is an acceptable approach or not.

Signed-off-by: Kristian Evensen 
---
 .../ipq40xx/base-files/etc/board.d/02_network |   5 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata  |   6 +-
 .../dts/qcom-ipq4019-unielec-u4019-32m.dts|  79 +++
 .../boot/dts/qcom-ipq4019-unielec-u4019.dtsi  | 223 ++
 target/linux/ipq40xx/image/Makefile   |  13 +
 .../700-net-add-qualcomm-mdio.patch   |  80 ++-
 .../901-arm-boot-add-dts-files.patch  |  15 +-
 7 files changed, 410 insertions(+), 11 deletions(-)
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
 create mode 100644 
target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019.dtsi

diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network 
b/target/linux/ipq40xx/base-files/etc/board.d/02_network
index e5ba7260f3..781935c421 100755
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -61,6 +61,11 @@ ipq40xx_setup_interfaces()
ucidef_add_switch "switch0" \
"0u@eth0" "3:lan" "4:lan" "0u@eth1" "5:wan"
;;
+   unielec,u4019*)
+   ucidef_set_interfaces_lan_wan "eth0" "eth1"
+   ucidef_add_switch "switch0" \
+   "0u@eth0" "1:lan" "2:lan" "3:lan" "4:lan" "0u@eth1" 
"5:wan"
+   ;;
*)
echo "Unsupported hardware. Network interfaces not initialized"
;;
diff --git 
a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata 
b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index be57646128..430bc231a2 100644
--- a/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ipq40xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -161,7 +161,8 @@ case "$FIRMWARE" in
openmesh,a42 |\
openmesh,a62 |\
qxwlan,e2600ac-c1 |\
-   qxwlan,e2600ac-c2)
+   qxwlan,e2600ac-c2 |\
+   unielec,u4019*)
ath10kcal_extract "0:ART" 0x1000 0x2f20
;;
engenius,ens620ext)
@@ -222,7 +223,8 @@ case "$FIRMWARE" in
openmesh,a42 |\
openmesh,a62 |\
qxwlan,e2600ac-c1 |\
-   qxwlan,e2600ac-c2)
+   qxwlan,e2600ac-c2 |\
+   unielec,u4019*)
ath10kcal_extract "0:ART" 0x5000 0x2f20
;;
engenius,ens620ext)
diff --git 
a/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
new file mode 100644
index 00..606ac165ba
--- /dev/null
+++ 
b/target/linux/ipq40xx/files-4.19/arch/arm/boot/dts/qcom-ipq4019-unielec-u4019-32m.dts
@@ -0

Re: [OpenWrt-Devel] [PATCH v2] ramips: use gpio_hog instead of gpio-exp

[Kristian Evensen]

Hi,

On Fri, Aug 23, 2019 at 1:40 PM Birger Koblitz  wrote:
>
> ramips: use gpio_hog instead of gpio-export
>
> The `gpio-export` functionality is a hack for
> missing kernel functionality, which was rejected in upstream kernel long
> time
> ago, for details see this email
> http://lists.infradead.org/pipermail/openwrt-devel/2019-February/015772.html,
> discussion in PR#1366 or
> https://github.com/openwrt/openwrt/pull/1814#issuecomment-462942022.
>
> This patch converts all ramips .dts(i) files which were
> using export-gpio for powering USB/SATA ports to using gpio_hog instead

While clean-ups are nice, the patch in its current form will break a
lot of functionality that users depend on. By changing for example the
D240 power_mpcieX nodes to gpio-hog, it is no longer possible to
power-cycle the devices inserted in these slots. Power-cycling is for
example convenient when recovering LTE-modems that have crashed/hung
due to firmware bugs. While I am not familiar with some of the other
devices, I suspect a lot of the nodes names "power_usb" or similar
have the same functionality.

I would start by moving the GPIOs used for power-control of USB to
03_gpio_switches and then take a look at the GPIOs that are left. This
probably requires going through the commits adding support for the
different devices.

BR,
Kristian

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] firewall3: ipset: Handle reload_set properly

[Kristian Evensen]

The reload_set option was added in commit 509e673dab01 ("firewall3:
Improve ipset support"), and the purpose of the option is to control if
a set should be flushed or not on a firewall reload.

In some cases, the option unfortunately does not work properly. I had
fixed the errors locally, but failed to submit a v2 of "Improve ipset
support". This patch contains my local fixes, and after the following
changes are applied then the option (as well as ipset support) works as
at least I expect.

The following errors have been fixed:

* "family" was not written to the state file, causing all sets read from
this file was considered as ipv4. Save family to ensure that sets are
handled correctly on firewall reload.

* The default value of "reload_set" is false, meaning that the
reload-check in "fw3_create_ipsets()" is always true (on reload). A
consequence of this is that new sets are never created on firewall
reload. In order to ensure that new sets are created, only consider
"reload_set" if the set exists. If a set (from configuration) does not
exist, we always want to create it.

* On reload and before "fw3_destroy_ipsets()" are called, we need to
update run_state to ensure that sets are updated correctly. We need to
check if the sets in run_state is found in cfg_state, if not the set
should be destroyed (done by forcing reload_set to true). If the set is
found, then we copy the value of reload_set to the set in run_state so
that the elements are updated as the user expects.

Since we now always copy the value of reload_set from cfg_state, there
is no need to write reload_set to run_state.

Signed-off-by: Kristian Evensen 
---
 ipsets.c | 47 +--
 ipsets.h |  4 
 main.c   |  1 +
 utils.c  |  7 +--
 4 files changed, 55 insertions(+), 4 deletions(-)

diff --git a/ipsets.c b/ipsets.c
index 93bde0d..280845b 100644
--- a/ipsets.c
+++ b/ipsets.c
@@ -427,13 +427,16 @@ fw3_create_ipsets(struct fw3_state *state, enum 
fw3_family family,
/* spawn ipsets */
list_for_each_entry(ipset, >ipsets, list)
{
-   if (ipset->family != family ||
-   (reload_set && !ipset->reload_set))
+   if (ipset->family != family)
continue;
 
if (ipset->external)
continue;
 
+   if (fw3_check_ipset(ipset) &&
+   (reload_set && !ipset->reload_set))
+   continue;
+
if (!exec)
{
exec = fw3_command_pipe(false, "ipset", "-exist", "-");
@@ -568,3 +571,43 @@ out:
 
return rv;
 }
+
+void
+fw3_ipsets_update_run_state(enum fw3_family family, struct fw3_state 
*run_state,
+   struct fw3_state *cfg_state)
+{
+   struct fw3_ipset *ipset_run, *ipset_cfg;
+   bool in_cfg;
+
+   list_for_each_entry(ipset_run, _state->ipsets, list) {
+   if (ipset_run->family != family)
+   continue;
+
+   in_cfg = false;
+
+   list_for_each_entry(ipset_cfg, _state->ipsets, list) {
+   if (ipset_cfg->family != family)
+   continue;
+
+   if (strlen(ipset_run->name) ==
+   strlen(ipset_cfg->name) &&
+   !strcmp(ipset_run->name, ipset_cfg->name)) {
+   in_cfg = true;
+   break;
+   }
+   }
+
+   /* If a set is found in run_state, but not in cfg_state then the
+* set has been deleted/renamed. Set reload_set to true to force
+* the old set to be destroyed in the "stop" fase of the reload.
+* If the set is found, then copy the reload_set value from the
+* configuration state. This ensures that the elements are
+* always updated according to the configuration, and not the
+* runtime state (which the user might have forgotten).
+*/
+   if (!in_cfg)
+   ipset_run->reload_set = true;
+   else
+   ipset_run->reload_set = ipset_cfg->reload_set;
+   }
+}
diff --git a/ipsets.h b/ipsets.h
index fec79f8..76078d4 100644
--- a/ipsets.h
+++ b/ipsets.h
@@ -37,6 +37,10 @@ struct fw3_ipset * fw3_lookup_ipset(struct fw3_state *state, 
const char *name);
 
 bool fw3_check_ipset(struct fw3_ipset *set);
 
+void
+fw3_ipsets_update_run_state(enum fw3_family family, struct fw3_state 
*run_state,
+   struct fw3_state *cfg_state);
+
 static inline void fw3_free_ipset(struct fw3_ipset *ipse

[OpenWrt-Devel] [PATCH] nftables: Update nftables & clean up dependencies

[Kristian Evensen]

This patch does three things:

* Bumps nftables from 0.9.0 to 0.9.1 and remove a patch that was
accepted upstream.
* Cleans up the nftables-dependencies in netfilter.mk. All targets are
not at 4.14+, so there is no need to specify for example "ge 4.9.0" or
keep "lt 4.9.0" around.
* Fix building support for nftables sets. In 4.18 the configuration
symbol changed from CONFIG_NFT_SET_RBTREE and CONFIG_NFT_SET_HAS, to
CONFIG_NF_TABLES_SET.

Signed-off-by: Kristian Evensen 
---
 include/netfilter.mk  | 17 ++-
 package/network/utils/nftables/Makefile   |  4 +--
 .../nftables/patches/010-uclibc-ng.patch  | 28 ---
 3 files changed, 10 insertions(+), 39 deletions(-)
 delete mode 100644 package/network/utils/nftables/patches/010-uclibc-ng.patch

diff --git a/include/netfilter.mk b/include/netfilter.mk
index 179d4ed7b9..0ba9c10dca 100644
--- a/include/netfilter.mk
+++ b/include/netfilter.mk
@@ -337,12 +337,11 @@ $(eval $(if $(NF_KMOD),$(call 
nf_add,NFT_CORE,CONFIG_NF_TABLES, $(P_XT)nf_tables
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NF_TABLES_INET, 
$(P_XT)nf_tables_inet, lt 4.17),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_EXTHDR, 
$(P_XT)nft_exthdr),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_META, 
$(P_XT)nft_meta),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_NUMGEN, 
$(P_XT)nft_numgen, ge 4.9.0),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_NUMGEN, 
$(P_XT)nft_numgen),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_CT, $(P_XT)nft_ct),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_SET_RBTREE, 
$(P_XT)nft_set_rbtree, ge 4.9.0),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_RBTREE, 
$(P_XT)nft_rbtree, lt 4.9.0),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_SET_HASH, 
$(P_XT)nft_set_hash, ge 4.9.0),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_HASH, 
$(P_XT)nft_hash, lt 4.9.0),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_SET_RBTREE, 
$(P_XT)nft_set_rbtree, le 4.17.0),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_SET_HASH, 
$(P_XT)nft_set_hash, le 4.17.0),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NF_TABLES_SET, 
$(P_XT)nf_tables_set, gt 4.17),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_COUNTER, 
$(P_XT)nft_counter),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_LOG, 
$(P_XT)nft_log),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_LIMIT, 
$(P_XT)nft_limit),))
@@ -352,8 +351,8 @@ $(eval $(if $(NF_KMOD),$(call 
nf_add,NFT_CORE,CONFIG_NF_TABLES_IPV4, $(P_V4)nf_t
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_CHAIN_ROUTE_IPV4, 
$(P_V4)nft_chain_route_ipv4),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NF_TABLES_IPV6, 
$(P_V6)nf_tables_ipv6, lt 4.17),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_CHAIN_ROUTE_IPV6, 
$(P_V6)nft_chain_route_ipv6),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_REDIR, 
$(P_XT)nft_redir, ge 3.19.0),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_QUOTA, 
$(P_XT)nft_quota, ge 4.9.0),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_REDIR, 
$(P_XT)nft_redir),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_CORE,CONFIG_NFT_QUOTA, 
$(P_XT)nft_quota),))
 
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_ARP,CONFIG_NF_TABLES_ARP, 
$(P_V4)nf_tables_arp, lt 4.17),))
 
@@ -363,11 +362,11 @@ $(eval $(if $(NF_KMOD),$(call 
nf_add,NFT_BRIDGE,CONFIG_NFT_BRIDGE_REJECT, $(P_EB
 
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_NAT, $(P_XT)nft_nat),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_CHAIN_NAT_IPV4, 
$(P_V4)nft_chain_nat_ipv4),))
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_REDIR_IPV4, 
$(P_V4)nft_redir_ipv4, ge 3.19.0),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_REDIR_IPV4, 
$(P_V4)nft_redir_ipv4),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_MASQ, 
$(P_XT)nft_masq),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT,CONFIG_NFT_MASQ_IPV4, 
$(P_V4)nft_masq_ipv4),))
 
-$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT6,CONFIG_NFT_REDIR_IPV6, 
$(P_V6)nft_redir_ipv6, ge 3.19.0),))
+$(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT6,CONFIG_NFT_REDIR_IPV6, 
$(P_V6)nft_redir_ipv6),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT6,CONFIG_NFT_CHAIN_NAT_IPV6, 
$(P_V6)nft_chain_nat_ipv6),))
 $(eval $(if $(NF_KMOD),$(call nf_add,NFT_NAT6,CONFIG_NFT_MASQ_IPV6, 
$(P_V6)nft_masq_ipv6),))
 
diff --git a/package/network/utils/nftables/Makefile 
b/package/network/utils/nftables/Makefile
index d4f91a2c89..0ffb2adc01 100644
--- a/package/network/utils/nftables/Makefile
+++ b/package/network/utils/nftables/Makefile
@@ -7,12 +7,12 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=nftables
-PKG_VERSION:=0.9.0
+PKG_VERSION:=0.9.1
 PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
 P

Re: [OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files

[Kristian Evensen]

Hi,

On Wed, Jul 3, 2019 at 9:55 AM Rafał Miłecki  wrote:
> Why you didn't cc Alex, so he can ack your relicensing? You also
> didn't care to let us know we need his ack!

While I don't appreciate your tone, I see now that I made a mistake.
When checking the history of the files that I relicense, there are
three more people that should be added to the CC-list (INAGAKI
Hiroshi, Mathias Kresin and Petr Štetiar). I have done so now, thanks
for spotting this and the mistake was of course not intentional.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH 2/2] ramips: Add support for ZBT WE1026-H

[Kristian Evensen]

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 
---
 .../ramips/base-files/etc/board.d/01_leds |  5 +++
 .../ramips/base-files/etc/board.d/02_network  |  3 +-
 target/linux/ramips/dts/WE1026-H-32M.dts  | 14 +++
 target/linux/ramips/dts/WE1026-H.dtsi | 41 +++
 target/linux/ramips/image/mt7620.mk   |  9 
 5 files changed, 71 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/WE1026-H-32M.dts
 create mode 100644 target/linux/ramips/dts/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 043b814773..e44e0cb973 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -439,6 +439,11 @@ zbt-we826-16M|\
 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 52204eacbf..9e953b4ef0 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -427,7 +427,8 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "5@eth0"
;;
-   wcr-1166ds)
+   wcr-1166ds|\
+   zbtlink,we1026-h-32m)
ucidef_add_switch "switch0" \
"3:lan" "4:wan" "6@eth0"
;;
diff --git a/target/linux/ramips/dts/WE1026-H-32M.dts 
b/target/linux/ramips/dts/WE1026-H-32M.dts
new file mode 100644
index 00..ba96b03355
--- /dev/null
+++ b/target/linux/ramips/dts/WE1026-H-32M.dts
@@ -0,0 +1,14 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "WE1026-H.dtsi"
+
+/ {
+   compatible = "zbtlink,we1026-h-32m", "zbtlink,we1026-h",
+"zbtlink,we1026","ralink,mt7620a-soc";
+   model = "ZBT WE1026-H (32M)";
+};
+
+ {
+   reg = <0x5 0x1fb>;
+};
diff --git a/target/linux/ramips/dts/WE1026-H.dtsi 
b/target/linux/ramips/dts/WE1026-H.dtsi
new file mode 100644
index 00..3c6a2f99dc
--- /dev/null
+++ b/target/linux/ramips/dts/WE1026-H.dtsi
@@ -0,0 +1,41 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "WE1026.dtsi"
+
+/ {
+   compatible = "zbtlink,we1026-h", "zbtlink,we1026",
+"ralink,mt7620a-soc";
+
+   aliases {
+   led-boot = _power;
+   led-failsafe = _power;
+   led-running = _power;
+   led-upgrade = _power;
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   led_power: usb {
+   label = &qu

[OpenWrt-Devel] [PATCH 1/2] ramips: Update ZBT WE1026 DTS-files

[Kristian Evensen]

This commit makes the following changes to the WE1026 DTS-files:

* The parts that are unique to the -5G-version (LED and 5GHz wifi)
are moved to a separate file, so that WE1026.dtsi can be referenced also
by the DTS for the -H version.
* Changed button from polled to interrupt.
* Use the generic "flash"-name for the spi-nor node.

All changes have been tested on the WE1026-5G-16M and work fine. I.e.,
the device works as before the DTS-changes.

Signed-off-by: Kristian Evensen 
---
 target/linux/ramips/dts/WE1026-5G-16M.dts |  77 ++---
 target/linux/ramips/dts/WE1026-5G.dtsi|  93 ++--
 target/linux/ramips/dts/WE1026.dtsi   | 101 ++
 3 files changed, 112 insertions(+), 159 deletions(-)
 create mode 100644 target/linux/ramips/dts/WE1026.dtsi

diff --git a/target/linux/ramips/dts/WE1026-5G-16M.dts 
b/target/linux/ramips/dts/WE1026-5G-16M.dts
index 8954006ece..df31a723c5 100644
--- a/target/linux/ramips/dts/WE1026-5G-16M.dts
+++ b/target/linux/ramips/dts/WE1026-5G-16M.dts
@@ -1,81 +1,16 @@
-/*
- *  BSD LICENSE
- *
- *  Copyright(c) 2017 Kristian Evensen .
- *  All rights reserved.
- *
- *  Redistribution and use in source and binary forms, with or without
- *  modification, are permitted provided that the following conditions
- *  are met:
- *
- ** Redistributions of source code must retain the above copyright
- *  notice, this list of conditions and the following disclaimer.
- ** Redistributions in binary form must reproduce the above copyright
- *  notice, this list of conditions and the following disclaimer in
- *  the documentation and/or other materials provided with the
- *  distribution.
- ** Neither the name of Broadcom Corporation nor the names of its
- *  contributors may be used to endorse or promote products derived
- *  from this software without specific prior written permission.
- *
- *  THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
- *  "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
- *  LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
- *  A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
- *  OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
- *  SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
- *  LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
- *  DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
- *  THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
- *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
- *  OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- */
-
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
 /dts-v1/;
 
 #include "WE1026-5G.dtsi"
 
 / {
-   compatible = "zbtlink,we1026-5g-16m", "ralink,mt7620a-soc";
+   compatible = "zbtlink,we1026-5g-16m", "zbtlink,we1026-5g",
+"zbtlink,we1026", "ralink,mt7620a-soc";
model = "ZBT WE1026-5G (16M)";
 };
 
- {
-   status = "okay";
-
-   en25q128@0 {
-   compatible = "jedec,spi-nor";
-   reg = <0>;
-   spi-max-frequency = <1000>;
-
-   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;
-   };
-
-   factory: partition@4 {
-   label = "factory";
-   reg = <0x4 0x1>;
-   read-only;
-   };
-
-   firmware: partition@5 {
-   compatible = "denx,uimage";
-   label = "firmware";
-   reg = <0x5 0xfb>;
-   };
-   };
-   };
+ {
+   reg = <0x5 0xfb>;
 };
+
diff --git a/target/linux/ramips/dts/WE1026-5G.dtsi 
b/target/linux/ramips/dts/WE1026-5G.dtsi
index e7e64e251a..d1a8471893 100644
--- a/target/linux/ramips/dts/WE1026-5G.dtsi
+++ b/target/linux/ramips/dts/WE1026-5G.dtsi
@@ -1,47 +1,11 @@
-/*
- *  BSD LICENSE
- *
- *  Copyright(c) 2017 Kristian Evensen .
- *  All rights reserved.
- *

[OpenWrt-Devel] [PATCH 0/2] Add support for the ZBT WE1026-H

[Kristian Evensen]

This patch series adds support for the ZBT WE1026-H, an outdoor AP with support
for adding an internal LTE modem. The first patch restructures the DTS files for
the WE0126-5G slightly and adds a WE1026 DTSI-file, containing descriptions of
the components that are shared between the WE0126-5G and the WE1026-H. The
second patch adds support for the WE1026-H.

Signed-off-by: Kristian Evensen 

Kristian Evensen (2):
  ramips: Update ZBT WE1026 DTS-files
  ramips: Add support for ZBT WE1026-H

 .../ramips/base-files/etc/board.d/01_leds |   5 +
 .../ramips/base-files/etc/board.d/02_network  |   3 +-
 target/linux/ramips/dts/WE1026-5G-16M.dts |  77 ++---
 target/linux/ramips/dts/WE1026-5G.dtsi|  93 +---
 target/linux/ramips/dts/WE1026-H-32M.dts  |  14 +++
 target/linux/ramips/dts/WE1026-H.dtsi |  41 +++
 target/linux/ramips/dts/WE1026.dtsi   | 101 ++
 target/linux/ramips/image/mt7620.mk   |   9 ++
 8 files changed, 183 insertions(+), 160 deletions(-)
 create mode 100644 target/linux/ramips/dts/WE1026-H-32M.dts
 create mode 100644 target/linux/ramips/dts/WE1026-H.dtsi
 create mode 100644 target/linux/ramips/dts/WE1026.dtsi

-- 
2.20.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

[Kristian Evensen]

Hi,

On Sun, Jun 9, 2019 at 10:06 AM Christian Lamparter  wrote:
> @ynezz, @Kristian
>
> The APM821xx checks out with both as well. While there are spurious
> events on enabling the interrupt (one released event),
> the /etc/rc.button/ scripts are setup to handle that. So, which patch
> should we take and who gets the merge them? (I've seen that ynezz has
> more patches as well.)

I am unfortunately not familiar enough with the code in question to
have an opinion on which patch is the most correct or the best way for
going forward. I will let you two decide on which patch to merge and
who gets the honor :)

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: Remove redundant LED-cases

[Kristian Evensen]

01_leds has several redundant LED-cases. This commit cleans
up the file by merging these cases into shared cases.

Signed-off-by: Kristian Evensen 
---
 .../ramips/base-files/etc/board.d/01_leds | 100 ++
 1 file changed, 32 insertions(+), 68 deletions(-)

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 1b02088ed2..35d046cc90 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -13,30 +13,29 @@ boardname="${board##*,}"
 board_config_update
 
 case $board in
-3g-6200n)
+3g-6200n|\
+br-6475nd|\
+mzk-w300nh2)
set_wifi_led "$boardname:amber:wlan"
;;
 3g-6200nl|\
+air3gii|\
 hilink,hlk-7628n|\
+mr-102n|\
 skylab,skw92a|\
-wnce2001)
+wnce2001|\
+zbt-we2026)
set_wifi_led "$boardname:green:wlan"
;;
-br-6475nd|\
-mzk-w300nh2)
-   set_wifi_led "$boardname:amber:wlan"
-   ;;
 ai-br100)
ucidef_set_led_netdev "wan" "wan" "$boardname:blue:wan" "eth0.2"
set_wifi_led "$boardname:blue:wlan"
;;
-air3gii)
-   set_wifi_led "$boardname:green:wlan"
-   ;;
 alfa-network,ac1200rm)
set_wifi_led "$boardname:green:wlan2g" "wlan1"
;;
-alfa-network,awusfree1)
+alfa-network,awusfree1|\
+edimax,br-6478ac-v2)
set_wifi_led "$boardname:blue:wlan"
;;
 alfa-network,tube-e4g)
@@ -96,37 +95,47 @@ cudy,wr1000)
ucidef_set_led_switch "lan1" "lan1" "$boardname:blue:lan1" "switch0" 
"0x08"
ucidef_set_led_switch "lan2" "lan2" "$boardname:blue:lan2" "switch0" 
"0x04"
;;
-d240)
+d240|\
+mlw221|\
+mlwg2|\
+rakwireless,rak633|\
+rt-ac51u)
set_wifi_led "$boardname:blue:wifi"
;;
 dcs-930l-b1)
ucidef_set_led_netdev "wifi" "WiFi" "$boardname:blue:wps"
;;
 dir-300-b1|\
-dir-600-b1|\
-dir-620-a1)
-   set_wifi_led "rt2800pci-phy0::radio"
-   ;;
 dir-300-b7|\
 dir-320-b1|\
+dir-600-b1|\
 dir-610-a1|\
+dir-615-d|\
+dir-615-h1|\
+dir-620-a1|\
 esr-9753|\
 hlk-rm04|\
+kn|\
+nbg-419n2|\
 sl-r7205|\
 v11st-fe|\
 w306r-v20|\
+w502u|\
 wt1520-4M|\
-wt1520-8M)
-   set_wifi_led "rt2800pci-phy0::radio"
-   ;;
-dir-615-d|\
-dir-615-h1)
+wt1520-8M|\
+zyxel,keenetic-start)
set_wifi_led "rt2800pci-phy0::radio"
;;
 dir-620-d1|\
 dlink,dwr-116-a1|\
 head-weblink,hdrm200|\
-mzk-ex300np)
+kn_rc|\
+kn_rf|\
+kng_rc|\
+mzk-ex300np|\
+oy-0001|\
+tew-714tru|\
+zbt-wr8305rt)
set_wifi_led "$boardname:green:wifi"
;;
 dlink,dwr-118-a1)
@@ -149,9 +158,6 @@ dlink,dwr-922-e2)
 dir-860l-b1)
ucidef_set_led_netdev "wan" "wan" "$boardname:green:net" "eth0.2"
;;
-edimax,br-6478ac-v2)
-   set_wifi_led "$boardname:blue:wlan"
-   ;;
 ex2700|\
 wn3000rpv3)
set_wifi_led "$boardname:green:router"
@@ -163,7 +169,8 @@ ex3700)
 f5d8235-v1)
set_wifi_led "$boardname:blue:wireless"
;;
-fonera20n)
+fonera20n|\
+tiny-ac)
set_wifi_led "$boardname:orange:wifi"
;;
 gnubee,gb-pc1|\
@@ -212,15 +219,6 @@ kimax,u35wf)
set_wifi_led "$boardname:blue:wifi"
ucidef_set_led_netdev "eth" "ETH" "$boardname:green:eth" "eth0"
;;
-kn|\
-nbg-419n2)
-   set_wifi_led "rt2800pci-phy0::radio"
-   ;;
-kn_rc|\
-kn_rf|\
-kng_rc)
-   set_wifi_led "$boardname:green:wifi"
-   ;;
 lava,lr-25g001)
ucidef_set_led_netdev "wlan2g" "WiFi 2.4GHz" "$boardname:green:wlan2g" 
"wlan1"
ucidef_set_led_netdev "wlan5g" "WiFi 5GHz" "$boardname:green:wlan5g" 
"wlan0"
@@ -243,13 +241,6 @@ mikrotik,rbm11g)
 miniembplug)
set_wifi_led "$boardname:red:wlan"
;;
-mlw221|\
-mlwg2)
-   set_wifi_led "$boardname:blue:wifi"
-   ;;
-mr-102n)
-   set_wifi_led "$boardname:green:wlan"
-   ;;
 mr200)
ucidef_set_led_netdev "lan" "lan" "$boardname:white:lan" "eth0.1"
ucidef_set_led_netdev "wan" "wan" "$boardname:white:wan" "usb0"
@@ -267,9 +258,6 @@ netgear,r6120)
ucidef_set_led_switch "wan" "wan" "$boardname:green:wan" "switch0" 
"0x10"
ucidef_set_led_wlan "wlan2g" "WiFi 2.4GHz" "$boardname:green:wlan2g" 
"phy0tpt"
;;
-oy-0001)
-   set_wifi_led "$boardname:green:wifi&q

Re: [OpenWrt-Devel] [PATCH] gpio-button-hotplug: gpio-keys: fix always missing first event

[Kristian Evensen]

Hi Christian,

On Wed, Jun 5, 2019 at 10:23 PM Christian Lamparter  wrote:
> @Kristian Evensen, can you please check if the following patch would also
> resolve the issues you have been experiencing?
>
> I had to attach the patch as a file since gmail's webmail interface now seems 
> to
> eat all the tabs. I hope this still gets through.

Patch arrived safe and sound, and I just finished my tests on the
ZBT-WD323 (AR9344). I started out by building a fresh image from
master (head of my tree is commit 66d1c29655a4), and with this image I
saw the earlier reported behavior (a press of the button triggers
factory reset). I then applied your patch on top of my tree and the
button now works as expected. A short press triggers reboot, and
holding the button for ~5 seconds triggers a factory reset.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] ath79: Add support for ZBT-WD323

[Kristian Evensen]

ZBT-WD323 is a dual-LTE router based on AR9344. The detailed
specifications are:

* AR9344 560MHz/450MHz/225MHz (CPU/DDR/AHN).
* 128 MB RAM
* 16MB of flash(SPI-NOR, 22MHz)
* 1x 2.4GHz wifi (Atheros AR9340)
* 3x 10/100Mbos Ethernet (AR8229)
* 1x USB2.0 port
* 2x miniPCIe-slots (USB2.0 only)
* 2x SIM slots (standard size)
* 4x LEDs (1 gpio controlled)
* 1x reset button
* 1x 10 pin terminal block (RS232, RS485, 4x GPIO)
* 2x CP210x UART bridge controllers (used for RS232 and RS485)
* 1x 2 pin 5mm industrial interface (input voltage 12V~36V)
* 1x DC jack
* 1x RTC (PCF8563)

Tested:
- Ethernet switch
- Wifi
- USB port
- MiniPCIe-slots (+ SIM slots)
- Sysupgrade
- Reset button
- RS232

Intallation and recovery:

The board ships with OpenWRT, but sysupgrade does not work as a
different firmware format than what is expected is generated.  The
easiest way to install (and recover) the router, is to use the
web-interface provided by the bootloader (Breed).

While the interface is in Chinese, it is easy to use. First, in order to
access the interface, you need to hold down the reset button for around
five seconds. Then, go to 192.168.1.1 in your browser. Click on the
second item in the list on the left to access the recovery page. The
second item on the next page is where you select the firmware.  Select
the menu item containing "Atheros SDK" and "16MB" in the dropdown close
to the buttom, and click on the button at the bottom to start
installation/recovery.

Notes:
* RS232 is available on /dev/ttyUSB0 and RS485 on /dev/ttyUSB1

Signed-off-by: Kristian Evensen 
---
v1->v2:
* Added WLAN trigger to DTS (thanks Petr Štetiar).
* Fixed typo in compatible string (ar9334->ar9344, thanks Petr Štetiar).
* Removed a reundant alias (thanks Petr Štetiar).
* Changed compatible-value for keys (Petr Štetiar).
* Fixed LAN-port LEDs. I did not noticed that the LEDs did not work
peroply when I submitted v1.
---
 .../ath79/base-files/etc/board.d/01_leds  |   4 +
 .../ath79/base-files/etc/board.d/02_network   |   1 +
 .../base-files/etc/board.d/03_gpio_switches   |   6 +
 .../ath79/dts/ar9344_zbtlink_zbt-wd323.dts| 163 ++
 target/linux/ath79/image/generic.mk   |   9 +
 5 files changed, 183 insertions(+)
 create mode 100644 target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts

diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds 
b/target/linux/ath79/base-files/etc/board.d/01_leds
index 69e26a4773..a23f2e7c73 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -210,6 +210,10 @@ yuncore,a770)
ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth0"
ucidef_set_led_switch "lan" "LAN" "$boardname:green:lan" "switch0" 
"0x10"
;;
+zbtlink,zbt-wd323)
+   ucidef_set_led_switch "lan1" "LAN1" "zbt-wd323:orange:lan1" "switch0" 
"0x10"
+   ucidef_set_led_switch "lan2" "LAN2" "zbt-wd323:orange:lan2" "switch0" 
"0x08"
+   ;;
 esac
 
 board_config_flush
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 c2e994530d..200782812b 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -258,6 +258,7 @@ ath79_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth0" "5:lan" "1:wan"
;;
+   zbtlink,zbt-wd323|\
xiaomi,mi-router-4q)
ucidef_set_interface_wan "eth0"
ucidef_add_switch "switch0" \
diff --git a/target/linux/ath79/base-files/etc/board.d/03_gpio_switches 
b/target/linux/ath79/base-files/etc/board.d/03_gpio_switches
index 6a51a79790..1c8a46df19 100755
--- a/target/linux/ath79/base-files/etc/board.d/03_gpio_switches
+++ b/target/linux/ath79/base-files/etc/board.d/03_gpio_switches
@@ -29,6 +29,12 @@ ubnt,nanostation-ac)
 ubnt,acb-isp)
ucidef_add_gpio_switch "poe_passthrough" "PoE Passthrough" "11"
;;
+zbtlink,zbt-wd323)
+   ucidef_add_gpio_switch "io0" "IO#0" "0"
+   ucidef_add_gpio_switch "io1" "IO#1" "1"
+   ucidef_add_gpio_switch "io2" "IO#2" "2"
+   ucidef_add_gpio_switch "io14" "IO#14" "14"
+   ;;
 esac
 
 board_config_flush
diff --git a/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts 
b/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts
new file mode 100644
index 00..6a7259a2fc
--- /dev/null
+++ b/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts
@@ -0,0 +1,163 

[OpenWrt-Devel] [PATCH] ath79: Add support for ZBT-WD323

[Kristian Evensen]

ZBT-WD323 is a dual-LTE router based on AR9344. The detailed
specifications are:

* AR9344 560MHz/450MHz/225MHz (CPU/DDR/AHN).
* 128 MB RAM
* 16MB of flash(SPI-NOR, 22MHz)
* 1x 2.4GHz wifi (Atheros AR9340)
* 3x 10/100Mbos Ethernet (AR8229)
* 1x USB2.0 port
* 2x miniPCIe-slots (USB2.0 only)
* 2x SIM slots (standard size)
* 4x LEDs (1 gpio controlled)
* 1x reset button
* 1x 10 pin terminal block (RS232, RS485, 4x GPIO)
* 2x CP210x UART bridge controllers (used for RS232 and RS485)
* 1x 2 pin 5mm industrial interface (input voltage 12V~36V)
* 1x DC jack
* 1x RTC (PCF8563)

Tested:
- Ethernet switch
- Wifi
- USB port
- MiniPCIe-slots (+ SIM slots)
- Sysupgrade
- Reset button
- RS232

Intallation and recovery:

The board ships with OpenWRT, but sysupgrade does not work as a
different firmware format than what is expected is generated.  The
easiest way to install (and recover) the router, is to use the
web-interface provided by the bootloader (Breed).

While the interface is in Chinese, it is easy to use. First, in order to
access the interface, you need to hold down the reset button for around
five seconds. Then, go to 192.168.1.1 in your browser. Click on the
second item in the list on the left to access the recovery page. The
second item on the next page is where you select the firmware.  Select
the menu item containing "Atheros SDK" and "16MB" in the dropdown close
to the buttom, and click on the button at the bottom to start
installation/recovery.

Notes:
* RS232 is available on /dev/ttyUSB0 and RS485 on /dev/ttyUSB1

Signed-off-by: Kristian Evensen 
---
 .../ath79/base-files/etc/board.d/01_leds  |   3 +
 .../ath79/base-files/etc/board.d/02_network   |   1 +
 .../base-files/etc/board.d/03_gpio_switches   |   6 +
 .../ath79/dts/ar9344_zbtlink_zbt-wd323.dts| 148 ++
 target/linux/ath79/image/generic.mk   |   9 ++
 5 files changed, 167 insertions(+)
 create mode 100644 target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts

diff --git a/target/linux/ath79/base-files/etc/board.d/01_leds 
b/target/linux/ath79/base-files/etc/board.d/01_leds
index 69e26a4773..48a5f2394b 100755
--- a/target/linux/ath79/base-files/etc/board.d/01_leds
+++ b/target/linux/ath79/base-files/etc/board.d/01_leds
@@ -210,6 +210,9 @@ yuncore,a770)
ucidef_set_led_netdev "wan" "WAN" "$boardname:green:wan" "eth0"
ucidef_set_led_switch "lan" "LAN" "$boardname:green:lan" "switch0" 
"0x10"
;;
+zbtlink,zbt-wd323)
+   ucidef_set_led_wlan "wlan" "WLAN" "$boardname:green:wifi" "phy0tpt"
+   ;;
 esac
 
 board_config_flush
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 7b89274ccf..df32e58baf 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -257,6 +257,7 @@ ath79_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth0" "5:lan" "1:wan"
;;
+   zbtlink,zbt-wd323|\
xiaomi,mi-router-4q)
ucidef_set_interface_wan "eth0"
ucidef_add_switch "switch0" \
diff --git a/target/linux/ath79/base-files/etc/board.d/03_gpio_switches 
b/target/linux/ath79/base-files/etc/board.d/03_gpio_switches
index 6a51a79790..1c8a46df19 100755
--- a/target/linux/ath79/base-files/etc/board.d/03_gpio_switches
+++ b/target/linux/ath79/base-files/etc/board.d/03_gpio_switches
@@ -29,6 +29,12 @@ ubnt,nanostation-ac)
 ubnt,acb-isp)
ucidef_add_gpio_switch "poe_passthrough" "PoE Passthrough" "11"
;;
+zbtlink,zbt-wd323)
+   ucidef_add_gpio_switch "io0" "IO#0" "0"
+   ucidef_add_gpio_switch "io1" "IO#1" "1"
+   ucidef_add_gpio_switch "io2" "IO#2" "2"
+   ucidef_add_gpio_switch "io14" "IO#14" "14"
+   ;;
 esac
 
 board_config_flush
diff --git a/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts 
b/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts
new file mode 100644
index 00..df67783952
--- /dev/null
+++ b/target/linux/ath79/dts/ar9344_zbtlink_zbt-wd323.dts
@@ -0,0 +1,148 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include 
+#include 
+
+#include "ar9344.dtsi"
+
+/ {
+   model = "ZBT WD323";
+   compatible = "zbtlink,zbt-wd323", "qca,ar9334";
+
+   aliases {
+   serial0 = 
+   };
+
+   keys {
+   compatible = "gpio-keys-polled";
+   poll-interval = <20>;
+
+   reset {
+   label = "reset";
+   

[OpenWrt-Devel] [PATCH v3] ramips: Add support for ZBT WE826-E

[Kristian Evensen]

ZBT WE826-E is a dual-SIM version of the ZBT WE826. The router has the
following specifications:

- MT7620A (580 MHz)
- 128MB RAM
- 32MB of flash (SPI NOR)
- 5x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM card slots (standard size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 10x LEDs (4 GPIO-controlled)
- 1x reset button

The following have been tested and working:
- Ethernet switch
- wifi
- miniPCIe slot
- USB port
- microSD slot
- sysupgrade
- reset button

Installation and recovery:

In order to install OpenWRT the first time or 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.

How to swap SIMs:

You control which SIM slot to use by writing 0/1 to
/sys/class/gpio/gpio13/value. In order for the change to take effect,
you can either use AT-commands (AT+CFUN) or power-cycle the modem (write
0/1 to /sys/class/gpio/gpio14/value).

Signed-off-by: Kristian Evensen 
---
v2->v3:
* Remove the old description of the first time installation and point
the user to the web based recovery system instead (thanks Petr Štetiar).
* Add license to DTS (thanks Petr Štetiar).

v1->v2:
* Use generic board/model detection, updated the match in 01_leds and
02_network (thanks Petr Štetiar).
* Changed the device/target device in the Makefile to match the
compatible-string in the DTS (thanks Petr Štetiar).
* Use the user-space gpio-switch alternative instead of gpio-export in
the DTS (thanks Petr Štetiar).
* Update name of flash node in DTS to the more generic "flash0" (thanks
Petr Štetiar).
* Fix image size in the Makefile (thanks Petr Štetiar).
* Group the wifi-LED together with other devices (thanks Petr Štetiar).
* Updated commit message.
* While the device can be ordered without a modem, I imagine most
devices will be delivered with a modem. I have therefore enabled support
for QMI and Option, so that most modems can be used out of the box.
---
 .../ramips/base-files/etc/board.d/01_leds |  3 +-
 .../ramips/base-files/etc/board.d/02_network  |  1 +
 .../base-files/etc/board.d/03_gpio_switches   |  4 +
 target/linux/ramips/dts/ZBT-WE826-E.dts   | 84 +++
 target/linux/ramips/image/mt7620.mk   |  9 ++
 5 files changed, 100 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/ZBT-WE826-E.dts

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 fa20ab0714..941b4b109b 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -251,7 +251,8 @@ mr200)
 mtc,wr1201)
ucidef_set_led_switch "eth_link" "LAN link" "$boardname:green:eth_link" 
"switch0" "0x0f"
;;
-mzk-ex750np)
+mzk-ex750np|\
+zbtlink,zbt-we826-e)
set_wifi_led "$boardname:red:wifi"
;;
 netgear,r6120)
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 c2646876a2..63bfab2486 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -133,6 +133,7 @@ ramips_setup_interfaces()
youku,yk-l2|\
zbt-ape522ii|\
zbt-we1326|\
+   zbtlink,zbt-we826-e|\
zbtlink,zbt-we3526|\
zbt-we826-16M|\
zbt-we826-32M|\
diff --git a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches 
b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
index 80e3c4c41f..6119d7c485 100755
--- a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
+++ b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
@@ -24,6 +24,10 @@ ubnt-erx-sfp)
ucidef_add_gpio_switch "poe_power_port3" "PoE Power Port3" "499"
ucidef_add_gpio_switch "poe_power_port4" "PoE Power Port4" "500"
;;
+zbtlink,zbt-we826-e)
+   ucidef_add_gpio_switch "sim_switch" "SIM slot switch" "13"
+   ucidef_add_gpio_switch "power_mpcie" "mPCIe power" "14" "1"
+   ;;
 esac
 
 board_config_flush
diff --git a/target/linux/ramips/dts/ZBT-WE826-E.dts 
b/target/linux/ramips/dts/ZBT-WE826-E.dts
new file mode 100644
index 00..ce97b03715
--- /dev/null
+++ b/target/linux/ramips/dts/ZBT-WE826-E.dts
@@ -0,0 +1,84 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "ZBT-WE826.dtsi"
+
+/ {
+   compatible = "zbtlink,zbt-we826-e", "zbtlink,zbt-we826", 
"ralink,mt7620a-soc";
+   model = "ZBT-WE826-E";
+
+   /delete-node/ leds;
+
+   leds {
+

Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for ZBT WE826-E

[Kristian Evensen]

Hi,

On Thu, May 16, 2019 at 3:17 PM Petr Štetiar  wrote:
> it's not mandatory, so you're not obliged to do so, but it makes me wonder if
> it would be possible to generate factory image which could be flashed with the
> same recovery mechanism, thus avoiding the -F in the sysupgrade above
> (considered dangerous).

If my memory serves me right, then it is possible to use the
sysupgrade-images with the recovery mechanism. I will test again and
then update the commit message if so.

>
> > +++ b/target/linux/ramips/dts/ZBT-WE826-E.dts
> > @@ -0,0 +1,83 @@
> > +/dts-v1/;
>
> Please can you consider adding `SPDX-License-Identifier: GPL-2.0-or-later OR
> MIT` ?

And I thought I had remembered to incorporate all the comments from
adding the HDRM200  :)

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] ramips: Add support for ZBT WE826-E

[Kristian Evensen]

ZBT WE826-E is a dual-SIM version of the ZBT WE826. The router has the
following specifications:

- MT7620A (580 MHz)
- 128MB RAM
- 32MB of flash (SPI NOR)
- 5x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM card slots (standard size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 10x LEDs (4 GPIO-controlled)
- 1x reset button

The following have been tested and working:
- Ethernet switch
- wifi
- miniPCIe slot
- USB port
- microSD slot
- sysupgrade
- reset button

Installation:

The router ships with an older version of OpenWRT, but with a broken web
user interface. In order to install the image, you need to SSH into the
router and run sysupgrade. The default address of the router is
192.168.1.1, user is root and password admin. Once you are in, run the
following command:

sysupgrade -n -F
openwrt-ramips-mt7620-zbtlink_zbt-we826-e-squashfs-sysupgrade.bin

Recovery:

The router ships with a web-based recovery system. If you need to
recover the router, 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.

How to swap SIMs:

You control which SIM slot to use by writing 0/1 to
/sys/class/gpio/gpio13/value. In order for the change to take effect,
you can either use AT-commands (AT+CFUN) or power-cycle the modem (write
0/1 to /sys/class/gpio/gpio14/value).

Signed-off-by: Kristian Evensen 
---
v1->v2:
* Use generic board/model detection, updated the match in 01_leds and
02_network (thanks Petr Štetiar).
* Changed the device/target device in the Makefile to match the
compatible-string in the DTS (thanks Petr Štetiar).
* Use the user-space gpio-switch alternative instead of gpio-export in
the DTS (thanks Petr Štetiar).
* Update name of flash node in DTS to the more generic "flash0" (thanks
Petr Štetiar).
* Fix image size in the Makefile (thanks Petr Štetiar).
* Group the wifi-LED together with other devices (thanks Petr Štetiar).
* Updated commit message.
* While the device can be ordered without a modem, I imagine most
devices will be delivered with a modem. I have therefore enabled support
for QMI and Option, so that most modems can be used out of the box.
---
 .../ramips/base-files/etc/board.d/01_leds |  3 +-
 .../ramips/base-files/etc/board.d/02_network  |  1 +
 .../base-files/etc/board.d/03_gpio_switches   |  4 +
 target/linux/ramips/dts/ZBT-WE826-E.dts   | 83 +++
 target/linux/ramips/image/mt7620.mk   |  9 ++
 5 files changed, 99 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/ZBT-WE826-E.dts

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 fa20ab0714..941b4b109b 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -251,7 +251,8 @@ mr200)
 mtc,wr1201)
ucidef_set_led_switch "eth_link" "LAN link" "$boardname:green:eth_link" 
"switch0" "0x0f"
;;
-mzk-ex750np)
+mzk-ex750np|\
+zbtlink,zbt-we826-e)
set_wifi_led "$boardname:red:wifi"
;;
 netgear,r6120)
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 c2646876a2..63bfab2486 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -133,6 +133,7 @@ ramips_setup_interfaces()
youku,yk-l2|\
zbt-ape522ii|\
zbt-we1326|\
+   zbtlink,zbt-we826-e|\
zbtlink,zbt-we3526|\
zbt-we826-16M|\
zbt-we826-32M|\
diff --git a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches 
b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
index 80e3c4c41f..6119d7c485 100755
--- a/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
+++ b/target/linux/ramips/base-files/etc/board.d/03_gpio_switches
@@ -24,6 +24,10 @@ ubnt-erx-sfp)
ucidef_add_gpio_switch "poe_power_port3" "PoE Power Port3" "499"
ucidef_add_gpio_switch "poe_power_port4" "PoE Power Port4" "500"
;;
+zbtlink,zbt-we826-e)
+   ucidef_add_gpio_switch "sim_switch" "SIM slot switch" "13"
+   ucidef_add_gpio_switch "power_mpcie" "mPCIe power" "14" "1"
+   ;;
 esac
 
 board_config_flush
diff --git a/target/linux/ramips/dts/ZBT-WE826-E.dts 
b/target/linux/ramips/dts/ZBT-WE826-E.dts
new file mode 100644
index 00..a1f71c7144
--- /dev/null
+++ b/target/linux/ramips/dts/ZBT-WE826-E.dts
@@ -0,0 +1,83 @@
+/dts-v1/;
+
+#include "ZBT-WE826.dtsi"
+
+/ {
+   compatible = "zbtlink,zbt-we826-e", "zbtlink,zbt-we826"

Re: [OpenWrt-Devel] [PATCH v4] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Hi,

On Wed, May 15, 2019 at 9:21 PM Petr Štetiar  wrote:
> Thanks, I've merged it into my staging tree[1], but I had to fix one merge
> conflict in target.mk so please check it if I did it properly.

Thanks and strange about the conflict + whitespace, as patch applies
cleanly to master and checkpatch does not complain. Anyway, target.mk
in your staging dir looks good to me.

I will proceed with updating the patch for the ZBT-device I created a
PR for, based on the work done to get support for the HDRM200 merged.

Thanks again,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] system: uci: Use config dir on uci_add and support add_/del_list

[Kristian Evensen]

This commit makes three changes to the uci shell library:

* A check for UCI_CONFIG_DIR has been added to the command line when
adding anonymous sections. Without this change, adding anonymous
sections to configs not stored in /etc/config is not possible.

* Support for adding/removing items from lists were missing, so I have
added the functions uci_add_list() and uci_remove_list() to simplify
working with uci lists from scripts.

Signed-off-by; Kristian Evensen 

---
v1->v2:
* Rename uci_del_list() to uci_remove_list() in order to be consistent
with uci_remove() (thanks Petr Štetiar).
---
 package/system/uci/files/lib/config/uci.sh | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/package/system/uci/files/lib/config/uci.sh 
b/package/system/uci/files/lib/config/uci.sh
index 78ec277669..1e85ced834 100644
--- a/package/system/uci/files/lib/config/uci.sh
+++ b/package/system/uci/files/lib/config/uci.sh
@@ -85,6 +85,15 @@ uci_set() {
/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} set 
"$PACKAGE.$CONFIG.$OPTION=$VALUE"
 }
 
+uci_add_list() {
+   local PACKAGE="$1"
+   local CONFIG="$2"
+   local OPTION="$3"
+   local VALUE="$4"
+
+   /sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} add_list 
"$PACKAGE.$CONFIG.$OPTION=$VALUE"
+}
+
 uci_get_state() {
uci_get "$1" "$2" "$3" "$4" "/var/state"
 }
@@ -108,7 +117,7 @@ uci_add() {
local CONFIG="$3"
 
if [ -z "$CONFIG" ]; then
-   export ${NO_EXPORT:+-n} CONFIG_SECTION="$(/sbin/uci add 
"$PACKAGE" "$TYPE")"
+   export ${NO_EXPORT:+-n} CONFIG_SECTION="$(/sbin/uci 
${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} add "$PACKAGE" "$TYPE")"
else
/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} set 
"$PACKAGE.$CONFIG=$TYPE"
export ${NO_EXPORT:+-n} CONFIG_SECTION="$CONFIG"
@@ -132,6 +141,15 @@ uci_remove() {
/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} del 
"$PACKAGE.$CONFIG${OPTION:+.$OPTION}"
 }
 
+uci_remove_list() {
+   local PACKAGE="$1"
+   local CONFIG="$2"
+   local OPTION="$3"
+   local VALUE="$4"
+
+   /sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} del_list 
"$PACKAGE.$CONFIG.$OPTION=$VALUE"
+}
+
 uci_commit() {
local PACKAGE="$1"
/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} commit $PACKAGE
-- 
2.19.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v4] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Head Weblink HDRM200 is a dual-sim router based on MT7620A. The detailed
specifications are:

- MT7620A (580MHz)
- 64MB RAM
- 16MB of flash (SPI NOR)
- 6x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus). Device is shipped with a SIMCOM
SIM7100E LTE modem.
- 2x SIM slots (standard size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 1x 5GHz wifi (mt7612)
- 1x reset button
- 1x WPS button
- 3x GPIO-controllable LEDs
- 1x 10 pin terminal block (RS232, RS485, 4 x GPIO)

Tested:
- Ethernet switch
- Wifi
- USB slot
- SD card slot
- miniPCIe-slot
- sysupgrade
- reset button

Installation instructions:

Installing OpenWRT for the first time requires a bit of work, as the
board does not ship with OpenWRT. In addition, the bootloader
automatically reboots when installing an image over tftp. In order to
install OpenWRT on the HDRM200, you need to do the following:

* Copy the initramfs-image to your tftp-root (default filename is
test.bin) and configure networking accordingly (default server IP is
10.10.10.3, client 10.10.10.123). Start your tftp server.
* Open the board and connect to UART. The pins are exposed and clearly
marked.
* Boot the board and press 1.
* Either use the default filename and client/server IP-addresses, or
specify your own.

The image should now be loaded to memory and board boot. If the router
reboots while the image is loading, you need to try again. Once the
board has booted, copy the sysupgrade-image to the router and run
sysupgrade in order to install OpenWRT to the flash.

Notes:

- You control which SIM slot to use by writing 0/1 to
/sys/class/gpio/sim_switch/value. In order for the change to take
effect, you can either use AT-commands (AT+CFUN) or power-cycle the
modem (write 0/1 to /sys/class/gpio/power_mpcie/value).
- RS485 is available on /dev/ttyS0.
- RS232 is available on /dev/ttyS1.
- The name of the ioX-gpios map to the labels on the casing.

Signed-off-by: Kristian Evensen 
---
v3->v4:
* Update commit. I had forgot to remove instructions to compile a
ramdisk. This now done automatically (thanks Petr Štetiar).
* Fix image size in the Makefile (thanks Petr Štetiar).
* Group the wifi-LED together with other devices. I see that there are
several lone cases with the same LED name, but in order to reduce the
changes made by this patch I have left them as-is (thanks Petr Štetiar).

v2->v3:
* Build initramfs automatically, which means that ramdisk is now enabled
the mt7620-target. Due to this change, an initramfs-image is built for all
deivces, but this seems to be ok when looking at other targets (mt7621)
(thanks Petr Štetiar).
* Use generic board/model detection, updated the match in 01_leds and
02_network (thanks Petr Štetiar).
* Changed the device/target device in the Makefile to match the
compatible-string in the DTS (thanks Petr Štetiar).
* Use the user-space gpio-switch alternative instead of gpio-export in
the DTS (thanks Petr Štetiar).
* Update name of flash node in DTS to the more generic "flash0" (thanks
Petr Štetiar)..
* Fix typo in commit message (mt7621->mt7612) (thanks Tom Psyborg).
* Added the QMI and option drivers, as well as uqmi, so that the modem
is available for use out of the box.

v1->v2:
* Add SPDX line to DTS (thanks Rafał Miłecki).
---
 .../ramips/base-files/etc/board.d/01_leds |   1 +
 .../ramips/base-files/etc/board.d/02_network  |   1 +
 .../base-files/etc/board.d/03_gpio_switches   |   8 +
 target/linux/ramips/dts/HDRM200.dts   | 188 ++
 target/linux/ramips/image/mt7620.mk   |   9 +
 target/linux/ramips/mt7620/target.mk  |   2 +-
 6 files changed, 208 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/HDRM200.dts

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 fa20ab0714..9d42720c60 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -119,6 +119,7 @@ dir-615-h1)
;;
 dir-620-d1|\
 dlink,dwr-116-a1|\
+head-weblink,hdrm200|\
 mzk-ex300np)
set_wifi_led "$boardname:green:wifi"
;;
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 c2646876a2..b0037a0ce2 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -314,6 +314,7 @@ ramips_setup_interfaces()
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "6@eth0"
;;
hc5661|\
+   head-weblink,hdrm200|\
y1s)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "5:lan" "0:wan" "6@eth0"
diff --git a/target/linux/rami

Re: [OpenWrt-Devel] [PATCH v3] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

On Wed, May 15, 2019 at 12:42 PM Petr Štetiar  wrote:
> Yes, you're correct, I've missed this userspace GPIOs.

Thanks for confirming. I will submit a v4 during the afternoon.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v3] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Hi Petr,

Thanks for your feedback.

On Wed, May 15, 2019 at 12:17 PM Petr Štetiar  wrote:
> > In order to install OpenWRT, you first need to compile an initramfs
> > (ramdisk)-image for the device.
>
> This is no longer valid, right?

Correct, will remove it for v4.

>
> > --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> > +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> > @@ -184,6 +184,9 @@ hc5861)
> >   ucidef_set_led_netdev "wifi5g" "wifi5g" "$boardname:blue:wlan5g" 
> > "wlan0"
> >   ucidef_set_led_netdev "wifi2g" "wifi2g" "$boardname:blue:wlan2g" 
> > "wlan1"
> >   ;;
> > +head-weblink,hdrm200)
> > + set_wifi_led "$boardname:green:wifi"
> > + ;;
>
> this could be grouped with other devices.

Thanks for spotting this.

> so if I'm counting it right, you should probably remove i2c.

If I have understood the datasheet correctly, then i2c is required for
two of the GPIOs exported in 03_gpio_switches (io1/GPIO#1 and
io2/GPIO#2).

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v3] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Head Weblink HDRM200 is a dual-sim router based on MT7620A. The detailed
specifications are:

- MT7620A (580MHz)
- 64MB RAM
- 16MB of flash (SPI NOR)
- 6x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus). Device is shipped with a SIMCOM
SIM7100E LTE modem.
- 2x SIM slots (standard size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 1x 5GHz wifi (mt7612)
- 1x reset button
- 1x WPS button
- 3x GPIO-controllable LEDs
- 1x 10 pin terminal block (RS232, RS485, 4 x GPIO)

Tested:
- Ethernet switch
- Wifi
- USB slot
- SD card slot
- miniPCIe-slot
- sysupgrade
- reset button

Installation instructions:

Installing OpenWRT for the first time requires a bit of work, as the
board does not ship with OpenWRT. In addition, the bootloader
automatically reboots when installing an image over tftp.

In order to install OpenWRT, you first need to compile an initramfs
(ramdisk)-image for the device. Once the image is ready, you need to do
the following:

* Copy the initramfs-image to your tftp-root (default filename is
test.bin) and configure networking accordingly (default server IP is
10.10.10.3, client 10.10.10.123). Start your tftp server.
* Open the board and connect to UART. The pins are exposed and clearly
marked.
* Boot the board and press 1.
* Either use the default filename and client/server IP-addresses, or
specify your own.

The image should now be loaded to memory and board boot. If the router
reboots while the image is loading, you need to try again. Once the
board has booted, copy the sysupgrade-image to the router and run
sysupgrade in order to install OpenWRT to the flash.

Notes:

- You control which SIM slot to use by writing 0/1 to
/sys/class/gpio/sim_switch/value. In order for the change to take
effect, you can either use AT-commands (AT+CFUN) or power-cycle the
modem (write 0/1 to /sys/class/gpio/power_mpcie/value).
- RS485 is available on /dev/ttyS0.
- RS232 is available on /dev/ttyS1.
- The name of the ioX-gpios map to the labels on the casing.

Signed-off-by: Kristian Evensen 
---
v2->v3:

* Build initramfs automatically, which means that ramdisk is now enabled
the mt7620-target. Due to this change, an initramfs-image is built for all
deivces, but this seems to be ok when looking at other targets (mt7621)
(thanks Petr Štetiar).
* Use generic board/model detection, updated the match in 01_leds and
02_network (thanks Petr Štetiar).
* Changed the device/target device in the Makefile to match the
compatible-string in the DTS (thanks Petr Štetiar).
* Use the user-space gpio-switch alternative instead of gpio-export in
the DTS (thanks Petr Štetiar).
* Update name of flash node in DTS to the more generic "flash0" (thanks
Petr Štetiar)..
* Fix typo in commit message (mt7621->mt7612) (thanks Tom Psyborg).
* Added the QMI and option drivers, as well as uqmi, so that the modem
is available for use out of the box.

v1->v2:
* Add SPDX line to DTS (thanks Rafał Miłecki).
---
 .../ramips/base-files/etc/board.d/01_leds |   3 +
 .../ramips/base-files/etc/board.d/02_network  |   1 +
 .../base-files/etc/board.d/03_gpio_switches   |   8 +
 target/linux/ramips/dts/HDRM200.dts   | 188 ++
 target/linux/ramips/image/mt7620.mk   |   9 +
 target/linux/ramips/mt7620/target.mk  |   2 +-
 6 files changed, 210 insertions(+), 1 deletion(-)
 create mode 100644 target/linux/ramips/dts/HDRM200.dts

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 fa20ab0714..0799314f6d 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -184,6 +184,9 @@ hc5861)
ucidef_set_led_netdev "wifi5g" "wifi5g" "$boardname:blue:wlan5g" "wlan0"
ucidef_set_led_netdev "wifi2g" "wifi2g" "$boardname:blue:wlan2g" "wlan1"
;;
+head-weblink,hdrm200)
+   set_wifi_led "$boardname:green:wifi"
+   ;;
 hg255d)
set_wifi_led "$boardname:green:wlan"
ucidef_set_led_netdev "internet" "internet" "$boardname:green:internet" 
"eth0.2"
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 c2646876a2..b0037a0ce2 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -314,6 +314,7 @@ ramips_setup_interfaces()
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "6@eth0"
;;
hc5661|\
+   head-weblink,hdrm200|\
y1s)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "5:lan" "0:wan&

Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Hi Petr,

On Sun, May 5, 2019 at 10:26 PM Petr Štetiar  wrote:
> Unfortunately no, but I've just proposed[1] some temporary workaround, so
> let's see how this pans out. Until it's accepted, I would simply go with that
> proposed `FEATURES += ramdisk` based solution.
>
> 1. http://lists.infradead.org/pipermail/openwrt-devel/2019-May/016931.html

Thanks. I have tested the selective-ramdisk approach with HDRM200 and
it works fine, but since it is not merged then my current
v3-submission sets the ramdisk feature.

> It's just a poor-man's replacement for a picture of scissors, meaning, that
> I've simply removed some text around this `...` line.

Aha, I see :)

> BTW, I haven't had time to check correctness of this pinctrl yet, but I'll do
> so.

Ok, I will wait with submitting a v3 until you are done with this.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH 0/2] [RFC] build: allow selective per device initramfs

[Kristian Evensen]

Hi Petr,

On Sun, May 5, 2019 at 10:14 PM Petr Štetiar  wrote:
> I find it quite weird to demand any kind of compilation by the end-users, but
> I also find it quite wasteful to build initramfs images for all devices under
> particular target (lantiq/xrx200 and ramips/mt7620), just because one (or
> minority) of device needs this image.
>
> So I've looked at the possible solutions, and with the limited time on hand
> I've come up with the following patch series. I'm sure, that this is kind of a
> weird workaround, but I find it less obtrusive then building of initramfs
> images for all targets, with no apparent use.
>
> Essential solution would be something like image recipe for initramfs, but
> since it's quite complicated topic it would need a lot more time to fix it
> properly.
>
> So I'm wondering if such workaround to avoid building of unnecessary initramfs
> images would be acceptable, or until there's a proper solution, we should
> simply live with the `FEATURES += ramdisk` based "solution".

Thank you for sharing your patches. I had started implementing a
similar solution, but quickly abandoned my work when I saw the commits
in your staging tree. Even though I have no authority, I think your
solution is nice and it solves the problem at hand. I applied your
patches and modified mt7620 + the HDRM200 target accordingly, and as
expected I only get one initramfs image. I agree that building
initramfs for devices that do not need it is redundant (I see that
initramfs is built for all mt7621 targets for example), so I am very
much in favor of merging this series.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Hi,

On Sun, May 5, 2019 at 12:53 PM Tom Psyborg  wrote:
> > - 1x 5GHz wifi (mt7621)
>
> mt7621 is not wifi chip, you should update the description or just
> leave mt76 if you intention is to specify supporting driver.

Thanks for spotting this typo. I know very well that mt7621 is not a
wifi chip, it should have said mt7612.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Hello again,

On Sat, May 4, 2019 at 12:07 PM Kristian Evensen
 wrote:
> Also, I am having some issues getting a ramdisk image to be built by
> default. After adding ramdisk to FEATURES, I still need to manually
> choose to build a ramdisk image. I have spent some time looking into
> the different mk-files to try to figure out what could be wrong, but
> without any luck. Do you have any pointers?

I made a second attempt here and turns out I had made a stupid mistake
- I had forgot to remove my old config. After starting from a clean
build dir, ramdisk is correctly enabled after selecting mt7620. I
still wonder if there is a way to only enable ramdisk for the HDRM200
though.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v2] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Hi Petr,

Thanks a lot for your feedback. I have implemented most of it and the
board seems to work fine, but I have some questions.

On Fri, May 3, 2019 at 6:32 PM Petr Štetiar  wrote:
> > In order to install OpenWRT, you first need to compile an initramfs
> > (ramdisk)-image for the device.
>
> if the ramdisk image is needed, then we probably should enable it for that
> target and provide it, we shouldn't demand end users to build the ramdisk
> images by themselves in order to be able to install OpenWrt, right?
>
> This needs adding `ramdisk` in FEATURES in target.mk.

I agree, building a ramdisk-image by default would be preferable.
However, wont adding ramdisk to FEATURES build a ramdisk image for all
mt7620-boards? Do you know any way to avoid that?

Also, I am having some issues getting a ramdisk image to be built by
default. After adding ramdisk to FEATURES, I still need to manually
choose to build a ramdisk image. I have spent some time looking into
the different mk-files to try to figure out what could be wrong, but
without any luck. Do you have any pointers?

> > The image should now be loaded to memory and board boot. If the router
> > reboots while the image is loading, you need to try again.
>
> Why does it reboot? Is there any kind of watchdog? Do you get any error in the
> bootloader?

Why the board reboots is a good question. I tried to ask the
manufacturer, but got no answer. There are no errors  as the board
just suddenly reboots, but I do suspect that there is some kind of
watchdog triggering the reboots. The reboot seems to occur after
roughly the same time, but something needs to happen for the reboot to
be triggered. For example, I can idle on the bootloader command line
for as long as I want. However, if I wait sufficiently long before
pressing enter, then the board reboots.

> > + {
> > + state_default: pinctrl0 {
> > + default {
> > + ralink,group = "i2c", "uartf", "pa", "spi refclk", 
> > "wled";
> > + ralink,function = "gpio";
> > + };
> > + };
> > +};
>
> ...

I have to admit that I don't understand what you are refering to there
(unless it is the too long "ralink,group"-line) :)

Thanks again for your comments!

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] system: uci: Use config dir on uci_add and support add_/del_list

[Kristian Evensen]

This commit makes three changes to the uci shell library:

* A check for UCI_CONFIG_DIR has been added to the command line when
adding anonymous sections. Without this change, adding anonymous
sections to configs not stored in /etc/config is not possible.

* Support for adding/removing items from lists were missing, so I have
added the functions uci_add_list() and uci_del_list() to simplify
working with uci lists from scripts.

Signed-off-by; Kristian Evensen 
---
 package/system/uci/files/lib/config/uci.sh | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/package/system/uci/files/lib/config/uci.sh 
b/package/system/uci/files/lib/config/uci.sh
index 78ec277669..803adf9d97 100644
--- a/package/system/uci/files/lib/config/uci.sh
+++ b/package/system/uci/files/lib/config/uci.sh
@@ -85,6 +85,15 @@ uci_set() {
/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} set 
"$PACKAGE.$CONFIG.$OPTION=$VALUE"
 }
 
+uci_add_list() {
+   local PACKAGE="$1"
+   local CONFIG="$2"
+   local OPTION="$3"
+   local VALUE="$4"
+
+   /sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} add_list 
"$PACKAGE.$CONFIG.$OPTION=$VALUE"
+}
+
 uci_get_state() {
uci_get "$1" "$2" "$3" "$4" "/var/state"
 }
@@ -108,7 +117,7 @@ uci_add() {
local CONFIG="$3"
 
if [ -z "$CONFIG" ]; then
-   export ${NO_EXPORT:+-n} CONFIG_SECTION="$(/sbin/uci add 
"$PACKAGE" "$TYPE")"
+   export ${NO_EXPORT:+-n} CONFIG_SECTION="$(/sbin/uci 
${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} add "$PACKAGE" "$TYPE")"
else
/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} set 
"$PACKAGE.$CONFIG=$TYPE"
export ${NO_EXPORT:+-n} CONFIG_SECTION="$CONFIG"
@@ -132,6 +141,15 @@ uci_remove() {
/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} del 
"$PACKAGE.$CONFIG${OPTION:+.$OPTION}"
 }
 
+uci_del_list() {
+   local PACKAGE="$1"
+   local CONFIG="$2"
+   local OPTION="$3"
+   local VALUE="$4"
+
+   /sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} del_list 
"$PACKAGE.$CONFIG.$OPTION=$VALUE"
+}
+
 uci_commit() {
local PACKAGE="$1"
/sbin/uci ${UCI_CONFIG_DIR:+-c $UCI_CONFIG_DIR} commit $PACKAGE
-- 
2.19.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Head Weblink HDRM200 is a dual-sim router based on MT7620A. The detailed
specifications are:

- MT7620A (580MHz)
- 64MB RAM
- 16MB of flash (SPI NOR)
- 6x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM slots (standard size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 1x 5GHz wifi (mt7621)
- 1x reset button
- 1x WPS button
- 3x GPIO-controllable LEDs
- 1x 10 pin terminal block (RS232, RS485, 4 x GPIO)

Tested:
- Ethernet switch
- Wifi
- USB slot
- SD card slot
- miniPCIe-slot
- sysupgrade
- reset button

Installation instructions:

Installing OpenWRT for the first time requires a bit of work, as the
board does not ship with OpenWRT. In addition, the bootloader
automatically reboots when installing an image over tftp.

In order to install OpenWRT, you first need to compile an initramfs
(ramdisk)-image for the device. Once the image is ready, you need to do
the following:

* Copy the initramfs-image to your tftp-root (default filename is
test.bin) and configure networking accordingly (default server IP is
10.10.10.3, client 10.10.10.123). Start your tftp server.
* Open the board and connect to UART. The pins are exposed and clearly
marked.
* Boot the board and press 1.
* Either use the default filename and client/server IP-addresses, or
specify your own.

The image should now be loaded to memory and board boot. If the router
reboots while the image is loading, you need to try again. Once the
board has booted, copy the sysupgrade-image to the router and run
sysupgrade in order to install OpenWRT to the flash.

Notes:

- You control which SIM slot to use by writing 0/1 to
/sys/class/gpio/sim_switch/value. In order for the change to take
effect, you can either use AT-commands (AT+CFUN) or power-cycle the
modem (write 0/1 to /sys/class/gpio/power_mpcie/value).
- RS485 is available on /dev/ttyS0.
- RS232 is available on /dev/ttyS1.
- The name of the ioX-gpios map to the labels on the casing.

v1->v2:
* Add SPDX line to DTS (thanks Rafał Miłecki).

Signed-off-by: Kristian Evensen 
---
 .../ramips/base-files/etc/board.d/01_leds |   3 +
 .../ramips/base-files/etc/board.d/02_network  |   1 +
 target/linux/ramips/base-files/lib/ramips.sh  |   3 +
 target/linux/ramips/dts/HDRM200.dts   | 227 ++
 target/linux/ramips/image/mt7620.mk   |   8 +
 5 files changed, 242 insertions(+)
 create mode 100644 target/linux/ramips/dts/HDRM200.dts

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 fa20ab0714..f9ca5c47b8 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -184,6 +184,9 @@ hc5861)
ucidef_set_led_netdev "wifi5g" "wifi5g" "$boardname:blue:wlan5g" "wlan0"
ucidef_set_led_netdev "wifi2g" "wifi2g" "$boardname:blue:wlan2g" "wlan1"
;;
+hdrm200)
+   set_wifi_led "$boardname:green:wifi"
+   ;;
 hg255d)
set_wifi_led "$boardname:green:wlan"
ucidef_set_led_netdev "internet" "internet" "$boardname:green:internet" 
"eth0.2"
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 c2646876a2..8ae41ae59e 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -314,6 +314,7 @@ ramips_setup_interfaces()
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "6@eth0"
;;
hc5661|\
+   hdrm200|\
y1s)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "5:lan" "0:wan" "6@eth0"
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 093303892c..6d5a9cc391 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -229,6 +229,9 @@ ramips_board_detect() {
*"HC5962")
name="hc5962"
;;
+   *"HDRM200")
+   name="hdrm200"
+   ;;
*"HG255D")
name="hg255d"
;;
diff --git a/target/linux/ramips/dts/HDRM200.dts 
b/target/linux/ramips/dts/HDRM200.dts
new file mode 100644
index 00..05e0b1a6dc
--- /dev/null
+++ b/target/linux/ramips/dts/HDRM200.dts
@@ -0,0 +1,227 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "head-weblink,hdrm200", "ralink,mt7620a-soc"

Re: [OpenWrt-Devel] [PATCH] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Hi Rafał,

On Thu, May 2, 2019 at 9:31 AM Rafał Miłecki  wrote:
> Please include SPDX line with .dts file license, see:
> https://openwrt.org/submitting-patches#dts_checklist

Thanks for your feedback. Will update and submit a V2 later today.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: Add support for Head Weblink HDRM200

[Kristian Evensen]

Head Weblink HDRM200 is a dual-sim router based on MT7620A. The detailed
specifications are:

- MT7620A (580MHz)
- 64MB RAM
- 16MB of flash (SPI NOR)
- 6x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM slots (standard size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 1x 5GHz wifi (mt7621)
- 1x reset button
- 1x WPS button
- 3x GPIO-controllable LEDs
- 1x 10 pin terminal block (RS232, RS485, 4 x GPIO)

Tested:
- Ethernet switch
- Wifi
- USB slot
- SD card slot
- miniPCIe-slot
- sysupgrade
- reset button

Installation instructions:

Installing OpenWRT for the first time requires a bit of work, as the
board does not ship with OpenWRT. In addition, the bootloader
automatically reboots when installing an image over tftp.

In order to install OpenWRT, you first need to compile an initramfs
(ramdisk)-image for the device. Once the image is ready, you need to do
the following:

* Copy the initramfs-image to your tftp-root (default filename is
test.bin) and configure networking accordingly (default server IP is
10.10.10.3, client 10.10.10.123). Start your tftp server.
* Open the board and connect to UART. The pins are exposed and clearly
marked.
* Boot the board and press 1.
* Either use the default filename and client/server IP-addresses, or
specify your own.

The image should now be loaded to memory and board boot. If the router
reboots while the image is loading, you need to try again. Once the
board has booted, copy the sysupgrade-image to the router and run
sysupgrade in order to install OpenWRT to the flash.

Notes:

- You control which SIM slot to use by writing 0/1 to
/sys/class/gpio/sim_switch/value. In order for the change to take
effect, you can either use AT-commands (AT+CFUN) or power-cycle the
modem (write 0/1 to /sys/class/gpio/power_mpcie/value).
- RS485 is available on /dev/ttyS0.
- RS232 is available on /dev/ttyS1.
- The name of the ioX-gpios map to the labels on the casing.

Signed-off-by: Kristian Evensen 
---
 .../ramips/base-files/etc/board.d/01_leds |   3 +
 .../ramips/base-files/etc/board.d/02_network  |   1 +
 target/linux/ramips/base-files/lib/ramips.sh  |   3 +
 target/linux/ramips/dts/HDRM200.dts   | 226 ++
 target/linux/ramips/image/mt7620.mk   |   8 +
 5 files changed, 241 insertions(+)
 create mode 100644 target/linux/ramips/dts/HDRM200.dts

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 1fc86c44c3..c9da17ddc9 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -184,6 +184,9 @@ hc5861)
ucidef_set_led_netdev "wifi5g" "wifi5g" "$boardname:blue:wlan5g" "wlan0"
ucidef_set_led_netdev "wifi2g" "wifi2g" "$boardname:blue:wlan2g" "wlan1"
;;
+hdrm200)
+   set_wifi_led "$boardname:green:wifi"
+   ;;
 hg255d)
set_wifi_led "$boardname:green:wlan"
ucidef_set_led_netdev "internet" "internet" "$boardname:green:internet" 
"eth0.2"
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 28fd00926c..69c281aeeb 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -315,6 +315,7 @@ ramips_setup_interfaces()
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "6@eth0"
;;
hc5661|\
+   hdrm200|\
y1s)
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "5:lan" "0:wan" "6@eth0"
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index 6742c5370b..ea12a021b3 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -229,6 +229,9 @@ ramips_board_detect() {
*"HC5962")
name="hc5962"
;;
+   *"HDRM200")
+   name="hdrm200"
+   ;;
*"HG255D")
name="hg255d"
;;
diff --git a/target/linux/ramips/dts/HDRM200.dts 
b/target/linux/ramips/dts/HDRM200.dts
new file mode 100644
index 00..b076f30978
--- /dev/null
+++ b/target/linux/ramips/dts/HDRM200.dts
@@ -0,0 +1,226 @@
+/dts-v1/;
+
+#include "mt7620a.dtsi"
+
+#include 
+#include 
+
+/ {
+   compatible = "head-weblink,hdrm200", "ralink,mt7620a-soc";
+   model = "Head Weblink HDRM200";
+
+   aliases {
+   led-boot = _system;
+  

[OpenWrt-Devel] [PATCH V2] procd: instance: Support deleting stopped instances

[Kristian Evensen]

procd currently does not support deleting a stopped instance. The reason
is that we return in instance_stop(), if pending is set to false. This
patch adds a new function, instance_delete(), which does the necessary
clean-up of an instance. instance_delete() is called before we return in
instance_stop(), as well as when a process that should not be restarted
has exited in instance_exit().

v1->v2:
- Only call instance_delete() in instance_stop() if halt is true (thanks
Hans Dedecker).

Signed-off-by: Kristian Evensen 
---
 service/instance.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/service/instance.c b/service/instance.c
index a5742b7..3512f66 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -518,6 +518,16 @@ instance_timeout(struct uloop_timeout *t)
instance_start(in);
 }
 
+static void
+instance_delete(struct service_instance *in)
+{
+   struct service *s = in->srv;
+
+   avl_delete(>instances.avl, >node.avl);
+   instance_free(in);
+   service_stopped(s);
+}
+
 static void
 instance_exit(struct uloop_process *p, int ret)
 {
@@ -539,13 +549,8 @@ instance_exit(struct uloop_process *p, int ret)
instance_removepid(in);
if (in->restart)
instance_start(in);
-   else {
-   struct service *s = in->srv;
-
-   avl_delete(>instances.avl, >node.avl);
-   instance_free(in);
-   service_stopped(s);
-   }
+   else
+   instance_delete(in);
} else if (in->restart) {
instance_start(in);
} else if (in->respawn) {
@@ -569,8 +574,11 @@ instance_exit(struct uloop_process *p, int ret)
 void
 instance_stop(struct service_instance *in, bool halt)
 {
-   if (!in->proc.pending)
+   if (!in->proc.pending) {
+   if (halt)
+   instance_delete(in);
return;
+   }
in->halt = halt;
in->restart = in->respawn = false;
kill(in->proc.pid, SIGTERM);
-- 
2.19.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] procd: instance: Support deleting stopped instances

[Kristian Evensen]

Hi Hans,

On Thu, Apr 4, 2019 at 10:59 PM Hans Dedecker  wrote:
> instance_delete should only be called when halt is set to true similar
> as in instance_exit

Thanks for the feedback. Just so I make sure I understand correctly,
do you mean that the conditional should look something like this?

 577 if (!in->proc.pending) {
 578 if (halt)
 579 instance_delete(in);
 580 return;
 581 }

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] ramips: Add support for ZBT WE826-E

[Kristian Evensen]

Hi,

On Thu, Mar 21, 2019 at 2:23 PM Bjørn Mork  wrote:
>
> Kristian Evensen  writes:
>
> > - 2x SIM card slots (full size)
>
> Really?  Am I the only one who remember credit card sized SIMs? :-)
>
> They were the only kind we had when GSM was introduced around here in
> 1991/1992.  See for example the description of the GSM version of the
> MicroTAC Classic:
> https://en.wikipedia.org/wiki/Motorola_MicroTAC#MicroTAC_Classic
>
> OK, I am old.  I know.

Hehe, I was not aware of credit-card sized SIMs :) I see now that
correct term is "mini-SIM", will update if there will be a v2 of the
patch. Thanks for letting me know.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: Add support for ZBT WE826-E

[Kristian Evensen]

ZBT WE826-E is a dual-SIM version of the ZBT WE826. The router has the
following specifications:

- MT7620A (580 MHz)
- 128MB RAM
- 32MB of flash (SPI NOR)
- 5x 10/100Mbps Ethernet (MT7620A built-in switch)
- 1x microSD slot
- 1x miniPCIe slot (only USB2.0 bus)
- 2x SIM card slots (full size)
- 1x USB2.0 port
- 1x 2.4GHz wifi (rt2800)
- 10x LEDs (4 GPIO-controlled)
- 1x reset button

The following have been tested and working:
- Ethernet switch
- wifi
- miniPCIe slot
- USB port
- microSD slot
- sysupgrade
- reset button

Installation:

The router ships with an older version of OpenWRT, but with a broken web
user interface. In order to install the image, you need to SSH into the
router and run sysupgrade. The default address of the router is
192.168.1.1, user is root and password admin. Once you are in, run the
following command:

sysupgrade -n -F openwrt-ramips-mt7620-zbt-we826-e-squashfs-sysupgrade.bin

Recovery:

The router ships with a web-based recovery system. If you need to
recover the router, 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.

How to swap SIMs:

In order to switch which SIM is used, you need to do the following:

- Turn off the modem by running the following command:
echo 0 > /sys/class/gpio/power_mpcie/value

- Write either 0 or 1 to /sys/class/gpio/sim_switch/value. After
boot/reboot, the router will always use SIM 0. You can check which SIM
slot is currently used by reading from the file mentioned in the first
sentence.

- Turn on the modem again by running the following command:
echo 1 > /sys/class/gpio/power_mpcie/value

Signed-off-by: Kristian Evensen 
---
 .../ramips/base-files/etc/board.d/01_leds |   3 +
 .../ramips/base-files/etc/board.d/02_network  |   1 +
 target/linux/ramips/base-files/lib/ramips.sh  |   3 +
 target/linux/ramips/dts/ZBT-WE826-E.dts   | 101 ++
 target/linux/ramips/image/mt7620.mk   |   8 ++
 5 files changed, 116 insertions(+)
 create mode 100644 target/linux/ramips/dts/ZBT-WE826-E.dts

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 9cca231ab6..ebfc1e360b 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -451,6 +451,9 @@ zbt-we826-16M|\
 zbt-we826-32M)
set_wifi_led "zbt-we826:green:wifi"
;;
+zbt-we826-e)
+   set_wifi_led "zbt-we826-e:red:wifi"
+   ;;
 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 890efa0d93..702f781e15 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -135,6 +135,7 @@ ramips_setup_interfaces()
zbtlink,zbt-we3526|\
zbt-we826-16M|\
zbt-we826-32M|\
+   zbt-we826-e|\
zbt-wg2626|\
zbt-wg3526-16M|\
zbt-wg3526-32M|\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index db93710ba7..b1e11f97b7 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -679,6 +679,9 @@ ramips_board_detect() {
*"ZBT-WE826 (32M)")
name="zbt-we826-32M"
;;
+   *"ZBT-WE826-E")
+   name="zbt-we826-e"
+   ;;
*"ZBT-WG2626")
name="zbt-wg2626"
;;
diff --git a/target/linux/ramips/dts/ZBT-WE826-E.dts 
b/target/linux/ramips/dts/ZBT-WE826-E.dts
new file mode 100644
index 00..a57aeb4823
--- /dev/null
+++ b/target/linux/ramips/dts/ZBT-WE826-E.dts
@@ -0,0 +1,101 @@
+/dts-v1/;
+
+#include "ZBT-WE826.dtsi"
+
+/ {
+   compatible = "zbtlink,zbt-we826-e", "zbtlink,zbt-we826", 
"ralink,mt7620a-soc";
+   model = "ZBT-WE826-E";
+
+   gpio-export {
+   compatible = "gpio-export";
+   #size-cells = <0>;
+
+   sim_switch {
+   gpio-export,name = "sim_switch";
+   gpio-export,output = <1>;
+   gpios = < 13 GPIO_ACTIVE_LOW>;
+   };
+
+   power_mpcie {
+   gpio-export,name = "power_mpcie";
+   gpio-export,output = <1>;
+   gpios = < 14 GPIO_ACTIVE_HIGH>;
+   };
+   };
+
+   /delete-node/ leds;
+
+   leds {
+   com

Re: [OpenWrt-Devel] [PATCH] openssl: Fix longer booting times by unblocking getrandom

[Kristian Evensen]

Hi,

On Fri, Mar 15, 2019 at 1:29 PM Petr Štetiar  wrote:
>
> While testing simple firmware image for x86/64 in QEMU I've discovered
> some weird behavior today. This image contains simple package with
> simple init script to bootstrap the device UCI configuration from
> network server. This init script uses uclient-fetch and libustream-openssl.
>
> This image was booting fine until today, usually finished booting under
> 10s, but today it was booting much slowly, boot times were in range from
> 60s to a few minutes. I was also unable to power off the QEMU with
> poweroff command.
>
> I've found out, that it's all happening because of uclient-fetch being
> blocked in getrandom syscall, leading for example to following:
>
>  root@OpenWrt:~# time uclient-fetch
>  ^CCommand terminated by signal 2
>  real   8m 31.08s
>
> The problem passes away after `random: crng init done` hits
> the system log, but this step can take ages in some cases (usually when there
> are more processes calling getrandom in parallel), but I couldn't get it
> under 60s on my QEMU machine. I've similar weird reports from users on
> MIPS devices as well.
>
>  [   13.786576] random: fast init done
>  ...
>  [  653.153740] random: crng init done
>
> I've bisected the problem down to the following commit (reverting it
> fixed the problem):
>
>   # first bad commit: [d872d00b2f] openssl: update to version 1.1.1a
>
> So this patch tries to fix this issue by making getrandom syscall
> nonblocking, and also removes possible usage of getentropy libc call,
> which in case of musl libc results again in use of getrandom syscall in
> blocking mode.
>
> I've also added new config option just in case someone would prefer to
> have probably safer but much slower boot times on some devices.

I  had a similar problem on some x86-devices. The problem is that
OpenWRT-devices are so "quiet" that it takes a while before a
sufficient amount of entropy is generated. Instead of disabling the
blocking getrandom()-call, what I did to "solve" the issue was to
install the haveged-packet on devices where I could not find a driver
for the hardware generator. haveged attempts to provide an
unpredictable random number generator, and I was able to get the crng
init down to a couple of sections. haveged apparently has/had some
issues with VMs (https://wiki.archlinux.org/index.php/Haveged), but
most of them seems to have been resolved.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] procd: instance: Support deleting stopped instances

[Kristian Evensen]

procd currently does not support deleting a stopped instance. The reason
is that we return in instance_stop(), if pending is set to false. This
patch adds a new function, instance_delete(), which does the necessary
clean-up of an instance. instance_delete() is called before we return in
instance_stop(), as well as when a process that should not be restarted
has exited in instance_exit().

Signed-off-by: Kristian Evensen 
---
 service/instance.c | 23 +++
 1 file changed, 15 insertions(+), 8 deletions(-)

diff --git a/service/instance.c b/service/instance.c
index a5742b7..78ac540 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -518,6 +518,16 @@ instance_timeout(struct uloop_timeout *t)
instance_start(in);
 }
 
+static void
+instance_delete(struct service_instance *in)
+{
+   struct service *s = in->srv;
+
+   avl_delete(>instances.avl, >node.avl);
+   instance_free(in);
+   service_stopped(s);
+}
+
 static void
 instance_exit(struct uloop_process *p, int ret)
 {
@@ -539,13 +549,8 @@ instance_exit(struct uloop_process *p, int ret)
instance_removepid(in);
if (in->restart)
instance_start(in);
-   else {
-   struct service *s = in->srv;
-
-   avl_delete(>instances.avl, >node.avl);
-   instance_free(in);
-   service_stopped(s);
-   }
+   else
+   instance_delete(in);
} else if (in->restart) {
instance_start(in);
} else if (in->respawn) {
@@ -569,8 +574,10 @@ instance_exit(struct uloop_process *p, int ret)
 void
 instance_stop(struct service_instance *in, bool halt)
 {
-   if (!in->proc.pending)
+   if (!in->proc.pending) {
+   instance_delete(in);
return;
+   }
in->halt = halt;
in->restart = in->respawn = false;
kill(in->proc.pid, SIGTERM);
-- 
2.19.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mac80211: rt2x00: fix crash on release_firmware

[Kristian Evensen]

Hi Stanislaw,

On Sun, Feb 24, 2019 at 10:23 AM Stanislaw Gruszka  wrote:
>
> Fix crash due to passing invalid r2x00dev->eeprom_file pointer to
> release_firmware(). Since we copy eeprom data with EEPROM_SIZE
> in rt2800_read_eeprom() we can use eeprom_file->size as marker
> if the file was crated by request_firmware().
>
> Cc: Felix Fietkau ,
> Cc: Daniel Golle 
> Signed-off-by: Stanislaw Gruszka 

Thanks for the patch. I submitted a patch doing something similar some
days ago, but your fix is much nicer. FWIW:

Acked-by: Kristian Evensen 

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] firewall3: Improve ipset support

[Kristian Evensen]

This patch is an attempt at improving the ipset support in firewall3.
The following changes have been made:

* The enabled option did not work properly for ipsets, as it was not
checked on create/destroy of a set. After this commit, sets are only
created/destroyed if enabled is set to true.

* Add support for reloading, or recreating, ipsets on firewall reload.
By setting "reload_set" to true, the set will be destroyed and then
re-created when the firewall is reloaded. My use-case for "reload_set"
was to reset sets populated by dnsmasq, without having to restart the
firewall or resort to scripts.

* Add support for the counters and comment extensions. By setting
"counters" or "comment" to true, then counters or comments are added to
the set.

Signed-off-by: Kristian Evensen 
---
 ipsets.c  | 35 +--
 ipsets.h  |  6 --
 main.c| 16 +++-
 options.h |  4 
 utils.c   |  5 +
 5 files changed, 57 insertions(+), 9 deletions(-)

diff --git a/ipsets.c b/ipsets.c
index b73c3d2..49ba672 100644
--- a/ipsets.c
+++ b/ipsets.c
@@ -21,6 +21,9 @@
 
 const struct fw3_option fw3_ipset_opts[] = {
FW3_OPT("enabled",   bool,   ipset, enabled),
+   FW3_OPT("reload_set",bool,   ipset, reload_set),
+   FW3_OPT("counters",  bool,   ipset, counters),
+   FW3_OPT("comment",   bool,   ipset, comment),
 
FW3_OPT("name",  string, ipset, name),
FW3_OPT("family",family, ipset, family),
@@ -56,6 +59,8 @@ enum ipset_optflag {
OPT_HASHSIZE  = (1 << 3),
OPT_MAXELEM   = (1 << 4),
OPT_FAMILY= (1 << 5),
+   OPT_COUNTERS  = (1 << 6),
+   OPT_COMMENT   = (1 << 7),
 };
 
 struct ipset_type {
@@ -204,6 +209,10 @@ check_types(struct uci_element *e, struct fw3_ipset *ipset)
 static bool
 check_ipset(struct fw3_state *state, struct fw3_ipset *ipset, struct 
uci_element *e)
 {
+   if (!ipset->enabled) {
+   return false;
+   }
+
if (ipset->external)
{
if (!*ipset->external)
@@ -253,6 +262,9 @@ fw3_alloc_ipset(struct fw3_state *state)
INIT_LIST_HEAD(>entries);
 
ipset->enabled = true;
+   ipset->reload_set = false;
+   ipset->counters = false;
+   ipset->comment = false;
ipset->family  = FW3_FAMILY_V4;
 
list_add_tail(>list, >ipsets);
@@ -389,6 +401,12 @@ create_ipset(struct fw3_ipset *ipset, struct fw3_state 
*state)
if (ipset->hashsize > 0)
fw3_pr(" hashsize %u", ipset->hashsize);
 
+   if (ipset->counters)
+   fw3_pr(" counters");
+
+   if (ipset->comment)
+   fw3_pr(" comment");
+
fw3_pr("\n");
 
list_for_each_entry(entry, >entries, list)
@@ -398,7 +416,8 @@ create_ipset(struct fw3_ipset *ipset, struct fw3_state 
*state)
 }
 
 void
-fw3_create_ipsets(struct fw3_state *state)
+fw3_create_ipsets(struct fw3_state *state, enum fw3_family family,
+ bool reload_set)
 {
int tries;
bool exec = false;
@@ -410,6 +429,10 @@ fw3_create_ipsets(struct fw3_state *state)
/* spawn ipsets */
list_for_each_entry(ipset, >ipsets, list)
{
+   if (ipset->family != family ||
+   (reload_set && !ipset->reload_set))
+   continue;
+
if (ipset->external)
continue;
 
@@ -442,15 +465,23 @@ fw3_create_ipsets(struct fw3_state *state)
 }
 
 void
-fw3_destroy_ipsets(struct fw3_state *state)
+fw3_destroy_ipsets(struct fw3_state *state, enum fw3_family family,
+  bool reload_set)
 {
int tries;
bool exec = false;
struct fw3_ipset *ipset;
 
+   if (state->disable_ipsets)
+   return;
+
/* destroy ipsets */
list_for_each_entry(ipset, >ipsets, list)
{
+   if (ipset->family != family ||
+   (reload_set && !ipset->reload_set))
+   continue;
+
if (!exec)
{
exec = fw3_command_pipe(false, "ipset", "-exist", "-");
diff --git a/ipsets.h b/ipsets.h
index 2ba862d..fec79f8 100644
--- a/ipsets.h
+++ b/ipsets.h
@@ -28,8 +28,10 @@
 extern const struct fw3_option fw3_ipset_opts[];
 
 void fw3_load_ipsets(struct fw3_state *state, struct uci_package *p, struct 
blob_attr *a);
-void fw3_create_ipsets(struct fw3_state *state);
-void fw3_destroy_ipsets(struct fw3_state *state);
+void fw3_create_ipsets(struct fw3_state *state, enum fw3_family family,
+  bool reload_set);
+void fw3_de

[OpenWrt-Devel] [PATCH] mac80211: fix removing rt2x00 module

[Kristian Evensen]

When EEPROM is loaded from mtd, removing the rt2x00 module triggers a
kernel oops. The reason for the oops is that release_firmware() is
always called from rt2x00lib_free_eeprom_file(). release_firmware()
frees the memory allocated by request_firmware(), which is called when
EEPROM is loaded from file. However, when loaded from mtd, no memory is
allocated for the EEPROM (and the firwmware subsystem is not used
either).

The best indication I could think of for if EEPROM is loaded from file
or mtd, is to check for the "ralink,mtd-eeprom" property. At least on
the devices I have access to and where this property is set, EEPROM is
only available from mtd.

Signed-off-by: Kristian Evensen 
---
 ...om-on-SoC-from-a-mtd-device-defines-.patch | 34 ---
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git 
a/package/kernel/mac80211/patches/rt2x00/604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
 
b/package/kernel/mac80211/patches/rt2x00/604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
index a98b49c541..0362dd10f5 100644
--- 
a/package/kernel/mac80211/patches/rt2x00/604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
+++ 
b/package/kernel/mac80211/patches/rt2x00/604-rt2x00-load-eeprom-on-SoC-from-a-mtd-device-defines-.patch
@@ -1,4 +1,4 @@
-From 339fe73f340161a624cc08e738d2244814852c3e Mon Sep 17 00:00:00 2001
+From b5e9327001bf4a859d2645442640c5f8ab77be07 Mon Sep 17 00:00:00 2001
 From: John Crispin 
 Date: Sun, 17 Mar 2013 00:55:04 +0100
 Subject: [PATCH] rt2x00: load eeprom on SoC from a mtd device defines inside
@@ -6,10 +6,12 @@ Subject: [PATCH] rt2x00: load eeprom on SoC from a mtd device 
defines inside
 
 Signed-off-by: John Crispin 
 ---
- drivers/net/wireless/ralink/rt2x00/Kconfig|  1 +
- drivers/net/wireless/ralink/rt2x00/rt2x00eeprom.c | 65 +++
- 2 files changed, 66 insertions(+)
+ drivers/net/wireless/ralink/rt2x00/Kconfig|  1 +
+ .../net/wireless/ralink/rt2x00/rt2x00eeprom.c | 75 +++
+ 2 files changed, 76 insertions(+)
 
+diff --git a/drivers/net/wireless/ralink/rt2x00/Kconfig 
b/drivers/net/wireless/ralink/rt2x00/Kconfig
+index 39fdaaf..2e836d8 100644
 --- a/drivers/net/wireless/ralink/rt2x00/Kconfig
 +++ b/drivers/net/wireless/ralink/rt2x00/Kconfig
 @@ -219,6 +219,7 @@ config RT2800SOC
@@ -20,6 +22,8 @@ Signed-off-by: John Crispin 
---help---
  This adds support for Ralink WiSoC devices.
  Supported chips: RT2880, RT3050, RT3052, RT3350, RT3352.
+diff --git a/drivers/net/wireless/ralink/rt2x00/rt2x00eeprom.c 
b/drivers/net/wireless/ralink/rt2x00/rt2x00eeprom.c
+index 1a30f9c..404a1f7 100644
 --- a/drivers/net/wireless/ralink/rt2x00/rt2x00eeprom.c
 +++ b/drivers/net/wireless/ralink/rt2x00/rt2x00eeprom.c
 @@ -26,11 +26,73 @@
@@ -96,7 +100,7 @@ Signed-off-by: John Crispin 
  static const char *
  rt2x00lib_get_eeprom_file_name(struct rt2x00_dev *rt2x00dev)
  {
-@@ -58,6 +120,9 @@ static int rt2x00lib_request_eeprom_file
+@@ -58,6 +120,9 @@ static int rt2x00lib_request_eeprom_file(struct rt2x00_dev 
*rt2x00dev)
const char *ee_name;
int retval;
  
@@ -106,3 +110,23 @@ Signed-off-by: John Crispin 
ee_name = rt2x00lib_get_eeprom_file_name(rt2x00dev);
if (!ee_name && test_bit(REQUIRE_EEPROM_FILE, >cap_flags)) {
rt2x00_err(rt2x00dev, "Required EEPROM name is missing.");
+@@ -111,6 +176,16 @@ int rt2x00lib_load_eeprom_file(struct rt2x00_dev 
*rt2x00dev)
+ 
+ void rt2x00lib_free_eeprom_file(struct rt2x00_dev *rt2x00dev)
+ {
++#ifdef CONFIG_OF
++  struct device_node *np = rt2x00dev->dev->of_node;
++  int size;
++
++  if (np && of_get_property(np, "ralink,mtd-eeprom", )) {
++  rt2x00dev->eeprom_file = NULL;
++  return;
++  }
++#endif
++
+   release_firmware(rt2x00dev->eeprom_file);
+   rt2x00dev->eeprom_file = NULL;
+ }
+-- 
+2.19.1
+
-- 
2.19.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] dnsmasq stops receiving packets after network restart

[Kristian Evensen]

Hi,

On Tue, Sep 25, 2018 at 11:23 AM Jo-Philipp Wich  wrote:
> Maybe netlink congestion or something related to privilege dropping? Can
> you manage to capture an strace log of the running dnsmasq instance
> while the network is getting restarted?

After some discussion on the dnsmasq mailing list, the cause has been
found and your theory about "resubscribe" is correct. When dnsmasq is
configured to listened to one particular interface, dnsmasq binds
(SO_BINDTODEVICE) to this interface during startup if the interface is
available. On my devices, I had configured dnsmasq to only listen to
br-lan. When I restart networking, br-lan is re-created. This event is
not detected by dnsmasq and the socket will silently fail. If I
configure dnsmasq to listen to two interfaces, SO_BINDTODEVICE is
never used and the error disappears.

Why this error has appeared now is still unknown, but it could be
because no one has gone looking for it. My current work-around, base
on the advice of Simon Kelley, is to have the function which looks up
the interface to bind to (whichdevice()) return NULL. Filtering of
received packets is anyway done not dependent on the bound socket.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] dnsmasq stops receiving packets after network restart

[Kristian Evensen]

Hi,

On Wed, Sep 26, 2018 at 3:14 PM Kristian Evensen
 wrote:
> On Tue, Sep 25, 2018 at 11:23 AM Jo-Philipp Wich  wrote:
> > does the same happen without "bind-dynamic" ? My hunch is that dnsmasq
> > fails to "resubscribe" to the socket after the ifindex of br-lan changed
> > due to the network restart (which will destroy and recreate br-lan).
>
> bind-dynamic seems indeed to be the trigger. Disabling bind-dynamic
> makes the problem go away.

I have been testing some more and I can now trigger the problem
locally as well. However, I don't quite know how I managed to trigger
the issue. Still, I think I have discovered something. When I restart
network, there are two different outcomes for the dnsmasq process - it
is either killed (SIGTERM, trying to identify process) or nor. The
error always happens when the process is not killed. When dnsmasq dies
and is restarted, DHCP continues to work as normal.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] dnsmasq stops receiving packets after network restart

[Kristian Evensen]

Hi Jo-Philipp,

On Tue, Sep 25, 2018 at 6:59 AM Jo-Philipp Wich  wrote:
> whats the complete dnsmasq cmdline?

This is the command line:
/usr/sbin/dnsmasq -C /var/etc/dnsmasq.conf.cfg01411c -k -x
/var/run/dnsmasq/dnsmasq.cfg01411c.pid

The configuration looks as follows:

# auto-generated config file from /etc/config/dhcp
conf-file=/etc/dnsmasq.conf
dhcp-authoritative
domain-needed
localise-queries
read-ethers
enable-ubus
expand-hosts
bind-dynamic
local-service
domain=lan
server=/lan/
server=8.8.8.8
server=8.8.4.4
server=208.67.222.222
server=208.67.220.220
interface=br-lan
dhcp-leasefile=/tmp/dhcp.leases
servers-file=/tmp/resolv-files/servers.conf
resolv-file=/tmp/resolv-files/resolv.conf
stop-dns-rebind
rebind-localhost-ok
dhcp-broadcast=tag:needs-broadcast
addn-hosts=/tmp/hosts
conf-dir=/tmp/dnsmasq.d
user=dnsmasq
group=dnsmasq




bogus-priv
conf-file=/usr/share/dnsmasq/rfc6761.conf
dhcp-range=set:lan,192.168.6.2,192.168.6.201,255.255.255.0,12h
no-dhcp-interface=eth0.2

Thanks,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] dnsmasq stops receiving packets after network restart

[Kristian Evensen]

Hello,

I have some routers running OpenWRT (latest nightly) and that I have
to access remotely (using reverse SSH). When I restart networking
(/etc/init.d/network restart), clients on the LAN can no longer obtain
an IP address using DHCP. If I restart networking locally, DHCP works
as expected after the network is back up.

In order to try and figure out what is going on, I have checked/tried
the following:

* I started out by checking if dnsmasq has been restarted and if the
DHCP socket has been created. I can always see the socket in netstat.
* I then took a look at the firewall. I can see the DHCP packets in
the INPUT chain in filter, which according to my understanding of
Netfilter-internals is the last stop before a packet is delivered to a
socket.
* I then instrumented dnsmasq and added some logging in dhcp_packet()
in dhcp.c. This function is never called, as none of my log-messages
are written to syslog. I checked that the logging works by checking
for my messages when DHCP is working.
* Restarting dnsmasq makes DHCP work again. I can't see any difference
in for example netstat-output.

Does anyone have any idea on what to try or where to look next? After
having spent a couple of days on this issue, I am quickly starting to
run out of ideas.

Thanks in advance for any help,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH v2] mediatek: Fix amount of memory on U7623

[Kristian Evensen]

While finalizing support for the U7623 with 512MB, I made an embarresing
error and configured 1GB RAM for the board. I also forgot to move memory
from the dtsi and to the dts. This commit takes care of my mistakes.

While I am confessing my mistakes, I also note that I made a mistake in
the commit message of the initial U7623 commit. It is the .bin-file, and
not the .gz file that shall be sent to the device via tftp.

v1->v2:
* Remove redundant memory node (thanks Jonas Gorski)

Signed-off-by: Kristian Evensen 
---
 .../0227-arm-dts-Add-Unielec-U7623-DTS.patch   | 35 --
 1 file changed, 19 insertions(+), 16 deletions(-)

diff --git 
a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch 
b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
index eb864e4657..5908108e6b 100644
--- 
a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
+++ 
b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
@@ -1,16 +1,18 @@
-From 13872b8abfadfe70598c065c19d1db759477c4e6 Mon Sep 17 00:00:00 2001
+From 004eb24e939b5b31f828333f37fb5cb2a877d6f2 Mon Sep 17 00:00:00 2001
 From: Kristian Evensen 
 Date: Sun, 17 Jun 2018 14:41:47 +0200
 Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 
 ---
  arch/arm/boot/dts/Makefile |   1 +
- .../dts/mt7623a-unielec-u7623-02-emmc-512M.dts |  17 +
- .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 375 +
- 3 files changed, 393 insertions(+)
+ .../dts/mt7623a-unielec-u7623-02-emmc-512M.dts |  18 +
+ .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 366 +
+ 3 files changed, 385 insertions(+)
  create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
  create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
 
+diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
+index 3fec84fa0..e685ce9a4 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -1062,6 +1062,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
@@ -21,9 +23,12 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
mt7623n-rfb-nand.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt8127-moose.dtb \
+diff --git a/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts 
b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
+new file mode 100644
+index 0..857d440d0
 --- /dev/null
 +++ b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
-@@ -0,0 +1,17 @@
+@@ -0,0 +1,18 @@
 +/*
 + * Copyright 2018 Kristian Evensen 
 + *
@@ -37,13 +42,17 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  model = "UniElec U7623-02 eMMC (512M RAM)";
 +  compatible = "unielec,u7623-02-emmc-512m", "unielec,u7623-02-emmc", 
"mediatek,mt7623";
 +
-+  memory {
++  memory@8000 {
++  device_type = "memory";
 +  reg = <0 0x8000 0 0x2000>;
 +  };
 +};
+diff --git a/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi 
b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
+new file mode 100644
+index 0..adc91266e
 --- /dev/null
 +++ b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
-@@ -0,0 +1,375 @@
+@@ -0,0 +1,366 @@
 +/*
 + * Copyright 2018 Kristian Evensen 
 + *
@@ -66,10 +75,6 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  stdout-path = "serial2:115200n8";
 +  };
 +
-+  memory {
-+  reg = <0 0x8000 0 0x2000>;
-+  };
-+
 +  cpus {
 +  cpu@0 {
 +  proc-supply = <_vproc_reg>;
@@ -145,11 +150,6 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  };
 +  };
 +
-+  memory@8000 {
-+  device_type = "memory";
-+  reg = <0 0x8000 0 0x4000>;
-+  };
-+
 +  mt7530: switch@0 {
 +  compatible = "mediatek,mt7530";
 +  #address-cells = <1>;
@@ -419,3 +419,6 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  status = "okay";
 +};
 +
+-- 
+2.14.1
+
-- 
2.14.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] mediatek: Fix amount of memory on U7623

[Kristian Evensen]

Hi Jonas,

On Tue, Aug 7, 2018 at 10:10 PM, Jonas Gorski  wrote:
> You are adding a second memory node with the same register range as
> the one directly above here, that looks wrong.

Thanks for noticing. The first memory node is redundant and a
left-over from when mediatek was based on an older kernel, and I had
forgot to remove it. I will submit a v2 where only the second memory
node is present.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mediatek: Fix amount of memory on U7623

[Kristian Evensen]

While finalizing support for the U7623 with 512MB RAM, I made an embarrassing
error and configured 1GB RAM for the board. I also forgot to move memory
from the dtsi and to the dts. This commit takes care of my errors.

While I am confessing my mistakes, I also note that I made a mistake in
the commit message of the initial U7623 commit. It is the .bin-file, and
not the .gz file that shall be sent to the device via tftp.

Signed-off-by: Kristian Evensen 
---
 .../0227-arm-dts-Add-Unielec-U7623-DTS.patch   | 37 +-
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git 
a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch 
b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
index eb864e4657..8c0b7611b6 100644
--- 
a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
+++ 
b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
@@ -1,16 +1,18 @@
-From 13872b8abfadfe70598c065c19d1db759477c4e6 Mon Sep 17 00:00:00 2001
+From 1ebcba67d45f1365bcb1b5eb8b0cd8c847610ef2 Mon Sep 17 00:00:00 2001
 From: Kristian Evensen 
 Date: Sun, 17 Jun 2018 14:41:47 +0200
 Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 
 ---
  arch/arm/boot/dts/Makefile |   1 +
- .../dts/mt7623a-unielec-u7623-02-emmc-512M.dts |  17 +
- .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 375 +
- 3 files changed, 393 insertions(+)
+ .../dts/mt7623a-unielec-u7623-02-emmc-512M.dts |  22 ++
+ .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 366 +
+ 3 files changed, 389 insertions(+)
  create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
  create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
 
+diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
+index 3fec84fa0..e685ce9a4 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -1062,6 +1062,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
@@ -21,9 +23,12 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
mt7623n-rfb-nand.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt8127-moose.dtb \
+diff --git a/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts 
b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
+new file mode 100644
+index 0..6efa6e159
 --- /dev/null
 +++ b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
-@@ -0,0 +1,17 @@
+@@ -0,0 +1,22 @@
 +/*
 + * Copyright 2018 Kristian Evensen 
 + *
@@ -40,10 +45,18 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  memory {
 +  reg = <0 0x8000 0 0x2000>;
 +  };
++
++  memory@8000 {
++  device_type = "memory";
++  reg = <0 0x8000 0 0x2000>;
++  };
 +};
+diff --git a/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi 
b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
+new file mode 100644
+index 0..adc91266e
 --- /dev/null
 +++ b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
-@@ -0,0 +1,375 @@
+@@ -0,0 +1,366 @@
 +/*
 + * Copyright 2018 Kristian Evensen 
 + *
@@ -66,10 +79,6 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  stdout-path = "serial2:115200n8";
 +  };
 +
-+  memory {
-+  reg = <0 0x8000 0 0x2000>;
-+  };
-+
 +  cpus {
 +  cpu@0 {
 +  proc-supply = <_vproc_reg>;
@@ -145,11 +154,6 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  };
 +  };
 +
-+  memory@8000 {
-+  device_type = "memory";
-+  reg = <0 0x8000 0 0x4000>;
-+  };
-+
 +  mt7530: switch@0 {
 +  compatible = "mediatek,mt7530";
 +  #address-cells = <1>;
@@ -419,3 +423,6 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  status = "okay";
 +};
 +
+-- 
+2.14.1
+
-- 
2.14.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mediatek: Fix memory node for U7623

[Kristian Evensen]

The changed applied to BananaPi R2 in upstream commit c0b0d540db1a,
which was backported to 4.14 in 4.14.53, is also required for the U7623.
Without updating the memory node, the board refuses to boot.

Fixes: d0839e020d0a ("kernel: bump 4.14 to 4.14.53")

Signed-off-by: Kristian Evensen 
---
 .../0227-arm-dts-Add-Unielec-U7623-DTS.patch | 20 
 1 file changed, 16 insertions(+), 4 deletions(-)

diff --git 
a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch 
b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
index f4a21d4f64..8688a453df 100644
--- 
a/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
+++ 
b/target/linux/mediatek/patches-4.14/0227-arm-dts-Add-Unielec-U7623-DTS.patch
@@ -1,4 +1,4 @@
-From 0c88c72bf130c9276958dc6f595ea473ea357a75 Mon Sep 17 00:00:00 2001
+From 13872b8abfadfe70598c065c19d1db759477c4e6 Mon Sep 17 00:00:00 2001
 From: Kristian Evensen 
 Date: Sun, 17 Jun 2018 14:41:47 +0200
 Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
@@ -6,11 +6,13 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 ---
  arch/arm/boot/dts/Makefile |   1 +
  .../dts/mt7623a-unielec-u7623-02-emmc-512M.dts |  17 +
- .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 374 +
- 3 files changed, 392 insertions(+)
+ .../boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi| 375 +
+ 3 files changed, 393 insertions(+)
  create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
  create mode 100644 arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
 
+diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
+index 3fec84fa0..e685ce9a4 100644
 --- a/arch/arm/boot/dts/Makefile
 +++ b/arch/arm/boot/dts/Makefile
 @@ -1062,6 +1062,7 @@ dtb-$(CONFIG_ARCH_MEDIATEK) += \
@@ -21,6 +23,9 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
mt7623n-rfb-nand.dtb \
mt7623n-bananapi-bpi-r2.dtb \
mt8127-moose.dtb \
+diff --git a/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts 
b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
+new file mode 100644
+index 0..3b14eccd3
 --- /dev/null
 +++ b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc-512M.dts
 @@ -0,0 +1,17 @@
@@ -41,9 +46,12 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  reg = <0 0x8000 0 0x2000>;
 +  };
 +};
+diff --git a/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi 
b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
+new file mode 100644
+index 0..436b02f2d
 --- /dev/null
 +++ b/arch/arm/boot/dts/mt7623a-unielec-u7623-02-emmc.dtsi
-@@ -0,0 +1,374 @@
+@@ -0,0 +1,375 @@
 +/*
 + * Copyright 2018 Kristian Evensen 
 + *
@@ -146,6 +154,7 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  };
 +
 +  memory@8000 {
++  device_type = "memory";
 +  reg = <0 0x8000 0 0x4000>;
 +  };
 +
@@ -418,3 +427,6 @@ Subject: [PATCH] arm: dts: Add Unielec U7623 DTS
 +  status = "okay";
 +};
 +
+-- 
+2.14.1
+
-- 
2.14.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Question about mac80211.sh and MAC address generation

[Kristian Evensen]

Hi,

I have created a small tool which uses the MAC address to identify an
interface, and then collects some statistics about the interface. This
tool has worked fine for a long time, but lately I have noticed
strange values when running on some mt7620-boards. The problem turns
out to be the MAC generation algorithm in mac80211.sh, which creates a
MAC address that conflicts with the WAN interface.

All of the problematic boards have two wifi interfaces configured on
one radio, and the address_mask is 00:00:00:00:00:07. The MAC address
of eth0 (LAN) and wlan0 are the same, while the MAC of eth0.2 (WAN) is
LAN + 1. When the address for the second wifi interface is created,
the last byte of the MAC is set to b6 ^ 1. I suspect the intention
behind this calculation is to subtract index from b6. However, in my
case, the value of b6 is such that the XOR-operation causes b6 to be
increased by one, colliding with the MAC address of WAN. One example
of a "bad" b6 value is 0xb8.

What would be the proper way to work-around or fix this issue? While I
have several options wrt my tool, I am probably not the only one that
will be (or has been) hit by this behavior. Thus, some change to the
MAC generation might be desirable.

My current system-wide work-around is to also set the LA bit of b1,
which prevents a collision on all my devices. However, I am not sure
if that is acceptable, as you loose one valid MAC address.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] mediatek: Add support for the UniElec U7623-02

[Kristian Evensen]

Hi Pavel,

On Tue, Jul 3, 2018 at 8:20 PM, Pavel Ivanov  wrote:
> Hi,  Kristian !
> In your instructions for the firmware U7623-02, you write about
> repartitioning emmc (tftpboot $ {loadaddr} ).
> Sorry, i do not understand where I should take the mbr file?

You need to create the mbr yourself. I have attached the small script
I use to create the mbr for my device. The only thing you need to do
is to set SECTORS to the number of sectors on your device (the value
in the script is correct for the 8GB eMMC). You might also want to
change the location of OUTFILE, as the script creates a (temporary)
file of the same size as the eMMC on your U7623. I tried to wrap my
head around ptgen, so that the mbr can be created during the build,
but I didn't quite manage to get the partitions aligned the way I want
to. I will give it another go this week, so that we can remove, or at
least simplify, this step :)

BR,
Kristian


create_u7623_mbr.sh
Description: application/shellscript
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] mediatek: Add support for the UniElec U7623-02

[Kristian Evensen]

This commit adds support for the MT7623A-based UniElec U7623-02 router,
with eMMC storage and 512MB RAM. The router can be delivered with NAND
Flash and more memory, but I only have access to the one configuration.
The DTS is structured in such a way that adding support for
more/different storage/memory should be straight forward.

The device has the following specifications:

* MT7623A (quad-core, 1.3 GHz)
* 512MB RAM (DDR3)
* 8GB storage (eMMC 4.5)
* 2x normal miniPCIe slots
* 1x miniPCIe slot that is connected via an internal USB OTG port
* 5x 1Gbps Ethernet (MT7530 switch)
* 1x UART header
* 1x USB 3.0 port
* 1x SATA 3.0
* 1x 40P*0.5mm FPC for MIPI LCD
* 1x SIM slot
* 12x LEDs (2 GPIO controlled)
* 1x reset button
* 1x DC jack for main power (12V)

The following has been tested and is working:
* Ethernet switch
* miniPCIe slots (tested with Wi-Fi cards)
* USB 3.0 port
* sysupgrade
* reset button

Not working:
* The miniPCIe connected via USB OTG. For the port to work, some MUSB
glue must be added. I am currently in the process of porting the glue
from the vendor SDK.

Not tested:
* SATA 3.0
* MIPI LCD

Installation:

The board ships with u-boot, and the first installation needs to be done
via the bootloader using tftp. Step number one is to update the MBR of
the eMMC, as the one that ships with the device is broken. Since the
device can ship with different storage sizes, I will not provide the
exact steps for creating a valid MBR. However, I have made some
assumptions about the disk layout - there must be one 8MB recovery
partition (FAT32) and a partition for the rootfs (Linux).

The board loads the kernel from block 0xA00 (2560) and I have reserved
32MB for the kernel (65536 blocks). I have aligned the partitions on the
erase block size (4096 byte), so the recovery partition must start on
block 69632 and end on 86016 (16385 sectors). The rootfs is assumed to
start on sector 90112.

In order to install the mbr, you run the following commands from the
u-boot command line:

* tftpboot ${loadaddr} 
* mmc device 0
* mmc write ${loadaddr} 0x00 1

Run the following commands to install + boot OpenWRT:

* tftpboot ${loadaddr} 
openwrt-mediatek-mt7623-7623a-unielec-u7623-02-emmc-512m-squashfs-sysupgrade-emmc.bin.gz
* run boot_wr_img
* run boot_rd_img
* bootm

Recovery:

In order to recover the router, you need to follow the installation
steps above (no need to replace MBR).

Notes:

* F2FS is used as the overlay filesystem.

* The device does not ship with any valid MAC address, so a random
address has to be generated. As a work-around, I write the initial
random MAC to a file on the recovery partition. The MAC of the WAN
interface is set to the MAC-address contained in this file on each boot,
and the address of the LAN-interfaces are WAN + 1. The MAC file is kept
across sysupgrade/firstboot.

My approach is slightly different than what the stock image does. The
first fives bytes of the MAC addresses in the stock image are static,
and then the last byte is random. I believe it is better to create fully
random MAC addresses.

* In order to support the miniPCIe-slots, I needed to add missing
pcie-nodes to mt7623.dtsi. The nodes are just c from the upstream
dtsi.

* One of the USB3.0 phys (u3phy2) on the board can be used as either USB
or PCI, and one of the wifi-cards is connected to this phy. In order to
support switching the phy from USB to PCI, I needed to patch the
phy-driver. The patch is based on a rejected (at least last time I
checked) PCI-driver submitted to the linux-mediatek mailing list.

* The eMMC is configured to boot from the user area, and according to
the data sheet of the eMMC this value can't be changed.

* I tried to structure the MBR more nicely and use for example a
FAT32-parition for the kernel, so that we don't need to write/read from
some offset. The bootloader does not support reading from
FAT32-paritions. While the command (fatload) is there, it just throws an
error when I try to use it.

* I will submit and hope to get the DTS for the device accepted
upstream. If and when that happens, I will update the patches
accordingly.

Signed-off-by: Kristian Evensen 
---
 .../mediatek/base-files/etc/board.d/02_network |  19 +-
 .../base-files/lib/preinit/07_set_iface_mac|  47 +++
 .../mediatek/base-files/lib/preinit/79_move_config |  19 +
 .../mediatek/base-files/lib/upgrade/platform.sh|  47 ++-
 target/linux/mediatek/image/Makefile   |  10 +
 target/linux/mediatek/image/gen_mt7623_emmc_img.sh |  18 +
 target/linux/mediatek/image/mt7623.mk  |  11 +
 target/linux/mediatek/mt7623/config-4.14   |  12 +-
 ...225-arm-dts-Add-missing-mt7623-pcie-nodes.patch | 128 ++
 .../0226-phy-phy-mtk-tphy-Add-hifsys-support.patch |  71 
 .../0227-arm-dts-Add-Unielec-U7623-DTS.patch   | 431 +
 11 files changed, 805 insertions(+), 8 deletions(-)
 create mode 100644 
target/linux/mediatek/base-files/lib/preinit/07_set_iface_mac
 create

Re: [OpenWrt-Devel] [PATCH] ramips: Fix pcie interrupt mapping for ZBT WE1326

[Kristian Evensen]

Hi,

On Tue, May 29, 2018 at 9:21 PM, Kristian Evensen
 wrote:
> +   interrupt-map = <0x1 0 0 1  GIC_SHARED 24 
> IRQ_TYPE_LEVEL_HIGH>,
> +   <0x2 0 0 1  GIC_SHARED 25 
> IRQ_TYPE_LEVEL_HIGH>;
> +

Now that the offending commit has been reverted, this patch can be
ignored. However, I thought I should provide some context on this
change, as the recent discussions on the forum triggered me to do a
more thorough investigation of what actually went wrong. Any feedback,
or plain "YOU ARE WRONG", are very much welcome as I am not very
experience with dts, setting up pci and interrupts, etc.

Before commit 5f7396ebef09, the IRQ was set inside a large if-clause
(removed by the mentioned commit). The wifi radios on the 1326 are on
PCIe bus 1, slot 0 (mt76x2) and bus 2, slot 1 (mt7603). When PCIe is
about to be enabled, pcie_link_status is six for both radios. The
RALINK_INT_PCIE-values map directly to interrupts specified for PCIe
in the dtsi-file. I.e., RALINK_INT_PCIE0 is GIC_SHARED 4, PCIE1 is 24
and PCIE2 is 25. Before 5f7396ebef09, the IRQ for mt76x2 was always
set to PCIE1 (24) and mt7603 to PCIE2 (25). /proc/interrupts looks as
follows on a working WE1326:

24: 2792 0 0 0 MIPS GIC 31 mt76x2e
25: 13123 0 0 0 MIPS GIC 32 mt7603e

The hardware interrupt numbers are calculated by doing
GIC_SHARED_HWIRQ_BASE + x (where X is either 4, 24 or 25).
GIC_SHARED_HWIRQ_BASE is defined as GIC_NUM_LOCAL_INTRS, which is
seven. This is why we see GIC 31 and 32. See
/drivers/irqchip/irq-mips-gic.c and /arch/mips/include/asm/mips-gic.h
in the kernel sources for more details about the calculations, values,
etc..

After commit 5f7396ebef09, the static IRQ assigned for the given
bus/slot combos are removed and the IRQ values from the DTS are used
directly. A consequence of this is that the first pci device (mt76x2)
in the 1326 is incorrectly assigned IRQ 11. /proc/interrupts after
5f7396ebef09 looks as follows:

24: 0 0 0 0 MIPS GIC 11 mt76x2e

The correct interrupts should be as above. I.e, mt76x2 should have IRQ
31 (GIC_SHARED 24) and mt7603 IRQ 32 (GIC_SHARED 25). By applying my
patch and thus update the interrupt map, the correct interrupt mapping
was restored. /proc/interrupts looks as follows:

23: 23 0 0 0 MIPS GIC 32 mt7603e
24: 3010 0 0 0 MIPS GIC 31 mt76x2e

In order to confirm that the IRQ-mapping on the WE1326 are different
from (some) other mt7621-devices, I checked the interrupt mapping on
the ZBT WG3526 (which worked before and after commit). It looks as
follows:

23: 84765 0 0 0 MIPS GIC 11 mt7603e
24: 27389 0 0 0 MIPS GIC 31 mt76x2e

I.e., mt7603 (first pci device) is GIC_SHARED 4 and mt76x2 GIC_SHARED
24. The paths to the pci-devices are the same on both WE1326 and
WG3526 (:01:00.0 and :02:00.0).

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Wifi on ZBT-WE1326 broken after commit 5f7396ebef09

[Kristian Evensen]

Hi,

On Tue, May 29, 2018 at 10:49 PM, Karl Palsson  wrote:
> There were a few people on this today it seems :)

Great!

> There's a patch at the bottom of that from mangix/neheb that
> removes from overrides that just set 0s, and that fixed it for my
> we1326

Yes, I saw the patch and made the change manually to my DTS before I
started looking into the interrupt mapping. Using the default register
from the dtsi had no effect on my device, i.e., wifi was still broken.
However, on my device, both wifi radios did not work. While I could
see one of the wlan-interfaces being created (don't remember if it was
2.4 or 5), it didn't work properly. Wifi only started working after I
updated the interrupt mapping to match the IRQ I saw pre-5f7396ebef09.
I also received some emails from other people were the interrupt
matching fixed the wifi one the we1326.

I should point out that I am not 100% sure that my patch/solution is
correct, I am still very much a beginner when it comes to DTS',
hardware, etc. So any feedback would be very much welcome.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: Fix pcie interrupt mapping for ZBT WE1326

[Kristian Evensen]

Commit 5f7396ebef09 ("ramips: improve interrupt mapping") changed how
pcie interrupts are mapped for mt7621. The default interrupt mapping in
mt7621.dtsi is incorrect for the ZBT WE1326, causing wifi not to work.
This commit updates the WE1326 DTS with the correct interrupt mapping,
restoring wifi.

Signed-off-by: Kristian Evensen 
---
 target/linux/ramips/dts/ZBT-WE1326.dts | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/target/linux/ramips/dts/ZBT-WE1326.dts 
b/target/linux/ramips/dts/ZBT-WE1326.dts
index 6cbab66307..72707192a2 100644
--- a/target/linux/ramips/dts/ZBT-WE1326.dts
+++ b/target/linux/ramips/dts/ZBT-WE1326.dts
@@ -84,6 +84,9 @@
  {
status = "okay";
 
+   interrupt-map = <0x1 0 0 1  GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>,
+   <0x2 0 0 1  GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>;
+
pcie0 {
mt76@0,0 {
reg = <0x 0 0 0 0>;
-- 
2.14.1


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Wifi on ZBT-WE1326 broken after commit 5f7396ebef09

[Kristian Evensen]

Hello,

On Tue, May 29, 2018 at 5:24 PM, Kristian Evensen
 wrote:
> Carrying a local revert of the commit in question is always a
> possibility (and does not seem to have any unintentional
> side-effects), but I would rather try to fix the problem properly.
> Does anyone have any suggestions on where to look?

Banging my head in the wall for some hours seems to have resulted in a solution.

The default PCIe interrupt mapping in mt7621.dtsi is wrong for WE1326.
After taking a look at which IRQs were set up before commit
5f7396ebef09, I noticed that the IRQs in mt7621.dtsi. After adding the
following to the pcie-node of ZBT-WE1326.dts, wifi is working fine:

interrupt-map = <0x1 0 0 1  GIC_SHARED 24 IRQ_TYPE_LEVEL_HIGH>,
 <0x2 0 0 1  GIC_SHARED 25 IRQ_TYPE_LEVEL_HIGH>;

I will prepare and submit a patch.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

[OpenWrt-Devel] Wifi on ZBT-WE1326 broken after commit 5f7396ebef09

[Kristian Evensen]

Hi,

Some days ago I pulled master, built an image and installed it on my
ZBT-WE1326 router. After installing the image, I noticed that wifi is
broken. When looking at dmesg, mt76 reports:

[   14.479853] mt76x2e :01:00.0: MCU message 1 (seq 1) timed out

I initially suspected mt76, but wifi turned out to work fine on other
devices using the mt76-driver (like the ZBT WG3526). I then started a
bisect, and I found out that 5f7396ebef09 ("ramips: improve interrupt
mapping") is the bad commit. Starting from this commit, wifi on the
WE1326 does not work any more.

Since WE1326 and WG3526 is very similar (or supposed to be at least),
I tried to make the DTS' (more) in sync. When I have seen the "MCU ...
timed out" message before, it has usually been because the pinctrl
group was missing entry. However, making the group of the WE1326 match
that of WG3526 had no effect. I also tried to enable the all the other
possible group entries, but no change.

Carrying a local revert of the commit in question is always a
possibility (and does not seem to have any unintentional
side-effects), but I would rather try to fix the problem properly.
Does anyone have any suggestions on where to look?

Thanks in advance for any help,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Kristian Evensen]

Hi,

(Accidentally hit send)

On Fri, May 25, 2018 at 7:06 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
>> I know how to fix the issue by recovery, however, from the responses
>> in the topic on the Lede forum it seems more people are running into
>> this issue. This definitely needs to be fixed before a 18.06 release.
>> Is there someone with a mt7621 device that can reproduce the problem,
>> and that has serial access? We might be able to figure out what is
>> going wrong.

I kept looking into this and instrumented /lib/upgrade/stage2. I added
some output showing which processes were left for each iteration of
the loop, as well as when "Failed to kill ..." hits. It seems that
hostapd, for some reason, takes unexpectedly long to die:

Sending TERM to remaining processes ... loop limit 10
logd
rpcd
netifd
odhcpd
crond
ntpd
nginx
nginx
ubusd
dnsmasq
sh
sh
sh
sshd
sleep
sh
hostapd
hostapd
rsync
ssh
sleep

[  115.583843] device wlan0 left promiscuous mode
[  115.588436] br-lan: port 3(wlan0) entered disabled state
[  115.594261] device wlan1 left promiscuous mode
[  115.598798] br-lan: port 2(wlan1) entered disabled state
Sending KILL to remaining processes ... loop limit 10
hostapd
loop limit 9
hostapd
loop limit 8
hostapd
loop limit 7
hostapd
loop limit 6
hostapd
loop limit 5
hostapd
loop limit 4
hostapd
loop limit 3
hostapd
loop limit 2
hostapd
loop limit 1

Failed to kill all processes.
  PID USER   VSZ STAT COMMAND
1 root   992 S/sbin/upgraded /tmp/firmware.bin . /lib/functions.sh
2 root 0 SW   [kthreadd]
3 root 0 IW   [kworker/0:0]
4 root 0 IW<  [kworker/0:0H]
5 root 0 IW   [kworker/u8:0]
6 root 0 IW<  [mm_percpu_wq]
7 root 0 SW   [ksoftirqd/0]
8 root 0 IW   [rcu_sched]
9 root 0 IW   [rcu_bh]
   10 root 0 SW   [migration/0]
   11 root 0 SW   [cpuhp/0]
   12 root 0 SW   [cpuhp/1]
   13 root 0 SW   [migration/1]
   14 root 0 SW   [ksoftirqd/1]
   15 root 0 IW   [kworker/1:0]
   16 root 0 IW<  [kworker/1:0H]
   17 root 0 SW   [cpuhp/2]
   18 root 0 SW   [migration/2]
   19 root 0 SW   [ksoftirqd/2]
   20 root 0 IW   [kworker/2:0]
   21 root 0 IW<  [kworker/2:0H]
   22 root 0 SW   [cpuhp/3]
   23 root 0 SW   [migration/3]
   24 root 0 SW   [ksoftirqd/3]
   25 root 0 IW   [kworker/3:0]
   26 root 0 IW<  [kworker/3:0H]
   27 root 0 IW   [kworker/u8:1]
   34 root 0 IW   [kworker/u8:2]
   65 root 0 IW   [kworker/0:1]
   66 root 0 IW   [kworker/3:1]
   67 root 0 IW   [kworker/2:1]
  136 root 0 IW   [kworker/1:1]
  137 root 0 SW   [oom_reaper]
  138 root 0 IW<  [writeback]
  140 root 0 IW<  [crypto]
  142 root 0 IW<  [kblockd]
  157 root 0 IW   [kworker/u8:3]
  177 root 0 IW<  [watchdogd]
  201 root 0 SW   [kswapd0]
  233 root 0 IW<  [pencrypt]
  262 root 0 IW<  [pdecrypt]
  295 root 0 SW   [spi0]
  353 root 0 IW<  [ipv6_addrconf]
  362 root 0 IW<  [kworker/1:1H]
  363 root 0 IW<  [kworker/0:1H]
  365 root 0 IW<  [kworker/3:1H]
  366 root 0 IW<  [kworker/2:1H]
  416 root 0 IW   [kworker/1:2]
  417 root 0 IW   [kworker/0:2]
  457 root 0 SWN  [jffs2_gcd_mtd6]
  575 root 0 IW   [kworker/2:2]
  869 root 0 IW<  [cfg80211]
 1842 root 0 IW   [kworker/3:2]
 7535 root  1328 S/bin/sh /lib/upgrade/stage2 /tmp/firmware.bin . /lib
 7547 root  1184 R/bin/ps
sysupgrade abort[  124.152193] reboot: Restarting system
ed with return code: 256

With a working update, KILL usually looks like this:
Sending KILL to remaining processes ... loop limit 10
hostapd
hostapd
celerway_wd
loop limit 9
hostapd
hostapd
loop limit 8
hostapd
hostapd
loop limit 7
hostapd
hostapd
loop limit 6
hostapd
hostapd
loop limit 5
hostapd
hostapd
loop limit 4
hostapd
loop limit 3

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Kristian Evensen]

Hi,

On Fri, May 25, 2018 at 7:06 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
>> I know how to fix the issue by recovery, however, from the responses
>> in the topic on the Lede forum it seems more people are running into
>> this issue. This definitely needs to be fixed before a 18.06 release.
>> Is there someone with a mt7621 device that can reproduce the problem,
>> and that has serial access? We might be able to figure out what is
>> going wrong.

I kept looking into this and instrumented /lib/upgrade/stage2. I added
some output showing which processes were left for each iteration of
the loop, as well as when "Failed to kill ..." hits. It seems that
hostapd, for some time, takes unexpectedly long to close:

Sending TERM to remaining processes ... loop limit 10
logd
rpcd
netifd
odhcpd
crond
ntpd
nginx
nginx
ubusd
dnsmasq
sh
sh
sh
sshd
sleep
sh
hostapd
hostapd
rsync
ssh
sleep

[  115.583843] device wlan0 left promiscuous mode
[  115.588436] br-lan: port 3(wlan0) entered disabled state
[  115.594261] device wlan1 left promiscuous mode
[  115.598798] br-lan: port 2(wlan1) entered disabled state
Sending KILL to remaining processes ... loop limit 10
hostapd
loop limit 9
hostapd
loop limit 8
hostapd
loop limit 7
hostapd
loop limit 6
hostapd
loop limit 5
hostapd
loop limit 4
hostapd
loop limit 3
hostapd
loop limit 2
hostapd
loop limit 1

Failed to kill all processes.
  PID USER   VSZ STAT COMMAND
1 root   992 S/sbin/upgraded /tmp/firmware.bin . /lib/functions.sh
2 root 0 SW   [kthreadd]
3 root 0 IW   [kworker/0:0]
4 root 0 IW<  [kworker/0:0H]
5 root 0 IW   [kworker/u8:0]
6 root 0 IW<  [mm_percpu_wq]
7 root 0 SW   [ksoftirqd/0]
8 root 0 IW   [rcu_sched]
9 root 0 IW   [rcu_bh]
   10 root 0 SW   [migration/0]
   11 root 0 SW   [cpuhp/0]
   12 root 0 SW   [cpuhp/1]
   13 root 0 SW   [migration/1]
   14 root 0 SW   [ksoftirqd/1]
   15 root 0 IW   [kworker/1:0]
   16 root 0 IW<  [kworker/1:0H]
   17 root 0 SW   [cpuhp/2]
   18 root 0 SW   [migration/2]
   19 root 0 SW   [ksoftirqd/2]
   20 root 0 IW   [kworker/2:0]
   21 root 0 IW<  [kworker/2:0H]
   22 root 0 SW   [cpuhp/3]
   23 root 0 SW   [migration/3]
   24 root 0 SW   [ksoftirqd/3]
   25 root 0 IW   [kworker/3:0]
   26 root 0 IW<  [kworker/3:0H]
   27 root 0 IW   [kworker/u8:1]
   34 root 0 IW   [kworker/u8:2]
   65 root 0 IW   [kworker/0:1]
   66 root 0 IW   [kworker/3:1]
   67 root 0 IW   [kworker/2:1]
  136 root 0 IW   [kworker/1:1]
  137 root 0 SW   [oom_reaper]
  138 root 0 IW<  [writeback]
  140 root 0 IW<  [crypto]
  142 root 0 IW<  [kblockd]
  157 root 0 IW   [kworker/u8:3]
  177 root 0 IW<  [watchdogd]
  201 root 0 SW   [kswapd0]
  233 root 0 IW<  [pencrypt]
  262 root 0 IW<  [pdecrypt]
  295 root 0 SW   [spi0]
  353 root 0 IW<  [ipv6_addrconf]
  362 root 0 IW<  [kworker/1:1H]
  363 root 0 IW<  [kworker/0:1H]
  365 root 0 IW<  [kworker/3:1H]
  366 root 0 IW<  [kworker/2:1H]
  416 root 0 IW   [kworker/1:2]
  417 root 0 IW   [kworker/0:2]
  457 root 0 SWN  [jffs2_gcd_mtd6]
  575 root 0 IW   [kworker/2:2]
  869 root 0 IW<  [cfg80211]
 1842 root 0 IW   [kworker/3:2]
 7535 root  1328 S/bin/sh /lib/upgrade/stage2 /tmp/firmware.bin . /lib
 7547 root  1184 R/bin/ps
sysupgrade abort[  124.152193] reboot: Restarting system
ed with return code: 256

With a working update, KILL usually looks like this:


BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] 18.06 Bug: Baby Jumbo Frames on mt7621

[Kristian Evensen]

Hi,

> I know how to fix the issue by recovery, however, from the responses
> in the topic on the Lede forum it seems more people are running into
> this issue. This definitely needs to be fixed before a 18.06 release.
> Is there someone with a mt7621 device that can reproduce the problem,
> and that has serial access? We might be able to figure out what is
> going wrong.

I am seeing the same on my mt7621-based devices. It seems that upgrade
works roughly every second time. Here is output from serial one
sysupgrade that went wrong (i.e., no effect):

Sending TERM to remaining processes ... logd rpcd netifd odhcpd crond
hostapd ntpd hostapd nginx nginx dnsmasq ubusd sh sh sh sh sshd [
416.897350] device wlan0 left promiscuous mode
[  416.902098] br-lan: port 2(wlan0) entered disabled state
ssh [  416.915527] device wlan1 left promiscuous mode
[  416.920286] br-lan: port 3(wlan1) entered disabled state
ssh sleep sleep sleep
Sending KILL to remaining processes ... hostapd chostapd hostapd
hostapd hostapd hostapd hostapd hostapd hostapd /lib/upgrade/stage2:
line 132: can't open /proc/3469/cmdline: no such file

Failed to kill a[  420.497042] reboot: Restarting system
ll processes.
sysupgrade aborted with return code: 256

-Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

Hi,

On Tue, May 22, 2018 at 10:33 PM, Rosen Penev  wrote:
> Looks like it's this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39
>
> Please try reverting. Unfortunately I don't have mt7620 hardware so I
> can't test. Based on the comment, the issue should be fixed elsewhere.

I saw that you had already reverted this commit on the master-branch.
After commit 048e41f6496697863cc7d73ab95fa89a6ddf2470, GPIO on my
mt7620 device works fine again. Thanks for figuring this out and
fixing the problem so fast.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

On Wed, May 23, 2018 at 4:09 AM, Andrey Jr. Melnikov
<temnota...@gmail.com> wrote:
> In gmane.comp.embedded.lede.devel Rosen Penev <ros...@gmail.com> wrote:
>> On Tue, May 22, 2018 at 7:45 AM, Kristian Evensen
>> <kristian.even...@gmail.com> wrote:
>> > Hi,
>> >
>> > On Tue, May 22, 2018 at 4:33 PM, John Crispin <j...@phrozen.org> wrote:
>> >> what exactly is the issue ? breaking compat means that rosen either needs 
>> >> to
>> >> fix the regression or we need to revert the patch.
>> >
>> > The issue I saw is that writing to GPIO has no effect. On my device
>> > (mt7620-based), I can control the power to the two mini-pcie slots by
>> > writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit
>> > "ramips: mmc: Sync with
>> > staging driver", writing to these two files have no effect. I.e., I
>> > can no longer control the power.
>> Looks like it's this commit:
>> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39
>
>> Please try reverting. Unfortunately I don't have mt7620 hardware so I
>> can't test. Based on the comment, the issue should be fixed elsewhere.
> This commit removed programming SDXC_MODE register to GPIO mode and nothing
> more.
> So - fix your device dts, add nd_sd to gpio group.

nd_sd is already part of the gpio group, so then I guess the change
linked to by Rosen is not relevant in my case.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

Hi,

On Tue, May 22, 2018 at 1:33 PM, Rosen Penev  wrote:
> Looks like it's this commit:
> https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/drivers/staging/mt7621-mmc?h=next-20180517=b734735fcaca60e8f07b040cd8a700f6fabe5b39
>
> Please try reverting. Unfortunately I don't have mt7620 hardware so I
> can't test. Based on the comment, the issue should be fixed elsewhere.

Unless anyone beats me to it, I can test this on Friday or during the weekend.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

Hi,

On Tue, May 22, 2018 at 4:33 PM, John Crispin  wrote:
> what exactly is the issue ? breaking compat means that rosen either needs to
> fix the regression or we need to revert the patch.

The issue I saw is that writing to GPIO has no effect. On my device
(mt7620-based), I can control the power to the two mini-pcie slots by
writing to /sys/class/gpio/power_pcie{1,2}/value. After the commit
"ramips: mmc: Sync with
staging driver", writing to these two files have no effect. I.e., I
can no longer control the power.

I see I used the wrong has in my original email, the correct sha of
the commit is fec205f6544a.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

On Sun, May 20, 2018 at 10:26 PM, Rosen Penev  wrote:
>> Bisecting further is hard, since the
>> commit is a combination of (a lot of) clean-up and some functional
>> changes.
> Changes can be viewed on the linux-next tree. It should be as simple
> as dropping in the relevant files to the files-4.14 directory.
>
>> Would it be possible to revert the commit and split it in two
>> parts (clean-up + functional)? Then it should be easier to figure out
>> what is wrong.
> I'm torn on this. The long term solution is to migrate to the mainline
> mtk-sd driver (which is just a newer version of this one). The new
> 18.06 release does not contain this patch.

I agree that using the mainline driver is ideal. This email was meant
more as a notification that the commit creates issues for some
devices. I didnt test, but I guess that my LEDs are also broken, since
some are also controlled using GPIO. For me, reverting the commit
locally works fine and I can carry that locally.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] Broken GPIO on MT7620 after commit 34ca34b32b02

[Kristian Evensen]

Hello,

When building and testing nightly on an MT7620-device I have (the
Sanlinking D240), I noticed that changing the state of the two
exported pins (45 and 46) had no effect. The pins are used to control
the power to the two mini-PCIe slots on the board, and the devices
connected to the slots were visible irrespective of if the pin was set
to high or low.

I bisected the problem to commit 34ca34b32b02 ("ramips: mmc: Sync with
staging driver"). Reverting the commit makes setting the pins to
low/high works as expected again. Bisecting further is hard, since the
commit is a combination of (a lot of) clean-up and some functional
changes. Would it be possible to revert the commit and split it in two
parts (clean-up + functional)? Then it should be easier to figure out
what is wrong.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

Hello,

On Wed, Apr 18, 2018 at 11:34 AM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> I will keep an eye on this router, just in case, but it seems the
> problem is gone. Thanks for fixing it so fast!

The router (WG3526) has been running fine for a while now, but after
changing configuration from client to access point (for both
interfaces) and updating I started seeing kernel oopses + reboot loops
again. The error messages is as follows:

[   30.665207] CPU 1 Unable to handle kernel paging request at virtual
address ea09a0dd, epc == 8f3a060c, ra == 8ed06fac
[   30.676034] Oops[#1]:
[   30.678341] CPU: 1 PID: 27 Comm: kworker/u8:1 Not tainted 4.14.37 #0
[   30.684852] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
[   30.690409] task: 8fce8000 task.stack: 8fce4000
[   30.694922] $ 0   :  0001 7ac0ae80 0020
[   30.700149] $ 4   : 8ec4cbc0 8ee83c20 ea099ae0 8f79f400
[   30.705373] $ 8   :  80452db0 0007 00096a93
[   30.710593] $12   :  0264 000390fa 77f5d3c0
[   30.715812] $16   : 8ec4d560 8f581000 8ee83480 8ec4cbc0
[   30.721033] $20   :   8056 fffe
[   30.726252] $24   : 0fa3 80058514
[   30.731475] $28   : 8fce4000 8fce5ce8 8057 8ed06fac
[   30.736697] Hi: 000a
[   30.739562] Lo: 6669
[   30.742470] epc   : 8f3a060c 0x8f3a060c
[   30.746401] ra: 8ed06fac sta_set_sinfo+0xcc/0xbb0 [mac80211]
[   30.752380] Status: 11007c03 KERNEL EXL IE
[   30.756561] Cause : 4088 (ExcCode 02)
[   30.760550] BadVA : ea09a0dd
[   30.763418] PrId  : 0001992f (MIPS 1004Kc)
[   30.767492] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[   30.838554]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_table
[   30.909546]  ip_set_hash_netport ip_set_hash_netnet ip_set_hash_net
ip_set_hash_netportnet ip_set_hash_mac ip_set_hash_ipportnet
ip_set_hash_ipportip ip_set_hash_ipport ip_set_hash_ipmark
ip_set_hash_ip ip_sd
[   30.979947]  ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   30.989345] Process kworker/u8:1 (pid: 27, threadinfo=8fce4000,
task=8fce8000, tls=)
[   30.997742] Stack : 0200  8fce5d78  8fce5d78
80081240 8f79f400 8f581000
[   31.006092] 8ee83480 8ec4cbc0 8f581130  8056
fffe 8057 8ed06fac
[   31.014443]  8f581000 8fc06000 8ee834ac 8f581000
8ec4cbc0 8f581000 8f79f400
[   31.022793] 8ee83480 8ee834ac 8ec4cbc0  8056
8ed07a10 8f148a80 8007be74
[   31.031143]   8fce5d70 8fce5d70 
8f581000 8fc06000 8ed07ac0
[   31.039491] ...
[   31.041940] Call Trace:
[   31.044386] [<8f3a060c>] 0x8f3a060c
[   31.047866] Code: 000630c0  02063021  94f40002 <90d205fd> 00e0b025
1682  3253  2414001f  96d50004
[   31.057611]
[   31.059362] ---[ end trace 7868a781b307fb50 ]---
[   31.068983] Kernel panic - not syncing: Fatal exception
[   31.076144] Rebooting in 3 seconds..

I will try to compile an image with KALLMSYS and see if I can
reproduce the issue. My firmware is based on latest nightly.

BR,
Kristian

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
http://lists.infradead.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] x86: Add APU3 reference to x86 board.d

[Kristian Evensen]

Hi,

On Sat, Apr 21, 2018 at 2:58 AM, Philip Prindeville
 wrote:
> Looks okay to me.

Great!

> Are the cases stenciled with the port #’s?

No, there are no markings on the case.

-Kristian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] x86: Add APU3 reference to x86 board.d

[Kristian Evensen]

On Thu, Mar 15, 2018 at 1:30 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> There is a new APU-model available, APU3. The device is configured in
> the same way as the APU1 and APU2, so the same LED/network setup can be
> used.
>
> I considered changing the case to pc-engines-apu*, but I chose to follow
> the existing pattern and add the full board name.

Ping on this patch :) Perhaps it should have been sent to lede-dev instead?

-Kristian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

Hi,

On Tue, Apr 17, 2018 at 3:34 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> Thanks, great. I just started building a new image for my router, will
> test and let you know if I still see the issue.

I think I have finished my testing, at least for now, and it seems the
problem is fixed. I compiled an image with the latest changes to mt76,
installed the image on one of my WG3526-routers showing the issue,
configured both radios as clients and updated the router ~10 times,
rebooted, etc. I did not see the crash, wifi was rock solid. I then
"updated" to the older image without the latest changes and the oops
appeared right away.

I will keep an eye on this router, just in case, but it seems the
problem is gone. Thanks for fixing it so fast!

BR,
Kristian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

On Tue, Apr 17, 2018 at 2:56 PM, Felix Fietkau <n...@nbd.name> wrote:
> On 2018-04-17 13:50, Kristian Evensen wrote:
>> This is with the same image as last time (commit
>> f6e6eadc99c6274207f8f2ebc739063549959a1f) and configuration (radios
>> used as clients). I see that mt76 has been updated during the weekend
>> so I will go ahead and compile a new image with the latest updates.
> I'm about to push another update in a minute. Please wait for that and
> test it. I fixed some more issues in the code.

Thanks, great. I just started building a new image for my router, will
test and let you know if I still see the issue.

BR,
Kristian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Wifi-related kernel-oops on mt7621 after 4.14 update

[Kristian Evensen]

Hi,

On Thu, Apr 12, 2018 at 3:28 PM, Kristian Evensen
<kristian.even...@gmail.com> wrote:
> Thanks for the pointer. I compiled a new image KALLSYMS, but now I am
> not able to reproduce the error. Perhaps there was something dirty in
> my build directory. I will keep the image KALLSYMS on the routers and
> keep checking for the error.

The error came back after I updated my router again. Here are the
oops'es with KALLMSYS enabled:

[   36.714334] CPU 1 Unable to handle kernel paging request at virtual
address f32f0c10, epc == 8f391304, ra == 8f391304
[   36.724966] Oops[#1]:
[   36.727246] CPU: 1 PID: 33 Comm: kworker/u8:2 Tainted: GW
4.14.32 #0
[   36.734949] Workqueue: phy1 ieee80211_ibss_leave [mac80211]
[   36.740523] task: 8fd48000 task.stack: 8fd36000
[   36.745037] $ 0   :  0001 000e 0001
[   36.750270] $ 4   : 8f37957c   
[   36.755506] $ 8   :  80452970 0001 00122121
[   36.760726] $12   :   0010 77ec6230
[   36.765946] $16   : 8f37957c 8fd37d58 f32f0c10 94573690
[   36.771173] $20   : 0001 0040 00ff 8f378bc0
[   36.776394] $24   : 10d9 8f391218
[   36.781615] $28   : 8fd36000 8fd37d10  8f391304
[   36.786837] Hi: 969d
[   36.789701] Lo: 0110
[   36.792603] epc   : 8f391304 mt76_get_survey+0xec/0x31c [mt76]
[   36.798417] ra: 8f391304 mt76_get_survey+0xec/0x31c [mt76]
[   36.804220] Status: 11007c03 KERNEL EXL IE
[   36.808399] Cause : 4088 (ExcCode 02)
[   36.812389] BadVA : f32f0c10
[   36.815257] PrId  : 0001992f (MIPS 1004Kc)
[   36.819331] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio rt2x00lib
rndis_host qmi_wwan ppp_generic nf_nat_pptp nf_conntrack_pptp
nf_conntrack_ipv6p
[   36.890390]  nf_nat_snmp_basic nf_nat_sip nf_nat_redirect
nf_nat_proto_gre nf_nat_masquerade_ipv4 nf_nat_irc nf_conntrack_ipv4
nf_nat_ipv4 nf_nat_h323 nf_nat_ftp nf_nat_amanda nf_nat nf_log_ipv4
nf_flow_tablt
[   36.961381]  ip_set_hash_netiface ip_set_hash_netport
ip_set_hash_netnet ip_set_hash_net ip_set_hash_netportnet
ip_set_hash_mac ip_set_hash_ipportnet ip_set_hash_ipportip
ip_set_hash_ipport ip_set_hash_ipmarm
[   37.032821]  ohci_hcd ehci_platform sd_mod scsi_mod ehci_hcd
gpio_button_hotplug usbcore nls_base usb_common mii
[   37.043006] Process kworker/u8:2 (pid: 33, threadinfo=8fd36000,
task=8fd48000, tls=)
[   37.051404] Stack : 0001 80051a40 81494dc0  0400
8f57c000  
[   37.059753]  8ec110dc 002f113b  8fc2a500
81494dc0  0001
[   37.068100] 814a2dc0 8fc2a614 94573690  
  
[   37.076449]     
  
[   37.084797] 000c   8ec113a0 0020
8149d2ec 814a2dc0 8fc2a500
[   37.093147] ...
[   37.095597] Call Trace:
[   37.098045] [<8f391304>] mt76_get_survey+0xec/0x31c [mt76]
[   37.103671] [<8ec110dc>]
___ieee80211_start_rx_ba_session+0x15c/0x39c [mac80211]
[   37.27] [<8ec113a0>] __ieee80211_start_rx_ba_session+0x84/0xb8 [mac80211]
[   37.118315] [<8ec1144c>] ieee80211_process_addba_request+0x78/0x8c [mac80211]
[   37.125507] [<8ec152a0>] ieee80211_ibss_leave+0x44c/0x19c8 [mac80211]
[   37.132067] Code: 2610001c  0c116236  02002025 <8e44> 3c058d4f
34a5df3b  00850019  3012  3810
[   37.141817]
[   37.143582] ---[ end trace 5af5293c693da408 ]---
[   37.151753] Kernel panic - not syncing: Fatal exception in interrupt
[   37.160354] Rebooting in 3 seconds..

[   30.252516] CPU 0 Unable to handle kernel paging request at virtual
address eb44a0d5, epc == 8ed40ba4, ra == 8ec86fac
[   30.263189] Oops[#1]:
[   30.265506] CPU: 0 PID: 33 Comm: kworker/u8:2 Tainted: GW
4.14.32 #0
[   30.273244] Workqueue: phy1 ieee80211_ibss_leave [mac80211]
[   30.278811] task: 8fd48000 task.stack: 8fd36000
[   30.283321] $ 0   :  0001 7adc6e80 
[   30.288546] $ 4   : 8f3d8bc0 8fd27c20 eb449ae0 8e03a800
[   30.293766] $ 8   :  80452970 0007 0006edf8
[   30.298985] $12   :  8ee8d0c0 0007 1dcd6501
[   30.304205] $16   : 8f3d9560 8f5b8800 8fd27480 8f3d8bc0
[   30.309425] $20   : 8e03a800  8056 fffe
[   30.314645] $24   :  
[   30.319865] $28   : 8fd36000 8fd37cf8 8056 8ec86fac
[   30.325085] Hi: 329d
[   30.327951] Lo: 010e
[   30.330849] epc   : 8ed40ba4 mt76x2_dma_cleanup+0x478/0x1128 [mt76x2e]
[   30.337408] ra: 8ec86fac sta_set_sinfo+0xcc/0xbb0 [mac80211]
[   30.343386] Status: 11008403 KERNEL EXL IE
[   30.347565] Cause : c088 (ExcCode 02)
[   30.351553] BadVA : eb44a0d5
[   30.354421] PrId  : 0001992f (MIPS 1004Kc)
[   30.358494] Modules linked in: rt2800pci rt2800mmio rt2800lib
qcserial ppp_async option usb_wwan rt2x00pci rt2x00mmio