date:20171129

[LEDE-DEV] [PATCH v2] dnsmaq: add interface to ubus notification

2017-11-29 Thread Borja Salazar

Signed-off-by: Borja Salazar 
---
 package/network/services/dnsmasq/patches/240-ubus.patch | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/package/network/services/dnsmasq/patches/240-ubus.patch 
b/package/network/services/dnsmasq/patches/240-ubus.patch
index 0e0b1dd1b0..0a380ca824 100644
--- a/package/network/services/dnsmasq/patches/240-ubus.patch
+++ b/package/network/services/dnsmasq/patches/240-ubus.patch
@@ -9,7 +9,7 @@
  struct daemon *daemon;
  
  static volatile pid_t pid = 0;
-@@ -32,6 +34,62 @@ static void fatal_event(struct event_des
+@@ -32,6 +34,64 @@ static void fatal_event(struct event_des
  static int read_event(int fd, struct event_desc *evp, char **msg);
  static void poll_resolv(int force, int do_reload, time_t now);
  
@@ -25,7 +25,7 @@
 +  .type = &ubus_object_type,
 +};
 +
-+void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
const char *name)
++void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
const char *name, const char *interface)
 +{
 +  if (!ubus || !ubus_object.has_subscribers)
 +  return;
@@ -37,6 +37,8 @@
 +  blobmsg_add_string(&b, "ip", ip);
 +  if (name)
 +  blobmsg_add_string(&b, "name", name);
++  if (interface)
++  blobmsg_add_string(&b, "interface", interface);
 +  ubus_notify(ubus, &ubus_object, type, b.head, -1);
 +}
 +
@@ -106,7 +108,7 @@
  #  endif
  #endif
  
-+void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
const char *name);
++void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
const char *name, const char *interface);
 +
  /* ipset.c */
  #ifdef HAVE_IPSET
@@ -118,9 +120,9 @@
  string ? string : "",
  err ? err : "");
 +  if (!strcmp(type, "DHCPACK"))
-+ubus_event_bcast("dhcp.ack", daemon->namebuff, addr ? inet_ntoa(a) : 
NULL, string ? string : NULL);
++ubus_event_bcast("dhcp.ack", daemon->namebuff, addr ? inet_ntoa(a) : 
NULL, string ? string : NULL, interface);
 +  else if (!strcmp(type, "DHCPRELEASE"))
-+ubus_event_bcast("dhcp.release", daemon->namebuff, addr ? 
inet_ntoa(a) : NULL, string ? string : NULL);
++ubus_event_bcast("dhcp.release", daemon->namebuff, addr ? 
inet_ntoa(a) : NULL, string ? string : NULL, interface);
  }
  
  static void log_options(unsigned char *start, u32 xid)
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] fixing of image file names

2017-11-29 Thread Mathias Kresin


28.11.2017 19:24, Daniel Golle:

Hi Moritz,

thanks for stepping forward and adressing this issue.
It'd be good to include the two assertions added to your list beelow.

On Tue, Nov 28, 2017 at 07:05:23PM +0100, Moritz Warning wrote:

Hi,

I noticed that there are some image file names that do not follow the "common" 
name scheme.
Is it ok to change it? I would like to submit a patch.

Some examples:
- all lower case image names
   - lede-ipq806x-EA8500-squashfs-sysupgrade.tar => 
lede-ipq806x-ea8500-squashfs-sysupgrade.tar
- revision between -
   - lede-mvebu-linksys-wrt1900acv2-squashfs-sysupgrade.bin => 
lede-mvebu-linksys-wrt1900ac-v2-squashfs-sysupgrade.bin
- region specific images with region identifiers (us, eu, il, ...)
  - lede-ramips-rt305x-wnce2001-squashfs-factory-northamerica.bin => 
lede-ramips-rt305x-wnce2001-us-squashfs-factory.bin
- separate images for each version
   - lede-brcm47xx-mips74k-linksys-e1000-v1-v2-v2.1-squashfs.bin => 
lede-brcm47xx-mips74k-linksys-e1000-v1-squashfs.bin, ...


  - board_name (in target userspace) == profile (in imagebuilder) == DTS name

  - image_filename == 
${distro}-${target}-${subtarget}-${board_name}-${fstype}-${imgtype}

that would make identifying sysupgrade images much more straight
forward (and hence automatizable).

See also
https://github.com/aparcar/attendedsysupgrade-server/issues/80


I would like to propose something different which basically aims the same.

1. fix the compatible strings in the DTS files
2. use the compatible string from the DTS in userspace (boardname)
3. use the compatible string for the image filename (board_name in above 
example)


The DTS compatible string is supposed to be unique across the whole 
kernel and this way we can prevent duplicates in big targets like ramips.


The compatible string includes the vendor, which will make it way easier 
to find a particular image in directories with a lot of images. In 
theory, it should be even possible to provide all images in a single 
directory without target/subtarget prefix.


Since the underscore isn't a valid character in compatible strings, we 
can use it in the image filename as replacement for the comma to split 
vendor from boardname.


Due to the sync of runtime boardname and the boardname used in the image 
filename, it should be possible to guess the used image filename more 
reliably as requested.


I'm working on to do so since a while, with the following status:

1. is already done for the ramips target, more fixes are in the 
boarddetection branch of my staging tree


2. done for some targets in the boarddetection branch of my staging 
tree; done for a handful of ramips boards in the ramips branch of my 
staging tree


3. done for a handful of ramips boards in the ramips branch of my 
staging tree


Using the TP-Link TL-WR840N v5 as an example, the userspace boardname 
would be "tplink,tl-wr840n-v5" and the image filename would change from


  lede-ramips-mt76x8-tl-wr840n-v4-squashfs-sysupgrade.bin

to

  lede-ramips-mt76x8-tplink_tl-wr840n-v4-squashfs-sysupgrade.bin

Target and subtarget can be found in /etc/os_release of the running system.

I started working on the compat string in userspace thingy to get rid of 
another layer of glue code 
(target/linux/ramips/base-files/lib/ramips.sh), to unify the creation of 
the userspace boardname across all targets.


Initially it was meant to make the review of board support patches 
easier for me. But I noticed that it has more benefits than that as we 
can see with this mail thread.


But fixing the compat strings and migrating the userspace boardname to a 
DTS compat string based one is a hugh task and time consuming.


The first commits in my staging tree regarding the topic are from April 
this year and I'm still not finished. As all of us, I'm time constrained 
as well.


Any feedback on this approach (and help in migrating exists boards of 
course) is highly welcome.


