[LEDE-DEV] [PATCH] ramips: Change ethernet driver to use napi_complete_done.

2017-09-06 Thread Rosen Penev 
Backport of mailine linux commit. Speeds up ethernet slightly and reduces 
latency.

Signed-off-by: Rosen Penev 
---
 target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c 
b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
index 5f4afade06..baa7a198d0 100644
--- a/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
+++ b/target/linux/ramips/files-4.9/drivers/net/ethernet/mtk/mtk_eth_soc.c
@@ -1003,7 +1003,7 @@ static int fe_poll(struct napi_struct *napi, int budget)
goto poll_again;
}
 
-   napi_complete(napi);
+   napi_complete_done(napi, rx_done);
fe_int_enable(tx_intr | rx_intr);
} else {
rx_done = budget;
-- 
2.13.5


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

[LEDE-DEV] [PATCH] dnsmasq: backport official fix for CVE-2017-13704

2017-09-06 Thread Kevin Darbyshire-Bryant 
Remove LEDE partial fix for CVE-2017-13704.

Backport official fix from upstream.

Signed-off-by: Kevin Darbyshire-Bryant 
---
Please cherrypick to LEDE 17.01

 .../patches/025-backport-fix-CVE-2017-13704.patch  | 94 ++
 .../dnsmasq/patches/025-fix-CVE-2017-13704.patch   | 37 -
 2 files changed, 94 insertions(+), 37 deletions(-)
 create mode 100644 
package/network/services/dnsmasq/patches/025-backport-fix-CVE-2017-13704.patch
 delete mode 100644 
package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch

diff --git 
a/package/network/services/dnsmasq/patches/025-backport-fix-CVE-2017-13704.patch
 
b/package/network/services/dnsmasq/patches/025-backport-fix-CVE-2017-13704.patch
new file mode 100644
index 000..bba9a08
--- /dev/null
+++ 
b/package/network/services/dnsmasq/patches/025-backport-fix-CVE-2017-13704.patch
@@ -0,0 +1,94 @@
+From 63437ffbb58837b214b4b92cb1c54bc5f3279928 Mon Sep 17 00:00:00 2001
+From: Simon Kelley 
+Date: Wed, 6 Sep 2017 22:34:21 +0100
+Subject: [PATCH] Fix CVE-2017-13704, which resulted in a crash on a large DNS
+ query.
+
+A DNS query recieved by UDP which exceeds 512 bytes (or the EDNS0 packet size,
+if different.) is enough to cause SIGSEGV.
+---
+ CHANGELOG |7 +++
+ src/auth.c|5 -
+ src/forward.c |8 
+ src/rfc1035.c |5 -
+ 4 files changed, 15 insertions(+), 10 deletions(-)
+
+diff --git a/CHANGELOG b/CHANGELOG
+index 3a640f3..7e65912 100644
+--- a/CHANGELOG
 b/CHANGELOG
+@@ -17,6 +17,13 @@ version 2.78
+   --strict-order active. Thanks to Hans Dedecker
+   for the patch
+ 
++  Fix regression in 2.77, ironically added as a security
++  improvement, which resulted in a crash when a DNS
++  query exceeded 512 bytes (or the EDNS0 packet size,
++  if different.) Thanks to Christian Kujau, Arne Woerner
++  Juan Manuel Fernandez and Kevin Darbyshire-Bryant for
++  chasing this one down.  CVE-2017-13704 applies.
++
+   
+ version 2.77
+   Generate an error when configured with a CNAME loop,
+diff --git a/src/auth.c b/src/auth.c
+index 2c24e16..7f95f98 100644
+--- a/src/auth.c
 b/src/auth.c
+@@ -119,11 +119,6 @@ size_t answer_auth(struct dns_header *header, char 
*limit, size_t qlen, time_t n
+   struct cname *a, *candidate;
+   unsigned int wclen;
+   
+-  /* Clear buffer beyond request to avoid risk of
+- information disclosure. */
+-  memset(((char *)header) + qlen, 0, 
+-   (limit - ((char *)header)) - qlen);
+-  
+   if (ntohs(header->qdcount) == 0 || OPCODE(header) != QUERY )
+ return 0;
+ 
+diff --git a/src/forward.c b/src/forward.c
+index f22556a..e3fa94b 100644
+--- a/src/forward.c
 b/src/forward.c
+@@ -1188,6 +1188,10 @@ void receive_query(struct listener *listen, time_t now)
+   (msg.msg_flags & MSG_TRUNC) ||
+   (header->hb3 & HB3_QR))
+ return;
++
++  /* Clear buffer beyond request to avoid risk of
++ information disclosure. */
++  memset(daemon->packet + n, 0, daemon->edns_pktsz - n);
+   
+   source_addr.sa.sa_family = listen->family;
+   
+@@ -1688,6 +1692,10 @@ unsigned char *tcp_request(int confd, time_t now,
+   
+   if (size < (int)sizeof(struct dns_header))
+   continue;
++
++  /* Clear buffer beyond request to avoid risk of
++   information disclosure. */
++  memset(payload + size, 0, 65536 - size);
+   
+   query_count++;
+ 
+diff --git a/src/rfc1035.c b/src/rfc1035.c
+index 26f5301..af2fe46 100644
+--- a/src/rfc1035.c
 b/src/rfc1035.c
+@@ -1223,11 +1223,6 @@ size_t answer_request(struct dns_header *header, char 
*limit, size_t qlen,
+   struct mx_srv_record *rec;
+   size_t len;
+ 
+-  /* Clear buffer beyond request to avoid risk of
+- information disclosure. */
+-  memset(((char *)header) + qlen, 0, 
+-   (limit - ((char *)header)) - qlen);
+-  
+   if (ntohs(header->ancount) != 0 ||
+   ntohs(header->nscount) != 0 ||
+   ntohs(header->qdcount) == 0 || 
+-- 
+1.7.10.4
+
diff --git 
a/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch 
b/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch
deleted file mode 100644
index 8848131..000
--- a/package/network/services/dnsmasq/patches/025-fix-CVE-2017-13704.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-From 38af9b1ac3242a4128e88069c495024caa565f0e Mon Sep 17 00:00:00 2001
-From: Kevin Darbyshire-Bryant 
-Date: Tue, 29 Aug 2017 12:35:40 +0100
-Subject: [PATCH] forward.c: fix CVE-2017-13704
-
-Fix SIGSEGV in rfc1035.c answer_request() line 1228 where memset()
-is called with header & limit pointing at the same address and thus
-tries to clear memory from before the buffer begins.
-
-answer_request() is called with an invalid edns packet size provided by
-the client.  Ensure the udp_size provided by the client is bounded by
-512 and configured maximum as per RFC 6891 6.2.3 "Values lower than

[LEDE-DEV] [PATCH] ath10k: Re-enable intermediate softqueues for all devices

2017-09-06 Thread Toke Høiland-Jørgensen 
The upstream ath10k driver disables the intermediate softqueues for some
devices. This patch reverts that behaviour and always enables the
softqueues (and associated bufferbloat fixes). We have had reports of people
running this with good results:
https://lists.bufferbloat.net/pipermail/make-wifi-fast/2017-September/001497.html

This also refreshes mac80211 patches.

Signed-off-by: Toke Høiland-Jørgensen 
---
 ...t-disable-wake_tx_queue-for-older-devices.patch | 27 ++
 .../patches/930-ath10k_add_tpt_led_trigger.patch   |  4 ++--
 2 files changed, 29 insertions(+), 2 deletions(-)
 create mode 100644 
package/kernel/mac80211/patches/332-ath10k-Revert-disable-wake_tx_queue-for-older-devices.patch

diff --git 
a/package/kernel/mac80211/patches/332-ath10k-Revert-disable-wake_tx_queue-for-older-devices.patch
 
b/package/kernel/mac80211/patches/332-ath10k-Revert-disable-wake_tx_queue-for-older-devices.patch
new file mode 100644
index 00..b4e7862264
--- /dev/null
+++ 
b/package/kernel/mac80211/patches/332-ath10k-Revert-disable-wake_tx_queue-for-older-devices.patch
@@ -0,0 +1,27 @@
+From 59f8c22bf1749c4a2b5947bfaebc677c259a1ad6 Mon Sep 17 00:00:00 2001
+From: dave taht 
+Date: Wed, 5 Oct 2016 20:09:15 -0700
+Subject: [PATCH 5/7] Revert "ath10k: disable wake_tx_queue for older devices"
+
+This reverts commit 4ca1807815aa6801aaced7fdefa9edacc2521767
+in the hope that we've fixed all the performance problems now.
+---
+
+--- a/drivers/net/wireless/ath/ath10k/mac.c
 b/drivers/net/wireless/ath/ath10k/mac.c
+@@ -8219,15 +8219,6 @@ int ath10k_mac_register(struct ath10k *a
+   ath10k_warn(ar, "failed to initialise DFS pattern 
detector\n");
+   }
+ 
+-  /* Current wake_tx_queue implementation imposes a significant
+-   * performance penalty in some setups. The tx scheduling code needs
+-   * more work anyway so disable the wake_tx_queue unless firmware
+-   * supports the pull-push mechanism.
+-   */
+-  if (!test_bit(ATH10K_FW_FEATURE_PEER_FLOW_CONTROL,
+-ar->running_fw->fw_file.fw_features))
+-  ar->ops->wake_tx_queue = NULL;
+-
+   ret = ath10k_mac_init_rd(ar);
+   if (ret) {
+   ath10k_err(ar, "failed to derive regdom: %d\n", ret);
diff --git 
a/package/kernel/mac80211/patches/930-ath10k_add_tpt_led_trigger.patch 
b/package/kernel/mac80211/patches/930-ath10k_add_tpt_led_trigger.patch
index 4cf1b9f92a..6137a50bcf 100644
--- a/package/kernel/mac80211/patches/930-ath10k_add_tpt_led_trigger.patch
+++ b/package/kernel/mac80211/patches/930-ath10k_add_tpt_led_trigger.patch
@@ -1,6 +1,6 @@
 --- a/drivers/net/wireless/ath/ath10k/mac.c
 +++ b/drivers/net/wireless/ath/ath10k/mac.c
-@@ -8003,6 +8003,21 @@ static int ath10k_mac_init_rd(struct ath
+@@ -8007,6 +8007,21 @@ static int ath10k_mac_init_rd(struct ath
return 0;
  }
  
@@ -22,7 +22,7 @@
  int ath10k_mac_register(struct ath10k *ar)
  {
static const u32 cipher_suites[] = {
-@@ -8248,6 +8263,12 @@ int ath10k_mac_register(struct ath10k *a
+@@ -8244,6 +8259,12 @@ int ath10k_mac_register(struct ath10k *a
ar->hw->wiphy->cipher_suites = cipher_suites;
ar->hw->wiphy->n_cipher_suites = ARRAY_SIZE(cipher_suites);
  
-- 
2.14.1


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

Re: [LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand framework

2017-09-06 Thread Weijie Gao 
Yes, I have to admit operations of GigaDevice's chips are the same.
All the chips have the same read/write/erase command sequences.
Differences are plane selection bits (Micron), die selection
(Micron/Winbond), buffered read/continuous read (Winbond) and ECC
status bits.
These differences can be abstracted to different functions chosen by
the flash id. So this won't be a problem.

As for the patches, may be I can submit patches to both generic-4.4
and generic-4.9, and remove patches from pistachio.
So this won't be a problem when ar71xx updates linux-4.9.

Sincerely,
Weijie


2017-09-06 3:25 GMT+08:00 Christian Lamparter via Lede-dev
:
> The sender domain has a DMARC Reject/Quarantine policy which disallows
> sending mailing list messages using the original "From" header.
>
> To mitigate this problem, the original message has been wrapped
> automatically by the mailing list software.
>
>
> -- 已转发邮件 --
> From: Christian Lamparter 
> To: Weijie Gao 
> Cc: LEDE Development List 
> Bcc:
> Date: Tue, 05 Sep 2017 21:24:48 +0200
> Subject: Re: [LEDE-DEV] [PATCHv2 3/4] kernel/4.4: add generic spi-nand 
> framework
> On Monday, September 4, 2017 1:48:38 PM CEST Weijie Gao wrote:
>> Yes. If I search "spi-nand linux" in Google, Micron's framework is the
>> first result.
>> However, Micron's patches are based on higher version of kernel, which
>> require lots of modifications to port to linux-4.4.
>> I choose the framework from LEDE's
>> target/linux/pistachio/patches-4.9/, which requires only few changes.
>
> Yes exactly this is my concern: all the porting of of out-of-tree patches.
> linux-4.4 has only about five to six more month left before the patches
> will run out:
>  (Projected EOL: Feb, 2018).
> So question is, what will ar71xx do in six month? Will it be updated to 4.9?
> Or will it be ported to the upcoming 4.14? (I don't know?) Would you be
> willing to stick around and be prepared to revisit the patch in this case too?
>
>> I've read nearly all datasheets from GigaDevice, Micron, Winbond,
>> Macronix, and other manufacturers. I found that their chips are not
>> full compatiable with each other.
>> For example, the ECC status bits definition. GigaDevice uses one
>> status to indicate the unrecoverable bits while Winbond uses two
>> statuses to indicate that.
>
>> And stacked die selection command is different between Micron and
>> Winbond. And Mircon's chip has its own plane selection bit.
>>
>> Even chips of the same manufacturer, the page size/OOB size and layout
>> can be different. You can see differences of GigaDevice's chips in
>> this patch.
>>
>> So, the mt29f_spinand is not enough, it's designed only for
>> Micron's chips.
> A micron engineer put it like this:
> 
>
> " As far as I've seen from the datasheets I have available (SPI NAND
> GigaDevice 1Gb/2Gb/4Gb, Micron 1Gb/2Gb/4Gb), the command sequencing
> is the same for read/write/erase operations (read: enable ECC, read to cache,
> wait, read from cache, check for errors, disable ECC; write: enable ECC,
> write enable, program load, program execute, wait, verify, disable ECC;
> erase: write enable, erase block, verify).
>
> Regarding the stream of bytes for each command, the problematic
> commands are the read from cache ones (read, fast read, read x2,
> read x4, read dual read quad) that have different command format
> (additional dummy bytes, a plane select bit to be set).
> Other differences are in the structure of the protection and status registers
> (some of them use more ECC and protection bits according to the size
> of the chip). Also, each has a different ECC layout "
>
> The funny thing is, that a micron engineer made a patch back in the day
> that had support for both the MT29F and your GD5F with
> 
> From the look of it, it seems easy to support the GD5F that way...
>
> So much so, that "this unification habbit" was picked up by imgtec
> for the pistachio!
>
> Just look at this pull request from an ImgTec engineer titled:
> "Add Imagination's Pistachio SoC and (Ci40) Marduk platform support" for
> openwrt project:
> 
>
> Look at the 
> target/linux/pistachio/patches-4.4/0001-mtd-nand-Introduce-SPI-NAND-framework.patch
> commit message:
>
> "5. mtd: spi-nand: Support common SPI NAND devices
> This commit uses the recently introduced SPI NAND framework to support
> Micron MT29F and Gigadevice GD5F serial NAND devices. These two families
> of devices are fairly similar and so they are supported with only minimal
> differences."
>
>> The framework I chose from
>>

[LEDE-DEV] [PATCH v4] ramips: Add support for the HNET C108

2017-09-06 Thread Kristian Evensen 
The HNET C108
(http://www.szhwtech88.com/Product-product-cid-100-id-4374.html) is a
mifi based on MT7602A, which has the following specifications:

* CPU: MT7620A
* 1x 10/100Mbps Ethernet.
* 16 MB Flash.
* 64 MB RAM.
* 1x USB 2.0 port. Only power is connected, this port is meant for
charging other devices.
* 1x mini-PCIe slots.
* 1x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.
* 6000 mAh battery.
* 5x controllable LEDs.

Works:
* Wifi.
* Switch.
* mini-PCIe slot. Only tested with a USB device (a modem).
* SIM slot.
* Sysupgrade.
* Button (reset).

Not working (also applies to the factory firmware):
* Wifi LED. It is always switched on, there is no relation to the
up/down state or activity of the wireless interface.

Not tested:
* SD card reader.

Notes:
* The C108 has no dedicated status LED. I therefore set the LAN LED as
status LED.

Installation:
The router comes pre-installed with OpenWRT, including a variant of
Luci. The initial firmware install can be done through this UI,
following normal procedure. I.e., access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to
keep existing settings.

Recovery:
If you brick the device, the C108 supports recovery using TFTP. Keep the
reset button pressed for ~5sec when booting to trigger TFTP. Set the
address of the network interface on your machine to 10.10.10.3/24, and
rename your image file to Kernal.bin.

v3->v4:
* Fixed typo in diag.sh.

v2->v3:
* Update description of USB port after discussing with factory.
* Updated Wifi LED description (thanks Mathias Kresin).
* Removed non-used GPIO bank and invalid portmap from dts, as well as
using absolute value for the gpio output value (thanks Mathias Kresin).
* Update size of firmware parition in Makefile to match factory firmware
(thanks Mathias Kresin).
* Respect ordering in diag.sh (thanks Mathias Kresin).

v1->v2:
* Update "Not working" based on more testing with factory firmware.
* Changed offset of LAN MAC address.

Signed-off-by: Kristian Evensen 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   3 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/C108.dts   | 177 +
 target/linux/ramips/image/mt7620.mk|   8 +
 7 files changed, 197 insertions(+)
 create mode 100644 target/linux/ramips/dts/C108.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 ff5d156f2c..83e1a94000 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -82,6 +82,10 @@ broadway)
set_usb_led "$board:red:diskmounted"
set_wifi_led "$board:red:wps_active"
;;
+c108)
+   ucidef_set_led_netdev "lan" "lan" "$board:green:lan" "eth0"
+   ucidef_set_led_netdev "modem" "modem" "$board:green:modem" "wwan0"
+   ;;
 c20i)
ucidef_set_led_switch "lan" "lan" "$board:blue:lan" "switch0" "0x1e"
ucidef_set_led_switch "wan" "wan" "$board:blue:wan" "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 df70a8b2ec..9284b1812f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -217,6 +217,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "9@eth0"
;;
+   c108|\
cf-wr800n)
ucidef_add_switch "switch0" \
"4:lan" "6t@eth0"
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..75171673bb 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -103,6 +103,9 @@ get_status_led() {
wrh-300cr)
status_led="$board:green:wps"
;;
+   c108)
+   status_led="$board:green:lan"
+   ;;
cf-wr800n|\
psg1208)
status_led="$board:white:wps"
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index fe66a87c2e..174e29e434 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -85,6 +85,9 @@ ramips_board_detect() {
*"Broadway")
name="broadway"
;;
+   *"C108")
+   name="c108"
+   ;;
*"C20i")
name="c20i"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh

Re: [LEDE-DEV] [PATCH uclient] uclient-http: fix Host: header for literal IPv6 addresses

2017-09-06 Thread Jo-Philipp Wich 
Hi Matthias,

> For literal IPv6 addresses, the host header must have the form
> 
> Host: [...]
> 
> including the square brackets, as it may also contain a port. Some 
> webservers ignore the missing brackets, while others will return
> error 400.
> 
> IPv6 addresses are determined by searching for ':' characters in the
> host, as neither IPv4 addresses nor DNS names can contain colons. An
> alternative would be to add a flag to the uclient_url struct; but as
> this struct is exposed in public headers, such a change could be
> considered an ABI change, making a backport difficult.
> 
> Signed-off-by: Matthias Schiffer  

I would've solved it the same way so ...

Acked-by: Jo-Philipp Wich 

~ Jo

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

Re: [LEDE-DEV] [PATCH v3] ramips: Add support for the HNET C108

2017-09-06 Thread Kristian Evensen 
On Wed, Sep 6, 2017 at 10:35 AM, Kristian Evensen
 wrote:
> The HNET C108
> (http://www.szhwtech88.com/Product-product-cid-100-id-4374.html) is a
> mifi based on MT7602A, which has the following specifications:
>
> * CPU: MT7620A
> * 1x 10/100Mbps Ethernet.
> * 16 MB Flash.
> * 64 MB RAM.
> * 1x USB 2.0 port. Only power is connected, this port is meant for
> charging other devices.
> * 1x mini-PCIe slots.
> * 1x SIM slots.
> * 1x 2.4Ghz WIFI.
> * 1x button.
> * 6000 mAh battery.
> * 5x controllable LEDs.
>
> Works:
> * Wifi.
> * Switch.
> * mini-PCIe slot. Only tested with a USB device (a modem).
> * SIM slot.
> * Sysupgrade.
> * Button (reset).
>
> Not working (also applies to the factory firmware):
> * Wifi LED. It is always switched on, there is no relation to the
> up/down state or activity of the wireless interface.
>
> Not tested:
> * SD card reader.
>
> Notes:
> * The C108 has no dedicated status LED. I therefore set the LAN LED as
> status LED.
>
> Installation:
> The router comes pre-installed with OpenWRT, including a variant of
> Luci. The initial firmware install can be done through this UI,
> following normal procedure. I.e., access the UI and update the firmware
> using the sysupgrade-image. Remember to select that you do not want to
> keep existing settings.
>
> Recovery:
> If you brick the device, the C108 supports recovery using TFTP. Keep the
> reset button pressed for ~5sec when booting to trigger TFTP. Set the
> address of the network interface on your machine to 10.10.10.3/24, and
> rename your image file to Kernal.bin.
>
> v2->v3:
> * Update description of USB port after discussing with factory.
> * Updated Wifi LED description (thanks Mathias Kresin).
> * Removed non-used GPIO bank and invalid portmap from dts, as well as
> using absolute value for the gpio output value (thanks Mathias Kresin).
> * Update size of firmware parition in Makefile to match factory firmware
> (thanks Mathias Kresin).
> * Respect ordering in diag.sh (thanks Mathias Kresin).
>
> v1->v2:
> * Update "Not working" based on more testing with factory firmware.
> * Changed offset of LAN MAC address.
>
> Signed-off-by: Kristian Evensen 
> ---
>  target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
>  .../linux/ramips/base-files/etc/board.d/02_network |   1 +
>  target/linux/ramips/base-files/etc/diag.sh |   3 +
>  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
>  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
>  target/linux/ramips/dts/C108.dts   | 177 
> +
>  target/linux/ramips/image/mt7620.mk|   8 +
>  7 files changed, 197 insertions(+)
>  create mode 100644 target/linux/ramips/dts/C108.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 ff5d156f2c..83e1a94000 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -82,6 +82,10 @@ broadway)
> set_usb_led "$board:red:diskmounted"
> set_wifi_led "$board:red:wps_active"
> ;;
> +c108)
> +   ucidef_set_led_netdev "lan" "lan" "$board:green:lan" "eth0"
> +   ucidef_set_led_netdev "modem" "modem" "$board:green:modem" "wwan0"
> +   ;;
>  c20i)
> ucidef_set_led_switch "lan" "lan" "$board:blue:lan" "switch0" "0x1e"
> ucidef_set_led_switch "wan" "wan" "$board:blue:wan" "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 df70a8b2ec..9284b1812f 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -217,6 +217,7 @@ ramips_setup_interfaces()
> ucidef_add_switch "switch0" \
> "1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "9@eth0"
> ;;
> +   c108|\
> cf-wr800n)
> ucidef_add_switch "switch0" \
> "4:lan" "6t@eth0"
> diff --git a/target/linux/ramips/base-files/etc/diag.sh 
> b/target/linux/ramips/base-files/etc/diag.sh
> index 960e189283..74352530b0 100644
> --- a/target/linux/ramips/base-files/etc/diag.sh
> +++ b/target/linux/ramips/base-files/etc/diag.sh
> @@ -103,6 +103,9 @@ get_status_led() {
> wrh-300cr)
> status_led="$board:green:wps"
> ;;
> +   c108)
> +   status_len="$board:green:lan"

Forgot to commit fix for this typo. Will send a v4.

-Kristian

> +   ;;
> cf-wr800n|\
> psg1208)
> status_led="$board:white:wps"
> diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
> b/target/linux/ramips/base-files/lib/ramips.sh
> index fe66a87c2e..174e29e434 100755
> --- a/target/linux/ramips/base-files/lib/ramips.sh
> +++

