Re: [PATCH 0/6] backport fixes and improvements for MT7530
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Hi, On Tue, May 22, 2018 at 10:33 PM, Rosen Penevwrote: > 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
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
Hi, On Tue, May 22, 2018 at 1:33 PM, Rosen Penevwrote: > 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
Hi, On Tue, May 22, 2018 at 4:33 PM, John Crispinwrote: > 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
On Sun, May 20, 2018 at 10:26 PM, Rosen Penevwrote: >> 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
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
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
Hi, On Sat, Apr 21, 2018 at 2:58 AM, Philip Prindevillewrote: > 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
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
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
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
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