Mathias

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v3] dnsmaq: add interface to ubus notification

2017-11-29 Thread Borja Salazar

Signed-off-by: Borja Salazar 
---
 package/network/services/dnsmasq/Makefile   |  2 +-
 package/network/services/dnsmasq/patches/240-ubus.patch | 12 +++-
 2 files changed, 8 insertions(+), 6 deletions(-)

diff --git a/package/network/services/dnsmasq/Makefile 
b/package/network/services/dnsmasq/Makefile
index ad118c6626..2c1073c148 100644
--- a/package/network/services/dnsmasq/Makefile
+++ b/package/network/services/dnsmasq/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
 
 PKG_NAME:=dnsmasq
 PKG_VERSION:=2.78
-PKG_RELEASE:=3
+PKG_RELEASE:=4
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/
diff --git a/package/network/services/dnsmasq/patches/240-ubus.patch 
b/package/network/services/dnsmasq/patches/240-ubus.patch
index 0e0b1dd1b0..0a380ca824 100644
--- a/package/network/services/dnsmasq/patches/240-ubus.patch
+++ b/package/network/services/dnsmasq/patches/240-ubus.patch
@@ -9,7 +9,7 @@
  struct daemon *daemon;
  
  static volatile pid_t pid = 0;
-@@ -32,6 +34,62 @@ static void fatal_event(struct event_des
+@@ -32,6 +34,64 @@ static void fatal_event(struct event_des
  static int read_event(int fd, struct event_desc *evp, char **msg);
  static void poll_resolv(int force, int do_reload, time_t now);
  
@@ -25,7 +25,7 @@
 +  .type = &ubus_object_type,
 +};
 +
-+void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
const char *name)
++void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
const char *name, const char *interface)
 +{
 +  if (!ubus || !ubus_object.has_subscribers)
 +  return;
@@ -37,6 +37,8 @@
 +  blobmsg_add_string(&b, "ip", ip);
 +  if (name)
 +  blobmsg_add_string(&b, "name", name);
++  if (interface)
++  blobmsg_add_string(&b, "interface", interface);
 +  ubus_notify(ubus, &ubus_object, type, b.head, -1);
 +}
 +
@@ -106,7 +108,7 @@
  #  endif
  #endif
  
-+void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
const char *name);
++void ubus_event_bcast(const char *type, const char *mac, const char *ip, 
const char *name, const char *interface);
 +
  /* ipset.c */
  #ifdef HAVE_IPSET
@@ -118,9 +120,9 @@
  string ? string : "",
  err ? err : "");
 +  if (!strcmp(type, "DHCPACK"))
-+ubus_event_bcast("dhcp.ack", daemon->namebuff, addr ? inet_ntoa(a) : 
NULL, string ? string : NULL);
++ubus_event_bcast("dhcp.ack", daemon->namebuff, addr ? inet_ntoa(a) : 
NULL, string ? string : NULL, interface);
 +  else if (!strcmp(type, "DHCPRELEASE"))
-+ubus_event_bcast("dhcp.release", daemon->namebuff, addr ? 
inet_ntoa(a) : NULL, string ? string : NULL);
++ubus_event_bcast("dhcp.release", daemon->namebuff, addr ? 
inet_ntoa(a) : NULL, string ? string : NULL, interface);
  }
  
  static void log_options(unsigned char *start, u32 xid)
-- 
2.11.0


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] iodine bad endianess?

2017-11-29 Thread Gui Iribarren

Hello,
i've been trying to run iodine (client) on LEDE,
but the packets generated by the client have a weird problem, which
looks like some endianness issue.
Comparing the initial handshake packets generated by debian iodine
client (which works fine), and LEDE one (which never connects to server)
the debian client correctly starts the conversation with an outgoing dns
query (Wireshark says "Flags: 0x0100 Standard query")
while the iodine client compiled for LEDE sends a very similar packet,
but with a reversed byte, so "Flags: 0x8000 Standard query response"

this (wrong) packet, of course, is not recognized by server.
why does iodine client code produce different packets when running on
debian than on LEDE?

notably, 0x0100 is  0001  
while0x8000 is 1000   

any pointers on what needs to be set during compile time, so that iodine
will not swap bytes like it does now?

(will be happy to patch Makefile myself, and contribute fix to the list,
of course)

###

just for the record, i'm on a TP-Link WR841N freshly flashed, with the
binary i downloaded yesterday from
https://downloads.lede-project.org/snapshots/targets/ramips/mt76x8/lede-ramips-mt76x8-tl-wr841n-v13-squashfs-tftp-recovery.bin

and opkg installed iodine from
http://downloads.lede-project.org/snapshots/packages/mipsel_24kc/packages/iodine_0.7.0-2_mipsel_24kc.ipk

root@LEDE:~# cat /etc/openwrt_version
r5431-0b3087e
root@LEDE:~# opkg list iodine
iodine - 0.7.0-2 - iodine client version
root@LEDE:~# iodine -v
iodine IP over DNS tunneling client
version: 0.7.0 from 2014-06-16


gui@debian:~ $ iodine -v
iodine IP over DNS tunneling client
version: 0.7.0 from 2014-06-16
gui@debian:~ $ dpkg -l iodine | grep ii
ii  iodine 0.7.0-3  i386 tool for tunneling IPv4
data through a DNS server

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] WRT3200ACM crashes after mac80211 wireless-testing 2017-11-01

2017-11-29 Thread Felix Fietkau

