Re: [OpenWrt-Devel] [PATCH] ramips: do not stop the build if some targets fail
2013.01.07. 15:15 keltezéssel, Paul Fertser írta: This becomes crucial when you are using a generic profile to build an image larger than 4M, e.g. for w502u. Signed-off-by: Paul Fertser fercer...@gmail.com Applied. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] rt2x00: add rt5350 wlan support
Still no news from Mediatek? If required, I can post the updated patch against latest mac80211 2013-01-07 from trunk. -Michel Le 13/01/2013 01:21, Felix Kaechele a écrit : Am 06.01.2013 11:33, schrieb John Crispin: Although I'm not a lawyer, but in my understanding, this does not allows to use that code as a basis for GPL licensed driver. -Gabor 1. https://forum.openwrt.org/viewtopic.php?pid=186188#p186188 i have sent an email to MTK to ask ;) John Any news on this from MediaTek? Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] [packages] libjpeg-turbo: fix binary names to match what is built
Signed-off-by: Russell Senior russ...@personaltelco.net
PKG_NAME:=libjpeg-turbo
PKG_VERSION:=1.2.1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
define Package/jpeg-tools/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/{c,d}jpeg $(1)/usr/bin/
- $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpeg{tran,gut} $(1)/usr/bin/
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpegtran $(1)/usr/bin/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/{rd,wr}jpgcom $(1)/usr/bin/
- $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpgtest $(1)/usr/bin/
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jcstest $(1)/usr/bin/
Looks good to me.
-Ian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: use MkImage for Hauppauge Broadway, Netcore NW718 and Tenda W306R V2.0
2013.01.07. 16:59 keltezéssel, Paul Fertser írta: These targets need custom image names specified in the uImage header. MkImage accepts an optional 4th argument to do exactly that. Reuse the facility to generate proper sysupgrade images suitable also for upgrading the factory firmware. Compile-tested, the generated files inspected with file utility. Signed-off-by: Paul Fertser fercer...@gmail.com Applied with some changes. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Generated firmware binaries naming (was: Re: [PATCH] ramips: use MkImage for Hauppauge Broadway, Netcore NW718 and Tenda W306R V2.0)
Hi, On Sat, Jan 19, 2013 at 04:38:34PM +0100, Gabor Juhos wrote: 2013.01.07. 16:59 keltezéssel, Paul Fertser írta: These targets need custom image names specified in the uImage header. MkImage accepts an optional 4th argument to do exactly that. Reuse the facility to generate proper sysupgrade images suitable also for upgrading the factory firmware. Applied with some changes. As far as i understand, the way you did it will produce both factory.bin files (suitable for the sysupgrade utility and the vendor's interface) and sysupgrade.bin (that would work only with the sysupgrade utility). Isn't that adding an unnecessary complexity and causing more confusion for the users and developers? OTOH, when the vendor tools require some uncommon format it's meaningless to try to support it with sysupgrade so it makes sense to generate two different images. Shouldn't there be established a policy regarding that? As a user i would prefer to have a single image (without sysupgrade or factory in its name) whenever possible to have only one binary for both usecases. Alternatively, i'd require every target to generate both -factory and -sysupgrade images but if they can be identical, they should be (cp will be enough). More consistency in naming is needed, imho, so i propose to decide on that. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] [packages] libjpeg-turbo: fix binary names to match what is built
Ian == Ian Leonard antonla...@gmail.com writes:
Signed-off-by: Russell Senior russ...@personaltelco.net
PKG_NAME:=libjpeg-turbo PKG_VERSION:=1.2.1 -PKG_RELEASE:=1
+PKG_RELEASE:=2
define Package/jpeg-tools/install $(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/{c,d}jpeg $(1)/usr/bin/ -
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpeg{tran,gut} $(1)/usr/bin/
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpegtran $(1)/usr/bin/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/{rd,wr}jpgcom $(1)/usr/bin/ -
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpgtest $(1)/usr/bin/ +
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jcstest $(1)/usr/bin/
Ian Looks good to me.
I just found the change to the binary names in the libjpeg-turbo SVN
repository in r643. The binary jpeggut was actually jpegut (where ut
stands for unit test), and was renamed to tjunittest. jpegtest became
tjbench. Arguably, tjunittest shouldn't be installed anyway.
Makefile.am lists it in noinst_PROGRAM. Or perhaps it should only be
installed in a separate testing/debugging package.
jcstest stands for jpeg color space extentions tests, see r733. Maybe
should go into the separate testing/debugging package.
I'll try to whip up a better patch.
I don't use this package but, to quote David Woodhouse, it offended
me by not building.
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/5] [packages] libjpeg-turbo: fix binary names to match what is built
btw: mjpg-streamer looks to me a bit smoother with libjpeg-turbo than libjpeg,
the only drawback is l-t is a little bigger than the old lib..
On Jan 19, 2013, at 6:13 PM, Russell Senior russ...@personaltelco.net wrote:
Ian == Ian Leonard antonla...@gmail.com writes:
Signed-off-by: Russell Senior russ...@personaltelco.net
PKG_NAME:=libjpeg-turbo PKG_VERSION:=1.2.1 -PKG_RELEASE:=1
+PKG_RELEASE:=2
define Package/jpeg-tools/install $(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/{c,d}jpeg $(1)/usr/bin/ -
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpeg{tran,gut} $(1)/usr/bin/
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpegtran $(1)/usr/bin/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/{rd,wr}jpgcom $(1)/usr/bin/ -
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpgtest $(1)/usr/bin/ +
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jcstest $(1)/usr/bin/
Ian Looks good to me.
I just found the change to the binary names in the libjpeg-turbo SVN
repository in r643. The binary jpeggut was actually jpegut (where ut
stands for unit test), and was renamed to tjunittest. jpegtest became
tjbench. Arguably, tjunittest shouldn't be installed anyway.
Makefile.am lists it in noinst_PROGRAM. Or perhaps it should only be
installed in a separate testing/debugging package.
jcstest stands for jpeg color space extentions tests, see r733. Maybe
should go into the separate testing/debugging package.
I'll try to whip up a better patch.
I don't use this package but, to quote David Woodhouse, it offended
me by not building.
--
Russell Senior, President
russ...@personaltelco.net
___
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] Generated firmware binaries naming
Hi Paul, On Sat, Jan 19, 2013 at 04:38:34PM +0100, Gabor Juhos wrote: 2013.01.07. 16:59 keltezéssel, Paul Fertser írta: These targets need custom image names specified in the uImage header. MkImage accepts an optional 4th argument to do exactly that. Reuse the facility to generate proper sysupgrade images suitable also for upgrading the factory firmware. Applied with some changes. As far as i understand, the way you did it will produce both factory.bin files (suitable for the sysupgrade utility and the vendor's interface) and sysupgrade.bin (that would work only with the sysupgrade utility). Isn't that adding an unnecessary complexity and causing more confusion for the users and developers? I agree that this adds some complexity. However both the sysupgrade and factory images were provided for these boards, and if one of them disappear users will complain about that. OTOH, when the vendor tools require some uncommon format it's meaningless to try to support it with sysupgrade so it makes sense to generate two different images. Shouldn't there be established a policy regarding that? As a user i would prefer to have a single image (without sysupgrade or factory in its name) whenever possible to have only one binary for both usecases. And what should we tell to the users? - On board A from vendor B use the image without any suffix, but be aware that it is only working with the sysupgrade command from OpenWrt. - On board C from vendor D, feel free to use the image without any suffix, and that will work with the original web interface and with OpenWrt as well. - On board E from vendor F, the image with the -factory prefix must be used from the factory web interface, and the -sysupgrade image must be used to upgrade an existing OpenWrt installation. Additionally, the fact that the factory images can be used for sysupgrade on some boards does not mean that this will be true always. Of course, the factory format won't change but we might want to use a generic format for sysupgrade on all boards later. There were plans for that. Alternatively, i'd require every target to generate both -factory and -sysupgrade images This won't happen until someone does not investigate the format of the factory images and write a tool for them for the boards where we are not providing factory images yet. but if they can be identical, they should be (cp will be enough). More consistency in naming is needed, imho, so i propose to decide on that. More consistency? The -factory images must be used to flash OpenWrt from the original web interface, and the -sysupgrade images must be used to upgrade an existing OpenWrt installation. This is quite consistent IMO. -Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: Add Tenda 3G300M
2013.01.09. 16:08 keltezéssel, Cezary Jackiewicz írta: Ralink RT3052F, 4MB flash, 32MB ram, one USB 2.0, two buttons and seven leds. Factory image should be used to flash from original firmware. Signed-off-by: Cezary Jackiewicz cezary.jackiew...@gmail.com Applied with some changes. Thanks, Gabor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Generated firmware binaries naming
On Sat, Jan 19, 2013 at 05:34:05PM +0100, Gabor Juhos wrote: As far as i understand, the way you did it will produce both factory.bin files (suitable for the sysupgrade utility and the vendor's interface) and sysupgrade.bin (that would work only with the sysupgrade utility). Isn't that adding an unnecessary complexity and causing more confusion for the users and developers? I agree that this adds some complexity. However both the sysupgrade and factory images were provided for these boards, and if one of them disappear users will complain about that. Right, they might. Probably it'd be nice to write down the explicit rules somewhere once and then always refer users to them. Shouldn't there be established a policy regarding that? As a user i would prefer to have a single image (without sysupgrade or factory in its name) whenever possible to have only one binary for both usecases. And what should we tell to the users? - On board A from vendor B use the image without any suffix, but be aware that it is only working with the sysupgrade command from OpenWrt. I think if the image is only suitable for sysupgrade it should have a -sysupgrade suffix. - On board C from vendor D, feel free to use the image without any suffix, and that will work with the original web interface and with OpenWrt as well. Yes, if the image has no suffix i'd expect it to be universally applicable. - On board E from vendor F, the image with the -factory prefix must be used from the factory web interface, and the -sysupgrade image must be used to upgrade an existing OpenWrt installation. Yes. Additionally, the fact that the factory images can be used for sysupgrade on some boards does not mean that this will be true always. Of course, the factory format won't change but we might want to use a generic format for sysupgrade on all boards later. There were plans for that. In that case the images will start to differ so all the targets that have means to generate factory images can start generating -factory-named images plus a sysupgrade image. Alternatively, i'd require every target to generate both -factory and -sysupgrade images This won't happen until someone does not investigate the format of the factory images and write a tool for them for the boards where we are not providing factory images yet. I meant to say that this alternative proposal is to require every target to generate a sysupgrade image and (whenever possible) a factory image but if that factory image can also be used for sysupgrade they should be explicitely the same so that the developers looking through the Makefiles will never be confused about that. More consistency in naming is needed, imho, so i propose to decide on that. More consistency? The -factory images must be used to flash OpenWrt from the original web interface, and the -sysupgrade images must be used to upgrade an existing OpenWrt installation. This is quite consistent IMO. Ok, so if that's declared the policy (it's about the same as my second suggestion but i'd prefer to require sysupgrade files be copied from factory files when possible), it should be written down somewhere and all the new targets be required to adhere to it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] [packages] libjpeg-turbo: add package for test utils, move appropriate targets there
Trying to figure out where jpeggut came from, found a) that it was a
typo and b) that it was renamed in r643 from jpegut to tjunittest. In
the same revision, jpegtest became tjbench, and later in r733, jcstest
was added to test jpeg color space extentions. Since these tools will
only be desirable for testing, added a new package libjpeg-turbo-tests
to provide these utilities. The utilities needed libturbojpeg, so
added what had been a commented out library to the new package.
The libturbojpeg are currently commented out in InstallDev as well.
If external packages begin to rely on libturbojpeg functions for some
reason, the library should be added back.
Signed-off-by: Russell Senior russ...@personaltelco.net
---
libs/libjpeg-turbo/Makefile | 24
1 file changed, 20 insertions(+), 4 deletions(-)
diff --git a/libs/libjpeg-turbo/Makefile b/libs/libjpeg-turbo/Makefile
index 9ae15a6..546bf9b 100644
--- a/libs/libjpeg-turbo/Makefile
+++ b/libs/libjpeg-turbo/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=libjpeg-turbo
PKG_VERSION:=1.2.1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=@SF/libjpeg-turbo
@@ -43,6 +43,14 @@ define Package/jpeg-tools
TITLE+= manipulation tools
endef
+define Package/libjpeg-turbo-tests
+ $(call Package/libjpeg-turbo/Default)
+ SECTION:=utils
+ CATEGORY:=Utilities
+ DEPENDS:=+libjpeg-turbo
+ TITLE+= testing utilities
+endef
+
TARGET_CFLAGS += $(FPIC)
CONFIGURE_ARGS += \
@@ -69,17 +77,25 @@ endef
define Package/libjpeg-turbo/install
$(INSTALL_DIR) $(1)/usr/lib
$(CP) $(PKG_BUILD_DIR)/.libs/libjpeg.{a,so*} $(1)/usr/lib/
-# $(CP) $(PKG_BUILD_DIR)/.libs/libturbojpeg.{a,so*} $(1)/usr/lib/
endef
define Package/jpeg-tools/install
$(INSTALL_DIR) $(1)/usr/bin
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/{c,d}jpeg $(1)/usr/bin/
- $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpeg{tran,gut} $(1)/usr/bin/
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpegtran $(1)/usr/bin/
$(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/{rd,wr}jpgcom $(1)/usr/bin/
- $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jpgtest $(1)/usr/bin/
+endef
+
+define Package/libjpeg-turbo-tests/install
+ $(INSTALL_DIR) $(1)/usr/bin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/tjbench $(1)/usr/bin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/tjunittest $(1)/usr/bin
+ $(INSTALL_BIN) $(PKG_BUILD_DIR)/.libs/jcstest $(1)/usr/bin
+ $(INSTALL_DIR) $(1)/usr/lib
+ $(CP) $(PKG_BUILD_DIR)/.libs/libturbojpeg.{a,so*} $(1)/usr/lib/
endef
$(eval $(call HostBuild))
$(eval $(call BuildPackage,libjpeg-turbo))
$(eval $(call BuildPackage,jpeg-tools))
+$(eval $(call BuildPackage,libjpeg-turbo-tests))
--
1.7.12
--
Russell Senior, President
russ...@personaltelco.net
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] brcm47xx: reinstate gpio IRQ assignment
Recent changes to the brcm47xx gpio implementation result in an IRQ
no longer being assigned to the gpio driver. This breaks the ability
to enter failsafe, and possibly other things.
Only tested on a BCMA device (SSB not tested).
Signed-off-by: Nathan Hintz nlhi...@hotmail.com
Index: target/linux/brcm47xx/patches-3.6/400-arch-bcm47xx.patch
===
--- target/linux/brcm47xx/patches-3.6/400-arch-bcm47xx.patch(revision 35248)
+++ target/linux/brcm47xx/patches-3.6/400-arch-bcm47xx.patch(working copy)
@@ -41,7 +41,7 @@
obj-$(CONFIG_BCM47XX_SSB) += wgt634u.o
--- /dev/null
+++ b/arch/mips/bcm47xx/gpio.c
-@@ -0,0 +1,119 @@
+@@ -0,0 +1,140 @@
+/*
+ * This file is subject to the terms and conditions of the GNU General Public
+ * License. See the file COPYING in the main directory of this archive
@@ -161,9 +161,38 @@
+ return -EINVAL;
+}
+EXPORT_SYMBOL(bcm47xx_gpio_polarity);
++
++int gpio_to_irq(unsigned gpio)
++{
++ switch (bcm47xx_bus_type) {
++#ifdef CONFIG_BCM47XX_SSB
++ case BCM47XX_BUS_TYPE_SSB:
++ if (ssb_chipco_available(bcm47xx_bus.ssb.chipco))
++ return ssb_mips_irq(bcm47xx_bus.ssb.chipco.dev) + 2;
++ else if (ssb_extif_available(bcm47xx_bus.ssb.extif))
++ return ssb_mips_irq(bcm47xx_bus.ssb.extif.dev) + 2;
++ else
++ return -EINVAL;
++#endif
++#ifdef CONFIG_BCM47XX_BCMA
++ case BCM47XX_BUS_TYPE_BCMA:
++ return bcma_core_irq(bcm47xx_bus.bcma.bus.drv_cc.core);
++#endif
++ }
++ return -EINVAL;
++}
++EXPORT_SYMBOL_GPL(gpio_to_irq);
--- a/arch/mips/include/asm/mach-bcm47xx/gpio.h
+++ b/arch/mips/include/asm/mach-bcm47xx/gpio.h
-@@ -14,4 +14,11 @@ static inline int irq_to_gpio(unsigned i
+@@ -7,11 +7,18 @@
+ #define gpio_set_value __gpio_set_value
+
+ #define gpio_cansleep __gpio_cansleep
+-#define gpio_to_irq __gpio_to_irq
++extern int gpio_to_irq(unsigned gpio);
+
+ static inline int irq_to_gpio(unsigned int irq)
+ {
return -EINVAL;
}
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] Add support for TL-WDR3500
WDR3500 is similar to WDR3600 except it doesn't have gigabit ethernet, and has only 1 USB port. So, this patch (over r35162) adds a new board type, based on mach-tl-wdr4300.c but replacing ethernet config with one based on mach-tl-wr841n-v8.c a huge thanks goes out to Paul Fertser for hours of tireless advice! Pending issues: * Leds are not working at all * ethernet ports are all scrambled up: [Label] - soft device [WAN] - eth1.1 [LAN1] - eth1.4 [LAN2] - eth1.3 [LAN3] - eth1.2 [LAN4] - eth0 Anyone with experience fixing those details that cares to help, will be much appreciated! Signed-off-by: Gui Iribarren g...@altermundi.net Thanks-to: Paul Fertser fercer...@gmail.com tlwdr3500_support.patch Description: Binary data ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] network/iproute2: Bump version to 3.7.0
Updated to latest stable version and added an upstream patch to handle
a link failure
Signed-off-by: Oliver Smith oli...@8.c.9.b.0.7.4.0.1.0.0.2.ip6.arpa
[dgo...@allnet.de: refreshed patches]
Signed-off-by: Daniel Golle dgo...@allnet.de
---
package/network/utils/iproute2/Makefile| 4 +-
.../iproute2/patches/000-sync_pkt_sched_h.patch| 87 +---
.../utils/iproute2/patches/008-no_netem.patch | 8 +-
.../utils/iproute2/patches/110-extra-ccopts.patch | 10 +-
.../utils/iproute2/patches/210-add_codel.patch | 437 -
.../210-build-unbreak-linkage-of-m_xt.so.patch | 58 +++
6 files changed, 70 insertions(+), 534 deletions(-)
delete mode 100644 package/network/utils/iproute2/patches/210-add_codel.patch
create mode 100644
package/network/utils/iproute2/patches/210-build-unbreak-linkage-of-m_xt.so.patch
diff --git a/package/network/utils/iproute2/Makefile
b/package/network/utils/iproute2/Makefile
index 256064e..578010f 100644
--- a/package/network/utils/iproute2/Makefile
+++ b/package/network/utils/iproute2/Makefile
@@ -8,12 +8,12 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=iproute2
-PKG_VERSION:=3.3.0
+PKG_VERSION:=3.7.0
PKG_RELEASE:=1
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
PKG_SOURCE_URL:=http://kernel.org/pub/linux/utils/net/iproute2/
-PKG_MD5SUM:=308e7145218dd552c2766fe527e239e1
+PKG_MD5SUM:=47040899f8fa30c8721fc5aec6509b44
PKG_BUILD_PARALLEL:=1
PKG_BUILD_DIR:=$(BUILD_DIR)/iproute2-$(PKG_VERSION)
diff --git a/package/network/utils/iproute2/patches/000-sync_pkt_sched_h.patch
b/package/network/utils/iproute2/patches/000-sync_pkt_sched_h.patch
index d3315a0..b06bc70 100644
--- a/package/network/utils/iproute2/patches/000-sync_pkt_sched_h.patch
+++ b/package/network/utils/iproute2/patches/000-sync_pkt_sched_h.patch
@@ -1,6 +1,6 @@
--- a/include/linux/pkt_sched.h
+++ b/include/linux/pkt_sched.h
-@@ -193,6 +193,33 @@ struct tc_sfq_xstats {
+@@ -214,6 +214,33 @@ struct tc_sfq_xstats {
__s32 allot;
};
@@ -34,88 +34,3 @@
/* RED section */
enum {
-@@ -633,4 +660,84 @@ struct tc_qfq_stats {
- __u32 lmax;
- };
-
-+/* CODEL */
-+
-+enum {
-+ TCA_CODEL_UNSPEC,
-+ TCA_CODEL_TARGET,
-+ TCA_CODEL_LIMIT,
-+ TCA_CODEL_INTERVAL,
-+ TCA_CODEL_ECN,
-+ __TCA_CODEL_MAX
-+};
-+
-+#define TCA_CODEL_MAX (__TCA_CODEL_MAX - 1)
-+
-+struct tc_codel_xstats {
-+ __u32 maxpacket; /* largest packet we've seen so far */
-+ __u32 count; /* how many drops we've done since the last time we
-+ * entered dropping state
-+ */
-+ __u32 lastcount; /* count at entry to dropping state */
-+ __u32 ldelay;/* in-queue delay seen by most recently dequeued
packet */
-+ __s32 drop_next; /* time to drop next packet */
-+ __u32 drop_overlimit; /* number of time max qdisc packet limit was
hit */
-+ __u32 ecn_mark; /* number of packets we ECN marked instead of
dropped */
-+ __u32 dropping; /* are we in dropping state ? */
-+};
-+
-+/* FQ_CODEL */
-+
-+enum {
-+ TCA_FQ_CODEL_UNSPEC,
-+ TCA_FQ_CODEL_TARGET,
-+ TCA_FQ_CODEL_LIMIT,
-+ TCA_FQ_CODEL_INTERVAL,
-+ TCA_FQ_CODEL_ECN,
-+ TCA_FQ_CODEL_FLOWS,
-+ TCA_FQ_CODEL_QUANTUM,
-+ __TCA_FQ_CODEL_MAX
-+};
-+
-+#define TCA_FQ_CODEL_MAX (__TCA_FQ_CODEL_MAX - 1)
-+
-+enum {
-+ TCA_FQ_CODEL_XSTATS_QDISC,
-+ TCA_FQ_CODEL_XSTATS_CLASS,
-+};
-+
-+struct tc_fq_codel_qd_stats {
-+ __u32 maxpacket; /* largest packet we've seen so far */
-+ __u32 drop_overlimit; /* number of time max qdisc
-+ * packet limit was hit
-+ */
-+ __u32 ecn_mark; /* number of packets we ECN marked
-+ * instead of being dropped
-+ */
-+ __u32 new_flow_count; /* number of time packets
-+ * created a 'new flow'
-+ */
-+ __u32 new_flows_len; /* count of flows in new list */
-+ __u32 old_flows_len; /* count of flows in old list */
-+};
-+
-+struct tc_fq_codel_cl_stats {
-+ __s32 deficit;
-+ __u32 ldelay; /* in-queue delay seen by most recently
-+ * dequeued packet
-+ */
-+ __u32 count;
-+ __u32 lastcount;
-+ __u32 dropping;
-+ __s32 drop_next;
-+};
-+
-+struct tc_fq_codel_xstats {
-+ __u32 type;
-+ union {
-+ struct tc_fq_codel_qd_stats qdisc_stats;
-+ struct tc_fq_codel_cl_stats class_stats;
-+ };
-+};
-+
- #endif
diff --git a/package/network/utils/iproute2/patches/008-no_netem.patch
b/package/network/utils/iproute2/patches/008-no_netem.patch
index c804b14..a6a74aa 100644
--- a/package/network/utils/iproute2/patches/008-no_netem.patch
+++
Re: [OpenWrt-Devel] [PATCH] Add support for TL-WDR3500
On Sat, Jan 19, 2013 at 8:22 PM, Gui Iribarren g...@altermundi.net wrote:
WDR3500 is similar to WDR3600 except it doesn't have gigabit ethernet,
and has only 1 USB port.
So, this patch (over r35162) adds a new board type, based on
mach-tl-wdr4300.c but replacing ethernet config with one based on
mach-tl-wr841n-v8.c
a huge thanks goes out to Paul Fertser for hours of tireless advice!
Pending issues:
* Leds are not working at all
* ethernet ports are all scrambled up:
[Label] - soft device
[WAN] - eth1.1
[LAN1] - eth1.4
[LAN2] - eth1.3
[LAN3] - eth1.2
[LAN4] - eth0
Anyone with experience fixing those details that cares to help, will
be much appreciated!
Signed-off-by: Gui Iribarren g...@altermundi.net
Thanks-to: Paul Fertser fercer...@gmail.com
Inline patch, probably newline-broken :(
Index: target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c
===
--- target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c(revision 0)
+++ target/linux/ar71xx/files/arch/mips/ath79/mach-tl-wdr3500.c(revision 0)
@@ -0,0 +1,139 @@
+/*
+ * TP-LINK TL-WDR3500 board support
+ *
+ * Copyright (C) 2012 Gabor Juhos juh...@openwrt.org
+ * Copyright (C) 2013 Gui Iribarren g...@altermundi.net
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published
+ * by the Free Software Foundation.
+ */
+
+#include linux/pci.h
+#include linux/phy.h
+#include linux/gpio.h
+#include linux/platform_device.h
+#include linux/ath9k_platform.h
+#include linux/ar8216_platform.h
+
+#include asm/mach-ath79/ar71xx_regs.h
+
+#include common.h
+#include dev-ap9x-pci.h
+#include dev-eth.h
+#include dev-gpio-buttons.h
+#include dev-leds-gpio.h
+#include dev-m25p80.h
+#include dev-spi.h
+#include dev-usb.h
+#include dev-wmac.h
+#include machtypes.h
+
+#define WDR3500_GPIO_LED_USB111
+#define WDR3500_GPIO_LED_WLAN2G13
+#define WDR3500_GPIO_LED_SYSTEM14
+#define WDR3500_GPIO_LED_QSS15
+
+#define WDR3500_GPIO_BTN_WPS16
+#define WDR3500_GPIO_BTN_RFKILL17
+
+#define WDR3500_GPIO_USB1_POWER22
+
+#define WDR3500_KEYS_POLL_INTERVAL20/* msecs */
+#define WDR3500_KEYS_DEBOUNCE_INTERVAL(3 * WDR3500_KEYS_POLL_INTERVAL)
+
+#define WDR3500_MAC0_OFFSET0
+#define WDR3500_MAC1_OFFSET6
+#define WDR3500_WMAC_CALDATA_OFFSET0x1000
+#define WDR3500_PCIE_CALDATA_OFFSET0x5000
+
+static const char *wdr3500_part_probes[] = {
+tp-link,
+NULL,
+};
+
+static struct flash_platform_data wdr3500_flash_data = {
+.part_probes= wdr3500_part_probes,
+};
+
+static struct gpio_led wdr3500_leds_gpio[] __initdata = {
+{
+.name= tp-link:blue:qss,
+.gpio= WDR3500_GPIO_LED_QSS,
+.active_low= 1,
+},
+{
+.name= tp-link:blue:system,
+.gpio= WDR3500_GPIO_LED_SYSTEM,
+.active_low= 1,
+},
+{
+.name= tp-link:green:usb1,
+.gpio= WDR3500_GPIO_LED_USB1,
+.active_low= 1,
+},
+{
+.name= tp-link:blue:wlan2g,
+.gpio= WDR3500_GPIO_LED_WLAN2G,
+.active_low= 1,
+},
+};
+
+static struct gpio_keys_button wdr3500_gpio_keys[] __initdata = {
+{
+.desc= QSS button,
+.type= EV_KEY,
+.code= KEY_WPS_BUTTON,
+.debounce_interval = WDR3500_KEYS_DEBOUNCE_INTERVAL,
+.gpio= WDR3500_GPIO_BTN_WPS,
+.active_low= 1,
+},
+{
+.desc= RFKILL switch,
+.type= EV_SW,
+.code= KEY_RFKILL,
+.debounce_interval = WDR3500_KEYS_DEBOUNCE_INTERVAL,
+.gpio= WDR3500_GPIO_BTN_RFKILL,
+},
+};
+
+
+static void __init wdr3500_setup(void)
+{
+u8 *mac = (u8 *) KSEG1ADDR(0x1f01fc00);
+
+ath79_register_m25p80(wdr3500_flash_data);
+ath79_register_leds_gpio(-1, ARRAY_SIZE(wdr3500_leds_gpio),
+ wdr3500_leds_gpio);
+ath79_register_gpio_keys_polled(-1, WDR3500_KEYS_POLL_INTERVAL,
+ARRAY_SIZE(wdr3500_gpio_keys),
+wdr3500_gpio_keys);
+
+ath79_setup_ar934x_eth_cfg(AR934X_ETH_CFG_SW_PHY_SWAP);
+
+ath79_register_mdio(1, 0x0);
+
+ath79_init_mac(ath79_eth0_data.mac_addr, mac, -1);
+ath79_init_mac(ath79_eth1_data.mac_addr, mac, 0);
+
+/* GMAC0 is connected to the PHY0 of the internal switch */
+ath79_switch_data.phy4_mii_en = 1;
+ath79_switch_data.phy_poll_mask = BIT(0);
+ath79_eth0_data.phy_if_mode = PHY_INTERFACE_MODE_MII;
+ath79_eth0_data.phy_mask = BIT(0);
+ath79_eth0_data.mii_bus_dev = ath79_mdio1_device.dev;
+ath79_register_eth(0);
+
+/* GMAC1 is connected to the internal switch */
+ath79_eth1_data.phy_if_mode = PHY_INTERFACE_MODE_GMII;
+
[OpenWrt-Devel] [PATCH] [packages] net/olsrd: IPv6 SmartGW doesn't require IPv6 NAT support
Signed-off-by: Daniel Golle dgo...@allnet.de
---
net/olsrd/files/olsrd.init | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/olsrd/files/olsrd.init b/net/olsrd/files/olsrd.init
index 7578316..5deca06 100644
--- a/net/olsrd/files/olsrd.init
+++ b/net/olsrd/files/olsrd.init
@@ -604,9 +604,9 @@ olsrd_setup_smartgw_rules() {
$IP6T -I input_rule -i $IFACE -p 4 -j
ACCEPT
done
else
+ $IP4T -t nat -I postrouting_rule -o tnl_+ -j
MASQUERADE
for IPT in $IP4T $IP6T; do
$IPT -I forwarding_rule -o tnl_+ -j
ACCEPT
- $IPT -t nat -I postrouting_rule -o
tnl_+ -j MASQUERADE
if [ $nowan=0 ]; then
for IFACE in $wanifnames; do
$IPT -A forwarding_rule
-i tunl0 -o $IFACE -j ACCEPT
--
1.8.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
