Re: [OpenWrt-Devel] kernel oops with ath9k + shared irqs
On Wednesday 12 November 2014 16:39:38 André Gaul wrote:
Hey openwrt devs!
I'm observing 100% reproducible kernel oopses with a recent openwrt
(tested with trunk and barrier breaker) on a Mikrotik Routerboard RB435
which is equipped with 5 minipci cards. The board boots up fine if all
wifi devices are disabled in /etc/config/wireless and yields the
following interrupt mapping for the wifi devices:
root@OpenWrt:~# dmesg | grep AR9280
[19.34] ieee80211 phy0: Atheros AR9280 Rev:2 mem=0xb000, irq=40
[20.96] ieee80211 phy1: Atheros AR9280 Rev:2 mem=0xb001, irq=41
[22.66] ieee80211 phy2: Atheros AR9280 Rev:2 mem=0xb002, irq=42
[24.37] ieee80211 phy3: Atheros AR9280 Rev:2 mem=0xb003, irq=41
[25.99] ieee80211 phy4: Atheros AR9280 Rev:2 mem=0xb004, irq=42
(full dmesg can be found in [1])
If the devices are enabled in /etc/config/wireless such that no
interrupt is shared (e.g., enabled phy{0,1,2}, phy{0,1,4}, phy{0,2,3},
...) the board continues to operate normally; otherwise (e.g., enabled
phy{1,3}, phy{0,1,2,3}, phy{0,1,2,3,4}, ...) it crashes with a data bus
error, cf. [2] for a full log.
Any ideas?
cheers,
André
[1] http://paste.debian.net/131446/
[2] http://paste.debian.net/131449/
It would be more meaningful if the memory addresses of (at least the top of)
the stack trace were mapped onto their symbolic names, using the System.map of
your kernel. You can do this manually or by using ksymoops or recompile your
kernel with CONFIG_KALLSYMS turned on.
Regards,
Tijs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] package/boot/uboot-envtools: retry uci-defaults on empty config
Consider an OpenWRT release for a certain board without support for uboot(-envtools). An empty config file /etc/config/uboot-env is created. Consider a new OpenWRT release with support for uboot(-envtools) added for that board. If the uci config was preserved over sysupgrade (the default), the /etc/config/uboot-env is restored at first boot and uci-defaults for uboot-envtools skips any processing, as a config already exists, failing to update the config with newly supported configuration for that board. The following patch retries uci-defaults for uboot-envtools at first boot (e.g. after sysupgrade) whenever an empty uci config file is found. Signed-off-by: Tijs Van Buggenhout t...@able.be -- diff --git a/package/boot/uboot-envtools/files/ar71xx b/package/boot/uboot-envtools/files/ar71xx index f660883..8d64d43 100644 --- a/package/boot/uboot-envtools/files/ar71xx +++ b/package/boot/uboot-envtools/files/ar71xx @@ -3,7 +3,7 @@ # Copyright (C) 2011-2014 OpenWrt.org # -[ -e /etc/config/ubootenv ] exit 0 +[ -s /etc/config/ubootenv ] exit 0 touch /etc/config/ubootenv diff --git a/package/boot/uboot-envtools/files/cns3xxx b/package/boot/uboot-envtools/files/cns3xxx index a56be15..70521ed 100644 --- a/package/boot/uboot-envtools/files/cns3xxx +++ b/package/boot/uboot-envtools/files/cns3xxx @@ -3,7 +3,7 @@ # Copyright (C) 2013 OpenWrt.org # -[ -e /etc/config/ubootenv ] exit 0 +[ -s /etc/config/ubootenv ] exit 0 touch /etc/config/ubootenv diff --git a/package/boot/uboot-envtools/files/imx6 b/package/boot/uboot-envtools/files/imx6 index fac6436..a63c8ae 100644 --- a/package/boot/uboot-envtools/files/imx6 +++ b/package/boot/uboot-envtools/files/imx6 @@ -3,7 +3,7 @@ # Copyright (C) 2013-2014 OpenWrt.org # -[ -e /etc/config/ubootenv ] exit 0 +[ -s /etc/config/ubootenv ] exit 0 touch /etc/config/ubootenv diff --git a/package/boot/uboot-envtools/files/kirkwood b/package/boot/uboot-envtools/files/kirkwood index ef6c113..ec32ec0 100644 --- a/package/boot/uboot-envtools/files/kirkwood +++ b/package/boot/uboot-envtools/files/kirkwood @@ -3,7 +3,7 @@ # Copyright (C) 2012-2014 OpenWrt.org # -[ -e /etc/config/ubootenv ] exit 0 +[ -s /etc/config/ubootenv ] exit 0 touch /etc/config/ubootenv diff --git a/package/boot/uboot-envtools/files/lantiq b/package/boot/uboot-envtools/files/lantiq index 69b375d..79526c0 100644 --- a/package/boot/uboot-envtools/files/lantiq +++ b/package/boot/uboot-envtools/files/lantiq @@ -3,7 +3,7 @@ # Copyright (C) 2012 OpenWrt.org # -[ -e /etc/config/ubootenv ] exit 0 +[ -s /etc/config/ubootenv ] exit 0 touch /etc/config/ubootenv diff --git a/package/boot/uboot-envtools/files/mvebu b/package/boot/uboot-envtools/files/mvebu index 1b1f5ff..bfec1e5 100644 --- a/package/boot/uboot-envtools/files/mvebu +++ b/package/boot/uboot-envtools/files/mvebu @@ -3,7 +3,7 @@ # Copyright (C) 2014 OpenWrt.org # -[ -e /etc/config/ubootenv ] exit 0 +[ -s /etc/config/ubootenv ] exit 0 touch /etc/config/ubootenv diff --git a/package/boot/uboot-envtools/files/mxs b/package/boot/uboot-envtools/files/mxs index ab8b4ef..ee66e8e 100644 --- a/package/boot/uboot-envtools/files/mxs +++ b/package/boot/uboot-envtools/files/mxs @@ -3,7 +3,7 @@ # Copyright (C) 2013 OpenWrt.org # -[ -e /etc/config/ubootenv ] exit 0 +[ -s /etc/config/ubootenv ] exit 0 touch /etc/config/ubootenv diff --git a/package/boot/uboot-envtools/files/ramips b/package/boot/uboot-envtools/files/ramips index 1ab6148..6dffbb6 100644 --- a/package/boot/uboot-envtools/files/ramips +++ b/package/boot/uboot-envtools/files/ramips @@ -3,7 +3,7 @@ # Copyright (C) 2011-2012 OpenWrt.org # -[ -e /etc/config/ubootenv ] exit 0 +[ -s /etc/config/ubootenv ] exit 0 touch /etc/config/ubootenv ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] package/boot/uboot-envtools: retry uci-defaults for fw_env.config
Consider a system with uboot-env at first boot after sysupgrade. By
default /etc/config/ubootenv will have been restored, which is not
the case for /etc/fw_env.config (generated, not installed by opkg).
Unfortunately fw_env.config will only be generated when
/etc/config/ubootenv is initialised (there is no uboot-env(tools)
init script. Hence the system may end up with a missing fw_env.config
after a sysupgrade:
* fw_env.config may not have existed, but now it should (added support
for board)
* fw_env.config existed, but not part of sysupgrade backup (and thus not
restored)
The following patch will retry uci-defaults for uboot-envtools when
fw_env.config is missing from sysupgrade backup, or it is empty.
Signed-off-by: Tijs Van Buggenhout t...@able.be
--
diff --git a/package/boot/uboot-envtools/files/ar71xx
b/package/boot/uboot-envtools/files/ar71xx
index 8d64d43..ea8cf72 100644
--- a/package/boot/uboot-envtools/files/ar71xx
+++ b/package/boot/uboot-envtools/files/ar71xx
@@ -3,14 +3,19 @@
# Copyright (C) 2011-2014 OpenWrt.org
#
-[ -s /etc/config/ubootenv ] exit 0
+FWC=/etc/fw_env.config
+UC=/etc/config/ubootenv
-touch /etc/config/ubootenv
+[ -s $FWC -a -s $UC ] exit 0
-. /lib/ar71xx.sh
. /lib/uboot-envtools.sh
. /lib/functions.sh
+[ -s $UC ] || {
+touch $UC
+
+. /lib/ar71xx.sh
+
board=$(ar71xx_board_name)
case $board in
@@ -45,6 +50,7 @@ qihoo-c301)
ubootenv_add_uci_config /dev/mtd9 0x0 0x1 0x1
;;
esac
+}
config_load ubootenv
config_foreach ubootenv_add_app_config ubootenv
diff --git a/package/boot/uboot-envtools/files/cns3xxx
b/package/boot/uboot-envtools/files/cns3xxx
index 70521ed..1412d3c 100644
--- a/package/boot/uboot-envtools/files/cns3xxx
+++ b/package/boot/uboot-envtools/files/cns3xxx
@@ -3,14 +3,19 @@
# Copyright (C) 2013 OpenWrt.org
#
-[ -s /etc/config/ubootenv ] exit 0
+FWC=/etc/fw_env.config
+UC=/etc/config/ubootenv
-touch /etc/config/ubootenv
+[ -s $FWC -a -s $UC ] exit 0
-. /lib/cns3xxx.sh
. /lib/uboot-envtools.sh
. /lib/functions.sh
+[ -s $UC ] || {
+touch $UC
+
+. /lib/cns3xxx.sh
+
board=$(cns3xxx_board_name)
case $board in
@@ -21,6 +26,7 @@ laguna)
ubootenv_add_uci_config /dev/mtd1 0x0 0x$size 0x$erasesize
;;
esac
+}
config_load ubootenv
config_foreach ubootenv_add_app_config ubootenv
diff --git a/package/boot/uboot-envtools/files/imx6
b/package/boot/uboot-envtools/files/imx6
index a63c8ae..5982c88 100644
--- a/package/boot/uboot-envtools/files/imx6
+++ b/package/boot/uboot-envtools/files/imx6
@@ -3,14 +3,19 @@
# Copyright (C) 2013-2014 OpenWrt.org
#
-[ -s /etc/config/ubootenv ] exit 0
+FWC=/etc/fw_env.config
+UC=/etc/config/ubootenv
-touch /etc/config/ubootenv
+[ -s $FWC -a -s $UC ] exit 0
-. /lib/imx6.sh
. /lib/uboot-envtools.sh
. /lib/functions.sh
+[ -s $UC ] || {
+touch $UC
+
+. /lib/imx6.sh
+
board=$(imx6_board_name)
case $board in
@@ -18,6 +23,7 @@ case $board in
ubootenv_add_uci_config /dev/mmcblk0 0x6 0x2000 0x2000
;;
esac
+}
config_load ubootenv
config_foreach ubootenv_add_app_config ubootenv
diff --git a/package/boot/uboot-envtools/files/kirkwood
b/package/boot/uboot-envtools/files/kirkwood
index ec32ec0..020e2f6 100644
--- a/package/boot/uboot-envtools/files/kirkwood
+++ b/package/boot/uboot-envtools/files/kirkwood
@@ -3,14 +3,19 @@
# Copyright (C) 2012-2014 OpenWrt.org
#
-[ -s /etc/config/ubootenv ] exit 0
+FWC=/etc/fw_env.config
+UC=/etc/config/ubootenv
-touch /etc/config/ubootenv
+[ -s $FWC -a -s $UC ] exit 0
-. /lib/kirkwood.sh
. /lib/uboot-envtools.sh
. /lib/functions.sh
+[ -s $UC ] || {
+touch $UC
+
+. /lib/kirkwood.sh
+
board=$(kirkwood_board_name)
case $board in
@@ -20,6 +25,7 @@ case $board in
ubootenv_add_uci_config /dev/mtd1 0x0 0x2 0x2
;;
esac
+}
config_load ubootenv
config_foreach ubootenv_add_app_config ubootenv
diff --git a/package/boot/uboot-envtools/files/lantiq
b/package/boot/uboot-envtools/files/lantiq
index 79526c0..aced7e9 100644
--- a/package/boot/uboot-envtools/files/lantiq
+++ b/package/boot/uboot-envtools/files/lantiq
@@ -3,14 +3,19 @@
# Copyright (C) 2012 OpenWrt.org
#
-[ -s /etc/config/ubootenv ] exit 0
+FWC=/etc/fw_env.config
+UC=/etc/config/ubootenv
-touch /etc/config/ubootenv
+[ -s $FWC -a -s $UC ] exit 0
-. /lib/functions/lantiq.sh
. /lib/uboot-envtools.sh
. /lib/functions.sh
+[ -s $UC ] || {
+touch $UC
+
+. /lib/functions/lantiq.sh
+
board=$(lantiq_board_name)
case $board in
@@ -21,6 +26,7 @@ BTHOMEHUBV2B)
ubootenv_add_uci_config /dev/mtd1 0x0 0x1 0x1 1
;;
esac
+}
config_load ubootenv
config_foreach ubootenv_add_app_config ubootenv
diff --git a/package/boot/uboot-envtools/files/mvebu
b/package/boot/uboot-envtools/files/mvebu
index bfec1e5..9565e5a 100644
--- a/package/boot/uboot-envtools/files/mvebu
+++ b/package/boot/uboot-envtools/files/mvebu
@@ -3,14 +3,19 @@
# Copyright (C) 2014 OpenWrt.org
#
-[ -s /etc
Re: [OpenWrt-Devel] [aa-mac80211] b43: backport bcma_core_pci_up/down from 3.12
On Friday 14 March 2014 21:25:04 Felix Fietkau wrote: On 2014-03-14 21:09, Tijs Van Buggenhout wrote: commit bbb52f346786f5ba51a58b5dc01aba297301ddfe Author: Tijs Van Buggenhout t...@able.be Date: Fri Mar 14 20:56:06 2014 +0100 Backport bcma_core_pci_up/down from 3.12 Compiling module b43 from compat-wireless-2014-01-23.1 for 3.3.8 kernel of AA results in build errors like so: [...] bcma_core_pci_up and bcma_core_pci_down are used in b43/main.c and brcmsmac/main.c, but are only introduced in kernel 3.12.0. The following patch adds a backport of these functions for earlier kernel versions. Tested patch on b43 and ath9k driver. Signed-off-by: Tijs Van Buggenhout t...@able.be The missing functions have already been committed as a kernel patch to the AA tree, and the mac80211 backport itself has been committed to AA as well. - Felix Wonderful! Missed that about a few hours. Creating patches takes too much time :-/ Should these changes already be part of backport or am I just looking at the wrong git repo? Tijs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [aa-mac80211] b43: backport bcma_core_pci_up/down from 3.12
On Tuesday 18 March 2014 10:46:44 Felix Fietkau wrote: On 2014-03-18 10:39, Tijs Van Buggenhout wrote: On Friday 14 March 2014 21:25:04 Felix Fietkau wrote: On 2014-03-14 21:09, Tijs Van Buggenhout wrote: commit bbb52f346786f5ba51a58b5dc01aba297301ddfe Author: Tijs Van Buggenhout t...@able.be Date: Fri Mar 14 20:56:06 2014 +0100 Backport bcma_core_pci_up/down from 3.12 Compiling module b43 from compat-wireless-2014-01-23.1 for 3.3.8 kernel of AA results in build errors like so: [...] bcma_core_pci_up and bcma_core_pci_down are used in b43/main.c and brcmsmac/main.c, but are only introduced in kernel 3.12.0. The following patch adds a backport of these functions for earlier kernel versions. Tested patch on b43 and ath9k driver. Signed-off-by: Tijs Van Buggenhout t...@able.be The missing functions have already been committed as a kernel patch to the AA tree, and the mac80211 backport itself has been committed to AA as well. - Felix Wonderful! Missed that about a few hours. Creating patches takes too much time :-/ Should these changes already be part of backport or am I just looking :at the wrong git repo? The change is part of the AA kernel patches in target/linux, not the backport git. - Felix I saw @r39926, just wondering where the backports came from and whether I should have seen them before ;-) Tijs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [aa-mac80211] b43: backport bcma_core_pci_up/down from 3.12
commit bbb52f346786f5ba51a58b5dc01aba297301ddfe
Author: Tijs Van Buggenhout t...@able.be
Date: Fri Mar 14 20:56:06 2014 +0100
Backport bcma_core_pci_up/down from 3.12
Compiling module b43 from compat-wireless-2014-01-23.1 for 3.3.8 kernel
of AA results in build errors like so:
CC [M] /attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/compat/backpor
t-3.13.o
CC [M] /attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/compat/dma-sha
red-helpers.o
LD [M] /attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/compat/compat.
o
CC [M] /attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/drivers/net/wi
reless/b43/main.o
/attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/drivers/net/wireless/b43
/main.c: In function 'b43_wireless_core_exit':
/attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/drivers/net/wireless/b43
/main.c:4680:3: error: implicit declaration of function 'bcma_core_pci_down'
[-Werror=implicit-function-declaration]
/attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/drivers/net/wireless/b43
/main.c: In function 'b43_wireless_core_init':
/attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/drivers/net/wireless/b43
/main.c:4729:3: error: implicit declaration of function 'bcma_core_pci_up' [-
Werror=implicit-function-declaration]
cc1: some warnings being treated as errors
make[9]: *** [/attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/drivers/ne
t/wireless/b43/main.o] Error 1
make[8]: *** [/attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/drivers/ne
t/wireless/b43] Error 2
make[7]: *** [/attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/drivers/ne
t/wireless] Error 2
make[6]: *** [_module_/attitude_adjustment-12.09/build_dir/linux-
brcm47xx/compat-wireless-2014-01-23.1] E
rror 2
make[5]: *** [modules] Error 2
make[4]: *** [modules] Error 2
make[3]: *** [modules] Error 2
make[3]: Leaving directory `/attitude_adjustment-12.09/build_dir/linux-
brcm47xx/compat-wireless-2014-01-2
3.1'
make[2]: *** [/attitude_adjustment-12.09/build_dir/linux-brcm47xx/compat-
wireless-2014-01-23.1/.built] Er
ror 2
make[2]: Leaving directory `/attitude_adjustment-12.09/package/mac80211'
make[1]: *** [package/mac80211/compile] Error 2
make[1]: Leaving directory `/attitude_adjustment-12.09'
make: *** [package/mac80211/compile] Error 2
bcma_core_pci_up and bcma_core_pci_down are used in b43/main.c and
brcmsmac/main.c, but are only introduced in kernel 3.12.0. The following patch
adds a backport of these functions for earlier kernel versions. Tested patch
on b43 and ath9k driver.
Signed-off-by: Tijs Van Buggenhout t...@able.be
--
diff --git a/mac80211/patches/848-b43-bcma_core_pci_up_down-backport.patch
b/mac80211/patches/848-b43-bcma_core_pci_up_down-backport.patch
new file mode 100644
index 000..bbeb62e
--- /dev/null
+++ b/mac80211/patches/848-b43-bcma_core_pci_up_down-backport.patch
@@ -0,0 +1,53 @@
+--- a/compat/backport-3.12.c
b/compat/backport-3.12.c
+@@ -27,3 +27,33 @@ u8 *hid_alloc_report_buf(struct hid_repo
+ return kmalloc(len, flags);
+ }
+ EXPORT_SYMBOL_GPL(hid_alloc_report_buf);
++
++#if defined(CONFIG_BCMA) || defined(CONFIG_BCMA_MODULE)
++#include linux/bcma/bcma.h
++
++void bcma_core_pci_up(struct bcma_bus *bus)
++{
++ struct bcma_drv_pci *pc;
++
++ if (bus-hosttype != BCMA_HOSTTYPE_PCI)
++ return;
++
++ pc = bus-drv_pci[0];
++
++ bcma_core_pci_extend_L1timer(pc, true);
++}
++EXPORT_SYMBOL_GPL(bcma_core_pci_up);
++
++void bcma_core_pci_down(struct bcma_bus *bus)
++{
++ struct bcma_drv_pci *pc;
++
++ if (bus-hosttype != BCMA_HOSTTYPE_PCI)
++ return;
++
++ pc = bus-drv_pci[0];
++
++ bcma_core_pci_extend_L1timer(pc, false);
++}
++EXPORT_SYMBOL_GPL(bcma_core_pci_down);
++#endif
+--- /dev/null
b/backport-include/linux/bcma/bcma_driver_pci.h
+@@ -0,0 +1,14 @@
++#ifndef __BACKPORT_BCMA_DRIVER_PCI_H
++#define __BACKPORT_BCMA_DRIVER_PCI_H
++#include_next linux/bcma/bcma_driver_pci.h
++#include linux/version.h
++
++#if LINUX_VERSION_CODE KERNEL_VERSION(3,12,0)
++struct bcma_bus;
++#define bcma_core_pci_up LINUX_BACKPORT(bcma_core_pci_up)
++extern void bcma_core_pci_up(struct bcma_bus *bus);
++#define bcma_core_pci_down LINUX_BACKPORT(bcma_core_pci_down)
++extern void bcma_core_pci_down(struct bcma_bus *bus);
++#endif
++
++#endif /* __BACKPORT_BCMA_DRIVER_PCI_H */
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH][feeds] openvpn-devel: make openvpn compatible with polarssl 1.2.3 or newer [AA]
Only relevant for Attitude Adjustment, see trac #12982 [1].
Commit r35529 [2] upgrades polarssl from v 1.1(.3) to 1.2(.5), but introduces
compile errors for openvpn-devel (2.2.2) package present in feeds, as detailed
in [1].
The following small patch [3] fixes these compatibility issues.
[1]. https://dev.openwrt.org/ticket/12983
[2]. https://dev.openwrt.org/changeset/35529
[3]. http://community.openvpn.net/openvpn/attachment/ticket/250/220-allow-
polarssl-1.2.3.patch
Signed-off-by: Tijs Van Buggenhout t...@able.be
--
Index: net/openvpn-devel/Makefile
===
diff --git a/branches/packages_12.09/net/openvpn-devel/Makefile
b/branches/packages_12.09/net/openvpn-devel/Makefile
--- a/branches/packages_12.09/net/openvpn-devel/Makefile(revision 39304)
+++ b/branches/packages_12.09/net/openvpn-devel/Makefile(working copy)
@@ -11,7 +11,7 @@
PKG_REV:=5d4f5435a421299ed047485d8d99bdf9a0d22fd1
PKG_VERSION:=r$(PKG_REV)
-PKG_RELEASE=1
+PKG_RELEASE=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git
Index: net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
===
diff --git
a/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
b/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
new file mode 10644
--- /dev/null (revision 0)
+++
b/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
(working copy)
@@ -0,0 +1,82 @@
+--- a/src/openvpn/crypto_polarssl.h
b/src/openvpn/crypto_polarssl.h
+@@ -60,7 +60,11 @@
+ #define OPENVPN_MODE_OFB POLARSSL_MODE_OFB
+
+ /** Cipher is in CFB mode */
++#if POLARSSL_VERSION_NUMBER 0x0102
+ #define OPENVPN_MODE_CFB POLARSSL_MODE_CFB128
++#else
++#define OPENVPN_MODE_CFB POLARSSL_MODE_CFB
++#endif
+
+ /** Cipher should encrypt */
+ #define OPENVPN_OP_ENCRYPTPOLARSSL_ENCRYPT
+--- a/src/openvpn/ssl_polarssl.c
b/src/openvpn/ssl_polarssl.c
+@@ -67,6 +67,20 @@
+
+ static int default_ciphersuites[] =
+ {
++#if POLARSSL_VERSION_NUMBER = 0x0102
++TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
++TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
++TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
++TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
++TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
++TLS_RSA_WITH_AES_256_CBC_SHA,
++TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,
++TLS_RSA_WITH_AES_128_CBC_SHA,
++TLS_RSA_WITH_CAMELLIA_128_CBC_SHA,
++TLS_RSA_WITH_3DES_EDE_CBC_SHA,
++TLS_RSA_WITH_RC4_128_SHA,
++TLS_RSA_WITH_RC4_128_MD5,
++#else
+ SSL_EDH_RSA_AES_256_SHA,
+ SSL_EDH_RSA_CAMELLIA_256_SHA,
+ SSL_EDH_RSA_AES_128_SHA,
+@@ -79,6 +93,7 @@
+ SSL_RSA_DES_168_SHA,
+ SSL_RSA_RC4_128_SHA,
+ SSL_RSA_RC4_128_MD5,
++#endif
+ 0
+ };
+
+@@ -515,7 +530,9 @@
+ ssl_set_rng (ks_ssl-ctx, ctr_drbg_random, rand_ctx_get());
+
+ ALLOC_OBJ_CLEAR (ks_ssl-ssn, ssl_session);
++#if POLARSSL_VERSION_NUMBER 0x0102
+ ssl_set_session (ks_ssl-ctx, 0, 0, ks_ssl-ssn );
++#endif
+ if (ssl_ctx-allowed_ciphers)
+ ssl_set_ciphersuites (ks_ssl-ctx, ssl_ctx-allowed_ciphers);
+ else
+@@ -828,7 +845,11 @@
+ ssl_get_version (ks_ssl-ctx),
+ ssl_get_ciphersuite(ks_ssl-ctx));
+
++#if POLARSSL_VERSION_NUMBER = 0x0102
++ cert = ks_ssl-ssn-peer_cert;
++#else
+ cert = ks_ssl-ctx-peer_cert;
++#endif
+ if (cert != NULL)
+ {
+ openvpn_snprintf (s2, sizeof (s2), , counter_format bit RSA,
(counter_type) cert-rsa.len * 8);
+--- a/src/openvpn/options.c
b/src/openvpn/options.c
+@@ -827,7 +827,12 @@
+ o-server_poll_timeout = 0;
+ #endif
+ #ifdef ENABLE_CRYPTO
++#ifdef ENABLE_CRYPTO_POLARSSL
++ o-ciphername = BLOWFISH-CBC;
++ o-keysize = 16;
++#else
+ o-ciphername = BF-CBC;
++#endif
+ o-ciphername_defined = true;
+ o-authname = SHA1;
+ o-authname_defined = true;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH][feeds] openvpn-devel: make openvpn compatible with polarssl 1.2.3 or newer [AA]
On Wednesday 22 January 2014 15:34:56 Tijs Van Buggenhout wrote:
Only relevant for Attitude Adjustment, see trac #12982 [1].
Commit r35529 [2] upgrades polarssl from v 1.1(.3) to 1.2(.5), but
introduces compile errors for openvpn-devel (2.2.2) package present in
version of openvpn is 2.3_alpha3, sorry for that
feeds, as detailed in [1].
The following small patch [3] fixes these compatibility issues.
[1]. https://dev.openwrt.org/ticket/12983
[2]. https://dev.openwrt.org/changeset/35529
[3]. http://community.openvpn.net/openvpn/attachment/ticket/250/220-allow-
polarssl-1.2.3.patch
Signed-off-by: Tijs Van Buggenhout t...@able.be
--
The same ticket holds a more complete patch [4].
[4].
http://community.openvpn.net/openvpn/attachment/ticket/250/freetz.org-openvpn-2.3.0-polarssl-1.2.x-support.patch
Signed-off-by: Tijs Van Buggenhout t...@able.be
--
Index: net/openvpn-devel/Makefile
===
diff --git a/branches/packages_12.09/net/openvpn-devel/Makefile
b/branches/packages_12.09/net/openvpn-devel/Makefile
--- a/branches/packages_12.09/net/openvpn-devel/Makefile(revision 39304)
+++ b/branches/packages_12.09/net/openvpn-devel/Makefile(working copy)
@@ -11,7 +11,7 @@
PKG_REV:=5d4f5435a421299ed047485d8d99bdf9a0d22fd1
PKG_VERSION:=r$(PKG_REV)
-PKG_RELEASE=1
+PKG_RELEASE=2
PKG_SOURCE_PROTO:=git
PKG_SOURCE_URL:=git://openvpn.git.sourceforge.net/gitroot/openvpn/openvpn.git
Index: net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
===
diff --git
a/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
b/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
new file mode 10644
--- /dev/null (revision 0)
+++
b/branches/packages_12.09/net/openvpn-devel/patches/010-allow-polarssl-1.2.3.patch
(working copy)
@@ -0,0 +1,185 @@
+--- a/src/openvpn/crypto_polarssl.h
b/src/openvpn/crypto_polarssl.h
+@@ -60,7 +60,11 @@
+ #define OPENVPN_MODE_OFB POLARSSL_MODE_OFB
+
+ /** Cipher is in CFB mode */
++#if POLARSSL_VERSION_NUMBER 0x0102
+ #define OPENVPN_MODE_CFB POLARSSL_MODE_CFB128
++#else
++#define OPENVPN_MODE_CFB POLARSSL_MODE_CFB
++#endif
+
+ /** Cipher should encrypt */
+ #define OPENVPN_OP_ENCRYPTPOLARSSL_ENCRYPT
+--- a/src/openvpn/options.c
b/src/openvpn/options.c
+@@ -827,7 +827,12 @@
+ o-server_poll_timeout = 0;
+ #endif
+ #ifdef ENABLE_CRYPTO
++#ifdef ENABLE_CRYPTO_POLARSSL
++ o-ciphername = BLOWFISH-CBC;
++ o-keysize = 16;
++#else
+ o-ciphername = BF-CBC;
++#endif
+ o-ciphername_defined = true;
+ o-authname = SHA1;
+ o-authname_defined = true;
+--- a/src/openvpn/ssl_polarssl.h
b/src/openvpn/ssl_polarssl.h
+@@ -30,6 +30,7 @@
+ #ifndef SSL_POLARSSL_H_
+ #define SSL_POLARSSL_H_
+
++#include polarssl/version.h
+ #include polarssl/ssl.h
+
+ #if defined(ENABLE_PKCS11)
+@@ -73,7 +74,9 @@
+
+ struct key_state_ssl {
+ ssl_context *ctx;
++#if POLARSSL_VERSION_NUMBER 0x0102
+ ssl_session *ssn;
++#endif
+ endless_buffer *ct_in;
+ endless_buffer *ct_out;
+ };
+--- a/src/openvpn/ssl_polarssl.c
b/src/openvpn/ssl_polarssl.c
+@@ -65,6 +65,7 @@
+ {
+ }
+
++#if POLARSSL_VERSION_NUMBER 0x0102000
+ static int default_ciphersuites[] =
+ {
+ SSL_EDH_RSA_AES_256_SHA,
+@@ -81,6 +82,7 @@
+ SSL_RSA_RC4_128_MD5,
+ 0
+ };
++#endif
+
+ void
+ tls_ctx_server_new(struct tls_root_ctx *ctx)
+@@ -514,12 +516,18 @@
+
+ ssl_set_rng (ks_ssl-ctx, ctr_drbg_random, rand_ctx_get());
+
++#if POLARSSL_VERSION_NUMBER 0x0102
+ ALLOC_OBJ_CLEAR (ks_ssl-ssn, ssl_session);
+ ssl_set_session (ks_ssl-ctx, 0, 0, ks_ssl-ssn );
++#endif
+ if (ssl_ctx-allowed_ciphers)
+ ssl_set_ciphersuites (ks_ssl-ctx, ssl_ctx-allowed_ciphers);
+ else
++#if POLARSSL_VERSION_NUMBER 0x0102
+ ssl_set_ciphersuites (ks_ssl-ctx, default_ciphersuites);
++#else
++ ssl_set_ciphersuites (ks_ssl-ctx, ssl_default_ciphersuites);
++#endif
+
+ /* Initialise authentication information */
+ if (is_server)
+@@ -556,8 +564,10 @@
+ ssl_free(ks_ssl-ctx);
+ free(ks_ssl-ctx);
+ }
++#if POLARSSL_VERSION_NUMBER 0x0102
+ if (ks_ssl-ssn)
+ free(ks_ssl-ssn);
++#endif
+ if (ks_ssl-ct_in) {
+ buf_free_entries(ks_ssl-ct_in);
+ free(ks_ssl-ct_in);
+@@ -818,7 +828,7 @@
+ void
+ print_details (struct key_state_ssl * ks_ssl, const char *prefix)
+ {
+- x509_cert *cert;
++ const x509_cert *cert;
+ char s1[256];
+ char s2[256];
+
+@@ -828,7 +838,11 @@
+ ssl_get_version (ks_ssl-ctx),
+ ssl_get_ciphersuite(ks_ssl-ctx));
+
++#if POLARSSL_VERSION_NUMBER 0x0102
+ cert = ks_ssl-ctx-peer_cert;
++#else
++ cert = ssl_get_peer_cert(ks_ssl-ctx);
++#endif
+ if (cert != NULL)
+ {
+ openvpn_snprintf (s2
Re: [OpenWrt-Devel] Updating vlan interface link on switch port link change?
On Wednesday 18 December 2013 21:37:40 Rafał Miłecki wrote: 2013/12/18 Rafał Miłecki zaj...@gmail.com: Some routers (a lot of/all Broadcom's BCM47xx based models) have only a one network card attached to a switch. In such situation you usually use one VLAN for WAN port and another VLAN for LAN ports. The problem is that WAN is a virtual VLAN interface and it's always up. Even if I disconnect ethernet cable from the WAN, eth0.X is still up. Do you have any idea how this could be improved? Could we for example keep a list of VLANs with only one port assigned and adjust VLAN interface state to match current port state? Is this the right thing to do? How otherwise we can know that WAN is disconnected/not working? Or maybe you have some other idea how we can handle refreshing IP address on VLAN interface? Currently once-assigned IP doesn't change until I restart network manually. http://0pointer.de/lennart/projects/ifplugd/ In openwrt: CONFIG_BUSYBOX_CONFIG_IFPLUGD or DHCP is unaware of any link changes, it will only renegotiate DHCP lease when lease time has elapsed.. so you could set dhcp lease time shorter (if you have control over DHCP server), like every 1 (or 5) minutes... that way (longer) link interrupts are caught more quickly by the DHCP daemon. Tijs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Quick hack for kernel entropy problem on MIPS
On Monday 18 November 2013 19:29:17 mancha wrote:
Hauke Mehrtens hauke at hauke-m.de writes:
On 10/17/2013 05:40 PM, chrono wrote:
Ahoi everyone,
it was requested on IRC that I send my solution to the entropy problem
with the current
kernel (e.g. having 0 available entropy):
root at OpenWrt:/# cat /proc/sys/kernel/random/entropy_avail
0
A similar patch was applied to trunk in r38834.
Hauke
I provided this backport patch to #openwrt on freenode last week. I am
glad it was included in trunk.
Two important clarifications:
1. The original poster applies his patch to kernel 3.3.8 (it seems) yet
the interface that makes use of get_cycles() in seeding the random
pool wasn't introduced until 3.6. The patch on pre-3.6 kernels
effectively does nothing entropy-wise. Without more comprehensive
backports, there is no similar simple solution for Attitude.
This seems not entirely accurate, as AA has a backport patch for the generic
3.3.8 kernel to add 'add_device_randomness', see
target/linux/generic/patches-3.3/050-rng_git_backport.patch
--- a/drivers/char/random.c
+++ b/drivers/char/random.c
@@ -125,21 +125,26 @@
* The current exported interfaces for gathering environmental noise
* from the devices are:
*
+ * void add_device_randomness(const void *buf, unsigned int size);
* void add_input_randomness(unsigned int type, unsigned int code,
*unsigned int value);
- * void add_interrupt_randomness(int irq);
+ * void add_interrupt_randomness(int irq, int irq_flags);
...
+/*
+ * Add device- or boot-specific data to the input and nonblocking
+ * pools to help initialize them to unique values.
+ *
+ * None of this adds any entropy, it is meant to avoid the
+ * problem of the nonblocking pool having similar initial state
+ * across largely identical devices.
+ */
+void add_device_randomness(const void *buf, unsigned int size)
+{
+ unsigned long time = get_cycles() ^ jiffies;
+
+ mix_pool_bytes(input_pool, buf, size, NULL);
...
Would there be anything else needed?
2. You aren't going to see /proc/sys/kernel/random/entropy_avail
affected by this patch because the machine/boot specific seeding
does not credit the entropy count.
--mancha
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Tijs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] mac82011 550-ath9k_entropy_from_adc.patch backport AA - questions
On Thursday 05 December 2013 22:56:01 you wrote:
On 2013-12-05 22:41, Tijs Van Buggenhout wrote:
Hi Felix,
I have a question about https://dev.openwrt.org/changeset/38486. While
backporting the aforementioned patch from trunk to attitude adjustment, I
noticed that the patch does not include a gettor function for the adc
entropy of the ar9002 chip, only those of ar5008 and ar9003.
static void ar9003_hw_get_adc_entropy(struct ath_hw *ah, u8 *buf, size_t
len) static void ar5008_hw_get_adc_entropy(struct ath_hw *ah, u8 *buf,
size_t len)
but no
static void ar9002_hw_get_adc_entropy(struct ath_hw *ah, u8 *buf, size_t
len)
Furthermore, when the phy_ops are constructed in ar9002_hw_attach_phy_ops,
the get_adc_entropy function pointer is never assigned.
I can be wrong ofcourse, but am under the impression this will create a
problem when the driver is probed for an ar9002 chip and possibly result
in a kernel oops, because ath9k_hw_get_adc_entropy expects the ath_hw
struct to have a valid (non-NULL) function pointer for get_adc_entropy.
See below:
static inline void ath9k_hw_get_adc_entropy(struct ath_hw *ah,
u8 *buf, size_t len)
{
ath9k_hw_ops(ah)-get_adc_entropy(ah, buf, len);
}
Did changes in ar9002_phy.c somehow miss inclusion in the patch?
ar5008_hw_attach_phy_ops is called for all chips older than AR9003, and
it is generic enough to work across that range of chips.
Ah yes, I see what you mean in ar9002_hw_attach_ops
ret = ar5008_hw_attach_phy_ops(ah);
if (ret)
return ret;
if (AR_SREV_9280_20_OR_LATER(ah))
ar9002_hw_attach_phy_ops(ah);
Missed that.. I assumed hw_attach_phy_ops was specific for every chip.
When testing the backported patch for my ar9003 chip, I was confronted
with a kernel oops at initialisation, which I narrowed down to
ath9k_hw_reset function, called from ath_get_initial_entropy, where the
channels in ieee80211_conf data field in common hardware config are not
yet initialised it seems. I changed the condition to verify for a valid
pointer before dereferencing it, which seems to solve the problem.
This is different in the mac82011 version from trunk (compat-
wireless-2013-11-05), where channelFlags from channel are used in the
condition, which is an u32, and thus can not result in a null pointer
dereference. My question now is, although the fix seems sufficient, is it
also correct/expected behaviour?
The patch assumes that ah-curchan is left initializes after the tx
power limit test.
In ath9k_init_txpower_limits, the new version has this code:
if (curchan)
ah-curchan = curchan;
I think the old version probably overwrites ah-curchan without checking
for NULL.
This is part of the entropy patch, which I included in the backport aswell..
diff -u -Naur a/drivers/net/wireless/ath/ath9k/init.c
b/drivers/net/wireless/ath/ath9k/init.c
--- a/drivers/net/wireless/ath/ath9k/init.c 2013-10-28 18:00:58.0
+0100
+++ b/drivers/net/wireless/ath/ath9k/init.c 2013-12-05 21:09:55.0
+0100
@@ -735,7 +735,8 @@
if (ah-caps.hw_caps ATH9K_HW_CAP_5GHZ)
ath9k_init_band_txpower(sc, IEEE80211_BAND_5GHZ);
- ah-curchan = curchan;
+ if (curchan)
+ ah-curchan = curchan;
}
void ath9k_reload_chainmask_settings(struct ath_softc *sc)
@@ -880,6 +881,19 @@
but the problem is in struct ieee80211_conf, part of hw common config, which
is not yet initialised when ath_get_initial_entropy is called from
ath9k_init_device..
--- a/drivers/net/wireless/ath/ath9k/hw.c 2013-10-28 18:00:58.0
+0100
+++ b/drivers/net/wireless/ath/ath9k/hw.c 2013-12-05 21:05:25.0
+0100
@@ -131,8 +131,8 @@
static void ath9k_hw_set_clockrate(struct ath_hw *ah)
{
- struct ieee80211_conf *conf = ath9k_hw_common(ah)-hw-conf;
struct ath_common *common = ath9k_hw_common(ah);
+ struct ieee80211_conf *conf = common-hw-conf;
unsigned int clockrate;
/* AR9287 v1.3+ uses async FIFO and runs the MAC at 117 MHz */
@@ -140,7 +140,7 @@
clockrate = 117;
else if (!ah-curchan) /* should really check for CCK instead */
clockrate = ATH9K_CLOCK_RATE_CCK;
- else if (conf-chandef.chan-band == IEEE80211_BAND_2GHZ)
+ else if (conf-chandef.chan conf-chandef.chan-band ==
IEEE80211_BAND_2GHZ)
In ath9k_hw_reset, I experienced the problem with ath9k_hw_set_clockrate(ah)
at line 1998, a few lines later (2008) in ath9k_hw_init_global_settings(ah) I
see the same kind of null condition check I introduced in
ath9k_hw_set_clockrate:
/*
* Workaround for early ACK timeouts, add an offset to match the
* initval's 64us ack timeout value. Use 48us for the CTS timeout.
* This was initially only meant to work around an issue with delayed
[OpenWrt-Devel] [PATCH] mac82011 550-ath9k_entropy_from_adc.patch backport AA - questions
Hi Felix,
I have a question about https://dev.openwrt.org/changeset/38486. While
backporting the aforementioned patch from trunk to attitude adjustment, I
noticed that the patch does not include a gettor function for the adc entropy
of the ar9002 chip, only those of ar5008 and ar9003.
static void ar9003_hw_get_adc_entropy(struct ath_hw *ah, u8 *buf, size_t len)
static void ar5008_hw_get_adc_entropy(struct ath_hw *ah, u8 *buf, size_t len)
but no
static void ar9002_hw_get_adc_entropy(struct ath_hw *ah, u8 *buf, size_t len)
Furthermore, when the phy_ops are constructed in ar9002_hw_attach_phy_ops, the
get_adc_entropy function pointer is never assigned.
I can be wrong ofcourse, but am under the impression this will create a
problem when the driver is probed for an ar9002 chip and possibly result in a
kernel oops, because ath9k_hw_get_adc_entropy expects the ath_hw struct to
have a valid (non-NULL) function pointer for get_adc_entropy. See below:
static inline void ath9k_hw_get_adc_entropy(struct ath_hw *ah,
u8 *buf, size_t len)
{
ath9k_hw_ops(ah)-get_adc_entropy(ah, buf, len);
}
Did changes in ar9002_phy.c somehow miss inclusion in the patch?
When testing the backported patch for my ar9003 chip, I was confronted with a
kernel oops at initialisation, which I narrowed down to ath9k_hw_reset
function, called from ath_get_initial_entropy, where the channels in
ieee80211_conf data field in common hardware config are not yet initialised it
seems. I changed the condition to verify for a valid pointer before
dereferencing it, which seems to solve the problem.
This is different in the mac82011 version from trunk (compat-
wireless-2013-11-05), where channelFlags from channel are used in the
condition, which is an u32, and thus can not result in a null pointer
dereference. My question now is, although the fix seems sufficient, is it also
correct/expected behaviour?
This is the backport of the patch thus far. I included the changes for the
ar9002 chip. I would expect the implementation for get_adc_entropy for ar9002
to be close(r) to ar9003, but since ar5008 depends on defines from
ar9002_phy.h and the latter are missing those from ar9003_phy.h, I copied the
implementation for ar5008 to ar9002, which may be very wrong ofcourse
(untested, as I have no ar9002 chip). The patch/driver does work for me now
(char buf being filled with entropy).
Signed-off-by: Tijs Van Buggenhout t...@able.be
--
diff -u -Naur a/drivers/net/wireless/ath/ath9k/hw.h
b/drivers/net/wireless/ath/ath9k/hw.h
--- a/drivers/net/wireless/ath/ath9k/hw.h 2013-10-28 18:00:58.0
+0100
+++ b/drivers/net/wireless/ath/ath9k/hw.h 2013-11-19 13:32:56.0
+0100
@@ -700,6 +700,7 @@
* @config_pci_powersave:
* @calibrate: periodic calibration for NF, ANI, IQ, ADC gain, ADC-DC
*
+ * @get_adc_entropy: get entropy from the raw ADC I/Q output
* @spectral_scan_config: set parameters for spectral scan and enable/disable
it
* @spectral_scan_trigger: trigger a spectral scan run
* @spectral_scan_wait: wait for a spectral scan run to finish
@@ -722,6 +723,7 @@
struct ath_hw_antcomb_conf *antconf);
void (*antdiv_comb_conf_set)(struct ath_hw *ah,
struct ath_hw_antcomb_conf *antconf);
+ void (*get_adc_entropy)(struct ath_hw *ah, u8 *buf, size_t len);
void (*antctrl_shared_chain_lnadiv)(struct ath_hw *hw, bool enable);
void (*spectral_scan_config)(struct ath_hw *ah,
struct ath_spec_scan *param);
diff -u -Naur a/drivers/net/wireless/ath/ath9k/hw.c
b/drivers/net/wireless/ath/ath9k/hw.c
--- a/drivers/net/wireless/ath/ath9k/hw.c 2013-10-28 18:00:58.0
+0100
+++ b/drivers/net/wireless/ath/ath9k/hw.c 2013-12-05 21:05:25.0
+0100
@@ -131,8 +131,8 @@
static void ath9k_hw_set_clockrate(struct ath_hw *ah)
{
- struct ieee80211_conf *conf = ath9k_hw_common(ah)-hw-conf;
struct ath_common *common = ath9k_hw_common(ah);
+ struct ieee80211_conf *conf = common-hw-conf;
unsigned int clockrate;
/* AR9287 v1.3+ uses async FIFO and runs the MAC at 117 MHz */
@@ -140,7 +140,7 @@
clockrate = 117;
else if (!ah-curchan) /* should really check for CCK instead */
clockrate = ATH9K_CLOCK_RATE_CCK;
- else if (conf-chandef.chan-band == IEEE80211_BAND_2GHZ)
+ else if (conf-chandef.chan conf-chandef.chan-band ==
IEEE80211_BAND_2GHZ)
clockrate = ATH9K_CLOCK_RATE_2GHZ_OFDM;
else if (ah-caps.hw_caps ATH9K_HW_CAP_FASTCLOCK)
clockrate = ATH9K_CLOCK_FAST_RATE_5GHZ_OFDM;
diff -u -Naur a/drivers/net/wireless/ath/ath9k/ar9003_phy.c
b/drivers/net/wireless/ath/ath9k/ar9003_phy.c
--- a/drivers/net/wireless/ath/ath9k/ar9003_phy.c 2013-10-28
18:00:58.0 +0100
+++ b/drivers/net/wireless/ath/ath9k/ar9003_phy.c 2013-12-05
19:09
[OpenWrt-Devel] [PATCH] [packages] ppp: correct module loaded check in proto_pptp_setup
proto_pptp_setup is responsible for loading the required modules to establish
a pptp connection to a foreign peer. The function checks whether all required
modules are already loaded, before actually loading them.
It seems that the filter being used to accomplish this, is not restrictive
enough in some cases. For instance when pptp nat helper modules are present on
a system, and already loaded before a pptp connection is enabled. Then the
search filter (possibly) returns the following for module=pptp, where actually
no matches are expected, resulting in the pptp.ko module not being loaded,
thereby failing to establish the pptp connection.
# module=pptp ; grep $module /proc/modules
nf_nat_pptp 1312 0 - Live 0x86ce7000
nf_conntrack_pptp 3072 1 nf_nat_pptp, Live 0x86cb9000
nf_nat_proto_gre 784 1 nf_nat_pptp, Live 0x86cba000
nf_conntrack_proto_gre 2368 1 nf_conntrack_pptp, Live 0x86cbf000
nf_nat 9792 13
nf_nat_rtsp,nf_nat_tftp,nf_nat_sip,nf_nat_pptp,nf_nat_h323,nf_nat_proto_gre,nf_nat_amanda,nf_nat_irc,nf_nat_ftp,ipt_REDIRECT,ipt_NETMAP,ipt_MASQUERADE,iptable_nat,
Live 0x86ca8000
nf_conntrack 37264 31
nf_nat_rtsp,nf_conntrack_rtsp,nf_nat_tftp,nf_conntrack_tftp,nf_nat_snmp_basic,nf_conntrack_snmp,nf_nat_sip,nf_conntrack_sip,nf_nat_pptp,nf_conntrack_pptp,nf_nat_h323,nf_conntrack_h323,nf_conntrack_proto_gre,nf_nat_amanda,nf_conntrack_amanda,nf_conntrack_broadcast,nf_nat_irc,nf_conntrack_irc,nf_nat_ftp,nf_conntrack_ftp,ipt_MASQUERADE,iptable_nat,nf_nat,xt_helper,xt_connmark,xt_connbytes,xt_conntrack,xt_CT,xt_NOTRACK,xt_state,nf_conntrack_ipv4,
Live 0x86c9
The search filter can be made more accurate/restrictive, by requiring the
occurance of the exact name of the module at the beginning of a line in
/proc/modules.
# module=pptp ; grep ^$module /proc/modules
pptp 13296 2 - Live 0x86e8
Signed-off-by: Tijs Van Buggenhout t...@able.be
--
package/network/services/ppp/files/ppp.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/network/services/ppp/files/ppp.sh
b/package/network/services/ppp/files/ppp.sh
index 43a7de9..02b4055 100755
--- a/package/network/services/ppp/files/ppp.sh
+++ b/package/network/services/ppp/files/ppp.sh
@@ -190,7 +190,7 @@ proto_pptp_setup() {
local load
for module in slhc ppp_generic ppp_async ppp_mppe ip_gre gre pptp; do
- grep -q $module /proc/modules continue
+ grep -q ^$module /proc/modules continue
/sbin/insmod $module 2- -
load=1
done
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kmod-switch : Fix led control register - adjust IMP port status
On Wednesday 27 February 2013 14:49:58 Tijs Van Buggenhout wrote:
On Monday 25 February 2013 21:30:07 Tijs Van Buggenhout wrote:
On Monday 25 February 2013 21:07:09 Hauke Mehrtens wrote:
On 02/25/2013 03:08 PM, Tijs Van Buggenhout wrote:
On Monday 25 February 2013 14:06:13 Jonas Gorski wrote:
On 21 February 2013 15:53, Hauke Mehrtens ha...@hauke-m.de wrote:
On 02/21/2013 02:57 PM, Tijs Van Buggenhout wrote:
From linksys firmware :
# et -i eth0 robord 0x0 0x0e
0x008b
# et -i eth0 robord 0x0 0x12
0x020b
root@OpenWrt:/# robocfg robord 0x0e
Page 0x00, Reg 0x0e: 00bb
root@OpenWrt:/# robocfg robord 0x12
Page 0x00, Reg 0x12: 0321
1. Fix led control register:
On normal ports only one led was used for both link and activity
(green),
internet port additionally had orange led on all the time.
I compared the value of registry 0x12 on linksys firmware vs
openwrt,
and
it showed a different value (0x20b for linksys vs 0x321 on
openwrt).
Now the green led is always used to signal link, the orange led
(only)
blinks on link activity.
2. Adjust IMP port status
As I was comparing register values/bcmrobo.c source code, I noticed
a
difference for the IMP port status register (0x0e), linksys
firmware
showed
0x8b vs 0xbb for openwrt.
From bcmrobo.c - int bcm_robo_enable_switch:
if ((robo-devid == DEVID53115) || (robo-devid ==
DEVID53125))
{
/* Over ride IMP port status to make it link by
default
*/
val8 = 0;
robo-ops-read_reg(robo, PAGE_CTRL,
REG_CTRL_MIIPO,
val8,
sizeof(val8));
val8 |= 0x81; /* Make Link pass and override it.
*/
robo-ops-write_reg(robo, PAGE_CTRL,
REG_CTRL_MIIPO,
val8,
sizeof(val8));
}
Hauke, did you use '0xb1' intentionally instead of '0x81'? Or do we
want
this to be the same?
I used the Asus ac66u source code as a reference as this contains
the
most recent source code I know of. There val8 |= 0xb1; is used.
Bits 5 and 6 enable rx/tx flow control - not sure if this is
potentially harmfull or not.
Does chaining this to 0x81 changes the behavior of your device?
Signed-off-by: Tijs Van Buggenhout t...@able.be
diff --git a/package/switch/src/switch-robo.c
b/package/switch/src/switch-
robo.c
index f715972..ac4855a 100644
--- a/package/switch/src/switch-robo.c
+++ b/package/switch/src/switch-robo.c
@@ -252,8 +252,13 @@ static int robo_switch_enable(void)
if (robo.devid == ROBO_DEVICE_ID_53125) {
/* Make IM port status link by default */
- val = robo_read16(ROBO_CTRL_PAGE,
ROBO_PORT_OVERRIDE_CTRL) | 0xb1;
+ val = robo_read16(ROBO_CTRL_PAGE,
ROBO_PORT_OVERRIDE_CTRL) | 0x81;
robo_write16(ROBO_CTRL_PAGE,
ROBO_PORT_OVERRIDE_CTRL,
val);
+
+ /* Write LED control register */
+ val = 0x020b;
+ robo_write16(ROBO_CTRL_PAGE, 0x12, val);
+
With this change my Asus n66u does not blink on activity any more.
Maybe there is some nvram value for it? the led configuration is
likely device specific, not chip specific.
Jonas
'et_swleds' nvram variable seems to be intended for this purpose, but
doesn't (seem to) exist by default for the e3200.. is it for the asus?
No, et_swleds is not set on any of my devices.
This code change is probably the device specific configuration.
I found the following code in the switch driver and it is missing in
kmod-switch. You could try to implement that, si_pmu_chipcontrol() is
the same as bcma_chipco_chipctl_maskset() expect that you have to
inverse the mask parameter.
/* Enable switch leds */
if (sih-chip == BCM5356_CHIP_ID) {
si_pmu_chipcontrol(sih, 2, (1 25), (1 25));
/* also enable fast MII clocks */
si_pmu_chipcontrol(sih, 0, (1 1), (1 1));
} else if ((sih-chip == BCM5357_CHIP_ID) || (sih-chip ==
BCM53572_CHIP_ID)) {
uint32 led_gpios = 0;
const char *var;
if (((sih-chip == BCM5357_CHIP_ID) (sih-chippkg !=
BCM47186_PKG_ID)) ||
((sih-chip == BCM53572_CHIP_ID) (sih-chippkg !=
BCM47188_PKG_ID)))
led_gpios = 0x1f;
var = getvar(vars, et_swleds);
if (var)
led_gpios = bcm_strtoul(var, NULL, 0);
if (led_gpios)
si_pmu_chipcontrol(sih, 2
Re: [OpenWrt-Devel] c question (for a patch..)
On Thursday 07 March 2013 18:47:53 Alexander Stadler wrote: Am 07.03.2013 17:25, schrieb Tijs Van Buggenhout: On Thursday 07 March 2013 16:39:33 Alexander Stadler wrote: Am 07.03.2013 16:24, schrieb Matthijs Kooijman: Hi Alexander, Hi Tijs, just read after I've sent my last Message.. . The next thought was that ARRAY_SIZE macro must get an array and not an pointer, so I tried it with: That's exactly right. An array's size is not stored in memory, so you can only get at it at compile time. However, then you must actually pass the array, not a pointer to the array (which could potentially point to different arrays). static void __init board_generic_setup(struct gpio_led *leds_gpio, size_t leds_gpio_size, struct gpio_keys_button *gpio_keys, size_t gpio_keys_size, struct mdio_board_info *mdio0_info, size_t mdio0_info_size) board_generic_setup(board_leds_gpio,ARRAY_SIZE(board_leds_gpio),board_g pi o_keys,ARRAY_SIZE(board_gpio_keys),board_mdio0_info,ARRAY_SIZE(board_md io 0_info)); And no const(s)? I'm a bit confused because mdio_board_info seems to use const struct but ath79_register_leds_gpio does not. In general it's good to inform/promise the compiler when the program is not going to change data (using const). However, you'll have to adjust to the function definition types of the other functions that you are going to use in your new function. When compiled with the appropriate flags, when passing a const pointer As I understand the struct gpio_led *leds_gpio syntax was a pointer to a const struct, and not to a const pointer. So that should give warnings after used with functions where its defined non-const, because they would be able to modify the content of the struct. But as written in the other mail I now use struct gpio_led *const leds_gpio. This should not throw errors (I think because in the next function its a new pointer, so which then could again be used to point to an other address?), as long as (in this function) the pointer is not used to point to another struct (which is exactly what I want to prevent.) Correct. Every function has its own scope (decendant of global scope), so the leds_gpio pointer is not visible by the next function, unless a pointer to a pointer would be supplied as an argument to the next function. This is not entirely true ofcourse, as pointers are globally visible, and one could guess the address of the leds_gpio pointer in the next function, and change the address of the pointer there. As long as the intension is not data protection, const can be useful ;-) to a function as argument, which is by definition typed non- const, it should produce a warning/error. The latter can be avoided by casting the const away, but what's the point in that... This might be interesting reading http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html . This would indeed be a sane way to handle this. No problems to expect from the functions like ath79_register_leds_gpio when getting the pointer instead the array? This should work, since that function also has a size parameter (for the same reason). The functions use unsigned for the size parameter, not size_t. But I think my ARRAY_SIZE will return size_t and so this will be the better approach? size_t is intended to represent memory related quantities, and is preferred in that regard. Gr. Matthijs Thanks Alex Regards, Tijs Alex Tijs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] c question (for a patch..)
On Thursday 07 March 2013 16:39:33 Alexander Stadler wrote: Am 07.03.2013 16:24, schrieb Matthijs Kooijman: Hi Alexander, The next thought was that ARRAY_SIZE macro must get an array and not an pointer, so I tried it with: That's exactly right. An array's size is not stored in memory, so you can only get at it at compile time. However, then you must actually pass the array, not a pointer to the array (which could potentially point to different arrays). static void __init board_generic_setup(struct gpio_led *leds_gpio, size_t leds_gpio_size, struct gpio_keys_button *gpio_keys, size_t gpio_keys_size, struct mdio_board_info *mdio0_info, size_t mdio0_info_size) board_generic_setup(board_leds_gpio,ARRAY_SIZE(board_leds_gpio),board_gpi o_keys,ARRAY_SIZE(board_gpio_keys),board_mdio0_info,ARRAY_SIZE(board_mdio 0_info)); And no const(s)? I'm a bit confused because mdio_board_info seems to use const struct but ath79_register_leds_gpio does not. In general it's good to inform/promise the compiler when the program is not going to change data (using const). However, you'll have to adjust to the function definition types of the other functions that you are going to use in your new function. When compiled with the appropriate flags, when passing a const pointer to a function as argument, which is by definition typed non- const, it should produce a warning/error. The latter can be avoided by casting the const away, but what's the point in that... This might be interesting reading http://publications.gbdirect.co.uk/c_book/chapter8/const_and_volatile.html. This would indeed be a sane way to handle this. No problems to expect from the functions like ath79_register_leds_gpio when getting the pointer instead the array? This should work, since that function also has a size parameter (for the same reason). The functions use unsigned for the size parameter, not size_t. But I think my ARRAY_SIZE will return size_t and so this will be the better approach? size_t is intended to represent memory related quantities, and is preferred in that regard. Gr. Matthijs Thanks Alex ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Regards, Tijs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] c question (for a patch..)
On Thursday 07 March 2013 17:47:02 Matthijs Kooijman wrote:
Hi Tijs,
In general it's good to inform/promise the compiler when the program is
not
going to change data (using const). However, you'll have to adjust to the
function definition types of the other functions that you are going to use
in your new function.
Agreed: If you need to pass the pointer on to functions that do not have
their arguments declared as non-const, you can't use const yourself
either (which indicates that const-correctness only really works when
all of the codebase uses it consistently).
When compiled with the appropriate flags, when passing a
const pointer to a function as argument, which is by definition typed non-
const, it should produce a warning/error.
Eh? Are you saying here that you can't declare a pointer argument as
const? I'm pretty sure you can?
E.g, this compiles:
void func(const char *foo) {}
void main() {
const char *x = foo;
func(x);
}
But removing the const from the definition of func makes the compiler
complain.
This is what I meant ;-) Supplying a const pointer to a function which
requires a non-const pointer as argument should make the compiler complain,
because the function intents to change the data in the memory address the
pointer is referring to.
Gr.
Matthijs
Thanks,
Tijs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bgmac - add support for unaligned addressing
On Thursday 28 February 2013 20:06:49 Hauke Mehrtens wrote:
Hi,
I haven't tested your patch I have just some comments. In general it
looks good to me.
Would be nice if it could be tested for both types.. I'm pretty sure by now
it's working okay for unaligned addressing, but have only one device to test
on.
On 02/25/2013 10:18 PM, Tijs Van Buggenhout wrote:
Signed-off-by: Tijs Van Buggenhout (t...@able.be)
Your whole patch is malformed, there are extra line breaks and tabs
were eaten by your mailer.
It's a cpp from a cat'ed diff on console. Email client does a line wrap
after 80 characters in plain text. Will try as attachment next time...
Read this http://kerneltrap.org/Linux/Email_Clients_and_Patches to
configure your mail client to not mangle the patches. You could also try
it for you own, just send he patch to your self and try to apply it.
Sorry again..
What do you think about the following patch?
Only one change in bgmac_ring struct, a boolean named dma_unaligned. An
u32
variable index_base is locally defined in functions where needed, assigned
to addr lo of dma_base in case of unaligned addr, otherwise 0.
--- a/drivers/net/ethernet/broadcom/bgmac.h 2013-02-20
12:41:03.138480108 +0100 +++ b/drivers/net/ethernet/broadcom/bgmac.h
2013-02-25 21:03:29.110125298 +0100 @@ -384,6 +384,7 @@
u16 mmio_base;
struct bgmac_dma_desc *cpu_base;
dma_addr_t dma_base;
+ bool dma_unaligned;
struct bgmac_slot_info slots[BGMAC_RX_RING_SLOTS];
};
--- a/drivers/net/ethernet/broadcom/bgmac.c 2013-02-25
22:10:14.744943929 +0100 +++ b/drivers/net/ethernet/broadcom/bgmac.c
2013-02-25 20:59:39.697996832 +0100 @@ -108,6 +108,7 @@
struct net_device *net_dev = bgmac-net_dev;
struct bgmac_dma_desc *dma_desc;
struct bgmac_slot_info *slot;
+ u32 index_base = ( ring-dma_unaligned ?
lower_32_bits(ring-dma_base) : 0 );
u32 ctl0, ctl1;
int free_slots;
@@ -156,7 +157,7 @@
if (++ring-end = BGMAC_TX_RING_SLOTS)
ring-end = 0;
bgmac_write(bgmac, ring-mmio_base + BGMAC_DMA_TX_INDEX,
- ring-end * sizeof(struct bgmac_dma_desc));
+ ( index_base + ( ring-end * sizeof(struct
bgmac_dma_desc) ) ));
/* Always keep one slot free to allow detecting bugged calls. */
if (--free_slots == 1)
@@ -174,14 +175,25 @@
static void bgmac_dma_tx_free(struct bgmac *bgmac, struct bgmac_dma_ring
*ring) {
struct device *dma_dev = bgmac-core-dma_dev;
- int empty_slot;
+ u16 empty_slot;
+ u32 index_base = ( ring-dma_unaligned ?
lower_32_bits(ring-dma_base) : 0 );
bool freed = false;
+ if (ring-start == ring-end)
+ return;
+
Is this an unrelated change?
Not entirely related.. would be an optimisation, but when I come to think of
it, it's probably more like a rare case. I'll have a look whether the hardware
can deal with this case..
/* The last slot that hardware didn't consume yet */
- empty_slot = bgmac_read(bgmac, ring-mmio_base +
BGMAC_DMA_TX_STATUS); - empty_slot = BGMAC_DMA_TX_STATDPTR;
+ empty_slot = (u16) ( ( bgmac_read(bgmac, ring-mmio_base +
BGMAC_DMA_TX_STATUS) - + index_base )
BGMAC_DMA_TX_STATDPTR );
I like the following more:
empty_slot = (u16)(bgmac_read(bgmac, ring-mmio_base +
BGMAC_DMA_TX_STATUS) - index_base);
empty_slot = BGMAC_DMA_TX_STATDPTR;
empty_slot /= sizeof(struct bgmac_dma_desc);
+ if (((ring-start == 0) (empty_slot ring-end)) ||
+ (empty_slot = ring-num_slots)) {
+ bgmac_err(bgmac, Bogus current TX slot index %u (start
index: %u, end index: %u)\n, + empty_slot,
ring-start, ring-end);
+ return;
+ }
+
Is this an unrelated change?
This is related if you consider the
bgmac bcma0:1: Hardware reported transmission for empty TX ring slot 0! End of
ring: 0
ams
messages.
They only appeared because the while loop (see underneath) would never end,
because the condition (ring-start != empty_slot) would always be true when
empty_slot = ring-num_slots. The body of the while loop doesn't allow ring-
start to become any higher than ring-num_slots, resetting it to zero when it
does, turning it into an infinite loop.
You can see this as a protection for the software driver in case the hardware
fails (and returns a faulty slot id (== not within range)). In that regard
I've been thinking to set a BUG_ON instead of the error report.. in case of
unaligned addressing, the hardware could not recover from this (without being
reset/reinitialised).
BUG_ON(empty_slot = ring-num_slots);
while (ring-start
Re: [OpenWrt-Devel] Option GlobeSurfer II 7.2 NVRAM contents
On Friday 01 March 2013 19:44:28 Fiach Antaw wrote: For board detection have a look at new detection code (in both 3.8, 3.6) https://dev.openwrt.org/browser/trunk/target/linux/brcm47xx/patches-3.8/26 0-MIPS-BCM47XX-add-board-detection.patch and the backup detection code in https://dev.openwrt.org/browser/trunk/package/broadcom-diag/src/diag.c Ah, I saw the 260- board detection patch but I didn't know that diag.c did it's own board detection, thanks. boardnum=G33779F3NR - unique I suppose the boardnum nvram variable makes the most sense. (or a combination of boardrev and boardtype) I thought that at first too, but it matches the serial number printed on the casing (along with the wifi/lan MAC IDs and such), so I'm thinking it's unit-specific. At the moment I'm just checking boardtype and boardrev, and will probably add a check for the presence of boardnum even if I can't use the value itself for detection. Don't forget to save board_data or other important partitions before you flash :D I just saved an image of the whole flash (0x1c00-0x1d00) with the CFE's 'save' command. I've been working under the assumption that if worst comes to worst I can just use JTAG to flash that back on (since I've worked out the JTAG pinouts and have a slow-but-workable Bus Pirate with OpenOCD support), is there anything else I'd need? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Maybe you can try a tftp boot of the new openwrt (elf) image via CFE, avoiding to flash the device? http://wiki.openwrt.org/doc/hardware/soc/soc.broadcom.bcm47xx#network.boot Regards, Tijs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bgmac - add support for unaligned addressing
On Friday 01 March 2013 10:56:33 Tijs Van Buggenhout wrote:
On Thursday 28 February 2013 20:06:49 Hauke Mehrtens wrote:
Hi,
I haven't tested your patch I have just some comments. In general it
looks good to me.
Would be nice if it could be tested for both types.. I'm pretty sure by now
it's working okay for unaligned addressing, but have only one device to test
on.
On 02/25/2013 10:18 PM, Tijs Van Buggenhout wrote:
Signed-off-by: Tijs Van Buggenhout (t...@able.be)
Your whole patch is malformed, there are extra line breaks and tabs
were eaten by your mailer.
It's a cpp from a cat'ed diff on console. Email client does a line
wrap
after 80 characters in plain text. Will try as attachment next time...
Read this http://kerneltrap.org/Linux/Email_Clients_and_Patches to
configure your mail client to not mangle the patches. You could also try
it for you own, just send he patch to your self and try to apply it.
Sorry again..
What do you think about the following patch?
Only one change in bgmac_ring struct, a boolean named dma_unaligned. An
u32
variable index_base is locally defined in functions where needed,
assigned
to addr lo of dma_base in case of unaligned addr, otherwise 0.
--- a/drivers/net/ethernet/broadcom/bgmac.h 2013-02-20
12:41:03.138480108 +0100 +++ b/drivers/net/ethernet/broadcom/bgmac.h
2013-02-25 21:03:29.110125298 +0100 @@ -384,6 +384,7 @@
u16 mmio_base;
struct bgmac_dma_desc *cpu_base;
dma_addr_t dma_base;
+ bool dma_unaligned;
struct bgmac_slot_info slots[BGMAC_RX_RING_SLOTS];
};
--- a/drivers/net/ethernet/broadcom/bgmac.c 2013-02-25
22:10:14.744943929 +0100 +++ b/drivers/net/ethernet/broadcom/bgmac.c
2013-02-25 20:59:39.697996832 +0100 @@ -108,6 +108,7 @@
struct net_device *net_dev = bgmac-net_dev;
struct bgmac_dma_desc *dma_desc;
struct bgmac_slot_info *slot;
+ u32 index_base = ( ring-dma_unaligned ?
lower_32_bits(ring-dma_base) : 0 );
u32 ctl0, ctl1;
int free_slots;
@@ -156,7 +157,7 @@
if (++ring-end = BGMAC_TX_RING_SLOTS)
ring-end = 0;
bgmac_write(bgmac, ring-mmio_base + BGMAC_DMA_TX_INDEX,
- ring-end * sizeof(struct bgmac_dma_desc));
+ ( index_base + ( ring-end * sizeof(struct
bgmac_dma_desc) ) ));
/* Always keep one slot free to allow detecting bugged calls. */
if (--free_slots == 1)
@@ -174,14 +175,25 @@
static void bgmac_dma_tx_free(struct bgmac *bgmac, struct
bgmac_dma_ring
*ring) {
struct device *dma_dev = bgmac-core-dma_dev;
- int empty_slot;
+ u16 empty_slot;
+ u32 index_base = ( ring-dma_unaligned ?
lower_32_bits(ring-dma_base) : 0 );
bool freed = false;
+ if (ring-start == ring-end)
+ return;
+
Is this an unrelated change?
Not entirely related.. would be an optimisation, but when I come to think of
it, it's probably more like a rare case. I'll have a look whether the
hardware can deal with this case..
This is not needed .. hardware can deal with it.
/* The last slot that hardware didn't consume yet */
- empty_slot = bgmac_read(bgmac, ring-mmio_base +
BGMAC_DMA_TX_STATUS); - empty_slot = BGMAC_DMA_TX_STATDPTR;
+ empty_slot = (u16) ( ( bgmac_read(bgmac, ring-mmio_base +
BGMAC_DMA_TX_STATUS) - + index_base )
BGMAC_DMA_TX_STATDPTR );
I like the following more:
empty_slot = (u16)(bgmac_read(bgmac, ring-mmio_base +
BGMAC_DMA_TX_STATUS) - index_base);
empty_slot = BGMAC_DMA_TX_STATDPTR;
Used this one.
empty_slot /= sizeof(struct bgmac_dma_desc);
+ if (((ring-start == 0) (empty_slot ring-end)) ||
+ (empty_slot = ring-num_slots)) {
+ bgmac_err(bgmac, Bogus current TX slot index %u (start
index: %u, end index: %u)\n, + empty_slot,
ring-start, ring-end);
+ return;
+ }
+
Is this an unrelated change?
This is related if you consider the
bgmac bcma0:1: Hardware reported transmission for empty TX ring slot 0! End
of ring: 0
ams
messages.
They only appeared because the while loop (see underneath) would never end,
because the condition (ring-start != empty_slot) would always be true when
empty_slot = ring-num_slots. The body of the while loop doesn't allow
ring-
start to become any higher than ring-num_slots, resetting it to zero when
it
does, turning it into an infinite loop.
You can see this as a protection for the software driver in case the
hardware fails (and returns a faulty slot id (== not within
Re: [OpenWrt-Devel] [PATCH] bgmac: add support for qos
On Thursday 28 February 2013 15:02:26 Hauke Mehrtens wrote: On 02/27/2013 02:04 PM, Tijs Van Buggenhout wrote: On Tuesday 26 February 2013 21:45:00 Tijs Van Buggenhout wrote: This is a proposal to add QoS support to bgmac driver, allowing to use (possibly) all of the tx queues supported by the hardware. The bgmac device is allocated as an ethernet multiqueue network device, reporting the (maximum) tx queues supported by the hardware to the kernel. The default queue selection mechenism is replaced with the bgmac_select_queue function, mapping the priorities of the skbs to a specific tx queue number. I would not replace the default algorithm. I would agree on that. I first tried with the default algorithm, but it maps the priorities to the queues in a very different way (other than found in broadcom driver, as displayed below). I don't know if it is intentional or not (by broadcom).. does the hardware treat TX queues differently in priority, e.g. broadcom driver prioritises TX_Q3 over TX_Q2, over TX_Q1, over TX_Q0. When using the default algorithm, I saw normal packets (without priority explicitely set), like ICMP being mapped to TX_Q3, whereas ssh traffic was going to TX_Q2. As it seems, the default algorithm can map priorities differently every time the driver/kernel is initialised (random). Not really what we want. Later this number is used in the bgmax_start_xmit function to select the right tx queue, on which the new skb is added. The hardware will generate an interrupt when the skb is handled, in which it reports on what hardware queue (number/id) the event occured, allowing to call bgmac_dma_tx_free on the right tx queue/ring. Mapping is according to 802.1d priority to traffic class mapping, as found in et_linux.c : Sorry, it resides in et/sys/etc.c, my mistake... TX_Q1, /* 0BETC_BEBest Effort */ TX_Q0, /* 1BKTC_BKBackground */ TX_Q0, /* 2--TC_BKBackground */ TX_Q1, /* 3EETC_BEBest Effort */ TX_Q2, /* 4CLTC_CLControlled Load */ TX_Q2, /* 5VITC_CLControlled Load */ TX_Q3, /* 6VOTC_VOVoice */ TX_Q3 /* 7NCTC_VOVoice */ Additionally any other value is mapped on TX_Q0.. Impact on the source code is rather limited, some extra local variables for netdev_queue, queue_id (u16), and all netif_.*_queue calls converted to appropriate netdif_tx_.*_queue calls. I did not test extensively yet, but proof of concept works and is easily tested by adding some debug code to the driver (in bgmac_dma_tx_add, bgmac_poll and bgmac_select_queue functions) and using the ping command on command line and the dropbear ssh (which uses a non-default TOS value on packets: Minimize Delay). Console output shows the following: root@OpenWrt:/# ping 192.168.1.113 PING 192.168.1.113 (192.168.1.113): 56 data bytes [ 58.304000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 58.316000] bgmac bcma0:1: Select tx queue 1 for packet [ 58.32] bgmac bcma0:1: Received interrupt for tx queue 1 [ 58.328000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 58.332000] bgmac bcma0:1: Select tx queue 1 for packet [ 58.34] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=0 ttl=64 time=40.513 ms [ 59.344000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 59.352000] bgmac bcma0:1: Select tx queue 1 for packet [ 59.356000] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=1 ttl=64 time=18.595 ms [ 60.364000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 60.372000] bgmac bcma0:1: Select tx queue 1 for packet [ 60.376000] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=2 ttl=64 time=18.550 ms ^C --- 192.168.1.113 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss root@OpenWrt:/# ssh tvb@192.168.1.113 [ 105.992000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 106.00] bgmac bcma0:1: Select tx queue 1 for packet [ 106.004000] bgmac bcma0:1: Received interrupt for tx queue 1 [ 106.012000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 106.016000] bgmac bcma0:1: Select tx queue 1 for packet [ 106.024000] bgmac bcma0:1: Received interrupt for tx queue 1 [ 106.032000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 [ 106.036000] bgmac bcma0:1: Select tx queue 3 for packet [ 106.044000] bgmac bcma0:1: Received interrupt for tx queue 3 [ 106.048000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 [ 106.056000] bgmac bcma0:1: Select tx queue 3 for packet [ 106.06] bgmac bcma0:1: Received interrupt for tx
Re: [OpenWrt-Devel] [PATCH] bgmac: add support for qos
On Tuesday 26 February 2013 21:45:00 Tijs Van Buggenhout wrote: This is a proposal to add QoS support to bgmac driver, allowing to use (possibly) all of the tx queues supported by the hardware. The bgmac device is allocated as an ethernet multiqueue network device, reporting the (maximum) tx queues supported by the hardware to the kernel. The default queue selection mechenism is replaced with the bgmac_select_queue function, mapping the priorities of the skbs to a specific tx queue number. Later this number is used in the bgmax_start_xmit function to select the right tx queue, on which the new skb is added. The hardware will generate an interrupt when the skb is handled, in which it reports on what hardware queue (number/id) the event occured, allowing to call bgmac_dma_tx_free on the right tx queue/ring. Mapping is according to 802.1d priority to traffic class mapping, as found in et_linux.c : Sorry, it resides in et/sys/etc.c, my mistake... TX_Q1, /* 0BETC_BEBest Effort */ TX_Q0, /* 1BKTC_BKBackground */ TX_Q0, /* 2--TC_BKBackground */ TX_Q1, /* 3EETC_BEBest Effort */ TX_Q2, /* 4CLTC_CLControlled Load */ TX_Q2, /* 5VITC_CLControlled Load */ TX_Q3, /* 6VOTC_VOVoice */ TX_Q3 /* 7NCTC_VOVoice */ Additionally any other value is mapped on TX_Q0.. Impact on the source code is rather limited, some extra local variables for netdev_queue, queue_id (u16), and all netif_.*_queue calls converted to appropriate netdif_tx_.*_queue calls. I did not test extensively yet, but proof of concept works and is easily tested by adding some debug code to the driver (in bgmac_dma_tx_add, bgmac_poll and bgmac_select_queue functions) and using the ping command on command line and the dropbear ssh (which uses a non-default TOS value on packets: Minimize Delay). Console output shows the following: root@OpenWrt:/# ping 192.168.1.113 PING 192.168.1.113 (192.168.1.113): 56 data bytes [ 58.304000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 58.316000] bgmac bcma0:1: Select tx queue 1 for packet [ 58.32] bgmac bcma0:1: Received interrupt for tx queue 1 [ 58.328000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 58.332000] bgmac bcma0:1: Select tx queue 1 for packet [ 58.34] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=0 ttl=64 time=40.513 ms [ 59.344000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 59.352000] bgmac bcma0:1: Select tx queue 1 for packet [ 59.356000] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=1 ttl=64 time=18.595 ms [ 60.364000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 60.372000] bgmac bcma0:1: Select tx queue 1 for packet [ 60.376000] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=2 ttl=64 time=18.550 ms ^C --- 192.168.1.113 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss root@OpenWrt:/# ssh tvb@192.168.1.113 [ 105.992000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 106.00] bgmac bcma0:1: Select tx queue 1 for packet [ 106.004000] bgmac bcma0:1: Received interrupt for tx queue 1 [ 106.012000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 106.016000] bgmac bcma0:1: Select tx queue 1 for packet [ 106.024000] bgmac bcma0:1: Received interrupt for tx queue 1 [ 106.032000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 [ 106.036000] bgmac bcma0:1: Select tx queue 3 for packet [ 106.044000] bgmac bcma0:1: Received interrupt for tx queue 3 [ 106.048000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 [ 106.056000] bgmac bcma0:1: Select tx queue 3 for packet [ 106.06] bgmac bcma0:1: Received interrupt for tx queue 3 [ 106.072000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 ... Host '192.168.1.113' is not in the trusted hosts file. (fingerprint md5 b7:12:75:ca:65:cb:c7:60:59:35:6a:5d:28:6d:27:83) Do you want to continue connecting? (y/n) [ 106.40] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 [ 106.404000] bgmac bcma0:1: Select tx queue 3 for packet [ 106.408000] bgmac bcma0:1: Received interrupt for tx queue 3 y [ 111.776000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 ... This patch is generated from git trunk.. Any comments/suggestions/ideas very welcome... Signed-off-by: Tijs Van Buggenhout t...@able.be --- diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c index 3fd3288..58b1d09 100644 --- a/drivers/net/ethernet/broadcom/bgmac.c +++ b/drivers/net/ethernet/broadcom/bgmac.c @@ -15,6 +15,8 @@ #include linux/mii.h #include
[OpenWrt-Devel] [PATCH] bgmac: add support for qos
This is a proposal to add QoS support to bgmac driver, allowing to use (possibly) all of the tx queues supported by the hardware. The bgmac device is allocated as an ethernet multiqueue network device, reporting the (maximum) tx queues supported by the hardware to the kernel. The default queue selection mechenism is replaced with the bgmac_select_queue function, mapping the priorities of the skbs to a specific tx queue number. Later this number is used in the bgmax_start_xmit function to select the right tx queue, on which the new skb is added. The hardware will generate an interrupt when the skb is handled, in which it reports on what hardware queue (number/id) the event occured, allowing to call bgmac_dma_tx_free on the right tx queue/ring. Mapping is according to 802.1d priority to traffic class mapping, as found in et_linux.c : TX_Q1, /* 0BETC_BEBest Effort */ TX_Q0, /* 1BKTC_BKBackground */ TX_Q0, /* 2--TC_BKBackground */ TX_Q1, /* 3EETC_BEBest Effort */ TX_Q2, /* 4CLTC_CLControlled Load */ TX_Q2, /* 5VITC_CLControlled Load */ TX_Q3, /* 6VOTC_VOVoice */ TX_Q3 /* 7NCTC_VOVoice */ Additionally any other value is mapped on TX_Q0.. Impact on the source code is rather limited, some extra local variables for netdev_queue, queue_id (u16), and all netif_.*_queue calls converted to appropriate netdif_tx_.*_queue calls. I did not test extensively yet, but proof of concept works and is easily tested by adding some debug code to the driver (in bgmac_dma_tx_add, bgmac_poll and bgmac_select_queue functions) and using the ping command on command line and the dropbear ssh (which uses a non-default TOS value on packets: Minimize Delay). Console output shows the following: root@OpenWrt:/# ping 192.168.1.113 PING 192.168.1.113 (192.168.1.113): 56 data bytes [ 58.304000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 58.316000] bgmac bcma0:1: Select tx queue 1 for packet [ 58.32] bgmac bcma0:1: Received interrupt for tx queue 1 [ 58.328000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 58.332000] bgmac bcma0:1: Select tx queue 1 for packet [ 58.34] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=0 ttl=64 time=40.513 ms [ 59.344000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 59.352000] bgmac bcma0:1: Select tx queue 1 for packet [ 59.356000] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=1 ttl=64 time=18.595 ms [ 60.364000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 60.372000] bgmac bcma0:1: Select tx queue 1 for packet [ 60.376000] bgmac bcma0:1: Received interrupt for tx queue 1 64 bytes from 192.168.1.113: seq=2 ttl=64 time=18.550 ms ^C --- 192.168.1.113 ping statistics --- 3 packets transmitted, 3 packets received, 0% packet loss root@OpenWrt:/# ssh tvb@192.168.1.113 [ 105.992000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 106.00] bgmac bcma0:1: Select tx queue 1 for packet [ 106.004000] bgmac bcma0:1: Received interrupt for tx queue 1 [ 106.012000] bgmac bcma0:1: bgmac_select_queue based on priority 0x0 [ 106.016000] bgmac bcma0:1: Select tx queue 1 for packet [ 106.024000] bgmac bcma0:1: Received interrupt for tx queue 1 [ 106.032000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 [ 106.036000] bgmac bcma0:1: Select tx queue 3 for packet [ 106.044000] bgmac bcma0:1: Received interrupt for tx queue 3 [ 106.048000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 [ 106.056000] bgmac bcma0:1: Select tx queue 3 for packet [ 106.06] bgmac bcma0:1: Received interrupt for tx queue 3 [ 106.072000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 ... Host '192.168.1.113' is not in the trusted hosts file. (fingerprint md5 b7:12:75:ca:65:cb:c7:60:59:35:6a:5d:28:6d:27:83) Do you want to continue connecting? (y/n) [ 106.40] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 [ 106.404000] bgmac bcma0:1: Select tx queue 3 for packet [ 106.408000] bgmac bcma0:1: Received interrupt for tx queue 3 y [ 111.776000] bgmac bcma0:1: bgmac_select_queue based on priority 0x6 ... This patch is generated from git trunk.. Any comments/suggestions/ideas very welcome... Signed-off-by: Tijs Van Buggenhout t...@able.be --- diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c index 3fd3288..58b1d09 100644 --- a/drivers/net/ethernet/broadcom/bgmac.c +++ b/drivers/net/ethernet/broadcom/bgmac.c @@ -15,6 +15,8 @@ #include linux/mii.h #include linux/interrupt.h #include linux/dma-mapping.h +#include linux/pkt_sched.h /* TC defines */ +#include linux/skbuff.h /* skb_get_queue_mapping */ #include asm/mach-bcm47xx/nvram.h static
Re: [OpenWrt-Devel] Linksys E4200v1 Support
On Friday 22 February 2013 18:58:07 Tijs Van Buggenhout wrote:
On Thursday 21 February 2013 18:40:20 Tijs Van Buggenhout wrote:
On Thursday 21 February 2013 16:13:07 Hauke Mehrtens wrote:
On 02/20/2013 02:46 PM, Cezary Jackiewicz wrote:
Dnia 2013-02-20, o godz. 14:11:53
Hauke Mehrtens ha...@hauke-m.de napisa?(a):
On my e3200 Ethernet works with the default config. Are there more
problems discussed in this tread?
On my e3200 also ethernet seems to work, but often hangs up with:
[ 121.98] bgmac bcma0:1: Hardware reported transmission for empty
TX
ring slot 120! End of ring: 0 [ 121.988000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 121! End of ring: 0 [
121.996000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 122! End of ring: 0 [ 122.008000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 123! End of ring: 0 [
122.016000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 124! End of ring: 0 [ 122.024000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 125! End of ring: 0 [
122.036000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 126! End of ring: 0 [ 122.044000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 127! End of ring: 0 [
122.052000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 0! End of ring: 0 [ 122.064000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 1! End of ring: 0 [
122.072000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 2! End of ring: 0 [ 122.08] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 3! End of ring: 0 [
122.088000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 4! End of ring: 0 [ 122.10] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 5! End of ring: 0 [
122.108000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 6! End of ring: 0 [ 122.116000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 7! End of ring: 0 [
122.128000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 8! End of ring: 0 [ 122.136000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 9! End of ring: 0
etc.
I have seen the same problem with my e3200. When this happens I see
~17MByte/s of garbage traffic on the NIC of my desktop connected to this
devices. It looks like it sends out old packages or parts of it in an
endless loop. Most of them did not contained a valid Ethernet header but
some contained the OpenWrt logo, where I expected an Ethernet or IP
header. ;-)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I notice the same behaviour here. I see this happen regularly, when
booting
the device, without network cables plugged in, or no network traffic being
received. By default, an udhcp client is run on internet interface, which
sends out packets, but no answer is (ever) returned.
After about 300 seconds, the driver will start reporting these messages,
after a while the system reboots.
I made a tcpdump on the wan port, which shows only udp dhcp requests being
sent. At the moment the driver starts reporting, I can see two packets being
echoed from the past (dhcp requests hold the 'seconds elapsed' field, which
normally only augments).
Packets sent out, with increasing seconds elapsed:
17:53:54.097432 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys.D.C.gl.1.Us.q..
.K!.s...
...c.Sc5..9..@7...*
.udhcp
1.19.4.
17:53:57.098021 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys.D.C.gl.1.Us.t..
.K!.s...
...c.Sc5..9..@7...*
.udhcp
1.19.4.
17:54:00.101515 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys
[OpenWrt-Devel] [PATCH] bgmac - add support for unaligned addressing
This is a proposal for target/linux/brcm47xx/patches-3.6/770-bgmac-unaligned-
addressing.patch, which adds support for DMA unaligned addressing in bgmac
driver (needed for e.g. linksys e3200 devices).
From analysing the 'Generic Broadcom Home Networking Division (HND) DMA
module' (hnddma.{c,h}), the DMA index register (BGMAC_DMA_TX_INDEX or
BGMAC_DMA_RX_INDEX) needs an extra base or offset from address register. This
offset needs to be accounted for when reading/analysing status
(BGMAC_DMA_TX_STATUS or BGMAC_DMA_RX_STATUS) to retrieve the current (empty)
slot id (BGMAC_DMA_TX_STATDPTR or BGMAC_DMA_RX_STATDPTR) in the ring.
Also for retrieving the active slot id (BGMAC_DMA_TX_ERRDPTR or
BGMAC_DMA_RX_STATDPTR) from BGMAC_DMA_TX_ERROR or BGMAC_DMA_RX_ERROR register
respectively, this would be needed, but currently not used in driver.
The patch adds two extra fields to the bgmac_dma_ring structure, namely a
boolean 'is_unaligned' which is set in bgmac_dma_alloc (and later used in
bgmac_dma_init), and an unsigned int of 32 bits, holding the base for the
index register for that ring.
For unaligned addressing (in bgmac_dma_init), the DMA table is first
initialised, before enabling any dma tx/rx control, which is different from
aligned addressing where it is the other way around.
I opted to introduce a CONFIG_BGMAC_UNALIGNED_ADDRESSING macro to introduce
the changes to support unaligned addressing for the bgmac driver (it does add
some extra bytes in bgmac_dma_ring struct). This could be an option in Kconfig
(not yet in patch), but for now it is defined fix in bgmac.h. The
implementation should work for both aligned and unaligned addressing when
CONFIG_BGMAC_UNALIGNED_ADDRESSING is defined.
If there is no need for en extra Kconfig option, let me know, I'll adjust the
patch. In the other case, I'll create an extra entry in Kconfig and add it to
the patch aswell. I created the patch from 3.6 kernel sources, let me know if
there are differences for the 3.8 kernel.
I hope this can be tested on different hardware supporting dma
aligned/unaligned addressing, it should work on both. Any comments/suggestions
are welcome..
Note: Besides the changes for unaligned addressing, I corrected some types for
variables and formats. I also introduced an extra int j variable in the second
loop within dma initialisation of rx ring(s).. from my understanding reusing
the int i variable in the inner loop breaks the outer loop if there would be
more than one rx ring.
Signed-off-by: Tijs Van Buggenhout (t...@able.be)
---
--- a/drivers/net/ethernet/broadcom/bgmac.h 2013-02-20 12:41:03.138480108
+0100
+++ b/drivers/net/ethernet/broadcom/bgmac.h 2013-02-25 13:22:06.187475387
+0100
@@ -15,6 +15,10 @@
#include linux/bcma/bcma.h
#include linux/netdevice.h
+#ifndef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+#define CONFIG_BGMAC_UNALIGNED_ADDRESSING
+#endif
+
#define BGMAC_DEV_CTL 0x000
#define BGMAC_DC_TSM 0x0002
#define BGMAC_DC_CFCO 0x0004
@@ -384,6 +388,10 @@
u16 mmio_base;
struct bgmac_dma_desc *cpu_base;
dma_addr_t dma_base;
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ bool is_unaligned;
+ u32 index_base;
+#endif
struct bgmac_slot_info slots[BGMAC_RX_RING_SLOTS];
};
--- a/drivers/net/ethernet/broadcom/bgmac.c 2013-02-20 12:41:03.122481212
+0100
+++ b/drivers/net/ethernet/broadcom/bgmac.c 2013-02-25 13:31:34.880174836
+0100
@@ -156,6 +156,9 @@
if (++ring-end = BGMAC_TX_RING_SLOTS)
ring-end = 0;
bgmac_write(bgmac, ring-mmio_base + BGMAC_DMA_TX_INDEX,
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ ring-index_base +
+#endif
ring-end * sizeof(struct bgmac_dma_desc));
/* Always keep one slot free to allow detecting bugged calls. */
@@ -174,14 +177,30 @@
static void bgmac_dma_tx_free(struct bgmac *bgmac, struct bgmac_dma_ring
*ring)
{
struct device *dma_dev = bgmac-core-dma_dev;
- int empty_slot;
+ u16 empty_slot;
bool freed = false;
+ if (ring-start == ring-end) {
+ bgmac_warn(bgmac, Ignore DMA TX free on empty ring 0x%X\n,
ring-mmio_base);
+ return;
+ }
+
/* The last slot that hardware didn't consume yet */
empty_slot = bgmac_read(bgmac, ring-mmio_base + BGMAC_DMA_TX_STATUS);
empty_slot = BGMAC_DMA_TX_STATDPTR;
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ empty_slot -= ring-index_base;
+ empty_slot = BGMAC_DMA_TX_STATDPTR;
+#endif
empty_slot /= sizeof(struct bgmac_dma_desc);
+ if (((ring-start == 0) (empty_slot ring-end)) ||
+ (empty_slot = ring-num_slots)) {
+ bgmac_err(bgmac, Bogus current TX slot index %u (start index:
%u, end index: %u)\n,
+ empty_slot, ring-start, ring-end);
+ return
Re: [OpenWrt-Devel] [PATCH] kmod-switch : Fix led control register - adjust IMP port status
On Monday 25 February 2013 14:06:13 Jonas Gorski wrote:
On 21 February 2013 15:53, Hauke Mehrtens ha...@hauke-m.de wrote:
On 02/21/2013 02:57 PM, Tijs Van Buggenhout wrote:
From linksys firmware :
# et -i eth0 robord 0x0 0x0e
0x008b
# et -i eth0 robord 0x0 0x12
0x020b
root@OpenWrt:/# robocfg robord 0x0e
Page 0x00, Reg 0x0e: 00bb
root@OpenWrt:/# robocfg robord 0x12
Page 0x00, Reg 0x12: 0321
1. Fix led control register:
On normal ports only one led was used for both link and activity (green),
internet port additionally had orange led on all the time.
I compared the value of registry 0x12 on linksys firmware vs openwrt, and
it showed a different value (0x20b for linksys vs 0x321 on openwrt).
Now the green led is always used to signal link, the orange led (only)
blinks on link activity.
2. Adjust IMP port status
As I was comparing register values/bcmrobo.c source code, I noticed a
difference for the IMP port status register (0x0e), linksys firmware
showed
0x8b vs 0xbb for openwrt.
From bcmrobo.c - int bcm_robo_enable_switch:
if ((robo-devid == DEVID53115) || (robo-devid == DEVID53125)) {
/* Over ride IMP port status to make it link by default
*/
val8 = 0;
robo-ops-read_reg(robo, PAGE_CTRL, REG_CTRL_MIIPO,
val8,
sizeof(val8));
val8 |= 0x81; /* Make Link pass and override it. */
robo-ops-write_reg(robo, PAGE_CTRL, REG_CTRL_MIIPO,
val8,
sizeof(val8));
}
Hauke, did you use '0xb1' intentionally instead of '0x81'? Or do we want
this to be the same?
I used the Asus ac66u source code as a reference as this contains the
most recent source code I know of. There val8 |= 0xb1; is used.
Bits 5 and 6 enable rx/tx flow control - not sure if this is
potentially harmfull or not.
Does chaining this to 0x81 changes the behavior of your device?
Signed-off-by: Tijs Van Buggenhout t...@able.be
diff --git a/package/switch/src/switch-robo.c
b/package/switch/src/switch-
robo.c
index f715972..ac4855a 100644
--- a/package/switch/src/switch-robo.c
+++ b/package/switch/src/switch-robo.c
@@ -252,8 +252,13 @@ static int robo_switch_enable(void)
if (robo.devid == ROBO_DEVICE_ID_53125) {
/* Make IM port status link by default */
- val = robo_read16(ROBO_CTRL_PAGE,
ROBO_PORT_OVERRIDE_CTRL) | 0xb1;
+ val = robo_read16(ROBO_CTRL_PAGE,
ROBO_PORT_OVERRIDE_CTRL) | 0x81;
robo_write16(ROBO_CTRL_PAGE, ROBO_PORT_OVERRIDE_CTRL,
val);
+
+ /* Write LED control register */
+ val = 0x020b;
+ robo_write16(ROBO_CTRL_PAGE, 0x12, val);
+
With this change my Asus n66u does not blink on activity any more.
Maybe there is some nvram value for it? the led configuration is
likely device specific, not chip specific.
Jonas
'et_swleds' nvram variable seems to be intended for this purpose, but doesn't
(seem to) exist by default for the e3200.. is it for the asus?
Regards,
Tijs
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] bgmac - add support for unaligned addressing
On Monday 25 February 2013 18:51:53 Rafał Miłecki wrote:
2013/2/25 Tijs Van Buggenhout t...@able.be:
I opted to introduce a CONFIG_BGMAC_UNALIGNED_ADDRESSING macro to
introduce
the changes to support unaligned addressing for the bgmac driver (it does
add some extra bytes in bgmac_dma_ring struct). This could be an option
in Kconfig (not yet in patch), but for now it is defined fix in bgmac.h.
The
implementation should work for both aligned and unaligned addressing when
CONFIG_BGMAC_UNALIGNED_ADDRESSING is defined.
I don't think we should need CONFIG_BGMAC_UNALIGNED_ADDRESSING, it
doesn't save a lot of size (when disabled) and makes configuration
more confusing.
I'll get rid of the defines, and create another patch ;-)
If there is no need for en extra Kconfig option, let me know, I'll adjust
the patch. In the other case, I'll create an extra entry in Kconfig and
add it to the patch aswell. I created the patch from 3.6 kernel sources,
let me know if there are differences for the 3.8 kernel.
Kernel 3.6 doesn't include bgmac at all ;)
Building from openwrt trunk, which configures a 3.6.11 kernel by default,
where bgmac is patched in?
I hope this can be tested on different hardware supporting dma
aligned/unaligned addressing, it should work on both. Any
comments/suggestions are welcome..
I'll give it a try on my BCM4706s, just give me some time.
No problem, take your time ;-)
Note: Besides the changes for unaligned addressing, I corrected some types
for variables and formats. I also introduced an extra int j variable in
the second loop within dma initialisation of rx ring(s).. from my
understanding reusing the int i variable in the inner loop breaks the
outer loop if there would be more than one rx ring.
That definitely should go in separated patches.
I'll separate them into different patches. The loop variable fix is already
settled
Signed-off-by: Tijs Van Buggenhout (t...@able.be)
Your whole patch is malformed, there are extra line breaks and tabs
were eaten by your mailer.
It's a cpp from a cat'ed diff on console. Email client does a line wrap after
80 characters in plain text. Will try as attachment next time...
@@ -384,6 +388,10 @@
u16 mmio_base;
struct bgmac_dma_desc *cpu_base;
dma_addr_t dma_base;
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ bool is_unaligned;
+ u32 index_base;
I'm pretty sure it's some duplication, we already store address somewhere
else.
Correct, but has implicit 0 value, when it is not assigned. Avoiding if
conditions in the rest of the code.
@@ -156,6 +156,9 @@
if (++ring-end = BGMAC_TX_RING_SLOTS)
ring-end = 0;
bgmac_write(bgmac, ring-mmio_base + BGMAC_DMA_TX_INDEX,
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ ring-index_base +
+#endif
Note: If we de-duplicate index_base we have to add that conditionally.
Indeed .. we could go for the bool is_unaligned, and write something like
'((is_unaligned ? lower_32_bits( ring-dma_base ) : 0 ) + ' or would you
prefer a normal if statement.
We could also go for a local variable index_base in the corresponding
functions, which is initialised to 0 or set to the correct value in case of
unalignment.
+ if (ring-start == ring-end) {
+ bgmac_warn(bgmac, Ignore DMA TX free on empty ring
0x%X\n, ring-mmio_base);
+ return;
+ }
+
Is that supposed to happen? I've to analyze that part :)
We can leave it out.. it's an optimisation (BGMAC_DMA_TX_STATUS doesn't need
to be read). I saw the warning appear a few times on my screen today, so the
message print is better left out anyways.
/* The last slot that hardware didn't consume yet */
empty_slot = bgmac_read(bgmac, ring-mmio_base +
BGMAC_DMA_TX_STATUS);
empty_slot = BGMAC_DMA_TX_STATDPTR;
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ empty_slot -= ring-index_base;
+ empty_slot = BGMAC_DMA_TX_STATDPTR;
+#endif
empty_slot /= sizeof(struct bgmac_dma_desc);
Do we need to mask that twice?
I kept as close to the broadcom sources as possible. Keeping in mind that
empty_slot is an u16, bgmac_read returns an u32 as is index_base, it's
probably best (for clarity) to write:
empty_slot = ( bgmac_read(bgmac, ring-mmio_base + BGMAC_DMA_TX_STATUS)
BGMAC_DMA_TX_STATDPTR );
empty_slot -= ( ring-index_base BGMAC_DMA_TX_STATDPTR )
but
empty_slot = (( bgmac_read(bgmac, ring-mmio_base + BGMAC_DMA_TX_STATUS) -
ring-index_base ) BGMAC_DMA_TX_STATDPTR );
can avoid the extra mask. Should I include an extra type cast (u16)?
+ if (((ring-start == 0) (empty_slot ring-end)) ||
+ (empty_slot = ring-num_slots)) {
+ bgmac_err(bgmac, Bogus current TX slot index %u (start
index: %u, end index: %u)\n
Re: [OpenWrt-Devel] [PATCH] kmod-switch : Fix led control register - adjust IMP port status
On Monday 25 February 2013 21:07:09 Hauke Mehrtens wrote:
On 02/25/2013 03:08 PM, Tijs Van Buggenhout wrote:
On Monday 25 February 2013 14:06:13 Jonas Gorski wrote:
On 21 February 2013 15:53, Hauke Mehrtens ha...@hauke-m.de wrote:
On 02/21/2013 02:57 PM, Tijs Van Buggenhout wrote:
From linksys firmware :
# et -i eth0 robord 0x0 0x0e
0x008b
# et -i eth0 robord 0x0 0x12
0x020b
root@OpenWrt:/# robocfg robord 0x0e
Page 0x00, Reg 0x0e: 00bb
root@OpenWrt:/# robocfg robord 0x12
Page 0x00, Reg 0x12: 0321
1. Fix led control register:
On normal ports only one led was used for both link and activity
(green),
internet port additionally had orange led on all the time.
I compared the value of registry 0x12 on linksys firmware vs openwrt,
and
it showed a different value (0x20b for linksys vs 0x321 on openwrt).
Now the green led is always used to signal link, the orange led (only)
blinks on link activity.
2. Adjust IMP port status
As I was comparing register values/bcmrobo.c source code, I noticed a
difference for the IMP port status register (0x0e), linksys firmware
showed
0x8b vs 0xbb for openwrt.
From bcmrobo.c - int bcm_robo_enable_switch:
if ((robo-devid == DEVID53115) || (robo-devid == DEVID53125))
{
/* Over ride IMP port status to make it link by default
*/
val8 = 0;
robo-ops-read_reg(robo, PAGE_CTRL, REG_CTRL_MIIPO,
val8,
sizeof(val8));
val8 |= 0x81; /* Make Link pass and override it. */
robo-ops-write_reg(robo, PAGE_CTRL, REG_CTRL_MIIPO,
val8,
sizeof(val8));
}
Hauke, did you use '0xb1' intentionally instead of '0x81'? Or do we
want
this to be the same?
I used the Asus ac66u source code as a reference as this contains the
most recent source code I know of. There val8 |= 0xb1; is used.
Bits 5 and 6 enable rx/tx flow control - not sure if this is
potentially harmfull or not.
Does chaining this to 0x81 changes the behavior of your device?
Signed-off-by: Tijs Van Buggenhout t...@able.be
diff --git a/package/switch/src/switch-robo.c
b/package/switch/src/switch-
robo.c
index f715972..ac4855a 100644
--- a/package/switch/src/switch-robo.c
+++ b/package/switch/src/switch-robo.c
@@ -252,8 +252,13 @@ static int robo_switch_enable(void)
if (robo.devid == ROBO_DEVICE_ID_53125) {
/* Make IM port status link by default */
- val = robo_read16(ROBO_CTRL_PAGE,
ROBO_PORT_OVERRIDE_CTRL) | 0xb1;
+ val = robo_read16(ROBO_CTRL_PAGE,
ROBO_PORT_OVERRIDE_CTRL) | 0x81;
robo_write16(ROBO_CTRL_PAGE, ROBO_PORT_OVERRIDE_CTRL,
val);
+
+ /* Write LED control register */
+ val = 0x020b;
+ robo_write16(ROBO_CTRL_PAGE, 0x12, val);
+
With this change my Asus n66u does not blink on activity any more.
Maybe there is some nvram value for it? the led configuration is
likely device specific, not chip specific.
Jonas
'et_swleds' nvram variable seems to be intended for this purpose, but
doesn't (seem to) exist by default for the e3200.. is it for the asus?
No, et_swleds is not set on any of my devices.
This code change is probably the device specific configuration.
I found the following code in the switch driver and it is missing in
kmod-switch. You could try to implement that, si_pmu_chipcontrol() is
the same as bcma_chipco_chipctl_maskset() expect that you have to
inverse the mask parameter.
/* Enable switch leds */
if (sih-chip == BCM5356_CHIP_ID) {
si_pmu_chipcontrol(sih, 2, (1 25), (1 25));
/* also enable fast MII clocks */
si_pmu_chipcontrol(sih, 0, (1 1), (1 1));
} else if ((sih-chip == BCM5357_CHIP_ID) || (sih-chip ==
BCM53572_CHIP_ID)) {
uint32 led_gpios = 0;
const char *var;
if (((sih-chip == BCM5357_CHIP_ID) (sih-chippkg !=
BCM47186_PKG_ID)) ||
((sih-chip == BCM53572_CHIP_ID) (sih-chippkg !=
BCM47188_PKG_ID)))
led_gpios = 0x1f;
var = getvar(vars, et_swleds);
if (var)
led_gpios = bcm_strtoul(var, NULL, 0);
if (led_gpios)
si_pmu_chipcontrol(sih, 2, (0x3ff 8), (led_gpios 8));
}
I was looking at the same code, tried even patching in bcma code, but then it
occured to me that the e3200 seems to have BCM47186_PKG_ID. The leds are
enabled by default on the switch, and thus don't need to be explicitely
enabled I guess.. I tried the following patch:
--- a/drivers/bcma/driver_chipcommon_pmu.c.orig 2013-02-20
12:41:03.026487835 +0100
+++ b/drivers/bcma/driver_chipcommon_pmu.c2013-02-25 17:16:01.072808066
+0100
@@ -139,6 +139,24
Re: [OpenWrt-Devel] [PATCH] bgmac - add support for unaligned addressing
On Monday 25 February 2013 20:35:23 Tijs Van Buggenhout wrote:
On Monday 25 February 2013 18:51:53 Rafał Miłecki wrote:
2013/2/25 Tijs Van Buggenhout t...@able.be:
I opted to introduce a CONFIG_BGMAC_UNALIGNED_ADDRESSING macro to
introduce
the changes to support unaligned addressing for the bgmac driver (it
does
add some extra bytes in bgmac_dma_ring struct). This could be an option
in Kconfig (not yet in patch), but for now it is defined fix in bgmac.h.
The
implementation should work for both aligned and unaligned addressing
when
CONFIG_BGMAC_UNALIGNED_ADDRESSING is defined.
I don't think we should need CONFIG_BGMAC_UNALIGNED_ADDRESSING, it
doesn't save a lot of size (when disabled) and makes configuration
more confusing.
I'll get rid of the defines, and create another patch ;-)
If there is no need for en extra Kconfig option, let me know, I'll
adjust
the patch. In the other case, I'll create an extra entry in Kconfig and
add it to the patch aswell. I created the patch from 3.6 kernel sources,
let me know if there are differences for the 3.8 kernel.
Kernel 3.6 doesn't include bgmac at all ;)
Building from openwrt trunk, which configures a 3.6.11 kernel by default,
where bgmac is patched in?
I hope this can be tested on different hardware supporting dma
aligned/unaligned addressing, it should work on both. Any
comments/suggestions are welcome..
I'll give it a try on my BCM4706s, just give me some time.
No problem, take your time ;-)
Note: Besides the changes for unaligned addressing, I corrected some
types
for variables and formats. I also introduced an extra int j variable in
the second loop within dma initialisation of rx ring(s).. from my
understanding reusing the int i variable in the inner loop breaks the
outer loop if there would be more than one rx ring.
That definitely should go in separated patches.
I'll separate them into different patches. The loop variable fix is already
settled
Signed-off-by: Tijs Van Buggenhout (t...@able.be)
Your whole patch is malformed, there are extra line breaks and tabs
were eaten by your mailer.
It's a cpp from a cat'ed diff on console. Email client does a line wrap
after 80 characters in plain text. Will try as attachment next time...
@@ -384,6 +388,10 @@
u16 mmio_base;
struct bgmac_dma_desc *cpu_base;
dma_addr_t dma_base;
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ bool is_unaligned;
+ u32 index_base;
I'm pretty sure it's some duplication, we already store address somewhere
else.
Correct, but has implicit 0 value, when it is not assigned. Avoiding if
conditions in the rest of the code.
@@ -156,6 +156,9 @@
if (++ring-end = BGMAC_TX_RING_SLOTS)
ring-end = 0;
bgmac_write(bgmac, ring-mmio_base + BGMAC_DMA_TX_INDEX,
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ ring-index_base +
+#endif
Note: If we de-duplicate index_base we have to add that conditionally.
Indeed .. we could go for the bool is_unaligned, and write something like
'((is_unaligned ? lower_32_bits( ring-dma_base ) : 0 ) + ' or would you
prefer a normal if statement.
We could also go for a local variable index_base in the corresponding
functions, which is initialised to 0 or set to the correct value in case of
unalignment.
+ if (ring-start == ring-end) {
+ bgmac_warn(bgmac, Ignore DMA TX free on empty ring
0x%X\n, ring-mmio_base);
+ return;
+ }
+
Is that supposed to happen? I've to analyze that part :)
We can leave it out.. it's an optimisation (BGMAC_DMA_TX_STATUS doesn't need
to be read). I saw the warning appear a few times on my screen today, so
the message print is better left out anyways.
/* The last slot that hardware didn't consume yet */
empty_slot = bgmac_read(bgmac, ring-mmio_base +
BGMAC_DMA_TX_STATUS);
empty_slot = BGMAC_DMA_TX_STATDPTR;
+#ifdef CONFIG_BGMAC_UNALIGNED_ADDRESSING
+ empty_slot -= ring-index_base;
+ empty_slot = BGMAC_DMA_TX_STATDPTR;
+#endif
empty_slot /= sizeof(struct bgmac_dma_desc);
Do we need to mask that twice?
I kept as close to the broadcom sources as possible. Keeping in mind that
empty_slot is an u16, bgmac_read returns an u32 as is index_base, it's
probably best (for clarity) to write:
empty_slot = ( bgmac_read(bgmac, ring-mmio_base + BGMAC_DMA_TX_STATUS)
BGMAC_DMA_TX_STATDPTR );
empty_slot -= ( ring-index_base BGMAC_DMA_TX_STATDPTR )
but
empty_slot = (( bgmac_read(bgmac, ring-mmio_base + BGMAC_DMA_TX_STATUS) -
ring-index_base ) BGMAC_DMA_TX_STATDPTR );
can avoid the extra mask. Should I include an extra type cast (u16)?
+ if (((ring-start == 0
Re: [OpenWrt-Devel] Linksys E4200v1 Support
On Thursday 21 February 2013 18:40:20 Tijs Van Buggenhout wrote:
On Thursday 21 February 2013 16:13:07 Hauke Mehrtens wrote:
On 02/20/2013 02:46 PM, Cezary Jackiewicz wrote:
Dnia 2013-02-20, o godz. 14:11:53
Hauke Mehrtens ha...@hauke-m.de napisa?(a):
On my e3200 Ethernet works with the default config. Are there more
problems discussed in this tread?
On my e3200 also ethernet seems to work, but often hangs up with:
[ 121.98] bgmac bcma0:1: Hardware reported transmission for empty
TX
ring slot 120! End of ring: 0 [ 121.988000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 121! End of ring: 0 [
121.996000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 122! End of ring: 0 [ 122.008000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 123! End of ring: 0 [
122.016000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 124! End of ring: 0 [ 122.024000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 125! End of ring: 0 [
122.036000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 126! End of ring: 0 [ 122.044000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 127! End of ring: 0 [
122.052000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 0! End of ring: 0 [ 122.064000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 1! End of ring: 0 [
122.072000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 2! End of ring: 0 [ 122.08] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 3! End of ring: 0 [
122.088000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 4! End of ring: 0 [ 122.10] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 5! End of ring: 0 [
122.108000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 6! End of ring: 0 [ 122.116000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 7! End of ring: 0 [
122.128000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 8! End of ring: 0 [ 122.136000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 9! End of ring: 0
etc.
I have seen the same problem with my e3200. When this happens I see
~17MByte/s of garbage traffic on the NIC of my desktop connected to this
devices. It looks like it sends out old packages or parts of it in an
endless loop. Most of them did not contained a valid Ethernet header but
some contained the OpenWrt logo, where I expected an Ethernet or IP
header. ;-)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I notice the same behaviour here. I see this happen regularly, when booting
the device, without network cables plugged in, or no network traffic being
received. By default, an udhcp client is run on internet interface, which
sends out packets, but no answer is (ever) returned.
After about 300 seconds, the driver will start reporting these messages,
after a while the system reboots.
I made a tcpdump on the wan port, which shows only udp dhcp requests being
sent. At the moment the driver starts reporting, I can see two packets being
echoed from the past (dhcp requests hold the 'seconds elapsed' field, which
normally only augments).
Packets sent out, with increasing seconds elapsed:
17:53:54.097432 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys.D.C.gl.1.Us.q..
.K!.s..c.Sc5..9..@7...*.udhcp
1.19.4.
17:53:57.098021 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys.D.C.gl.1.Us.t..
.K!.s..c.Sc5..9..@7...*.udhcp
1.19.4.
17:54:00.101515 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys.D.C.gl.1.Us.w..
.K!.s
[OpenWrt-Devel] [PATCH] kmod-switch : Fix led control register - adjust IMP port status
From linksys firmware :
# et -i eth0 robord 0x0 0x0e
0x008b
# et -i eth0 robord 0x0 0x12
0x020b
root@OpenWrt:/# robocfg robord 0x0e
Page 0x00, Reg 0x0e: 00bb
root@OpenWrt:/# robocfg robord 0x12
Page 0x00, Reg 0x12: 0321
1. Fix led control register:
On normal ports only one led was used for both link and activity (green),
internet port additionally had orange led on all the time.
I compared the value of registry 0x12 on linksys firmware vs openwrt, and it
showed a different value (0x20b for linksys vs 0x321 on openwrt).
Now the green led is always used to signal link, the orange led (only) blinks
on link activity.
2. Adjust IMP port status
As I was comparing register values/bcmrobo.c source code, I noticed a
difference for the IMP port status register (0x0e), linksys firmware showed
0x8b vs 0xbb for openwrt.
From bcmrobo.c - int bcm_robo_enable_switch:
if ((robo-devid == DEVID53115) || (robo-devid == DEVID53125)) {
/* Over ride IMP port status to make it link by default */
val8 = 0;
robo-ops-read_reg(robo, PAGE_CTRL, REG_CTRL_MIIPO, val8,
sizeof(val8));
val8 |= 0x81; /* Make Link pass and override it. */
robo-ops-write_reg(robo, PAGE_CTRL, REG_CTRL_MIIPO, val8,
sizeof(val8));
}
Hauke, did you use '0xb1' intentionally instead of '0x81'? Or do we want this
to be the same?
Signed-off-by: Tijs Van Buggenhout t...@able.be
diff --git a/package/switch/src/switch-robo.c b/package/switch/src/switch-
robo.c
index f715972..ac4855a 100644
--- a/package/switch/src/switch-robo.c
+++ b/package/switch/src/switch-robo.c
@@ -252,8 +252,13 @@ static int robo_switch_enable(void)
if (robo.devid == ROBO_DEVICE_ID_53125) {
/* Make IM port status link by default */
- val = robo_read16(ROBO_CTRL_PAGE, ROBO_PORT_OVERRIDE_CTRL) |
0xb1;
+ val = robo_read16(ROBO_CTRL_PAGE, ROBO_PORT_OVERRIDE_CTRL) |
0x81;
robo_write16(ROBO_CTRL_PAGE, ROBO_PORT_OVERRIDE_CTRL, val);
+
+ /* Write LED control register */
+ val = 0x020b;
+ robo_write16(ROBO_CTRL_PAGE, 0x12, val);
+
// TODO: init EEE feature
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kmod-switch : Fix led control register - adjust IMP port status
On Thursday 21 February 2013 15:53:40 Hauke Mehrtens wrote:
On 02/21/2013 02:57 PM, Tijs Van Buggenhout wrote:
From linksys firmware :
# et -i eth0 robord 0x0 0x0e
0x008b
# et -i eth0 robord 0x0 0x12
0x020b
root@OpenWrt:/# robocfg robord 0x0e
Page 0x00, Reg 0x0e: 00bb
root@OpenWrt:/# robocfg robord 0x12
Page 0x00, Reg 0x12: 0321
1. Fix led control register:
On normal ports only one led was used for both link and activity (green),
internet port additionally had orange led on all the time.
I compared the value of registry 0x12 on linksys firmware vs openwrt, and
it showed a different value (0x20b for linksys vs 0x321 on openwrt).
Now the green led is always used to signal link, the orange led (only)
blinks on link activity.
2. Adjust IMP port status
As I was comparing register values/bcmrobo.c source code, I noticed a
difference for the IMP port status register (0x0e), linksys firmware
showed
0x8b vs 0xbb for openwrt.
From bcmrobo.c - int bcm_robo_enable_switch:
if ((robo-devid == DEVID53115) || (robo-devid == DEVID53125)) {
/* Over ride IMP port status to make it link by default */
val8 = 0;
robo-ops-read_reg(robo, PAGE_CTRL, REG_CTRL_MIIPO,
val8,
sizeof(val8));
val8 |= 0x81; /* Make Link pass and override it. */
robo-ops-write_reg(robo, PAGE_CTRL, REG_CTRL_MIIPO,
val8,
sizeof(val8));
}
Hauke, did you use '0xb1' intentionally instead of '0x81'? Or do we want
this to be the same?
I used the Asus ac66u source code as a reference as this contains the
most recent source code I know of. There val8 |= 0xb1; is used.
Does chaining this to 0x81 changes the behavior of your device?
Not so far as I noticed.. 0xbb has the same bits on as 0x8b, and two extra
(bits 5 and 6).
Signed-off-by: Tijs Van Buggenhout t...@able.be
diff --git a/package/switch/src/switch-robo.c b/package/switch/src/switch-
robo.c
index f715972..ac4855a 100644
--- a/package/switch/src/switch-robo.c
+++ b/package/switch/src/switch-robo.c
@@ -252,8 +252,13 @@ static int robo_switch_enable(void)
if (robo.devid == ROBO_DEVICE_ID_53125) {
/* Make IM port status link by default */
- val = robo_read16(ROBO_CTRL_PAGE, ROBO_PORT_OVERRIDE_CTRL)
| 0xb1;
+ val = robo_read16(ROBO_CTRL_PAGE, ROBO_PORT_OVERRIDE_CTRL)
| 0x81;
robo_write16(ROBO_CTRL_PAGE, ROBO_PORT_OVERRIDE_CTRL,
val);
+
+ /* Write LED control register */
+ val = 0x020b;
+ robo_write16(ROBO_CTRL_PAGE, 0x12, val);
+
With this change my Asus n66u does not blink on activity any more.
Odd indeed! What is the default setting for this register on the asus n66u? Is
it the same as 0x321? Maybe I can test that one on the e3200?
I can make a dump of page 0 registers, for comparison...
// TODO: init EEE feature
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Linksys E4200v1 Support
On Thursday 21 February 2013 16:13:07 Hauke Mehrtens wrote:
On 02/20/2013 02:46 PM, Cezary Jackiewicz wrote:
Dnia 2013-02-20, o godz. 14:11:53
Hauke Mehrtens ha...@hauke-m.de napisał(a):
On my e3200 Ethernet works with the default config. Are there more
problems discussed in this tread?
On my e3200 also ethernet seems to work, but often hangs up with:
[ 121.98] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 120! End of ring: 0 [ 121.988000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 121! End of ring: 0 [
121.996000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 122! End of ring: 0 [ 122.008000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 123! End of ring: 0 [
122.016000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 124! End of ring: 0 [ 122.024000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 125! End of ring: 0 [
122.036000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 126! End of ring: 0 [ 122.044000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 127! End of ring: 0 [
122.052000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 0! End of ring: 0 [ 122.064000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 1! End of ring: 0 [
122.072000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 2! End of ring: 0 [ 122.08] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 3! End of ring: 0 [
122.088000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 4! End of ring: 0 [ 122.10] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 5! End of ring: 0 [
122.108000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 6! End of ring: 0 [ 122.116000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 7! End of ring: 0 [
122.128000] bgmac bcma0:1: Hardware reported transmission for empty TX
ring slot 8! End of ring: 0 [ 122.136000] bgmac bcma0:1: Hardware
reported transmission for empty TX ring slot 9! End of ring: 0
etc.
I have seen the same problem with my e3200. When this happens I see
~17MByte/s of garbage traffic on the NIC of my desktop connected to this
devices. It looks like it sends out old packages or parts of it in an
endless loop. Most of them did not contained a valid Ethernet header but
some contained the OpenWrt logo, where I expected an Ethernet or IP
header. ;-)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
I notice the same behaviour here. I see this happen regularly, when booting
the device, without network cables plugged in, or no network traffic being
received. By default, an udhcp client is run on internet interface, which
sends out packets, but no answer is (ever) returned.
After about 300 seconds, the driver will start reporting these messages, after
a while the system reboots.
I made a tcpdump on the wan port, which shows only udp dhcp requests being
sent. At the moment the driver starts reporting, I can see two packets being
echoed from the past (dhcp requests hold the 'seconds elapsed' field, which
normally only augments).
Packets sent out, with increasing seconds elapsed:
17:53:54.097432 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys.D.C.gl.1.Us.q..
.K!.s..c.Sc5..9..@7...*.udhcp
1.19.4.
17:53:57.098021 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys.D.C.gl.1.Us.t..
.K!.s..c.Sc5..9..@7...*.udhcp
1.19.4.
17:54:00.101515 IP 0.0.0.0.bootpc 255.255.255.255.bootps: BOOTP/DHCP,
Request from 20:aa:4b:21:19:73 (oui Unknown), length 351
E..{@.ys.D.C.gl.1.Us.w..
.K!.s..c.Sc5..9..@7...*.udhcp
Re: [OpenWrt-Devel] Linksys E4200v1 Support
On Wednesday 20 February 2013 14:11:53 Hauke Mehrtens wrote: On 02/18/2013 10:51 AM, Tijs Van Buggenhout wrote: On Monday 18 February 2013 04:30:14 Chirag Chhatriwala wrote: Tijs: Are you using your settings on vlan0ports vlan1ports OR vlan1ports vlan2ports I had a glance at vlanports assignment in OpenWRT, Tomato and DD-WRT and I found that openwrt uses vlan[01]ports (according to the patchfile provided by Haukehttps://dev.openwrt.org/changeset/35597 https://dev.openwrt.org/changeset/35597) Tomato and DD-WRT use vlan[12]ports for port assignments. All this is armchair programming as I have yet to receive my UART module and cable to work with the E4200. However, I do want to get to the bottom of this issue given that I want to understand the openwrt assignment using vlan[01]ports and not vlan[12]ports (unlike Tomato DD-WRT). I apologize if I'm cross referencing the two alternatives to OpenWRT but thats the only info I can go on so far. Thanks, Chirag On Mon, Feb 18, 2013 at 3:12 AM, Tijs Van Buggenhout t...@able.be mailto:t...@able.be wrote: On Thursday 14 February 2013 18:35:48 Chirag Chhatriwala wrote: Hi All, I'm trying to get additional info. Hauke: per your latest response indicating the changeset: https://dev.openwrt.org/changeset/35597 This will not work for E4200v1. I just dug a few things from the tomato source tree. Line 36: http://repo.or.cz/w/tomato.git/blob/tomato-RT:/release/src/router/shared/ id.c Shows much of the E4200 v1 board related identification Also: http://repo.or.cz/w/tomato.git/blob/tomato-RT:/release/src/router/rc/init .c shows vlan[01]ports initializations settings, which do not match the patch you mention. I am not sure what else is needed to make sure the proper initializations are in place for the switch to come up. Wifi (according to broadcom-wl) should just work. However, I'm worried more about the switch. Thanks, Chirag On Thu, Feb 14, 2013 at 7:41 AM, Hauke Mehrtens ha...@hauke-m.de mailto:ha...@hauke-m.de wrote: On 02/14/2013 07:30 AM, Nathan Hintz wrote: On Wed, 2013-02-13 at 19:03 -0800, Nathan Hintz wrote: On Wed, 2013-02-13 at 22:46 +0100, Hauke Mehrtens wrote: On 02/13/2013 10:33 PM, Chirag Chhatriwala wrote: Hi All, I've notcied a huge deal of progress with bgmac in the recent month and was willing to help bring support for the E4200v1. I own one of these devices but I'm not too familiar with the entire driver process. Also, I haven't flashed anything via serial/uart or JTAG as I'm simply familiar with flashing via tftp method. I've reached out to Rafal and Nathan for advice as well. Firstly, I wanted to know if there is anyone who owns one of these and can help with enabling OpenWrt support. I can certainly help in any way I can. I'm sure there are several folks out there who own one of these and I could mean a lot to revive their E4200v1 with OpenWrt support. I simply wish I had another one of these to donate to the OpenWrt devs for the cause. Thanks, Chirag Hi Chirag, Your device should work, at least Ethernet wifi probably not. When you have a serial console connected to your device just flash OpenWrt or boot it from the network and report your results. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org mailto:openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Will the ethernet work if the device is not recognized by /etc/init.d/netconfig? It sounded like it had a different nvram value for boardtype? I've never booted my E3000 from the network, and tftp only works for me from a serial console using upgrade code.bin (I think my CFE is possibly broken). What command do you use when you boot from the network; and do you need a factory .bin image, or does the generic .trx work for this? Thanks, Nathan Hi Hauke: I saw that /etc/init.d/netconfig has additional boardtype values added. Is the E4200v1 one of those added? Chirag didn't have an nvram dump, but he had a reference to a tomato issue that indicated it might be 0xF52C. Also, a patch had been added to the set maintained at http://www.znau.edu.ua/temp/asus-rt-n16/2012-12-08T15-25/003-openwrt4716-T ARGET_brcm4716-Linksys-E2000.patch that indicated the E2000 has a boardtype of 0x04EF; although the same tomato reference has that one in lower case for WRT320N/E2000. This list would have never been complete so now it is checked where the CPU port is and if it is port 8, this port is used instead of port 5 in the default switch configuration, see [0]. Hauke [0]: https://dev.openwrt.org/changeset/35597
Re: [OpenWrt-Devel] Linksys E4200v1 Support
On Thursday 14 February 2013 11:24:50 you wrote: On 02/14/2013 11:18 AM, Florian Fainelli wrote: Hello, On 02/14/2013 09:39 AM, Tijs Van Buggenhout wrote: [snip] Device eth0: hwaddr 00-00-00-00-00-00, ipaddr 192.168.1.1, mask 255.255.255.0 gateway not set, nameserver not set cfe_led_init: start to set power LED and switch LEDs. Loader:raw Filesys:tftp Dev:eth0 File:: Options:(null) Loading: .. 10679296 bytes read Entry at 0x807a0440 Loader:raw Filesys:memory Dev:eth0 File::0x807a0440 Options:(null) Loading: . 0 bytes read Failed. Could not load :0x807a0440: Error CFE You should be able to use load -elf to ensure that the file you want to load is an ELF one. I am not sure whether this is available for your specific device though. Playing with load help will give you more infos. The load command is available ... help load gives more information ;-) There is also a wiki page about network boot with CFE: http://wiki.openwrt.org/doc/hardware/soc/soc.broadcom.bcm47xx#network.boot Hauke CFE boot -tftp -elf 192.168.1.113:openwrt-brcm47xx-vmlinux.elf Loader:elf Filesys:tftp Dev:eth0 File:192.168.1.113:openwrt-brcm47xx- vmlinux.elf Options:(null) Loading: 0x80001000/6802772 0x8067dd54/234764 Entry at 0x802512e0 Closing network. Starting program at 0x802512e0 Works nicely,thanks! Would there also be a way to have the system load an image (elf/bin) automatically? When I start up the device, it seems to have started a tftp server, but thus far unclear to what purpose or how it can be used (putting an elf/bin openwrt image fails). Regards, Tijs___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Linksys E4200v1 Support
On Thursday 14 February 2013 18:35:48 Chirag Chhatriwala wrote: Hi All, I'm trying to get additional info. Hauke: per your latest response indicating the changeset: https://dev.openwrt.org/changeset/35597 This will not work for E4200v1. I just dug a few things from the tomato source tree. Line 36: http://repo.or.cz/w/tomato.git/blob/tomato- RT:/release/src/router/shared/id.c Shows much of the E4200 v1 board related identification Also: http://repo.or.cz/w/tomato.git/blob/tomato- RT:/release/src/router/rc/init.c shows vlan[01]ports initializations settings, which do not match the patch you mention. I am not sure what else is needed to make sure the proper initializations are in place for the switch to come up. Wifi (according to broadcom-wl) should just work. However, I'm worried more about the switch. Thanks, Chirag On Thu, Feb 14, 2013 at 7:41 AM, Hauke Mehrtens ha...@hauke-m.de wrote: On 02/14/2013 07:30 AM, Nathan Hintz wrote: On Wed, 2013-02-13 at 19:03 -0800, Nathan Hintz wrote: On Wed, 2013-02-13 at 22:46 +0100, Hauke Mehrtens wrote: On 02/13/2013 10:33 PM, Chirag Chhatriwala wrote: Hi All, I've notcied a huge deal of progress with bgmac in the recent month and was willing to help bring support for the E4200v1. I own one of these devices but I'm not too familiar with the entire driver process. Also, I haven't flashed anything via serial/uart or JTAG as I'm simply familiar with flashing via tftp method. I've reached out to Rafal and Nathan for advice as well. Firstly, I wanted to know if there is anyone who owns one of these and can help with enabling OpenWrt support. I can certainly help in any way I can. I'm sure there are several folks out there who own one of these and I could mean a lot to revive their E4200v1 with OpenWrt support. I simply wish I had another one of these to donate to the OpenWrt devs for the cause. Thanks, Chirag Hi Chirag, Your device should work, at least Ethernet wifi probably not. When you have a serial console connected to your device just flash OpenWrt or boot it from the network and report your results. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Will the ethernet work if the device is not recognized by /etc/init.d/netconfig? It sounded like it had a different nvram value for boardtype? I've never booted my E3000 from the network, and tftp only works for me from a serial console using upgrade code.bin (I think my CFE is possibly broken). What command do you use when you boot from the network; and do you need a factory .bin image, or does the generic .trx work for this? Thanks, Nathan Hi Hauke: I saw that /etc/init.d/netconfig has additional boardtype values added. Is the E4200v1 one of those added? Chirag didn't have an nvram dump, but he had a reference to a tomato issue that indicated it might be 0xF52C. Also, a patch had been added to the set maintained at http://www.znau.edu.ua/temp/asus-rt-n16/2012-12-08T15-25/003-openwrt4716- TARGET_brcm4716-Linksys-E2000.patch that indicated the E2000 has a boardtype of 0x04EF; although the same tomato reference has that one in lower case for WRT320N/E2000. This list would have never been complete so now it is checked where the CPU port is and if it is port 8, this port is used instead of port 5 in the default switch configuration, see [0]. Hauke [0]: https://dev.openwrt.org/changeset/35597 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel 437 case MODEL_E4200: 438 dirty |= check_nv(vlan1ports, 0 1 2 3 8*); 439 dirty |= check_nv(vlan2ports, 4 8); I've been using the same settings for the e3200 (port 4 is wan/internet port). Regards, Tijs___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Linksys E4200v1 Support
On Monday 18 February 2013 04:30:14 Chirag Chhatriwala wrote: Tijs: Are you using your settings on vlan0ports vlan1ports OR vlan1ports vlan2ports I had a glance at vlanports assignment in OpenWRT, Tomato and DD-WRT and I found that openwrt uses vlan[01]ports (according to the patchfile provided by Hauke https://dev.openwrt.org/changeset/35597) Tomato and DD-WRT use vlan[12]ports for port assignments. All this is armchair programming as I have yet to receive my UART module and cable to work with the E4200. However, I do want to get to the bottom of this issue given that I want to understand the openwrt assignment using vlan[01]ports and not vlan[12]ports (unlike Tomato DD-WRT). I apologize if I'm cross referencing the two alternatives to OpenWRT but thats the only info I can go on so far. Thanks, Chirag On Mon, Feb 18, 2013 at 3:12 AM, Tijs Van Buggenhout t...@able.be wrote: On Thursday 14 February 2013 18:35:48 Chirag Chhatriwala wrote: Hi All, I'm trying to get additional info. Hauke: per your latest response indicating the changeset: https://dev.openwrt.org/changeset/35597 This will not work for E4200v1. I just dug a few things from the tomato source tree. Line 36: http://repo.or.cz/w/tomato.git/blob/tomato- RT:/release/src/router/shared/id.c Shows much of the E4200 v1 board related identification Also: http://repo.or.cz/w/tomato.git/blob/tomato- RT:/release/src/router/rc/init.c shows vlan[01]ports initializations settings, which do not match the patch you mention. I am not sure what else is needed to make sure the proper initializations are in place for the switch to come up. Wifi (according to broadcom-wl) should just work. However, I'm worried more about the switch. Thanks, Chirag On Thu, Feb 14, 2013 at 7:41 AM, Hauke Mehrtens ha...@hauke-m.de wrote: On 02/14/2013 07:30 AM, Nathan Hintz wrote: On Wed, 2013-02-13 at 19:03 -0800, Nathan Hintz wrote: On Wed, 2013-02-13 at 22:46 +0100, Hauke Mehrtens wrote: On 02/13/2013 10:33 PM, Chirag Chhatriwala wrote: Hi All, I've notcied a huge deal of progress with bgmac in the recent month and was willing to help bring support for the E4200v1. I own one of these devices but I'm not too familiar with the entire driver process. Also, I haven't flashed anything via serial/uart or JTAG as I'm simply familiar with flashing via tftp method. I've reached out to Rafal and Nathan for advice as well. Firstly, I wanted to know if there is anyone who owns one of these and can help with enabling OpenWrt support. I can certainly help in any way I can. I'm sure there are several folks out there who own one of these and I could mean a lot to revive their E4200v1 with OpenWrt support. I simply wish I had another one of these to donate to the OpenWrt devs for the cause. Thanks, Chirag Hi Chirag, Your device should work, at least Ethernet wifi probably not. When you have a serial console connected to your device just flash OpenWrt or boot it from the network and report your results. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Will the ethernet work if the device is not recognized by /etc/init.d/netconfig? It sounded like it had a different nvram value for boardtype? I've never booted my E3000 from the network, and tftp only works for me from a serial console using upgrade code.bin (I think my CFE is possibly broken). What command do you use when you boot from the network; and do you need a factory .bin image, or does the generic .trx work for this? Thanks, Nathan Hi Hauke: I saw that /etc/init.d/netconfig has additional boardtype values added. Is the E4200v1 one of those added? Chirag didn't have an nvram dump, but he had a reference to a tomato issue that indicated it might be 0xF52C. Also, a patch had been added to the set maintained at http://www.znau.edu.ua/temp/asus-rt-n16/2012-12-08T15-25/003-openwrt4716- TARGET_brcm4716-Linksys-E2000.patch that indicated the E2000 has a boardtype of 0x04EF; although the same tomato reference has that one in lower case for WRT320N/E2000. This list would have never been complete so now it is checked where the CPU port is and if it is port 8, this port is used instead of port 5 in the default switch configuration, see [0]. Hauke [0]: https://dev.openwrt.org/changeset/35597 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel 437 case MODEL_E4200: 438 dirty |= check_nv(vlan1ports, 0 1 2 3 8*); 439 dirty |= check_nv(vlan2ports, 4 8); I've been using the same settings for the e3200 (port 4 is wan/internet port). Regards, Tijs ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https
Re: [OpenWrt-Devel] Linksys E4200v1 Support
On Wednesday 13 February 2013 19:03:38 Nathan Hintz wrote: On Wed, 2013-02-13 at 22:46 +0100, Hauke Mehrtens wrote: On 02/13/2013 10:33 PM, Chirag Chhatriwala wrote: Hi All, I've notcied a huge deal of progress with bgmac in the recent month and was willing to help bring support for the E4200v1. I own one of these devices but I'm not too familiar with the entire driver process. Also, I haven't flashed anything via serial/uart or JTAG as I'm simply familiar with flashing via tftp method. I've reached out to Rafal and Nathan for advice as well. Firstly, I wanted to know if there is anyone who owns one of these and can help with enabling OpenWrt support. I can certainly help in any way I can. I'm sure there are several folks out there who own one of these and I could mean a lot to revive their E4200v1 with OpenWrt support. I simply wish I had another one of these to donate to the OpenWrt devs for the cause. Thanks, Chirag Hi Chirag, Your device should work, at least Ethernet wifi probably not. When you have a serial console connected to your device just flash OpenWrt or boot it from the network and report your results. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel Will the ethernet work if the device is not recognized by /etc/init.d/netconfig? It sounded like it had a different nvram value for boardtype? I've never booted my E3000 from the network, and tftp only works for me from a serial console using upgrade code.bin (I think my CFE is possibly broken). What command do you use when you boot from the network; and do you need a factory .bin image, or does the generic .trx work for this? Thanks, Nathan ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel I can second the latter, I see the same for the E3200 device. I can use tftp with a .bin file at boot up, but the image will always fail to program. The upgrade code.bin from uboot always works. It shows the following: CFE version 1.0.37 for BCM947XX (32bit,SP,LE) Build Date: Thu Apr 21 02:03:27 HKT 2011 (zhaoguang@sw1) Copyright (C) 2000-2008 Broadcom Corporation. Init Arena Init Devs. This is a Serial Flash Boot partition size = 262144(0x4) Found a 16MB ST compatible serial flash et0: Broadcom BCM47XX 10/100/1000 Mbps Ethernet Controller 5.60.127.2901 @VERSION_TYPE@ CPU type 0x19749: 500MHz Tot mem: 65536 KBytes CFE mem:0x8070 - 0x807A0440 (656448) Data: 0x80735750 - 0x80739790 (16448) BSS:0x80739790 - 0x8073A440 (3248) Heap: 0x8073A440 - 0x8079E440 (409600) Stack: 0x8079E440 - 0x807A0440 (8192) Text: 0x8070 - 0x80735744 (218948) Boot version: v5.10 The boot is CFE Flash base: bfc0, mac start: 3ef00 mac_init(): Find mac [00:00:00:00:00:00] in location 0 Nothing... country_init(): Find country code in location 0 The country is same ### CLKDIV= 0x20e0842, SFlashClkDiv=2 clkdivsf=2 ### ### Change it to 0x20e0842 (2) ### Device eth0: hwaddr 00-00-00-00-00-00, ipaddr 192.168.1.1, mask 255.255.255.0 gateway not set, nameserver not set cfe_led_init: start to set power LED and switch LEDs. Loader:raw Filesys:tftp Dev:eth0 File:: Options:(null) Loading: .. 10679296 bytes read Entry at 0x807a0440 Loader:raw Filesys:memory Dev:eth0 File::0x807a0440 Options:(null) Loading: . 0 bytes read Failed. Could not load :0x807a0440: Error CFE Regards, Tijs___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
