[OpenWrt-Devel] [PATCH] Add support for PandoraBox PBR-M1 Board
Hi all,
please find below patch that adds support for PandoraBox PBR-M1 Board
to OpenWRT trunk.
The board is based on mt7621 platform, and this patch
adds a separate profile for pbr-m1.
Best regards,
Tymon
From: tymon
Signed-off-by: tymon
---
target/linux/ramips/base-files/etc/board.d/01_leds | 5 +
.../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/PBR-M1.dts | 150 +
target/linux/ramips/image/Makefile | 7 +-
target/linux/ramips/mt7621/profiles/pbr-m1.mk | 22 +++
8 files changed, 191 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/PBR-M1.dts
create mode 100644 target/linux/ramips/mt7621/profiles/pbr-m1.mk
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 ad0062a..c63ff47 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -175,6 +175,11 @@ case $board in
set_wifi_led "7links:orange:wifi"
set_usb_led "7links:blue:storage"
;;
+pbr-m1)
+ucidef_set_led_netdev "internet" "internet" "pbr-m1:green:internet"
"eth0.2"
+ucidef_set_led_default "power" "power" "pbr-m1:green:power" "1"
+ucidef_set_led_default "sys" "sys" "pbr-m1:green:sys" "1"
+;;
sl-r7205)
set_wifi_led "rt2800pci-phy0::radio"
;;
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 4982566..b3dd1f1 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -129,6 +129,7 @@ ramips_setup_interfaces()
dir-320-b1 | \
dir-615-h1 | \
firewrt | \
+ pbr-m1 | \
hlk-rm04 | \
mt7621 | \
mt7628 | \
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index d6001c5..bfc92e5 100644
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -117,6 +117,9 @@ get_status_led() {
omni-emb-hpm)
status_led="emb:green:status"
;;
+ pbr-m1)
+ status_led="pbr-m1:green:sys"
+ ;;
psr-680w)
status_led="psr-680w:red:wan"
;;
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 0cb02c7..14ffc21 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -247,6 +247,9 @@ ramips_board_detect() {
*"OLinuXino-RT5350F-EVB")
name="olinuxino-rt5350f-evb"
;;
+ *"PBR-M1")
+ name="pbr-m1"
+ ;;
*"Petatel PSR-680W"*)
name="psr-680w"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 99cabbd..8d5f74f 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -53,6 +53,7 @@ platform_check_image() {
fonera20n | \
freestation5 | \
firewrt |\
+ pbr-m1 |\
hg255d | \
hlk-rm04 | \
ht-tm02 | \
diff --git a/target/linux/ramips/dts/PBR-M1.dts
b/target/linux/ramips/dts/PBR-M1.dts
new file mode 100644
index 000..76eae93
--- /dev/null
+++ b/target/linux/ramips/dts/PBR-M1.dts
@@ -0,0 +1,150 @@
+/dts-v1/;
+
+/include/ "mt7621.dtsi"
+
+/ {
+ compatible = "mediatek,mt7621-eval-board", "mediatek,mt7621-soc";
+ model = "PBR-M1";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x1000>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ sdhci@1013 {
+ status = "okay";
+ };
+
+ palmbus@1E00 {
+ spi@b00 {
+ status = "okay";
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "w25q256";
+ reg = <0 0>;
+ linux,modalias = "m25p80";
+ spi-max-frequency = <1000>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
On Tue, 2015-06-16 at 08:47 +0200, Steven Barth wrote: > That commit got reverted 4 months later Oh good. It was the wrong way to solve that, IMHO. > Source-Destination routing has been used to replace it for egress > traffic, i.e. there are simply no external (e.g. default) routes that > have a matching source-restriction. I'm not sure exactly what all of that meant but egress is my concern here so let's expand here. Ultimately, I don't see anything in the IPv6 routing table on my 14.07 router that prevents the LAN side of the 14.07 router from trying to access a ULA (or any other bogon) that is on the WAN side of the router (i.e. through the default route), because somebody incorrectly lists a ULA on their Internet facing DNS zone for example. I would have expected to see something along the lines of a: unreachable fc00::/7 dev lo metric 1024 error -128 but I don't. So what mechanism is (or should be) being used to accomplish that? Cheers, b. signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Renaming trunk to Dxx Dxx ?
Please rename trunk to Dxxx Dxxx something. It is a bit confusing when both trunk and CC15.05 claim to be Chaos Calmer. The clear identification of the two got more important now when trunk has started to use musl, and trunk and CC start to deviate further. I considered patching trunk's include/toplevel.mk and etc/banner in my own build to something imaginary, but it would much better if the official new name gets assigned (or should I say designated?) soon. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: mitigate cgroups config dependency changes
Memory Resource Controller no longer depends on Resource counters since Kernel version 4.0. Signed-off-by: Daniel Golle --- config/Config-kernel.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/config/Config-kernel.in b/config/Config-kernel.in index cc8df5a..86753ca 100644 --- a/config/Config-kernel.in +++ b/config/Config-kernel.in @@ -300,7 +300,7 @@ if KERNEL_CGROUPS config KERNEL_MEMCG bool "Memory Resource Controller for Control Groups" default n - depends on KERNEL_RESOURCE_COUNTERS + depends on KERNEL_RESOURCE_COUNTERS || LINUX_4_0 help Provides a memory resource controller that manages both anonymous memory and page cache. (See Documentation/cgroups/memory.txt) -- 2.4.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Renaming trunk to Dxx Dxx ?
On Tue, Jun 16, 2015 at 03:58:34PM +0300, Hannu Nyman wrote: > Please rename trunk to Dxxx Dxxx something. > > It is a bit confusing when both trunk and CC15.05 claim to be Chaos Calmer. > The clear identification of the two got more important now when trunk has > started to use musl, and trunk and CC start to deviate further. > > I considered patching trunk's include/toplevel.mk and etc/banner in my own > build to something imaginary, but it would much better if the official new > name gets assigned (or should I say designated?) soon. After the heated debate about concerning naming the next release, maybe the spelled-out release name should be configurable in menuconfig? Some Freifunk groups apparently consider running find | while read f; do sed -i 's/Designated Driver/Dirty Diamond/' "$f"; done libreCMC also defined spelled-out names for their releases: https://librecmc.org/librecmc/wiki?name=releases Cheers Daniel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] musl: provide wtmp compatibility stub for Linux-PAM.
Signed-off-by: Yousong Zhou
---
...ide-wtmp-compatibility-stub-for-Linux-PAM.patch | 104
1 file changed, 104 insertions(+)
create mode 100644
toolchain/musl/patches/200-Provide-wtmp-compatibility-stub-for-Linux-PAM.patch
diff --git
a/toolchain/musl/patches/200-Provide-wtmp-compatibility-stub-for-Linux-PAM.patch
b/toolchain/musl/patches/200-Provide-wtmp-compatibility-stub-for-Linux-PAM.patch
new file mode 100644
index 000..fd9d9b1
--- /dev/null
+++
b/toolchain/musl/patches/200-Provide-wtmp-compatibility-stub-for-Linux-PAM.patch
@@ -0,0 +1,104 @@
+From 57f783cdc46dd11a186dd6fb78ebba1a3986cf6d Mon Sep 17 00:00:00 2001
+From: Yousong Zhou
+Date: Tue, 16 Jun 2015 16:49:39 +0800
+Subject: [PATCH] Provide wtmp compatibility stub for Linux PAM.
+
+Adapted from a version by Raphael Cohn [1]
+
+ - Patch to musl to provide wtmp for Linux PAM,
+ http://www.openwall.com/lists/musl/2013/12/04/11
+
+Signed-off-by: Yousong Zhou
+---
+ include/utmp.h|6 +-
+ include/utmpx.h |9 +++--
+ src/legacy/utmp.c | 20
+ 3 files changed, 28 insertions(+), 7 deletions(-)
+ create mode 100644 src/legacy/utmp.c
+
+diff --git a/include/utmp.h b/include/utmp.h
+index 24e2da7..2338587 100644
+--- a/include/utmp.h
b/include/utmp.h
+@@ -7,11 +7,6 @@ extern "C" {
+
+ #include
+
+-#define ACCOUNTING 9
+-#define UT_NAMESIZE 32
+-#define UT_HOSTSIZE 256
+-#define UT_LINESIZE 32
+-
+ struct lastlog {
+ time_t ll_time;
+ char ll_line[UT_LINESIZE];
+@@ -39,6 +34,7 @@ int login_tty(int);
+
+ #define _PATH_UTMP "/dev/null/utmp"
+ #define _PATH_WTMP "/dev/null/wtmp"
++#define _PATH_LASTLOG "/dev/null/lastlog"
+
+ #define UTMP_FILE _PATH_UTMP
+ #define WTMP_FILE _PATH_WTMP
+diff --git a/include/utmpx.h b/include/utmpx.h
+index f0c3b01..12da4da 100644
+--- a/include/utmpx.h
b/include/utmpx.h
+@@ -14,14 +14,18 @@ extern "C" {
+
+ #include
+
++#define UT_NAMESIZE 32
++#define UT_HOSTSIZE 256
++#define UT_LINESIZE 32
++
+ struct utmpx
+ {
+ short ut_type;
+ pid_t ut_pid;
+ char ut_line[32];
+ char ut_id[4];
+- char ut_user[32];
+- char ut_host[256];
++ char ut_user[UT_NAMESIZE];
++ char ut_host[UT_HOSTSIZE];
+ struct {
+ short __e_termination;
+ short __e_exit;
+@@ -54,6 +58,7 @@ void updwtmpx(const char *, const struct utmpx *);
+ #define LOGIN_PROCESS 6
+ #define USER_PROCESS7
+ #define DEAD_PROCESS8
++#define ACCOUNTING 9
+
+ #ifdef __cplusplus
+ }
+diff --git a/src/legacy/utmp.c b/src/legacy/utmp.c
+new file mode 100644
+index 000..4c94547
+--- /dev/null
b/src/legacy/utmp.c
+@@ -0,0 +1,20 @@
++#include
++#include
++#include
++#include
++#include "libc.h"
++
++void logwtmp(const char * line, const char * name, const char * host)
++{
++struct utmp u;
++memset(&u, 0, sizeof(u));
++
++u.ut_pid = getpid();
++u.ut_type = name[0] ? USER_PROCESS : DEAD_PROCESS;
++strncpy(u.ut_line, line, sizeof(u.ut_line));
++strncpy(u.ut_name, name, sizeof(u.ut_name));
++strncpy(u.ut_host, host, sizeof(u.ut_host));
++gettimeofday(&(u.ut_tv), NULL);
++
++updwtmp(_PATH_WTMP, &u);
++}
+--
+1.7.10.4
+
--
1.7.10.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
You should see an unreachable route for your own local ULA /48. Also if your clients try to use your local ULA as source to reach anything outside of the ULA (e.g. global addresses) this is blocked (there is no matching route - simpler explanation to my previous post). I don't see any particular point to blocking all of the ULA-space as destination though. If you think its useful for you you can either add a firewall route or an unreachable route manually in /etc/config/firewall or /etc/config/network respectively. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
On Tue, 2015-06-16 at 17:05 +0200, Steven Barth wrote: > You should see an unreachable route for your own local ULA /48. Indeed: fd31:aeb1:48df::/64 dev br-lan proto static metric 1024 unreachable fd31:aeb1:48df::/48 dev lo proto static metric 2147483647 error -128 > Also if your clients try to use your local ULA as source to reach > anything outside of the ULA (e.g. global addresses) this is blocked > (there is no matching route - simpler explanation to my previous post). Hrm. How is that done, since that is source-route matching? Not via the normal routing table, right? > I don't see any particular point to blocking all of the ULA-space as > destination though. The point is to give an immediate failure (i.e. ENETUNREACH) to misguided attempts to connect to the ULA space via one's Internet connection. These typically happen when somebody else misguidedly puts the ULA address for their host into their global DNS zone instead of the global address. Yes, it should just time out eventually, but why make them wait for that? > If you think its useful for you It seems to me to be useful to everybody. And TBH, I'm surprised it's not a requirement of some RFC, as I was unable to find any such requirement although I found recommendations. Cheers, b. signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
Source-Destination matching is done in the regular routing table. E.g. for my he.net connection the v6 routing table looks like this: default from 2001:470:xx:yyy::/64 dev 6in4-henet proto static metric 1024 default from 2001:470:::/48 dev 6in4-henet proto static metric 1024 if you try to send with a ULA there is no matching route since there is no unspecific default route. Also I disagree about the general usefulness of a fc00::/7 block. I can imagine e.g. a VPN-scenario where (on top of tunneling internet access) you access certain local services which have ULAs. This would essentially be broken by your generic rule for not much added gain. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] firewall instead of routing rules to keep ULAs from escaping
On Tue, 2015-06-16 at 18:56 +0200, Steven Barth wrote: > Source-Destination matching is done in the regular routing table. > E.g. for my he.net connection the v6 routing table looks like this: > > default from 2001:470:xx:yyy::/64 dev 6in4-henet proto static metric 1024 > default from 2001:470:::/48 dev 6in4-henet proto static metric 1024 A. I see what you are saying now. > if you try to send with a ULA there is no matching route since there is > no unspecific default route. Unfortunately I do have such a route (that is not Source matching in addition to the destination): default via 2001:470:aa:bbb::1 dev 6in4-henet metric 1024 This is likely due to Shorewall and LSM managing a default route in a multi-isp configuration. > Also I disagree about the general usefulness of a fc00::/7 block. I can > imagine e.g. a VPN-scenario where (on top of tunneling internet access) > you access certain local services which have ULAs. This would > essentially be broken by your generic rule for not much added gain. But (and yes) if you had an fc00::/7 unreachable route, any ULAs you need to reach need to have more specific routes, but one should have those because one should be getting those through a routing protocol. It just seems to make sense to me that on a router that would otherwise route ULAs out to a network where ULAs have not been announced should prevent them from going there. I guess that's a point we might just have to agree to disagree on. But you are right about the Source-Destination matching should take care of net letting ULAs out. I just have something in my configuration that is defeating that at the moment. :-( Thanks very much for your patience on this. b. signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add support for WeIO board
---
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 3 +-
target/linux/ar71xx/config-3.18| 1 +
.../linux/ar71xx/files/arch/mips/ath79/mach-weio.c | 162 +
target/linux/ar71xx/generic/profiles/weio.mk | 17 +++
target/linux/ar71xx/image/Makefile | 8 +
.../610-MIPS-ath79-openwrt-machines.patch | 21 ++-
7 files changed, 209 insertions(+), 6 deletions(-)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
create mode 100644 target/linux/ar71xx/generic/profiles/weio.mk
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index b13be1e..fe7478c 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -892,6 +892,9 @@ ar71xx_board_detect() {
"8devices Carambola2"*)
name="carambola2"
;;
+ *"WeIO")
+ name="weio"
+ ;;
*"Sitecom WLR-8100")
name="wlr8100"
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 3dbd91c..0f2920b 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -243,7 +243,8 @@ platform_check_image() {
nbg460n_550n_550nh | \
unifi | \
unifi-outdoor | \
- carambola2 )
+ carambola2 | \
+ weio )
[ "$magic" != "2705" ] && {
echo "Invalid image type."
return 1
diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18
index 543b77e..e81ba51 100644
--- a/target/linux/ar71xx/config-3.18
+++ b/target/linux/ar71xx/config-3.18
@@ -126,6 +126,7 @@ CONFIG_ATH79_MACH_TL_WR941ND=y
CONFIG_ATH79_MACH_TUBE2H=y
CONFIG_ATH79_MACH_UBNT=y
CONFIG_ATH79_MACH_UBNT_XM=y
+CONFIG_ATH79_MACH_WEIO=y
CONFIG_ATH79_MACH_WHR_HP_G300N=y
CONFIG_ATH79_MACH_WLAE_AG300N=y
CONFIG_ATH79_MACH_WLR8100=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
new file mode 100644
index 000..2ac4f92
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-weio.c
@@ -0,0 +1,162 @@
+/**
+ * WEIO Web Of Things Platform
+ *
+ * Copyright (C) 2013 Drasko DRASKOVIC and Uros PETREVSKI
+ *
+ * ## ## ###
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ## ## ## #### ## ##
+ * ### ### ###
+ *
+ * Web Of Things Platform
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Authors :
+ * Drasko DRASKOVIC
+ * Uros PETREVSKI
+ */
+
+#include
+#include
+#include "common.h"
+#include "dev-eth.h"
+#include "dev-gpio-buttons.h"
+#include "dev-leds-gpio.h"
+#include "dev-m25p80.h"
+#include "dev-spi.h"
+#include "dev-usb.h"
+#include "dev-wmac.h"
+#include "machtypes.h"
+#include "linux/i2c-gpio.h"
+#include "linux/platform_device.h"
+
+#define WEIO_GPIO_LED_STA 1
+#define WEIO_GPIO_LED_AP 16
+//#define WEIO_GPIO_LED_ETH0 13
+
+#define WEIO_GPIO_BTN_AP 20
+#define WEIO_GPIO_BTN_RESET23
+
+#define WEIO_KEYS_POLL_INTERVAL20 /* msecs */
+#define WEIO_KEYS_DEBOUNCE_INTERVAL(3 * WEIO_KEYS_POLL_INTERVAL)
+
+#define WEIO_MAC0_OFFSET 0x
+#define WEIO_MAC1_OFFSET 0x0006
+#define WEIO_CALDATA_OFFSET0x1000
+#define WEIO_WMAC_MAC_OFFSET 0x1002
+
+static struct gpio_led weio_leds_gpio[] __initdata = {
+ {
+ .name = "weio:green:sta",
+ .gpio = WEIO_GPIO_LED_STA,
+ .active_low = 1,
+.default_state = LEDS_GPIO_DEFSTATE_ON,
+ }, {
+ .name = "weio:green:ap",
+ .gpio = WEIO_GPIO_LED_AP,
+
Re: [OpenWrt-Devel] [PATCH] Add Support for WeIO Board (Chaos Calmer)
HI all, I have just re-sent patch through `git send-email`. I have corrected following: - Added GPLv2 header - Corrected alphabetical order everywhere where I saw it was respected - removed eth0 and other carambola2 LED related stuff Best regards, Drasko ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4 0/2] Support Ubiquiti Unifi Outdoor Plus HSR filter
Hi, so we arrive at the fourth iteration of the patchset to support the HSR of the Ubiquiti Unifi Outdoor Plus access point. This version implements the suggestions from Felix. We lost the feature to avoid tuning the same channel multiple times in a row, but this should not be critical. The HSR is a configurable RF filter in the receive path that must be tuned according to the selected Wifi channel for the access point to work. Patch 1 adds a ubnt_hsr flag to struct ath9k_platform_data and enables it for the Outdoor Plus access point. Patch 2 adds the HSR tuner to the ath9k driver as a configurable option, controller by the ubnt_hsr flag. The patchset is based on work of Kirill Berezin and me. The patch is against chaos_calmer branch and running on the access point right now. It applies against trunk, too, however this resulted in a bricked access point that did not boot at all. I don't know if that happened because of the patch, the new libc or due to Alexander's conversion to the new build code. I'm happy that I could recover via TFTP and I'm not too eager to retest trunk because the device is borrowed. I also compiled the brcm47xx platform successfully. Stefan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 1/2] Add ubnt_hsr platform flag and enable for UniFi Outdoor Plus
Add ubnt_hsr flag to struct ath9k_platform_data and enable it for the Outdoor Plus access point so that the availability ot the HSR filter can be detected by the ath9k driver at runtime. Signed-off-by: Stefan Rompf --- Index: package/kernel/mac80211/patches/150-ath9k_ubnt_hsr_filter.patch === --- package/kernel/mac80211/patches/150-ath9k_ubnt_hsr_filter.patch (Revision 0) +++ package/kernel/mac80211/patches/150-ath9k_ubnt_hsr_filter.patch (Arbeitskopie) @@ -0,0 +1,15 @@ +Flag that this platform is an Ubiquiti UniFi Outdoor Plus +containing a RF filter in ath9k's receive path. + +Signed-off-by: Stefan Rompf + +--- mac80211/include/linux/ath9k_platform.h.orig 2015-06-15 22:18:46.0 +0200 mac80211/include/linux/ath9k_platform.h2015-06-15 22:15:23.0 +0200 +@@ -36,6 +36,7 @@ + bool tx_gain_buffalo; + bool disable_2ghz; + bool disable_5ghz; ++ bool ubnt_hsr; + + int (*get_mac_revision)(void); + int (*external_reset)(void); Index: target/linux/generic/patches-3.18/150-ath9k_ubnt_hsr_filter.patch === --- target/linux/generic/patches-3.18/150-ath9k_ubnt_hsr_filter.patch (Revision 0) +++ target/linux/generic/patches-3.18/150-ath9k_ubnt_hsr_filter.patch (Arbeitskopie) @@ -0,0 +1,15 @@ +Flag that this platform is an Ubiquiti UniFi Outdoor Plus +containing a RF filter in ath9k's receive path. + +Signed-off-by: Stefan Rompf + +--- linux-3.18.14/include/linux/ath9k_platform.h.orig 2015-06-15 22:18:46.0 +0200 linux-3.18.14/include/linux/ath9k_platform.h 2015-06-15 22:15:23.0 +0200 +@@ -36,6 +36,7 @@ + bool tx_gain_buffalo; + bool disable_2ghz; + bool disable_5ghz; ++ bool ubnt_hsr; + + int (*get_mac_revision)(void); + int (*external_reset)(void); Index: target/linux/ar71xx/patches-3.18/608-MIPS-ath79-ubnt-xm-add-more-boards.patch === --- target/linux/ar71xx/patches-3.18/608-MIPS-ath79-ubnt-xm-add-more-boards.patch (Revision 46000) +++ target/linux/ar71xx/patches-3.18/608-MIPS-ath79-ubnt-xm-add-more-boards.patch (Arbeitskopie) @@ -254,6 +254,7 @@ + ath79_register_eth(0); + ath79_register_eth(1); + ++ ap9x_pci_get_wmac_data(0)->ubnt_hsr = true; + ap91_pci_init(ee, NULL); + + ath79_register_leds_gpio(-1, ARRAY_SIZE(ubnt_unifi_outdoor_plus_leds_gpio), ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v4 2/2] Add HSR tuner to ath9k
Add tuner for the HSR filter of the UniFi Outdoor Plus access point. Usage of
the tuner is controlled at runtime by ath9k_platform_data. The code can be
enabled or disabled by a compile time option.
Signed-off-by: Stefan Rompf
---
Index: package/kernel/mac80211/Makefile
===
--- package/kernel/mac80211/Makefile(Revision 46000)
+++ package/kernel/mac80211/Makefile(Arbeitskopie)
@@ -587,6 +587,11 @@
bool "Support chips used in PC OEM cards"
depends on PACKAGE_kmod-ath9k
+ config ATH9K_UBNTHSR
+ bool "Support for Ubiquiti UniFi Outdoor Plus access point"
+ depends on PACKAGE_kmod-ath9k
+ default y
+
endef
define KernelPackage/ath9k-htc
@@ -1558,6 +1563,7 @@
config-$(CONFIG_PCI) += ATH9K_PCI
config-$(CONFIG_ATH_USER_REGD) += ATH_USER_REGD
config-$(CONFIG_ATH9K_SUPPORT_PCOEM) += ATH9K_PCOEM
+config-$(CONFIG_ATH9K_UBNTHSR) += ATH9K_UBNTHSR
config-$(call config_package,ath9k-htc) += ATH9K_HTC
config-$(call config_package,ath10k) += ATH10K ATH10K_PCI
Index: package/kernel/mac80211/patches/930-ubnt-uap-plus-hsr.patch
===
--- package/kernel/mac80211/patches/930-ubnt-uap-plus-hsr.patch (Revision 0)
+++ package/kernel/mac80211/patches/930-ubnt-uap-plus-hsr.patch (Arbeitskopie)
@@ -0,0 +1,373 @@
+--- compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k.orig/channel.c
2015-06-16 09:28:34.0 +0200
compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/channel.c
2015-06-16 09:49:53.0 +0200
+@@ -15,6 +15,8 @@
+ */
+
+ #include "ath9k.h"
++#include
++#include "hsr.h"
+
+ /* Set/change channels. If the channel is really being changed, it's done
+ * by reseting the chip. To accomplish this we must first cleanup any pending
+@@ -22,6 +24,7 @@
+ */
+ static int ath_set_channel(struct ath_softc *sc)
+ {
++ struct ath9k_platform_data *pdata = sc->dev->platform_data;
+ struct ath_hw *ah = sc->sc_ah;
+ struct ath_common *common = ath9k_hw_common(ah);
+ struct ieee80211_hw *hw = sc->hw;
+@@ -41,6 +44,11 @@
+ ath_dbg(common, CONFIG, "Set channel: %d MHz width: %d\n",
+ chan->center_freq, chandef->width);
+
++ if (pdata && pdata->ubnt_hsr) {
++ hsr_enable(ah, chandef->width, chan->center_freq);
++ hsr_status(ah);
++ }
++
+ /* update survey stats for the old channel before switching */
+ spin_lock_bh(&common->cc_lock);
+ ath_update_survey_stats(sc);
+--- compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k.orig/hsr.c
1970-01-01 01:00:00.0 +0100
compat-wireless-2015-03-09/drivers/net/wireless/ath/ath9k/hsr.c
2015-06-16 09:41:24.0 +0200
+@@ -0,0 +1,220 @@
++/*
++ *
++ * The MIT License (MIT)
++ *
++ * Copyright (c) 2015 Kirill Berezin
++ *
++ * Permission is hereby granted, free of charge, to any person obtaining a
copy
++ * of this software and associated documentation files (the "Software"), to
deal
++ * in the Software without restriction, including without limitation the
rights
++ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
++ * copies of the Software, and to permit persons to whom the Software is
++ * furnished to do so, subject to the following conditions:
++ *
++ * The above copyright notice and this permission notice shall be included in
all
++ * copies or substantial portions of the Software.
++ *
++ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
++ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
++ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
++ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
++ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
++ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
++ * SOFTWARE.
++ *
++ */
++
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++#include
++
++#include "hw.h"
++#include "ath9k.h"
++
++#define HSR_GPIO_CSN 8
++#define HSR_GPIO_CLK 6
++#define HSR_GPIO_DOUT 7
++#define HSR_GPIO_DIN 5
++
++/* delays are in useconds */
++#define HSR_DELAY_HALF_TICK 100
++#define HSR_DELAY_PRE_WRITE 75
++#define HSR_DELAY_FINAL 2
++#define HSR_DELAY_TRAILING 200
++
++
++void hsr_init(struct ath_hw* ah) {
++ ath9k_hw_cfg_gpio_input(ah, HSR_GPIO_DIN);
++ ath9k_hw_cfg_output(ah, HSR_GPIO_CSN, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
++ ath9k_hw_cfg_output(ah, HSR_GPIO_CLK, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
++ ath9k_hw_cfg_output(ah, HSR_GPIO_DOUT, AR_GPIO_OUTPUT_MUX_AS_OUTPUT);
++
++ ath9k_hw_set_gpio(ah, HSR_GPIO_CSN, 1);
++ ath9k_hw_set_gpio(ah, HSR_GPIO_CLK, 0);
++ ath9k_hw_set_gpio(ah, HSR_GPIO_DOUT, 0);
++
++
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc2
On 06/13/15, Steven Barth wrote: The OpenWrt developers are proud to announce the first release candidateof OpenWrt Chaos Calmer. ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M - CHAOS CALMER (15.05 RC2) -Upgrading from RC1 I ran into problems because opkg was still configured for rc1.I modified /etc/opkg.conf manually and changed all rc1 to rc2 and it worked fine.This was on a buffalo wzr-600dhp using image:openwrt-15.05-rc2-ar71xx-generic-wzr-600dhp-squashfs-sysupgrade.bin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Add support for WeIO board
Missing Signed-off-by tag and description of the patch. Le 06/16/15 14:06, Drasko DRASKOVIC a écrit : -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Chaos Calmer 15.05-rc2
Anyone ? I am still investigating this issue and trying to figure out if it's a Openwrt or ISP problem. Would that changelog have anything to do with this ? Fernando On 13/06/2015 12:43, Fernando Frediani wrote: Hi folks, I'm seeing an issue on my Barrier Breaker running on a TP-Link WR842ND where it gets an IPv6 /128 to the WAN interface + /64 on the LAN interface via DHCPv6 + PD, however it does NOT set the default gateway by default, so I have to discover it and set manually using the other-side link-local. Even though eventually while running and after a few "Save & Apply" it "mysteriously" looses the same default gateway I have set manually (I'm guessing due DHCPv6 changing it every in a while to the original when it booted - none). And it can't ping it anymore (the other-side link local address). By the way, it's a cable connection. For comparison I have another router running DD-WRT from 22/Nov/2014 connected to the same ISP in another point of the city and it works fine DHCPv6, sets the default gateway by default and never looses it. By any chance this changelog "/Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling/" would perhaps have anything to do with that problem observed ? Thanks Fernando On 13/06/2015 11:21, Steven Barth wrote: The OpenWrt developers are proud to announce the first release candidate of OpenWrt Chaos Calmer. ___ __ | |.-.-.-.| | | |..| |_ | - || _ | -__| || | | || _|| _| |___|| __|_|__|__||||__| || |__| W I R E L E S S F R E E D O M - CHAOS CALMER (15.05 RC2) - * 1 1/2 oz GinShake with a glassful * 1/4 oz Triple Sec of broken ice and pour * 3/4 oz Lime Juice unstrained into a goblet. * 1 1/2 oz Orange Juice * 1 tsp. Grenadine Syrup - - http://downloads.openwrt.org/chaos_calmer/15.05-rc2/ ** Improvements since RC 1 ** * Fixed broken ImageBuilders for most targets * Updated 3.18 to 3.18.14 * Fixed broken IPv6 downstream DHCPv6-PD and onlink-route handling * Images (special format) for Asus brcm47xx and bcm53xx devices * Improved stability of sysupgrade on brcm47xx and bcm53xx * Added HTTPS enforcement option to uhttpd * Fixed umask issue * Added support for a few new boards ** Highlights since Barrier Breaker ** * Linux kernel updated to version 3.18 * Improved Security Features - Rewritten package signing architecture based on ed25519 - Added support for jails - Added support for hardened builds * Improved Networking Support - Added or improved support for lots of 3G/4G modems (MBIM, QMI, NCM, ...) - Added support for 464XLAT (CLAT) [RFC 6877 + RFC 7050] - Netfilter performance enhancements (conntrack route cache) - Improved support for self-managing networks [draft-ietf-homenet-hncp] - Better multi-core support for the network stack - Improved support for MAP-E, MAP-T and LW4over6 IPv4 transitioning technologies [draft-ietf-softwire-map, -map-t, -map-dhcp, -lw4over6] - Improved network auto-setup capable of detecting and bootstrapping IPv4-only, 6rd, Dual-Stack, IPv6-only, DS-Lite, LW4over6, MAP-E, MAP-T, 464XLAT and combinations without explicit configuration [based on RFC 7084] - Added support for Smart Queue Management (SQM) QoS, AQM and Traffic Shaping - Improved support for DNSSEC * Platform and Driver Support - Added support for feeds of externally maintained targets - New mt7621 subtarget for Mediatek 11ac SoC - New mt76 mac80211 based wifi driver for MTK 11ac cores. - New mwlwifi mac80211 based wifi driver for the Marvell 88W8864 - New bcm53xx target for Broadcom ARM BCM47xx/53xx devices - New mxs target for Freescale i.MX23/28 family and various boards - New sunxi target for AllWinner A10/A13/A20 family and various boards - brcm2708: support for Raspberry Pi 2 - brcm63xx: support for BCM6318 and BCM63268 family - brcm63xx: improved fallback sprom support with bcma support * Known Issues - Sysupgrade on brcm47xx may fail by running out of memory when using .bin or .chk files. Please use .trx when using rc1 (it was fixed in rc2). - openssl and strongswan are outdated. If you intend to use either of them please update the packages using the snapshots repository: https://downloads.openwrt.org/snapshots/trunk/ And lots and lots of other advancements... As always a big thank you goes to all our active package maintainers, testers, supporters and documenters. Have fun! The OpenWrt developer team ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.
Re: [OpenWrt-Devel] [PATCH] cyassl: version bump
On Wed, 2015-05-20 at 15:34 -0700, Daniel Gimpelevich wrote: > On Thu, 2015-05-21 at 00:19 +0200, Hauke Mehrtens wrote: > > On 05/20/2015 11:42 PM, Daniel Gimpelevich wrote: > > > This patch introduces a new build error into coova-chilli, but > > > coova-chilli already fails to build even without it anyway. CyaSSL is > > > now called wolfSSL, and all the API's have been renamed, and > > > backward-compatibility headers added. > > > > Does this fix any security Issues? Otherwise I would wait till the > > branch to update this library. > > > > Hauke > > > > It's mostly new features and many bug fixes, though there are a few > minor security-related changes relating to obsolete algorithms and > protocols. The changelog contains the following note: > > - No high level security fixes that requires an update though we always > recommend updating to the latest (except note 6 use case of ecc/normal math) > > It should be noted that since version 3.3.0, there have been versions > 3.3.2, 3.4.0, and 3.4.6 now. > > It might be worth fixing the coova-chilli package to build before the > branch so that it isn't stuck with a broken package, but if anyone does > that without this patch, applying this patch will re-break it, so it > might pay to do this a priori. If you disagree, I believe the branch is > scheduled for this week, so the wait wouldn't be long. Chaos Calmer has been branched. Time to apply the patch? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [generic] ramips: adding support for OYE-0001 Wireless Router
From: Tom Deng <2579131...@qq.com>
Adding support for OYE-0001 Wireless Router.
OYE-0001 is a wireless router made by oyewifi.com. Below is the details:
MT7620A, 128MB DDR2, 16MB FLASH, SD Slot, USB 2.0, 4 x LAN + 1 x WAN.
Signed-off-by: Tom Deng <2579131...@qq.com>
---
Index: target/linux/ramips/base-files/etc/diag.sh
===
--- target/linux/ramips/base-files/etc/diag.sh(revision 43797)
+++ target/linux/ramips/base-files/etc/diag.sh(working copy)
@@ -185,6 +185,9 @@
f7c027)
status_led="belkin:orange:status"
;;
+oye-0001)
+status_led="oye:green:wifi"
+;;
na930)
status_led="na930:blue:power"
;;
Index: target/linux/ramips/base-files/etc/uci-defaults/01_leds
===
--- target/linux/ramips/base-files/etc/uci-defaults/01_leds(revision 43797)
+++ target/linux/ramips/base-files/etc/uci-defaults/01_leds(working copy)
@@ -198,6 +198,10 @@
set_wifi_led "zbtlink:blue:air"
set_usb_led "zbtlink:blue:usb"
;;
+oye-0001)
+ucidef_set_led_default "power" "power" "oye:green:power" "1"
+set_wifi_led "oye:green:wifi"
+;;
wr8305rt)
ucidef_set_led_default "power" "power" "wr8305rt:sys" "1"
set_usb_led "wr8305rt:usb"
Index: target/linux/ramips/base-files/etc/uci-defaults/02_network
===
--- target/linux/ramips/base-files/etc/uci-defaults/02_network(revision
43797)
+++ target/linux/ramips/base-files/etc/uci-defaults/02_network(working
copy)
@@ -103,6 +103,7 @@
dir-615-h1 | \
hlk-rm04 | \
mzk-w300nh2 | \
+oye-0001 | \
mzk-750dhp)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
ucidef_add_switch "switch0" "1" "1"
@@ -220,6 +221,11 @@
wan_mac=$(mtd_get_mac_binary devdata 7)
;;
+oye-0001)
+lan_mac=$(mtd_get_mac_binary factory 40)
+wan_mac=$(mtd_get_mac_binary factory 46)
+;;
+
w306r-v20)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 5)
Index: target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
===
--- target/linux/ramips/base-files/lib/preinit/06_set_iface_mac(revision 0)
+++ target/linux/ramips/base-files/lib/preinit/06_set_iface_mac(revision 0)
@@ -0,0 +1,113 @@
+#
+# Copyright (C) 2011 OpenWrt.org
+#
+
+preinit_set_mac_address() {
+local mac
+
+. /lib/functions.sh
+. /lib/ramips.sh
+
+case $(ramips_board_name) in
+3g-6200n |\
+3g-6200nl |\
+3g300m | \
+dir-620-d1 |\
+dir-300-b7 | \
+w150m | \
+mzk-w300nh2 |\
+wl-330n |\
+wl-330n3g |\
+wr8305rt)
+mac=$(mtd_get_mac_binary factory 4)
+ifconfig eth0 hw ether $mac 2>/dev/null
+;;
+bc2 |\
+broadway |\
+d105 |\
+dir-620-a1 |\
+esr-9753 |\
+freestation5 |\
+hlk-rm04 | \
+mpr-a1 | \
+mpr-a2 | \
+dir-300-b7 | \
+dir-320-b1 | \
+psr-680w |\
+rt-n56u |\
+sl-r7205)
+mac=$(mtd_get_mac_binary factory 4)
+mac=$(macaddr_setbit_la "$mac")
+ifconfig eth0 hw ether $mac 2>/dev/null
+;;
+br-6475nd)
+mac=$(mtd_get_mac_binary devdata 13)
+ifconfig eth0 hw ether $mac 2>/dev/null
+;;
+asl26555 |\
+dir-300-b1 |\
+dir-300-b2 |\
+dir-600-b1 |\
+dir-610-a1)
+mac=$(mtd_get_mac_binary devdata 16388)
+ifconfig eth0 hw ether $mac 2>/dev/null
+;;
+cy-swr1100 |\
+dir-645)
+mac=$(mtd_get_mac_ascii nvram lanmac)
+mac=$(macaddr_setbit_la "$mac")
+ifconfig eth0 hw ether $mac 2>/dev/null
+;;
+dap-1350)
+mac=$(mtd_get_mac_binary devdata 46)
+ifconfig eth0 hw ether $mac 2>/dev/null
+;;
+all0239-3g |\
+all0256n |\
+all5002 |\
+all5003 |\
+awm002-evb |\
+carambola |\
+dir-615-h1 |\
+fonera20n |\
+ip2202 |\
+rt-n13u |\
+hw550-3g |\
+nbg-419n |\
+omni-emb |\
+omni-emb-hpm |\
+px4885 |\
+tew-691gr |\
+tew-692gr |\
+w306r-v20 |\
+w502u|\
+wr6202 |\
+wnce2001 |\
+xdxrn502j)
+mac=$(mtd_get_mac_binary factory 40)
+ifconfig eth0 hw ether $mac 2>/dev/null
+;;
+m3 |\
+m4 |\
+x5 |\
+x8)
+mac=$(mtd_get_mac_binary factory 4)
+mac=$(macaddr_add "$mac" -1)
+ifconfig eth0 hw ether $mac 2>/dev/null
+;;
+oye-0001)
+mac=$(mtd_get_mac_binary factory 40)
+ifconfig eth0 hw ether $mac 2>/dev/null
+
Re: [OpenWrt-Devel] [PATCH] [generic] ramips: adding support for OYE-0001 Wireless Router
* younfan33 [17.06.2015 08:52]:
> --- target/linux/ramips/base-files/lib/preinit/06_set_iface_mac(revision
> 0)
> +++ target/linux/ramips/base-files/lib/preinit/06_set_iface_mac(revision
> 0)
> @@ -0,0 +1,113 @@
> +#
> +# Copyright (C) 2011 OpenWrt.org
> +#
> +
> +preinit_set_mac_address() {
here must be something wrong - why are there so many added lines?
bye, bastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
