Re: [OpenWrt-Devel] [PATCH v6] ath79: add support for COMFAST CF-E130N v2

2020-05-26 Thread mail 
Hi,

> Hello. I have just run-tested the patch from your tree on actual hardware - 
> the web GUI works fine, as do both internet and wireless interfaces.
> An investigation into the art partition has shown that there are four 
> sequential MAC addresses stored in memory.
> The first and the third are back-to-back, addresses 0x and 0x0006 
> respectively.
> The second one is located at 0x1002, and the fourth one is at 0x5006. I have 
> no explanation for why it is like that.
> To answer your question - it's not an exact match, but it's close to that.

That makes perfect sense, as these are the locations of the addresses in the 
calibration data.

Can you translate that into a list of addresses (you may just report the last 
one or two bytes ...) related to the locations?

0x0 aa:bb:cc:xx:xx:f1
0x6 aa:bb:cc:xx:xx:f2
etc.

How are these addresses assigned on OEM firmware (lan,wan,2g,5g)?

Best

Adrian


openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH v6] ath79: add support for COMFAST CF-E130N v2

2020-05-26 Thread Pavel Balan 
Hello. I have just run-tested the patch from your tree on actual 
hardware - the web GUI works fine, as do both internet and wireless 
interfaces.


An investigation into the art partition has shown that there are four 
sequential MAC addresses stored in memory.


The first and the third are back-to-back, addresses 0x and 0x0006 
respectively.


The second one is located at 0x1002, and the fourth one is at 0x5006. I 
have no explanation for why it is like that.


To answer your question - it's not an exact match, but it's close to that.


P.S. Thank you for catching the v5/v6 difference - or lack of thereof, 
rather.


On 2020-05-24 7:45 a.m., m...@adrianschmutzler.de wrote:

Hi,


-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of ad...@kryma.net
Sent: Freitag, 27. März 2020 04:33
To: openwrt-devel@lists.openwrt.org
Cc: Pavel Balan 
Subject: [OpenWrt-Devel] [PATCH v6] ath79: add support for COMFAST CF-
E130N v2

From: Pavel Balan 

This patch adds support for the COMFAST CF-E130N v2, an outdoor wireless
CPE with a single Ethernet port and a 802.11bgn radio.

Specifications:

  - QCA9531 SoC
  - 1x 10/100 Mbps Ethernet with PoE-in support
  - 64 MB of RAM (DDR2)
  - 16 MB of FLASH
  - 5 dBi built-in antenna
  - POWER/LAN/WLAN green LEDs
  - 4x RSSI LEDs (2x red, 2x green)
  - UART (115200 8N1) and GPIO (J9) headers on PCB

Flashing instructions:

  The original firmware is based on OpenWrt so a sysupgrade image can be
installed via the stock web GUI.

  The U-boot bootloader also contains a backup TFTP client to upload the
firmware from. Upon boot, it checks its ethernet network for the IP
192.168.1.10. Host a TFTP server and provide the image to be flashed as  file
firmware_auto.bin.

Signed-off-by: Pavel Balan 
---
Run-tested on hardware.

Changes since v5:

  Made partition@7e read-only.

  Changed IMAGE_SIZE to 7936k.

it looks like you have actually sent the v5 version of your patch again, as the 
v6-changes you report are not included. Anyway, I've added these (and a few 
others) myself and pushed the result to my staging tree here:

https://git.openwrt.org/?p=openwrt/staging/adrian.git;a=shortlog;h=refs/heads/staging

Please run this on your device and check whether everything is okay, so I can 
merge this.

Despite, I'd be interested whether the MAC address from calibration data (art 
0x1002) is actually the same as art 0x0, so we can drop mtd-mac-address from 
wmac.

Best

Adrian


---
  .../ath79/dts/qca9531_comfast_cf-e130n-v2.dts | 150
++
  .../generic/base-files/etc/board.d/01_leds|   8 +
  .../generic/base-files/etc/board.d/02_network |   1 +
  target/linux/ath79/image/generic.mk   |  10 ++
  4 files changed, 169 insertions(+)
  create mode 100644 target/linux/ath79/dts/qca9531_comfast_cf-e130n-