On 2017-11-23 01:25, Syrone Wong wrote:
> Hi,
> 
> 1. minor warning
> 
> .config:5:warning: symbol value 'm' invalid for ATH_REG_DYNAMIC_USER_REG_HINTS
> 
> The config entry is of type bool.
> 
> config ATH_REG_DYNAMIC_USER_REG_HINTS
> bool "Atheros dynamic user regulatory hints"
> depends on CFG80211_CERTIFICATION_ONUS
> default n
> ---help---
>  Say N. This should only be enabled in countries where
>  this feature is explicitly allowed and only on cards that
>  specifically have been tested for this.
> 
> 2. wireless-regdb
> 
> python $(PKG_BUILD_DIR)/db2fw.py $(PKG_BUILD_DIR)/regulatory.db
> $(PKG_BUILD_DIR)/db.txt in Build/Compile assumes python is linked to
> python2 by default. But it's not the truth for bleeding edge distros,
> for example, Archlinux.
> 
> It will fail on the system that links python to python 3.
> 
>  File 
> "/home/wong/github/lede-1/build_dir/target-arm_cortex-a9+vfpv3_musl_eabi/wireless-regdb-2017-10-20-4343d359/db2fw.py",
> line 13
> 
> print 'Usage: %s output-file input-file' % sys.argv[0]
>^
> SyntaxError: Missing parentheses in call to 'print'. Did you mean
> print(int 'Usage: %s output-file input-file' % sys.argv[0])?
> 
> The error got ignored silently.
> 
> I propose following `tools/scons/files/pywrap.sh` way, find python2
> ourselves and call python2 explicitly.
> 
> 3. About the crash
> 
> It crashes in ~5mins after clients connected to the router. No warning
> or kernel panic messages at all, just rebooting.
> 
> I tried to build new backports based on wt-2017-11-14, drop some
> patches already upstream, and still the same issue.
> 
> After reverting
> 6a6dc94e0c9a0533eaa9819bf3c22128b009af56,
> 9247864b6ed933841ee3068dbd4add06babe7fbd,
> 2dc485250d516f1535eeaf53f0f2f5742e5f9e0c and
> f9fa266faf9a2fdea48cc2fb72fa5a7e52a527c0, the crash disappears.
Please try the latest version, I fixed a bug in
2dc485250d516f1535eeaf53f0f2f5742e5f9e0c which led to crashes.

- Felix

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] iodine bad endianess?

2017-11-29 Thread Jo-Philipp Wich

Hi Gui,

please test the PR at https://github.com/openwrt/packages/pull/5190.

~ Jo

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH] procd: nand: dont rely on boardname in nand_upgrade_tar

2017-11-29 Thread Mathias Kresin

Kernel and rootfs in a subdirectory matching the userspace boardname
was intended to use a single sysupgrade-tar archive for multiple boards
with different kernel/rootfs images. This feature was never used.

Use the first found directory in the tar archive instead of relying on
a directory named according to the userspace boardname.

It allows to change the boardname without adding another compatibility
layer - using the nand_board_name() function - for (sub)targets using
the metadata based image validation in favour to
nand_do_platform_check().

Signed-off-by: Mathias Kresin 
---
 package/base-files/files/lib/upgrade/nand.sh | 16 +---
 1 file changed, 9 insertions(+), 7 deletions(-)

diff --git a/package/base-files/files/lib/upgrade/nand.sh 
b/package/base-files/files/lib/upgrade/nand.sh
index 563db4c..1c6b86b 100644
--- a/package/base-files/files/lib/upgrade/nand.sh
+++ b/package/base-files/files/lib/upgrade/nand.sh
@@ -250,19 +250,21 @@ nand_board_name() {
 
 nand_upgrade_tar() {
local tar_file="$1"
-   local board_name="$(nand_board_name)"
local kernel_mtd="$(find_mtd_index $CI_KERNPART)"
 
-   local kernel_length=`(tar xf $tar_file sysupgrade-$board_name/kernel -O 
| wc -c) 2> /dev/null`
-   local rootfs_length=`(tar xf $tar_file sysupgrade-$board_name/root -O | 
wc -c) 2> /dev/null`
+   local board_dir=$(tar tf $tar_file | grep -m 1 '^sysupgrade-.*/$')
+   board_dir=${board_dir%/}
 
-   local rootfs_type="$(identify_tar "$tar_file" 
sysupgrade-$board_name/root)"
+   local kernel_length=`(tar xf $tar_file ${board_dir}/kernel -O | wc -c) 
2> /dev/null`
+   local rootfs_length=`(tar xf $tar_file ${board_dir}/root -O | wc -c) 2> 
/dev/null`
+
+   local rootfs_type="$(identify_tar "$tar_file" ${board_dir}/root)"
 
local has_kernel=1
local has_env=0
 
[ "$kernel_length" != 0 -a -n "$kernel_mtd" ] && {
-   tar xf $tar_file sysupgrade-$board_name/kernel -O | mtd write - 
$CI_KERNPART
+   tar xf $tar_file ${board_dir}/kernel -O | mtd write - 
$CI_KERNPART
}
[ "$kernel_length" = 0 -o ! -z "$kernel_mtd" ] && has_kernel=0
 
@@ -271,12 +273,12 @@ nand_upgrade_tar() {
local ubidev="$( nand_find_ubi "$CI_UBIPART" )"
[ "$has_kernel" = "1" ] && {
local kern_ubivol="$(nand_find_volume $ubidev $CI_KERNPART)"
-   tar xf $tar_file sysupgrade-$board_name/kernel -O | \
+   tar xf $tar_file ${board_dir}/kernel -O | \
ubiupdatevol /dev/$kern_ubivol -s $kernel_length -
}
 
local root_ubivol="$(nand_find_volume $ubidev rootfs)"
-   tar xf $tar_file sysupgrade-$board_name/root -O | \
+   tar xf $tar_file ${board_dir}/root -O | \
ubiupdatevol /dev/$root_ubivol -s $rootfs_length -
 
nand_do_upgrade_success
-- 
2.7.4


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Add support for Comfast E312A

2017-11-29 Thread Bill Moffitt

This unit is the 5 GHz cousin to the E314N - a 5 GHz. 2x2 radio with 
built-in directional antenna. Very similar to a Ubiquiti NanoStation M5. 
This version of the patch seems to have everything working.


I need some help generating a pull request (I'm a git newbie) - I have 
followed the directions here: 
https://lede-project.org/submitting-patches, but, when I get to the step 
"git push --all" I get the response, "fatal: unable to access 
'https://git.lede-project.org/source.git/': The requested URL returned 
error: 403" and I can't seem to get past that.


Thanks!


diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds 
b/target/linux/ar71xx/base-files/etc/board.d/01_leds

index e101d55..1c506d0 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
 ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
 ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
 ;;
+cf-e312a)
+    ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+    ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+    ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+    ;;
 cf-e316n-v2)
 ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
 ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh 
b/target/linux/ar71xx/base-files/etc/diag.sh

index 5ef620b..6274841 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -118,6 +118,7 @@ get_status_led() {
 cap4200ag)
     status_led="senao:green:pwr"
     ;;
+    cf-e312a|\
 cf-e316n-v2|\
 cf-e520n|\
 cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh 
b/target/linux/ar71xx/base-files/lib/ar71xx.sh

index 9903563..98ed277 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
 *"Carambola2"*)
     name="carambola2"
     ;;
+    *"CF-E312A")
+        name="cf-e312a"
+        ;;
 *"CF-E316N v2")
     name="cf-e316n-v2"
     ;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh

index 18e5e41..1b13230 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
 bullet-m|\
 c-55|\
 carambola2|\
