Re: [OpenWrt-Devel] [PATCH] dnsmasq: bump to dnsmasq2.73rc7
On 29/04/2015 10:13, Steven Barth wrote: Looks good and applies. Usually the Signed-off-by is at the end of the commit message though. Understood. Happy :-) smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Status report: spent lots of time trying to figure out how to use cpu port 8 and use vlan1ports 0 1 2 3 5 7 8t, and found that I got fooled by the way I tried to determine if it was working or not. To see if the switch configuration was working I used to type ifconfig and then see if there were and rx packets. Today I added logging in bgmac to see if there are any rx interrupts, and to my surprise there are. So it is possible to get it to work with cpu port 8 but the data is being dropped by the stack (nothing visible in the counters). This is sample data that gets received: [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 The ip addres of the ipv4 packet is of one of the connected PCs. These packets get dropped somehow and it is related to the config vlan1ports 0 1 2 3 5 7 8t. I can use cpu port 8 and config vlan1ports 0 1 2 3 5t without a problem. So there might be an issue in the switch code, but there are more problems with this configuration in other areas. -Original Message- On Thu, 2015-04-23 at 14:48 +, Hante Meuleman wrote: Thank you for the information Ian, that was very helpful. Just found part of the problem. My R8000 used to work quite well, till I upgraded to new Netgear firmware. The old Netgear firmware is using this nvram entry: vlan1ports=3 2 1 0 5 7 8* Newer firmware will update this nvram entry to vlan1ports=0 1 2 3 5 7 8* My device had this setting from the beginning. So depending on when you bought the AP you will have one of these entries in the nvram. Both strings indicate that port 8 is the cpu port, however, somehow the application (or script, not sure what is doing this) that generates the file /etc/config/network at first boot will generate different results for the entry: option ports vlan1ports=3 2 1 0 5 7 8* - option ports '0 1 2 3 5t' vlan1ports=0 1 2 3 5 7 8* - option ports '0 1 2 3 5 7 8t' So when you have newer Netgear FW in your AP then you'll have a different setting for vlan1ports in /etc/config/network then with older firmware. This setting determines whether or not the switch is going to work (as you already figured out). Still investigating to as of why this setting doesn't work with b53 driver. -Original Message- On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: Today I wrote the original firmware back on the device (using the latest from netgear). This worked and the device was working fine. Then I flashed openwrt again, now the switch didn’t work anymore. So I checked the ports configuration and it had changed. So I reverted that using the nvram userspace program. This killed the nvram contents completely and after reboot I only had the bare minimum nvram contents and it was the same as before. However, now I cannot get the switch to work anymore. So doing an nvram set xxx=yyy, followed by nvram commit appears to be killing my nvram contents. I've no idea why my switch is not working anymore. The problems with this switch is starting to get frustrating Yes, the switch is frustrating and all I can do is describe what I've seen, maybe it will help. A fairly recent change to setting the switch configuration in /etc/config/network at install sets the switch ports to 0 1 2 3 5 7 8t and 4 8t for the respective vlans. But the b53 driver still uses port 5 as the cpu and does the setup that you've previously described as working (using port 5 as cpu). The switch configuration in network is done once at firmware install so it needs to be changed by hand. What's more annoying is doing the heavy lifting in b53 to setup the switch to use port 8 for the cpu, the way the Broadcom source does, doesn't work so I'm missing something with that for sure. So we do need to stick to using port 5 for the cpu consistently throughout for now. Regards, Hante -Original Message- From: Hante Meuleman Sent: dinsdag 21 april 2015 17:22 To: 'Ian Kent'; Arend Van Spriel Cc: 'Jonas Gorski'; 'mailinglist' Subject: RE: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram. Today I managed to update brcmfmac to load the data directly from bcm47xx_nvram but it will require an additional api in this module. I will post my version of bcm47xx_nvram later this week. Also the patch for brcmfmac will be posted later this week. With proper NVRAM the device is now booting fine and all wireless devices get detected properly and are working fine. I still do not know why I
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Created some more logging, it is probably a configuration error in the switch when port 8 is part of the vlan configuration. It appears there is an offset in the data being received by bgmac, strangely enough, the log appears to show valid data, but that data is not accepted while the working configuration gives debug data like this: [ 23.955731] bgmac: ETH, len=64, flags=0x05, protocol=0x0081 [ 23.962731] bgmac: 00 01 08 00 46 c0 00 20 00 00 40 00 01 02 40 72 [ 23.970811] bgmac: c0 a8 02 02 e0 00 00 fb 94 04 00 00 16 00 09 04 Which appears to be incorrect (wrong protocol) and data has offset of 4. But this data does get accepted and is working. -Original Message- Status report: spent lots of time trying to figure out how to use cpu port 8 and use vlan1ports 0 1 2 3 5 7 8t, and found that I got fooled by the way I tried to determine if it was working or not. To see if the switch configuration was working I used to type ifconfig and then see if there were and rx packets. Today I added logging in bgmac to see if there are any rx interrupts, and to my surprise there are. So it is possible to get it to work with cpu port 8 but the data is being dropped by the stack (nothing visible in the counters). This is sample data that gets received: [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 The ip addres of the ipv4 packet is of one of the connected PCs. These packets get dropped somehow and it is related to the config vlan1ports 0 1 2 3 5 7 8t. I can use cpu port 8 and config vlan1ports 0 1 2 3 5t without a problem. So there might be an issue in the switch code, but there are more problems with this configuration in other areas. -Original Message- On Thu, 2015-04-23 at 14:48 +, Hante Meuleman wrote: Thank you for the information Ian, that was very helpful. Just found part of the problem. My R8000 used to work quite well, till I upgraded to new Netgear firmware. The old Netgear firmware is using this nvram entry: vlan1ports=3 2 1 0 5 7 8* Newer firmware will update this nvram entry to vlan1ports=0 1 2 3 5 7 8* My device had this setting from the beginning. So depending on when you bought the AP you will have one of these entries in the nvram. Both strings indicate that port 8 is the cpu port, however, somehow the application (or script, not sure what is doing this) that generates the file /etc/config/network at first boot will generate different results for the entry: option ports vlan1ports=3 2 1 0 5 7 8* - option ports '0 1 2 3 5t' vlan1ports=0 1 2 3 5 7 8* - option ports '0 1 2 3 5 7 8t' So when you have newer Netgear FW in your AP then you'll have a different setting for vlan1ports in /etc/config/network then with older firmware. This setting determines whether or not the switch is going to work (as you already figured out). Still investigating to as of why this setting doesn't work with b53 driver. -Original Message- On Wed, 2015-04-22 at 11:45 +, Hante Meuleman wrote: Today I wrote the original firmware back on the device (using the latest from netgear). This worked and the device was working fine. Then I flashed openwrt again, now the switch didn’t work anymore. So I checked the ports configuration and it had changed. So I reverted that using the nvram userspace program. This killed the nvram contents completely and after reboot I only had the bare minimum nvram contents and it was the same as before. However, now I cannot get the switch to work anymore. So doing an nvram set xxx=yyy, followed by nvram commit appears to be killing my nvram contents. I've no idea why my switch is not working anymore. The problems with this switch is starting to get frustrating Yes, the switch is frustrating and all I can do is describe what I've seen, maybe it will help. A fairly recent change to setting the switch configuration in /etc/config/network at install sets the switch ports to 0 1 2 3 5 7 8t and 4 8t for the respective vlans. But the b53 driver still uses port 5 as the cpu and does the setup that you've previously described as working (using port 5 as cpu). The switch configuration in network is done once at firmware install so it needs to be changed by hand. What's more annoying is doing the heavy lifting in b53 to setup the switch to use port 8 for the cpu, the way the Broadcom source does, doesn't work so I'm missing something with that for sure. So we do need to stick to using port 5 for the cpu consistently throughout for now. Regards, Hante
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
On 29 April 2015 at 12:51, Hante Meuleman meule...@broadcom.com wrote: Status report: spent lots of time trying to figure out how to use cpu port 8 and use vlan1ports 0 1 2 3 5 7 8t, and found that I got fooled by the way I tried to determine if it was working or not. To see if the switch configuration was working I used to type ifconfig and then see if there were and rx packets. Today I added logging in bgmac to see if there are any rx interrupts, and to my surprise there are. So it is possible to get it to work with cpu port 8 but the data is being dropped by the stack (nothing visible in the counters). This is sample data that gets received: [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 Packets received by bgmac are supposed to be VLAN tagged. Are they in your case? I think you're dumping beginning on every packet. Compare dump (early bytes, look for 802.1Q header [0]) when using 5t vs. 8t. [0] http://en.wikipedia.org/wiki/IEEE_802.1Q ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: bump to dnsmasq2.73rc7
Sorry, beat you again by 20 minutes :P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR8334 switch support
On Wed, Apr 29, 2015 at 11:26 AM, Christian Mehlis christ...@m3hlis.de wrote: On plug/unplug I get those events: [ 25.12] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is up [ 37.13] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is down but the linux network stack is keeping the interface UP. IMHO that's no contradiction. If the port is disconnected the interface should no longer be LOWER_UP. UP just means it's enabled, not necessarily connected. Rgds, Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: bump to dnsmasq2.73rc7
Looks good and applies. Usually the Signed-off-by is at the end of the commit message though. Cheers, Steven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR8334 switch support
Am 28.04.2015 um 22:10 schrieb Heiner Kallweit: It was easier than I thought, here comes the related patch. Known limitations: 1. The patch supports configuration of this bit for platform-data-configured platforms only. DT-based platforms would need a similar extension. 2. For now it's for WPJ344 only. Every other AR8334-based device would need the same extension to the platform data. Rgds, Heiner Hi Heiner, this explicit way to talk to the driver is working! Thank you for your effort! Tested-By: Christian Mehlis christ...@m3hlis.de ## Perhaps you know the answer to my last problem with this hardware too: On plug/unplug I get those events: [ 25.12] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is up [ 37.13] Atheros AR8216/AR8236/AR8316 ag71xx-mdio.0:00: Port 2 is down but the linux network stack is keeping the interface UP. config interface 'wan' option ifname 'eth0.2' option proto 'dhcp' config switch option name 'switch0' option reset '1' option enable_vlan '1' config switch_vlan option device 'switch0' option vlan '1' option ports '0t 3' config switch_vlan option device 'switch0' option vlan '2' option ports '0t 2' I have never had this behaviour on other platforms...do you think the compex-344 specific initialization is done wrong? # Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] dnsmasq: bump to dnsmasq2.73rc7
Bump dnsmasq to v2.73rc7 Fixes DNSSEC over TCP issue Also include patch from dnsmasq upstream to include RRSIG RR replies in ANY queries Signed-off-by: Kevin Darbyshire-Bryant ke...@darbyshire-bryant.me.uk Tested Archer C7 Maybe I even get this one right :-) diff --git a/package/network/services/dnsmasq/Makefile b/package/network/services/dnsmasq/Makefile index b962470..8f55274 100644 --- a/package/network/services/dnsmasq/Makefile +++ b/package/network/services/dnsmasq/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=dnsmasq -PKG_VERSION:=2.73rc6 +PKG_VERSION:=2.73rc7 PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=http://thekelleys.org.uk/dnsmasq/release-candidates -PKG_MD5SUM:=9ee735fe4f1250620f007039a034710f +PKG_MD5SUM:=526f7d51b71e07e6e431f5ea48f4b5be PKG_LICENSE:=GPL-2.0 PKG_LICENSE_FILES:=COPYING diff --git a/package/network/services/dnsmasq/patches/001-include-RRSIG-RR-answers-to-ANY-queries.patch b/package/network/services/dnsmasq/patches/001-include-RRSIG-RR-answers-to-ANY-queries.patch new file mode 100644 index 000..40ccd1a --- /dev/null +++ b/package/network/services/dnsmasq/patches/001-include-RRSIG-RR-answers-to-ANY-queries.patch @@ -0,0 +1,29 @@ +From 2ed162ac204f3609fe4d9f9a0430baeaa352d88f Mon Sep 17 00:00:00 2001 +From: Simon Kelley si...@thekelleys.org.uk +Date: Tue, 28 Apr 2015 21:26:35 +0100 +Subject: [PATCH] Don't remove RRSIG RR from answers to ANY queries when the + do bit is not set. + +--- + src/rfc1035.c |5 + + 1 file changed, 5 insertions(+) + +diff --git a/src/rfc1035.c b/src/rfc1035.c +index 32df31a..5828055 100644 +--- a/src/rfc1035.c b/src/rfc1035.c +@@ -1608,6 +1608,11 @@ size_t answer_request(struct dns_header *header, char *limit, size_t qlen, + GETSHORT(qtype, p); + GETSHORT(qclass, p); + ++ /* Don't filter RRSIGS from answers to ANY queries, even if do-bit ++ not set. */ ++ if (qtype == T_ANY) ++*do_bit = 1; ++ + ans = 0; /* have we answered this question */ + + if (qtype == T_TXT || qtype == T_ANY) +-- +1.7.10.4 + smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] dnsmasq: bump to dnsmasq2.73rc7
On 29/04/2015 09:17, Steven Barth wrote: Sorry, beat you again by 20 minutes :P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ROFL - I *should* give up, but I won't :-) Out of interest, did I actually get the patch formatting and everything correct? Any reason why it wouldn't be applied? If not I'll be very happy! Kevin smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] netifd: Default enabling of transmit/receive packet steering
In netifd transmit and receive packet steering is enabled by default since commit 20510bd. This default setting gives problems on our architecture as real time threads are used for networking. The transmit/receive packet steering will move some of the work to softirq which has higher prio than the real time threads which will cripple the system in some scenarios. As transmit/receive packet steering is enabled by default extra device config need to be added to guarantee backwards compatibility (thus disabling per device transmit/receive packet steering) which makes it hard to maintain. To avoid this overhead does it make sense to disable transmit/receive packet steering by default (and thus enable it only by device config to keep backwards compatiblity) or keep the default value but allow it to be overruled by a cmd line parameter passed to netifd ? Thx, Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Fwd: Re: [PATCH 10/10] brcmfmac: Add support for multiple PCIE devices in nvram.
Thanks, that explains. Also found some code in proprietary driver which appears to correct the header in certain situations, but it is rather complex. But what it appears to be is that there should be a vlan tag, but there isn’t always. And when there isn’t it should be inserted. But the current bgmac is incorrectly determining the ethertype as the function eth_type_trans won't take this vlan tag into account. Trying some trickery (based upon flags in header of rx frame) to make it work. -Original Message- On 29 April 2015 at 12:51, Hante Meuleman meule...@broadcom.com wrote: Status report: spent lots of time trying to figure out how to use cpu port 8 and use vlan1ports 0 1 2 3 5 7 8t, and found that I got fooled by the way I tried to determine if it was working or not. To see if the switch configuration was working I used to type ifconfig and then see if there were and rx packets. Today I added logging in bgmac to see if there are any rx interrupts, and to my surprise there are. So it is possible to get it to work with cpu port 8 but the data is being dropped by the stack (nothing visible in the counters). This is sample data that gets received: [ 32.759614] bgmac: ETH, len=324, flags=0x01, protocol=0x0008 [ 32.766714] bgmac: 45 00 01 36 bc f2 40 00 ff 11 19 8a c0 a8 02 96 [ 32.774796] bgmac: e0 00 00 fb 14 e9 14 e9 01 22 b5 86 00 00 84 00 [ 32.782892] bgmac: ETH, len=344, flags=0x01, protocol=0xdd86 [ 32.789989] bgmac: 60 00 00 00 01 22 11 ff fd 1b 72 e5 79 5c 00 00 [ 32.798077] bgmac: 75 58 39 77 51 db f7 b2 ff 02 00 00 00 00 00 00 Packets received by bgmac are supposed to be VLAN tagged. Are they in your case? I think you're dumping beginning on every packet. Compare dump (early bytes, look for 802.1Q header [0]) when using 5t vs. 8t. [0] http://en.wikipedia.org/wiki/IEEE_802.1Q ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: fix sysupgrade for compex-wpj344
Moved board to the right magic case.
Signed-off-by: Christian Mehlis christ...@m3hlis.de
---
target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index a8cec91..b3c61ef 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -184,7 +184,6 @@ platform_check_image() {
db120 | \
f9k1115v2 |\
hornet-ub | \
- wpj344 | \
wpj558 | \
zcn-1523h-2 | \
zcn-1523h-5)
@@ -229,6 +228,7 @@ platform_check_image() {
nanostation-m-xw | \
rw2458n | \
wndap360 | \
+ wpj344 | \
wzr-hp-g300nh2 | \
wzr-hp-g300nh | \
wzr-hp-g450h | \
--
2.3.4.263.gf53fc38
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Tue, 2015-04-07 at 00:00 +0200, Martin Blumenstingl wrote: Feel free to send me the details how to get more versions into this list (please be aware that I need a link to a public hosted file that *everyone* can download). You can run the w921v_fw_cutter also on newer firmware for that, e.g. http://hilfe.telekom.de/dlp/eki/downloads/Speedport/Speedport%20W%20921V/Firmware_Speedport_W921V_1.34.000.bin which gets you a file with filename: vr9_dsl_fw_annex_b.bin version: 5.6.7.6.1.7-5.6.7.2.1.2 sha1sum: 1e472dad0eda88281af7c00cd3f49fcc29d4fa83 filesize: 877836 Firmware1: PLATFORM: 5 PLATFORM_STR: VRX200 APPLICATION_TYPE: 7 APPLICATION_TYPE_STR: VDSL over ISDN incl. vectoring support VERSION_STR: 6.7.6 RELEASE_STATUS: 1 RELEASE_STATUS_STR: Pre-Release Firmware2: PLATFORM: 5 PLATFORM_STR: VRX200 APPLICATION_TYPE: 2 APPLICATION_TYPE_STR: ADSL Annex B VERSION_STR: 6.7.2 RELEASE_STATUS: 1 RELEASE_STATUS_STR: Pre-Release While I was at it I researched if there was a newer driver version that the one we currently have in OpenWrt (v4.11.4). There was an update to v4.11.11 like 9 months ago, which was reverted because it was not working for everyone. Since I was not sure if the old driver could handle newer DSL firmwares I searched if I could find anything newer than v4.11.11 - and I found v4.15.2 in BT Home Hub 5A's sources (unfortunately with all build files stripped off). Did you figure out which firmware that can deal with? Have you tried running it? I could try running it with vectoring. johannes ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Raspberry Pi 2 buildbot (brcm2708/bcm2709)
Hello guys, It's been over 3 months since Raspberry PI 2 (brcm2708/bcm2709) target was added. I requested Travis a buildbot over a month ago but my email wasn't responded. So, can we have a buildbot please :D? Regards, Álvaro. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar8216: Fix problem with AR8337 MAC swap handling
AR8337 supports a configuration bit to swap MAC0 and MAC6.
Currently this is set in general if an AR8337 is detected and causes
issues with devices using an AR8334 (internally an AR8337, just
less chip pins).
And it might even cause issues with AR8337-based devices with
different board designs.
Swapping the MAC's however isn't needed for AR8337 in general.
It's just needed in case of certain board designs (affected devices
seem to be based on Atheros reference board AP135/136-010).
Therefore this configuration bit should be moved to platform data.
The patch includes the needed changes to the device initialization
code of affected devices. Hopefully I didn't miss any ..
Signed-off-by: Heiner Kallweit hkallwe...@gmail.com
---
target/linux/ar71xx/files/arch/mips/ath79/mach-esr1750.c | 1 +
target/linux/ar71xx/files/arch/mips/ath79/mach-f9k1115v2.c | 1 +
target/linux/ar71xx/files/arch/mips/ath79/mach-nbg6716.c | 1 +
target/linux/ar71xx/files/arch/mips/ath79/mach-wlr8100.c | 1 +
target/linux/generic/files/drivers/net/phy/ar8327.c| 6 +++---
target/linux/generic/files/include/linux/ar8216_platform.h | 4 +++-
6 files changed, 10 insertions(+), 4 deletions(-)
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-esr1750.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-esr1750.c
index 2a34b3a..d2bc177 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-esr1750.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-esr1750.c
@@ -97,6 +97,7 @@ static struct ar8327_pad_cfg esr1750_ar8327_pad0_cfg = {
.rxclk_delay_en = true,
.txclk_delay_sel = AR8327_CLK_DELAY_SEL2,
.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
+ .mac06_exchange_en = true,
};
static struct ar8327_platform_data esr1750_ar8327_data = {
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-f9k1115v2.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-f9k1115v2.c
index 69d005d..9e86e9a 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-f9k1115v2.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-f9k1115v2.c
@@ -98,6 +98,7 @@ static struct ar8327_pad_cfg f9k1115v2_ar8327_pad0_cfg = {
.rxclk_delay_en = true,
.txclk_delay_sel = AR8327_CLK_DELAY_SEL1,
.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2,
+ .mac06_exchange_en = true,
};
static struct ar8327_pad_cfg f9k1115v2_ar8327_pad6_cfg = {
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-nbg6716.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-nbg6716.c
index 0ca2e56..69a73cc 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-nbg6716.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-nbg6716.c
@@ -251,6 +251,7 @@ static void __init nbg6716_010_setup(void)
nbg6716_ar8327_pad0_cfg.rxclk_delay_en = true;
nbg6716_ar8327_pad0_cfg.txclk_delay_sel = AR8327_CLK_DELAY_SEL1;
nbg6716_ar8327_pad0_cfg.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2;
+ nbg6716_ar8327_pad0_cfg.mac06_exchange_en = true;
/* GMAC6 of the AR8337 switch is connected to GMAC1 via SGMII */
nbg6716_ar8327_pad6_cfg.mode = AR8327_PAD_MAC_SGMII;
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-wlr8100.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-wlr8100.c
index 88022e7..6a90c6e 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-wlr8100.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-wlr8100.c
@@ -186,6 +186,7 @@ static void __init wlr8100_010_setup(void)
wlr8100_ar8327_pad0_cfg.rxclk_delay_en = true;
wlr8100_ar8327_pad0_cfg.txclk_delay_sel = AR8327_CLK_DELAY_SEL1;
wlr8100_ar8327_pad0_cfg.rxclk_delay_sel = AR8327_CLK_DELAY_SEL2;
+ wlr8100_ar8327_pad0_cfg.mac06_exchange_en = true;
/* GMAC6 of the AR8337 switch is connected to GMAC1 via SGMII */
wlr8100_ar8327_pad6_cfg.mode = AR8327_PAD_MAC_SGMII;
diff --git a/target/linux/generic/files/drivers/net/phy/ar8327.c
b/target/linux/generic/files/drivers/net/phy/ar8327.c
index 07e837e..a6dd7d8 100644
--- a/target/linux/generic/files/drivers/net/phy/ar8327.c
+++ b/target/linux/generic/files/drivers/net/phy/ar8327.c
@@ -124,6 +124,9 @@ ar8327_get_pad_cfg(struct ar8327_pad_cfg *cfg)
break;
}
+ if (cfg-mac06_exchange_en)
+ t |= AR8337_PAD_MAC06_EXCHANGE_EN;
+
return t;
}
@@ -508,9 +511,6 @@ ar8327_hw_config_pdata(struct ar8xxx_priv *priv,
data-port6_status = ar8327_get_port_init_status(pdata-port6_cfg);
t = ar8327_get_pad_cfg(pdata-pad0_cfg);
- if (chip_is_ar8337(priv))
- t |= AR8337_PAD_MAC06_EXCHANGE_EN;
-
ar8xxx_write(priv, AR8327_REG_PAD0_MODE, t);
t = ar8327_get_pad_cfg(pdata-pad5_cfg);
ar8xxx_write(priv, AR8327_REG_PAD5_MODE, t);
diff --git a/target/linux/generic/files/include/linux/ar8216_platform.h
b/target/linux/generic/files/include/linux/ar8216_platform.h
index 4935ad3..d70f11a 100644
---
[OpenWrt-Devel] [PATCH 2/2] ar71xx: use Image/BuildLoaderPatched for TPLINK-SAFELOADER images
Building the loader in Image/Build/TPLINK-SAFELOADER would break the image builder as no target compiler is available in that stage. Fixes #19580 Signed-off-by: Matthias Schiffer mschif...@universe-factory.net --- target/linux/ar71xx/image/Makefile | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/target/linux/ar71xx/image/Makefile b/target/linux/ar71xx/image/Makefile index 06e2c0d..8db278d 100644 --- a/target/linux/ar71xx/image/Makefile +++ b/target/linux/ar71xx/image/Makefile @@ -1078,14 +1078,10 @@ define Image/Build/TPLINK-LZMA/initramfs endef -Image/Build/TPLINK-SAFELOADER/buildkernel=$(call PatchKernelLzma,$(2),$(3) $(4)) +Image/Build/TPLINK-SAFELOADER/loader = $(call Image/BuildLoaderPatched,$(1),elf,$(2) $(3)) define Image/Build/TPLINK-SAFELOADER - -rm -rf $(KDIR)/lzma-loader - $(LOADER_MAKE) LOADER=loader-$(2).elf\ - LZMA_TEXT_START=0x80a0 LOADADDR=0x8006 \ - LOADER_DATA=$(KDIR_TMP)/vmlinux-$(2).bin.lzma BOARD=$(2) \ - compile loader.elf + [ -e $(KDIR)/loader-$(2).elf ] -$(STAGING_DIR_HOST)/bin/tplink-safeloader \ -B $(5) \ -- 2.3.7 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR8334 switch support
I still have to adjust it to make handling of the new platform parameter more consistent with general handling of platform data. Most likely I can submit the final patch by today. Rgds, Heiner On Wed, Apr 29, 2015 at 4:16 PM, Christian Mehlis christ...@m3hlis.de wrote: Am 28.04.2015 um 22:10 schrieb Heiner Kallweit: It was easier than I thought, here comes the related patch. do you plan to send this as a patch to make the change available for everyone, or should I? Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] AR8334 switch support
Am 28.04.2015 um 22:10 schrieb Heiner Kallweit: It was easier than I thought, here comes the related patch. do you plan to send this as a patch to make the change available for everyone, or should I? Best Christian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] mpc85xx: gianfar: add mtd-mac-address support
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
.../101-NET-add-of_get_mac_address_mtd.patch | 76 ++
.../102-net-gianfar-use-mtd-mac-address.patch | 19 ++
2 files changed, 95 insertions(+)
create mode 100644
target/linux/mpc85xx/patches-3.18/101-NET-add-of_get_mac_address_mtd.patch
create mode 100644
target/linux/mpc85xx/patches-3.18/102-net-gianfar-use-mtd-mac-address.patch
diff --git
a/target/linux/mpc85xx/patches-3.18/101-NET-add-of_get_mac_address_mtd.patch
b/target/linux/mpc85xx/patches-3.18/101-NET-add-of_get_mac_address_mtd.patch
new file mode 100644
index 000..4d05dd6
--- /dev/null
+++ b/target/linux/mpc85xx/patches-3.18/101-NET-add-of_get_mac_address_mtd.patch
@@ -0,0 +1,76 @@
+From 92f38460229a8816404408f036f0a374f1013d0e Mon Sep 17 00:00:00 2001
+From: John Crispin blo...@openwrt.org
+Date: Sun, 27 Jul 2014 09:40:01 +0100
+Subject: NET: add of_get_mac_address_mtd()
+
+Many embedded devices have information such as mac addresses stored inside mtd
+devices. This patch allows us to add a property inside a node describing a
+network interface. The new property points at a mtd partition with an offset
+where the mac address can be found.
+
+Signed-off-by: John Crispin blo...@openwrt.org
+---
+ drivers/of/of_net.c| 37 +
+ include/linux/of_net.h |1 +
+ 2 files changed, 38 insertions(+)
+
+--- a/drivers/of/of_net.c
b/drivers/of/of_net.c
+@@ -10,6 +10,7 @@
+ #include linux/of_net.h
+ #include linux/phy.h
+ #include linux/export.h
++#include linux/mtd/mtd.h
+
+ /**
+ * of_get_phy_mode - Get phy mode for given device_node
+@@ -75,3 +76,39 @@ const void *of_get_mac_address(struct de
+ return NULL;
+ }
+ EXPORT_SYMBOL(of_get_mac_address);
++
++int of_get_mac_address_mtd(struct device_node *np, void *mac)
++{
++ struct device_node *mtd_np = NULL;
++ size_t retlen;
++ int size, ret;
++ struct mtd_info *mtd;
++ const char *part;
++ const __be32 *list;
++ phandle phandle;
++
++ list = of_get_property(np, mtd-mac-address, size);
++ if (!list || (size != (2 * sizeof(*list
++ return -ENOENT;
++
++ phandle = be32_to_cpup(list++);
++ if (phandle)
++ mtd_np = of_find_node_by_phandle(phandle);
++
++ if (!mtd_np)
++ return -ENOENT;
++
++ part = of_get_property(mtd_np, label, NULL);
++ if (!part)
++ part = mtd_np-name;
++
++ mtd = get_mtd_device_nm(part);
++ if (IS_ERR(mtd))
++ return PTR_ERR(mtd);
++
++ ret = mtd_read(mtd, be32_to_cpup(list), 6, retlen, (u_char *) mac);
++ put_mtd_device(mtd);
++
++ return ret;
++}
++EXPORT_SYMBOL_GPL(of_get_mac_address_mtd);
+--- a/include/linux/of_net.h
b/include/linux/of_net.h
+@@ -11,6 +11,7 @@
+ #include linux/of.h
+ extern int of_get_phy_mode(struct device_node *np);
+ extern const void *of_get_mac_address(struct device_node *np);
++extern int of_get_mac_address_mtd(struct device_node *np, void *mac);
+ #else
+ static inline int of_get_phy_mode(struct device_node *np)
+ {
diff --git
a/target/linux/mpc85xx/patches-3.18/102-net-gianfar-use-mtd-mac-address.patch
b/target/linux/mpc85xx/patches-3.18/102-net-gianfar-use-mtd-mac-address.patch
new file mode 100644
index 000..1b7abc8
--- /dev/null
+++
b/target/linux/mpc85xx/patches-3.18/102-net-gianfar-use-mtd-mac-address.patch
@@ -0,0 +1,19 @@
+--- a/drivers/net/ethernet/freescale/gianfar.c
b/drivers/net/ethernet/freescale/gianfar.c
+@@ -858,10 +858,13 @@ static int gfar_of_init(struct platform_
+ if (stash_len || stash_idx)
+ priv-device_flags |= FSL_GIANFAR_DEV_HAS_BUF_STASHING;
+
+- mac_addr = of_get_mac_address(np);
++ err = of_get_mac_address_mtd(np, dev-dev_addr);
++ if (err) {
++ mac_addr = of_get_mac_address(np);
+
+- if (mac_addr)
+- memcpy(dev-dev_addr, mac_addr, ETH_ALEN);
++ if (mac_addr)
++ memcpy(dev-dev_addr, mac_addr, ETH_ALEN);
++ }
+
+ if (model !strcasecmp(model, TSEC))
+ priv-device_flags |= FSL_GIANFAR_DEV_HAS_GIGABIT |
--
2.3.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] mpc85xx: replace WDR4900 uci-defaults ethernet MAC address hack with DTS entry
This also changes the MAC address to one of the adresses actually used by the
stock firmware on one of the ethernet interfaces.
Signed-off-by: Matthias Schiffer mschif...@universe-factory.net
---
target/linux/mpc85xx/base-files/etc/uci-defaults/02_network| 2 --
target/linux/mpc85xx/files/arch/powerpc/boot/dts/tl-wdr4900-v1.dts | 3 ++-
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/target/linux/mpc85xx/base-files/etc/uci-defaults/02_network
b/target/linux/mpc85xx/base-files/etc/uci-defaults/02_network
index e4e3566..525a552 100644
--- a/target/linux/mpc85xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/mpc85xx/base-files/etc/uci-defaults/02_network
@@ -20,8 +20,6 @@ tl-wdr4900-v1)
ucidef_add_switch switch0 1 1
ucidef_add_switch_vlan switch0 1 0t 2 3 4 5
ucidef_add_switch_vlan switch0 2 0t 1
- ucidef_set_interface_macaddr lan $(mtd_get_mac_binary config 338)
- ucidef_set_interface_macaddr wan $(mtd_get_mac_binary config 344)
;;
*)
ucidef_set_interfaces_lan_wan eth0 eth1
diff --git a/target/linux/mpc85xx/files/arch/powerpc/boot/dts/tl-wdr4900-v1.dts
b/target/linux/mpc85xx/files/arch/powerpc/boot/dts/tl-wdr4900-v1.dts
index 49e516c..7e48e23 100644
--- a/target/linux/mpc85xx/files/arch/powerpc/boot/dts/tl-wdr4900-v1.dts
+++ b/target/linux/mpc85xx/files/arch/powerpc/boot/dts/tl-wdr4900-v1.dts
@@ -63,7 +63,7 @@
label = rootfs;
};
- config@fe {
+ config: config@fe {
reg = 0x00fe 0x0001;
label = config;
read-only;
@@ -118,6 +118,7 @@
enet0: ethernet@b {
phy-handle = phy0;
phy-connection-type = rgmii-id;
+ mtd-mac-address = config 0x14c;
};
enet1: ethernet@b1000 {
--
2.3.7
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC PATCH] ar71xx: Support Antminer S1/S3
The Antminer S1 and S3 use a controller with a modified version of
OpenWRT which has a single ethernet port and a wifi antenna header.
This is the patch from their GPL source release which appears to break
support for the tl-wr741nd-v4 in order to support their board. What
would be the proper way to differentiate this device and add support
for it?
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr741nd-v4.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr741nd-v4.c
(revision 38031)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wr741nd-v4.c
(working copy)
@@ -27,12 +27,13 @@
#define TL_WR741NDV4_GPIO_LED_WLAN 0
#define TL_WR741NDV4_GPIO_LED_QSS 1
-#define TL_WR741NDV4_GPIO_LED_WAN 13
-#define TL_WR741NDV4_GPIO_LED_LAN1 14
-#define TL_WR741NDV4_GPIO_LED_LAN2 15
-#define TL_WR741NDV4_GPIO_LED_LAN3 16
-#define TL_WR741NDV4_GPIO_LED_LAN4 17
-#define TL_WR741NDV4_GPIO_LED_SYSTEM 27
+#define TL_WR741NDV4_GPIO_LED_WAN 17
+#define TL_WR741NDV4_GPIO_LED_WANL 22
+#define TL_WR741NDV4_GPIO_LED_LAN1 13
+#define TL_WR741NDV4_GPIO_LED_LAN2 14
+#define TL_WR741NDV4_GPIO_LED_LAN3 15
+#define TL_WR741NDV4_GPIO_LED_LAN4 16
+#define TL_WR741NDV4_GPIO_LED_SYSTEM 23
#define TL_MR3220V2_GPIO_BTN_WPS 11
#define TL_MR3220V2_GPIO_BTN_WIFI 24
@@ -68,7 +69,7 @@
}, {
.name = tp-link:green:lan4,
.gpio = TL_WR741NDV4_GPIO_LED_LAN4,
- .active_low = 1,
+ .active_low = 0,
}, {
.name = tp-link:green:qss,
.gpio = TL_WR741NDV4_GPIO_LED_QSS,
@@ -76,12 +77,16 @@
}, {
.name = tp-link:green:system,
.gpio = TL_WR741NDV4_GPIO_LED_SYSTEM,
- .active_low = 1,
+ .active_low = 0,
}, {
.name = tp-link:green:wan,
.gpio = TL_WR741NDV4_GPIO_LED_WAN,
.active_low = 0,
}, {
+ .name = tp-link:green:wan_link,
+ .gpio = TL_WR741NDV4_GPIO_LED_WANL,
+ .active_low = 0,
+ }, {
.name = tp-link:green:wlan,
.gpio = TL_WR741NDV4_GPIO_LED_WLAN,
.active_low = 0,
@@ -100,7 +105,7 @@
.code = KEY_RESTART,
.debounce_interval = TL_WR741NDV4_KEYS_DEBOUNCE_INTERVAL,
.gpio = TL_WR741NDV4_GPIO_BTN_RESET,
- .active_low = 0,
+ .active_low = 1,
}, {
.desc = WPS,
.type = EV_KEY,
@@ -134,7 +139,20 @@
u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00);
u8 *ee = (u8 *) KSEG1ADDR(0x1fff1000);
- ath79_setup_ar933x_phy4_switch(true, true);
+ if((mac[0] == 0xff)
+ (mac[1] == 0xff)
+ (mac[2] == 0xff)
+ (mac[3] == 0xff)
+ (mac[4] == 0xff)
+ (mac[5] == 0xff))
+ {
+ printk(MAC FF:FF:FF:FF:FF:FF\n);
+ memcpy(mac, ee+2, 6);
+ mac = ee+2;
+ printk(MAC %02x:%02x:%02x:%02x:%02x:%02x, mac[0], mac[1], mac[2],
mac[3], mac[4], mac[5]);
+ }
+ //ath79_setup_ar933x_phy4_switch(true, true);
+ ath79_setup_ar933x_phy4_switch(false, false);
ath79_gpio_function_disable(AR933X_GPIO_FUNC_ETH_SWITCH_LED0_EN |
AR933X_GPIO_FUNC_ETH_SWITCH_LED1_EN |
@@ -156,6 +174,11 @@
static void __init tl_wr741ndv4_setup(void)
{
tl_ap121_setup();
+
+ gpio_request_one(TL_MR3220V2_GPIO_USB_POWER,
+ GPIOF_OUT_INIT_HIGH | GPIOF_EXPORT_DIR_FIXED,
+ USB power);
+ath79_register_usb();
ath79_register_leds_gpio(-1, ARRAY_SIZE(tl_wr741ndv4_leds_gpio) - 1,
tl_wr741ndv4_leds_gpio);
Index: target/linux/ar71xx/files/drivers/mtd/tplinkpart.c
===
--- target/linux/ar71xx/files/drivers/mtd/tplinkpart.c (revision 38031)
+++ target/linux/ar71xx/files/drivers/mtd/tplinkpart.c (working copy)
@@ -149,7 +149,7 @@
parts[0].name = u-boot;
parts[0].offset = 0;
parts[0].size = offset;
- parts[0].mask_flags = MTD_WRITEABLE;
+ //parts[0].mask_flags = MTD_WRITEABLE;
parts[1].name = kernel;
parts[1].offset = offset;
@@ -159,15 +159,24 @@
parts[2].offset = rootfs_offset;
parts[2].size = art_offset - rootfs_offset;
+ parts[4].name = art;
+ parts[4].offset = art_offset;
+ parts[4].size = TPLINK_ART_LEN;
+ //part4[3].mask_flags = MTD_WRITEABLE;
+
+ parts[3].name = firmware;
+ parts[3].offset = offset;
+ parts[3].size = art_offset - offset;
+ #if 0
parts[3].name = art;
parts[3].offset = art_offset;
parts[3].size = TPLINK_ART_LEN;
- parts[3].mask_flags = MTD_WRITEABLE;
+ //parts[3].mask_flags = MTD_WRITEABLE;
parts[4].name = firmware;
parts[4].offset = offset;
parts[4].size = art_offset - offset;
-
+ #endif
vfree(header);
*pparts = parts;
Index: target/linux/ar71xx/image/Makefile
===
--- target/linux/ar71xx/image/Makefile (revision 38031)
+++ target/linux/ar71xx/image/Makefile (working copy)
@@ -921,7 +921,8 @@
$(eval $(call
SingleProfile,TPLINK-LZMA,64kraw,TLWR720NV3,tl-wr720n-v3,TL-WR720N-v3,ttyATH0,115200,0x07200103,1,4Mlzma))
$(eval $(call
SingleProfile,TPLINK-LZMA,64kraw,TLWR740NV4,tl-wr740n-v4,TL-WR741ND-v4,ttyATH0,115200,0x0744,1,4Mlzma))
$(eval $(call