[LEDE-DEV] [PATCH v3] ramips: Add support for the HNET C108

2017-09-06 Thread Kristian Evensen 
The HNET C108
(http://www.szhwtech88.com/Product-product-cid-100-id-4374.html) is a
mifi based on MT7602A, which has the following specifications:

* CPU: MT7620A
* 1x 10/100Mbps Ethernet.
* 16 MB Flash.
* 64 MB RAM.
* 1x USB 2.0 port. Only power is connected, this port is meant for
charging other devices.
* 1x mini-PCIe slots.
* 1x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.
* 6000 mAh battery.
* 5x controllable LEDs.

Works:
* Wifi.
* Switch.
* mini-PCIe slot. Only tested with a USB device (a modem).
* SIM slot.
* Sysupgrade.
* Button (reset).

Not working (also applies to the factory firmware):
* Wifi LED. It is always switched on, there is no relation to the
up/down state or activity of the wireless interface.

Not tested:
* SD card reader.

Notes:
* The C108 has no dedicated status LED. I therefore set the LAN LED as
status LED.

Installation:
The router comes pre-installed with OpenWRT, including a variant of
Luci. The initial firmware install can be done through this UI,
following normal procedure. I.e., access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to
keep existing settings.

Recovery:
If you brick the device, the C108 supports recovery using TFTP. Keep the
reset button pressed for ~5sec when booting to trigger TFTP. Set the
address of the network interface on your machine to 10.10.10.3/24, and
rename your image file to Kernal.bin.

v2->v3:
* Update description of USB port after discussing with factory.
* Updated Wifi LED description (thanks Mathias Kresin).
* Removed non-used GPIO bank and invalid portmap from dts, as well as
using absolute value for the gpio output value (thanks Mathias Kresin).
* Update size of firmware parition in Makefile to match factory firmware
(thanks Mathias Kresin).
* Respect ordering in diag.sh (thanks Mathias Kresin).

v1->v2:
* Update "Not working" based on more testing with factory firmware.
* Changed offset of LAN MAC address.

Signed-off-by: Kristian Evensen 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   3 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/C108.dts   | 177 +
 target/linux/ramips/image/mt7620.mk|   8 +
 7 files changed, 197 insertions(+)
 create mode 100644 target/linux/ramips/dts/C108.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 ff5d156f2c..83e1a94000 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -82,6 +82,10 @@ broadway)