+    cf-e312a|\
 cf-e316n-v2|\
 cf-e320n-v2|\
 cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 4793bf4..e86837f 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
 CONFIG_ATH79_MACH_CAP324=y
 CONFIG_ATH79_MACH_CAP4200AG=y
 CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
 CONFIG_ATH79_MACH_CF_E316N_V2=y
 CONFIG_ATH79_MACH_CF_E320N_V2=y
 CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 84b2a0b..231e78e 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -65,6 +65,7 @@ CONFIG_ATH79_MACH_C55=y
 CONFIG_ATH79_MACH_CAP324=y
 CONFIG_ATH79_MACH_CAP4200AG=y
 CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
 CONFIG_ATH79_MACH_CF_E316N_V2=y
 CONFIG_ATH79_MACH_CF_E320N_V2=y
 CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt 
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt

index 5cb4f7e..e0484f2 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -2021,6 +2021,16 @@ config ATH79_MACH_RAMBUTAN
 select ATH79_DEV_USB
 select ATH79_DEV_WMAC

+config ATH79_MACH_CF_E312A
+    bool "COMFAST CF-E312A support"
+    select SOC_AR934X
+    select ATH79_DEV_ETH
+    select ATH79_DEV_GPIO_BUTTONS
+    select ATH79_DEV_LEDS_GPIO
+    select ATH79_DEV_M25P80
+    select ATH79_DEV_USB
+    select ATH79_DEV_WMAC
+
 config ATH79_MACH_CF_E316N_V2
 bool "COMFAST CF-E316N v2 support"
 select SOC_AR934X
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile 
b/target/linux/ar71xx/files/arch/mips/ath79/Makefile

index 7d12282..3cf8e69 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_ATH79_MACH_C60)            += mach-c60.o
 obj-$(CONFIG_ATH79_MACH_CAP324)            += mach-cap324.o
 obj-$(CONFIG_ATH79_MACH_CAP4200AG)        += mach-cap4200ag.o
 obj-$(CONFIG_ATH79_MACH_CARAMBOLA2)        += mach-carambola2.o
+obj-$(CONFIG_ATH79_MACH_CF_E312A)        += mach-cf-e316n-v2.o
 obj-$(CONFIG_ATH79_MACH_CF_E316N_V2)        += mach-cf-e316n-v2.o
 obj-$(CONFIG_ATH79_MACH_CF_E

Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

2017-11-29 Thread Piotr Dymacz


Hello Karol,

Sorry for a late reply.

On 06.11.2017 18:58, Bizon wrote:

Hi Piotr,

  Thank You for comments.

Before sending v2 patch lets clarify all doubts.

2017-11-05 23:22 GMT+01:00 Piotr Dymacz :

Hello Karol,

Thank you for your patch but it seems that it got whitespace mangled and
tabs were replaced with spaces. Please, send v2 using git send-email.

Also, please see my comments inline, below.

On 30.10.2017 20:32, Bizon wrote:


Add support for TP-Link TL-WDR7500 V6.

Specifications:
- WiSoC: QCA9563 - 3x3 2.4GHz
- Radio2: QCA9880 - 3x3 5GHz
- RAM: 64MB DDR2
- Storage: 8MB NOR SPI flash, can be replaced with 16M
- Switch: RTL8367S, now unmanaged
- Ethernet: 5x1G
- Misc: 2x button, 2x LED



Please, include in commit message how to install LEDE on this device as
described under "commit description" section on [1].


Ok, will prepare manual how to change bootloader to non-RSA one, move art and
install LEDE.


I'm sorry but I'm against accepting support for devices which requires 
such invasive modifications. We always try to make it possible for users 
to get back to the stock firmware which wouldn't be easy (or possible at 
all) with your changes in mtd layout and after bootloader swap.


--
Cheers,
Piotr







Signed-off-by: Karol Bizewski 
---
  package/boot/uboot-envtools/files/ar71xx|  2 ++
  target/linux/ar71xx/base-files/etc/board.d/02_network   |  2 ++
  target/linux/ar71xx/base-files/etc/diag.sh  |  4 
  .../base-files/etc/hotplug.d/firmware/11-ath10k-caldata |  5 +
  target/linux/ar71xx/base-files/lib/ar71xx.sh|  6 ++
  target/linux/ar71xx/config-4.4  |  1 +
  target/linux/ar71xx/config-4.9  |  1 +
  .../linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt  | 10 ++
  target/linux/ar71xx/files/arch/mips/ath79/Makefile  |  1 +
  target/linux/ar71xx/files/arch/mips/ath79/machtypes.h   |  1 +
  target/linux/ar71xx/image/generic.mk| 17
+
  .../files/arch/mips/ath79/mach-tl-wdr7500-v6.c  | 112
+
  12 files changed, 162 insertions(+)
  create mode 100644
target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr7500-v6.c

  diff --git a/package/boot/uboot-envtools/files/ar71xx
b/package/boot/uboot-envtools/files/ar71xx
index 0bdb6de..789c317 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -46,6 +46,8 @@ om5p-acv2|\
  om5p-an|\
  sr3200|\
  tube2h|\
+tl-wdr7500-v6|\
+tl-wdr7500-v6-16M|\



Please, drop this "tl-wdr7500-v6-16M" thing. As far as I understand, this is
only your custom hardware modification and the default/factory version comes
with just 8 MB of FLASH.


Ok. 16MB flash is hw mod.



And I really don't think this device has a writable U-Boot environment in a
separate sector. Please, provide some explanation.


Original bootloader checks RSA for second bootloader and system.
To install LEDE I chose to replace bootloader instead of using any
workarounds (if even exists).

Working bootloader is available at:
https://github.com/bizongod/u-boot_wdr7500v6
It is based on u-boot from TL-WDR1043v4 plus initializing routines for
switch and other usable mods. It has also writable env.

With changing bootloader I decided also that's good opportunity to move
art to better address, that's end of flash.





  wndr3700|\
  xd3200)
   ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1" "0x1"
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index d838352..6cdd2fe 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -122,6 +122,8 @@ ar71xx_setup_interfaces()
   tl-wa901nd-v2|\
   tl-wa901nd-v3|\
   tl-wa901nd-v4|\
+ tl-wdr7500-v6|\
+ tl-wdr7500-v6-16M|\
   tl-wr703n|\
   tl-wr802n-v1|\
   tl-wr802n-v2|\
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index ade726f..f0ec9e6 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -20,6 +20,10 @@ get_status_led() {
   all0305)
   status_led="eap7660d:green:ds4"
   ;;