v2.dts

diff --git a/target/linux/ath79/dts/qca9531_comfast_cf-e130n-v2.dts
b/target/linux/ath79/dts/qca9531_comfast_cf-e130n-v2.dts
new file mode 100644
index 00..dc1e037307
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_comfast_cf-e130n-v2.dts
@@ -0,0 +1,150 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
+
+#include 
+#include 
+
+#include "qca953x.dtsi"
+
+/ {
+   compatible = "comfast,cf-e130n-v2", "qca,qca9531";
+   model = "COMFAST CF-E130N v2";
+
+   aliases {
+   serial0 = 
+   led-boot = _rssihigh;
+   led-failsafe = _rssihigh;
+   led-upgrade = _rssihigh;
+   label-mac-device = 
+   };
+
+   leds {
+   compatible = "gpio-leds";
+
+   pinctrl-names = "default";
+
+   wlan {
+   label = "cf-e130n-v2:green:wlan";
+   gpios = < 0 GPIO_ACTIVE_LOW>;
+   linux,default-trigger = "phy0tpt";
+   };
+
+   lan {
+   label = "cf-e130n-v2:green:lan";
+   gpios = < 2 GPIO_ACTIVE_LOW>;
+   };
+
+   unused {
+   label = "cf-e130n-v2:green:unused";
+   gpios = < 3 GPIO_ACTIVE_LOW>;
+   };
+
+   rssilow {
+   label = "cf-e130n-v2:red:rssilow";
+   gpios = < 11 GPIO_ACTIVE_LOW>;
+   };
+
+   rssimediumlow {
+   label = "cf-e130n-v2:red:rssimediumlow";
+   gpios = < 12 GPIO_ACTIVE_LOW>;
+   };
+
+   rssimediumhigh {
+   label = "cf-e130n-v2:green:rssimediumhigh";
+   gpios = < 14 GPIO_ACTIVE_LOW>;
+   };
+
+   led_rssihigh: rssihigh {
+   label = "cf-e130n-v2:green:rssihigh";
+   gpios = < 16 GPIO_ACTIVE_LOW>;
+   };
+   };
+
+   keys {
+   compatible = "gpio-keys";
+
+   reset {
+

Re: [OpenWrt-Devel] [PATCH 19.07] generic: fix flow table hw offload

2020-05-26 Thread John Crispin 

On 26.05.20 22:01, Petr Štetiar wrote:

From: John Crispin 

Make the driver work with recent upstream changes.

Fixes: FS#2632
Ref: https://github.com/openwrt/openwrt/pull/2815
Signed-off-by: John Crispin 
(cherry picked from commit 6786dc26a205da55ec2d9771693cdfb99e756e59)
---

thanks, feel free to commit.
Acked-by: John Crispin 

  ...w_table-support-hw-offload-through-v.patch | 33 ++-
  1 file changed, 18 insertions(+), 15 deletions(-)

diff --git 
a/target/linux/generic/pending-4.14/641-netfilter-nf_flow_table-support-hw-offload-through-v.patch
 
b/target/linux/generic/pending-4.14/641-netfilter-nf_flow_table-support-hw-offload-through-v.patch
index 93117253466b..e1b13a1ad491 100644
--- 
a/target/linux/generic/pending-4.14/641-netfilter-nf_flow_table-support-hw-offload-through-v.patch
+++ 
b/target/linux/generic/pending-4.14/641-netfilter-nf_flow_table-support-hw-offload-through-v.patch
@@ -79,7 +79,7 @@ Signed-off-by: Felix Fietkau 
   struct nf_flow_route {
  --- a/net/netfilter/nf_flow_table_hw.c
  +++ b/net/netfilter/nf_flow_table_hw.c
-@@ -19,48 +19,75 @@ struct flow_offload_hw {
+@@ -19,48 +19,77 @@ struct flow_offload_hw {
enum flow_offload_type  type;
struct flow_offload *flow;
struct nf_conn  *ct;
@@ -92,6 +92,7 @@ Signed-off-by: Felix Fietkau 
  -static int do_flow_offload_hw(struct net *net, struct flow_offload *flow,
  -   int type)
  +static void flow_offload_check_ethernet(struct flow_offload_tuple *tuple,
++  struct dst_entry *dst,
  + struct flow_offload_hw_path *path)
   {
  - struct net_device *indev;
@@ -112,7 +113,7 @@ Signed-off-by: Felix Fietkau 
   
  -	dev_put(indev);

  + memcpy(path->eth_src, path->dev->dev_addr, ETH_ALEN);
-+  n = dst_neigh_lookup(tuple->dst_cache, >src_v4);
++  n = dst_neigh_lookup(dst, >src_v4);
  + if (!n)
  + return;
   
@@ -125,6 +126,7 @@ Signed-off-by: Felix Fietkau 

  -static void flow_offload_hw_work_add(struct flow_offload_hw *offload)
  +static int flow_offload_check_path(struct net *net,
  +struct flow_offload_tuple *tuple,
++ struct dst_entry *dst,
  +struct flow_offload_hw_path *path)
   {
  - struct net *net;
@@ -138,7 +140,7 @@ Signed-off-by: Felix Fietkau 
  + return -ENOENT;
  +
  + path->dev = dev;
-+  flow_offload_check_ethernet(tuple, path);
++  flow_offload_check_ethernet(tuple, dst, path);
   
  -	net = read_pnet(>flow_hw_net);

  - ret = do_flow_offload_hw(net, offload->flow, FLOW_OFFLOAD_ADD);
@@ -166,11 +168,11 @@ Signed-off-by: Felix Fietkau 
  + /* restore devices in case the driver mangled them */
  + offload->src.dev = src_dev;
  + offload->dest.dev = dest_dev;
-+
-+  return ret;
-+}
   
  -	do_flow_offload_hw(net, offload->flow, FLOW_OFFLOAD_DEL);

++  return ret;
++}
++
  +static void flow_offload_hw_free(struct flow_offload_hw *offload)
  +{
  + dev_put(offload->src.dev);
@@ -182,7 +184,7 @@ Signed-off-by: Felix Fietkau 
   }
   
   static void flow_offload_hw_work(struct work_struct *work)

-@@ -73,18 +100,22 @@ static void flow_offload_hw_work(struct
+@@ -73,18 +102,22 @@ static void flow_offload_hw_work(struct
spin_unlock_bh(_offload_hw_pending_list_lock);
   
   	list_for_each_entry_safe(offload, next, _offload_pending, list) {

@@ -211,7 +213,7 @@ Signed-off-by: Felix Fietkau 
}
   }
   
-@@ -97,20 +128,55 @@ static void flow_offload_queue_work(stru

+@@ -97,20 +130,56 @@ static void flow_offload_queue_work(stru
schedule_work(_flow_offload_hw_work);
   }
   
@@ -220,17 +222,18 @@ Signed-off-by: Felix Fietkau 

  +{
  + struct flow_offload_hw_path src = {};
  + struct flow_offload_hw_path dest = {};
-+  struct flow_offload_tuple *tuple;
++  struct flow_offload_tuple *tuple_s, *tuple_d;
  + struct flow_offload_hw *offload = NULL;
  +
  + rcu_read_lock_bh();
  +
-+  tuple = >tuplehash[FLOW_OFFLOAD_DIR_ORIGINAL].tuple;
-+  if (flow_offload_check_path(net, tuple, ))
++  tuple_s = >tuplehash[FLOW_OFFLOAD_DIR_ORIGINAL].tuple;
++  tuple_d = >tuplehash[FLOW_OFFLOAD_DIR_REPLY].tuple;
++
++  if (flow_offload_check_path(net, tuple_s, tuple_d->dst_cache, ))
  + goto out;
  +
-+  tuple = >tuplehash[FLOW_OFFLOAD_DIR_REPLY].tuple;
-+  if (flow_offload_check_path(net, tuple, ))
++  if (flow_offload_check_path(net, tuple_d, tuple_s->dst_cache, ))
  + goto out;
  +
  + if (!src.dev->netdev_ops->ndo_flow_offload)
@@ -270,7 +273,7 @@ Signed-off-by: Felix Fietkau 
   
   	flow_offload_queue_work(offload);

   }
-@@ -119,14 +185,11 @@ static void flow_offload_hw_del(struct n
+@@ -119,14 +188,11 @@ static void flow_offload_hw_del(struct n
   {
struct flow_offload_hw *offload;
   
@@ -286,7 +289,7 @@

[OpenWrt-Devel] [PATCH 19.07] generic: fix flow table hw offload

2020-05-26 Thread Petr Štetiar 
From: John Crispin 

Make the driver work with recent upstream changes.

Fixes: FS#2632
Ref: https://github.com/openwrt/openwrt/pull/2815
Signed-off-by: John Crispin 
(cherry picked from commit 6786dc26a205da55ec2d9771693cdfb99e756e59)
---
 ...w_table-support-hw-offload-through-v.patch | 33 ++-
 1 file changed, 18 insertions(+), 15 deletions(-)

diff --git 
a/target/linux/generic/pending-4.14/641-netfilter-nf_flow_table-support-hw-offload-through-v.patch
 
b/target/linux/generic/pending-4.14/641-netfilter-nf_flow_table-support-hw-offload-through-v.patch
index 93117253466b..e1b13a1ad491 100644
--- 
a/target/linux/generic/pending-4.14/641-netfilter-nf_flow_table-support-hw-offload-through-v.patch
+++ 
b/target/linux/generic/pending-4.14/641-netfilter-nf_flow_table-support-hw-offload-through-v.patch
@@ -79,7 +79,7 @@ Signed-off-by: Felix Fietkau 
  struct nf_flow_route {
 --- a/net/netfilter/nf_flow_table_hw.c
 +++ b/net/netfilter/nf_flow_table_hw.c
-@@ -19,48 +19,75 @@ struct flow_offload_hw {
+@@ -19,48 +19,77 @@ struct flow_offload_hw {
enum flow_offload_type  type;
struct flow_offload *flow;
struct nf_conn  *ct;
@@ -92,6 +92,7 @@ Signed-off-by: Felix Fietkau 
 -static int do_flow_offload_hw(struct net *net, struct flow_offload *flow,
 -int type)
 +static void flow_offload_check_ethernet(struct flow_offload_tuple *tuple,
++  struct dst_entry *dst,
 +  struct flow_offload_hw_path *path)
  {
 -  struct net_device *indev;
@@ -112,7 +113,7 @@ Signed-off-by: Felix Fietkau 
  
 -  dev_put(indev);
 +  memcpy(path->eth_src, path->dev->dev_addr, ETH_ALEN);
-+  n = dst_neigh_lookup(tuple->dst_cache, >src_v4);
++  n = dst_neigh_lookup(dst, >src_v4);
 +  if (!n)
 +  return;
  
@@ -125,6 +126,7 @@ Signed-off-by: Felix Fietkau 
 -static void flow_offload_hw_work_add(struct flow_offload_hw *offload)
 +static int flow_offload_check_path(struct net *net,
 + struct flow_offload_tuple *tuple,
++ struct dst_entry *dst,
 + struct flow_offload_hw_path *path)
  {
 -  struct net *net;
@@ -138,7 +140,7 @@ Signed-off-by: Felix Fietkau 
 +  return -ENOENT;
 +
 +  path->dev = dev;
-+  flow_offload_check_ethernet(tuple, path);
++  flow_offload_check_ethernet(tuple, dst, path);
  
 -  net = read_pnet(>flow_hw_net);
 -  ret = do_flow_offload_hw(net, offload->flow, FLOW_OFFLOAD_ADD);
@@ -166,11 +168,11 @@ Signed-off-by: Felix Fietkau 
 +  /* restore devices in case the driver mangled them */
 +  offload->src.dev = src_dev;
 +  offload->dest.dev = dest_dev;
-+
-+  return ret;
-+}
  
 -  do_flow_offload_hw(net, offload->flow, FLOW_OFFLOAD_DEL);
++  return ret;
++}
++
 +static void flow_offload_hw_free(struct flow_offload_hw *offload)
 +{
 +  dev_put(offload->src.dev);
@@ -182,7 +184,7 @@ Signed-off-by: Felix Fietkau 
  }
  
  static void flow_offload_hw_work(struct work_struct *work)
-@@ -73,18 +100,22 @@ static void flow_offload_hw_work(struct
+@@ -73,18 +102,22 @@ static void flow_offload_hw_work(struct
spin_unlock_bh(_offload_hw_pending_list_lock);
  
list_for_each_entry_safe(offload, next, _offload_pending, list) {
@@ -211,7 +213,7 @@ Signed-off-by: Felix Fietkau 
}
  }
  
-@@ -97,20 +128,55 @@ static void flow_offload_queue_work(stru
+@@ -97,20 +130,56 @@ static void flow_offload_queue_work(stru
schedule_work(_flow_offload_hw_work);
  }
  
@@ -220,17 +222,18 @@ Signed-off-by: Felix Fietkau 
 +{
 +  struct flow_offload_hw_path src = {};
 +  struct flow_offload_hw_path dest = {};
-+  struct flow_offload_tuple *tuple;
++  struct flow_offload_tuple *tuple_s, *tuple_d;
 +  struct flow_offload_hw *offload = NULL;
 +
 +  rcu_read_lock_bh();
 +
-+  tuple = >tuplehash[FLOW_OFFLOAD_DIR_ORIGINAL].tuple;
-+  if (flow_offload_check_path(net, tuple, ))
++  tuple_s = >tuplehash[FLOW_OFFLOAD_DIR_ORIGINAL].tuple;
++  tuple_d = >tuplehash[FLOW_OFFLOAD_DIR_REPLY].tuple;
++
++  if (flow_offload_check_path(net, tuple_s, tuple_d->dst_cache, ))
 +  goto out;
 +
-+  tuple = >tuplehash[FLOW_OFFLOAD_DIR_REPLY].tuple;
-+  if (flow_offload_check_path(net, tuple, ))
++  if (flow_offload_check_path(net, tuple_d, tuple_s->dst_cache, ))
 +  goto out;
 +
 +  if (!src.dev->netdev_ops->ndo_flow_offload)
@@ -270,7 +273,7 @@ Signed-off-by: Felix Fietkau 
  
flow_offload_queue_work(offload);
  }
-@@ -119,14 +185,11 @@ static void flow_offload_hw_del(struct n
+@@ -119,14 +188,11 @@ static void flow_offload_hw_del(struct n
  {
struct flow_offload_hw *offload;
  
@@ -286,7 +289,7 @@ Signed-off-by: Felix Fietkau 
  
flow_offload_queue_work(offload);
  }
-@@ -153,12 +216,8 @@ static void __exit

[OpenWrt-Devel] [PATCH] wolfssl: use -fomit-frame-pointer to fix asm error

2020-05-26 Thread Eneas U de Queiroz 
32-bit x86 fail to compile fast-math feature when compiled with frame
pointer, which uses a register used in a couple of inline asm functions.

Previous versions of wolfssl had this by default.  Keeping an extra
register available may increase performance, so it's being restored for
all architectures.

Signed-off-by: Eneas U de Queiroz 

---
i386 builds currently fail with:
./wolfcrypt/src/asm.c:700:1: error: 'asm' operand has impossible constraints

This is because wolfssl uses all of the available register for [at
least] a couple of its fast-math inline asm functions.  The
frame-pointer uses up one of them causing the above failure.

gcc documentation indicates that -fomit-frame-pointer is used in -O1, so
it should be enabled without the flag, but this compile error indicates
otherwise.  I'm not experienced enough to know why this is happening.

There are other alternatives:
 - use -fomit-frame-pointer only for i386
 - disable asm for i386
 - disable fast-math for i386
 - patch asm.c to loosen the constraint of one of the arguments from r=
   to g= in the affected functions

The last 3 are there for completeness, I'm not really considering them.

Eneas

diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index b186a087e7..159cfbc53f 100644
--- a/package/libs/wolfssl/Makefile
+++ b/package/libs/wolfssl/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=wolfssl
 PKG_VERSION:=4.4.0-stable
-PKG_RELEASE:=1
+PKG_RELEASE:=2
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
@@ -56,7 +56,7 @@ define Package/libwolfssl/config
source "$(SOURCE)/Config.in"
 endef
 
-TARGET_CFLAGS += $(FPIC) -DFP_MAX_BITS=8192
+TARGET_CFLAGS += $(FPIC) -DFP_MAX_BITS=8192 -fomit-frame-pointer
 
 # --enable-stunnel needed for OpenSSL API compatibility bits
 CONFIGURE_ARGS += \

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

[OpenWrt-Devel] [PATCH] uboot-envtools: ath79: add Netgear WNDR4300SW

2020-05-26 Thread Stijn Segers 
Add Netgear WNDR4300SW to the list of supported boards.

Signed-off-by: Stijn Segers 
---
 package/boot/uboot-envtools/files/ath79 | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/package/boot/uboot-envtools/files/ath79 
b/package/boot/uboot-envtools/files/ath79
index aebfeca85d..928a46ca8e 100644
--- a/package/boot/uboot-envtools/files/ath79
+++ b/package/boot/uboot-envtools/files/ath79
@@ -56,7 +56,8 @@ netgear,wndr3700-v2)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x2" "0x1"
;;
 netgear,wndr3700-v4|\
-netgear,wndr4300)
+netgear,wndr4300|\
+netgear,wndr4300sw)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x4" "0x2"
;;
 qihoo,c301)
-- 
2.20.1


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

Re: [OpenWrt-Devel] [PATCH v7] ramips: add support for TRENDnet TEW-810DR

2020-05-26 Thread mail 
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Heppler, J. Scott
> Sent: Dienstag, 26. Mai 2020 03:25
> To: openwrt-de...@openwrt.org
> Subject: [OpenWrt-Devel] [PATCH v7] ramips: add support for TRENDnet
> TEW-810DR
> 
> * MediaTek MT7620A (580 Mhz)
> * 8 MB of FLASH * 64 MB of RAM
> * 2.4Ghz and 5.0Ghz radios both now functional

Drop the "both now functional"

> * 5x 10/100 Mbps Ethernet (1 WAN and 4 LAN)
> * UART header on PCB (57600 8n1)
> * Green/Orange Power LEDs illuminating a Power-Button Lens
>Green/Orange Internet LEDs GPIO controlled illuminating a Globe/Internet
> Lens
> * 3x button - wps, power and reset
> * U-boot bootloader

I'd still like to know whether there are valid MAC addresses in other flash 
locations, i.e. 0x4, 0x8004, 0x2e. The WiFi MAC addresses should only be set up 
from a separate address if absolutely necessary, and I'm not convinced that's 
necessary yet.
I haven't found any information about that on a quick look into my mail 
history, and the fact that you just ignored it for your newer patches also 
doesn't help.
Please provide that information, and if possible also the MAC address 
assignment (lan,wan,2g,5g) on vendor OS and on a device label. If it's easier 
for you, you may also just send me a dump of the factory partition to my 
private address.

Despite, while you have dropped lan LED now and added a wan LED, you still rely 
on ucidef_set_led_netdev instead of ucidef_set_led_switch. Please use the 
latter if you deal with ports on a switch.
You can also drop the "link tx rx" as this is default. Please support both 
LEDs, not just lan _or_ wan.

Finally, please note that I don't care about whether this matches any other 
device's definition. It should be correct for the device at hand, and if the 
other device deviates, then please either fix that one as well or just ignore 
it. But making support worse just for consistency with an old support isn't 
desirable IMO.

Best

Adrian

> 
> Installation:
> 
> The sysupgrade.bin image is reported to be OEM web flashed with an
> ncc_att_hwid appended.  ncc_att_hwid is a 32bit binary in the GPL Source
> download for either the TEW-810DR or DIR-810L and is located at
> source/user/wolf/cameo/ncc/hostTools.
> The invocation is: ncc_att_hwid
> -f tew-810dr-squashfs-factory.bin -a -m "TEW-810DR" -H "1.0R" -r "WW" -c
> "1.0"
> This may need to be altered if your hardware version is "1.1R".
> The image can also be directly flashed via serial tftp.
> 1.  Load *.sysupgrade.bin to your tftp server directory and rename for
> convenience.
> 2.  Set a static ip 192.168.10.100.
> 3.  NIC cable to a lan port.
> 4.  Serial connection parameters 57600,8N1 5.  Power on the TEW-810 and
> press 4 for a u-boot command line prompt.
> 6.  Verify IP's with U-Boot command "printenv".
> 7.  Adjust tftp settings if needed per the tftp documentation 8.  Boot the 
> tftp
> image to test the build.
> 9.  If the image loads, reset your server ip to 192.168.1.10 and restart
> network.
> 10. Log in to Luci, 192.168.1.1, and flash the *sysupgrade.bin image.
> 
> Summary v4 -> v5 -> v6
> 1.  Enumerated installation steps and corrected grammar.
> 2.  Added SPDX License Identifier to *.dts.
> 3.  gpio-keys-polled -> gpio-keys in *.dts.
> 4.  gpio2 0 is actually behind a Globe/Internet lens - changed to wan.
> 5.  Increased spi-max-frequency 1000 -> 5000 6.  jffs2 partition
> 0xe -> 0xf.
> 7.  _default groups dropped mdio, rgmii1, wled.
> 8.  MAC assignments mirror DIR-810L and verify in Luci.  Unchanged
> 02_network and *.dts.
> 9.  01_leds changed consistent with #4.
> 10. Removed SUPPORTED_DEVICES from image/mt7620.mk.  Note: the D-
> Link DIR-810L has the same SUPPORTED_DEVICES entry in image/mt7620.mk.
> 11. Builds/Runs on my test Device.
> 
> Summary v6 -> v7
> 1.  White space issues in  *.dts, image/mt7620.mk, 01_leds and
> 02_network;
>  spaces replaced with tabs
> 
> Signed-off-by: J. Scott Heppler 
> ---
>   .../ramips/dts/mt7620a_trendnet_tew-810dr.dts | 166
> ++
>   target/linux/ramips/image/mt7620.mk   |   9 +
>   .../mt7620/base-files/etc/board.d/01_leds |   3 +
>   .../mt7620/base-files/etc/board.d/02_network  |   4 +-
>   4 files changed, 181 insertions(+), 1 deletion(-)
>   create mode 100644 target/linux/ramips/dts/mt7620a_trendnet_tew-
> 810dr.dts
> 
> diff --git a/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> new file mode 100644
> index 00..2873b5d780
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7620a_trendnet_tew-810dr.dts
> @@ -0,0 +1,166 @@
> +//SPDX-License-Identifier: GPL-2.0-or-later OR MIT /dts-v1/;
> +
> +#include "mt7620a.dtsi"
> +
> +#include 
> +#include 
> +
> +/ {
> + compatible = "trendnet,tew-810dr", "ralink,mt7620a-soc";
> + model = "TRENDnet TEW-810DR";
> +
> + aliases {
> + led-boot = _power_green;
>

[OpenWrt-Devel] blob vs. blobmsg - simplifying & cleaning libubox API

2020-05-26 Thread Rafał Miłecki 

* Introduction *

OpenWrt heavily uses blob-s and blobmsg-s implemented in libubox. They
are used in ubus and when parsing JSON-s.

Short summary for two formats by Jo:

[14:51]  I think a blobmsg is a structure nested into a blob
[14:52]  a blob is  id_len (8 bits type (aka ID), 24 bits length) + data 
payload
[14:53]  a blobmsg follows the id_len and consists of a name_len (16bit) 
and a variable length name string
[14:53]  any payload data then follows the variable length name (32bit 
aligned)
[14:54]  I think the extra set of blobmsg_*() apis is needed to handle the 
blob attributes while somehow transparently dealing with the name TLV squeezed in 
front
[14:55]  due to that, there's different notions of "payload"
[14:55]  a blob payload is simply the data after the id_len member 
(pointing to the start of the blobmsg hdr)
[14:56]  a blobmsg payload is the actual payload after the id_len member, 
the namelen member and the variable length name


* Problem *

Some/many developers are confused regarding what do they deal with (blob
vs. blobmsg). There is single struct blob_attr that gets passed around
but it isn't clear if it contains blob or blobmsg.

Depending on blob vs. blobmsg type a correct set of API functions should
be used. E.g.
1. blob_len() vs. blobmsg_data_len()
2. blob_for_each_attr() vs. blobmsg_for_each_attr()

There are many cases where blobmsg_data() is used for blob format. It
works thanks to some extra check in the blobmsg_data().

Naming is confusing too:
1. "blobmsg" could be "namedblob" or "blob_named" or "blob_with_name"
2. blobmsg_parse() requires passing *blob* data not blobmsg data


* Cleaning API usage *

One idea for cleaning up blob(msg) dependant code was to make it always
call right functions (blob_* for blob and blobmsg_* for blobmsg). I
started looking at this but it's not that obvious.

I realized that ubus method handlers always receive struct blob_attr
that is *blob*. Some projects call blobmsg_data() and blobmsg_len() on
it that isn't 100% clean solution. Of course having blobmsg_parse() name
doesn't help.

I planned to replace all such blobmsg_data() calls with blob_data() but
then I realized that *nested* tables will actually need blobmsg_data().
Parsing fails if blobmsg data gets passed.


* Looking for ideas *

I'm looking for ideas how to simplify and clean blob(msg) API. The only
idea I have is merging blob & blogmsg APIs so all functions get aware of
both types. I suggested that but Felix pointed out it's not a good idea:

[17:12]  not sure if that makes sense, they're used differently
[17:12]  blob is indexed by id
[17:12]  in blobmsg, the id specifies the type and fields are indexed by 
name
(...)
[17:39]  well, blobmsg is a layer around blob
[17:39]  so i don't think the blob api should deal with blobmsg specifics 
directly

Any suggestions?

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

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

2020-05-26 Thread Daniel Golle 
On Tue, May 26, 2020 at 09:54:40AM +0200, Jaap Buurman wrote:
> Dear all,
> 
> The above patch has been committed for a long while in the master
> branch 
> (https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0).
> Is there any chance this could be backported to the 19.07 branch as
> well, since it's a bug-fix and not a new feature? Thanks!

Done.

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

Re: [OpenWrt-Devel] [PATCH] hostapd: add support for wifi-station and wifi-vlan sections

2020-05-26 Thread John Crispin 

On 26.05.20 10:07, Vincent Wiemann wrote:

On 25.05.20 16:46, John Crispin wrote:

With this patch applied it is possible to use multiple PSKs and VIDs on a
single BSS.


Nice! So hostapd supports different keys for different stations now?
Did you test it? This is particularly interesting for me as I wanted to
use different PSKs for different 802.11s mesh links (for trust on first use).
But as far as I could see hostapd was not able to use per-station PSKs at
that time. If yes, could you try to cover that case?

Best,

Vincent



I have only tested AP mode so far. it does not look like wpas supports 
this feature.

John

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

Re: [OpenWrt-Devel] [PATCH] hostapd: add support for wifi-station and wifi-vlan sections

2020-05-26 Thread Vincent Wiemann 
On 25.05.20 16:46, John Crispin wrote:
> With this patch applied it is possible to use multiple PSKs and VIDs on a
> single BSS.

Nice! So hostapd supports different keys for different stations now?
Did you test it? This is particularly interesting for me as I wanted to
use different PSKs for different 802.11s mesh links (for trust on first use).
But as far as I could see hostapd was not able to use per-station PSKs at
that time. If yes, could you try to cover that case?

Best,

Vincent

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

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

2020-05-26 Thread Jaap Buurman 
Dear all,

The above patch has been committed for a long while in the master
branch 
(https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0).
Is there any chance this could be backported to the 19.07 branch as
well, since it's a bug-fix and not a new feature? Thanks!

Yours sincerely,

Jaap

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