set_usb_led "$board:red:diskmounted"
set_wifi_led "$board:red:wps_active"
;;
+c108)
+   ucidef_set_led_netdev "lan" "lan" "$board:green:lan" "eth0"
+   ucidef_set_led_netdev "modem" "modem" "$board:green:modem" "wwan0"
+   ;;
 c20i)
ucidef_set_led_switch "lan" "lan" "$board:blue:lan" "switch0" "0x1e"
ucidef_set_led_switch "wan" "wan" "$board:blue:wan" "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 df70a8b2ec..9284b1812f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -217,6 +217,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "9@eth0"
;;
+   c108|\
cf-wr800n)
ucidef_add_switch "switch0" \
"4:lan" "6t@eth0"
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..74352530b0 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -103,6 +103,9 @@ get_status_led() {
wrh-300cr)
status_led="$board:green:wps"
;;
+   c108)
+   status_len="$board:green:lan"
+   ;;
cf-wr800n|\
psg1208)
status_led="$board:white:wps"
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index fe66a87c2e..174e29e434 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -85,6 +85,9 @@ ramips_board_detect() {
*"Broadway")
name="broadway"
;;
+   *"C108")
+   name="c108"
+   ;;
*"C20i")
name="c20i"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index

Re: [LEDE-DEV] [PATCH] ramips: Add support for the HNET C108