+ tl-wdr7500-v6|\
+ tl-wdr7500-v6-16M)
+ status_led="$board:blue:system"
+ ;;
   antminer-s1|\
   antminer-s3|\
   antminer-r1|\
diff --git
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 85a2a63..bd0cf2e 100644
---
a/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++
b/target/linux/ar71xx/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -98,6 +98,11 @@ case "$FIRMWARE" in
   rb-952ui-5ac2nd)
   ath10kcal_from_file "/sys/firmware/routerboot/ext_wlan_data" 20480 2116
   ;;
+ tl-wdr7500-v6|\
+ tl-wdr7500-v6-16M)
+ ath10kcal_extract "art" 8192 2116
+ ath10kcal_patch_mac $(macaddr_ad

Re: [LEDE-DEV] add support for Comfast E314N

2017-11-29 Thread Piotr Dymacz


Hello Bill,

Thank you for your patch but it seems that it got whitespace mangled and 
tabs were replaced with spaces. Please, send v2 using git send-email.


Also, please see our submitting patches guide: [1]. Your patch is 
missing at least:


- SoB line
- correct prefix in the subject
- information how to install LEDE on the device

[1] https://lede-project.org/submitting-patches

--
Cheers,
Piotr

On 28.11.2017 21:21, Bill Moffitt wrote:

Comfast E314N is a 2.4 GHz. outdoor directional wireless radio with two
Ethernet ports and PoE pass-through (controlled by a slide switch).

diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e5baa90..f1e29c7 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
   ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
   ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
   ;;
+cf-e314n)
+    ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+    ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+    ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+    ;;
   cf-e316n-v2)
   ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
   ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 6cbb357..93b9e76 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -119,6 +119,7 @@ get_status_led() {
   cap4200ag)
       status_led="senao:green:pwr"
       ;;
+    cf-e314n|\
   cf-e316n-v2|\
   cf-e520n|\
   cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 285fa68..ee7b93a 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
   *"Carambola2"*)
       name="carambola2"
       ;;
+    *"CF-E314N")
+        name="cf-e314n"
+        ;;
   *"CF-E316N v2")
       name="cf-e316n-v2"
       ;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 172a58b..159bd49 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
   bullet-m|\
   c-55|\
   carambola2|\
+    cf-e314n|\
   cf-e316n-v2|\
   cf-e320n-v2|\
   cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 3ba3853..134352b 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
   CONFIG_ATH79_MACH_CAP324=y
   CONFIG_ATH79_MACH_CAP4200AG=y
   CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E314N=y
   CONFIG_ATH79_MACH_CF_E316N_V2=y
   CONFIG_ATH79_MACH_CF_E320N_V2=y
   CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 1d47246..7047aa4 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -65,6 +65,7 @@ CONFIG_ATH79_MACH_C55=y
   CONFIG_ATH79_MACH_CAP324=y
   CONFIG_ATH79_MACH_CAP4200AG=y
   CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E314N=y
   CONFIG_ATH79_MACH_CF_E316N_V2=y
   CONFIG_ATH79_MACH_CF_E320N_V2=y
   CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 1198fcb..bd21f40 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -2051,6 +2051,16 @@ config ATH79_MACH_RAMBUTAN
   select ATH79_DEV_USB
   select ATH79_DEV_WMAC

+config ATH79_MACH_CF_E314N
+    bool "COMFAST CF-E314N support"
+    select SOC_QCA953X
+    select ATH79_DEV_ETH
+    select ATH79_DEV_GPIO_BUTTONS
+    select ATH79_DEV_LEDS_GPIO
+    select ATH79_DEV_M25P80
+    select ATH79_DEV_USB
+    select ATH79_DEV_WMAC
+
   config ATH79_MACH_CF_E316N_V2
   bool "COMFAST CF-E316N v2 support"
   select SOC_AR934X
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
index 455af76..148c3a3 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Makefile
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Makefile
@@ -74,6 +74,7 @@ obj-$(CONFIG_ATH79_MACH_C60)            += mach-c60.o
   obj-$(CONFIG_ATH79_MACH_CAP324)            += mach-cap324.o
   obj-$(CONFIG_ATH79_MACH_CAP4200AG)        += mach-cap4200ag.o
   obj-$(CONFIG_ATH79_MACH_CARAMBOLA2)        += mach-carambola2.o
+obj-$(CONFIG_ATH79_MACH_CF_E314N)        += mach-cf-e316n-v2.o
   obj-

Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

2017-11-29 Thread Bill Moffitt


Hello Piotr and Karol,


On 11/29/2017 11:03 AM, Piotr Dymacz wrote:

Hello Karol,

Sorry for a late reply.

On 06.11.2017 18:58, Bizon wrote:

Hi Piotr,

  Thank You for comments.

Before sending v2 patch lets clarify all doubts.

2017-11-05 23:22 GMT+01:00 Piotr Dymacz :

Hello Karol,

Thank you for your patch but it seems that it got whitespace mangled 
and

tabs were replaced with spaces. Please, send v2 using git send-email.

Also, please see my comments inline, below.

On 30.10.2017 20:32, Bizon wrote:


Add support for TP-Link TL-WDR7500 V6.

Specifications:
- WiSoC: QCA9563 - 3x3 2.4GHz
- Radio2: QCA9880 - 3x3 5GHz
- RAM: 64MB DDR2
- Storage: 8MB NOR SPI flash, can be replaced with 16M
- Switch: RTL8367S, now unmanaged
- Ethernet: 5x1G
- Misc: 2x button, 2x LED



Please, include in commit message how to install LEDE on this device as
described under "commit description" section on [1].


Ok, will prepare manual how to change bootloader to non-RSA one, move 
art and

install LEDE.


I'm sorry but I'm against accepting support for devices which requires 
such invasive modifications. We always try to make it possible for 
users to get back to the stock firmware which wouldn't be easy (or 
possible at all) with your changes in mtd layout and after bootloader 
swap.


In general, of course, I agree. However, we are seeing an increasing 
number of vendors (TP-Link and Ubiquiti, to name 2) using some form of 
locking in the bootloader to prevent loading of third-party firmware. 
The only option for loading OpenWRT (permanently - not using initramfs) 
on these devices will be replacing the bootloader, as Karol does in this 
patch.


