Re: [OpenWrt-Devel] CC release dates? (Was Re: [PATCH 1/2] oxnas: re-add support for kernel 3.14)
i intentionally don't set a date. i have done so in the past and got ranted at for not being on time. this happened with AA and BB so CC is illusive and will be ready when ready. all i will say is that i am already working on it, but you noticed that yourself :) On 05/12/2014 02:20, Karl P wrote: That's the second[2] email I've seen that hints at some sort of formal date being known for CC, or some plan, or some detail. It would be appreciated if this magical special knowledge was shared a little wider. I haven't seen _any_ emails or irc conversations about _any_ dates or guidelines for any upcoming release. I can't see any release branches. I don't know where else I should be looking. Is there some release guidelines that I should know about? Have there been decisions taken by anyone? I'm not asking to be involved in the decision making process, but I would very much like to know when decisions have been made. Sincerely, Karl P [2]http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg27746.html On 12/04/2014 10:53 PM, John Crispin wrote: great, oxnas will now be part of CC :) On 04/12/2014 23:51, Daniel Golle wrote: This reverts commit c81de5fd193802d511b42eb7b108aac17136 on https://gitorious.org/openwrt-oxnas/openwrt-oxnas.git which removed patches and config for 3.14. [arm_introduce-dma-fiq-irq-broadcast patch was renamed to match 3.18] Signed-off-by: Daniel Golle dan...@makrotopia.org --- target/linux/oxnas/config-3.14 | 349 + .../010-arm_introduce-dma-fiq-irq-broadcast.patch | 62 ...-obtain-reset-controller-from-device-tree.patch | 99 ++ .../250-add-plxtech-vendor-prefix.patch| 12 + .../300-introduce-oxnas-platform.patch | 79 + .../oxnas/patches-3.14/310-oxnas-clocksource.patch | 24 ++ .../oxnas/patches-3.14/320-oxnas-irqchip.patch | 40 +++ .../oxnas/patches-3.14/330-oxnas-pinctrl.patch | 32 ++ .../linux/oxnas/patches-3.14/340-oxnas-pcie.patch | 23 ++ .../linux/oxnas/patches-3.14/350-oxnas-reset.patch | 20 ++ .../linux/oxnas/patches-3.14/400-oxnas-nand.patch | 28 ++ .../linux/oxnas/patches-3.14/500-oxnas-sata.patch | 30 ++ .../linux/oxnas/patches-3.14/800-oxnas-ehci.patch | 30 ++ .../linux/oxnas/patches-3.14/900-more-boards.patch | 16 + 14 files changed, 844 insertions(+) create mode 100644 target/linux/oxnas/config-3.14 create mode 100644 target/linux/oxnas/patches-3.14/010-arm_introduce-dma-fiq-irq-broadcast.patch create mode 100644 target/linux/oxnas/patches-3.14/100-obtain-reset-controller-from-device-tree.patch create mode 100644 target/linux/oxnas/patches-3.14/250-add-plxtech-vendor-prefix.patch create mode 100644 target/linux/oxnas/patches-3.14/300-introduce-oxnas-platform.patch create mode 100644 target/linux/oxnas/patches-3.14/310-oxnas-clocksource.patch create mode 100644 target/linux/oxnas/patches-3.14/320-oxnas-irqchip.patch create mode 100644 target/linux/oxnas/patches-3.14/330-oxnas-pinctrl.patch create mode 100644 target/linux/oxnas/patches-3.14/340-oxnas-pcie.patch create mode 100644 target/linux/oxnas/patches-3.14/350-oxnas-reset.patch create mode 100644 target/linux/oxnas/patches-3.14/400-oxnas-nand.patch create mode 100644 target/linux/oxnas/patches-3.14/500-oxnas-sata.patch create mode 100644 target/linux/oxnas/patches-3.14/800-oxnas-ehci.patch create mode 100644 target/linux/oxnas/patches-3.14/900-more-boards.patch diff --git a/target/linux/oxnas/config-3.14 b/target/linux/oxnas/config-3.14 new file mode 100644 index 000..727d81e --- /dev/null +++ b/target/linux/oxnas/config-3.14 @@ -0,0 +1,349 @@ +CONFIG_ALIGNMENT_TRAP=y +# CONFIG_APM_EMULATION is not set +CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAS_RESET_CONTROLLER=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set +CONFIG_ARCH_NR_GPIO=0 +CONFIG_ARCH_OXNAS=y +CONFIG_ARCH_REQUIRE_GPIOLIB=y +# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set +# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ARM=y +# CONFIG_ARM_CPU_SUSPEND is not set +CONFIG_ARM_GIC=y +CONFIG_ARM_L1_CACHE_SHIFT=5 +CONFIG_ARM_NR_BANKS=8 +CONFIG_ARM_PATCH_PHYS_VIRT=y +CONFIG_ARM_THUMB=y +CONFIG_ARM_UNWIND=y +CONFIG_ATA=y +CONFIG_AUTO_ZRELADDR=y +# CONFIG_BLK_DEV_INITRD is not set +CONFIG_BLK_DEV_SD=y +CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y +CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1 +CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y +CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1 +# CONFIG_CACHE_L2X0 is not set +CONFIG_CLKDEV_LOOKUP=y +CONFIG_CLKSRC_MMIO=y
Re: [OpenWrt-Devel] Need guidance to modify default vanilla OpenWRT settings
add a file in /etc/uci-defaults/ these get called on firstboot and are deleted after being run to add the file you need to make a package or you simply place the script in the files/ folder of your checkout John On 05/12/2014 08:16, Nguyen Nam wrote: Hi list, I posted request on forum but not get any reply, so have to send to the dev-list. My need is modify OpenWRT with some sensible settings for us (few SSID, enable ssh login,etc ), but I cannot found the right way yet. Checked with the firstlogin on OpenWRT site, but still not figured out where to hook to replace configs. The preinit 90_restore_config hook look quite interesting, should I use that hook to replace the configs? With best regards, Nguyen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] CC release dates? (Was Re: [PATCH 1/2] oxnas: re-add support for kernel 3.14)
Hi, do I understand it correctly. For CC is 3.14 planed? Thanks, Claudio -- Reviewing OpenWrt BB for Xmodus Systems XM1710E GSM/UMTS Router http://www.xmodus-systems.de/en/terminals/routers.html On 05.12.2014 09:07, John Crispin wrote: i intentionally don't set a date. i have done so in the past and got ranted at for not being on time. this happened with AA and BB so CC is illusive and will be ready when ready. all i will say is that i am already working on it, but you noticed that yourself :) On 05/12/2014 02:20, Karl P wrote: That's the second[2] email I've seen that hints at some sort of formal date being known for CC, or some plan, or some detail. It would be appreciated if this magical special knowledge was shared a little wider. I haven't seen _any_ emails or irc conversations about _any_ dates or guidelines for any upcoming release. I can't see any release branches. I don't know where else I should be looking. Is there some release guidelines that I should know about? Have there been decisions taken by anyone? I'm not asking to be involved in the decision making process, but I would very much like to know when decisions have been made. Sincerely, Karl P [2]http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg27746.html On 12/04/2014 10:53 PM, John Crispin wrote: great, oxnas will now be part of CC :) On 04/12/2014 23:51, Daniel Golle wrote: This reverts commit c81de5fd193802d511b42eb7b108aac17136 on https://gitorious.org/openwrt-oxnas/openwrt-oxnas.git which removed patches and config for 3.14. [arm_introduce-dma-fiq-irq-broadcast patch was renamed to match 3.18] Signed-off-by: Daniel Golle dan...@makrotopia.org --- target/linux/oxnas/config-3.14 | 349 + .../010-arm_introduce-dma-fiq-irq-broadcast.patch | 62 ...-obtain-reset-controller-from-device-tree.patch | 99 ++ .../250-add-plxtech-vendor-prefix.patch| 12 + .../300-introduce-oxnas-platform.patch | 79 + .../oxnas/patches-3.14/310-oxnas-clocksource.patch | 24 ++ .../oxnas/patches-3.14/320-oxnas-irqchip.patch | 40 +++ .../oxnas/patches-3.14/330-oxnas-pinctrl.patch | 32 ++ .../linux/oxnas/patches-3.14/340-oxnas-pcie.patch | 23 ++ .../linux/oxnas/patches-3.14/350-oxnas-reset.patch | 20 ++ .../linux/oxnas/patches-3.14/400-oxnas-nand.patch | 28 ++ .../linux/oxnas/patches-3.14/500-oxnas-sata.patch | 30 ++ .../linux/oxnas/patches-3.14/800-oxnas-ehci.patch | 30 ++ .../linux/oxnas/patches-3.14/900-more-boards.patch | 16 + 14 files changed, 844 insertions(+) create mode 100644 target/linux/oxnas/config-3.14 create mode 100644 target/linux/oxnas/patches-3.14/010-arm_introduce-dma-fiq-irq-broadcast.patch create mode 100644 target/linux/oxnas/patches-3.14/100-obtain-reset-controller-from-device-tree.patch create mode 100644 target/linux/oxnas/patches-3.14/250-add-plxtech-vendor-prefix.patch create mode 100644 target/linux/oxnas/patches-3.14/300-introduce-oxnas-platform.patch create mode 100644 target/linux/oxnas/patches-3.14/310-oxnas-clocksource.patch create mode 100644 target/linux/oxnas/patches-3.14/320-oxnas-irqchip.patch create mode 100644 target/linux/oxnas/patches-3.14/330-oxnas-pinctrl.patch create mode 100644 target/linux/oxnas/patches-3.14/340-oxnas-pcie.patch create mode 100644 target/linux/oxnas/patches-3.14/350-oxnas-reset.patch create mode 100644 target/linux/oxnas/patches-3.14/400-oxnas-nand.patch create mode 100644 target/linux/oxnas/patches-3.14/500-oxnas-sata.patch create mode 100644 target/linux/oxnas/patches-3.14/800-oxnas-ehci.patch create mode 100644 target/linux/oxnas/patches-3.14/900-more-boards.patch diff --git a/target/linux/oxnas/config-3.14 b/target/linux/oxnas/config-3.14 new file mode 100644 index 000..727d81e --- /dev/null +++ b/target/linux/oxnas/config-3.14 @@ -0,0 +1,349 @@ +CONFIG_ALIGNMENT_TRAP=y +# CONFIG_APM_EMULATION is not set +CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAS_RESET_CONTROLLER=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set +CONFIG_ARCH_NR_GPIO=0 +CONFIG_ARCH_OXNAS=y +CONFIG_ARCH_REQUIRE_GPIOLIB=y +# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set +# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ARM=y +# CONFIG_ARM_CPU_SUSPEND is not set +CONFIG_ARM_GIC=y +CONFIG_ARM_L1_CACHE_SHIFT=5 +CONFIG_ARM_NR_BANKS=8 +CONFIG_ARM_PATCH_PHYS_VIRT=y +CONFIG_ARM_THUMB=y +CONFIG_ARM_UNWIND=y +CONFIG_ATA=y +CONFIG_AUTO_ZRELADDR=y +# CONFIG_BLK_DEV_INITRD is not set +CONFIG_BLK_DEV_SD=y
Re: [OpenWrt-Devel] CC release dates? (Was Re: [PATCH 1/2] oxnas: re-add support for kernel 3.14)
yes, 3.14 is baseline for CC On 05/12/2014 09:45, Claudio Thomas wrote: Hi, do I understand it correctly. For CC is 3.14 planed? Thanks, Claudio -- Reviewing OpenWrt BB for Xmodus Systems XM1710E GSM/UMTS Router http://www.xmodus-systems.de/en/terminals/routers.html On 05.12.2014 09:07, John Crispin wrote: i intentionally don't set a date. i have done so in the past and got ranted at for not being on time. this happened with AA and BB so CC is illusive and will be ready when ready. all i will say is that i am already working on it, but you noticed that yourself :) On 05/12/2014 02:20, Karl P wrote: That's the second[2] email I've seen that hints at some sort of formal date being known for CC, or some plan, or some detail. It would be appreciated if this magical special knowledge was shared a little wider. I haven't seen _any_ emails or irc conversations about _any_ dates or guidelines for any upcoming release. I can't see any release branches. I don't know where else I should be looking. Is there some release guidelines that I should know about? Have there been decisions taken by anyone? I'm not asking to be involved in the decision making process, but I would very much like to know when decisions have been made. Sincerely, Karl P [2]http://www.mail-archive.com/openwrt-devel@lists.openwrt.org/msg27746.html On 12/04/2014 10:53 PM, John Crispin wrote: great, oxnas will now be part of CC :) On 04/12/2014 23:51, Daniel Golle wrote: This reverts commit c81de5fd193802d511b42eb7b108aac17136 on https://gitorious.org/openwrt-oxnas/openwrt-oxnas.git which removed patches and config for 3.14. [arm_introduce-dma-fiq-irq-broadcast patch was renamed to match 3.18] Signed-off-by: Daniel Golle dan...@makrotopia.org --- target/linux/oxnas/config-3.14 | 349 + .../010-arm_introduce-dma-fiq-irq-broadcast.patch | 62 ...-obtain-reset-controller-from-device-tree.patch | 99 ++ .../250-add-plxtech-vendor-prefix.patch | 12 + .../300-introduce-oxnas-platform.patch | 79 + .../oxnas/patches-3.14/310-oxnas-clocksource.patch | 24 ++ .../oxnas/patches-3.14/320-oxnas-irqchip.patch | 40 +++ .../oxnas/patches-3.14/330-oxnas-pinctrl.patch | 32 ++ .../linux/oxnas/patches-3.14/340-oxnas-pcie.patch | 23 ++ .../linux/oxnas/patches-3.14/350-oxnas-reset.patch | 20 ++ .../linux/oxnas/patches-3.14/400-oxnas-nand.patch | 28 ++ .../linux/oxnas/patches-3.14/500-oxnas-sata.patch | 30 ++ .../linux/oxnas/patches-3.14/800-oxnas-ehci.patch | 30 ++ .../linux/oxnas/patches-3.14/900-more-boards.patch | 16 + 14 files changed, 844 insertions(+) create mode 100644 target/linux/oxnas/config-3.14 create mode 100644 target/linux/oxnas/patches-3.14/010-arm_introduce-dma-fiq-irq-broadcast.patch create mode 100644 target/linux/oxnas/patches-3.14/100-obtain-reset-controller-from-device-tree.patch create mode 100644 target/linux/oxnas/patches-3.14/250-add-plxtech-vendor-prefix.patch create mode 100644 target/linux/oxnas/patches-3.14/300-introduce-oxnas-platform.patch create mode 100644 target/linux/oxnas/patches-3.14/310-oxnas-clocksource.patch create mode 100644 target/linux/oxnas/patches-3.14/320-oxnas-irqchip.patch create mode 100644 target/linux/oxnas/patches-3.14/330-oxnas-pinctrl.patch create mode 100644 target/linux/oxnas/patches-3.14/340-oxnas-pcie.patch create mode 100644 target/linux/oxnas/patches-3.14/350-oxnas-reset.patch create mode 100644 target/linux/oxnas/patches-3.14/400-oxnas-nand.patch create mode 100644 target/linux/oxnas/patches-3.14/500-oxnas-sata.patch create mode 100644 target/linux/oxnas/patches-3.14/800-oxnas-ehci.patch create mode 100644 target/linux/oxnas/patches-3.14/900-more-boards.patch diff --git a/target/linux/oxnas/config-3.14 b/target/linux/oxnas/config-3.14 new file mode 100644 index 000..727d81e --- /dev/null +++ b/target/linux/oxnas/config-3.14 @@ -0,0 +1,349 @@ +CONFIG_ALIGNMENT_TRAP=y +# CONFIG_APM_EMULATION is not set +CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAS_RESET_CONTROLLER=y +CONFIG_ARCH_HAS_TICK_BROADCAST=y +CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set +CONFIG_ARCH_NR_GPIO=0 +CONFIG_ARCH_OXNAS=y +CONFIG_ARCH_REQUIRE_GPIOLIB=y +# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set +# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y +CONFIG_ARCH_WANT_GENERAL_HUGETLB=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ARM=y +# CONFIG_ARM_CPU_SUSPEND is not set +CONFIG_ARM_GIC=y +CONFIG_ARM_L1_CACHE_SHIFT=5 +CONFIG_ARM_NR_BANKS=8 +CONFIG_ARM_PATCH_PHYS_VIRT=y +CONFIG_ARM_THUMB=y +CONFIG_ARM_UNWIND=y +CONFIG_ATA=y +CONFIG_AUTO_ZRELADDR=y +#
Re: [OpenWrt-Devel] [PATCH 1/3] ag71xx: replace fixed PHY reset wait time in ar7240sw_setup
Hi,
just added this to my local tree, images are building, the ar71xx
network stuff scares me and i want to test this for a few b
On 05/12/2014 07:36, Heiner Kallweit wrote:
Replace the fixed wait time of 1s with polling for BMCR_RESET
to be cleared on all PHYs.
Signed-off-by: Heiner Kallweit hkallwe...@gmail.com
---
.../net/ethernet/atheros/ag71xx/ag71xx_ar7240.c| 29
+-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
index d4ccc02..0a6d0ca 100644
---
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
+++
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
@@ -618,6 +618,31 @@ static void ar7240sw_setup(struct ar7240sw *as)
ar7240sw_reg_rmw(mii, AR7240_REG_SERVICE_TAG, AR7240_SERVICE_TAG_M, 0);
}
+/* inspired by phy_poll_reset in drivers/net/phy/phy_device.c */
+static int
+ar7240sw_phy_poll_reset(struct mii_bus *bus)
+{
+ const unsigned int sleep_msecs = 20;
+ int ret, elapsed, i;
+
+ for (elapsed = sleep_msecs; elapsed = 600;
+ elapsed += sleep_msecs) {
+ msleep(sleep_msecs);
+ for (i = 0; i AR7240_NUM_PHYS; i++) {
+ ret = ar7240sw_phy_read(bus, i, MII_BMCR);
+ if (ret 0)
+ return ret;
+ if (ret BMCR_RESET)
+ break;
+ if (i == AR7240_NUM_PHYS - 1) {
+ usleep_range(1000, 2000);
+ return 0;
+ }
+ }
+ }
+ return -ETIMEDOUT;
+}
+
static int ar7240sw_reset(struct ar7240sw *as)
{
struct mii_bus *mii = as-mii_bus;
@@ -646,7 +671,9 @@ static int ar7240sw_reset(struct ar7240sw *as)
ar7240sw_phy_write(mii, i, MII_BMCR,
BMCR_RESET | BMCR_ANENABLE);
}
- msleep(1000);
+ ret = ar7240sw_phy_poll_reset(mii);
+ if (ret)
+ return ret;
ar7240sw_setup(as);
return ret;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] ag71xx: replace fixed PHY reset wait time in ar7240sw_setup
(i got attacked by the cat :) and she did manage to hit the send
button before i finished typing)
Hi,
just added this to my local tree, images are building, the ar71xx
network stuff scares me and i want to test this for a few boards
before pushing. i might not manage to do so today
John
On 05/12/2014 09:55, John Crispin wrote:
Hi,
just added this to my local tree, images are building, the ar71xx
network stuff scares me and i want to test this for a few b
On 05/12/2014 07:36, Heiner Kallweit wrote:
Replace the fixed wait time of 1s with polling for BMCR_RESET to
be cleared on all PHYs.
Signed-off-by: Heiner Kallweit hkallwe...@gmail.com ---
.../net/ethernet/atheros/ag71xx/ag71xx_ar7240.c| 29
+- 1 file changed, 28 insertions(+), 1
deletion(-)
diff --git
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
index d4ccc02..0a6d0ca 100644
---
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
+++
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_ar7240.c
@@ -618,6 +618,31 @@ static void ar7240sw_setup(struct ar7240sw
*as) ar7240sw_reg_rmw(mii, AR7240_REG_SERVICE_TAG,
AR7240_SERVICE_TAG_M, 0); }
+/* inspired by phy_poll_reset in drivers/net/phy/phy_device.c */
+static int +ar7240sw_phy_poll_reset(struct mii_bus *bus) +{ +
const unsigned int sleep_msecs = 20; + int ret, elapsed, i; + +
for (elapsed = sleep_msecs; elapsed = 600; + elapsed +=
sleep_msecs) { + msleep(sleep_msecs); + for (i = 0; i
AR7240_NUM_PHYS; i++) { +ret = ar7240sw_phy_read(bus, i,
MII_BMCR); + if (ret 0) + return
ret; + if (ret
BMCR_RESET) +break; +
if (i == AR7240_NUM_PHYS - 1) { +
usleep_range(1000, 2000); + return 0; +
} + } + } + return
-ETIMEDOUT; +} + static int ar7240sw_reset(struct ar7240sw *as) {
struct mii_bus *mii = as-mii_bus; @@ -646,7 +671,9 @@ static int
ar7240sw_reset(struct ar7240sw *as) ar7240sw_phy_write(mii, i,
MII_BMCR, BMCR_RESET | BMCR_ANENABLE); } - msleep(1000); + ret =
ar7240sw_phy_poll_reset(mii); + if (ret) + return ret;
ar7240sw_setup(as); return ret;
___ openwrt-devel
mailing list openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/1] [kernel] ar71xx: reset problem fix
Hello guys, I got no response here in this mailing list to my last e-mail regarding to the reset patch. The problem is still active and it also concerns the trunk version. Please also see the corresponding ticket: https://dev.openwrt.org/ticket/17839 The patch which I used for BB is also available by the following download link, if you prefer this way: http://www.ctb.co.at/download/OpenWRT/14.07-rf/ar71xx/generic/903-MIPS-ath79-fix-restart.patch Is there a special reason why this patch gets not accepted? Michael --- This patch fixes the reset bug on the ar71xx platform. The reboot command causes sometimes hanging routers with TL-WDR3600 (HW V1.5) and TL-WDR4300 (HW V1.7) platforms and probably also on other devices. Sometimes a reboot is successful, sometimes not and a power cycle of the device is required. This patch runs an endless loop when the mask for the FULL_CHIP_RESET gets set, the write to the reset register is done and waits then until the CPU reboots. There is also a ticket #17839 to this bug. https://dev.openwrt.org/ticket/17839 Signed-off-by: Michael Uray michael.u...@ctb.co.at --- --- a/arch/mips/ath79/common.c +++ b/arch/mips/ath79/common.c @@ -83,6 +83,8 @@ void ath79_device_reset_set(u32 mask) spin_lock_irqsave(ath79_device_reset_lock, flags); t = ath79_reset_rr(reg); ath79_reset_wr(reg, t | mask); + if (mask == AR71XX_RESET_FULL_CHIP) +for (;;); spin_unlock_irqrestore(ath79_device_reset_lock, flags); } EXPORT_SYMBOL_GPL(ath79_device_reset_set); -Ursprüngliche Nachricht- Von: Michael Uray Gesendet: Dienstag, 21. Oktober 2014 14:31 An: openwrt-devel@lists.openwrt.org Betreff: AW: [OpenWrt-Devel] [PATCH 1/1] [kernel] ar71xx: reset problem fix John, I have tried to use your recommended macro but it did not work. Please see comment #70 for details: https://dev.openwrt.org/ticket/17839#comment:70 The patch should be then fine so far as I can see, I just corrected the comments. Michael --- This patch fixes the reset bug on the ar71xx platform. The reboot command causes sometimes hanging routers with TL-WDR3600 (HW V1.5) and TL-WDR4300 (HW V1.7) platforms and probably also on other devices. Sometimes a reboot is successful, sometimes not and a power cycle of the device is required. This patch runs an endless loop when the mask for the FULL_CHIP_RESET gets set, the write to the reset register is done and waits then until the CPU reboots. There is also a ticket #17839 to this bug. https://dev.openwrt.org/ticket/17839 Signed-off-by: Michael Uray michael.u...@ctb.co.at --- --- a/arch/mips/ath79/common.c +++ b/arch/mips/ath79/common.c @@ -83,6 +83,8 @@ void ath79_device_reset_set(u32 mask) spin_lock_irqsave(ath79_device_reset_lock, flags); t = ath79_reset_rr(reg); ath79_reset_wr(reg, t | mask); + if (mask == AR71XX_RESET_FULL_CHIP) +for (;;); spin_unlock_irqrestore(ath79_device_reset_lock, flags); } EXPORT_SYMBOL_GPL(ath79_device_reset_set); -Ursprüngliche Nachricht- Von: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] Im Auftrag von John Crispin Gesendet: Samstag, 18. Oktober 2014 07:37 An: openwrt-devel@lists.openwrt.org Betreff: Re: [OpenWrt-Devel] [PATCH 1/1] [kernel] ar71xx: reset problem fix On 18/10/2014 00:10, Michael Uray wrote: This patch fixes the reset bug on the ar71xx platform. The reboot command causes sometimes hanging routers with TL-WDR3600 (HW V1.5) and TL-WDR4300 (HW V1.7) platforms and probably also on other devices. Sometimes a reboot is successful, sometimes not and a power cycle of the device is required. This patch runs an endless loop after the interrupts get disabled and the FULL_CHIP_RESET gets set and waits then until the CPU reboots. Hi, the code does not set the FULL_CHIP_RESET but checks whether it is set. also please look at the unreachable() macro instead of using a endless loop John There is also a ticket #17839 to this bug. https://dev.openwrt.org/ticket/17839 Signed-off-by: Michael Uray michael.u...@ctb.co.at I am not subscribed to the mailing list, so please put me on CC if you answer. --- --- a/arch/mips/ath79/common.c +++ b/arch/mips/ath79/common.c @@ -83,6 +83,8 @@ void ath79_device_reset_set(u32 mask) spin_lock_irqsave(ath79_device_reset_lock, flags); t = ath79_reset_rr(reg); ath79_reset_wr(reg, t | mask); + if (mask == AR71XX_RESET_FULL_CHIP) +for (;;); spin_unlock_irqrestore(ath79_device_reset_lock, flags); } EXPORT_SYMBOL_GPL(ath79_device_reset_set); ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org
Re: [OpenWrt-Devel] ar934x+ar8327v4
This sounds very like the bug #18401 I have raised for my RB2011UiAS-2HnD-IN. I have exactly the same problem of everything appearing to be detected OK and interfaces OK but eth0 simply doesn't do anything. I can try patches etc. if/when necessary. On Thu, Dec 04, 2014 at 10:13:52PM -0700, David Hutchison wrote: Hi, I ran into an issue with the Mikrotik Routerboard 951G's switch chip. The new batch that we received use an updated ar8327 switch chip. The switch chip would not function properly so I decided to load trunk and utilize your patches. dmesg shows the following: switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 libphy: ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] It appears the updated ar8216.c with your changes have successfully initialized the chip. In fact I can even use swconfig dev switch0 to create vlans etc. If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug ethernet cables into each port and push data from port 1 to port 2 etc. It appears the switch driver is working correctly. What is broken is the interface handle eth0. It exposes eth0 and ties it to the switch correctly ( as you can see from the above dmesg output ). I then assign an IP address to eth0, however when I try to ping a device connected to the switch. I get no response. There is no arp traffic either. It's like data from the eth0 handle doesn't know how to route through the switch. It appears like the switch hardware is working ( since port 1 can communicate to port 2 ). However when eth0 attempts to communicate to a device on port 1, it doesn't work. The device on port 1 cannot communicate with the eth0 interface either. I think your patches are specifically for the switch only. If that's the case, then they are working. However, with your knowledge of ar8327 could you point me into the direction of fixing the eth0 interface communicating to the ar8327 switch properly? Is there something in ag71xx that I should be looking at? Could the ar8327 switch not be initializing properly? The probe is definitely finding *AR8327* so that seems to be OK. I am guessing this is something specific with the ar924x CPU + ar8327 switch chip. I'm open to any suggestions :-) -- Davey ___ -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/3] ag71xx: replace fixed PHY reset wait time in ar7240sw_setup
On Fri, Dec 5, 2014 at 9:57 AM, John Crispin blo...@openwrt.org wrote: Hi, just added this to my local tree, images are building, the ar71xx network stuff scares me and i want to test this for a few boards before pushing. i might not manage to do so today Sure, take your time. A similar phy poll change was added to the AR8216 driver recently and works fine there, so I expect no problems. However I just have two platforms for tests (TL-WDR4300/WDR4900) so I appreciate tests on further platforms. Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] netifd: Pass source address to proto_add_ipv4_route
From: Kristian Evensen kristian.even...@gmail.com
Enable callers to pass the source IP of an IPv4 route when using
proto_add_ipv4_route(). This is useful with for example DHCP in a multihomed
scenario, as it provides an easy way to match default routes with the correct IP
address. One use case for this are applications that monitor the state of the
WAN port, and the WAN port is assigned multiple addresses.
Signed-off-by: Kristian Evensen kristian.even...@gmail.com
---
scripts/netifd-proto.sh | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/scripts/netifd-proto.sh b/scripts/netifd-proto.sh
index ce316c4..b5ef3d1 100644
--- a/scripts/netifd-proto.sh
+++ b/scripts/netifd-proto.sh
@@ -120,8 +120,9 @@ proto_add_ipv4_route() {
local target=$1
local mask=$2
local gw=$3
+ local source=$4
- append PROTO_ROUTE $target/$mask/$gw//
+ append PROTO_ROUTE $target/$mask/$gw///$source
}
proto_add_ipv6_route() {
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] netifd: Set source IP for DHCP default route
From: Kristian Evensen kristian.even...@gmail.com
This patch depends on Pass source address to proto_add_ipv4_route.
I have not found a scenario that would break by setting the source address on
default, but please let me know if any special considerations should be taken.
Signed-off-by: Kristian Evensen kristian.even...@gmail.com
---
package/network/config/netifd/files/lib/netifd/dhcp.script | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/package/network/config/netifd/files/lib/netifd/dhcp.script
b/package/network/config/netifd/files/lib/netifd/dhcp.script
index 90fa6d3..17e22af 100755
--- a/package/network/config/netifd/files/lib/netifd/dhcp.script
+++ b/package/network/config/netifd/files/lib/netifd/dhcp.script
@@ -20,7 +20,7 @@ setup_interface () {
# TODO: apply $broadcast
for i in $router; do
- proto_add_ipv4_route 0.0.0.0 0 $i
+ proto_add_ipv4_route 0.0.0.0 0 $i $ip
done
# CIDR STATIC ROUTES (rfc3442)
--
1.9.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
its your lucky day, according to the DHL website my RB2011UiAS-2HnD-IN will arrive in the next 2-3 hours :) On 05/12/2014 10:21, Chris Green wrote: This sounds very like the bug #18401 I have raised for my RB2011UiAS-2HnD-IN. I have exactly the same problem of everything appearing to be detected OK and interfaces OK but eth0 simply doesn't do anything. I can try patches etc. if/when necessary. On Thu, Dec 04, 2014 at 10:13:52PM -0700, David Hutchison wrote: Hi, I ran into an issue with the Mikrotik Routerboard 951G's switch chip. The new batch that we received use an updated ar8327 switch chip. The switch chip would not function properly so I decided to load trunk and utilize your patches. dmesg shows the following: switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 libphy: ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] It appears the updated ar8216.c with your changes have successfully initialized the chip. In fact I can even use swconfig dev switch0 to create vlans etc. If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug ethernet cables into each port and push data from port 1 to port 2 etc. It appears the switch driver is working correctly. What is broken is the interface handle eth0. It exposes eth0 and ties it to the switch correctly ( as you can see from the above dmesg output ). I then assign an IP address to eth0, however when I try to ping a device connected to the switch. I get no response. There is no arp traffic either. It's like data from the eth0 handle doesn't know how to route through the switch. It appears like the switch hardware is working ( since port 1 can communicate to port 2 ). However when eth0 attempts to communicate to a device on port 1, it doesn't work. The device on port 1 cannot communicate with the eth0 interface either. I think your patches are specifically for the switch only. If that's the case, then they are working. However, with your knowledge of ar8327 could you point me into the direction of fixing the eth0 interface communicating to the ar8327 switch properly? Is there something in ag71xx that I should be looking at? Could the ar8327 switch not be initializing properly? The probe is definitely finding *AR8327* so that seems to be OK. I am guessing this is something specific with the ar924x CPU + ar8327 switch chip. I'm open to any suggestions :-) -- Davey ___ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 5, 2014 at 10:21 AM, Chris Green c...@isbd.net wrote: This sounds very like the bug #18401 I have raised for my RB2011UiAS-2HnD-IN. I have exactly the same problem of everything appearing to be detected OK and interfaces OK but eth0 simply doesn't do anything. Ticket 18401 relates to BB 14.07. Therefore the issue doesn't seem to be related to recent changes in the AR8216 driver. It might be something more general related to the SoC-internal switch and and external switch chip being active in parallel. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
On 17 November 2014 at 18:42, Sebastian Moeller moell...@gmx.de wrote: Hi Richard, hi Jaime After changing the pop values have a look at the output of “ps w” on the router, when I tried to p;ay with these from the luci GUI I noticed that pppd was called with lcp-echo-failure 5 while the GUI reported 0 (meaning unlimited), so something might be off in parsing/passing the arguments from the GUI. (Then again with my testing I nave managed to get pop session timeout even though packet captures indicated that under load some lcl echo requests went missing…) Best Regards Sebastian Problem fixed! After hours of trying to diagnose what was going wrong, I took a long shot and tried overwriting the openwrt-distributed adsl firmware blob (/lib/firmware/ltq-dsl-fw-a-danube.bin) with the firmware blob that was originally distributed by BT (the original supplier of the Home Hub). Hey presto! My dsl connection has been perfect ever since (even though my dsl supplier is _not_ BT!) The whole saga is documented here (in case anyone else has the same problem and wants to try this solution): http://openwrt.ebilan.co.uk/viewtopic.php?f=4t=68 Many thanks to all who tried to help. With kind regards, Jaime ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] QA for upcoming(?) CC?
Hi. in any event, if the idea of an official release is that it should build out of the box, there are clearly a number of (albeit easily fixable) download and build issues to clean up. is it part of pre-release QA to make sure all of these issues are resolved? Such issues are usually not (completely) resolved before a release. Release builds are generating using make ... IGNORE_ERRORS=m so broken, non-builtin packages are simply skipped. Most of the packages you quoted are community maintained ones so the core developer team does not consider them a blocker if they do not build. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 05, 2014 at 10:59:11AM +0100, Heiner Kallweit wrote: On Fri, Dec 5, 2014 at 10:21 AM, Chris Green c...@isbd.net wrote: This sounds very like the bug #18401 I have raised for my RB2011UiAS-2HnD-IN. I have exactly the same problem of everything appearing to be detected OK and interfaces OK but eth0 simply doesn't do anything. Ticket 18401 relates to BB 14.07. Therefore the issue doesn't seem to be related to recent changes in the AR8216 driver. It might be something more general related to the SoC-internal switch and and external switch chip being active in parallel. As I noted in #18401 the bug is exactly the same both in BB 14.07 and in the CC trunk. Thus I think it's probably not to do with the recent changes in the driver, rather to some sort of change in the hardware in the latest Mikrotik routers. Some people with the RB2011 (other incarnations but presumably basically the same) have it working OK. -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] QA for upcoming(?) CC?
On 05/12/2014 11:19, Jo-Philipp Wich wrote: Hi. in any event, if the idea of an official release is that it should build out of the box, there are clearly a number of (albeit easily fixable) download and build issues to clean up. is it part of pre-release QA to make sure all of these issues are resolved? Such issues are usually not (completely) resolved before a release. Release builds are generating using make ... IGNORE_ERRORS=m so broken, non-builtin packages are simply skipped. actually i spent 4 week fixing all the issues for BB and we have a fallout of 0 packages on the main targets and a fallout of max 15 unimportant packages on unimportant targets. i intend to do the same for CC John Most of the packages you quoted are community maintained ones so the core developer team does not consider them a blocker if they do not build. ~ Jow ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] QA for upcoming(?) CC?
On Fri, 5 Dec 2014, John Crispin wrote: On 05/12/2014 11:19, Jo-Philipp Wich wrote: Hi. in any event, if the idea of an official release is that it should build out of the box, there are clearly a number of (albeit easily fixable) download and build issues to clean up. is it part of pre-release QA to make sure all of these issues are resolved? Such issues are usually not (completely) resolved before a release. Release builds are generating using make ... IGNORE_ERRORS=m so broken, non-builtin packages are simply skipped. actually i spent 4 week fixing all the issues for BB and we have a fallout of 0 packages on the main targets and a fallout of max 15 unimportant packages on unimportant targets. i intend to do the same for CC cool, i suspected as much, just wanted to check, thanks. rday -- Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWRT and grsecurity experiments and ponderings
Hi all noticing that CC may be coming at some point, and whilst recently taking the latest turunk for a spin, I noticed that the kernel 3.14.25 matched the current grsecurity patch (which is in long term support against 3.14) so I thought I'd see what it would take to apply it to OpenWRT. It turned out to be easier than I'd hoped - although I've only tested it against ar71xx and the carambola2 specifically. The best way turned out to be to apply it after all the openwrt patches, then I had to fix about four rejects and some quirks introduced by other OpenWRT patches, the biggest challenge being something that OpenWRT does for MIPS in the module loading code needing to be fixed to work with grsec changes. The other main one is that compat wireless ath9k driver uses a macro that needs to be changed for grsec. Thereafter I was able to get my board to run with a -grsec kernel with the following caveats: * because OpenWRT turns off kernel MODVERSIONs, grsecurity requires RANDSTRUCT turned off * my particular config uncovered that openssl doesnt build with NX for mips and programs libcrypto.so were actually intercepted by grsec! So I had to fix that by adding a gnu-stack patch to several assembler-(generating) files So far I have managed to test the following features of grsec with success: * mount auditing * time change auditing * NX protection on MIPS (which doesnt have h/w support on my SOC) I'll end up pushing my modified OpenWRT build to github soonish This did the job for me, but I figured it was worth sharing as the buzzword Internet of Things looms large and openwrt is increasing adoption on products such as the vocore and wrtnode... I wonder what people feel the priority might be to get this tidied up and integrated into the main openwrt - or would it be infeasible to properly test and support? Noting that there will likely be other packages that I dont currently use that could need NX fixing on MIPS for starters, so wider implementation would depend on the priorities of other users of different packages. There is also the risk is that mixing the openwrt package suite with grsec may introduce inadvertent security holes - my changes seem OK but I havent yet done the deep research to know for sure. This can be mitigated by making an GRSEC config option optional with a big warning in menuconfig for those who want to do their own diligence. Perhaps the option in the config would also only be enabled for a limited subset of boards where people have made the effort to patch test, as an 'experimental' feature. ar7240 bootm ## Booting image at 8300 ... Image Name: MIPS OpenWrt Linux-3.14.25 Created: 2014-12-04 13:48:17 UTC Image Type: MIPS Linux Kernel Image (lzma compressed) Data Size:4796179 Bytes = 4.6 MB Load Address: 8006 Entry Point: 8006 Verifying Checksum at 0x8340 ...OK Uncompressing Kernel Image ... OK Starting kernel ... [0.00] Linux version 3.14.25-grsec (andrew@atlantis4) (gcc version 4.8.3 (OpenWrt/Linaro GCC 4.8-2014.04 r43488) ) #6 Fri Dec 5 00:17:55 ACDT 2014 [0.00] bootconsole [early0] enabled [0.00] CPU0 revision is: 00019374 (MIPS 24Kc) [0.00] SoC: Atheros AR9330 rev 1 ... [ 21.562499] grsec: mount of devpts to /dev/pts by /sbin/procd[procd:1] uid/euid:0/0 gid/egid:0/0, parent /[swapper:0] uid/euid:0/0 gid/egid:0/0 ... [ 26.583332] grsec: time set by /bin/busybox[date:665] uid/euid:0/0 gid/egid:0/0, parent /etc/init.d/system[S10system:660] uid/euid:0/0 gid/egid:0/0 ... root@OpenWrt:/sbin# opkg search /wbin/wget2nand [ 306.541661] grsec: denied marking stack executable as requested by PT_GNU_STACK marking in /usr/lib/libcrypto.so.1.0.0 by /bin/opkg[opkg:1040] uid/euid:0/0 gid/egid:0/0, parent /bin/bus0 --A -- http://blog.oldcomputerjunk.net https://au.linkedin.com/in/amcdonnell https://launchpad.net/~andymc73 https://github.com/andymc73 Twitter: @pastcompute GPG: http://www.andrewmcdonnell.net/gpg.html ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar8216: Use IGMP Join and Fast Leave functions
Avoids flooding the network with multicast data. Signed-off-by: Cristian Morales Vega crist...@samknows.com --- Since I guess not all the switches support this... Good idea? Is some OpenWRT package expecting to receive the multicast packages? At the very least you lose the capacity of using iptables to play with the packets. target/linux/generic/files/drivers/net/phy/ar8216.c | 13 - target/linux/generic/files/drivers/net/phy/ar8216.h | 11 +++ 2 files changed, 23 insertions(+), 1 deletion(-) diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.c b/target/linux/generic/files/drivers/net/phy/ar8216.c index 558b9f7..6583d8d 100644 --- a/target/linux/generic/files/drivers/net/phy/ar8216.c +++ b/target/linux/generic/files/drivers/net/phy/ar8216.c @@ -1690,7 +1690,6 @@ ar8327_init_globals(struct ar8xxx_priv *priv) /* forward multicast and broadcast frames to CPU */ t = (AR8327_PORTS_ALL AR8327_FWD_CTRL1_UC_FLOOD_S) | - (AR8327_PORTS_ALL AR8327_FWD_CTRL1_MC_FLOOD_S) | (AR8327_PORTS_ALL AR8327_FWD_CTRL1_BC_FLOOD_S); priv-write(priv, AR8327_REG_FWD_CTRL1, t); @@ -1710,6 +1709,18 @@ ar8327_init_globals(struct ar8xxx_priv *priv) AR8327_EEE_CTRL_DISABLE_PHY(3) | AR8327_EEE_CTRL_DISABLE_PHY(4); priv-write(priv, AR8327_REG_EEE_CTRL, t); + + /* Enable IGMP Join/Leave */ + t = AR8327_IGMP_JOIN_LEAVE0 | + AR8327_IGMP_JOIN_LEAVE1 | + AR8327_IGMP_JOIN_LEAVE2 | + AR8327_IGMP_JOIN_LEAVE3; + priv-write(priv, AR8327_REG_FRAM_ACK_CTRL0, t); + t = AR8327_IGMP_JOIN_LEAVE4 | + AR8327_IGMP_JOIN_LEAVE5 | + AR8327_IGMP_JOIN_LEAVE6; + t |= AR8327_IGMP_V3; /* Look _also_ for IGMPv3 */ + priv-write(priv, AR8327_REG_FRAM_ACK_CTRL1, t); } static void diff --git a/target/linux/generic/files/drivers/net/phy/ar8216.h b/target/linux/generic/files/drivers/net/phy/ar8216.h index f6df7c8..871134d 100644 --- a/target/linux/generic/files/drivers/net/phy/ar8216.h +++ b/target/linux/generic/files/drivers/net/phy/ar8216.h @@ -364,6 +364,17 @@ #define AR8327_REG_EEE_CTRL0x100 #define AR8327_EEE_CTRL_DISABLE_PHY(_i) BIT(4 + (_i) * 2) +#define AR8327_REG_FRAM_ACK_CTRL0 0x210 +#define AR8327_IGMP_JOIN_LEAVE0 BITS(1, 2) +#define AR8327_IGMP_JOIN_LEAVE1 BITS(9, 2) +#define AR8327_IGMP_JOIN_LEAVE2 BITS(17, 2) +#define AR8327_IGMP_JOIN_LEAVE3 BITS(25, 2) +#define AR8327_REG_FRAM_ACK_CTRL1 0x214 +#define AR8327_IGMP_JOIN_LEAVE4 BITS(1, 2) +#define AR8327_IGMP_JOIN_LEAVE5 BITS(9, 2) +#define AR8327_IGMP_JOIN_LEAVE6 BITS(17, 2) +#define AR8327_IGMP_V3 BIT(24) + #define AR8327_REG_PORT_VLAN0(_i) (0x420 + (_i) * 0x8) #define AR8327_PORT_VLAN0_DEF_SVID BITS(0, 12) #define AR8327_PORT_VLAN0_DEF_SVID_S 0 -- 1.9.3 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: generate factory images for Nexx devices
From: Roger Pueyo Centelles roger.pu...@guifi.net
---
target/linux/ramips/dts/WT1520-4M.dts | 83 +++
target/linux/ramips/dts/WT1520-8M.dts | 83 +++
target/linux/ramips/dts/WT1520.dts| 83 ---
target/linux/ramips/image/Makefile| 9 +---
tools/firmware-utils/src/mkporayfw.c | 32 ++
5 files changed, 191 insertions(+), 99 deletions(-)
create mode 100644 target/linux/ramips/dts/WT1520-4M.dts
create mode 100644 target/linux/ramips/dts/WT1520-8M.dts
delete mode 100644 target/linux/ramips/dts/WT1520.dts
diff --git a/target/linux/ramips/dts/WT1520-4M.dts
b/target/linux/ramips/dts/WT1520-4M.dts
new file mode 100644
index 000..dc0ad32
--- /dev/null
+++ b/target/linux/ramips/dts/WT1520-4M.dts
@@ -0,0 +1,83 @@
+/dts-v1/;
+
+/include/ rt5350.dtsi
+
+/ {
+ compatible = NEXXWT1520, ralink,rt5350-soc;
+ model = Nexx WT1520;
+
+ memory@0 {
+ device_type = memory;
+ reg = 0x0 0x200;
+ };
+
+ chosen {
+ bootargs = console=ttyS1,57600;
+ };
+
+ palmbus@1000 {
+ uart@500 {
+ status = okay;
+ };
+
+ spi@b00 {
+ status = okay;
+ m25p80@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = w25q32;
+ reg = 0 0;
+ linux,modalias = m25p80, s25fl064k;
+ spi-max-frequency = 1000;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x0 0x3;
+ read-only;
+ };
+
+ partition@3 {
+ label = u-boot-env;
+ reg = 0x3 0x1;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = factory;
+ reg = 0x4 0x1;
+ read-only;
+ };
+
+ partition@5 {
+ label = firmware;
+ reg = 0x5 0x3b;
+ };
+ };
+ };
+ };
+
+ pinctrl {
+ state_default: pinctrl0 {
+ gpio {
+ ralink,group = jtag;
+ ralink,function = gpio;
+ };
+ };
+ };
+
+ ethernet@1010 {
+ mtd-mac-address = factory 0x4;
+ };
+
+ wmac@1018 {
+ ralink,mtd-eeprom = factory 0;
+ };
+
+ ehci@101c {
+ status = okay;
+ };
+
+ ohci@101c1000 {
+ status = okay;
+ };
+};
diff --git a/target/linux/ramips/dts/WT1520-8M.dts
b/target/linux/ramips/dts/WT1520-8M.dts
new file mode 100644
index 000..d526149
--- /dev/null
+++ b/target/linux/ramips/dts/WT1520-8M.dts
@@ -0,0 +1,83 @@
+/dts-v1/;
+
+/include/ rt5350.dtsi
+
+/ {
+ compatible = NEXXWT1520, ralink,rt5350-soc;
+ model = Nexx WT1520;
+
+ memory@0 {
+ device_type = memory;
+ reg = 0x0 0x200;
+ };
+
+ chosen {
+ bootargs = console=ttyS1,57600;
+ };
+
+ palmbus@1000 {
+ uart@500 {
+ status = okay;
+ };
+
+ spi@b00 {
+ status = okay;
+ m25p80@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = w25q64;
+ reg = 0 0;
+ linux,modalias = m25p80, s25fl064k;
+ spi-max-frequency = 1000;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x0 0x3;
+ read-only;
+ };
+
+ partition@3 {
+ label = u-boot-env;
+ reg = 0x3 0x1;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = factory;
+
Re: [OpenWrt-Devel] ar934x+ar8327v4
Hello, Yes the problem remains when enable_vlan is set to 0 I don't think it's related to your changes either. I synced with trunk in hope that your changes made a difference with my problem. However that does not seem to be the case. I was hoping someone could point me in the right direction. Does this sound more like an issue with ag71xx since that is what exposes the eth0 interface? Could it be as simple as the switch just isn't recognized? Perhaps the switch interconnect is no longer RGMII and should be GMII? If I knew where in those drivers to start looking, I could probably help fix this problem. I enjoy tinkering with the drivers, and learning how to fix them :) I was hoping you had some knowledge about how the interface becomes tied with the switch itself, and if there were any specifics for the ar8327 that must be set before the communication between the CPU + Switch Chip can happen. Felix, would you by chance have any ideas as to what to check next? The switch0 interface works fine, the eth0 interface tied to the switch. Does not. The other thing to note ( and i'm not sure if this is by design ).. I used to be able to do swconfig dev eth0 show and show the switch the eth0 was connected to. Now I must use swconfig dev switch0 show to configure the switch. When you do swconfig dev eth0 show it says it Failed to connect to the switch. In the past, I have always used eth0 to configure the switch however that may have been incorrect. -- Davey On Thu, Dec 4, 2014 at 11:57 PM, Heiner Kallweit hkallwe...@gmail.com wrote: Am 05.12.2014 um 06:13 schrieb David Hutchison: Hi, I ran into an issue with the Mikrotik Routerboard 951G's switch chip. The new batch that we received use an updated ar8327 switch chip. The switch chip would not function properly so I decided to load trunk and utilize your patches. dmesg shows the following: switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 libphy: ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] It appears the updated ar8216.c with your changes have successfully initialized the chip. In fact I can even use swconfig dev switch0 to create vlans etc. If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug ethernet cables into each port and push data from port 1 to port 2 etc. It appears the switch driver is working correctly. What is broken is the interface handle eth0. It exposes eth0 and ties it to the switch correctly ( as you can see from the above dmesg output ). I then assign an IP address to eth0, however when I try to ping a device connected to the switch. I get no response. There is no arp traffic either. It's like data from the eth0 handle doesn't know how to route through the switch. It appears like the switch hardware is working ( since port 1 can communicate to port 2 ). However when eth0 attempts to communicate to a device on port 1, it doesn't work. The device on port 1 cannot communicate with the eth0 interface either. I think your patches are specifically for the switch only. If that's the case, then they are working. However, with your knowledge of ar8327 could you point me into the direction of fixing the eth0 interface communicating to the ar8327 switch properly? Is there something in ag71xx that I should be looking at? Could the ar8327 switch not be initializing properly? The probe is definitely finding *AR8327* so that seems to be OK. I am guessing this is something specific with the ar924x CPU + ar8327 switch chip. I'm open to any suggestions :-) -- Davey The recent changes to the AR8216 driver are mainly cleanups with no functional change. Also your dmesg output looks good. So at a first glance I don't think it's something with the driver. At first your /etc/config/network would be helpful. Does your problem also happen if vlans are switched off (enable_vlan set to 0) ? Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
I meant to say Could it be as simple as the switch just isn't fully initialized? instead of *recognized*... the ar8216 driver definitely recognizes it properly, and exposes the switch0 interface. I was thinking perhaps something else had to happen during init for the eth0 interface. -- Davey On Fri, Dec 5, 2014 at 9:15 AM, David Hutchison dhutchi...@bluemesh.net wrote: Hello, Yes the problem remains when enable_vlan is set to 0 I don't think it's related to your changes either. I synced with trunk in hope that your changes made a difference with my problem. However that does not seem to be the case. I was hoping someone could point me in the right direction. Does this sound more like an issue with ag71xx since that is what exposes the eth0 interface? Could it be as simple as the switch just isn't recognized? Perhaps the switch interconnect is no longer RGMII and should be GMII? If I knew where in those drivers to start looking, I could probably help fix this problem. I enjoy tinkering with the drivers, and learning how to fix them :) I was hoping you had some knowledge about how the interface becomes tied with the switch itself, and if there were any specifics for the ar8327 that must be set before the communication between the CPU + Switch Chip can happen. Felix, would you by chance have any ideas as to what to check next? The switch0 interface works fine, the eth0 interface tied to the switch. Does not. The other thing to note ( and i'm not sure if this is by design ).. I used to be able to do swconfig dev eth0 show and show the switch the eth0 was connected to. Now I must use swconfig dev switch0 show to configure the switch. When you do swconfig dev eth0 show it says it Failed to connect to the switch. In the past, I have always used eth0 to configure the switch however that may have been incorrect. -- Davey On Thu, Dec 4, 2014 at 11:57 PM, Heiner Kallweit hkallwe...@gmail.com wrote: Am 05.12.2014 um 06:13 schrieb David Hutchison: Hi, I ran into an issue with the Mikrotik Routerboard 951G's switch chip. The new batch that we received use an updated ar8327 switch chip. The switch chip would not function properly so I decided to load trunk and utilize your patches. dmesg shows the following: switch0: Atheros AR8327 rev. 4 switch registered on ag71xx-mdio.0 libphy: ag71xx_mdio: probed eth0: Atheros AG71xx at 0xb900, irq 4, mode:RGMII ag71xx ag71xx.0 eth0: connected to PHY at ag71xx-mdio.0:00 [uid=004dd034, driver=Atheros AR8216/AR8236/AR8316] It appears the updated ar8216.c with your changes have successfully initialized the chip. In fact I can even use swconfig dev switch0 to create vlans etc. If I create a port vlan ( eg. put ports 1 - 2 in vlan 1 ). I can plug ethernet cables into each port and push data from port 1 to port 2 etc. It appears the switch driver is working correctly. What is broken is the interface handle eth0. It exposes eth0 and ties it to the switch correctly ( as you can see from the above dmesg output ). I then assign an IP address to eth0, however when I try to ping a device connected to the switch. I get no response. There is no arp traffic either. It's like data from the eth0 handle doesn't know how to route through the switch. It appears like the switch hardware is working ( since port 1 can communicate to port 2 ). However when eth0 attempts to communicate to a device on port 1, it doesn't work. The device on port 1 cannot communicate with the eth0 interface either. I think your patches are specifically for the switch only. If that's the case, then they are working. However, with your knowledge of ar8327 could you point me into the direction of fixing the eth0 interface communicating to the ar8327 switch properly? Is there something in ag71xx that I should be looking at? Could the ar8327 switch not be initializing properly? The probe is definitely finding *AR8327* so that seems to be OK. I am guessing this is something specific with the ar924x CPU + ar8327 switch chip. I'm open to any suggestions :-) -- Davey The recent changes to the AR8216 driver are mainly cleanups with no functional change. Also your dmesg output looks good. So at a first glance I don't think it's something with the driver. At first your /etc/config/network would be helpful. Does your problem also happen if vlans are switched off (enable_vlan set to 0) ? Heiner ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On 2014-12-05 17:15, David Hutchison wrote: Hello, Yes the problem remains when enable_vlan is set to 0 I don't think it's related to your changes either. I synced with trunk in hope that your changes made a difference with my problem. However that does not seem to be the case. I was hoping someone could point me in the right direction. Does this sound more like an issue with ag71xx since that is what exposes the eth0 interface? Could it be as simple as the switch just isn't recognized? Perhaps the switch interconnect is no longer RGMII and should be GMII? If I knew where in those drivers to start looking, I could probably help fix this problem. I enjoy tinkering with the drivers, and learning how to fix them :) I was hoping you had some knowledge about how the interface becomes tied with the switch itself, and if there were any specifics for the ar8327 that must be set before the communication between the CPU + Switch Chip can happen. Felix, would you by chance have any ideas as to what to check next? The switch0 interface works fine, the eth0 interface tied to the switch. Does not. The other thing to note ( and i'm not sure if this is by design ).. I used to be able to do swconfig dev eth0 show and show the switch the eth0 was connected to. Now I must use swconfig dev switch0 show to configure the switch. When you do swconfig dev eth0 show it says it Failed to connect to the switch. In the past, I have always used eth0 to configure the switch however that may have been incorrect. Please post your network/switch configuration, and the output of swconfig dev switch0 show - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 05, 2014 at 05:37:31PM +0100, Felix Fietkau wrote: On 2014-12-05 17:15, David Hutchison wrote: The other thing to note ( and i'm not sure if this is by design ).. I used to be able to do swconfig dev eth0 show and show the switch the eth0 was connected to. Now I must use swconfig dev switch0 show to configure the switch. When you do swconfig dev eth0 show it says it Failed to connect to the switch. In the past, I have always used eth0 to configure the switch however that may have been incorrect. Please post your network/switch configuration, and the output of swconfig dev switch0 show Just to join in the fun here's my results (from rb-2011uias-2hnd) attached. -- Chris Green root@OpenWrt:/# swconfig dev switch0 show Global attributes: enable_vlan: 1 enable_mirror_rx: 0 enable_mirror_tx: 0 mirror_monitor_port: 0 mirror_source_port: 0 Port 0: mib: Port 0 MIB counters RxBroad : 459787 RxPause : 0 RxMulti : 26183 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 7557 Rx128Byte : 145114 Rx256Byte : 12418 Rx512Byte : 320892 Rx1024Byte : 6 Rx1518Byte : 4 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 125498098 RxBadByte : 0 RxOverFlow : 0 Filtered: 485983 TxBroad : 1 TxPause : 0 TxMulti : 12 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 1 Tx256Byte : 0 Tx512Byte : 12 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 4694 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: Port 1 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 2 link: port:1 link:down Port 2: mib: Port 2 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 1 link: port:2 link:down Port 3: mib: Port 3 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 1 link: port:3 link:down Port 4: mib: Port 4 MIB counters RxBroad : 1 RxPause : 0 RxMulti : 12 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 1 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 12 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 4642 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 1 link: port:4 link:down Port 5: mib: Port 5 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte:
Re: [OpenWrt-Devel] ar934x+ar8327v4
I am using a very simple test setup with no vlans for now: root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd26:7dae:48cb::/48' config interface 'lan' option ifname 'eth0' option type 'bridge' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' root@OpenWrt:/# swconfig dev switch0 show Global attributes: enable_vlan: 0 enable_mirror_rx: 0 enable_mirror_tx: 0 mirror_monitor_port: 0 mirror_source_port: 0 Port 0: mib: Port 0 MIB counters RxBroad : 5 RxPause : 0 RxMulti : 6 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 3252 Rx256Byte : 3 Rx512Byte : 4 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 223169 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 151 TxPause : 0 TxMulti : 324 TxUnderRun : 0 Tx64Byte: 208 Tx128Byte : 93 Tx256Byte : 99 Tx512Byte : 57 Tx1024Byte : 12 Tx1518Byte : 3260 TxMaxByte : 0 TxOverSize : 0 TxByte : 4960741 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: Port 1 MIB counters RxBroad : 151 RxPause : 0 RxMulti : 324 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 208 Rx128Byte : 93 Rx256Byte : 99 Rx512Byte : 57 Rx1024Byte : 12 Rx1518Byte : 3260 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 4960741 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 5 TxPause : 0 TxMulti : 6 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 3252 Tx256Byte : 3 Tx512Byte : 4 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 223169 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:1 link:up speed:1000baseT full-duplex auto Port 2: mib: Port 2 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:2 link:down Port 3: mib: Port 3 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:3 link:down Port 4: mib: Port 4 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:4 link:down Port 5: mib: Port 5 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0
Re: [OpenWrt-Devel] ar934x+ar8327v4
Here is a test I did by setting up swconfig manually. As you can see I put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping 10.128.41.1 which is a device on port 1. However eth0.1 which as address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. Attached is the swconfig setup, and a dmesg. Here is the arp result as well: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x0 00:00:00:00:00:00 *eth0.1 I used to be able to do: root@OpenWrt:/# swconfig dev eth0 show Failed to connect to the switch root@OpenWrt:/# swconfig list Found: switch0 - ag71xx-mdio.0 Do you not think this is an issue with ag71xx? Do you it is something in user-space? On Fri, Dec 5, 2014 at 12:18 PM, David Hutchison dhutchi...@bluemesh.net wrote: I am using a very simple test setup with no vlans for now: root@OpenWrt:/# cat /etc/config/network config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config globals 'globals' option ula_prefix 'fd26:7dae:48cb::/48' config interface 'lan' option ifname 'eth0' option type 'bridge' option proto 'static' option ipaddr '192.168.1.1' option netmask '255.255.255.0' option ip6assign '60' root@OpenWrt:/# swconfig dev switch0 show Global attributes: enable_vlan: 0 enable_mirror_rx: 0 enable_mirror_tx: 0 mirror_monitor_port: 0 mirror_source_port: 0 Port 0: mib: Port 0 MIB counters RxBroad : 5 RxPause : 0 RxMulti : 6 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 3252 Rx256Byte : 3 Rx512Byte : 4 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 223169 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 151 TxPause : 0 TxMulti : 324 TxUnderRun : 0 Tx64Byte: 208 Tx128Byte : 93 Tx256Byte : 99 Tx512Byte : 57 Tx1024Byte : 12 Tx1518Byte : 3260 TxMaxByte : 0 TxOverSize : 0 TxByte : 4960741 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:0 link:up speed:1000baseT full-duplex txflow rxflow Port 1: mib: Port 1 MIB counters RxBroad : 151 RxPause : 0 RxMulti : 324 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 208 Rx128Byte : 93 Rx256Byte : 99 Rx512Byte : 57 Rx1024Byte : 12 Rx1518Byte : 3260 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 4960741 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 5 TxPause : 0 TxMulti : 6 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 3252 Tx256Byte : 3 Tx512Byte : 4 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 223169 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:1 link:up speed:1000baseT full-duplex auto Port 2: mib: Port 2 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:2 link:down Port 3: mib: Port 3 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0 Rx1024Byte : 0 Rx1518Byte : 0 RxMaxByte : 0 RxTooLong : 0 RxGoodByte : 0 RxBadByte : 0 RxOverFlow : 0 Filtered: 0 TxBroad : 0 TxPause : 0 TxMulti : 0 TxUnderRun : 0 Tx64Byte: 0 Tx128Byte : 0 Tx256Byte : 0 Tx512Byte : 0 Tx1024Byte : 0 Tx1518Byte : 0 TxMaxByte : 0 TxOverSize : 0 TxByte : 0 TxCollision : 0 TxAbortCol : 0 TxMultiCol : 0 TxSingleCol : 0 TxExcDefer : 0 TxDefer : 0 TxLateCol : 0 pvid: 0 link: port:3 link:down Port 4: mib: Port 4 MIB counters RxBroad : 0 RxPause : 0 RxMulti : 0 RxFcsErr: 0 RxAlignErr : 0 RxRunt : 0 RxFragment : 0 Rx64Byte: 0 Rx128Byte : 0 Rx256Byte : 0 Rx512Byte : 0
Re: [OpenWrt-Devel] Frequent adsl disconnections with BTHOMEHUBV2B (lantiq xway danube)
On Dec 5, 2014 5:12 AM, Jaime T enopa...@gmail.com wrote: Problem fixed! After hours of trying to diagnose what was going wrong, I took a long shot and tried overwriting the openwrt-distributed adsl firmware blob (/lib/firmware/ltq-dsl-fw-a-danube.bin) with the firmware blob that was originally distributed by BT (the original supplier of the Home Hub). Hey presto! My dsl connection has been perfect ever since (even though my dsl supplier is _not_ BT!) The whole saga is documented here (in case anyone else has the same problem and wants to try this solution): http://openwrt.ebilan.co.uk/viewtopic.php?f=4t=68 Many thanks to all who tried to help. With kind regards, Jaime Are you connected to BTs network? Reseller? Sounds like BT tuned the firmware for their specific hardware environment after the generic did not deliver optimal performance. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 05, 2014 at 12:39:16PM -0700, David Hutchison wrote: Here is a test I did by setting up swconfig manually. As you can see I put ports 1 and 2 into vlangroup 1. Traffic from port 2 can ping 10.128.41.1 which is a device on port 1. However eth0.1 which as address 10.128.41.249 cannot ping 10.128.41.1 device on port 1. Attached is the swconfig setup, and a dmesg. Here is the arp result as well: root@OpenWrt:/# arp -n IP address HW type Flags HW addressMask Device 10.128.41.1 0x1 0x0 00:00:00:00:00:00 *eth0.1 I used to be able to do: root@OpenWrt:/# swconfig dev eth0 show Failed to connect to the switch root@OpenWrt:/# swconfig list Found: switch0 - ag71xx-mdio.0 Do you not think this is an issue with ag71xx? Do you it is something in user-space? Same on mine (except I have an eth1 which is the 10/100 that works OK):- root@OpenWrt:~# swconfig dev eth0 show Failed to connect to the switch. Use the list command to see which switches are available. root@OpenWrt:~# swconfig list Found: switch0 - ag71xx-mdio.0 Found: switch1 - eth1 root@OpenWrt:~# -- Chris Green ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ar934x+ar8327v4
On Fri, Dec 5, 2014 at 5:21 AM, Chris Green c...@isbd.net wrote: Some people with the RB2011 (other incarnations but presumably basically the same) have it working OK. I'm one of those that has a working RB2011; it's currently running r41293 with my RB2011UiAS patch ( http://patchwork.openwrt.org/patch/5841/ ). Unfortunately, it's working so well that I can't mess around with it at the moment. If John can't track down the problem with his RB2011 in the next few weeks, I can take a day before New Years, pull my RB2011 out of production, upgrade it to trunk, and see what happens. That will at least tell us whether it's a software or hardware problem. -- Soren Harward ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