2017-09-06 Thread Kristian Evensen 
On Wed, Sep 6, 2017 at 10:07 AM, Mathias Kresin  wrote:
> 06.09.2017 09:26, Kristian Evensen:
>>
>> On Wed, Sep 6, 2017 at 9:03 AM, Mathias Kresin  wrote:

 * Wifi LED. It is always switched on.
>>>
>>>
>>>
>>> Always switched on in terms of no relation to the up/down state of the
>>> wireless interface or it doesn't blink on activity?
>>>
>>> Is the LED connected to the SoC? Have you tried to set the "wled" group
>>> to
>>> the gpio function? The wled group is only GPIO#72 ( 0).
>>
>>
>> No relation to the state. I tried to set the wled group + set gpio 72
>> to high/low, but it had no effect. Will update comment.
>
>
> Might be that the LED is connected to VCC and not controllable at all.
> Strange hw design but who knows..
>
>>
 diff --git a/target/linux/ramips/base-files/etc/diag.sh
 b/target/linux/ramips/base-files/etc/diag.sh
 index 960e189283..7b267a6854 100644
 --- a/target/linux/ramips/base-files/etc/diag.sh
 +++ b/target/linux/ramips/base-files/etc/diag.sh
 @@ -296,6 +296,9 @@ get_status_led() {
  zbt-wg3526-32M)
  status_led="zbt-wg3526:green:status"
  ;;
 +   c108)
 +   status_len="$board:green:lan"
 +   ;;
>>>
>>>
>>>
>>> Please keep alphabetical order!
>>
>>
>> I was trying to figure out the lexicographical order in this file :)
>> The different cases seems to group together devices with different
>> names, so I thought it safest to place my entry at the end since I did
>> not find another device with same LED name. Any suggestions for a
>> different location (or LED name) are more than welcome.
>
>
> Yeah, the file is out of alphabetical order again. Please add the c108 to
> line 106, right before the block starting with cf-wr800n.
>
>>
>> I missed the typo ("status_len"), so I will fix that for a v3.
>>
 +   power_modem {
 +   gpio-export,name = "power_modem";
 +   gpio-export,output = ;
>>>
>>>
>>>
>>> You set the output value to 1 here. Please use gpio-export,output = 1.
>>
>>
>> Based on feedback I have got on earlier patches, it is preferred to
>> use the _LOW/_HIGH constants than 0/1 directly.
>
>
> Most likely it was me who gave that advice. It was meant for the gpios
> device tree property. Here you are setting a value instead of describing
> active state. If there would be a macro, it should be something like
> GPIO_LOW or just LOW.

Thanks for the comments. Preparing a v3 now, will send it after some
quick testing.

-Kristian

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the HNET C108

2017-09-06 Thread Mathias Kresin 

06.09.2017 09:26, Kristian Evensen:

On Wed, Sep 6, 2017 at 9:03 AM, Mathias Kresin  wrote:

* Wifi LED. It is always switched on.



Always switched on in terms of no relation to the up/down state of the
wireless interface or it doesn't blink on activity?

Is the LED connected to the SoC? Have you tried to set the "wled" group to
the gpio function? The wled group is only GPIO#72 ( 0).


No relation to the state. I tried to set the wled group + set gpio 72
to high/low, but it had no effect. Will update comment.


Might be that the LED is connected to VCC and not controllable at all. 
Strange hw design but who knows..





diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..7b267a6854 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -296,6 +296,9 @@ get_status_led() {
 zbt-wg3526-32M)
 status_led="zbt-wg3526:green:status"
 ;;
+   c108)
+   status_len="$board:green:lan"
+   ;;



