[OpenWrt-Devel] ath9k / longshot / 5 MHz enforced but 20 MHz shown
during debugging a problematic longshot i discovered, that /sys/kernel/debug/ieee80211/phy0/ath9k/chanbw show 0x5 - but 'iw dev wlan0 info' shows: Interface wlan0 ifindex 6 wdev 0x2 addr 00:15:6d:1c:6a:09 ssid bb type IBSS wiphy 0 channel 48 (5240 MHz), width: 20 MHz, center1: 5240 MHz ^ is there something wrong or do i read it wrong? (both involved nodes show the same). for completeness minstrel: type rate throughput ewma prob this prob retry this succ/attempt successattempts HT20/LGI MCS06.1 99.0 100.0 3 0( 0)72 83 HT20/LGI MCS1 11.4 98.0 100.0 3 0( 0) 1757 2104 HT20/LGI MCS2 16.1 98.4 100.0 5 0( 0) 22388 27846 HT20/LGI MCS3 17.2 82.9 100.0 4 0( 0) 92491 116564 HT20/LGI MCS4 24.8 88.9 100.0 5 1( 1)444291 603432 HT20/LGI t MCS5 26.7 79.166.6 5 16( 24) 665378 969233 HT20/LGI T P MCS6 29.1 80.5 100.0 5 2( 2)597554 894272 HT20/LGI MCS7 25.6 65.8 100.0 5 1( 1)457498 715307 Total packet count::ideal 2198103 lookaround 83460 Average A-MPDU length: 1.4 and station info: Station 00:15:6d:1c:6a:09 (on wlan0) inactive time: 0 ms rx bytes: 565039507 rx packets: 3736926 tx bytes: 305468193 tx packets: 2309388 tx retries: 667046 tx failed: 129 signal: -80 [-80] dBm signal avg: -77 [-77] dBm tx bitrate: 65.0 MBit/s MCS 7 rx bitrate: 65.0 MBit/s MCS 7 authorized: yes authenticated: yes preamble: long WMM/WME:yes MFP:no TDLS peer: no bye, bastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH libubox/uloop] Remove signal handle after uloop_run()
From: Kristian Evensen uloop_run calls uloop_setup_signals() to set up signal handling before the while loop, but does not remove the signal handling after the loop has ended. This can cause problems for for example applications using the ubus file descriptor in their own event loops, and perhaps with their own signal handling. One use-case I experienced was an application that subscribed to several ubus objects and used the ubus file descriptor in its own event loop. Even though ubus_register_subscriber() (which calls uloop_run()) had returned, the signal handler was not removed. This caused SIGINT not to be caught by the application. I am not sure if adding the add variable to uloop_run() is required, or if it is sufficient to send 0/1 directly. Signed-off-by: Kristian Evensen --- uloop.c | 17 + 1 file changed, 13 insertions(+), 4 deletions(-) diff --git a/uloop.c b/uloop.c index 9a0590f..a3e95f7 100644 --- a/uloop.c +++ b/uloop.c @@ -556,17 +556,24 @@ static void uloop_sigchld(int signo) do_sigchld = true; } -static void uloop_setup_signals(void) +static void uloop_setup_signals(uint8_t add) { struct sigaction s; memset(&s, 0, sizeof(struct sigaction)); - s.sa_handler = uloop_handle_sigint; + if(add) + s.sa_handler = uloop_handle_sigint; + else + s.sa_handler = NULL; s.sa_flags = 0; sigaction(SIGINT, &s, NULL); if (uloop_handle_sigchld) { - s.sa_handler = uloop_sigchld; + if(add) + s.sa_handler = uloop_sigchld; + else + s.sa_handler = NULL; + sigaction(SIGCHLD, &s, NULL); } } @@ -622,8 +629,9 @@ static void uloop_clear_processes(void) void uloop_run(void) { struct timeval tv; + uint8_t add = 1; - uloop_setup_signals(); + uloop_setup_signals(add); while(!uloop_cancelled) { uloop_gettime(&tv); @@ -636,6 +644,7 @@ void uloop_run(void) uloop_gettime(&tv); uloop_run_events(uloop_get_next_timeout(&tv)); } + uloop_setup_signals(!add); } void uloop_done(void) -- 1.8.3.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox/uloop] Remove signal handle after uloop_run()
On 2013-10-21 4:43 PM, Kristian Evensen wrote: > From: Kristian Evensen > > uloop_run calls uloop_setup_signals() to set up signal handling before the > while > loop, but does not remove the signal handling after the loop has ended. This > can > cause problems for for example applications using the ubus file descriptor in > their own event loops, and perhaps with their own signal handling. > > One use-case I experienced was an application that subscribed to several ubus > objects and used the ubus file descriptor in its own event loop. Even though > ubus_register_subscriber() (which calls uloop_run()) had returned, the signal > handler was not removed. This caused SIGINT not to be caught by the > application. > > I am not sure if adding the add variable to uloop_run() is required, or if it > is > sufficient to send 0/1 directly. > > Signed-off-by: Kristian Evensen > > --- > uloop.c | 17 + > 1 file changed, 13 insertions(+), 4 deletions(-) > > diff --git a/uloop.c b/uloop.c > index 9a0590f..a3e95f7 100644 > --- a/uloop.c > +++ b/uloop.c > @@ -556,17 +556,24 @@ static void uloop_sigchld(int signo) > do_sigchld = true; > } > > -static void uloop_setup_signals(void) > +static void uloop_setup_signals(uint8_t add) bool is a more appropriate type here than uint8_t > { > struct sigaction s; > > memset(&s, 0, sizeof(struct sigaction)); > - s.sa_handler = uloop_handle_sigint; > + if(add) > + s.sa_handler = uloop_handle_sigint; > + else > + s.sa_handler = NULL; > s.sa_flags = 0; > sigaction(SIGINT, &s, NULL); > > if (uloop_handle_sigchld) { > - s.sa_handler = uloop_sigchld; > + if(add) > + s.sa_handler = uloop_sigchld; > + else > + s.sa_handler = NULL; > + > sigaction(SIGCHLD, &s, NULL); > } > } I think you need to use a different approach. What you're doing here breaks recursive uloop_run calls, which are used in a few places. You need to change the code to save/restore signal handlers instead of just setting them to NULL. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath9k / longshot / 5 MHz enforced but 20 MHz shown
On 2013-10-21 11:18 AM, Bastian Bittorf wrote: > during debugging a problematic longshot i discovered, that > /sys/kernel/debug/ieee80211/phy0/ath9k/chanbw > > show 0x5 - but 'iw dev wlan0 info' shows: > > Interface wlan0 > ifindex 6 > wdev 0x2 > addr 00:15:6d:1c:6a:09 > ssid bb > type IBSS > wiphy 0 > channel 48 (5240 MHz), width: 20 MHz, center1: 5240 MHz >^ > > is there something wrong or do i read it wrong? > (both involved nodes show the same). for completeness minstrel: That's normal. Right now, channel bandwidth is applied via debugfs - bypassing mac80211/cfg80211 entirely - so anything in mac80211 or above will think that it's still running in 20 MHz, whereas the driver is using 5 MHz. The main reason for this is that the 5/10 MHz support code in mac80211 currently disables 802.11n and changes the rate calculation, which breaks compatibility with other 5/10 MHz implementations. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox/uloop] Remove signal handle after uloop_run()
Hi, On Mon, Oct 21, 2013 at 5:31 PM, Felix Fietkau wrote: > bool is a more appropriate type here than uint8_t Thanks for letting me know. > I think you need to use a different approach. What you're doing here > breaks recursive uloop_run calls, which are used in a few places. > You need to change the code to save/restore signal handlers instead of > just setting them to NULL. Thanks for your comments. The more I think about this, the more I believe that this is better dealt with by the user applications. One simple approach would be to store the old sigaction (when entering uloop first time) somewhere, and only guarantee that signal handling is restored to what it was when uloop_run() was called the first time. However, this would not cover all cases. Since you allow recursive calls, I guess we have to store the signal handler + flags for each call, to make sure no information is lost. Would approach one be sufficient, or is number two required? -Kristian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH libubox/uloop] Remove signal handle after uloop_run()
On 2013-10-21 7:21 PM, Kristian Evensen wrote: > Hi, > > On Mon, Oct 21, 2013 at 5:31 PM, Felix Fietkau wrote: >> bool is a more appropriate type here than uint8_t > > Thanks for letting me know. > >> I think you need to use a different approach. What you're doing here >> breaks recursive uloop_run calls, which are used in a few places. >> You need to change the code to save/restore signal handlers instead of >> just setting them to NULL. > > Thanks for your comments. The more I think about this, the more I > believe that this is better dealt with by the user applications. One > simple approach would be to store the old sigaction (when entering > uloop first time) somewhere, and only guarantee that signal handling > is restored to what it was when uloop_run() was called the first time. > However, this would not cover all cases. Since you allow recursive > calls, I guess we have to store the signal handler + flags for each > call, to make sure no information is lost. Would approach one be > sufficient, or is number two required? I think storing the signal handler once and skipping the apply/restore for recursive calls should work. You could use a simple static counter to track the recursion level. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [OpenWrt-Devel 4/4] Add profile and build image for Sagemcom F@ST2704V2 ADSL router
This adds profile and build image for Sagemcom F@st2704, using b43 driver. For WiFi to work properly BCMA fallback SPROM support patch must be applied (http://git.io/z1Ki8A). Signed-off-by: Marcin Jurkowski --- target/linux/brcm63xx/generic/profiles/202-Sagemcom.mk | 16 target/linux/brcm63xx/image/Makefile | 3 +++ 2 files changed, 19 insertions(+) create mode 100644 target/linux/brcm63xx/generic/profiles/202-Sagemcom.mk diff --git a/target/linux/brcm63xx/generic/profiles/202-Sagemcom.mk b/target/linux/brcm63xx/generic/profiles/202-Sagemcom.mk new file mode 100644 index 000..a666ba3 --- /dev/null +++ b/target/linux/brcm63xx/generic/profiles/202-Sagemcom.mk @@ -0,0 +1,16 @@ +# +# Copyright (C) 2006 OpenWrt.org +# +# This is free software, licensed under the GNU General Public License v2. +# See /LICENSE for more information. +# + +define Profile/Sagemcom-2704V2 + NAME:=Sagemcom F@ST 2704 V2 + PACKAGES:=kmod-b43 wpad-mini \ +kmod-usb2 kmod-usb-ohci kmod-usb-storage block-mount kmod-fs-ext4 kmod-fs-msdos kmod-nls-cp437 kmod-nls-iso8859-1 kmod-ledtrig-usbdev +endef +define Profile/Sagemcom-2704V2/Description + Package set optimized for Sagemcom F@ST 2704 using open-source b43 WiFi driver +endef +$(eval $(call Profile,Sagemcom-2704V2)) diff --git a/target/linux/brcm63xx/image/Makefile b/target/linux/brcm63xx/image/Makefile index dc11c33..e0bcb07 100755 --- a/target/linux/brcm63xx/image/Makefile +++ b/target/linux/brcm63xx/image/Makefile @@ -255,6 +255,9 @@ define Image/Build # Sagem F@ST2604 $(call Image/Build/CFE,$(1),F@ST2604,6348,F@ST2604-cfe) $(call Image/Build/CFE,$(1),F@ST2604,6348,F@ST2604,OpenWRT-$(REVISION)) + # Sagem F@ST2704V2 + $(call Image/Build/CFE,$(1),F@ST2704V2,6328,F@ST2704V2-cfe) + $(call Image/Build/CFE,$(1),F@ST2704V2,6328,F@ST2704V2,OpenWRT-$(REVISION)) # Inventel Livebox $(call Image/Build/RedBoot,livebox) # Pirelli Alice Gate VoIP 2 Plus Wi-Fi AGPF-S0 -- 1.8.1.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [OpenWrt-Devel 1/4] Add kernel support for Sagemcom F@ST2704V2 ADSL router
This adds kernel support support for Sagemcom F@st 2704 wireless ADSL router. It's a BCM6328-based 802.11n wireless router with USB port and ADSL2+ modem equipped with 64 MiB RAM and 8 MiB flash. Signed-off-by: Marcin Jurkowski --- .../brcm63xx/patches-3.10/803-board_fast2704.patch | 133 + 1 file changed, 133 insertions(+) create mode 100644 target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch diff --git a/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch b/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch new file mode 100644 index 000..69a024f --- /dev/null +++ b/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch @@ -0,0 +1,133 @@ +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c b/arch/mips/bcm63xx/boards/board_bcm963xx.c +@@ -1501,6 +1501,122 @@ static struct board_info __initdata boar + }, + }; + ++static struct board_info __initdata board_FAST2704V2 = { ++ .name = "F@ST2704V2", ++ .expected_cpu_id= 0x6328, ++ ++ .has_uart0 = 1, ++ .has_pci= 1, ++ .has_ohci0 = 1, ++ .has_ehci0 = 1, ++ .has_usbd = 1, ++ ++ .has_enetsw = 1, ++ ++ .enetsw = { ++ .used_ports = { ++ [0] = { ++ .used = 1, ++ .phy_id = 1, ++ .name = "Port 1", ++ }, ++ [1] = { ++ .used = 1, ++ .phy_id = 2, ++ .name = "Port 2", ++ }, ++ [2] = { ++ .used = 1, ++ .phy_id = 3, ++ .name = "Port 3", ++ }, ++ [3] = { ++ .used = 1, ++ .phy_id = 4, ++ .name = "Port 4", ++ }, ++ }, ++ }, ++ ++ .leds = { ++ // Front LEDs ++ { ++ .name = "F@ST2704V2:green:power", ++ .gpio = 4, ++ .active_low = 1, ++ .default_trigger= "default-on", ++ }, ++ { ++ .name = "F@ST2704V2:red:power", ++ .gpio = 5, ++ .active_low = 1, ++ }, ++ { ++ .name = "F@ST2704V2:red:inet", ++ .gpio = 2, ++ .active_low = 1, ++ }, ++ { ++ .name = "F@ST2704V2:green:dsl", ++ .gpio = 3, ++ .active_low = 1, ++ }, ++ { ++ .name = "F@ST2704V2:green:inet", ++ .gpio = 11, ++ .active_low = 1, ++ }, ++ { ++ .name = "F@ST2704V2:green:usb", ++ .gpio = 1, ++ .active_low = 1, ++ }, ++ ++ // Side button LEDs ++ { ++ .name = "F@ST2704V2:green:wps", ++ .gpio = 10, ++ .active_low = 1, ++ }, ++ ++ /* ++ // TODO LED emits dim light when GPIO line is set to out state, regardless of GPIO output level ++ { ++ .name = "F@ST2704V2:green:rfkill", ++ .gpio = 0, ++ .active_low = 1, ++ }, ++ */ ++ ++ }, ++ .buttons = { ++ { ++ .desc = "reset", ++ .gpio = 23, ++ .active_low = 1, ++ .type = EV_KEY, ++ .code = KEY_RESTART, ++ .debounce_interval = BCM963XX_KEYS_DEBOUNCE_INTERVAL, ++ }, ++ { ++ .desc = "wps", ++ .gpio = 24, ++ .active_low = 1, ++ .type = EV_KEY, ++
[OpenWrt-Devel] [OpenWrt-Devel 3/4] Add userspace support for Sagemcom F@ST2704V2 ADSL router
This adds userspace support for Sagemcom F@st 2704 router. Signed-off-by: Marcin Jurkowski --- .../brcm63xx/base-files/etc/uci-defaults/01_leds | 19 +++ .../brcm63xx/base-files/etc/uci-defaults/02_network | 3 ++- target/linux/brcm63xx/base-files/lib/brcm63xx.sh | 5 + 3 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds b/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds new file mode 100644 index 000..6007e38 --- /dev/null +++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/01_leds @@ -0,0 +1,19 @@ +#!/bin/sh +# +# Copyright (C) 2013 OpenWrt.org +# + + +. /lib/functions/uci-defaults.sh +. /lib/brcm63xx.sh + + +case "$board_name" in +'F@ST2704V2') + ucidef_set_led_usbdev "usb" "USB" "F@ST2704V2:green:usb" "1-1" + ;; +esac + +ucidef_commit_leds + +exit 0 diff --git a/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network b/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network index d7f6c3a..087bce9 100755 --- a/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network +++ b/target/linux/brcm63xx/base-files/etc/uci-defaults/02_network @@ -80,7 +80,8 @@ DVG3810BN) 96328A-1441N1 |\ 963281TAN |\ 963281T_TEF |\ -96368MVNgr) +96368MVNgr |\ +"F@ST2704V2") ucidef_set_interface_lan "eth0.1" ucidef_add_switch "eth0" "1" "1" ucidef_add_switch_vlan "eth0" "1" "0 1 2 3 8t" diff --git a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh index 7c449ae..afe9624 100755 --- a/target/linux/brcm63xx/base-files/lib/brcm63xx.sh +++ b/target/linux/brcm63xx/base-files/lib/brcm63xx.sh @@ -121,6 +121,11 @@ brcm63xx_detect() { brcm63xx_has_reset_button="true" ifname=eth0 ;; + 'F@ST2704V2') + status_led="F@ST2704V2:green:power" + brcm63xx_has_reset_button="true" + ifname=eth0 + ;; *) ;; esac -- 1.8.1.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [OpenWrt-Devel 2/4] button-hotplug: Add KEY_RFKILL handling
This extends button-hotplug to allow userspace handlers for rfkill events, enabling /etc/rc.button/rfkill script to work properly on routers with rfkill switch. Signed-off-by: Marcin Jurkowski --- package/kernel/button-hotplug/src/button-hotplug.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/package/kernel/button-hotplug/src/button-hotplug.c b/package/kernel/button-hotplug/src/button-hotplug.c index 684a0c6..588f7a0 100644 --- a/package/kernel/button-hotplug/src/button-hotplug.c +++ b/package/kernel/button-hotplug/src/button-hotplug.c @@ -85,6 +85,9 @@ static struct bh_map button_map[] = { BH_MAP(BTN_9, "BTN_9"), BH_MAP(KEY_RESTART, "reset"), BH_MAP(KEY_POWER, "power"), +#ifdef KEY_RFKILL + BH_MAP(KEY_RFKILL, "rfkill"), +#endif /* KEY_RFKILL */ #ifdef KEY_WPS_BUTTON BH_MAP(KEY_WPS_BUTTON, "wps"), #endif /* KEY_WPS_BUTTON */ -- 1.8.1.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [OpenWrt-Devel 4/4] Add profile and build image for Sagemcom F@ST2704V2 ADSL router
On 21 Oct 2013 14:47, "Marcin Jurkowski" wrote: > > This adds profile and build image for Sagemcom F@st2704, using b43 > driver. > For WiFi to work properly BCMA fallback SPROM support patch must > be applied (http://git.io/z1Ki8A). > ... I can put a real OS on this pile of ass? I CAN HAVE REAL BRIDGE MODE? I kinda want to have your kids. Or a donation link. Thank you so much for this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: Backport DIR-825 C1 support to AA
This is a backport to add support for D-Link's DIR-825 rev. C1 to the Attitude Adjustment branch. Signed-off-by: Sebastian Kemper --- I don't know with certainty how open the OpenWrt project is towards backporting a router from trunk to the stable branch. This backport is tested by myself and works well. If it's just about the format of the patch, e.g. one big patch versus multiple smaller patches, I'm willing to put in the extra work to divide the patch into a series. Index: package/base-files/files/lib/functions.sh === --- package/base-files/files/lib/functions.sh (revision 36088) +++ package/base-files/files/lib/functions.sh (working copy) @@ -229,6 +229,25 @@ echo "${PART:+$PREFIX$PART}" } +mtd_get_mac_ascii() { + local mtdname="$1" + local key="$2" + local part + local mac_dirty + + . /lib/functions.sh + + part=$(find_mtd_part "$mtdname") + if [ -z "$part" ]; then + echo "mtd_get_mac_ascii: partition $mtdname not found!" >&2 + return + fi + + mac_dirty=$(strings "$part" | sed -n 's/'"$key"'=//p') + # "canonicalize" mac + printf "%02x:%02x:%02x:%02x:%02x:%02x" 0x${mac_dirty//:/ 0x} +} + strtok() { # { [] ... } local tmp local val="$1" Index: target/linux/ar71xx/base-files/etc/diag.sh === --- target/linux/ar71xx/base-files/etc/diag.sh (revision 36088) +++ target/linux/ar71xx/base-files/etc/diag.sh (working copy) @@ -70,6 +70,9 @@ dir-825-b1) status_led="d-link:orange:power" ;; + dir-825-c1) + status_led="d-link:amber:power" + ;; eap7660d) status_led="eap7660d:green:ds4" ;; Index: target/linux/ar71xx/base-files/etc/uci-defaults/leds === --- target/linux/ar71xx/base-files/etc/uci-defaults/leds(revision 36088) +++ target/linux/ar71xx/base-files/etc/uci-defaults/leds(working copy) @@ -63,6 +63,10 @@ dir-825-b1) ucidef_set_led_usbdev "usb" "USB" "d-link:blue:usb" "1-1" ;; +dir-825-c1) + ucidef_set_led_usbdev "usb" "USB" "d-link:blue:usb" "1-1" + ucidef_set_led_wlan "wlan2g" "WLAN 2.4 GHz" "d-link:blue:wlan2g" "phy0tpt" + ;; hornet-ub) ucidef_set_led_netdev "lan" "LAN" "alfa:blue:lan" "eth0" Index: target/linux/ar71xx/base-files/etc/uci-defaults/network === --- target/linux/ar71xx/base-files/etc/uci-defaults/network (revision 36088) +++ target/linux/ar71xx/base-files/etc/uci-defaults/network (working copy) @@ -146,6 +146,16 @@ ucidef_add_switch_vlan "switch0" "1" "0 1 2 3 5t" ;; +dir-825-c1) + local mac + ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2" + ucidef_add_switch "eth0" "1" "1" + ucidef_add_switch_vlan "eth0" "1" "0t 1 2 3 4" + ucidef_add_switch_vlan "eth0" "2" "0t 5" + mac=$(mtd_get_mac_ascii nvram "^wan_mac") + [ -n "$mac" ] && ucidef_set_interface_macaddr "wan" "$mac" + ;; + all0305 |\ aw-nr580 |\ bullet-m |\ Index: target/linux/ar71xx/base-files/lib/ar71xx.sh === --- target/linux/ar71xx/base-files/lib/ar71xx.sh(revision 36088) +++ target/linux/ar71xx/base-files/lib/ar71xx.sh(working copy) @@ -204,6 +204,9 @@ *"DIR-825 rev. B1") name="dir-825-b1" ;; + *"DIR-825 rev. C1") + name="dir-825-c1" + ;; *EAP7660D) name="eap7660d" ;; Index: target/linux/ar71xx/base-files/lib/upgrade/platform.sh === --- target/linux/ar71xx/base-files/lib/upgrade/platform.sh (revision 36088) +++ target/linux/ar71xx/base-files/lib/upgrade/platform.sh (working copy) @@ -105,6 +105,7 @@ dir-600-a1 | \ dir-615-c1 | \ dir-615-e4 | \ + dir-825-c1 | \ ew-dorin | \ ew-dorin-router | \ mzk-w04nu | \ Index: target/linux/ar71xx/config-3.3 === --- target/linux/ar71xx/config-3.3 (revision 36088) +++ target/linux/ar71xx/config-3.3 (working copy) @@ -35,6 +35,7 @@ CONFIG_ATH79_MACH_DIR_600_A1=y CONFIG_ATH79_MACH_DIR_615_C1=y CONFIG_ATH79_MACH_DIR_825_B1=y +CONFIG_ATH79_MACH_DIR_825_C1=y CONFIG_ATH79_MACH_EAP7660D=y CONFIG_ATH79_MACH_EW_DORIN=y CONFIG_ATH79_MACH_HORNET_UB=y Index: target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c === --- target/linux/ar71xx/files/arch/mips/ath79/mach-dir-825-c1.c (revision 0) +++ target/linux/ar71xx/files/
Re: [OpenWrt-Devel] [OpenWrt-Devel 1/4] Add kernel support for Sagemcom F@ST2704V2 ADSL router
2013/10/21 Marcin Jurkowski : > This adds kernel support support for Sagemcom F@st 2704 wireless ADSL > router. > It's a BCM6328-based 802.11n wireless router with USB port and ADSL2+ > modem equipped with 64 MiB RAM and 8 MiB flash. > > Signed-off-by: Marcin Jurkowski > --- > .../brcm63xx/patches-3.10/803-board_fast2704.patch | 133 > + > 1 file changed, 133 insertions(+) > create mode 100644 > target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch > > diff --git a/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch > b/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch > new file mode 100644 > index 000..69a024f > --- /dev/null > +++ b/target/linux/brcm63xx/patches-3.10/803-board_fast2704.patch > @@ -0,0 +1,133 @@ > +--- a/arch/mips/bcm63xx/boards/board_bcm963xx.c > b/arch/mips/bcm63xx/boards/board_bcm963xx.c > +@@ -1501,6 +1501,122 @@ static struct board_info __initdata boar > + }, > + }; > + > ++static struct board_info __initdata board_FAST2704V2 = { > ++ .name = "F@ST2704V2", > ++ .expected_cpu_id= 0x6328, > ++ > ++ .has_uart0 = 1, > ++ .has_pci= 1, > ++ .has_ohci0 = 1, > ++ .has_ehci0 = 1, > ++ .has_usbd = 1, > ++ > ++ .has_enetsw = 1, > ++ > ++ .enetsw = { > ++ .used_ports = { > ++ [0] = { > ++ .used = 1, > ++ .phy_id = 1, > ++ .name = "Port 1", > ++ }, > ++ [1] = { > ++ .used = 1, > ++ .phy_id = 2, > ++ .name = "Port 2", > ++ }, > ++ [2] = { > ++ .used = 1, > ++ .phy_id = 3, > ++ .name = "Port 3", > ++ }, > ++ [3] = { > ++ .used = 1, > ++ .phy_id = 4, > ++ .name = "Port 4", > ++ }, > ++ }, > ++ }, > ++ > ++ .leds = { > ++ // Front LEDs Please use C99 style comments: /* Front LEDs */ other than that, this looks good to me. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel