[OpenWrt-Devel] Setting channel on ath9k
Folks, I have a trouble setting the channel on Buffalo WZR-HP-G300NH (says its AR9100) and WHR-HP-G300N (says its AR9280) on recent revision of the OpenWrt (r37180) with compat-wireless-2013-06-27. The problem is that I CAN NOT set the channel on an interface, regardless of the up/down state of the interface. // Make sure I start with fresh state root@gh3:~# ifconfig -a eth0 Link encap:Ethernet HWaddr 00:1D:73:B3:3E:90 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:207 errors:0 dropped:1 overruns:59125 frame:0 TX packets:65 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:38989 (38.0 KiB) TX bytes:16045 (15.6 KiB) Interrupt:4 eth0.1Link encap:Ethernet HWaddr 00:1D:73:B3:3E:90 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:196 errors:0 dropped:0 overruns:0 frame:0 TX packets:64 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:32203 (31.4 KiB) TX bytes:14746 (14.4 KiB) eth1 Link encap:Ethernet HWaddr 00:1D:73:B3:3E:91 inet addr:192.168.0.38 Bcast:192.168.0.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:981 errors:0 dropped:80 overruns:0 frame:0 TX packets:285 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:171850 (167.8 KiB) TX bytes:34008 (33.2 KiB) Interrupt:5 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:16 errors:0 dropped:0 overruns:0 frame:0 TX packets:16 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1536 (1.5 KiB) TX bytes:1536 (1.5 KiB) // Create a managed interface root@gh3:~# iw phy0 interface add wlan0 type managed // Confirm its creation and state (down) root@gh3:~# ifconfig wlan0 wlan0 Link encap:Ethernet HWaddr 00:1D:73:B3:3E:90 BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) // Try to set the channel root@gh3:~# iw wlan0 set channel 11 command failed: Device or resource busy (-16) // Bring the interface up, and set channel root@gh3:~# ifconfig wlan0 up root@gh3:~# iw wlan0 set channel 11 command failed: Device or resource busy (-16) // Try it directly on phy root@gh3:~# iw phy0 set channel 11 command failed: Device or resource busy (-16) After some attempts, I found out that the only way to set the channel is to do it through a monitor interface that is UP, and all other interfaces on the original phy down. root@gh3:~# iw wlan0 interface add wlan0.mon type monitor root@gh3:~# ifconfig wlan0 down root@gh3:~# ifconfig wlan0.mon up root@gh3:~# iw wlan0.mon set channel 11 root@gh3:~# BTW, root@gh3:~# iw --version iw version 3.10 So, is this a broken iw? or broken ath9k driver? Oh, and one more (maybe) trivial question. How can I find out the current state (e.g. channel) of a phy or interface with iw? Any comments and pointers are welcome. --- shinoda smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH, AA12.09-beta, ramips] D-Link DAP-1350; Avoid bricking esw config
This is a patch to connect eth0.1 (lan) to the only ethernet connector available. D-Link DAP-1350 goes bricked with AA 12.09-beta. This is because the current esw configuration for the board connects eth0.2 (wan) to the *ONE and ONLY* ethernet connector available, preventing initial access to the board through 192.168.1.1 on eth0.1 after flashing, effectively bricking the board. There are things that should be done to make this board really useful, but for AA 12.09, this one liner is indispensable. Signed of by Yoichi Shinoda shin...@jaist.ac.jp --- .../files/arch/mips/ralink/rt305x/mach-dap-1350.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dap-1350.c b/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dap-1350.c index cd5d6ae..42d3ebe 100644 --- a/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dap-1350.c +++ b/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dap-1350.c @@ -79,7 +79,7 @@ static void __init dap_1350_init(void) rt305x_register_flash(0); - rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_W; + rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_W; rt305x_register_ethernet(); ramips_register_gpio_leds(-1, ARRAY_SIZE(dap_1350_leds_gpio), dap_1350_leds_gpio); -- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Slide switches and gpio-buttons
Hi List, I started to believe that slide switches available in various boards should not be handled with gpio-buttons, as we have to know states, not activities, of the gpios if we really want to give them some positional semantics. Is there any example of implementing the positional switch using, say gpio-buttons + hotplug? Does gpio-keys-polled works simultaneously with gpio-buttons + hotplug? (Is there any reference material for the gpio-keys-polled facility?) Is there any kmod that encodes multiple gpio states into a single value? Any comments and pointers will be greatly appreciated. Regards, --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] AR9132 based mesh does not start
With OpenWrt r33276 (compat-wireless-2012-07-13), Buffalo WZR-HP-G300NH (AR9132) does not start a mesh until an adjacent monitor interface is created and brought up. For example, let's consider a mesh interface mesh0. # iw phy0 interface add mesh0 type mp # iw mesh0 set channel 11 # iw mesh0 mesh join mymesh # ifconfig mesh0 up I need to issue following additional commands before the mesh is actually capable of seeing the interface, or the interface seeing the mesh. # iw phy0 interface add mon0 type monitor # ifconfig mon0 up Where do I start looking? Oh, BTW, the WSoC is identified as [8.10] ieee80211 phy0: Atheros AR9100 MAC/BB Rev:7 AR2133 RF Rev:a2 mem=0xb80c, irq=2 --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR9132 based mesh does not start
Chun-Yeow, Thanks for the suggestion, but there's no luck here… root@gh3:~# iw phy0 interface add mesh0 type mp root@gh3:~# iw mesh0 set channel 11 root@gh3:~# ifconfig mesh0 192.168.100.23 netmask 255.255.255.0 root@gh3:~# ifconfig mesh0 up root@gh3:~# iw mesh0 mesh join mymesh root@gh3:~# iw mesh0 mpath dump Dest Next/Gate Iface FlagsSN Metric Qlen root@gh3:~# sleep 60 root@gh3:~# iw mesh0 mpath dump Dest Next/Gate Iface FlagsSN Metric Qlen root@gh3:~# iw phy0 interface add mon0 type monitor root@gh3:~# iw mesh0 mpath dump Dest Next/Gate Iface FlagsSN Metric Qlen root@gh3:~# ifconfig mon0 up root@gh3:~# iw mesh0 mpath dump Dest Next/Gate Iface FlagsSN Metric Qlen 4c:e6:76:44:9a:e8 4c:e6:76:97:d7:1 mesh0 ARS 174780 17250 0 4c:e6:76:a9:5b:9d direct mesh0 ARS 150900 8193 0 4c:e6:76:44:9a:d5 direct mesh0 AGTRS328839 8193 0 4c:e6:76:44:9b:a 4c:e6:76:97:d7:1 mesh0 ARS 32539 8421 0 0:1:8e:10:bc:79 direct mesh0 ARS 308552 8193 0 4c:e6:76:aa:51:a8 direct mesh0 ARS 81618 8193 0 4c:e6:76:97:d7:1 direct mesh0 ARS 131398 8193 0 4c:e6:76:44:9b:4 direct mesh0 ATS 97623 8193 0 4c:e6:76:44:9a:d6 4c:e6:76:44:9a:d5 mesh0 P a:0:27:0:0:0 0:1:8e:10:bc:79 mesh0 P 4c:e6:76:44:9a:d5 direct mesh0 AgTRS328839 8193 0 root@gh3:~# --- shinoda On 2012/08/30, at 0:44, Yeoh Chun-Yeow wrote: Hi, Shinoda Up the mesh interface before joining the mesh network. Like this: # ifconfig mesh0 up # iw mesh0 mesh join mymesh --- Chun-Yeow On Wed, Aug 29, 2012 at 8:21 PM, LEO Airwarosu Yoichi Shinoda shin...@jaist.ac.jp wrote: With OpenWrt r33276 (compat-wireless-2012-07-13), Buffalo WZR-HP-G300NH (AR9132) does not start a mesh until an adjacent monitor interface is created and brought up. For example, let's consider a mesh interface mesh0. # iw phy0 interface add mesh0 type mp # iw mesh0 set channel 11 # iw mesh0 mesh join mymesh # ifconfig mesh0 up I need to issue following additional commands before the mesh is actually capable of seeing the interface, or the interface seeing the mesh. # iw phy0 interface add mon0 type monitor # ifconfig mon0 up Where do I start looking? Oh, BTW, the WSoC is identified as [8.10] ieee80211 phy0: Atheros AR9100 MAC/BB Rev:7 AR2133 RF Rev:a2 mem=0xb80c, irq=2 --- shinoda ___ Devel mailing list de...@lists.open80211s.org http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR9132 based mesh does not start
Chun-Yeow, It worked like a charm! Thanks a million! --- shinoda On 2012/08/30, at 10:31, Yeoh Chun-Yeow wrote: Hi, Shinoda It could be due to old ath9k chipset filtering issue (broadcast packet is filtered out, such as ARP request) as mentioned in: https://github.com/cozybit/open80211s/wiki/ath9kFilteringIssueFix So modify as follow in ath9k/recv.c and see how: + if (sc-sc_ah-hw_version.macVersion == AR_SREV_VERSION_9160 || + sc-sc_ah-hw_version.macVersion == AR_SREV_VERSION_9100) I have run into the same problem on my AR54516 PCI card before. --- Chun-Yeow On Thu, Aug 30, 2012 at 5:39 AM, Thomas Pedersen tho...@cozybit.com wrote: On Wed, Aug 29, 2012 at 5:21 AM, LEO Airwarosu Yoichi Shinoda shin...@jaist.ac.jp wrote: With OpenWrt r33276 (compat-wireless-2012-07-13), Buffalo WZR-HP-G300NH (AR9132) does not start a mesh until an adjacent monitor interface is created and brought up. For example, let's consider a mesh interface mesh0. # iw phy0 interface add mesh0 type mp # iw mesh0 set channel 11 # iw mesh0 mesh join mymesh # ifconfig mesh0 up I need to issue following additional commands before the mesh is actually capable of seeing the interface, or the interface seeing the mesh. # iw phy0 interface add mon0 type monitor # ifconfig mon0 up Where do I start looking? Is the card even beaconing before the monitor interface comes up? Are peering frames transmitted? What does station dump show before starting mon0? A capture during this period would also be useful. Thomas ___ Devel mailing list de...@lists.open80211s.org http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list de...@lists.open80211s.org http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR9132 based mesh does not start
Thomas, I was preparing some trace/log data for you, but Chun-Yeow's suggestion did the trick. Thank you very much anyway. --- shinoda On 2012/08/30, at 6:39, Thomas Pedersen wrote: On Wed, Aug 29, 2012 at 5:21 AM, LEO Airwarosu Yoichi Shinoda shin...@jaist.ac.jp wrote: With OpenWrt r33276 (compat-wireless-2012-07-13), Buffalo WZR-HP-G300NH (AR9132) does not start a mesh until an adjacent monitor interface is created and brought up. For example, let's consider a mesh interface mesh0. # iw phy0 interface add mesh0 type mp # iw mesh0 set channel 11 # iw mesh0 mesh join mymesh # ifconfig mesh0 up I need to issue following additional commands before the mesh is actually capable of seeing the interface, or the interface seeing the mesh. # iw phy0 interface add mon0 type monitor # ifconfig mon0 up Where do I start looking? Is the card even beaconing before the monitor interface comes up? Are peering frames transmitted? What does station dump show before starting mon0? A capture during this period would also be useful. Thomas ___ Devel mailing list de...@lists.open80211s.org http://lists.open80211s.org/cgi-bin/mailman/listinfo/devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH, 1/3] ar71xx: Buffalo WZR-HP-AG300H LED support (target diffs)
An improved LED support for Buffalo WZR-HP-AG300H.
There will be two new packages to go with this patch
(ar922x-led-fix-hotplug and ar922x-led-fix-init).
These packages essentially perform the same task of
disabling JTAG over GPIO pins function which is
currently required for LEDs on AR922x emac GPIO to work,
and are both considered a temporary fix that circumvent
this problem.
Following is the first part of the support, diffs for
files under trunk/target/linux/ar71xx.
Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-wzr-hp-ag300h.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-wzr-hp-ag300h.c
(revision 33188)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-wzr-hp-ag300h.c
(working copy)
@@ -75,6 +75,47 @@
},
};
+static struct gpio_led wzrhpag300h_wmac0_leds_gpio[] = {
+{
+.name = buffalo:amber:band2g,
+.gpio = 1,
+.active_low = 1,
+ },
+{
+.name = buffalo:green:usb,
+.gpio = 3,
+.active_low = 1,
+ },
+{
+.name = buffalo:green:band2g,
+.gpio = 5,
+.active_low = 1,
+ },
+};
+
+static struct gpio_led wzrhpag300h_wmac1_leds_gpio[] = {
+{
+.name = buffalo:green:band5g,
+.gpio = 1,
+.active_low = 1,
+ },
+{
+.name = buffalo:green:router,
+.gpio = 3,
+.active_low = 1,
+ },
+{
+.name = buffalo:blue:movie_engine,
+.gpio = 4,
+.active_low = 1,
+ },
+{
+.name = buffalo:amber:band5g,
+.gpio = 5,
+.active_low = 1,
+ },
+};
+
static struct gpio_keys_button wzrhpag300h_gpio_keys[] __initdata = {
{
.desc = reset,
@@ -111,6 +152,13 @@
.debounce_interval = WZRHPAG300H_KEYS_DEBOUNCE_INTERVAL,
.gpio = 7,
.active_low = 1,
+ }, {
+ .desc = movie_engine,
+ .type = EV_KEY,
+ .code = BTN_7,
+ .debounce_interval = WZRHPAG300H_KEYS_DEBOUNCE_INTERVAL,
+ .gpio = 8,
+ .active_low = 1,
}
};
@@ -150,6 +198,14 @@
ath79_register_m25p80_multi(wzrhpag300h_flash_data);
ap94_pci_init(eeprom1, mac1, eeprom2, mac2);
+
+ ap9x_pci_setup_wmac_led_pin(0, 1);
+ ap9x_pci_setup_wmac_led_pin(1, 5);
+
+ ap9x_pci_setup_wmac_leds(0, wzrhpag300h_wmac0_leds_gpio,
+ ARRAY_SIZE(wzrhpag300h_wmac0_leds_gpio));
+ ap9x_pci_setup_wmac_leds(1, wzrhpag300h_wmac1_leds_gpio,
+ ARRAY_SIZE(wzrhpag300h_wmac1_leds_gpio));
}
MIPS_MACHINE(ATH79_MACH_WZR_HP_AG300H, WZR-HP-AG300H,
Index: target/linux/ar71xx/base-files/etc/uci-defaults/leds
===
--- target/linux/ar71xx/base-files/etc/uci-defaults/leds(revision 33188)
+++ target/linux/ar71xx/base-files/etc/uci-defaults/leds(working copy)
@@ -152,6 +152,12 @@
ucidef_set_led_netdev wireless WIRELESS buffalo:green:wireless
wlan0
;;
+wzr-hp-ag300h)
+ ucidef_set_led_default diag DIAG buffalo:red:diag 0
+ ucidef_set_led_netdev router ROUTER buffalo:green:router eth1
+ ucidef_set_led_usbdev usb USB buffalo:green:usb 1-1
+ ;;
+
wzr-hp-g300nh)
ucidef_set_led_wlan wlan Wireless buffalo:green:wireless phy0tpt
ucidef_set_led_netdev router Router buffalo:green:router eth1
Index: target/linux/ar71xx/base-files/etc/diag.sh
===
--- target/linux/ar71xx/base-files/etc/diag.sh (revision 33188)
+++ target/linux/ar71xx/base-files/etc/diag.sh (working copy)
@@ -144,6 +144,7 @@
wlae-ag300n)
status_led=buffalo:green:status
;;
+ wzr-hp-ag300h | \
wzr-hp-g300nh2)
status_led=buffalo:red:diag
;;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH, 2/3] ar71xx: Buffalo WZR-HP-AG300H LED support (new package: hotplug version)
New package ar922x-led-fix-hotplug.
This package includes a hotplug script to disable
JTAG over GPIO pins function which is currently
required for LEDs on AR922x emac GPIO to work.
There is another package ar922x-led-fix-init
that performs the same task. Selecting either package
will work, and selecting both packages still work.
P.S.
It is classified as utils/Utilities, but I'm not
too sure if this is the correct classification.
Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp
Index: package/ar922x-led-fix-hotplug/ar922xledfix-hotplug
===
--- package/ar922x-led-fix-hotplug/ar922xledfix-hotplug (revision 0)
+++ package/ar922x-led-fix-hotplug/ar922xledfix-hotplug (revision 0)
@@ -0,0 +1,51 @@
+#!/bin/sh
+
+# For AR9220 and AR9223, GPIO JTAG must explicit be disabled
+# before LEDs start working. Do this when wifi device is
+# detected.
+
+#
+# $DEVPATH is not valid for some boards (including WZR-HP-AG300H).
+# Manipulate the $DEVPATH to reach the corresponding phyN.
+#
+
+devdir=`dirname $DEVPATH`
+devdir=`dirname $devdir`
+phydir=/sys$devdir/ieee80211
+phyname=`cat $phydir/phy*/name`
+
+if [ -z $phyname -o $ACTION != add ]; then exit 0; fi
+
+#
+# ar922x_disable_gpio_jtag():
+#
+# Emulate
+# REG_SET_BIT(ah, AR_GPIO_INPUT_EN_VAL, AR_GPIO_JTAG_DISABLE);
+# for AR9220 and AR9223.
+#
+
+ar922x_disable_gpio_jtag()
+{
+local regidx=0x4054
+
+ [ -f /sys/kernel/debug/ieee80211/$1/ath9k/regidx ] {
+ echo $regidx /sys/kernel/debug/ieee80211/$1/ath9k/regidx
+ regval=`cat /sys/kernel/debug/ieee80211/$1/ath9k/regval`
+ regval=$((regval | 0x2))
+ echo regval $regval
+ echo $regval /sys/kernel/debug/ieee80211/$1/ath9k/regval
+}
+}
+
+if [ $phyname -a $ACTION = add ]; then
+
+ . /lib/ar71xx.sh
+
+ case $(ar71xx_board_name) in
+ wzr-hp-ag300h)
+ ar922x_disable_gpio_jtag $phyname
+ ;;
+ esac;
+fi
+
+exit 0
Index: package/ar922x-led-fix-hotplug/Makefile
===
--- package/ar922x-led-fix-hotplug/Makefile (revision 0)
+++ package/ar922x-led-fix-hotplug/Makefile (revision 0)
@@ -0,0 +1,42 @@
+#
+# Copyright (C) 2011 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ar922x-led-fix-hotplug
+PKG_RELEASE:=1
+
+PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/ar922x-led-fix-hotplug
+ SECTION:=util
+ CATEGORY:=Utilities
+ TITLE:=Make LEDs on AR922x work (hotplug version)
+ DEPENDS:=+PACKAGE_MAC80211_DEBUGFS +kmod-leds-gpio
+endef
+
+define Package/ar922x-led-fix-hotplug/description
+ This package contains a hotplug script to make LEDs on AR922x work.
+endef
+
+define Build/Prepare
+endef
+
+define Build/Configure
+endef
+
+define Build/Compile
+endef
+
+define Package/ar922x-led-fix-hotplug/install
+ $(INSTALL_DIR) $(1)/etc/hotplug.d/net
+ $(INSTALL_BIN) ./ar922xledfix-hotplug
$(1)/etc/hotplug.d/net/10-ar922xledfix-hotplug
+endef
+
+$(eval $(call BuildPackage,ar922x-led-fix-hotplug))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH, 2/3] ar71xx: Buffalo WZR-HP-AG300H LED support (new package: init.d version)
New package ar922x-led-fix-init.
This package includes an init.d script to disable
JTAG over GPIO pins function which is currently
required for LEDs on AR922x emac GPIO to work.
There is another package ar922x-led-fix-hotplug
that performs the same task. Selecting either package
will work, and selecting both packages still work.
P.S.
It is classified as utils/Utilities, but I'm not
too sure if this is the correct classification.
Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp
Index: package/ar922x-led-fix-init/ar922xledfix.init
===
--- package/ar922x-led-fix-init/ar922xledfix.init (revision 0)
+++ package/ar922x-led-fix-init/ar922xledfix.init (revision 0)
@@ -0,0 +1,44 @@
+#!/bin/sh /etc/rc.common
+
+START=12
+
+# For AR9220 and AR9223, GPIO JTAG must explicit be disabled
+# before LEDs start working.
+
+#
+# ar922x_disable_gpio_jtag():
+#
+# Emulate
+# REG_SET_BIT(ah, AR_GPIO_INPUT_EN_VAL, AR_GPIO_JTAG_DISABLE);
+# for AR9220 and AR9223.
+#
+
+ar922x_disable_gpio_jtag()
+{
+local regidx=0x4054
+
+ [ -f /sys/kernel/debug/ieee80211/$1/ath9k/regidx ] {
+ echo $regidx /sys/kernel/debug/ieee80211/$1/ath9k/regidx
+ regval=`cat /sys/kernel/debug/ieee80211/$1/ath9k/regval`
+ regval=$((regval | 0x2))
+ echo regval $regval
+ echo $regval /sys/kernel/debug/ieee80211/$1/ath9k/regval
+}
+}
+
+ar922x_find_and_fix()
+{
+ for phycls in /sys/class/ieee80211/* ; do
+ if [ `cat $phycls/device/vendor` = 0x168c \
+ -a `cat $phycls/device/device` = 0x0029 ]; then
+ phyname=`basename $phycls`
+ ar922x_disable_gpio_jtag $phyname
+ echo ar922xledfix: $phyname fixed
+ fi
+ done
+}
+
+start()
+{
+ ar922x_find_and_fix
+}
Index: package/ar922x-led-fix-init/Makefile
===
--- package/ar922x-led-fix-init/Makefile(revision 0)
+++ package/ar922x-led-fix-init/Makefile(revision 0)
@@ -0,0 +1,47 @@
+#
+# Copyright (C) 2011 OpenWrt.org
+#
+# This is free software, licensed under the GNU General Public License v2.
+# See /LICENSE for more information.
+#
+
+include $(TOPDIR)/rules.mk
+
+PKG_NAME:=ar922x-led-fix-init
+PKG_RELEASE:=1
+
+PKG_BUILD_DIR := $(BUILD_DIR)/$(PKG_NAME)
+
+include $(INCLUDE_DIR)/package.mk
+
+define Package/ar922x-led-fix-init
+ SECTION:=util
+ CATEGORY:=Utilities
+ TITLE:=Make LEDs on AR922x work (init.d version)
+ DEPENDS:=+PACKAGE_MAC80211_DEBUGFS +kmod-leds-gpio
+endef
+
+define Package/ar922x-led-fix-init/description
+ This package contains an init.d script to make LEDs on AR922x work.
+endef
+
+define Build/Prepare
+endef
+
+define Build/Configure
+endef
+
+define Build/Compile
+endef
+
+define Package/ar922x-led-fix-init/postinst
+#!/bin/sh
+[ -n $${IPKG_INSTROOT} ] || /etc/init.d/ar922x-led-fix-init enable || true
+endef
+
+define Package/ar922x-led-fix-init/install
+ $(INSTALL_DIR) $(1)/etc/init.d
+ $(INSTALL_BIN) ./ar922xledfix.init $(1)/etc/init.d/ar922xledfix
+endef
+
+$(eval $(call BuildPackage,ar922x-led-fix-init))
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iwinfo: add hw info support for Rt3xxx SoCs
Hi.
My Buffalo WZR-HP-AG300H is said to have AR9220 and AR9223.
root@ag300h:/# cat /sys/devices/pci\:00/\:00\:11.0/subsystem_device
0xa097
root@ag300h:/# cat /sys/devices/pci\:00/\:00\:12.0/subsystem_device
0xa096
--- shinoda
On 2012/08/16, at 1:08, Daniel Golle wrote:
This takes the device_id and subsystem_id from the EEPROM, I'll add
the info for other Rt3xxx chips in the next days.
Signed-off-by: Daniel Golle dgo...@allnet.de
diff --git a/package/iwinfo/src/iwinfo_lib.c b/package/iwinfo/src/iwinfo_lib.c
index b2fc6aa..5ca0a45 100644
--- a/package/iwinfo/src/iwinfo_lib.c
+++ b/package/iwinfo/src/iwinfo_lib.c
@@ -314,6 +314,7 @@ const struct iwinfo_iso3166_label IWINFO_ISO3166_NAMES[]
= {
const char VENDOR_UBNT[] = Ubiquiti;
const char VENDOR_ATH[] = Atheros;
+const char VENDOR_RALINK[] = RaLink;
const struct iwinfo_hardware_entry IWINFO_HARDWARE_ENTRIES[] = {
/*{ vendor, model, vendorid, deviceid, subsys vendorid, subsys deviceid,
poweroff, freqoff } */
@@ -368,6 +369,7 @@ const struct iwinfo_hardware_entry
IWINFO_HARDWARE_ENTRIES[] = {
{ VENDOR_ATH, AR9220,0x168c, 0x0029, 0x168c, 0xa094,
0, 0 },
{ VENDOR_ATH, AR9223,0x168c, 0x0029, 0x168c, 0xa095,
0, 0 },
{ VENDOR_ATH, AR9285,0x168c, 0x002b, 0x168c, 0xa091,
0, 0 },
+ { VENDOR_RALINK, Rt3352, 0x1814, 0x3352, 0x1814, 0x000c,
0, 0 },
#endif
{ NULL }
};
diff --git a/package/iwinfo/src/iwinfo_utils.c
b/package/iwinfo/src/iwinfo_utils.c
index 514f34b..c430652 100644
--- a/package/iwinfo/src/iwinfo_utils.c
+++ b/package/iwinfo/src/iwinfo_utils.c
@@ -165,7 +165,8 @@ int iwinfo_hardware_id_from_mtd(struct iwinfo_hardware_id
*id)
while (fgets(buf, sizeof(buf), mtd) 0)
{
if (fscanf(mtd, mtd%d: %*x %x %127s, off, len, buf) 3 ||
- (strcmp(buf, \boardconfig\) strcmp(buf,
\EEPROM\)))
+ (strcmp(buf, \boardconfig\) strcmp(buf,
\EEPROM\)
+ strcmp(buf, \factory\)) )
{
off = -1;
continue;
@@ -212,6 +213,26 @@ int iwinfo_hardware_id_from_mtd(struct
iwinfo_hardware_id *id)
id-subsystem_device_id = bc[off + 0x14];
break;
}
+ /* Rt3xxx SoC */
+ else if ((bc[off] == 0x3352) || (bc[off] == 0x5233) ||
+ (bc[off] == 0x3350) || (bc[off] == 0x5033) ||
+ (bc[off] == 0x3050) || (bc[off] == 0x5030) ||
+ (bc[off] == 0x3052) || (bc[off] == 0x5230))
+ {
+ /* vendor: RaLink */
+ id-vendor_id = 0x1814;
+ id-subsystem_vendor_id = 0x1814;
+
+ /* device */
+ if (bc[off] 0xf0 == 0x30)
+ id-device_id = ( bc[off] 8 ) |
+ ( bc[off] 0x00ff )
8;
+ else
+ id-device_id = bc[off];
+
+ /* subsystem from EEPROM_NIC_CONF0_RF_TYPE */
+ id-subsystem_device_id = ( bc[off + 0x1a]
0x0f00 ) 8;
+ }
}
munmap(bc, len);
--
1.7.11.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WMAC LED Problems
Peter,
I believe 'led' should come after 'done'.
If 'done' comes after 'led', something 'led' configured
for so called status_led will be wiped and it is set
to default-on by /etc/diag.sh done.
Am I missing something?
--- shinoda
On 2012/08/03, at 0:21, Peter Naulls wrote:
On 08/01/2012 09:03 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/08/01, at 22:39, Peter Naulls wrote:
The problem here is that the LED handling is done in the wrong
order. I submitted a fix/patch(?) for this months ago, but
it seems to have been ignored or lost. I can dig it out
again - the fix is pretty simple.
I would definitely would like to take a look at it.
Ah yes:
Index: base-files/files/etc/init.d/led
===
--- base-files/files/etc/init.d/led (revision 31054)
+++ base-files/files/etc/init.d/led (working copy)
@@ -1,7 +1,7 @@
#!/bin/sh /etc/rc.common
# (C) 2008 openwrt.org
-START=96
+START=94
load_led() {
local name
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Help wanted: Execution of wmac-led enabler script; where?
Experts,
I will drop a message to the ath9k-devel list for the fix,
but I suspect that it will be long before the fix actually
appears in the compat-wireless (or will not appear at all).
So I wrote an alternative script to do the same thing,
to circumvent my momentum/interest from going.
--
. /lib/ar71xx.sh
board=$(ar71xx_board_name)
ar922x_disable_gpio_jtag()
{
local regidx=0x4054
echo $regidx /sys/kernel/debug/ieee80211/$1/ath9k/regidx
regval=`cat /sys/kernel/debug/ieee80211/$1/ath9k/regval`
regval=$((regval | 0x2))
echo regval $regval
echo $regval /sys/kernel/debug/ieee80211/$1/ath9k/regval
}
if [ ${board} == wzr-hp-ag300h ]; then
ar922x_disable_gpio_jtag phy0
ar922x_disable_gpio_jtag phy1
fi
--
I have tested it by inserting the code at the done case of
the set_state() function in /etc/diag.sh, but I believe there
are other more appropriate places and/or mechanism to invoke
this kind of script. It should be executed after the ath9k*.ko
modules are loaded.
I would like to hear ideas and pointers from the openwrt experts.
--- shinoda
On 2012/08/03, at 7:21, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/08/01, at 15:45, LEO Airwarosu Yoichi Shinoda wrote:
WZR-HP-AG300H
- Current /etc/diag.sh does not support boot/init progress
indication.
- Wmac leds REQUIRES phy initialization (by means of wifi
command execution) to start working. After the first
phy initialization, they continue to work fine.
Okay, after playing around with files under
compat-wireless/driver/net/wireless/ath/ath9k
using numerous printk()s, I tracked down the problem down
to ath9k_hw_reset(), where
if (AR_SREV_9280_20_OR_LATER(ah))
REG_SET_BIT(ah, AR_GPIO_INPUT_EN_VAL, AR_GPIO_JTAG_DISABLE);
is executed. After this register write, wmac leds start to work.
By replicating these lines at the end of ath9k_hw_post_init(),
which is executed during the attach phase, and where it looked
most appropriate for an ath9k_hw novice, I could successfully
manipulate all leds on the wmacs without bringing up corresponding
interfaces.
Being without technical reference manuals for the wmac,
I wonder why something called INPUT has anything to do
with outputs, and wonder if I can disable the gpio jtag
functionality when the wmac is attached.
But nevertheless, I now have a working image.
So, what should I do next? Report to the ath9k-devel list and
ask for technically correct patch?
BTW, my current patch is as follows if someone is interested.
---
build_dir/linux-ar71xx_generic/compat-wireless-2012-07-16/drivers/net/wireless/ath/ath9k/hw.c-orig
2012-07-28 13:12:14.387929391 +0900
+++
build_dir/linux-ar71xx_generic/compat-wireless-2012-07-16/drivers/net/wireless/ath/ath9k/hw.c
2012-08-03 07:08:04.019333507 +0900
@@ -578,6 +578,9 @@
ath9k_hw_ani_init(ah);
}
+ if (AR_SREV_9280_20_OR_LATER(ah))
+ REG_SET_BIT(ah, AR_GPIO_INPUT_EN_VAL, AR_GPIO_JTAG_DISABLE);
+
return 0;
}
--- shinoda
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WMAC LED Problems
On 2012/08/01, at 15:45, LEO Airwarosu Yoichi Shinoda wrote: WZR-HP-AG300H - Current /etc/diag.sh does not support boot/init progress indication. - Wmac leds REQUIRES phy initialization (by means of wifi command execution) to start working. After the first phy initialization, they continue to work fine. Okay, after playing around with files under compat-wireless/driver/net/wireless/ath/ath9k using numerous printk()s, I tracked down the problem down to ath9k_hw_reset(), where if (AR_SREV_9280_20_OR_LATER(ah)) REG_SET_BIT(ah, AR_GPIO_INPUT_EN_VAL, AR_GPIO_JTAG_DISABLE); is executed. After this register write, wmac leds start to work. By replicating these lines at the end of ath9k_hw_post_init(), which is executed during the attach phase, and where it looked most appropriate for an ath9k_hw novice, I could successfully manipulate all leds on the wmacs without bringing up corresponding interfaces. Being without technical reference manuals for the wmac, I wonder why something called INPUT has anything to do with outputs, and wonder if I can disable the gpio jtag functionality when the wmac is attached. But nevertheless, I now have a working image. So, what should I do next? Report to the ath9k-devel list and ask for technically correct patch? BTW, my current patch is as follows if someone is interested. --- build_dir/linux-ar71xx_generic/compat-wireless-2012-07-16/drivers/net/wireless/ath/ath9k/hw.c-orig 2012-07-28 13:12:14.387929391 +0900 +++ build_dir/linux-ar71xx_generic/compat-wireless-2012-07-16/drivers/net/wireless/ath/ath9k/hw.c 2012-08-03 07:08:04.019333507 +0900 @@ -578,6 +578,9 @@ ath9k_hw_ani_init(ah); } + if (AR_SREV_9280_20_OR_LATER(ah)) + REG_SET_BIT(ah, AR_GPIO_INPUT_EN_VAL, AR_GPIO_JTAG_DISABLE); + return 0; } --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WMAC LED Problems
The problem of wmac based leds on WZR-HP-AG300H stimulated some research on status of led support on other buffalo units with wmac based leds. The following results and observations are based on the trunk revision r32910. COMMON - Wmac based leds do not appear in the /sys/class/leds directory until the corresponding phy is recognized and initialized, which happens during regular init. This suggest that we can not use wmac based leds to indicate the boot/init progress. WZR-HP-G300NH2 - Current /etc/diag.sh uses buffalo:red:diag for indicating boot/init progress. This led is connected to the platform's gpio, so it works. However, the problem is that it REMAINS LIT when the boot/init completes. VERY mis-leading. - Wmac leds works fine WITHOUT phy initialization (by means of wifi command execution). WZR-HP-G450H - Current /etc/diag.sh does not support boot/init progress indication. - Wmac leds works fine WITHOUT phy initialization (by means of wifi command execution). WZR-HP-AG300H - Current /etc/diag.sh does not support boot/init progress indication. - Wmac leds REQUIRES phy initialization (by means of wifi command execution) to start working. After the first phy initialization, they continue to work fine. OBSERVATION - If we can initiate the phy recognition before preinit, it would solve the entire problem, but I suspect this is extremely hard. - Using the buffalo:red:diag in the /etc/diag.sh seems to be the only solution, but it must be turned off when done. - The dependency on phy initialization on AG300H must be investigated. As WZR-HP-G300NH2 and WZR-HP-AG300H uses the same phy driver, there must be some discrepancy between AR9220/AR9223 and AR9280. - I wonder if other non-buffalo units with wmac leds are dealing with the problem. Comments are welcome. --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem with sysupgrade
How about adding the -n flag? --- shinoda On 2012/08/01, at 16:43, Andrea Ferraresi wrote: Hello folks, i'm currently develop a custom version of openwrt for openwisp.org project. So i have to install it remotely to a large number of access points distributed in the province of Rome. (i cannot reach the ap's easily) So when i perform a sysupgrade with our firmware i put in it a recovery tarball that contains some files included the old network configuration. The command sysupgrade -v -f old_sys.tgz new_firmware.img goes fine it replace correctly all the needed files except the /etc/config/network. In this case the one in the new firmware is preserved but we need to replace that one with the settings in the tgz package. I wish i'm explain the problem correctly. Any suggestions? Thank you. (please put me in cc) Andrea. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WMAC LED Problems
On 2012/08/01, at 22:39, Peter Naulls wrote: The problem here is that the LED handling is done in the wrong order. I submitted a fix/patch(?) for this months ago, but it seems to have been ignored or lost. I can dig it out again - the fix is pretty simple. I would definitely would like to take a look at it. --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WZR-HP-AG300H led support
On 2012/08/01, at 6:28, Peter Naulls wrote: On 07/30/2012 09:51 PM, LEO Airwarosu Yoichi Shinoda wrote: Peter and folks, I believe Peter meant WZR-HP-AG300H. Last night, I did some research on behaviors of leds on WZR-HP-AG300H, and located controls for all remaining leds on wmacs. Awesome, seems to work fine. Thanks. What about the initialization (priming?) problem I mentioned? I.e., I added a code for the wmac_leds, and they work, EXCEPT that wmacs must be enabled ONCE (by means of wifi command execution) before they actually start to work. After the first enable, leds can be controlled independent from phy states. --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Buffalo WLAE-AG300N wireless led patch
Folks, Here is the uci-defaults version of the led support for the Buffalo WLAE-AG300N. Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp = diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/leds b/target/linux/ar71xx/base-files/etc/uci-defaults/leds index e32d33d..cdbb301 100755 --- a/target/linux/ar71xx/base-files/etc/uci-defaults/leds +++ b/target/linux/ar71xx/base-files/etc/uci-defaults/leds @@ -141,6 +141,10 @@ whr-hp-gn) ucidef_set_led_switch lan4 LAN4 buffalo:green:lan4 switch0 0x10 ;; +wlae-ag300n) + ucidef_set_led_netdev wireless WIRELESS buffalo:green:wireless wlan0 + ;; + wzr-hp-g300nh) ucidef_set_led_wlan wlan Wireless buffalo:green:wireless phy0tpt ucidef_set_led_netdev router Router buffalo:green:router eth1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] WZR-HP-AG300H led support
Peter and folks,
I believe Peter meant WZR-HP-AG300H.
Last night, I did some research on behaviors of leds on WZR-HP-AG300H,
and located controls for all remaining leds on wmacs.
wmac gpio
0 12.4G amber
0 3USB
0 52.4G green
1 15G green
1 3ROUTER
1 4MOVIE ENGINE
1 55G amber
This result also suggested that we use
ap9x_pci_setup_wmac_led_pin(0, 1);
to correct phy-triggered led on 2.4G band being green,
to amber, to match that of 5G band.
I added a code for the wmac_leds, and they work, EXCEPT that
wmacs must be enabled ONCE (by means of wifi command
execution) before they actually start to work.
After the first enable, leds can be controlled independent
from phy states.
Any suggestions?
Current patch follows.
(Oh, and I also want some suggestions on band2g and band5g names.)
--- mach-wzr-hp-ag300h.c-orig 2012-07-25 22:53:19.036000195 +0900
+++ mach-wzr-hp-ag300h.c2012-07-31 13:31:16.905375954 +0900
@@ -75,6 +75,47 @@
},
};
+static struct gpio_led wzrhpag300h_wmac0_leds_gpio[] = {
+{
+.name = buffalo:amber:band2g,
+.gpio = 1,
+.active_low = 1,
+ },
+{
+.name = buffalo:green:usb,
+.gpio = 3,
+.active_low = 1,
+ },
+{
+.name = buffalo:green:band2g,
+.gpio = 5,
+.active_low = 1,
+ },
+};
+
+static struct gpio_led wzrhpag300h_wmac1_leds_gpio[] = {
+{
+.name = buffalo:green:band5g,
+.gpio = 1,
+.active_low = 1,
+ },
+{
+.name = buffalo:green:router,
+.gpio = 3,
+.active_low = 1,
+ },
+{
+.name = buffalo:blue:movie_engine,
+.gpio = 4,
+.active_low = 1,
+ },
+{
+.name = buffalo:amber:band5g,
+.gpio = 5,
+.active_low = 1,
+ },
+};
+
static struct gpio_keys_button wzrhpag300h_gpio_keys[] __initdata = {
{
.desc = reset,
@@ -111,6 +152,13 @@
.debounce_interval = WZRHPAG300H_KEYS_DEBOUNCE_INTERVAL,
.gpio = 7,
.active_low = 1,
+ }, {
+ .desc = movie_engine,
+ .type = EV_KEY,
+ .code = BTN_7,
+ .debounce_interval = WZRHPAG300H_KEYS_DEBOUNCE_INTERVAL,
+ .gpio = 8,
+ .active_low = 1,
}
};
@@ -149,6 +197,14 @@
ath79_register_m25p80_multi(wzrhpag300h_flash_data);
+ ap9x_pci_setup_wmac_led_pin(0, 1);
+ ap9x_pci_setup_wmac_led_pin(1, 5);
+
+ ap9x_pci_setup_wmac_leds(0, wzrhpag300h_wmac0_leds_gpio,
+ ARRAY_SIZE(wzrhpag300h_wmac0_leds_gpio));
+ ap9x_pci_setup_wmac_leds(1, wzrhpag300h_wmac1_leds_gpio,
+ ARRAY_SIZE(wzrhpag300h_wmac1_leds_gpio));
+
ap94_pci_init(eeprom1, mac1, eeprom2, mac2);
}
--- shinoda
On 2012/07/29, at 1:41, Peter Naulls wrote:
On 07/27/2012 07:35 PM, LEO Airwarosu Yoichi Shinoda wrote:
On 2012/07/28, at 8:04, Peter Naulls wrote:
On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote:
Folks,
Please ignore this particular (additional) patch.
I've started to learn how uci-defaults work.
Also, and unless I've missed some very recent patch, we're still sans
full support of all the LEDs on the AG300N. Anyone want to have
a go?
Do you mean full support by something similar to those provided by the
factory
firmware
(e.g.
http://www.cellularforless.com/resources/userguides/buffalo_Manual.pdf
pp.8-9)?
No, this is different, but possibly, quite similar hardware internally - the
WZR-AG300N - I thought I had seen mention of that in this thread too, but
perhaps not. I mention it for completeness.
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Buffalo WLAE-AG300N wireless led support
Folks, Please ignore this particular (additional) patch. I've started to learn how uci-defaults work. --- shinoda On 2012/07/26, at 0:36, LEO Airwarosu Yoichi Shinoda wrote: This is an additional patch for the WLAE-AG300N that makes wireless led to work. On 2012/07/24, at 11:13, LEO Airwarosu Yoichi Shinoda wrote: Folks, I also have a question regarding how to include a board dependent base-file file in the source tree. More specifically, the file is a hotplug script to get the wireless led work on the buffalo's wlae-ag300n. The wireless led on this board is not connected to the phy, but controlled independently by gpios. The script sets up the ledtrig-netdev upon detection of an addition of a wireless device on wlae-ag300n, and it is written so that it will ignore other boards. I wonder if there is a way to specify board-dependent base-file files so that this script does not go into images for other boards, or better yet, if there is a way to do this better. Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp === 300 target/linux/ar71xx/base-files/etc/hotplug.d/net/10-wlae-ag300n-wireless-led === --- /dev/null +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/net/10-wlae-ag300n-wireless-led @@ -0,0 +1,30 @@ +#!/bin/sh +# +# Manipulate Buffalo WLAE-AG300N wireless led (green only) +# +# If the blinking led is annoying, set the ledmode to link + +ledmode=link tx rx + +# Check if the device is wireless first, to prevent ar71xx.sh +# from being read. + +if [ -e /sys$DEVPATH/phy80211 ]; then + + . /lib/ar71xx.sh + + if [ `ar71xx_board_name` != wlae-ag300n ]; then + exit 0 + fi + + leddev=/sys/class/leds/buffalo\:green\:wireless + + if [ $ACTION = add ]; then + echo netdev $leddev/trigger + echo $DEVICENAME $leddev/device_name + echo $ledmode $leddev/mode + elif [ $ACTION = remove ]; then + echo none $leddev/trigger + fi +fi + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Buffalo WLAE-AG300N wireless led support
On 2012/07/28, at 8:04, Peter Naulls wrote: On 07/27/2012 04:00 PM, LEO Airwarosu Yoichi Shinoda wrote: Folks, Please ignore this particular (additional) patch. I've started to learn how uci-defaults work. Also, and unless I've missed some very recent patch, we're still sans full support of all the LEDs on the AG300N. Anyone want to have a go? Do you mean full support by something similar to those provided by the factory firmware (e.g. http://www.cellularforless.com/resources/userguides/buffalo_Manual.pdf pp.8-9)? --- shinoda smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Buffalo WLAE-AG300N wireless led support
This is an additional patch for the WLAE-AG300N that makes wireless led to work. On 2012/07/24, at 11:13, LEO Airwarosu Yoichi Shinoda wrote: Folks, I also have a question regarding how to include a board dependent base-file file in the source tree. More specifically, the file is a hotplug script to get the wireless led work on the buffalo's wlae-ag300n. The wireless led on this board is not connected to the phy, but controlled independently by gpios. The script sets up the ledtrig-netdev upon detection of an addition of a wireless device on wlae-ag300n, and it is written so that it will ignore other boards. I wonder if there is a way to specify board-dependent base-file files so that this script does not go into images for other boards, or better yet, if there is a way to do this better. Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp === 30 0 target/linux/ar71xx/base-files/etc/hotplug.d/net/10-wlae-ag300n-wireless-led === --- /dev/null +++ b/target/linux/ar71xx/base-files/etc/hotplug.d/net/10-wlae-ag300n-wireless-led @@ -0,0 +1,30 @@ +#!/bin/sh +# +# Manipulate Buffalo WLAE-AG300N wireless led (green only) +# +# If the blinking led is annoying, set the ledmode to link + +ledmode=link tx rx + +# Check if the device is wireless first, to prevent ar71xx.sh +# from being read. + +if [ -e /sys$DEVPATH/phy80211 ]; then + + . /lib/ar71xx.sh + + if [ `ar71xx_board_name` != wlae-ag300n ]; then + exit 0 + fi + + leddev=/sys/class/leds/buffalo\:green\:wireless + + if [ $ACTION = add ]; then + echo netdev $leddev/trigger + echo $DEVICENAME $leddev/device_name + echo $ledmode $leddev/mode + elif [ $ACTION = remove ]; then + echo none $leddev/trigger + fi +fi + ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Buffalo WLAE-AG300N initial support
The patch set for Buffalo WLAE-AG300N initial support.
There is another patch for wireless led support that
is posted separately.
Note on serial console:
This unit has buffalo standard 4 pin console, but the unit may not power
on if some console apparatus is connected. This is probably due to some
electronic interaction between the unit's electronic power switch circuit
and the serial console apparatus. If this happens, it is required to power
on the unit without the console, then quickly (re-)attach it.
Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp
===
3 0 target/linux/ar71xx/base-files/etc/diag.sh
3 0 target/linux/ar71xx/base-files/lib/ar71xx.sh
1 0 target/linux/ar71xx/base-files/lib/upgrade/platform.sh
1 0 target/linux/ar71xx/config-3.3
114 0 target/linux/ar71xx/files/arch/mips/ath79/mach-wlae-ag300n.c
11 0 target/linux/ar71xx/generic/profiles/buffalo.mk
6 0 target/linux/ar71xx/image/Makefile
17 7
target/linux/ar71xx/patches-3.3/610-MIPS-ath79-openwrt-machines.patch
===
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index f52012f..02cfa35 100755
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -141,6 +141,9 @@ get_status_led() {
wzr-hp-g300nh)
status_led=buffalo:green:router
;;
+ wlae-ag300n)
+ status_led=buffalo:green:status
+ ;;
wzr-hp-g300nh2)
status_led=buffalo:red:diag
;;
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 4d21caf..2829d9f 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -354,6 +354,9 @@ ar71xx_board_detect() {
*WHR-HP-GN)
name=whr-hp-gn
;;
+ *WLAE-AG300N)
+ name=wlae-ag300n
+ ;;
*WP543)
name=wp543
;;
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index 5e5a54f..0e08603 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -118,6 +118,7 @@ platform_check_image() {
whr-g301n | \
whr-hp-g300n | \
whr-hp-gn | \
+ wlae-ag300n | \
nbg460n_550n_550nh | \
unifi )
[ $magic != 2705 ] {
diff --git a/target/linux/ar71xx/config-3.3 b/target/linux/ar71xx/config-3.3
index ebb0553..9e0f5b1 100644
--- a/target/linux/ar71xx/config-3.3
+++ b/target/linux/ar71xx/config-3.3
@@ -66,6 +66,7 @@ CONFIG_ATH79_MACH_TL_WR941ND=y
CONFIG_ATH79_MACH_UBNT=y
CONFIG_ATH79_MACH_UBNT_XM=y
CONFIG_ATH79_MACH_WHR_HP_G300N=y
+CONFIG_ATH79_MACH_WLAE_AG300N=y
CONFIG_ATH79_MACH_WNDR3700=y
CONFIG_ATH79_MACH_WNR2000=y
CONFIG_ATH79_MACH_WP543=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wlae-ag300n.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wlae-ag300n.c
new file mode 100644
index 000..c2dbc69
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wlae-ag300n.c
@@ -0,0 +1,114 @@
+/*
+ * Buffalo WLAE-AG300N board support
+ */
+
+#include linux/gpio.h
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+#include asm/mach-ath79/ath79.h
+
+#include dev-eth.h
+#include dev-ap9x-pci.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-m25p80.h
+#include dev-usb.h
+#include machtypes.h
+
+#define WLAEAG300N_MAC_OFFSET 0x20c
+#define WLAEAG300N_KEYS_POLL_INTERVAL 20 /* msecs */
+#define WLAEAG300N_KEYS_DEBOUNCE_INTERVAL (3 * WLAEAG300N_KEYS_POLL_INTERVAL)
+
+
+static struct gpio_led wlaeag300n_leds_gpio[] __initdata = {
+ //
+ // Note: Writing 1 into GPIO 13 will power down the device.
+ //
+ {
+ .name = buffalo:green:wireless,
+ .gpio = 14,
+ .active_low = 1,
+ }, {
+ .name = buffalo:red:wireless,
+ .gpio = 15,
+ .active_low = 1,
+ }, {
+ .name = buffalo:green:status,
+ .gpio = 16,
+ .active_low = 1,
+ }, {
+ .name = buffalo:red:status,
+ .gpio = 17,
+ .active_low = 1,
+ }
+};
+
+
+static struct gpio_keys_button wlaeag300n_gpio_keys[] __initdata = {
+ {
+ .desc = function,
+ .type = EV_KEY,
+ .code = KEY_MODE,
+ .debounce_interval =
Re: [OpenWrt-Devel] Patch formatting for new device support
Bump Anyone? --- shinoda On 2012/07/15, at 14:36, LEO Airwarosu Yoichi Shinoda wrote: Hi. I've finished working on a support for Buffalo WLAE-AG300N, and was going to post a patch set. I noticed that machtype.h and Kconfig are not in the directory target/linux/ar71xx/files/arch/mips/ath79/ any more, but provided as a patch (i.e. 610-MIPS-ath79-openwrt-machines.patch) in patches-3.3. Should I create patches for machtype.h and Kconfig, or should I create a patch for 610-MIPS-openwrt-machines.patch? --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Board dependent base-file files in the source tree?
Folks, I also have a question regarding how to include a board dependent base-file file in the source tree. More specifically, the file is a hotplug script to get the wireless led work on the buffalo's wlae-ag300n. The wireless led on this board is not connected to the phy, but controlled independently by gpios. The script sets up the ledtrig-netdev upon detection of an addition of a wireless device on wlae-ag300n, and it is written so that it will ignore other boards. I wonder if there is a way to specify board-dependent base-file files so that this script does not go into images for other boards, or better yet, if there is a way to do this better. FYI, the script follows. #!/bin/sh # # Manipulate Buffalo WLAE-AG300N wireless led (green only) # # If the blinking led is annoying, set the ledmode to link ledmode=link tx rx # Check if the device is wireless first, to prevent ar71xx.sh # from being read. if [ -e /sys$DEVPATH/phy80211 ]; then . /lib/ar71xx.sh if [ `ar71xx_board_name` != wlae-ag300n ]; then exit 0 fi leddev=/sys/class/leds/buffalo\:green\:wireless if [ $ACTION = add ]; then echo netdev $leddev/trigger echo $DEVICENAME $leddev/device_name echo $ledmode $leddev/mode elif [ $ACTION = remove ]; then echo none $leddev/trigger fi fi --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] D-Link DAP-1350 initial support
The initial support for the D-Link DAP-1350.
USB related functionality is not tested.
Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp
---
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 68aa0ee..c1f5949 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -39,6 +39,9 @@ get_status_led() {
dir-300-b1 | dir-600-b1 | dir-600-b2)
status_led=d-link:green:status
;;
+ dap-1350)
+ status_led=d-link:blue:power
+ ;;
esr-9753)
status_led=esr-9753:orange:power
;;
diff --git
a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
index d7542ca..2f7cb33 100644
--- a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
+++ b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
@@ -38,6 +38,10 @@ case $FIRMWARE in
rt2x00_eeprom_extract devdata 16384 272
;;
+ dap-1350)
+ rt2x00_eeprom_extract devdata 0 272
+ ;;
+
rt-n10-plus | \
rt-g32-b1)
rt2x00_eeprom_extract devconf 0 272
diff --git a/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
b/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
index db6e5c8..ebe06f4 100644
--- a/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
+++ b/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
@@ -29,6 +29,10 @@ preinit_set_mac_address() {
mac=$(ramips_get_mac_binary devdata 16388)
ifconfig eth0 hw ether $mac 2/dev/null
;;
+ dap-1350)
+ mac=$(ramips_get_mac_binary devdata 46)
+ ifconfig eth0 hw ether $mac 2/dev/null
+;;
all0256n |\
fonera20n |\
hw550-3g |\
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 277d9da..4a96d50 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -77,6 +77,9 @@ ramips_board_name() {
*DIR-600 B2)
name=dir-600-b2
;;
+*DAP-1350)
+name=dap-1350
+;;
*ESR-9753)
name=esr-9753
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index dba5e79..4b41d7e 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -20,6 +20,7 @@ platform_check_image() {
dir-300-b1 | \
dir-600-b1 | \
dir-600-b2 | \
+ dap-1350 | \
esr-9753 | \
fonera20n | \
freestation5 | \
diff --git
a/target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
b/target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
index 6ff24f2..e04c365 100644
--- a/target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
+++ b/target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
@@ -36,6 +36,7 @@ enum ramips_mach_type {
/* RT3052 based machines */
RAMIPS_MACH_ARGUS_ATP52B, /* Argus ATP-52B */
RAMIPS_MACH_BC2,/* NexAira BC2 */
+ RAMIPS_MACH_DAP_1350, /* D-Link DAP-1350 */
RAMIPS_MACH_ESR_9753, /* Senao / EnGenius ESR-9753*/
RAMIPS_MACH_F5D8235_V2, /* Belkin F5D8235 v2 */
RAMIPS_MACH_FONERA20N, /* La Fonera 2.0N */
diff --git a/target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
b/target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
index 77269fe..999cb1a 100644
--- a/target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
+++ b/target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
@@ -66,6 +66,11 @@ config RT305X_MACH_DIR_300_REVB
select RALINK_DEV_GPIO_BUTTONS
select RALINK_DEV_GPIO_LEDS
+config RT305X_MACH_DAP_1350
+ bool D-Link DAP-1350 board support
+ select RALINK_DEV_GPIO_BUTTONS
+ select RALINK_DEV_GPIO_LEDS
+
config RT305X_MACH_ESR_9753
bool EnGenius ESR-9753 support
select RALINK_DEV_GPIO_BUTTONS
diff --git a/target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
b/target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
index bb8cf07..eee5a0d 100644
--- a/target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
+++ b/target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
@@ -16,6 +16,7 @@ obj-$(CONFIG_RT305X_MACH_ARGUS_ATP52B)+=
mach-argus-atp52b.o
obj-$(CONFIG_RT305X_MACH_BC2) += mach-bc2.o
obj-$(CONFIG_RT305X_MACH_ALL0256N) += mach-all0256n.o
obj-$(CONFIG_RT305X_MACH_DIR_300_REVB) +=
[OpenWrt-Devel] Patch formatting for new device support
Hi. I've finished working on a support for Buffalo WLAE-AG300N, and was going to post a patch set. I noticed that machtype.h and Kconfig are not in the directory target/linux/ar71xx/files/arch/mips/ath79/ any more, but provided as a patch (i.e. 610-MIPS-ath79-openwrt-machines.patch) in patches-3.3. Should I create patches for machtype.h and Kconfig, or should I create a patch for 610-MIPS-openwrt-machines.patch? --- shinoda ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: rt305x: add add support for the Asus WL-330N3G board
Hi.
It looks like the current ramips config only generates sysupgrade.bin version
of the image for WL-330N3G. Is there any pointer to an write-up describing
how to put this image into the real hw?
Any info would be appreciated.
Thanks in advance.
--- shinoda
On 2012/04/22, at 18:31, Frédéric Leroy wrote:
This patch adds support for the ASUS WL-330N3G
Comparing to the WL-330N, It have 32MB ram, usb support and a bicolor led.
The bi-color led is driven by 2 gpio.
I don't know how to handle this, so I simply made 2 leds : one red, one blue.
But the red light takes precedence over the blue one according to the chart
below.
r = led is red
b = led is blue
0 = led is off
xy= x-r for red, b for blue led, y-value of brightness in
/sys/class/leds/x/brughtness
initial state action ledgpio state
r0b0 r0-r1 r r0 b0
r0b0 b0-b1 b r0 b1
r1b0 r1-r0 0 r0 b0
r1b0 b0-b1 r r1 *b1*
r1b1 r1-r0 b r0 b1
r1b1 b1-b0 r r1 b0
r0b1 r0-r1 r r1 *b1*
r0b1 b1-b0 0 r0 r0
Signed-off-by: Frédéric Leroy fr...@starox.org
---
target/linux/ramips/base-files/etc/diag.sh |2 +-
.../etc/hotplug.d/firmware/10-rt2x00-eeprom|1 +
.../ramips/base-files/lib/preinit/06_set_iface_mac |1 +
target/linux/ramips/base-files/lib/ramips.sh |3 +
.../arch/mips/include/asm/mach-ralink/machine.h|1 +
.../ramips/files/arch/mips/ralink/rt305x/Kconfig |5 +
.../ramips/files/arch/mips/ralink/rt305x/Makefile |1 +
.../files/arch/mips/ralink/rt305x/mach-wl-330n3g.c | 100
target/linux/ramips/image/Makefile |5 +
target/linux/ramips/rt305x/config-3.2 |1 +
10 files changed, 119 insertions(+), 1 deletions(-)
create mode 100644
target/linux/ramips/files/arch/mips/ralink/rt305x/mach-wl-330n3g.c
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 95f608a..aa02721 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -69,7 +69,7 @@ get_status_led() {
rt-n10-plus)
status_led=asus:green:wps
;;
- rt-n56u | wl-330n )
+ rt-n56u | wl-330n | wl-330n3g)
status_led=asus:blue:power
;;
sl-r7205)
diff --git
a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
index 62788cd..3a602f7 100644
--- a/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
+++ b/target/linux/ramips/base-files/etc/hotplug.d/firmware/10-rt2x00-eeprom
@@ -69,6 +69,7 @@ case $FIRMWARE in
wcr-150gn | \
whr-g300n | \
wl-330n | \
+ wl-330n3g | \
wl-351 | \
wli-tx4-ag300n | \
wr512-3gn | \
diff --git a/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
b/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
index f523d69..131c9ba 100644
--- a/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
+++ b/target/linux/ramips/base-files/lib/preinit/06_set_iface_mac
@@ -30,6 +30,7 @@ preinit_set_mac_address() {
omni-emb |\
w502u|\
wl-330n |\
+ wl-330n3g |\
wr6202 |\
xdxrn502j)
mac=$(ramips_get_mac_binary factory 40)
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 1298ebd..801a134 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -59,6 +59,9 @@ ramips_board_name() {
*Asus WL-330N)
name=wl-330n
;;
+ *Asus WL-330N3G)
+ name=wl-330n3g
+ ;;
*Aztech HW550-3G)
name=hw550-3g
;;
diff --git
a/target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
b/target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
index c2ec146..46a091b 100644
--- a/target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
+++ b/target/linux/ramips/files/arch/mips/include/asm/mach-ralink/machine.h
@@ -30,6 +30,7 @@ enum ramips_mach_type {
RAMIPS_MACH_RT_N10_PLUS,/* Asus RT-N10+ */
RAMIPS_MACH_NW718, /* Netcore NW718 */
RAMIPS_MACH_WL_330N,/* Asus WL-330N */
+ RAMIPS_MACH_WL_330N3G, /* Asus WL-330N3G */
/* RT3052 based machines */
RAMIPS_MACH_ARGUS_ATP52B, /* Argus ATP-52B */
diff --git a/target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
b/target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
index ef4ddf4..5c86de3 100644
--- a/target/linux/ramips/files/arch/mips/ralink/rt305x/Kconfig
+++
[OpenWrt-Devel] __asm__ (mips) guru's help wanted
Hi.
While porting Realtek's 8196c code to OpenWrt,
I came up with a need for an inline asm macro that mimics
instructions that manipulate lexra's CP0 registers.
The instructions are
MFLXC0 reg,cp0reg
where cp0reg = 0 (ESTATUS), 1 (ECAUSE) or 2 (INTVEC),
to read ESTATUS, ECAUSE or INTVEC into reg, and
MTLXC0 reg,cp0reg
where cp0reg = 0 (ESTATUS) or 2 (INTVEC),
to write reg into ESTATUS or INTVEC.
For MFLXC0, the base opcode is 0x4060, and the
reg and cp0reg are encoded as 0x4060 | (reg 16) | (cp0reg 11).
For MTLXC0, the base opcode is 0x40e0.
Let's say I want an inline macro that read the ECAUSE register.
I came up with the following.
#define read_lxc0_ecause() \
({ int __res; \
__asm__ __volatile__( \
.word 0x40600800 | (%0 16)\n\t\
: =r (__res));\
__res; \
})
If I just write read_lxc0_ecause();, and assume $2 is
assigned to %0 by gcc, then I have
#APP
.word 0x40600800 | ($2 16)
#NOAPP
sw $2,8($fp)
which clearly will not survive through an as stage.
I would want
.word 0x40600800 | (2 16)
instead of
.word 0x40600800 | ($2 16)
Is there anyway to convert the assigned $2 into 2
(or equivalent integer constant) before it is pass to the as stage?
Any help would be appreciated, including a pointer to proper ML
that this question should be redirected to.
Thanks in advance.
--- shinoda
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] HELP : Can't patch config.sub in a package
Hello,
I'm trying to add a new processor type (lexra), but having
trouble patching the config.sub, that checks for recognizable
cpu-os-kernel identifier, used in some packages.
More specifically, I want the config.sub in iptables-1.4.10 to
recognize the 'lexra-openwrt-linux'.
I'm working on the trunk r29839.
In the first place, I thought I can do this as a piece of cake
by adding a patch file that adds couple of lines to the config.sub,
in ${BUILDROOT}/package/iptables/patches.
Then, after few attempts, I found out that the autoreconf or a similar
mechanism replaces
${BUILDROOT}/build_dir/${TARGETSPEC}/iptables-1.4.10/config.sub
during the build process so that it points (symlinks) to
${BUILDROOT}/staging_dir/host/share/automake-1.11/config.sub.
At this point, I turned around and added a similar patch to
${BUILDROOT}/tools/automake/patches.
I checked my result immediately after the automake build,
and confirmed that the config.sub was patched appropriately.
But, ...the next make V=99 only revealed that the
${BUILDROOT}/staging_dir/host/share/automake-1.11/config.sub
was magically overwritten to the original unpatched state.
Here's my question:
I'm not an expert on OpenWrt build system, and therefore
I believe this is some kind of magic, and I also believe that
I need a same kind of magic to overcome this problem.
Is there any?
Thanks in advance,
--- shinoda
P.S.
Here's some discussion:
Is the behavior of Modifying a generic build tool during a build
process for a single target considered legitimate?
Wouldn't it introduce some unexpected side effects?
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] HELP : Can't patch config.sub in a package
Jow, Yes, patch scripts/config.sub - that is whats fored upon each package. Yikes!!! Thanks a billion!!! I've been caught in this trap for half a day. Packages were built flawlessly. Is the behavior of Modifying a generic build tool during a build process for a single target considered legitimate? Modifying the generic build tool to accept a new platform is certainly legitimate, nobody wants to patch a new CPU definition into each single package. Ah, then, automake's config.sub should be patched once when it is built? :-) (There's no argument, just my personal thoughts.) --- shinoda On 2012/01/23, at 3:33, Jo-Philipp Wich wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi. I need a same kind of magic to overcome this problem. Is there any? Yes, patch scripts/config.sub - that is whats fored upon each package. Is the behavior of Modifying a generic build tool during a build process for a single target considered legitimate? Modifying the generic build tool to accept a new platform is certainly legitimate, nobody wants to patch a new CPU definition into each single package. Wouldn't it introduce some unexpected side effects? Its autohell so nobody can tell :) ~ Jow -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk8cVnkACgkQdputYINPTPOmHQCeK+HDFGdXAfX8QjM4trm9B1uM RDoAoIB1Gu3rRoaRs3OVkviYxsET6qLx =7I17 -END PGP SIGNATURE- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] PATCH: Buffalo WZR-HP-G300NH2 support
On 2011/08/30, at 6:13, Peter Naulls wrote: I have an immediate need to support v1 and v2 hardware in one image. As products they are essentially identical, as well as in user space in Linux, and deploying a image which is all but identical to support 2 machines makes no sense to me. Are you sure that WZR-HP-G300NH/NH1 and WZR-HP-G300NH2 are (essentially) identical? Here are brief description of chip sets used in WZR-HP*. WZR-HP-G300NH1 AR9132 + AR9100 + RTL8366* (WZR-HP-G300NH, WZR-HP-G301NH(JP market), WZR-HP-G302NH(JP market)) WZR-HP-G300NH2 AR7242 + AR9280 + AR8316 and just FYI, WHR-HP-G300NAR7240 + AR9280 + AR8316 WZR-HP-AG300H AR7161 + AR9220 + AR9223 + AR8316 --- shinoda smime.p7s Description: S/MIME cryptographic signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Buffalo WHR-HP-G300N initial support
The initial support for the Buffalo WHR-HP-G300N box.
The code was confirmed to boot and run, but not tested in depth.
Known problem: iw phy phy0 info shows:
Coverage class: 0 (up to 0m)
Available Antennas: TX 0 RX 0
Signed-off-by: Yoichi Shinoda shin...@jaist.ac.jp
---
Index: target/linux/ar71xx/files/arch/mips/ar71xx/mach-whr-hp-g300n.c
===
--- target/linux/ar71xx/files/arch/mips/ar71xx/mach-whr-hp-g300n.c
(revision 0)
+++ target/linux/ar71xx/files/arch/mips/ar71xx/mach-whr-hp-g300n.c
(revision 0)
@@ -0,0 +1,171 @@
+/*
+ * Buffalo WHR-HP-G300N board support
+ *
+ * based on ...
+ *
+ * TP-LINK TL-WR741ND board support
+ *
+ * Copyright (C) 2009-2010 Gabor Juhos juh...@openwrt.org
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/mtd/mtd.h
+#include linux/mtd/partitions.h
+
+#include asm/mach-ar71xx/ar71xx.h
+
+#include machtype.h
+#include devices.h
+#include dev-m25p80.h
+#include dev-ap91-pci.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+
+#defineWHRHPG300N_GPIO_LED_SECURITY0
+#defineWHRHPG300N_GPIO_LED_DIAG1
+#defineWHRHPG300N_GPIO_LED_ROUTER 6
+
+#defineWHRHPG300N_GPIO_BTN_ROUTER_ON 7
+#defineWHRHPG300N_GPIO_BTN_ROUTER_AUTO 8
+#defineWHRHPG300N_GPIO_BTN_RESET 11
+#defineWHRHPG300N_GPIO_BTN_AOSS12
+
+#defineWHRHPG300N_KEYS_POLL_INTERVAL 20 /* msecs */
+#define WHRHPG300N_KEYS_DEBOUNCE_INTERVAL (3 * WHRHPG300N_KEYS_POLL_INTERVAL)
+
+#define WHRHPG300N_MAC_OFFSET 0x20c
+
+#ifdef CONFIG_MTD_PARTITIONS
+static struct mtd_partition whrhpg300n_partitions[] = {
+ {
+ .name = u-boot,
+ .offset = 0,
+ .size = 0x03e000,
+ .mask_flags = MTD_WRITEABLE,
+ }, {
+ .name = u-boot-env,
+ .offset = 0x03e000,
+ .size = 0x002000,
+ }, {
+ .name = kernel,
+ .offset = 0x04,
+ .size = 0x0e,
+ }, {
+ .name = rootfs,
+ .offset = 0x12,
+ .size = 0x2c,
+ }, {
+ .name = NVRAM,
+ .offset = 0x3e,
+ .size = 0x01,
+ }, {
+ .name = ART,
+ .offset = 0x3f,
+ .size = 0x01,
+ .mask_flags = MTD_WRITEABLE,
+ }, {
+ .name = firmware,
+ .offset = 0x04,
+ .size = 0x3a,
+ }
+};
+#endif /* CONFIG_MTD_PARTITIONS */
+
+static struct flash_platform_data whrhpg300n_flash_data = {
+#ifdef CONFIG_MTD_PARTITIONS
+ .parts = whrhpg300n_partitions,
+ .nr_parts = ARRAY_SIZE(whrhpg300n_partitions),
+#endif
+};
+
+static struct gpio_led whrhpg300n_leds_gpio[] __initdata = {
+ {
+ .name = whr_hp_g300n:orange:security,
+ .gpio = WHRHPG300N_GPIO_LED_SECURITY,
+ .active_low = 1,
+ }, {
+ .name = whr_hp_g300n:red:diag,
+ .gpio = WHRHPG300N_GPIO_LED_DIAG,
+ .active_low = 1,
+ }, {
+ .name = whr_hp_g300n:green:router,
+ .gpio = WHRHPG300N_GPIO_LED_ROUTER,
+ .active_low = 1,
+ }
+};
+
+static struct gpio_keys_button whrhpg300n_gpio_keys[] __initdata = {
+ {
+ .desc = reset,
+ .type = EV_KEY,
+ .code = KEY_RESTART,
+ .debounce_interval = WHRHPG300N_KEYS_DEBOUNCE_INTERVAL,
+ .gpio = WHRHPG300N_GPIO_BTN_RESET,
+ .active_low = 1,
+ }, {
+ .desc = aoss/wps,
+ .type = EV_KEY,
+ .code = KEY_WPS_BUTTON,
+ .gpio = WHRHPG300N_GPIO_BTN_AOSS,
+ .debounce_interval = WHRHPG300N_KEYS_DEBOUNCE_INTERVAL,
+ .active_low = 1,
+ }, {
+ .desc = router_on,
+ .type = EV_KEY,
+ .code = BTN_2,
+ .gpio = WHRHPG300N_GPIO_BTN_ROUTER_ON,
+ .debounce_interval = WHRHPG300N_KEYS_DEBOUNCE_INTERVAL,
+ .active_low = 1,
+ }, {
+ .desc = router_auto,
+ .type =