Please keep alphabetical order!


I was trying to figure out the lexicographical order in this file :)
The different cases seems to group together devices with different
names, so I thought it safest to place my entry at the end since I did
not find another device with same LED name. Any suggestions for a
different location (or LED name) are more than welcome.


Yeah, the file is out of alphabetical order again. Please add the c108 
to line 106, right before the block starting with cf-wr800n.




I missed the typo ("status_len"), so I will fix that for a v3.


+   power_modem {
+   gpio-export,name = "power_modem";
+   gpio-export,output = ;



You set the output value to 1 here. Please use gpio-export,output = 1.


Based on feedback I have got on earlier patches, it is preferred to
use the _LOW/_HIGH constants than 0/1 directly.


Most likely it was me who gave that advice. It was meant for the gpios 
device tree property. Here you are setting a value instead of describing 
active state. If there would be a macro, it should be something like 
GPIO_LOW or just LOW.


Mathias

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the HNET C108

2017-09-06 Thread Kristian Evensen 
Hi,

On Wed, Sep 6, 2017 at 9:46 AM, John Crispin  wrote:
> the mt7620 only has 1 usb port. if the minipcie usb works, then its wired
> there. maybe there is a gpio to switch between internal modem port and
> external port ?

Thanks for the help! I just spoke to the factory and it turns out that
port is meant for charging other devices, so data is not connected.

-Kristian

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the HNET C108

2017-09-06 Thread John Crispin 



On 06/09/17 09:26, Kristian Evensen wrote:

Hi,

Thanks for the feedback.

On Wed, Sep 6, 2017 at 9:03 AM, Mathias Kresin  wrote:

Not working:
* USB port.


What does not working means? Not detected? USB devices not powered (but are
working with an external powered hub)? Any error messages?

Not detected and no error messages, so it seems to be completely dead.
I see the same with the default firmware. Will update comment. If you
have any hints or tips on how to enable it, then that would be great.


the mt7620 only has 1 usb port. if the minipcie usb works, then its 
wired there. maybe there is a gpio to switch between internal modem port 
and external port ?


John


* Wifi LED. It is always switched on.


Always switched on in terms of no relation to the up/down state of the
wireless interface or it doesn't blink on activity?

Is the LED connected to the SoC? Have you tried to set the "wled" group to
the gpio function? The wled group is only GPIO#72 ( 0).

No relation to the state. I tried to set the wled group + set gpio 72
to high/low, but it had no effect. Will update comment.


diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..7b267a6854 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -296,6 +296,9 @@ get_status_led() {
 zbt-wg3526-32M)
 status_led="zbt-wg3526:green:status"
 ;;
+   c108)
+   status_len="$board:green:lan"
+   ;;


Please keep alphabetical order!

I was trying to figure out the lexicographical order in this file :)
The different cases seems to group together devices with different
names, so I thought it safest to place my entry at the end since I did
not find another device with same LED name. Any suggestions for a
different location (or LED name) are more than welcome.

I missed the typo ("status_len"), so I will fix that for a v3.


+   power_modem {
+   gpio-export,name = "power_modem";
+   gpio-export,output = ;


You set the output value to 1 here. Please use gpio-export,output = 1.

Based on feedback I have got on earlier patches, it is preferred to
use the _LOW/_HIGH constants than 0/1 directly.


+ {
+   status = "okay";
+};


gpio3 is enabled but not used. either use the only available GPIO on this
gpio bank or drop it.

Thanks, will remove it.


+ {
+   mtd-mac-address = < 0x4>;
+   mediatek,portmap = "l";


Beside that fact that I'm not sure if the property is supported by the
driver, it looks wrong. The mediatek,portmap property can be only "w" or
"w".

Yes, that is correct, but I saw that for another device (MR200) a
non-supported portmap is used (""). So I thought it was ok to add,
in case the portmap will in the future support more values (the driver
anyway ignores maps different than the two you mention). But I will
remove it for v3.


diff --git a/target/linux/ramips/image/mt7620.mk
b/target/linux/ramips/image/mt7620.mk
index f9a9fdb84c..0061a018b9 100644
--- a/target/linux/ramips/image/mt7620.mk
+++ b/target/linux/ramips/image/mt7620.mk
@@ -62,6 +62,14 @@ define Device/ArcherMR200
   endef
   TARGET_DEVICES += ArcherMR200
   +define Device/c108
+  DTS := C108
+  IMAGE_SIZE := $(ralink_default_fw_size_16M)


Doesn't match the size of your firmware partition.

ralink_default_fw_size_16M == 16121856 == 0xF6

Good catch, thanks. I based the dts on the dts of another 16MB mt7620
device. I will take a look at the bootlog of the default firmware and
correct firmware size.

Thanks again for all the feedback.

-Kristian

___
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] [PATCH] ramips: Add support for the HNET C108

2017-09-06 Thread Kristian Evensen 
Hi,

Thanks for the feedback.

On Wed, Sep 6, 2017 at 9:03 AM, Mathias Kresin  wrote:
>> Not working:
>> * USB port.
>
>
> What does not working means? Not detected? USB devices not powered (but are
> working with an external powered hub)? Any error messages?

Not detected and no error messages, so it seems to be completely dead.
I see the same with the default firmware. Will update comment. If you
have any hints or tips on how to enable it, then that would be great.

>
>> * Wifi LED. It is always switched on.
>
>
> Always switched on in terms of no relation to the up/down state of the
> wireless interface or it doesn't blink on activity?
>
> Is the LED connected to the SoC? Have you tried to set the "wled" group to
> the gpio function? The wled group is only GPIO#72 ( 0).

No relation to the state. I tried to set the wled group + set gpio 72
to high/low, but it had no effect. Will update comment.

>> diff --git a/target/linux/ramips/base-files/etc/diag.sh
>> b/target/linux/ramips/base-files/etc/diag.sh
>> index 960e189283..7b267a6854 100644
>> --- a/target/linux/ramips/base-files/etc/diag.sh
>> +++ b/target/linux/ramips/base-files/etc/diag.sh
>> @@ -296,6 +296,9 @@ get_status_led() {
>> zbt-wg3526-32M)
>> status_led="zbt-wg3526:green:status"
>> ;;
>> +   c108)
>> +   status_len="$board:green:lan"
>> +   ;;
>
>
> Please keep alphabetical order!

