[OpenWrt-Devel] [PATCH] ramips: adding support for OY-0001 Wireless Router
From: Tom Deng <2579131...@qq.com>
Adding support for OY-0001 Wireless Router.
OY-0001 is a wireless router made by oyewifi.com. Below is the details:
MT7620A, 128MB DDR2, 16MB FLASH, SD Slot, USB 2.0, 4 x LAN + 1 x WAN.
Signed-off-by: Tom Deng <2579131...@qq.com>
---
diff --git a/target/linux/ramips/base-files/etc/diag.sh
b/target/linux/ramips/base-files/etc/diag.sh
index 74b8867..35a64dd 100755
--- a/target/linux/ramips/base-files/etc/diag.sh
+++ b/target/linux/ramips/base-files/etc/diag.sh
@@ -186,6 +186,9 @@ get_status_led() {
f7c027)
status_led="belkin:orange:status"
;;
+ oy-0001)
+ status_led="oy:green:wifi"
+ ;;
na930)
status_led="na930:blue:power"
;;
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/01_leds
b/target/linux/ramips/base-files/etc/uci-defaults/01_leds
index 5d6ed2b..265525a 100755
--- a/target/linux/ramips/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ramips/base-files/etc/uci-defaults/01_leds
@@ -199,6 +199,10 @@ case $board in
set_wifi_led "zbtlink:blue:air"
set_usb_led "zbtlink:blue:usb"
;;
+ oy-0001)
+ ucidef_set_led_default "power" "power" "oy:green:power" "1"
+ set_wifi_led "oy:green:wifi"
+ ;;
wr8305rt)
ucidef_set_led_default "power" "power" "wr8305rt:sys" "1"
set_usb_led "wr8305rt:usb"
diff --git a/target/linux/ramips/base-files/etc/uci-defaults/02_network
b/target/linux/ramips/base-files/etc/uci-defaults/02_network
index c3ea489..b847a1b 100755
--- a/target/linux/ramips/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ramips/base-files/etc/uci-defaults/02_network
@@ -104,6 +104,7 @@ ramips_setup_interfaces()
dir-615-h1 | \
hlk-rm04 | \
mzk-w300nh2 | \
+ oy-0001 | \
mzk-750dhp)
ucidef_set_interfaces_lan_wan "eth0.1" "eth0.2"
ucidef_add_switch "switch0" "1" "1"
@@ -221,6 +222,11 @@ ramips_setup_macs()
wan_mac=$(mtd_get_mac_binary devdata 7)
;;
+ oy-0001)
+ lan_mac=$(mtd_get_mac_binary factory 40)
+ wan_mac=$(mtd_get_mac_binary factory 46)
+ ;;
+
w306r-v20)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(macaddr_add "$lan_mac" 5)
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index fd03423..f95adc5 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -325,6 +325,9 @@ ramips_board_detect() {
*"Zbtlink ZBT-WA05")
name="zbt-wa05"
;;
+ *"OY-0001")
+ name="oy-0001"
+ ;;
*"ZBT WR8305RT")
name="wr8305rt"
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index ba69a89..ad35f9d 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -96,6 +96,7 @@ platform_check_image() {
wmr300 |\
wr8305rt |\
wrtnode |\
+ oy-0001 |\
x5 |\
x8 |\
zbt-wa05 |\
diff --git a/target/linux/ramips/dts/OY-0001.dts
b/target/linux/ramips/dts/OY-0001.dts
new file mode 100644
index 000..48b7099
--- /dev/null
+++ b/target/linux/ramips/dts/OY-0001.dts
@@ -0,0 +1,123 @@
+/dts-v1/;
+
+/include/ "mt7620a.dtsi"
+
+/ {
+ compatible = "ralink,mt7620a-soc";
+ model = "OY-0001";
+
+chosen {
+bootargs = "console=ttyS0,115200";
+};
+
+ palmbus@1000 {
+ gpio2: gpio@660 {
+ status = "okay";
+ };
+
+ gpio3: gpio@688 {
+ status = "okay";
+ };
+
+ spi@b00 {
+ status = "okay";
+
+ m25p80@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "w25q128";
+ reg = <0 0>;
+ linux,modalias = "m25p80", "w25q128";
+ spi-max-frequency = <1000>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x0 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "u-boot-env";
+ reg = <0x3 0x1>;
+ read-only;
+
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images
On 5 July 2015 at 23:31, Matt . wrote: > Hi, > > This needs to be patched on ALL versions! After this, we need to point > the main devs of this package to it. > > Sounds like a plan ? > What do you mean ALL versions? This patch is easily backportable into CC if you mean that... Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Huawei 3372 NCM support on CC not working
Ahoy everyone, If you are interested again, here is the working patch. After removing the cover, I could verify that the Telekom Speedstick LTE V is actually a Huawei 3372s (at least it says so on the label next to the IMEI). I've applied mrkiko's latest patches and also tested vittgam's hints about tx magic but the situation and symptoms habe not changed, here's the trace: Huawei 3372 ncm-patch2 trace on mr3020 (MIPS) dmesg after bootup: [0.00] Linux version 3.18.16 (chrono@chronos) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r46120) ) #1 Sat Jul 4 15:34:33 2015 [0.00] MyLoader: sysp=7ab7c29c, boardp=07ac6486, parts=24fed496 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 00019374 (MIPS 24Kc) [0.00] SoC: Atheros AR9330 rev 1 [0.00] Determined physical RAM map: [0.00] memory: 0200 @ (usable) [0.00] Initrd not found or empty - disabling initrd [0.00] Zone ranges: [0.00] Normal [mem 0x-0x01ff] [0.00] Movable zone start for each node [0.00] Early memory node ranges [0.00] node 0: [mem 0x-0x01ff] [0.00] Initmem setup node 0 [mem 0x-0x01ff] [0.00] On node 0 totalpages: 8192 [0.00] free_area_init_node: node 0, pgdat 803500f0, node_mem_map 8100 [0.00] Normal zone: 64 pages used for memmap [0.00] Normal zone: 0 pages reserved [0.00] Normal zone: 8192 pages, LIFO batch:0 [0.00] Primary instruction cache 64kB, VIPT, 4-way, linesize 32 bytes. [0.00] Primary data cache 32kB, 4-way, VIPT, cache aliases, linesize 32 bytes [0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768 [0.00] pcpu-alloc: [0] 0 [0.00] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 8128 [0.00] Kernel command line: board=TL-MR3020 console=ttyATH0,115200 rootfstype=squashfs,jffs2 noinitrd [0.00] PID hash table entries: 128 (order: -3, 512 bytes) [0.00] Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) [0.00] Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) [0.00] Writing ErrCtl register= [0.00] Readback ErrCtl register= [0.00] Memory: 28536K/32768K available (2452K kernel code, 119K rwdata, 524K rodata, 224K init, 188K bss, 4232K reserved) [0.00] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1 [0.00] NR_IRQS:51 [0.00] Clocks: CPU:400.000MHz, DDR:400.000MHz, AHB:200.000MHz, Ref:25.000MHz [0.00] Calibrating delay loop... 265.42 BogoMIPS (lpj=1327104) [0.08] pid_max: default: 32768 minimum: 301 [0.08] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.09] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes) [0.10] NET: Registered protocol family 16 [0.10] MIPS: machine is TP-LINK TL-MR3020 [0.37] Switched to clocksource MIPS [0.37] NET: Registered protocol family 2 [0.38] TCP established hash table entries: 1024 (order: 0, 4096 bytes) [0.38] TCP bind hash table entries: 1024 (order: 0, 4096 bytes) [0.38] TCP: Hash tables configured (established 1024 bind 1024) [0.39] TCP: reno registered [0.39] UDP hash table entries: 256 (order: 0, 4096 bytes) [0.40] UDP-Lite hash table entries: 256 (order: 0, 4096 bytes) [0.41] NET: Registered protocol family 1 [0.41] PCI: CLS 0 bytes, default 32 [0.41] futex hash table entries: 256 (order: -1, 3072 bytes) [0.43] squashfs: version 4.0 (2009/01/31) Phillip Lougher [0.43] jffs2: version 2.2 (NAND) (SUMMARY) (LZMA) (RTIME) (CMODE_PRIORITY) (c) 2001-2006 Red Hat, Inc. [0.44] msgmni has been set to 55 [0.46] io scheduler noop registered [0.46] io scheduler deadline registered (default) [0.46] Serial: 8250/16550 driver, 1 ports, IRQ sharing disabled [0.47] ar933x-uart: ttyATH0 at MMIO 0x1802 (irq = 11, base_baud = 1562500) is a AR933X UART [0.48] console [ttyATH0] enabled [0.48] bootconsole [early0] disabled [0.50] m25p80 spi0.0: found s25sl032p, expected m25p80 [0.50] m25p80 spi0.0: s25sl032p (4096 Kbytes) [0.51] 5 tp-link partitions found on MTD device spi0.0 [0.51] Creating 5 MTD partitions on "spi0.0": [0.52] 0x-0x0002 : "u-boot" [0.52] 0x0002-0x00132940 : "kernel" [0.53] 0x00132940-0x003f : "rootfs" [0.53] mtd: device 2 (rootfs) set to be root filesystem [0.54] 1 squashfs-split partitions found on MTD device rootfs [0.54] 0x003a-0x003f : "rootfs_data" [0.55] 0x003f-0x0040 : "art" [0.55] 0x0002-0x003f : "firmware" [0.58] libphy: ag
[OpenWrt-Devel] VoCore as wireless bridge
Hi,
I am trying to use VoCore (RT5350 board) as wireless bridge with the following
wpa_supplicant config:
ctrl_interface=/var/run/wpa.sock
update_config=1
fast_reauth=1
ap_scan=1
network={
ssid="home_wifi"
psk=915644af001df2afbcf02df60f3fc27f9f7d7b09f1ac3667bb84e0776ec25e08
}
I do:
# iw dev wlan0 interface add client0 type station
# wpa_supplicant -i client0 -c ./wpa.conf -dd -t
And got log:
1436168056.380440: Successfully initialized wpa_supplicant
1436168057.769320: client0: SME: Trying to authenticate with 00:21:91:8b:61:c4
(SSID='home_wifi' freq=2462 MHz)
1436168057.827220: client0: Trying to associate with 00:21:91:8b:61:c4
(SSID='home_wifi' freq=2462 MHz)
1436168057.874320: client0: Associated with 00:21:91:8b:61:c4
1436168057.989180: client0: WPA: Key negotiation completed with
00:21:91:8b:61:c4 [PTK=CCMP GTK=CCMP]
1436168057.990540: client0: CTRL-EVENT-CONNECTED - Connection to
00:21:91:8b:61:c4 completed [id=0 id_str=]
Kernel side:
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.44] client0: authenticate
with 00:21:91:8b:61:c4
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.48] client0: send auth to
00:21:91:8b:61:c4 (try 1/3)
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.49] client0: authenticated
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.51] client0: associate
with 00:21:91:8b:61:c4 (try 1/3)
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.52] client0: RX AssocResp
from 00:21:91:8b:61:c4 (capab=0x411 status=0 aid=1)
Mon Jul 6 07:36:11 2015 kern.info kernel: [130154.54] client0: associated
Looks like everything is fine:
# iwinfo
client0 ESSID: "home_wifi"
Access Point: 00:21:91:8B:61:C4
Mode: Client Channel: 11 (2.462 GHz)
Tx-Power: 20 dBm Link Quality: 42/70
Signal: -68 dBm Noise: unknown
Bit Rate: 65.0 MBit/s
Encryption: unknown
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0
wlan0 ESSID: "OpenWrt"
Access Point: 00:0C:43:30:50:F8
Mode: Master Channel: 11 (2.462 GHz)
Tx-Power: 20 dBm Link Quality: unknown/70
Signal: unknown Noise: unknown
Bit Rate: unknown
Encryption: none
Type: nl80211 HW Mode(s): 802.11bgn
Hardware: unknown [Generic MAC80211]
TX power offset: unknown
Frequency offset: unknown
Supports VAPs: yes PHY name: phy0
As next step, i run: ifconfig client0 172.16.0.31 netmask 255.255.240.0 up
# ping 172.16.0.1
PING 172.16.0.1 (172.16.0.1): 56 data bytes
64 bytes from 172.16.0.1: seq=0 ttl=64 time=2.160 ms
64 bytes from 172.16.0.1: seq=1 ttl=64 time=2.740 ms
^C
--- 172.16.0.1 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 2.160/2.450/2.740 ms
# route add default gw 172.16.0.1 dev client0
# echo 'nameserver 8.8.8.8' > /etc/resolv.conf
# opkg update && opkg install iperf
HW:
GW) bcm63168 based router
PC) connected to gw as 172.16.0.111 on gigabit ethernet port
VoCore) connected to gw via WiFi (2.4 Ghz)
And run test on VoCore:
# iperf -c 172.16.0.111 -i 5 -t 999
Client connecting to 172.16.0.111, TCP port 5001
TCP window size: 43.8 KByte (default)
[ 3] local 172.16.0.31 port 32956 connected with 172.16.0.111 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 5.0 sec 12.0 MBytes 20.1 Mbits/sec
[ 3] 5.0-10.0 sec 11.6 MBytes 19.5 Mbits/sec
[ 3] 10.0-15.0 sec 11.5 MBytes 19.3 Mbits/sec
[ 3] 15.0-20.0 sec 11.4 MBytes 19.1 Mbits/sec
[ 3] 20.0-25.0 sec 11.5 MBytes 19.3 Mbits/sec
[ 3] 25.0-30.0 sec 11.6 MBytes 19.5 Mbits/sec
[ 3] 30.0-35.0 sec 11.5 MBytes 19.3 Mbits/sec
But sometimes i got this without *ANY* logs or warnings on
kernel/wpa_supplicant,
And in this moment ping also fails:
[ 3] 205.0-210.0 sec 3.12 MBytes 5.24 Mbits/sec
[ 3] 210.0-215.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 215.0-220.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 220.0-225.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 225.0-230.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 230.0-235.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 235.0-240.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 240.0-245.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 245.0-250.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 250.0-255.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 255.0-260.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 260.0-265.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 265.0-270.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 270.0-275.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 275.0-280.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 280.0-285.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 285.0-290.0 sec 0.00 Bytes 0.00 bits/sec
[ 3] 290.0-295.0 sec 7.00 MBytes 11.7 Mbits/sec
[
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images
Hi, I mean, not only ar71xx. Which version is going to be patched, as in BB, CC ? 2015-07-06 10:30 GMT+02:00 Roman Yeryomin : > On 5 July 2015 at 23:31, Matt . wrote: >> Hi, >> >> This needs to be patched on ALL versions! After this, we need to point >> the main devs of this package to it. >> >> Sounds like a plan ? >> > > What do you mean ALL versions? > This patch is easily backportable into CC if you mean that... > > Regards, > Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images
On 6 July 2015 at 12:40, Matt . wrote: > Hi, > > I mean, not only ar71xx. Looks like you don't understand what you are talking about - UAP-PRO exists only under ar71xx target. > Which version is going to be patched, as in BB, CC ? This patch is for trunk, it's up to core devs if they want it to be backported or not. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix UAP-PRO images
Ow I'm sorry, I'm replying to the wrong thread it seems! :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable
On 2015-07-02 13:47, Günther Kelleter wrote: > The ath10k firmware version is now a choice in the config menu. > Added options for older firmware versions (10.1 and 10.2). It seems that > recent firmware versions don't always run properly and this provides the > option to select an older (more stable) version instead. > > Signed-off-by: Günther Kelleter Instead of adding more options that most people don't know what to do with, please test the current v5 firmware in trunk and provide details about any issues that you find. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable
Hi Felix, On Mon, Jul 6, 2015 at 12:26 PM, Felix Fietkau wrote: > Instead of adding more options that most people don't know what to do > with, please test the current v5 firmware in trunk and provide details > about any issues that you find. I am not sure which issue Günther is trying to solve, but there ath10k firmware crashes for some users: [0] For me the crashes are reproducible even with the latest v5 firmware on a QCA9880-BR4A. However, older and newer ath10k firmware versions are working fine on a QCA9880-2R4E - so it seems that this crash is chip-specific. Regards, Martin [0] https://dev.openwrt.org/ticket/19167 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable
On 2015-07-06 12:36, Martin Blumenstingl wrote: > Hi Felix, > > On Mon, Jul 6, 2015 at 12:26 PM, Felix Fietkau wrote: >> Instead of adding more options that most people don't know what to do >> with, please test the current v5 firmware in trunk and provide details >> about any issues that you find. > I am not sure which issue Günther is trying to solve, but there ath10k > firmware crashes for some users: [0] > For me the crashes are reproducible even with the latest v5 firmware > on a QCA9880-BR4A. > However, older and newer ath10k firmware versions are working fine on > a QCA9880-2R4E - so it seems that this crash is chip-specific. What's the newest firmware that still works on your card? Also, please report these issues to the ath10k firmware maintainer. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by request_threaded_irq to fix non working ledtrig-gpio
On 2015-07-02 13:47, Günther Kelleter wrote: > Signed-off-by: Günther Kelleter What issue does this fix? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable
On Mon, Jul 6, 2015 at 12:39 PM, Felix Fietkau wrote: > What's the newest firmware that still works on your card? > Also, please report these issues to the ath10k firmware maintainer. I think the latest working version was the newest -2 (10.1 branch). I can look it up when I have access to the device again (probably this weekend). "Reporting to the ath10k firmware maintainer" is done by sending an email to the ath10k mailing list, or what is the preferred way? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable
On 2015-07-06 12:48, Martin Blumenstingl wrote: > On Mon, Jul 6, 2015 at 12:39 PM, Felix Fietkau wrote: >> What's the newest firmware that still works on your card? >> Also, please report these issues to the ath10k firmware maintainer. > I think the latest working version was the newest -2 (10.1 branch). I > can look it up when I have access to the device again (probably this > weekend). > "Reporting to the ath10k firmware maintainer" is done by sending an > email to the ath10k mailing list, or what is the preferred way? Yes, and Cc kv...@qca.qualcomm.com (Kalle Valo) - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable
Hi Felix > -Original Message- > From: Felix Fietkau [mailto:n...@openwrt.org] > Sent: Monday, July 06, 2015 12:27 PM > To: Guenther Kelleter; openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k > firmwares selectable > > On 2015-07-02 13:47, Günther Kelleter wrote: > > The ath10k firmware version is now a choice in the config menu. > > Added options for older firmware versions (10.1 and 10.2). It seems > > that recent firmware versions don't always run properly and this > > provides the option to select an older (more stable) version instead. > > > > Signed-off-by: Günther Kelleter > Instead of adding more options that most people don't know what to do with, > please test the current v5 firmware in trunk and provide details about any > issues that you find. > > - Felix The V2 firmware was the only one that didn't crash. We didn't try V5 so far because it was released after we made that patch. I'm going to check V5. Günther ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ar71xx: fix kernel Oops in at803x_link_change_notify
On Friday, July 03, 2015 12:29:32 PM Sven Eckelmann wrote:
> > Sven, I've seen you did quite a bit of work on the OM5P-AN
> > with the same F1E-PHY. I went through the code from Atheros'
> > original driver SDK v17 (which was part of the GPL source
> > for the mynet). Apart from tx delay handling, everything
> > else matches perfectly, so the tx/rx delay code should be
> > enabled by default for this chip on all platforms without
> > needing any platform data overwrites.
>
> Interesting, I don't have the SDK and I am only using OpenWrt. So I cannot say
> anything about the Atheros driver. But sounds like you are right. At least all
> recent devices I had in my hand required this change.
Oh, I figured you have access to some of Qualcomm Atheros' SDKs
and most importantly: some documentations from Qualcomm Atheros?
I hoped you could confirm or disconfirm based on the documents.
> I also saw your fixup_rgmii_tx_delay delay change. I would ack when you submit
> a change like this. Just don't forget that the pll_1000 has also to be changed
> (especially when you move the default values to at803x.c):
>
> --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-om5p.c
> +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-om5p.c
> @@ -154,7 +154,8 @@ static struct i2c_board_info om5pan_i2c_devs[] __initdata
> = {
> static struct at803x_platform_data om5p_an_at803x_data = {
> .disable_smarteee = 1,
> .enable_rgmii_rx_delay = 1,
> - .enable_rgmii_tx_delay = 1,
> + .enable_rgmii_tx_delay = 0,
> + .fixup_rgmii_tx_delay = 1,
> };
>
> static struct mdio_board_info om5p_an_mdio0_info[] = {
> @@ -201,7 +202,7 @@ static void __init om5p_an_setup(void)
> ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_RGMII;
> ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
> ath79_eth0_data.phy_mask = BIT(7);
> - ath79_eth0_pll_data.pll_1000 = 0x0200;
> + ath79_eth0_pll_data.pll_1000 = 0x0e00;
> ath79_eth0_pll_data.pll_100 = 0x0101;
> ath79_eth0_pll_data.pll_10 = 0x1313;
> ath79_register_eth(0);
>
>
> I don't have the equipment to check the actual signals (as you said in an
> earlier mail) - only some people which complained very loud when their long
> cable setup didn't work. :)
Long cable... That's a good point, I think I never tested the AT8035 with
anything beyond a 5m / 16 feet cable.
> Maybe there are some non atheros SoC's out there which would have problems
> when you would change the default behavior of the AT8035.
I've been looking around for devices with an AT8035. And I found a few gems.
...
(The AT8035 is also used in some of the new HomePlug AV2 equipment)
As far as I can tell, the defaults only seem to work for the 100mbps.
This makes sense, since the F1E has different PLLs and rx/tx delay
settings. Fixing this "globally" might actually be a good thing. At
least I'll give it a try.
> > I'm interested to hear from any other devices which have
> > a AT803x. Also, please let me know where to get the GPL
> > tars for the devices.
>
> I have forwarded your mail to the person which is handling the actual
> firmware builds of the OM5P-AN. He will contact you later and provide
> the sources.
Oh, that might be helpful yes. I can also post the sources from Western
Digital's S17_SSDK [The Ethernet driver SDK is part of their GPL.tar.gz].
Thanks,
Christian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by request_threaded_irq to fix non working ledtrig-gpio
> -Original Message- > From: Felix Fietkau [mailto:n...@openwrt.org] > Sent: Monday, July 06, 2015 12:43 PM > To: Guenther Kelleter; openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by > request_threaded_irq to fix non working ledtrig-gpio > > On 2015-07-02 13:47, Günther Kelleter wrote: > > Signed-off-by: Günther Kelleter > What issue does this fix? > > - Felix Without this change, gpio_trig_gpio_store() throws this error: [ 88.54] leds devolo:status:dlan: request_irq failed with error -22 [ 88.55] leds devolo:error:dlan: request_irq failed with error -22 Günther ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by request_threaded_irq to fix non working ledtrig-gpio
On 2015-07-06 14:14, Guenther Kelleter wrote: > >> -Original Message- >> From: Felix Fietkau [mailto:n...@openwrt.org] >> Sent: Monday, July 06, 2015 12:43 PM >> To: Guenther Kelleter; openwrt-devel@lists.openwrt.org >> Subject: Re: [OpenWrt-Devel] [PATCH v2 6/8] generic: replace request_irq by >> request_threaded_irq to fix non working ledtrig-gpio >> >> On 2015-07-02 13:47, Günther Kelleter wrote: >> > Signed-off-by: Günther Kelleter >> What issue does this fix? >> >> - Felix > > Without this change, gpio_trig_gpio_store() throws this error: > [ 88.54] leds devolo:status:dlan: request_irq failed with error -22 > [ 88.55] leds devolo:error:dlan: request_irq failed with error -22 If you rework the GPIO IRQ handler code to not require threading, you probably won't have to change this generic code. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: rework patch for qca953x/956x
On 07/04/2015 10:32 PM, Christian Mehlis wrote: > Am 02.07.2015 um 23:10 schrieb Matthias Schiffer: >> I've fixed it >> up using the following snippet, the Compex WPJ531 will probably need the >> same fix (it uses pretty much the same initialization code). > > Thanks Matthias, > > When submitting the fix for the WR841Nv9 please also include the fix for > the wpj531. > > I'll test and verify! > > Best > Christian Hi, could you send me the output of `swconfig dev eth1 show` (or eth0?) on OpenWrt? The current initialization code looks a bit weird as it's the same one would use for a device with 4 LAN ports, even though the WPJ531 has only one. Matthias signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable
> -Original Message- > From: Martin Blumenstingl [mailto:martin.blumensti...@googlemail.com] > Sent: Monday, July 06, 2015 12:36 PM > To: Felix Fietkau > Cc: Guenther Kelleter; openwrt-devel@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k > firmwares selectable > > Hi Felix, > > On Mon, Jul 6, 2015 at 12:26 PM, Felix Fietkau wrote: > > Instead of adding more options that most people don't know what to do > > with, please test the current v5 firmware in trunk and provide details > > about any issues that you find. > I am not sure which issue Günther is trying to solve, but there ath10k > firmware crashes for some users: [0] For me the crashes are reproducible even > with the latest v5 firmware on a QCA9880-BR4A. > However, older and newer ath10k firmware versions are working fine on a > QCA9880-2R4E - so it seems that this crash is chip-specific. > > Regards, > Martin > > > [0] https://dev.openwrt.org/ticket/19167 I've tried v5 firmware patch from mailing list. This is the result. 4 fw crashes during boot time: [ 13.18] cfg80211: Calling CRDA to update world regulatory domain [ 13.21] cfg80211: World regulatory domain updated: [ 13.21] cfg80211: DFS Master region: unset [ 13.22] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 13.23] cfg80211: (2402000 KHz - 2472000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 13.23] cfg80211: (2457000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 13.24] cfg80211: (2474000 KHz - 2494000 KHz @ 2 KHz), (N/A, 2000 mBm), (N/A) [ 13.25] cfg80211: (517 KHz - 525 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 13.26] cfg80211: (525 KHz - 533 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 13.27] cfg80211: (549 KHz - 573 KHz @ 16 KHz), (N/A, 2000 mBm), (0 s) [ 13.28] cfg80211: (5735000 KHz - 5835000 KHz @ 8 KHz), (N/A, 2000 mBm), (N/A) [ 13.28] cfg80211: (5724 KHz - 6372 KHz @ 216 KHz), (N/A, 0 mBm), (N/A) [ 13.39] PCI: Enabling device :00:00.0 ( -> 0002) [ 13.40] ath10k_pci :00:00.0: pci irq legacy interrupts 0 irq_mode 0 reset_mode 0 [ 13.62] ath10k_pci :00:00.0: Direct firmware load for ath10k/cal-pci-:00:00.0.bin failed with error -2 [ 13.63] ath10k_pci :00:00.0: Falling back to user helper [ 15.43] ath10k_pci :00:00.0: qca988x hw2.0 (0x4100016c, 0x043222ff) fw 10.2.4.70-2 api 5 htt 2.1 wmi 5 cal file max_sta 128 [ 15.44] ath10k_pci :00:00.0: debug 0 debugfs 1 tracing 0 dfs 1 testmode 1 [ 15.56] cfg80211: Calling CRDA for country: AW [ 15.56] cfg80211: Regulatory domain changed to country: AW [ 15.57] cfg80211: DFS Master region: ETSI [ 15.57] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 15.58] cfg80211: (2402000 KHz - 2482000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 15.59] cfg80211: (517 KHz - 525 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 15.60] cfg80211: (525 KHz - 533 KHz @ 8 KHz, 16 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 15.61] cfg80211: (549 KHz - 571 KHz @ 16 KHz), (N/A, 2700 mBm), (0 s) [ 15.69] Ebtables v2.0 registered [ 15.70] ip_tables: (C) 2000-2006 Netfilter Core Team [ 15.73] nf_conntrack version 0.5.0 (1971 buckets, 7884 max) [ 15.87] xt_time: kernel timezone is - [ 15.92] PPP generic driver version 2.4.2 [ 15.94] NET: Registered protocol family 24 [ 15.99] ieee80211 phy1: Atheros AR9340 Rev:3 mem=0xb810, irq=47 [ 29.33] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0 [ 29.36] jffs2_build_filesystem(): unlocking the mtd device... done. [ 29.36] jffs2_build_filesystem(): erasing all blocks after the end marker... [ 35.14] device eth0 entered promiscuous mode [ 35.18] IPv6: ADDRCONF(NETDEV_UP): br-lan: link is not ready [ 37.29] eth0: link up (1000Mbps/Full duplex) [ 37.36] br-lan: port 1(eth0) entered forwarding state [ 37.36] br-lan: port 1(eth0) entered forwarding state [ 37.37] IPv6: ADDRCONF(NETDEV_CHANGE): br-lan: link becomes ready [ 37.46] cfg80211: Calling CRDA for country: DE [ 37.47] cfg80211: Regulatory domain changed to country: DE [ 37.47] cfg80211: DFS Master region: ETSI [ 37.48] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp), (dfs_cac_time) [ 37.49] cfg80211: (240 KHz - 2483000 KHz @ 4 KHz), (N/A, 2000 mBm), (N/A) [ 37.49] cfg80211: (515 KHz - 525 KHz @ 8 KHz, 20 KHz AUTO), (N/A, 2000 mBm), (N/A) [ 37.50] cfg80211: (525 KHz - 535 KHz @ 8 KHz, 20 KHz AUTO), (N/A, 2000 mBm), (0 s) [ 37.51] cfg80211: (5470
Re: [OpenWrt-Devel] [PATCH] ar71xx: add LED defaults for the EnGenius EPG5000
Am Mon, 22 Jun 2015 13:28:14 +0200 schrieb Christian Beier : > NB that wlan5g is phy0tpt and wlan2g phy1tpt. Hey, just wanted to know whether I need to change anything or this just takes time to get applied? Cheers, Christian > > Signed-off-by: Christian Beier > --- > target/linux/ar71xx/base-files/etc/uci-defaults/01_leds | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds > b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds index > 19814f4..7c10f42 100644 --- > a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds +++ > b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds @@ -165,6 +165,11 > @@ esr1750) ucidef_set_led_wlan "wlan5g" "WLAN 5 GHz" "esr1750:blue:wlan-5g" > "phy1tpt" ;; > > +epg5000) > + ucidef_set_led_wlan "wlan2g" "WLAN 2.4 GHz" "epg5000:blue:wlan-2g" > "phy1tpt" > + ucidef_set_led_wlan "wlan5g" "WLAN 5 GHz" "epg5000:blue:wlan-5g" > "phy0tpt" > + ;; > + > hiwifi-hc6361) > ucidef_set_led_netdev "inet" "INET" "hiwifi:blue:internet" "eth1" > ucidef_set_led_wlan "wlan" "WLAN" "hiwifi:blue:wlan-2p4" "phy0tpt" ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2 5/8] mac80211: make more ath10k firmwares selectable
On 2015-07-06 16:05, Guenther Kelleter wrote: > Instead of the original patch, would you accept an option to only > choose between STA mode, AP mode w/ latest API fw (default) and AP mode > with fallback API2 fw (new) for those people who experience crashes with > latest fw? At least until these issues are finally fixed? I already removed the STA fw because it has been obsolete for a long time. I will accept a patch that adds v2 firmware as a fallback until the current one is fixed. Maybe it would also be worth testing the Ben Greear's firmware (the candelatech one) to see if that's a suitable replacement for the old v2 stuff. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ar71xx: rework patch for qca953x/956x
Am 06.07.2015 um 15:59 schrieb Matthias Schiffer: could you send me the output of `swconfig dev eth1 show` (or eth0?) on OpenWrt? The current initialization code looks a bit weird as it's the same one would use for a device with 4 LAN ports, even though the WPJ531 has only one. root@OpenWrt:/# swconfig dev eth0 show Failed to connect to the switch. Use the "list" command to see which switches are available. root@OpenWrt:/# swconfig dev eth1 show Global attributes: enable_vlan: 0 Port 0: pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: pvid: 0 link: port:1 link:down Port 2: pvid: 0 link: port:2 link:down Port 3: pvid: 0 link: port:3 link:up speed:100baseT full-duplex auto Port 4: pvid: 0 link: port:4 link:down VLAN 0: vid: 0 ports: 0 1 2 3 4 root@OpenWrt:/# ethtool eth0 Settings for eth0: Supported ports: [ TP MII ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause frame use: No Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised pause frame use: No Advertised auto-negotiation: Yes Link partner advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full Link partner advertised pause frame use: Symmetric Link partner advertised auto-negotiation: Yes Speed: 100Mb/s Duplex: Full Port: MII PHYAD: 4 Transceiver: external Auto-negotiation: on Current message level: 0x00ff (255) drv probe link timer ifdown ifup rx_err tx_err Link detected: no root@OpenWrt:/# ethtool eth1 Settings for eth1: Cannot get device settings: No such device Current message level: 0x00ff (255) drv probe link timer ifdown ifup rx_err tx_err Link detected: yes ### Both ports are working, but I just took the vendor source code... In case you have any suggestion to make the initialization more "correct" drop me a mail, I will test your it! Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] dnsmasq: enable extra tracing by default when UCI parameter logqueries is set
Signed-off-by: Hans Dedecker
---
package/network/services/dnsmasq/files/dnsmasq.init | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index b0a5fbc..bbe2b56 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -121,7 +121,7 @@ dnsmasq() {
append_bool "$cfg" nohosts "--no-hosts"
append_bool "$cfg" nonegcache "--no-negcache"
append_bool "$cfg" strictorder "--strict-order"
- append_bool "$cfg" logqueries "--log-queries"
+ append_bool "$cfg" logqueries "--log-queries=extra"
append_bool "$cfg" noresolv "--no-resolv"
append_bool "$cfg" localise_queries "--localise-queries"
append_bool "$cfg" readethers "--read-ethers"
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] dnsmasq: Add sequential_ip UCI parameter
When enabled the dnsmasq DHCP server allocates the IP addresses sequentially
starting from the lowest available IP address.
Signed-off-by: Hans Dedecker
---
package/network/services/dnsmasq/files/dnsmasq.init | 1 +
1 file changed, 1 insertion(+)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index bbe2b56..5844aaf 100644
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -135,6 +135,7 @@ dnsmasq() {
append_bool "$cfg" proxydnssec "--proxy-dnssec"
append_bool "$cfg" localservice "--local-service"
append_bool "$cfg" quietdhcp "--quiet-dhcp"
+ append_bool "$cfg" sequential_ip "--dhcp-sequential-ip"
append_parm "$cfg" dhcpscript "--dhcp-script"
append_parm "$cfg" cachesize "--cache-size"
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] watchping
Hi Juliusz and all, Exporting a route to a routing protocol was just one example of what could be done based on the fact that internet connectivity is available on an interface. There are other uses one could imagine: - Activate a backup interface, say a 3G connection - Announce a default GW or not (routing proto or DHCP). - Check for firmware upgrades on a public server - Start or reconfigure a service Second, a default route is not enough: what counts is wether inernet connectivity is available thru that route. Sometimes a router announces a default route but is not connected itself, or problems exist "upstream". In that sense it's probably like your "babel-pinger" but more generic. The mwan3 package seems do do a similar thing in a script. Do you think it could profit from a C-based ubus service? Would it make sense? bruno On 07/03/2015 09:19 PM, Juliusz Chroboczek wrote: > Hi Bruno, > >> Sometimes it's necessary to re-configure an OpenWRT system based on the >> fact wether Internet connectivity is available on a certain interface. > [...] >> One example where this is useful is: When Internet is available, we >> configure BATMAN to act as a gateway 'server', if not as a gateway >> 'client'. > > I think that a solution that relies on distribution scripts is inherently > brittle. The routing daemon should be able to detect the current > configuration, in a distribution-independent manner, and automatically > adapt to the current situation. This is what happens with babeld -- it is > able to automatically redistribute a kernel route (typically the default > route, but not necessarily) into the routing protocol. > > I know of three ways of automatically obtaining a default route, in > descending order of preference: > > - if the other end of the Internet connection speaks RIP, RIPng or OSPF, > we run Quagga on the gateway and redistribute into Babel; > > - if DHCPv4 is reliable (it usually is), then we simply redistribute the > DHCP-provided route into the routing protocol; > > - if DHCPv4 is unreliable, we use the "babel-pinger" utility which > pings a remote host and installs a route depending on its availability. > > Additionally, there is some very promising but still experimental work to > provide a fully general and highly integrated solution in the "hnetd-full" > package. > > -- Juliusz > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] mac80211: update regulatory database to master-2015-06-05
Signed-off-by: Petko Bordjukov --- package/kernel/mac80211/files/regdb.txt | 126 1 file changed, 81 insertions(+), 45 deletions(-) diff --git a/package/kernel/mac80211/files/regdb.txt b/package/kernel/mac80211/files/regdb.txt index ba95fc6..84413fd 100644 --- a/package/kernel/mac80211/files/regdb.txt +++ b/package/kernel/mac80211/files/regdb.txt @@ -6,7 +6,7 @@ country 00: # Channel 14. Only JP enables this and for 802.11b only (2474 - 2494 @ 20), (20), NO-IR, NO-OFDM # Channel 36 - 48 - (5170 - 5250 @ 80), (20) + (5170 - 5250 @ 80), (20), AUTO-BW # Channel 52 - 64 (5250 - 5330 @ 80), (20), NO-IR, DFS, AUTO-BW # Channel 100 - 144 @@ -54,8 +54,8 @@ country AL: DFS-ETSI country AM: DFS-ETSI (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (18) - (5250 - 5330 @ 80), (18), DFS + (5170 - 5250 @ 20), (18) + (5250 - 5330 @ 20), (18), DFS country AN: DFS-ETSI (2402 - 2482 @ 40), (20) @@ -85,7 +85,7 @@ country AT: DFS-ETSI # 60 gHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) -country AU: +country AU: DFS-ETSI (2402 - 2482 @ 40), (20) (5170 - 5250 @ 80), (17), AUTO-BW (5250 - 5330 @ 80), (24), DFS, AUTO-BW @@ -141,14 +141,20 @@ country BG: DFS-ETSI (5170 - 5250 @ 80), (20), AUTO-BW (5250 - 5330 @ 80), (20), DFS, AUTO-BW (5490 - 5710 @ 160), (27), DFS + # 5 gHz Short Range Devices, ref: + # Etsi EN 300 440-1 + # Etsi EN 300 440-2 + # http://crc.bg/files/_bg/Spisak_2015.pdf + # http://crc.bg/files/_bg/Pravila_2015_resh24.pdf + (5725 - 5875 @ 80), (14) # 60 gHz band channels 1-4, ref: Etsi En 302 567 (57000 - 66000 @ 2160), (40) country BH: DFS-JP (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20) - (5250 - 5330 @ 80), (20), DFS - (5735 - 5835 @ 80), (20) + (5170 - 5250 @ 20), (20) + (5250 - 5330 @ 20), (20), DFS + (5735 - 5835 @ 20), (20) country BL: DFS-ETSI (2402 - 2482 @ 40), (20) @@ -263,10 +269,10 @@ country CO: DFS-FCC country CR: DFS-FCC (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (17) - (5250 - 5330 @ 80), (24), DFS - (5490 - 5730 @ 80), (24), DFS - (5735 - 5835 @ 80), (30) + (5170 - 5250 @ 20), (17) + (5250 - 5330 @ 20), (24), DFS + (5490 - 5730 @ 20), (24), DFS + (5735 - 5835 @ 20), (30) country CX: DFS-FCC (2402 - 2482 @ 40), (20) @@ -349,10 +355,10 @@ country DZ: DFS-JP country EC: DFS-FCC (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (17) - (5250 - 5330 @ 80), (24), DFS - (5490 - 5730 @ 80), (24), DFS - (5735 - 5835 @ 80), (30) + (5170 - 5250 @ 20), (17) + (5250 - 5330 @ 20), (24), DFS + (5490 - 5730 @ 20), (24), DFS + (5735 - 5835 @ 20), (30) country EE: DFS-ETSI (2402 - 2482 @ 40), (20) @@ -364,8 +370,8 @@ country EE: DFS-ETSI country EG: DFS-ETSI (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20) - (5250 - 5330 @ 80), (20), DFS + (5170 - 5250 @ 40), (20) + (5250 - 5330 @ 40), (20), DFS # Orden IET/787/2013, de 25 de abril, por la que se aprueba # el cuadro nacional de atribución de frecuencias. @@ -474,10 +480,10 @@ country GT: DFS-FCC country GU: DFS-FCC (2402 - 2472 @ 40), (30) - (5170 - 5250 @ 80), (17) - (5250 - 5330 @ 80), (24), DFS - (5490 - 5730 @ 80), (24), DFS - (5735 - 5835 @ 80), (30) + (5170 - 5250 @ 20), (17) + (5250 - 5330 @ 20), (24), DFS + (5490 - 5730 @ 20), (24), DFS + (5735 - 5835 @ 20), (30) country GY: (2402 - 2482 @ 40), (30) @@ -522,8 +528,8 @@ country HU: DFS-ETSI country ID: DFS-JP # ref: http://www.postel.go.id/content/ID/regulasi/standardisasi/kepdir/bwa%205,8%20ghz.pdf - (2402 - 2482 @ 40), (20) - (5735 - 5815 @ 80), (23) + (2402 - 2482 @ 20), (20) + (5735 - 5815 @ 20), (23) country IE: DFS-ETSI (2402 - 2482 @ 40), (20) @@ -584,6 +590,9 @@ country JP: DFS-JP (5170 - 5250 @ 80), (20), AUTO-BW (5250 - 5330 @ 80), (20), DFS, AUTO-BW (5490 - 5710 @ 160), (23), DFS + # 60 GHz band channels 2-4 at 10mW, + # ref: http://www.arib.or.jp/english/html/overview/doc/1-STD-T74v1_1.pdf + (59000 - 66000 @ 2160), (10 mW) country KE: DFS-JP (2402 - 2482 @ 40), (20) @@ -607,11 +616,11 @@ country KN: DFS-ETSI (5735 - 5815 @ 80), (30) country KP: DFS-JP - (2402 - 2482 @ 40), (20) - (5170 - 5250 @ 80), (20), AUTO-BW - (5250 - 5330 @ 80), (20), DFS, AUTO-BW - (5490 - 5630 @ 80), (30), DFS - (5735 - 5815 @ 80), (30) + (2402 - 2482 @ 20), (20) + (5170 - 5250 @ 20), (20) + (5250 - 5330 @ 20), (20), DFS + (5490 - 5630 @ 20), (30), DFS + (5735 - 58
[OpenWrt-Devel] [PATCH] ramips mt7620: ArcherC20i USB support and more
Hi,
Trunk and CC image for ArcherC20i do not support USB/leds/buttons.
This patch is for an updated/improved .dts-file.
See also: https://forum.openwrt.org/viewtopic.php?pid=281794#p281794
Signed-off-by: Gunnar Thorburn
$ diff -up target/linux/ramips/dts/ArcherC20i.dts{.orig,}
--- target/linux/ramips/dts/ArcherC20i.dts.orig 2015-07-05
15:27:04.763421748 +0200
+++ target/linux/ramips/dts/ArcherC20i.dts 2015-07-05 15:53:24.738509389
+0200
@@ -3,109 +3,139 @@
/include/ "mt7620a.dtsi"
/ {
- compatible = "ralink,mt7620a-soc";
- model = "TP-Link Archer C20i";
+compatible = "ralink,mt7620a-soc";
+model = "TP-Link Archer C20i";
- chosen {
- bootargs = "console=ttyS0,115200";
- };
-
- palmbus@1000 {
- gpio2: gpio@660 {
- status = "okay";
- };
-
- spi@b00 {
- status = "okay";
-
- m25p80@0 {
- #address-cells = <1>;
- #size-cells = <1>;
- compatible = "en25q64";
- reg = <0 0>;
- linux,modalias = "m25p80", "mx25l6405d";
- spi-max-frequency = <1000>;
-
- partition@0 {
- label = "u-boot";
- reg = <0x0 0x2>;
- read-only;
- };
-
- partition@2 {
- label = "firmware";
- reg = <0x2 0x7a>;
- };
-
- partition@7c {
- label = "config";
- reg = <0x7c 0x1>;
- };
-
- rom: partition@7d {
- label = "rom";
- reg = <0x7d 0x1>;
- };
-
- partition@7e {
- label = "romfile";
- reg = <0x7e 0x1>;
- };
-
- radio: partition@7f {
- label = "radio";
- reg = <0x7f 0x1>;
- };
- };
- };
- };
-
- pinctrl {
- state_default: pinctrl0 {
- gpio {
- ralink,group = "i2c", "uartf", "rgmii1", "rgmii2",
"wled", "nd_sd";
- ralink,function = "gpio";
- };
- };
- };
-
- ethernet@1010 {
- pinctrl-names = "default";
- pinctrl-0 = <&ephy_pins>;
-
- mtd-mac-address = <&rom 0xf100>;
- ralink,port-map = "w";
- };
-
- gsw@1011 {
- ralink,port4 = "ephy";
- };
-
- wmac@1018 {
- ralink,mtd-eeprom = <&radio 0>;
- };
-
- pcie@1014 {
- status = "okay";
-
- pcie-bridge {
- mt76@0,0 {
- reg = <0x 0 0 0 0>;
- device_type = "pci";
- mediatek,mtd-eeprom = <&radio 32768>;
- mediatek,2ghz = <0>;
- };
- };
- };
-
- gpio-leds {
- compatible = "gpio-leds";
- };
-
- gpio-keys-polled {
- compatible = "gpio-keys-polled";
- #address-cells = <1>;
- #size-cells = <0>;
- poll-interval = <20>;
- };
+chosen {
+bootargs = "console=ttyS0,115200";
+};
+
+palmbus@1000 {
+gpio2: gpio@660 {
+status = "okay";
+};
+
+gpio3: gpio@688 {
+status = "okay";
+};
+
+spi@b00 {
+status = "okay";
+
+m25p80@0 {
+#address-cells = <1>;
+#size-cells = <1>;
+compatible = "en25q64";
+reg = <0 0>;
+linux,modalias = "m25p80", "mx25l6405d";
+spi-max-frequency = <1000>;
+
+partition@0 {
+label = "u-boot";
+reg = <0x0 0x2>;
+read-only;
+};
+
+partition@2 {
+label = "firmware";
+reg = <0x2 0x7a>;
+};
+
+partition
Re: [OpenWrt-Devel] watchping
Hello Bruno, yet another tool used in Ninux.org: https://github.com/ninuxorg/misc_tools/tree/master/adsl_check What you want to implement is a generic tool... that checks a network condition and if this condition happens triggers an event. Yes it would be a nice tool. However routing protocols implementations have to provide some kind of API to make possible for the tool to make some actions once a condition is met. Saverio 2015-07-06 20:54 GMT+02:00 Bruno Randolf : > Hi Juliusz and all, > > Exporting a route to a routing protocol was just one example of what > could be done based on the fact that internet connectivity is available > on an interface. There are other uses one could imagine: > - Activate a backup interface, say a 3G connection > - Announce a default GW or not (routing proto or DHCP). > - Check for firmware upgrades on a public server > - Start or reconfigure a service > > Second, a default route is not enough: what counts is wether inernet > connectivity is available thru that route. Sometimes a router announces > a default route but is not connected itself, or problems exist > "upstream". In that sense it's probably like your "babel-pinger" but > more generic. > > The mwan3 package seems do do a similar thing in a script. Do you think > it could profit from a C-based ubus service? Would it make sense? > > bruno > > > > On 07/03/2015 09:19 PM, Juliusz Chroboczek wrote: >> Hi Bruno, >> >>> Sometimes it's necessary to re-configure an OpenWRT system based on the >>> fact wether Internet connectivity is available on a certain interface. >> [...] >>> One example where this is useful is: When Internet is available, we >>> configure BATMAN to act as a gateway 'server', if not as a gateway >>> 'client'. >> >> I think that a solution that relies on distribution scripts is inherently >> brittle. The routing daemon should be able to detect the current >> configuration, in a distribution-independent manner, and automatically >> adapt to the current situation. This is what happens with babeld -- it is >> able to automatically redistribute a kernel route (typically the default >> route, but not necessarily) into the routing protocol. >> >> I know of three ways of automatically obtaining a default route, in >> descending order of preference: >> >> - if the other end of the Internet connection speaks RIP, RIPng or OSPF, >> we run Quagga on the gateway and redistribute into Babel; >> >> - if DHCPv4 is reliable (it usually is), then we simply redistribute the >> DHCP-provided route into the routing protocol; >> >> - if DHCPv4 is unreliable, we use the "babel-pinger" utility which >> pings a remote host and installs a route depending on its availability. >> >> Additionally, there is some very promising but still experimental work to >> provide a fully general and highly integrated solution in the "hnetd-full" >> package. >> >> -- Juliusz >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel >> > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips mt7620: ArcherC20i USB support and more
Hi,
On Mon, Jul 6, 2015 at 10:36 PM, Gunnar Thorburn wrote:
> Hi,
>
> Trunk and CC image for ArcherC20i do not support USB/leds/buttons.
> This patch is for an updated/improved .dts-file.
Please describe what you changed (added/removed/changed nodes/properties).
> See also: https://forum.openwrt.org/viewtopic.php?pid=281794#p281794
>
> Signed-off-by: Gunnar Thorburn
>
> $ diff -up target/linux/ramips/dts/ArcherC20i.dts{.orig,}
> --- target/linux/ramips/dts/ArcherC20i.dts.orig 2015-07-05
> 15:27:04.763421748 +0200
> +++ target/linux/ramips/dts/ArcherC20i.dts 2015-07-05
> 15:53:24.738509389 +0200
> @@ -3,109 +3,139 @@
> /include/ "mt7620a.dtsi"
>
> / {
> - compatible = "ralink,mt7620a-soc";
> - model = "TP-Link Archer C20i";
> +compatible = "ralink,mt7620a-soc";
> +model = "TP-Link Archer C20i";
Why did you replace all tabs with spaces? This makes the patch hard to
review. Please fix and resend.
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Deal with allocation errors in a few missing places.
On 2015-06-26 00:20, Juliusz Chroboczek wrote: > Since libubox is used by procd, it should deal gracefully with allocation > failures. > --- > blobmsg_json.c | 2 ++ > json_script.c | 3 +++ > kvlist.c | 4 > ustream.c | 16 +--- > utils.c| 3 +++ > 5 files changed, 25 insertions(+), 3 deletions(-) > > diff --git a/blobmsg_json.c b/blobmsg_json.c > index ffde23d..1f2b4bc 100644 > --- a/blobmsg_json.c > +++ b/blobmsg_json.c > @@ -297,6 +297,8 @@ char *blobmsg_format_json_with_cb(struct blob_attr *attr, > bool list, blobmsg_jso > > s.len = blob_len(attr); > s.buf = malloc(s.len); > +if (!s.buf) > +return NULL; Please use tab instead of spaces for indenting. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Deal gracefully with allocation failures in a few omitted places.
On 2015-06-26 00:21, Juliusz Chroboczek wrote: > --- > libubus.c | 3 +++ > ubusd_acl.c | 2 ++ > 2 files changed, 5 insertions(+) > > diff --git a/libubus.c b/libubus.c > index ccaa069..9aae613 100644 > --- a/libubus.c > +++ b/libubus.c > @@ -77,6 +77,9 @@ ubus_queue_msg(struct ubus_context *ctx, struct > ubus_msghdr_buf *buf) > void *data; > > pending = calloc_a(sizeof(*pending), &data, blob_raw_len(buf->data)); > +if (!pending) > + /* XXX */ > + return; Please use tab instead of space for indenting. Also, why XXX here? - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] Provide meaningful error messages when fork fails.
On 2015-06-26 00:23, Juliusz Chroboczek wrote:
> ---
> inittab.c | 6 +++---
> rcS.c | 4 +++-
> 2 files changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/inittab.c b/inittab.c
> index eb402f8..2767e17 100644
> --- a/inittab.c
> +++ b/inittab.c
> @@ -116,13 +116,13 @@ static void fork_worker(struct init_action *a)
> execvp(a->argv[0], a->argv);
> ERROR("Failed to execute %s\n", a->argv[0]);
> exit(-1);
> - }
> -
> - if (a->proc.pid > 0) {
> + } if (a->proc.pid > 0) {
Why change the indentation here?
- Felix
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH V3] service: if logging start app with LD_PRELOAD & lib for line buffering
Using pipe automatically switches service to block buffering which kind
of breaks our logging. We won't get anything from stdout FD until the
buffer gets filled fully or the service exits. This makes log messages
appear with an unwanted delay.
This change adds a tiny libsetlbf.so switching stdout to line buffering
and uses this lib for every logging-enabled service started by procd.
We don't need any extra change for stderr as it's unbuffered by default.
Signed-off-by: Rafał Miłecki
---
V2: Use strncat for safety
Use line buffering instead of no buffering
V3: Use asprintf & putenv as suggested byu cyrus
---
CMakeLists.txt | 7 +++
service/instance.c | 19 ++-
service/setlbf.c | 6 ++
3 files changed, 31 insertions(+), 1 deletion(-)
create mode 100644 service/setlbf.c
diff --git a/CMakeLists.txt b/CMakeLists.txt
index dfa9413..6af17a3 100644
--- a/CMakeLists.txt
+++ b/CMakeLists.txt
@@ -10,6 +10,13 @@ IF(APPLE)
LINK_DIRECTORIES(/opt/local/lib)
ENDIF()
+
+ADD_LIBRARY(setlbf SHARED service/setlbf.c)
+INSTALL(TARGETS setlbf
+ LIBRARY DESTINATION lib
+)
+
+
SET(SOURCES procd.c signal.c watchdog.c state.cinittab.c rcS.c ubus.c
system.c
service/service.c service/instance.c service/validate.c
service/trigger.c service/watch.c
plug/coldplug.c plug/hotplug.c utils/utils.c)
diff --git a/service/instance.c b/service/instance.c
index 35b2def..0bd0bed 100644
--- a/service/instance.c
+++ b/service/instance.c
@@ -12,6 +12,7 @@
* GNU General Public License for more details.
*/
+#define _GNU_SOURCE
#include
#include
#include
@@ -19,6 +20,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -224,6 +226,9 @@ instance_run(struct service_instance *in, int _stdout, int
_stderr)
struct blobmsg_list_node *var;
struct blob_attr *cur;
char **argv;
+ char *ld_preload;
+ bool ld_preload_seccomp = false;
+ bool ld_preload_setlbf = false;
int argc = 1; /* NULL terminated */
int rem, _stdin;
@@ -238,7 +243,19 @@ instance_run(struct service_instance *in, int _stdout, int
_stderr)
if (!in->trace && !in->has_jail && in->seccomp) {
setenv("SECCOMP_FILE", in->seccomp, 1);
- setenv("LD_PRELOAD", "/lib/libpreload-seccomp.so", 1);
+ ld_preload_seccomp = true;
+ }
+ if (_stdout >= 0) {
+ ld_preload_setlbf = true;
+ }
+
+ if (ld_preload_seccomp || ld_preload_setlbf) {
+ int bytes = asprintf(&ld_preload, "LD_PRELOAD=%s%s%s",
+ld_preload_seccomp ?
"/lib/libpreload-seccomp.so" : "",
+ld_preload_seccomp && ld_preload_setlbf ?
":" : "",
+ld_preload_setlbf ? "/lib/libsetlbf.so" :
"");
+ if (bytes)
+ putenv(ld_preload);
}
blobmsg_list_for_each(&in->limits, var)
diff --git a/service/setlbf.c b/service/setlbf.c
new file mode 100644
index 000..df00366
--- /dev/null
+++ b/service/setlbf.c
@@ -0,0 +1,6 @@
+#include
+
+static void __attribute__((constructor)) setlbf(void)
+{
+ setlinebuf(stdout);
+}
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips mt7620: ArcherC20i USB support and more
Hi,
The patch (actually the entire file) was contributed on the OpenWrt
forum:
https://forum.openwrt.org/viewtopic.php?pid=281794#p281794
My contribution is that I have tested it and that I am trying to submit
it here.
I can confirm that:
1) My ArcherC20i works fine with the patch applied
2) USB works (which it does not do in CC without the patch)
If the changes not related to USB (ehci/ohci) are questionable, I would
be happy to resubmit a patch for just USB. I am sorry about the spaces
and tabs. The clean patch below looks much nicer.
Gunnar T.
$ diff -up target/linux/ramips/dts/ArcherC20i.dts{.orig,}
--- target/linux/ramips/dts/ArcherC20i.dts.orig 2015-07-05
15:27:04.763421748 +0200
+++ target/linux/ramips/dts/ArcherC20i.dts 2015-07-06 23:11:04.533094775
+0200
@@ -15,6 +15,10 @@
status = "okay";
};
+ gpio3: gpio@688 {
+ status = "okay";
+ };
+
spi@b00 {
status = "okay";
@@ -77,8 +81,12 @@
ralink,port-map = "w";
};
- gsw@1011 {
- ralink,port4 = "ephy";
+ ehci@101c {
+ status = "okay";
+ };
+
+ ohci@101c1000 {
+ status = "okay";
};
wmac@1018 {
@@ -100,6 +108,18 @@
gpio-leds {
compatible = "gpio-leds";
+ lan {
+ label = "tp-link:blue:lan";
+ gpios = <&gpio0 1 1>;
+ };
+ usb {
+ label = "tp-link:blue:usb";
+ gpios = <&gpio0 11 1>;
+ };
+ wlan {
+ label = "tp-link:blue:wlan";
+ gpios = <&gpio3 0 1>;
+ };
};
gpio-keys-polled {
@@ -107,5 +127,15 @@
#address-cells = <1>;
#size-cells = <0>;
poll-interval = <20>;
+ reset_wps {
+ label = "reset_wps";
+ gpios = <&gpio0 13 1>;
+ linux,code = <0x198>;
+ };
+ rfkill {
+ label = "rfkill";
+ gpios = <&gpio0 2 1>;
+ linux,code = <0xf7>;
+ };
};
};
06.07.2015 22:54 skrev Jonas Gorski:
Hi,
Why did you replace all tabs with spaces? This makes the patch hard to
review. Please fix and resend.
Jonas
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] mvsw61xx: use unique forwarding database per VLAN
Previously, all VLANs (port-based or 802.1q) were sharing
a single database in the ATU. This created problems in the
case of a system where two ports/devices share a MAC address
(e.g. Linksys WRT1900AC eth0/eth1).
This also clears any bootloader-set FDB defaults. This had
caused issues creating port-based VLANs when mappings
overlapped previous VLANs. Packets destined to a port
not in the default port group flooded all ports.
Tested on a 88E6171 (Linksys EA4500) and 88E6172 ('1900AC)
Signed-off-by: Claudio Leite
---
The indentation looks broken (around HI/LO_SHIFT) but it's a
consequence of the diff '+' AFAICT.
target/linux/generic/files/drivers/net/phy/mvsw61xx.c | 17 +
target/linux/generic/files/drivers/net/phy/mvsw61xx.h | 6 ++
2 files changed, 19 insertions(+), 4 deletions(-)
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
b/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
index 116f6cf..9417fd4 100644
--- a/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
+++ b/target/linux/generic/files/drivers/net/phy/mvsw61xx.c
@@ -493,7 +493,7 @@ static int mvsw61xx_vtu_program(struct switch_dev *dev)
sw16(dev, MV_GLOBALREG(VTU_VID),
MV_VTU_VID_VALID | state->vlans[i].vid);
sw16(dev, MV_GLOBALREG(VTU_SID), i);
- sw16(dev, MV_GLOBALREG(VTU_FID), 0);
+ sw16(dev, MV_GLOBALREG(VTU_FID), i);
sw16(dev, MV_GLOBALREG(VTU_DATA1), v1);
sw16(dev, MV_GLOBALREG(VTU_DATA2), v2);
sw16(dev, MV_GLOBALREG(VTU_DATA3), 0);
@@ -521,8 +521,10 @@ static void mvsw61xx_vlan_port_config(struct switch_dev
*dev, int vno)
if(mode != MV_VTUCTL_EGRESS_TAGGED)
state->ports[i].pvid = state->vlans[vno].vid;
- if (state->vlans[vno].port_based)
+ if (state->vlans[vno].port_based) {
state->ports[i].mask |= state->vlans[vno].mask;
+ state->ports[i].fdb = vno;
+ }
else
state->ports[i].qmode = MV_8021Q_MODE_SECURE;
}
@@ -579,8 +581,14 @@ static int mvsw61xx_update_state(struct switch_dev *dev)
state->ports[i].mask &= ~(1 << i);
- reg = sr16(dev, MV_PORTREG(VLANMAP, i)) & ~MV_PORTS_MASK;
- reg |= state->ports[i].mask;
+ /* set default forwarding DB number and port mask */
+ reg = sr16(dev, MV_PORTREG(CONTROL1, i)) & ~MV_FDB_HI_MASK;
+ reg |= (state->ports[i].fdb >> MV_FDB_HI_SHIFT) &
+ MV_FDB_HI_MASK;
+ sw16(dev, MV_PORTREG(CONTROL1, i), reg);
+
+ reg = ((state->ports[i].fdb & 0xf) << MV_FDB_LO_SHIFT) |
+ state->ports[i].mask;
sw16(dev, MV_PORTREG(VLANMAP, i), reg);
reg = sr16(dev, MV_PORTREG(CONTROL2, i)) &
@@ -620,6 +628,7 @@ static int mvsw61xx_reset(struct switch_dev *dev)
return -ETIMEDOUT;
for (i = 0; i < dev->ports; i++) {
+ state->ports[i].fdb = 0;
state->ports[i].qmode = 0;
state->ports[i].mask = 0;
state->ports[i].pvid = 0;
diff --git a/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
b/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
index 61e134c..dbc6c92 100644
--- a/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
+++ b/target/linux/generic/files/drivers/net/phy/mvsw61xx.h
@@ -224,6 +224,11 @@ enum {
#define MV_PVID_MASK 0x0fff
+#define MV_FDB_HI_MASK 0x00ff
+#define MV_FDB_LO_MASK 0xf000
+#define MV_FDB_HI_SHIFT4
+#define MV_FDB_LO_SHIFT12
+
struct mvsw61xx_state {
struct switch_dev dev;
struct mii_bus *bus;
@@ -238,6 +243,7 @@ struct mvsw61xx_state {
int vlan_enabled;
struct port_state {
+ u16 fdb;
u16 pvid;
u16 mask;
u8 qmode;
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] mvebu: undo LA bit on WRT1900ACv1 WAN MAC address
This had been set in r44508 as a workaround for switch
problems.
Now that the switch driver can handle two devices with
the same MAC address in separate VLANs we can go back
to using the same address on both interfaces.
This is the Linksys firmware's default behavior.
Signed-off-by: Claudio Leite
---
target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac
b/target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac
index 7217e93..9fc8d9a 100644
--- a/target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac
+++ b/target/linux/mvebu/base-files/lib/preinit/06_set_iface_mac
@@ -11,9 +11,8 @@ preinit_set_mac_address() {
case $(mvebu_board_name) in
armada-xp-linksys-mamba)
mac=$(mtd_get_mac_ascii devinfo hw_mac_addr)
- mac_wan=$(macaddr_setbit_la "$mac")
ifconfig eth0 hw ether $mac 2>/dev/null
- ifconfig eth1 hw ether $mac_wan 2>/dev/null
+ ifconfig eth1 hw ether $mac 2>/dev/null
;;
armada-385-linksys-caiman|armada-385-linksys-cobra)
mac=$(mtd_get_mac_ascii devinfo hw_mac_addr)
--
2.1.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 1/3] ar71xx: fix ethernet initialization on QCA953x-based boards (TP-Link TL-WR841N/ND v9, Compex WPJ531)
The initialization routines for these boards were relying on some (wrong) defaults for the QCA953x ethernet. Make these defaults explicit to prevent breaking them when the QCA953x defaults are fixed. Signed-off-by: Matthias Schiffer --- target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v9.c | 6 ++ target/linux/ar71xx/files/arch/mips/ath79/mach-wpj531.c | 7 +++ 2 files changed, 13 insertions(+) diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v9.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v9.c index c28afc6..3e5c2a2 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v9.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr841n-v9.c @@ -109,12 +109,18 @@ static void __init tl_ap143_setup(void) ath79_register_mdio(0, 0x0); /* LAN */ + ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII; + ath79_eth1_data.duplex = DUPLEX_FULL; + ath79_switch_data.phy_poll_mask |= BIT(4); ath79_init_mac(ath79_eth1_data.mac_addr, mac, 0); ath79_register_eth(1); /* WAN */ ath79_switch_data.phy4_mii_en = 1; ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII; + ath79_eth0_data.duplex = DUPLEX_FULL; + ath79_eth0_data.speed = SPEED_100; + ath79_eth0_data.phy_mask = BIT(4); ath79_init_mac(ath79_eth0_data.mac_addr, mac, 1); ath79_register_eth(0); diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj531.c b/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj531.c index bc13d70..e665a2e 100644 --- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj531.c +++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wpj531.c @@ -105,12 +105,19 @@ static void __init common_setup(void) ath79_register_mdio(0, 0x0); /* LAN */ + ath79_eth0_data.duplex = DUPLEX_FULL; + ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII; + ath79_eth0_data.speed = SPEED_100; + ath79_eth0_data.phy_mask = BIT(4); ath79_init_mac(ath79_eth0_data.mac_addr, mac, 0); ath79_register_eth(0); /* WAN */ ath79_switch_data.phy4_mii_en = 1; + ath79_eth1_data.duplex = DUPLEX_FULL; ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_MII; + ath79_eth1_data.speed = SPEED_100; + ath79_switch_data.phy_poll_mask |= BIT(4); ath79_init_mac(ath79_eth1_data.mac_addr, mac, 1); ath79_register_eth(1); -- 2.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 0/3] QCA953x fixes, AP143 support
This patchset was originally submitted by Miaoqing Pan. * 1/3 fixes the initialization on TP-Link TL-WR841N/ND v9 and Compex WPJ531 (TL-WR841N/ND v9 is working, Compex WPJ531 compile-tested only, please test!) * 2/3 is 1/2 from the original submission rebased to apply to the current trunk * 3/3 is 2/2 from the original submission without changes Matthias Schiffer (1): ar71xx: fix ethernet initialization on QCA953x-based boards (TP-Link TL-WR841N/ND v9, Compex WPJ531) Miaoqing Pan (2): ar71xx: rework patch for qca953x/956x ar71xx: add support for ap143 .../ar71xx/base-files/etc/uci-defaults/02_network | 1 + target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 + target/linux/ar71xx/config-3.18| 1 + .../linux/ar71xx/files/arch/mips/ath79/dev-eth.c | 18 +- .../ar71xx/files/arch/mips/ath79/mach-ap143.c | 142 + .../files/arch/mips/ath79/mach-tl-wr841n-v9.c | 6 + .../ar71xx/files/arch/mips/ath79/mach-wpj531.c | 7 + target/linux/ar71xx/generic/profiles/atheros.mk| 12 + target/linux/ar71xx/image/Makefile | 5 + ...07-MIPS-ath79-add-support-for-QCA953x-SoC.patch | 326 +++-- ...35-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 171 --- .../736-MIPS-ath79-fix-chained-irq-disable.patch | 21 +- .../810-MIPS-ath79-wmac-enable-set-led-pin.patch | 24 ++ .../811-MIPS-ath79-gpio-enable-set-direction.patch | 43 +++ .../812-MIPS-ath79-add-ap143-support.patch | 43 +++ 15 files changed, 666 insertions(+), 157 deletions(-) create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c create mode 100644 target/linux/ar71xx/patches-3.18/810-MIPS-ath79-wmac-enable-set-led-pin.patch create mode 100644 target/linux/ar71xx/patches-3.18/811-MIPS-ath79-gpio-enable-set-direction.patch create mode 100644 target/linux/ar71xx/patches-3.18/812-MIPS-ath79-add-ap143-support.patch -- 2.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2 3/3] ar71xx: add support for ap143
From: Miaoqing Pan
Signed-off-by: Miaoqing Pan
---
.../ar71xx/base-files/etc/uci-defaults/02_network | 1 +
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
target/linux/ar71xx/config-3.18| 1 +
.../ar71xx/files/arch/mips/ath79/mach-ap143.c | 142 +
target/linux/ar71xx/generic/profiles/atheros.mk| 12 ++
target/linux/ar71xx/image/Makefile | 5 +
.../810-MIPS-ath79-wmac-enable-set-led-pin.patch | 24
.../811-MIPS-ath79-gpio-enable-set-direction.patch | 43 +++
.../812-MIPS-ath79-add-ap143-support.patch | 43 +++
9 files changed, 274 insertions(+)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c
create mode 100644
target/linux/ar71xx/patches-3.18/810-MIPS-ath79-wmac-enable-set-led-pin.patch
create mode 100644
target/linux/ar71xx/patches-3.18/811-MIPS-ath79-gpio-enable-set-direction.patch
create mode 100644
target/linux/ar71xx/patches-3.18/812-MIPS-ath79-add-ap143-support.patch
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index 2fab4c2..6d76af8 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -383,6 +383,7 @@ wpj558)
ap121 |\
ap121-mini |\
+ap143 |\
ap96 |\
airrouter |\
dir-600-a1 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 00e39ae..4fee82c 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -359,6 +359,9 @@ ar71xx_board_detect() {
*"AP135-020 reference board")
name="ap135-020"
;;
+ *"AP143 reference board")
+ name="ap143"
+ ;;
*AP81)
name="ap81"
;;
diff --git a/target/linux/ar71xx/config-3.18 b/target/linux/ar71xx/config-3.18
index 17f33bd..0af087d 100644
--- a/target/linux/ar71xx/config-3.18
+++ b/target/linux/ar71xx/config-3.18
@@ -35,6 +35,7 @@ CONFIG_ATH79_MACH_AP113=y
CONFIG_ATH79_MACH_AP121=y
CONFIG_ATH79_MACH_AP132=y
CONFIG_ATH79_MACH_AP136=y
+CONFIG_ATH79_MACH_AP143=y
CONFIG_ATH79_MACH_AP81=y
CONFIG_ATH79_MACH_AP83=y
CONFIG_ATH79_MACH_AP96=y
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c
new file mode 100644
index 000..098420b
--- /dev/null
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ap143.c
@@ -0,0 +1,142 @@
+/*
+ * Atheros AP143 reference board support
+ *
+ * Copyright (c) 2013-2015 The Linux Foundation. All rights reserved.
+ * Copyright (c) 2012 Gabor Juhos
+ *
+ * Permission to use, copy, modify, and/or distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ *
+ */
+
+#include
+#include
+#include
+
+#include
+
+#include "common.h"
+#include "dev-eth.h"
+#include "dev-gpio-buttons.h"
+#include "dev-leds-gpio.h"
+#include "dev-m25p80.h"
+#include "dev-spi.h"
+#include "dev-usb.h"
+#include "dev-wmac.h"
+#include "machtypes.h"
+
+#define AP143_GPIO_LED_WLAN12
+#define AP143_GPIO_LED_WPS 13
+#define AP143_GPIO_LED_STATUS 13
+
+#define AP143_GPIO_LED_WAN 4
+#define AP143_GPIO_LED_LAN116
+#define AP143_GPIO_LED_LAN215
+#define AP143_GPIO_LED_LAN314
+#define AP143_GPIO_LED_LAN411
+
+#define AP143_GPIO_BTN_WPS 17
+
+#define AP143_KEYS_POLL_INTERVAL 20 /* msecs */
+#define AP143_KEYS_DEBOUNCE_INTERVAL (3 * AP143_KEYS_POLL_INTERVAL)
+
+#define AP143_MAC0_OFFSET 0
+#define AP143_MAC1_OFFSET 6
+#define AP143_WMAC_CALDATA_OFFSET 0x1000
+
+static struct gpio_led ap143_leds_gpio[] __initdata = {
+ {
+ .name = "ap143:green:status",
+ .gpio = AP143_GPIO_LED_STATUS,
+ .active_low = 1,
+ },
+ {
+ .name = "ap143:green:wlan",
+ .gpio = AP143_GPIO_LED_WLAN,
+ .active_low = 1,
+ }
+};
+
+static struct gpio_keys_button ap143_gpio_keys[] __initdata = {
+ {
+ .desc = "WPS button",
+
[OpenWrt-Devel] [PATCH v2 2/3] ar71xx: rework patch for qca953x/956x
From: Miaoqing Pan
Patch cherry-picked from the following location:
https://www.codeaurora.org/cgit/quic/qsdk/oss/system/openwrt/commit/?h=release/coconut_ioe4531_2.0&id=5c357bf6c763e4140dddcc9a3bc5f005525a9c0e
Changelist,
- add more register defines
- add EHCI support
- fix GPIO pin count to 18
- fix chained irq disabled
- fix GMAC0/GMAC1 initial
- fix WMAC irq number to 47
- merge the changes of dev-eth.c from the patch to file.
Signed-off-by: Miaoqing Pan
Signed-off-by: Matthias Schiffer
---
.../linux/ar71xx/files/arch/mips/ath79/dev-eth.c | 18 +-
...07-MIPS-ath79-add-support-for-QCA953x-SoC.patch | 326 +++--
...35-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 171 ---
.../736-MIPS-ath79-fix-chained-irq-disable.patch | 21 +-
4 files changed, 379 insertions(+), 157 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
index ae3db4c..ff94e2e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/dev-eth.c
@@ -198,6 +198,8 @@ void __init ath79_register_mdio(unsigned int id, u32
phy_mask)
case ATH79_SOC_AR9330:
case ATH79_SOC_AR9331:
case ATH79_SOC_QCA9533:
+ case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
mdio_dev = &ath79_mdio1_device;
mdio_data = &ath79_mdio1_data;
break;
@@ -256,6 +258,8 @@ void __init ath79_register_mdio(unsigned int id, u32
phy_mask)
break;
case ATH79_SOC_QCA9533:
+ case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
mdio_data->builtin_switch = 1;
break;
@@ -571,6 +575,8 @@ static void __init ath79_init_eth_pll_data(unsigned int id)
case ATH79_SOC_QCA9533:
case ATH79_SOC_QCA9556:
case ATH79_SOC_QCA9558:
+ case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
pll_10 = AR934X_PLL_VAL_10;
pll_100 = AR934X_PLL_VAL_100;
pll_1000 = AR934X_PLL_VAL_1000;
@@ -627,6 +633,8 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
case ATH79_SOC_AR9330:
case ATH79_SOC_AR9331:
case ATH79_SOC_QCA9533:
+ case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
pdata->phy_if_mode = PHY_INTERFACE_MODE_MII;
break;
@@ -687,7 +695,8 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
case ATH79_SOC_AR7241:
case ATH79_SOC_AR9330:
case ATH79_SOC_AR9331:
- case ATH79_SOC_QCA9533:
+ case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
pdata->phy_if_mode = PHY_INTERFACE_MODE_GMII;
break;
@@ -697,6 +706,7 @@ static int __init ath79_setup_phy_if_mode(unsigned int id,
case ATH79_SOC_AR9341:
case ATH79_SOC_AR9342:
case ATH79_SOC_AR9344:
+ case ATH79_SOC_QCA9533:
switch (pdata->phy_if_mode) {
case PHY_INTERFACE_MODE_MII:
case PHY_INTERFACE_MODE_GMII:
@@ -986,6 +996,7 @@ void __init ath79_register_eth(unsigned int id)
case ATH79_SOC_AR9341:
case ATH79_SOC_AR9342:
case ATH79_SOC_AR9344:
+ case ATH79_SOC_QCA9533:
if (id == 0) {
pdata->reset_bit = AR934X_RESET_GE0_MAC |
AR934X_RESET_GE0_MDIO;
@@ -1017,7 +1028,8 @@ void __init ath79_register_eth(unsigned int id)
pdata->fifo_cfg3 = 0x01f00140;
break;
- case ATH79_SOC_QCA9533:
+ case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
if (id == 0) {
pdata->reset_bit = AR933X_RESET_GE0_MAC |
AR933X_RESET_GE0_MDIO;
@@ -1123,6 +1135,8 @@ void __init ath79_register_eth(unsigned int id)
case ATH79_SOC_AR9330:
case ATH79_SOC_AR9331:
case ATH79_SOC_QCA9533:
+ case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
pdata->mii_bus_dev = &ath79_mdio1_device.dev;
break;
diff --git
a/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
b/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
index 4f5d203..be4f547 100644
---
a/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
+++
b/target/linux/ar71xx/patches-3.18/707-MIPS-ath79-add-support-for-QCA953x-SoC.patch
@@ -44,7 +44,7 @@ meaning of the bits CPUCLK_FROM_CPUPLL and DDRCLK_FROM_DDRPLL
is reversed.
config ATH79_NVRAM
--- a/arch/mips/ath79/clock
[OpenWrt-Devel] Change Default Configuration
Hi, I am able to change the settings in the file under overlay and settings will get change, but when i do factory reset from GUI, All the changes i have done in script file will go. So i need to know from which file this all factory reset configuration is loading so that if i will change it that file with my default configuration. So that after factory reset it should load with my default settings. Thanks, John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