If the only objection is that it involves invasive modifications that 
may not (probably won't) allow the device to be re-flashed to stock, I 
would prefer we accept the patch and make a very strongly-worded note in 
the ToH and the device's wiki page explaining the situation.


FWIW,

Bill

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

2017-11-29 Thread Stijn Tintel

On 08-11-17 12:14, Baptiste Jonglez wrote:
> Hi Stijn,
>
> What is your opinion on this patch?  There has been a bit of feedback, but
> you were the one requesting the change in the first place :)
It seems most feedback simply ignores the part where b30ba14e actually
broke existing functionality. I keep running into this breakage when
using the script to bump kernel version, or when bumping packages I
maintain. While I agree that adding another knob seems cumbersome, I
would like to be able to use the broken functionality, so

Acked-by: Stijn Tintel 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH 1/2] scripts/download.pl: Add a --skip-hash option

2017-11-29 Thread Stijn Tintel

On 26-10-17 11:50, Baptiste Jonglez wrote:
> When the new "--skip-hash" option is passed to scripts/download.pl, hash
> verification of the downloaded files is completely skipped.  This can be
> useful when bumping package version, since the hash may not be known in
> advance.
>
>
Acked-by: Stijn Tintel 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] Add support for Comfast E312A

2017-11-29 Thread Piotr Dymacz


Hello Bill,

Thank you for your patch but it seems that it got whitespace mangled and
tabs were replaced with spaces. Please, send v2 using git send-email.

Also, please see our submitting patches guide: [1]. Your patch is
missing at least:

- SoB line
- correct prefix in the subject
- information how to install LEDE on the device

On 29.11.2017 19:53, Bill Moffitt wrote:

This unit is the 5 GHz cousin to the E314N - a 5 GHz. 2x2 radio with
built-in directional antenna. Very similar to a Ubiquiti NanoStation M5.
This version of the patch seems to have everything working.

I need some help generating a pull request (I'm a git newbie) - I have
followed the directions here:
https://lede-project.org/submitting-patches, but, when I get to the step
"git push --all" I get the response, "fatal: unable to access
'https://git.lede-project.org/source.git/': The requested URL returned
error: 403" and I can't seem to get past that.


From our submitting patches guide: "Patches can be submitted as a pull 
request on Github or via the mailing list.". Please, use our GitHub 
mirror for sending pull requests: [2].


[1] https://lede-project.org/submitting-patches
[2] https://github.com/lede-project/source

--
Cheers,
Piotr



Thanks!


diff --git a/target/linux/ar71xx/base-files/etc/board.d/01_leds
b/target/linux/ar71xx/base-files/etc/board.d/01_leds
index e101d55..1c506d0 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/01_leds
+++ b/target/linux/ar71xx/base-files/etc/board.d/01_leds
@@ -182,6 +182,11 @@ carambola2)
   ucidef_set_led_netdev "wan" "WAN" "$board:orange:eth1" "eth1"
   ucidef_set_led_wlan "wlan" "WLAN" "$board:green:wlan" "phy0tpt"
   ;;
+cf-e312a)
+    ucidef_set_led_netdev "lan" "LAN" "$board:white:lan" "eth0"
+    ucidef_set_led_netdev "wan" "WAN" "$board:white:wan" "eth1"
+    ucidef_set_led_wlan "wlan" "WLAN" "$board:white:wlan" "phy0tpt"
+    ;;
   cf-e316n-v2)
   ucidef_set_led_netdev "lan" "LAN" "$board:blue:lan" "eth0"
   ucidef_set_led_netdev "wan" "WAN" "$board:blue:wan" "eth1"
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 5ef620b..6274841 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -118,6 +118,7 @@ get_status_led() {
   cap4200ag)
       status_led="senao:green:pwr"
       ;;
+    cf-e312a|\
   cf-e316n-v2|\
   cf-e520n|\
   cf-e530n)
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 9903563..98ed277 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -504,6 +504,9 @@ ar71xx_board_detect() {
   *"Carambola2"*)
       name="carambola2"
       ;;
+    *"CF-E312A")
+        name="cf-e312a"
+        ;;
   *"CF-E316N v2")
       name="cf-e316n-v2"
       ;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 18e5e41..1b13230 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -215,6 +215,7 @@ platform_check_image() {
   bullet-m|\
   c-55|\
   carambola2|\
+    cf-e312a|\
   cf-e316n-v2|\
   cf-e320n-v2|\
   cf-e355ac|\
diff --git a/target/linux/ar71xx/config-4.4 b/target/linux/ar71xx/config-4.4
index 4793bf4..e86837f 100644
--- a/target/linux/ar71xx/config-4.4
+++ b/target/linux/ar71xx/config-4.4
@@ -67,6 +67,7 @@ CONFIG_ATH79_MACH_C55=y
   CONFIG_ATH79_MACH_CAP324=y
   CONFIG_ATH79_MACH_CAP4200AG=y
   CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
   CONFIG_ATH79_MACH_CF_E316N_V2=y
   CONFIG_ATH79_MACH_CF_E320N_V2=y
   CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/config-4.9 b/target/linux/ar71xx/config-4.9
index 84b2a0b..231e78e 100644
--- a/target/linux/ar71xx/config-4.9
+++ b/target/linux/ar71xx/config-4.9
@@ -65,6 +65,7 @@ CONFIG_ATH79_MACH_C55=y
   CONFIG_ATH79_MACH_CAP324=y
   CONFIG_ATH79_MACH_CAP4200AG=y
   CONFIG_ATH79_MACH_CARAMBOLA2=y
+CONFIG_ATH79_MACH_CF_E312A=y
   CONFIG_ATH79_MACH_CF_E316N_V2=y
   CONFIG_ATH79_MACH_CF_E320N_V2=y
   CONFIG_ATH79_MACH_CF_E355AC=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
index 5cb4f7e..e0484f2 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
+++ b/target/linux/ar71xx/files/arch/mips/ath79/Kconfig.openwrt
@@ -2021,6 +2021,16 @@ config ATH79_MACH_RAMBUTAN
   select ATH79_DEV_USB
   select ATH79_DEV_WMAC

+config ATH79_MACH_CF_E312A
+    bool "COMFAST CF-E312A support"
+    select SOC_AR934X
+    select ATH79_DEV_ETH
+    select ATH79_DEV_GPIO_BUTTONS
+    select ATH79_DEV_LEDS_GPIO
+    select ATH79_DEV_M25P80
+    select ATH79_DEV_USB
+    select ATH79_DEV_WMAC
+
   config ATH79_MACH_CF_E316N_V2
   bool "COM

Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

2017-11-29 Thread Piotr Dymacz


Hello Bill,

On 29.11.2017 20:17, Bill Moffitt wrote:

Hello Piotr and Karol,


[snip]


Please, include in commit message how to install LEDE on this device as
described under "commit description" section on [1].


Ok, will prepare manual how to change bootloader to non-RSA one, move 
art and

install LEDE.


I'm sorry but I'm against accepting support for devices which requires 
such invasive modifications. We always try to make it possible for 
users to get back to the stock firmware which wouldn't be easy (or 
possible at all) with your changes in mtd layout and after bootloader 
swap.



In general, of course, I agree. However, we are seeing an increasing
number of vendors (TP-Link and Ubiquiti, to name 2) using some form of
locking in the bootloader to prevent loading of third-party firmware.


Then buy and use hardware from vendors who are open source friendly and 
allow users to actually fully own the hardware they paid for! :)



The only option for loading OpenWRT (permanently - not using initramfs)
on these devices will be replacing the bootloader, as Karol does in this
patch.


Swapping bootloader isn't the only issue I see here. Moving ART which is 
essential and unique per device might end up in a data loss which cannot 
be recovered in any way.



If the only objection is that it involves invasive modifications that
may not (probably won't) allow the device to be re-flashed to stock, I
would prefer we accept the patch and make a very strongly-worded note in
the ToH and the device's wiki page explaining the situation.


This is not the only one objection. Personally I don't have problems 
with swapping bootloader and for ar71xx target we already have a 
dedicated package with old U-Boot sources: [1]


The problem here is that the bootloader the user has to use for this 
device comes from some random GitHub repository which exist today but 
may disappear tomorrow. Who will make sure that the bootloader image the 
author of the support mentions in his patch will be still available in 
next years and is correct and won't break users device?
If the bootloader code was in our repository or in upstream, I would be 
first one accepting support for this device.


What's also important to notice here, devices with QCA WiSoCs and SPI 
NOR flash chips aren't easy to recover from a failed bootloader flash. 
If there is no JTAG on the board the only way to bring device back to 
life is to use flash chip programmer.


[1] 
https://github.com/lede-project/source/tree/master/package/boot/uboot-ar71xx


--
Cheers,
Piotr



FWIW,

Bill

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev




___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] STP, rSTP and MSTP

2017-11-29 Thread Alexandru Ardelean

resending, since I initially sent it from my GMail phone app, which
does not allow plain-text mode
[ and i keep forgetting ]

On Tue, Nov 28, 2017 at 2:22 PM, Lucian Cristian  wrote:
> On 28.11.2017 13:39, Stefan Peter wrote:
>>
>> Hi Pablo
>>
>> On 28.11.2017 11:05, Pablo I. Pousada Rial wrote:
>>>
>>> Does LEDE implement just basic STP, or does it provide access to RSTP or
>>> MSTP?
>>
>> The Linux kernel only implements basic STP. I successfully have used
>> mstpd from https://github.com/mstpd/mstpd for RSTP, but I never tried
>> MSTP.

I have a plan to package mstpd for OpenWrt.
It’s in work in progress.

RSTP works fine in mstpd.
MSTP has been reported to not work well with some switches.

Maybe we’ll find some resources to test mstpd’s MSTP compliance.

Tbh I never tried STP, but it should work fine as well.

>>
>> With kind regards
>>
>> Stefan Peter
>>
>>
>> ___
>> Lede-dev mailing list
>> Lede-dev@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/lede-dev
>
>
> there is another option found in feeds http://www.openvswitch.org/features/

> there is another option found in feeds http://www.openvswitch.org/features/

OVS implements both STP & RSTP.

It requires that you use it’s own bridge implementation vs Linux bridges.

What I don’t like about OVS, is the bloat.
It’s data-center centric, and it uses plenty of RAM.
An example from memory: you cannot create 100 OVS bridges and make it
fit onto 128 MB of RAM, running on a ar71xx platform.
Also, OVS’ flash foot-print is big: it would be hard if you need to
fit it in anything lower than 8-16 MB of flash.

There were some tentative discussions about trying to trim it down,
but there is some resistance there.

Depending on what’s needed, either OVS or mstpd could work.

I’ve been wanting to package mstpd sooner.
It’s also very small for needs that are closer to embedded.
The initial maintainer of it (Vitalii) intended it for embedded.

We’ve also been using it successfully as an RSTP implementation.
Problem with our use-case is that we’ve written some swconfig hooks
that upstream does not like.

In any case, I’ll try to find time to package it in a more
OpenWrt-friendly fashion that works nice with netifd.
It should still work fine out-of-the-box.

>
> Regards
>
>
>
> ___
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] Invalid hash for usbip package

2017-11-29 Thread Nicholas Smith

Hi,

When compiling the usbip package in the latest snapshot, the hash of the 
downloaded file is not the expected hash, causing the compilation to fail.

I propose changing the hash in $build/feeds/packages/net/usbip/Makefile from 
the current value to the value below:
312d411c21404a16516cb4d33dcda4cb1c7ed43c003a8736db274de655e418d7



___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] fixing of image file names

2017-11-29 Thread Luis Araneda

Hi,


> I would like to propose something different which basically aims the same.
>
> 1. fix the compatible strings in the DTS files
> 2. use the compatible string from the DTS in userspace (boardname)
> 3. use the compatible string for the image filename (board_name in above
> example)
>
> The DTS compatible string is supposed to be unique across the whole kernel
> and this way we can prevent duplicates in big targets like ramips.
>
> The compatible string includes the vendor, which will make it way easier to
> find a particular image in directories with a lot of images. In theory, it
> should be even possible to provide all images in a single directory without
> target/subtarget prefix.
>
> Since the underscore isn't a valid character in compatible strings, we can
> use it in the image filename as replacement for the comma to split vendor
> from boardname.
>
> Due to the sync of runtime boardname and the boardname used in the image
> filename, it should be possible to guess the used image filename more
> reliably as requested.
>
> I'm working on to do so since a while, with the following status:
>
> 1. is already done for the ramips target, more fixes are in the
> boarddetection branch of my staging tree
>
> 2. done for some targets in the boarddetection branch of my staging tree;
> done for a handful of ramips boards in the ramips branch of my staging tree
>
> 3. done for a handful of ramips boards in the ramips branch of my staging
> tree
>
> Using the TP-Link TL-WR840N v5 as an example, the userspace boardname would
> be "tplink,tl-wr840n-v5" and the image filename would change from
>
>   lede-ramips-mt76x8-tl-wr840n-v4-squashfs-sysupgrade.bin
>
> to
>
>   lede-ramips-mt76x8-tplink_tl-wr840n-v4-squashfs-sysupgrade.bin
>
> Target and subtarget can be found in /etc/os_release of the running system.
>
> I started working on the compat string in userspace thingy to get rid of
> another layer of glue code (target/linux/ramips/base-files/lib/ramips.sh),
> to unify the creation of the userspace boardname across all targets.
>
> Initially it was meant to make the review of board support patches easier
> for me. But I noticed that it has more benefits than that as we can see with
> this mail thread.
>
> But fixing the compat strings and migrating the userspace boardname to a DTS
> compat string based one is a hugh task and time consuming.
>
> The first commits in my staging tree regarding the topic are from April this
> year and I'm still not finished. As all of us, I'm time constrained as well.
>
> Any feedback on this approach (and help in migrating exists boards of
> course) is highly welcome.