I was trying to figure out the lexicographical order in this file :)
The different cases seems to group together devices with different
names, so I thought it safest to place my entry at the end since I did
not find another device with same LED name. Any suggestions for a
different location (or LED name) are more than welcome.

I missed the typo ("status_len"), so I will fix that for a v3.

>> +   power_modem {
>> +   gpio-export,name = "power_modem";
>> +   gpio-export,output = ;
>
>
> You set the output value to 1 here. Please use gpio-export,output = 1.

Based on feedback I have got on earlier patches, it is preferred to
use the _LOW/_HIGH constants than 0/1 directly.

>> + {
>> +   status = "okay";
>> +};
>
>
> gpio3 is enabled but not used. either use the only available GPIO on this
> gpio bank or drop it.

Thanks, will remove it.

>> + {
>> +   mtd-mac-address = < 0x4>;
>> +   mediatek,portmap = "l";
>
>
> Beside that fact that I'm not sure if the property is supported by the
> driver, it looks wrong. The mediatek,portmap property can be only "w" or
> "w".

Yes, that is correct, but I saw that for another device (MR200) a
non-supported portmap is used (""). So I thought it was ok to add,
in case the portmap will in the future support more values (the driver
anyway ignores maps different than the two you mention). But I will
remove it for v3.

>> diff --git a/target/linux/ramips/image/mt7620.mk
>> b/target/linux/ramips/image/mt7620.mk
>> index f9a9fdb84c..0061a018b9 100644
>> --- a/target/linux/ramips/image/mt7620.mk
>> +++ b/target/linux/ramips/image/mt7620.mk
>> @@ -62,6 +62,14 @@ define Device/ArcherMR200
>>   endef
>>   TARGET_DEVICES += ArcherMR200
>>   +define Device/c108
>> +  DTS := C108
>> +  IMAGE_SIZE := $(ralink_default_fw_size_16M)
>
>
> Doesn't match the size of your firmware partition.
>
> ralink_default_fw_size_16M == 16121856 == 0xF6

Good catch, thanks. I based the dts on the dts of another 16MB mt7620
device. I will take a look at the bootlog of the default firmware and
correct firmware size.

Thanks again for all the feedback.

-Kristian

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

Re: [LEDE-DEV] [PATCH] ramips: Add support for the HNET C108

2017-09-06 Thread Mathias Kresin 

Hey Kristian,

I've picked your 01_leds file permission fix since it fixes an bug that 
I'm searching for a few days already.


Find comments from a first brief review inline.

Mathias

05.09.2017 21:48, Kristian Evensen:

The HNET C108
(http://www.szhwtech88.com/Product-product-cid-100-id-4374.html) is a
mifi based on MT7602A, which has the following specifications:

* CPU: MT7620A
* 1x 10/100Mbps Ethernet.
* 16 MB Flash.
* 64 MB RAM.
* 1x USB 2.0 port.
* 1x mini-PCIe slots.
* 1x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.
* 6000 mAh battery.
* 5x controllable LEDs.

Works:
* Wifi.
* Switch.
* mini-PCIe slot. Only tested with a USB device (a modem).
* SIM slot.
* Sysupgrade.
* Button (reset).

Not working:
* USB port.


What does not working means? Not detected? USB devices not powered (but 
are working with an external powered hub)? Any error messages?



* Wifi LED. It is always switched on.


Always switched on in terms of no relation to the up/down state of the 
wireless interface or it doesn't blink on activity?


Is the LED connected to the SoC? Have you tried to set the "wled" group 
to the gpio function? The wled group is only GPIO#72 ( 0).




Not tested:
* SD card reader.

Notes:
* The C108 has no dedicated status LED. I therefore set the LAN LED as
status LED.
* By default, both the LAN and Wifi interface has the same MAC address.
The factory firmware sets the MAC address of the Wifi interface to (LAN
+ 2) in order to avoid having the same MAC. I did not find an easy way
to accomplish this using the existing LEDE infrastructure. Instead, I
implemented the opposite, i.e., the MAC address of the LAN interface is
increased by two.
* In commit 77645ffcd9ad767be02ea6d5cfe042928a3565d1, the mode of
01_leds was set to 0644. This patch changes that back 0755.

Installation:
The router comes pre-installed with OpenWRT, including a variant of
Luci. The initial firmware install can be done through this UI,
following normal procedure. I.e., access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to
keep existing settings.

Recovery:
If you brick the device, the C108 supports recovery using TFTP. Keep the
reset button pressed for ~5sec when booting to trigger TFTP. Set the
address of the network interface on your machine to 10.10.10.3/24, and
rename your image file to Kernal.bin.

Signed-off-by: Kristian Evensen 
---
  target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
  .../linux/ramips/base-files/etc/board.d/02_network |   5 +
  target/linux/ramips/base-files/etc/diag.sh |   3 +
  target/linux/ramips/base-files/lib/ramips.sh   |   3 +
  .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
  target/linux/ramips/dts/C108.dts   | 182 +
  target/linux/ramips/image/mt7620.mk|   8 +
  7 files changed, 206 insertions(+)
  mode change 100644 => 100755 
target/linux/ramips/base-files/etc/board.d/01_leds
  create mode 100644 target/linux/ramips/dts/C108.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
old mode 100644
new mode 100755
index ff5d156f2c..83e1a94000
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -82,6 +82,10 @@ broadway)
set_usb_led "$board:red:diskmounted"
set_wifi_led "$board:red:wps_active"
;;
+c108)
+   ucidef_set_led_netdev "lan" "lan" "$board:green:lan" "eth0"
+   ucidef_set_led_netdev "modem" "modem" "$board:green:modem" "wwan0"
+   ;;
  c20i)