That seems like the correct way to go, but is a lot of work as you mentioned.
I can start with the ipq806x and sunxi targets, since they are the
ones I am most familiar with.

@Mathias: Should I send you the patches to be applied to your staging
tree, or to the mailing list?


Cheers,

Luis Araneda.

___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] uqmi: fix raw-ip mode for newer lte modems

2017-11-29 Thread Nicholas Smith

Hi Koen,

I would like to report that it is attempting, but it is unable to change 
/sys/class/wwan0/qmi/raw_ip to a “Y” on it’s own.  I have to bring the 
interface down myself, set raw_ip to Y, then bring it back up.  Manual, but it 
works every time.

[   40.40] qmi_wwan 1-2:1.8 wwan0: Cannot change a running device

Here’s what I do to work around:

In LuCI go to wwan0 and stop the interface.
echo “Y” > /sys/class/wwan0/qmi/raw_ip
In LuCI go to wwan0 and connect the interface.



> On 28 Nov 2017, at 6:27 pm, Koen Vandeputte  
> wrote:
> 
> 
> 
> On 2017-11-27 23:38, Nicholas Smith wrote:
>> Hi!
>> 
>> Will this also apply to the Sierra MC7430, as it is also raw-ip only?  If I 
>> am not mistaken it is the same as the MC7455, just for the Asia/Pacific 
>> region.  I would be able to verify this patch on the device.  To verify that 
>> it works, do I just look for /sys/class/net/$ifname/qmi/raw_ip ?
>> 
>> Nicholas
>> smith.nicholas...@gmail.com
>> 
> 
> 
> Judging by the datasheet compared to the MC7455 and some other resources 
> online:  most likely yes.
> Keep in mind that this will not work on the 17.01 branch as kernel 4.5 or 
> better is required which contains the needed driver parts and fixes.
> 
> If you would like to evaluate, please use master branch.
> 
> Testing the patch in full checking connectivity is always better than just 
> checking if that particular file is present.
> You should see a print referring to raw-ip popping up using logread. (see 
> patch contents)
> 
> 
> Regards,
> 
> Koen


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

Re: [LEDE-DEV] [PATCH v2] uqmi: fix raw-ip mode for newer lte modems

2017-11-29 Thread Nicholas Smith

Here is the VID:PID of the MC7430, if it helps.
Bus 001 Device 002: ID 1199:9071 Sierra Wireless, Inc. 


> On 30 Nov 2017, at 1:49 pm, Nicholas Smith  
> wrote:
> 
> Hi Koen,
> 
> I would like to report that it is attempting, but it is unable to change 
> /sys/class/wwan0/qmi/raw_ip to a “Y” on it’s own.  I have to bring the 
> interface down myself, set raw_ip to Y, then bring it back up.  Manual, but 
> it works every time.
> 
> [   40.40] qmi_wwan 1-2:1.8 wwan0: Cannot change a running device
> 
> Here’s what I do to work around:
> 
> In LuCI go to wwan0 and stop the interface.
> echo “Y” > /sys/class/wwan0/qmi/raw_ip
> In LuCI go to wwan0 and connect the interface.
> 
> 
> 
>> On 28 Nov 2017, at 6:27 pm, Koen Vandeputte  
>> wrote:
>> 
>> 
>> 
>> On 2017-11-27 23:38, Nicholas Smith wrote:
>>> Hi!
>>> 
>>> Will this also apply to the Sierra MC7430, as it is also raw-ip only?  If I 
>>> am not mistaken it is the same as the MC7455, just for the Asia/Pacific 
>>> region.  I would be able to verify this patch on the device.  To verify 
>>> that it works, do I just look for /sys/class/net/$ifname/qmi/raw_ip ?
>>> 
>>> Nicholas
>>> smith.nicholas...@gmail.com
>>> 
>> 
>> 
>> Judging by the datasheet compared to the MC7455 and some other resources 
>> online:  most likely yes.
>> Keep in mind that this will not work on the 17.01 branch as kernel 4.5 or 
>> better is required which contains the needed driver parts and fixes.
>> 
>> If you would like to evaluate, please use master branch.
>> 
>> Testing the patch in full checking connectivity is always better than just 
>> checking if that particular file is present.
>> You should see a print referring to raw-ip popping up using logread. (see 
>> patch contents)
>> 
>> 
>> Regards,
>> 
>> Koen
> 


___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev

[LEDE-DEV] [PATCH v2] dnsmaq: add interface to ubus notification

Re: [LEDE-DEV] fixing of image file names

[LEDE-DEV] [PATCH v3] dnsmaq: add interface to ubus notification

[LEDE-DEV] iodine bad endianess?

Re: [LEDE-DEV] WRT3200ACM crashes after mac80211 wireless-testing 2017-11-01

Re: [LEDE-DEV] iodine bad endianess?

[LEDE-DEV] [PATCH] procd: nand: dont rely on boardname in nand_upgrade_tar

[LEDE-DEV] Add support for Comfast E312A

Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

Re: [LEDE-DEV] add support for Comfast E314N

Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

Re: [LEDE-DEV] [PATCH 2/2] download.mk: introduce a new variable SKIPHASH

Re: [LEDE-DEV] [PATCH 1/2] scripts/download.pl: Add a --skip-hash option

Re: [LEDE-DEV] Add support for Comfast E312A

Re: [LEDE-DEV] [PATCH] ar71xx: add support for TP-Link TL-WDR7500v6

Re: [LEDE-DEV] STP, rSTP and MSTP

[LEDE-DEV] Invalid hash for usbip package

Re: [LEDE-DEV] fixing of image file names

Re: [LEDE-DEV] [PATCH v2] uqmi: fix raw-ip mode for newer lte modems

Re: [LEDE-DEV] [PATCH v2] uqmi: fix raw-ip mode for newer lte modems

20 matches

Site Navigation

Mail list logo

Footer information