ucidef_set_led_switch "lan" "lan" "$board:blue:lan" "switch0" "0x1e"
ucidef_set_led_switch "wan" "wan" "$board:blue:wan" "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 df70a8b2ec..273a0a75c9 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -217,6 +217,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "9@eth0"
;;
+   c108|\
cf-wr800n)
ucidef_add_switch "switch0" \
"4:lan" "6t@eth0"
@@ -386,6 +387,10 @@ ramips_setup_macs()
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(mtd_get_mac_binary devdata 7)
;;
+   c108)
+   lan_mac=$(cat /sys/class/net/eth0/address)
+   lan_mac=$(macaddr_add "$lan_mac" 2)
+   ;;
cy-swr1100|\
dch-m225)
lan_mac=$(mtd_get_mac_ascii factory lanmac)
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..7b267a6854 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++

[LEDE-DEV] [PATCH v2] ramips: Add support for the HNET C108

2017-09-06 Thread Kristian Evensen 
The HNET C108
(http://www.szhwtech88.com/Product-product-cid-100-id-4374.html) is a
mifi based on MT7602A, which has the following specifications:

* CPU: MT7620A
* 1x 10/100Mbps Ethernet.
* 16 MB Flash.
* 64 MB RAM.
* 1x USB 2.0 port.
* 1x mini-PCIe slots.
* 1x SIM slots.
* 1x 2.4Ghz WIFI.
* 1x button.
* 6000 mAh battery.
* 5x controllable LEDs.

Works:
* Wifi.
* Switch.
* mini-PCIe slot. Only tested with a USB device (a modem).
* SIM slot.
* Sysupgrade.
* Button (reset).

Not working (both of these also applies to the factory firmware):
* USB port.
* Wifi LED. It is always switched on.

Not tested:
* SD card reader.

Notes:
* The C108 has no dedicated status LED. I therefore set the LAN LED as
status LED.
* In commit 77645ffcd9ad767be02ea6d5cfe042928a3565d1, the mode of
01_leds was set to 0644. This patch changes that back 0755.

Installation:
The router comes pre-installed with OpenWRT, including a variant of
Luci. The initial firmware install can be done through this UI,
following normal procedure. I.e., access the UI and update the firmware
using the sysupgrade-image. Remember to select that you do not want to
keep existing settings.

Recovery:
If you brick the device, the C108 supports recovery using TFTP. Keep the
reset button pressed for ~5sec when booting to trigger TFTP. Set the
address of the network interface on your machine to 10.10.10.3/24, and
rename your image file to Kernal.bin.

v1->v2:
* Update "Not working" based on more testing with factory firmware.
* Changed offset of LAN MAC address.

Signed-off-by: Kristian Evensen 
---
 target/linux/ramips/base-files/etc/board.d/01_leds |   4 +
 .../linux/ramips/base-files/etc/board.d/02_network |   1 +
 target/linux/ramips/base-files/etc/diag.sh |   3 +
 target/linux/ramips/base-files/lib/ramips.sh   |   3 +
 .../ramips/base-files/lib/upgrade/platform.sh  |   1 +
 target/linux/ramips/dts/C108.dts   | 182 +
 target/linux/ramips/image/mt7620.mk|   8 +
 7 files changed, 202 insertions(+)
 mode change 100644 => 100755 target/linux/ramips/base-files/etc/board.d/01_leds
 create mode 100644 target/linux/ramips/dts/C108.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
old mode 100644
new mode 100755
index ff5d156f2c..83e1a94000
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -82,6 +82,10 @@ broadway)
set_usb_led "$board:red:diskmounted"
set_wifi_led "$board:red:wps_active"
;;
+c108)
+   ucidef_set_led_netdev "lan" "lan" "$board:green:lan" "eth0"
+   ucidef_set_led_netdev "modem" "modem" "$board:green:modem" "wwan0"
+   ;;
 c20i)
ucidef_set_led_switch "lan" "lan" "$board:blue:lan" "switch0" "0x1e"
ucidef_set_led_switch "wan" "wan" "$board:blue:wan" "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 df70a8b2ec..9284b1812f 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -217,6 +217,7 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"1:lan" "2:lan" "3:lan" "4:lan" "0:wan" "9@eth0"
;;
+   c108|\
cf-wr800n)
ucidef_add_switch "switch0" \
"4:lan" "6t@eth0"
diff --git a/target/linux/ramips/base-files/etc/diag.sh 
b/target/linux/ramips/base-files/etc/diag.sh
index 960e189283..7b267a6854 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -296,6 +296,9 @@ get_status_led() {
zbt-wg3526-32M)
status_led="zbt-wg3526:green:status"
;;
+   c108)
+   status_len="$board:green:lan"
+   ;;
esac
 }
 
diff --git a/target/linux/ramips/base-files/lib/ramips.sh 
b/target/linux/ramips/base-files/lib/ramips.sh
index fe66a87c2e..174e29e434 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -85,6 +85,9 @@ ramips_board_detect() {
*"Broadway")
name="broadway"
;;
+   *"C108")
+   name="c108"
+   ;;
*"C20i")
name="c20i"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh 
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 3cb1d19a28..5cfca52ab1 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -29,6 +29,7 @@ platform_check_image() {
awm002-evb-8M|\
bc2|\
broadway|\
+   c108|\
carambola|\
cf-wr800n|\
cs-qr10|\
diff --git a/target/linux/ramips/dts/C108.dts