Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
On 23/06/2014 20:22, Paul Blazejowski wrote: Hello list, Have found bug in the ubifs component when mounting images on wndr3700v4/4300 routers. This happens in trunk builds after r41130 but does not happen before r41118. Please take a look at bug https://dev.openwrt.org/ticket/16803 i have filed on this issue. Unfortunately i do not have any fixes for this but i am willing to test patches and debug in hopes of getting this fixed. On a side note, sysupgrade image for wndr4300 does work from the web interface on my 3700v4 router but the wndr3700v4 image does not. Guess one bugat a time ;-). cheerios, -paulb Hi, do you know how to build your own image and could you test a patch if i send one ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ethernet problems with trunk on brcm47xx
On 24 June 2014 01:17, Paul Sokolovsky pmis...@gmail.com wrote: Intuitively, this would look like problem with bridging (eth0.0 - br-lan works, but the other direction doesn't), but brctl looks as usual: root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.0015f23d7889 no eth0.0 wlan0 I would appreciate any hints (again, I upgraded, preserving config, from 10.03.1, if that may be relevant). Provide us /etc/config/network ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Guys if you need a guinea pig for testing the WNDR4300's I am happy to assist. Since introducing the sysupgrade features, upon a router reboot all settings are restored to factory defaults. Also, is this mail list a channel that reaches most or all developers? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ethernet problems with trunk on brcm47xx
Hello, On Tue, 24 Jun 2014 10:32:31 +0200 Rafał Miłecki zaj...@gmail.com wrote: On 24 June 2014 01:17, Paul Sokolovsky pmis...@gmail.com wrote: Intuitively, this would look like problem with bridging (eth0.0 - br-lan works, but the other direction doesn't), but brctl looks as usual: root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.0015f23d7889 no eth0.0 wlan0 I would appreciate any hints (again, I upgraded, preserving config, from 10.03.1, if that may be relevant). Provide us /etc/config/network It is: -- config switch 'eth0' option enable '1' config switch_vlan 'eth0_0' option device 'eth0' option vlan '0' option ports '1 2 3 4 5' config switch_vlan 'eth0_1' option device 'eth0' option vlan '1' option ports '0 5' config interface 'loopback' option ifname 'lo' option proto 'static' option ipaddr '127.0.0.1' option netmask '255.0.0.0' config interface 'lan' option type 'bridge' option ifname 'eth0.0' option proto 'static' option netmask '255.255.255.0' option ipaddr '192.168.15.1' config interface 'wan' option ifname 'eth0.1' option proto 'dhcp' -- Which hopefuly for you looks just as normal as for me, so I skipped it initially. -- Best regards, Paul mailto:pmis...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
On 24/06/2014 10:55, Adam Kuklycz wrote: Guys if you need a guinea pig for testing the WNDR4300’s I am happy to assist. Since introducing the sysupgrade features, upon a router reboot all settings are restored to factory defaults. ok, i'll look into it today. i think daniel already pushed a fix for this int the fstools tree. i'll give him a call in a sec to ask. as for 3700, we need to apply the same fixups to tit as we did to 4300. i'll look into this aswell. Also, is this mail list a channel that reaches most or all developers? yes ___ 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] Ethernet problems with trunk on brcm47xx
On 24 June 2014 11:23, Paul Sokolovsky pmis...@gmail.com wrote: config switch_vlan 'eth0_0' option device 'eth0' option vlan '0' option ports '1 2 3 4 5' config switch_vlan 'eth0_1' option device 'eth0' option vlan '1' option ports '0 5' Your CPU port is untagged, it should be: '1 2 3 4 5t' '0 5t' (without this CPU - or OpenWrt - doesn't know if the packet is coming from LAN of WAN). Also you may want to *not* use VID 0, which is a reserved value, see: http://en.wikipedia.org/wiki/IEEE_802.1Q In other words... I suggest deleting /etc/config/network and rebooting to let OpenWrt regenerate new one. Then you will have to simply restore your changes (hint: ipaddr). Older OpenWrt versions were using such a incomplete/invalid configs that don't work anymore with BB+. So sysupgrade to BB is correctly broken. I'll submit some RFC patch for it in a minute. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC][PATCH] brcm47xx: drop network configs with VID 0
Old OpenWrt releases were using network configs that are not valid
anymore. They specified tagging in a different way (or were not tagging
CPU at all), used VID 0 which is a reserved value.
Porting old configs would be tricky (changing VIDs, interfaces names,
ports tagging), so it's probably wiser to drop them.
Signed-off-by: Rafał Miłecki zaj...@gmail.com
---
target/linux/brcm47xx/base-files/etc/init.d/netconfig | 5 +
1 file changed, 5 insertions(+)
diff --git a/target/linux/brcm47xx/base-files/etc/init.d/netconfig
b/target/linux/brcm47xx/base-files/etc/init.d/netconfig
index ced2a42..273c4ec 100755
--- a/target/linux/brcm47xx/base-files/etc/init.d/netconfig
+++ b/target/linux/brcm47xx/base-files/etc/init.d/netconfig
@@ -4,6 +4,11 @@
START=05
start() {
+ # Configs from old releases (10.03, 12.09) are not compatible with BB+
+ # They used to use reserved 0 VID and didn't tag CPU port
+ uci show network | grep \.vlan=0
+ [ $? -eq 0 ] rm /etc/config/network
+
[ -e /etc/config/network ] {
local batch
--
1.8.4.5
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] netifd: Crash when netifd reload is handled during netifd startup
Netifd is crashing when when a network reload (ubus call network reload) is handled during the parsing of the network config in the function config_init_all (called from main) at startup. As an ubus_invoke function call is issued when the interfaces are created; ubus will also process the pending ubus calls in this case the network reload during the invoke. As netifd_reload calls again config_init_all network config will be parsed again; on return from netifd_reload the original config_init_all function call will continue but will crash as references hold to interface/device/etc ... lists are not correct anymore. This potential problem has always been present but due to netifd_reload timing behavior change in netifd commit 5db02763d61785529bef538f196c180e968b7c26 this problem can easily be triggered. To solve the issue I was thinking about deferring the network reload when the function config_init_all is parsing the config. Any opinion if this is the correct way to go or any other alternatives ? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ethernet problems with trunk on brcm47xx
On 2014-06-24 01:17, Paul Sokolovsky wrote: Hello, I upgraded my Asus WL-500g Deluxe from 10.03.1 to today's daily build of trunk (BARRIER BREAKER (Bleeding Edge, r41302)) to test fix for issue https://dev.openwrt.org/ticket/7552 . After upgrade, all WiFi clients work ok. However, all wired ethernet clients lost connectivity. All obvious checks like leds blinking for lan ports, swconfig dev eth0 show showing connected ports up, dnsmasq running on udp 0.0.0.0:67, pass. Ultimately, doing logread -f and connecting cable to my RasPi I see: Mon Jun 23 22:54:14 2014 daemon.info dnsmasq-dhcp[905]: DHCPDISCOVER(br-lan) b8:27:eb:2d:38:4d Mon Jun 23 22:54:14 2014 daemon.info dnsmasq-dhcp[905]: DHCPOFFER(br-lan) 192.168.15.177 b8:27:eb:2d:38:4d Mon Jun 23 22:54:17 2014 daemon.info dnsmasq-dhcp[905]: DHCPDISCOVER(br-lan) b8:27:eb:2d:38:4d Mon Jun 23 22:54:17 2014 daemon.info dnsmasq-dhcp[905]: DHCPOFFER(br-lan) 192.168.15.177 b8:27:eb:2d:38:4d Mon Jun 23 22:54:20 2014 daemon.info dnsmasq-dhcp[905]: DHCPDISCOVER(br-lan) b8:27:eb:2d:38:4d Mon Jun 23 22:54:20 2014 daemon.info dnsmasq-dhcp[905]: DHCPOFFER(br-lan) 192.168.15.177 b8:27:eb:2d:38:4d In other words, dnsmasq on router sees DHCP request from RasPi, and replies to it with IP address, but RasPi never sees that reply and keeps resending requests, until it gives up and autoassigns 169.*. Worse, I cannot access a device with static IP address on the same subnet connected via ethernet (from WiFi client or from router itself). Also, if I connect via ethernet and set static IP on my laptop, I cannot ping router from it. But I can ping and otherwise access another ethernet device with static IP, so switch in router works as expected ;-). Intuitively, this would look like problem with bridging (eth0.0 - br-lan works, but the other direction doesn't), but brctl looks as usual: root@OpenWrt:~# brctl show bridge name bridge id STP enabled interfaces br-lan7fff.0015f23d7889 no eth0.0 wlan0 I would appreciate any hints (again, I upgraded, preserving config, from 10.03.1, if that may be relevant). Please try resetting your config, your network config probably doesn't have the updated switch configuration settings. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC 3/3] PKG_CHECK_FORMAT_SECURITY: disable the check for the failing packages
On 2014-06-23 23:39, Etienne CHAMPETIER wrote: The idea is to gradually fix the packages Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr --- package/libs/gettext-full/Makefile|1 + package/network/utils/comgt/Makefile |1 + package/network/utils/iperf/Makefile |1 + package/network/utils/linux-atm/Makefile |1 + package/network/utils/xtables-addons/Makefile |1 + package/system/fstools/Makefile |1 + package/system/mountd/Makefile|1 + package/system/ubox/Makefile |1 + package/utils/busybox/Makefile|1 + package/utils/px5g-standalone/Makefile|1 + package/utils/xfsprogs/Makefile |1 + 11 files changed, 11 insertions(+), 0 deletions(-) Is this the full list of broken packages, or are there more? By the way, this patch should probably be the first one on the list (followed by the rbcfg fix) to avoid unnecessary regressions between commits. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Ethernet problems with trunk on brcm47xx
Hello, On Tue, 24 Jun 2014 12:08:04 +0200 Rafał Miłecki zaj...@gmail.com wrote: On 24 June 2014 11:23, Paul Sokolovsky pmis...@gmail.com wrote: config switch_vlan 'eth0_0' option device 'eth0' option vlan '0' option ports '1 2 3 4 5' config switch_vlan 'eth0_1' option device 'eth0' option vlan '1' option ports '0 5' Your CPU port is untagged, it should be: '1 2 3 4 5t' '0 5t' (without this CPU - or OpenWrt - doesn't know if the packet is coming from LAN of WAN). Pure magic, thanks for spotting this, Rafał! I remember seeing these t's once upon a time, but I hack on OpenWRT too rarely to spot it missing. I was reluctant to do config reset, risking losing WiFi connection too. Will now proceed to b43 fixes testing. Also you may want to *not* use VID 0, which is a reserved value, see: http://en.wikipedia.org/wiki/IEEE_802.1Q In other words... I suggest deleting /etc/config/network and rebooting to let OpenWrt regenerate new one. Then you will have to simply restore your changes (hint: ipaddr). Older OpenWrt versions were using such a incomplete/invalid configs that don't work anymore with BB+. So sysupgrade to BB is correctly broken. I'll submit some RFC patch for it in a minute. Thanks. -- Best regards, Paul mailto:pmis...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] 答复: [RFC] netifd: Crash when netifd reload is handled during netifd startup
Hi,
That commit was intended to fix a bug report by me. I also attached a patch
with my issue:
diff --git a/package/netifd/files/sbin/ifup b/package/netifd/files/sbin/ifup
index af3aaa8..15c0c8e 100755
--- a/package/netifd/files/sbin/ifup
+++ b/package/netifd/files/sbin/ifup
@@ -35,7 +35,7 @@ while :; do
-[ $modes = down up ] ubus call network reload
+[ $modes = down up ] ubus call network reload sleep 1
if [ -n $ifup_all ]; then
for interface in `ubus -S list 'network.interface.*'`; do
if_call ${interface##network.interface.}
This will fix the ifup script and leave netifd's deferred reload untouched.
发件人: openwrt-devel [openwrt-devel-boun...@lists.openwrt.org] 代表 Hans Dedecker
[dedec...@gmail.com]
发送时间: 2014年6月24日 18:46
收件人: openwrt-devel@lists.openwrt.org
主题: [OpenWrt-Devel] [RFC] netifd: Crash when netifd reload is handled during
netifd startup
Netifd is crashing when when a network reload (ubus call network reload) is
handled during the parsing of the network config in the function
config_init_all (called from main) at startup.
As an ubus_invoke function call is issued when the interfaces are created; ubus
will also process the pending ubus calls in this case the network reload during
the invoke.
As netifd_reload calls again config_init_all network config will be parsed
again; on return from netifd_reload the original config_init_all function call
will continue but will crash as references hold to interface/device/etc ...
lists are not correct anymore.
This potential problem has always been present but due to netifd_reload timing
behavior change in netifd commit 5db02763d61785529bef538f196c180e968b7c26 this
problem can easily be triggered.
To solve the issue I was thinking about deferring the network reload when the
function config_init_all is parsing the config.
Any opinion if this is the correct way to go or any other alternatives ?
___
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] [RFC 3/3] PKG_CHECK_FORMAT_SECURITY: disable the check for the failing packages
hi - Mail original - De: Felix Fietkau n...@openwrt.org À: Etienne CHAMPETIER etienne.champet...@free.fr, openwrt-devel@lists.openwrt.org Envoyé: Mardi 24 Juin 2014 12:48:37 Objet: Re: [OpenWrt-Devel] [RFC 3/3] PKG_CHECK_FORMAT_SECURITY: disable the check for the failing packages On 2014-06-23 23:39, Etienne CHAMPETIER wrote: The idea is to gradually fix the packages Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr --- package/libs/gettext-full/Makefile|1 + package/network/utils/comgt/Makefile |1 + package/network/utils/iperf/Makefile |1 + package/network/utils/linux-atm/Makefile |1 + package/network/utils/xtables-addons/Makefile |1 + package/system/fstools/Makefile |1 + package/system/mountd/Makefile|1 + package/system/ubox/Makefile |1 + package/utils/busybox/Makefile|1 + package/utils/px5g-standalone/Makefile|1 + package/utils/xfsprogs/Makefile |1 + 11 files changed, 11 insertions(+), 0 deletions(-) Is this the full list of broken packages, or are there more? By the way, this patch should probably be the first one on the list (followed by the rbcfg fix) to avoid unnecessary regressions between commits. - Felix It's the full list of 'core' package (when building ar71xx / CONFIG_ALL=y) I also have a patch for the new 'package' feed routing and luci are ok haven't rebuild telephony and old-package Anyway the compile errors are pretty obvious, and there is no run time errors If everything is fine i'll resend tonight. Etienne ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] netifd: Crash when netifd reload is handled during netifd startup
On 2014-06-24 12:46, Hans Dedecker wrote: Netifd is crashing when when a network reload (ubus call network reload) is handled during the parsing of the network config in the function config_init_all (called from main) at startup. As an ubus_invoke function call is issued when the interfaces are created; ubus will also process the pending ubus calls in this case the network reload during the invoke. As netifd_reload calls again config_init_all network config will be parsed again; on return from netifd_reload the original config_init_all function call will continue but will crash as references hold to interface/device/etc ... lists are not correct anymore. This potential problem has always been present but due to netifd_reload timing behavior change in netifd commit 5db02763d61785529bef538f196c180e968b7c26 this problem can easily be triggered. To solve the issue I was thinking about deferring the network reload when the function config_init_all is parsing the config. Any opinion if this is the correct way to go or any other alternatives ? Please try applying this patch to ubus: http://nbd.name/libubus-req-defer.patch It should ensure that no invoke will be processed while netifd is busy with registering/unregistering objects or sending notify calls. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update MT7530 switch driver.
Hi,
On 21/06/2014 17:10, xf...@credosemi.com wrote:
From: Xiongfei Guo xf...@credosemi.com
- Support set VLAN ID of each vlan. - Support untag feature. -
Replace register address with C MACRO. - There are 8 ports for
MT7530 actually.
Signed-off-by: Xiongfei Guo xf...@credosemi.com
on which boards did you test this ? i want to give it a quick try on
the eval kit today before merging the patch. i have so far not seen
any boards in the wild with this switch
John
--- ...8-NET-MIPS-add-ralink-SoC-ethernet-driver.patch | 268
++--- 1 file changed, 186 insertions(+), 82
deletions(-)
diff --git
a/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
b/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
index 75f78bf..c8ec17c 100644
---
a/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
+++
b/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
@@ -2814,7 +2814,7 @@ Signed-off-by: John Crispin
blo...@openwrt.org +#endif --- /dev/null +++
b/drivers/net/ethernet/ralink/mt7530.c -@@ -0,0 +1,467 @@ +@@ -0,0
+1,571 @@ +/* + * This program is free software; you can
redistribute it and/or + * modify it under the terms of the GNU
General Public License @@ -2851,25 +2851,45 @@ Signed-off-by: John
Crispin blo...@openwrt.org +#include mt7530.h + +#define
MT7530_CPU_PORT 6 -+#define MT7530_NUM_PORTS7 ++#define
MT7530_NUM_PORTS 8 +#define MT7530_NUM_VLANS 16 -+#define
MT7530_NUM_VIDS 16 ++#define MT7530_MAX_VID 4095
++#define
MT7530_MIN_VID0 + -+#define REG_ESW_VLAN_VTCR 0x90 -+#define
REG_ESW_VLAN_VAWD10x94 -+#define REG_ESW_VLAN_VAWD2 0x98 ++/*
registers */ ++#define REG_ESW_VLAN_VTCR 0x90 ++#define
REG_ESW_VLAN_VAWD10x94 ++#define REG_ESW_VLAN_VAWD2
0x98
++#define REG_ESW_VLAN_VTIM(x)(0x100 + 4 * ((x) / 2)) ++ ++#define
REG_ESW_VLAN_VAWD1_IVL_MACBIT(30) ++#define
REG_ESW_VLAN_VAWD1_VTAG_ENBIT(28) ++#define
REG_ESW_VLAN_VAWD1_VALID BIT(0) ++ ++/* vlan egress mode */ ++enum
{ ++ ETAG_CTRL_UNTAG = 0, ++ ETAG_CTRL_TAG = 2, ++ ETAG_CTRL_SWAP =
1, ++ ETAG_CTRL_STACK = 3, ++}; + ++#define REG_ESW_PORT_PCR(x)
(0x2004 | ((x) 8)) ++#define REG_ESW_PORT_PVC(x) (0x2010 | ((x)
8)) ++#define REG_ESW_PORT_PPBV1(x)(0x2014 | ((x) 8)) +enum
{ + /* Global attributes. */ + MT7530_ATTR_ENABLE_VLAN, +}; +
-+struct mt7530_port { ++struct mt7530_port_entry { + u16 pvid;
+}; + -+struct mt7530_vlan { -+ u8 ports; ++struct
mt7530_vlan_entry { ++u16 vid; ++ u8 member; ++ u8
etags; +}; +
+struct mt7530_priv { @@ -2878,23 +2898,29 @@ Signed-off-by: John
Crispin blo...@openwrt.org +struct switch_dev swdev; + +
bool
global_vlan_enable; -+struct mt7530_vlan
vlans[MT7530_NUM_VLANS];
-+struct mt7530_port ports[MT7530_NUM_PORTS]; ++ struct
mt7530_vlan_entry vlan_entries[MT7530_NUM_VLANS]; ++ struct
mt7530_port_entry port_entries[MT7530_NUM_PORTS]; +}; + +struct
mt7530_mapping { +char*name; -+ u8 pvids[6]; -+u8
vlans[8]; ++
u16 pvids[MT7530_NUM_PORTS]; ++ u8 members[MT7530_NUM_VLANS]; ++
u8
etags[MT7530_NUM_VLANS]; ++ u16 vids[MT7530_NUM_VLANS]; +}
mt7530_defaults[] = { + { + .name = w, -+
.pvids = { 1, 1,
1, 1, 2, 1 }, -+ .vlans = { 0, 0x6f, 0x50 }, ++ .pvids
= { 1, 1,
1, 1, 2, 1, 1 }, ++ .members = { 0x6f, 0x50 }, ++ .etags
= {
0x40, 0x40 }, ++ .vids = { 1, 2 }, + }, { + .name =
w, -+
.pvids = { 2, 1, 1, 1, 1, 1 }, -+ .vlans = { 0, 0x7e, 0x41 }, ++
.pvids = { 2, 1, 1, 1, 1, 1, 1 }, ++ .members = { 0x7e, 0x41 }, ++
.etags = { 0x40, 0x40 }, ++ .vids = { 1, 2 }, + }, +}; + @@
-2921,10 +2947,14 @@ Signed-off-by: John Crispin
blo...@openwrt.org + + mt7530-global_vlan_enable = 1; + -+for
(i = 0; i 6; i++) -+mt7530-ports[i].pvid = map-pvids[i];
-+
for (i = 0; i 8; i++) -+mt7530-vlans[i].ports =
map-vlans[i]; ++ for (i = 0; i MT7530_NUM_PORTS; i++) ++
mt7530-port_entries[i].pvid = map-pvids[i]; ++ ++ for (i = 0; i
MT7530_NUM_VLANS; i++) { ++ mt7530-vlan_entries[i].member =
map-members[i]; ++ mt7530-vlan_entries[i].etags =
map-etags[i]; ++ mt7530-vlan_entries[i].vid = map-vids[i]; ++
} +} + +static int @@ -2932,8 +2962,8 @@ Signed-off-by: John
Crispin blo...@openwrt.org +{ + struct mt7530_priv *priv =
container_of(dev, struct mt7530_priv, swdev); + -+
memset(priv-ports, 0, sizeof(priv-ports)); -+ memset(priv-vlans,
0, sizeof(priv-vlans)); ++ memset(priv-port_entries, 0,
Re: [OpenWrt-Devel] [PATCH v2 1/3] ar71xx: add kernel support for the EnGenius ESR900
Hi,
On 22/06/2014 22:20, Forest Crossman wrote:
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/nvram.c
b/target/linux/ar71xx/files/arch/mips/ath79/nvram.c index
43911b8..41c3542 100644 ---
a/target/linux/ar71xx/files/arch/mips/ath79/nvram.c +++
b/target/linux/ar71xx/files/arch/mips/ath79/nvram.c @@ -16,6
+16,21 @@
#include nvram.h
+char *ath79_nvram_sanitize_mac(char *input) +{ + int i,j; + char
*output=input; + for (i = 0, j = 0; istrlen(input); i++,j++) + {
+ if (input[i]!='\') + output[j]=input[i]; +
else + j--; + }
+ output[j]=0; + return output; +} + char
*ath79_nvram_find_var(const char *name, const char *buf, unsigned
buf_len) { unsigned len = strlen(name);
this loop is a bit weird. ca you tell us in what way the mac is broken
on your board ?
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update MT7530 switch driver.
hi,
I'm test it on Mercury MW305R with a modified dts file for RT-N14U. Maybe I
can give a dts patch for this board later.
Actually, MT7530 is the ethernet switch inside the MTK MT7620A/N. So you
can try it with any MT7620 based board.
Xiongfei Guo
Credo Semi.
On Tue, Jun 24, 2014 at 8:54 PM, John Crispin j...@phrozen.org wrote:
Hi,
On 21/06/2014 17:10, xf...@credosemi.com wrote:
From: Xiongfei Guo xf...@credosemi.com
- Support set VLAN ID of each vlan. - Support untag feature. -
Replace register address with C MACRO. - There are 8 ports for
MT7530 actually.
Signed-off-by: Xiongfei Guo xf...@credosemi.com
on which boards did you test this ? i want to give it a quick try on
the eval kit today before merging the patch. i have so far not seen
any boards in the wild with this switch
John
--- ...8-NET-MIPS-add-ralink-SoC-ethernet-driver.patch | 268
++--- 1 file changed, 186 insertions(+), 82
deletions(-)
diff --git
a/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
b/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
index 75f78bf..c8ec17c 100644
---
a/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
+++
b/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
@@ -2814,7 +2814,7 @@ Signed-off-by: John Crispin
blo...@openwrt.org +#endif --- /dev/null +++
b/drivers/net/ethernet/ralink/mt7530.c -@@ -0,0 +1,467 @@ +@@ -0,0
+1,571 @@ +/* + * This program is free software; you can
redistribute it and/or + * modify it under the terms of the GNU
General Public License @@ -2851,25 +2851,45 @@ Signed-off-by: John
Crispin blo...@openwrt.org +#include mt7530.h + +#define
MT7530_CPU_PORT 6 -+#define MT7530_NUM_PORTS7 ++#define
MT7530_NUM_PORTS 8 +#define MT7530_NUM_VLANS 16 -+#define
MT7530_NUM_VIDS 16 ++#define MT7530_MAX_VID
4095 ++#define
MT7530_MIN_VID0 + -+#define REG_ESW_VLAN_VTCR 0x90
-+#define
REG_ESW_VLAN_VAWD10x94 -+#define REG_ESW_VLAN_VAWD2 0x98 ++/*
registers */ ++#define REG_ESW_VLAN_VTCR 0x90 ++#define
REG_ESW_VLAN_VAWD10x94 ++#define REG_ESW_VLAN_VAWD2
0x98
++#define REG_ESW_VLAN_VTIM(x)(0x100 + 4 * ((x) / 2)) ++
++#define
REG_ESW_VLAN_VAWD1_IVL_MACBIT(30) ++#define
REG_ESW_VLAN_VAWD1_VTAG_ENBIT(28) ++#define
REG_ESW_VLAN_VAWD1_VALID BIT(0) ++ ++/* vlan egress mode */ ++enum
{ ++ ETAG_CTRL_UNTAG = 0, ++ ETAG_CTRL_TAG = 2, ++ ETAG_CTRL_SWAP =
1, ++ ETAG_CTRL_STACK = 3, ++}; + ++#define REG_ESW_PORT_PCR(x)
(0x2004 | ((x) 8)) ++#define REG_ESW_PORT_PVC(x) (0x2010 | ((x)
8)) ++#define REG_ESW_PORT_PPBV1(x)(0x2014 | ((x) 8)) +enum
{ + /* Global attributes. */ + MT7530_ATTR_ENABLE_VLAN, +}; +
-+struct mt7530_port { ++struct mt7530_port_entry { + u16 pvid;
+}; + -+struct mt7530_vlan { -+ u8 ports; ++struct
mt7530_vlan_entry { ++u16 vid; ++ u8 member; ++ u8
etags; +}; +
+struct mt7530_priv { @@ -2878,23 +2898,29 @@ Signed-off-by: John
Crispin blo...@openwrt.org +struct switch_dev swdev; +
+ bool
global_vlan_enable; -+struct mt7530_vlan
vlans[MT7530_NUM_VLANS];
-+struct mt7530_port ports[MT7530_NUM_PORTS]; ++ struct
mt7530_vlan_entry vlan_entries[MT7530_NUM_VLANS]; ++ struct
mt7530_port_entry port_entries[MT7530_NUM_PORTS]; +}; + +struct
mt7530_mapping { +char*name; -+ u8 pvids[6]; -+u8
vlans[8]; ++
u16 pvids[MT7530_NUM_PORTS]; ++ u8 members[MT7530_NUM_VLANS];
++ u8
etags[MT7530_NUM_VLANS]; ++ u16 vids[MT7530_NUM_VLANS]; +}
mt7530_defaults[] = { + { + .name = w, -+
.pvids = { 1, 1,
1, 1, 2, 1 }, -+ .vlans = { 0, 0x6f, 0x50 }, ++
.pvids = { 1, 1,
1, 1, 2, 1, 1 }, ++ .members = { 0x6f, 0x50 }, ++
.etags = {
0x40, 0x40 }, ++ .vids = { 1, 2 }, + }, { +
.name = w, -+
.pvids = { 2, 1, 1, 1, 1, 1 }, -+ .vlans = { 0, 0x7e, 0x41
}, ++
.pvids = { 2, 1, 1, 1, 1, 1, 1 }, ++ .members = { 0x7e, 0x41 },
++
.etags = { 0x40, 0x40 }, ++ .vids = { 1, 2 }, + }, +}; + @@
-2921,10 +2947,14 @@ Signed-off-by: John Crispin
blo...@openwrt.org + + mt7530-global_vlan_enable = 1; + -+
for
(i = 0; i 6; i++) -+mt7530-ports[i].pvid =
map-pvids[i]; -+
for (i = 0; i 8; i++) -+mt7530-vlans[i].ports =
map-vlans[i]; ++ for (i = 0; i MT7530_NUM_PORTS; i++) ++
mt7530-port_entries[i].pvid = map-pvids[i]; ++ ++ for (i = 0; i
MT7530_NUM_VLANS; i++) { ++ mt7530-vlan_entries[i].member =
map-members[i]; ++ mt7530-vlan_entries[i].etags =
map-etags[i]; ++
Re: [OpenWrt-Devel] [PATCH v2 1/3] ar71xx: add kernel support for the EnGenius ESR900
The MAC as it's stored the u-boot environment looks like
'ethaddr=XX:XX:XX:XX:XX:XX', so to get the other functions to parse
the MAC correctly, I had to get rid of the quotes before and after the
MAC. There might be a better way to do it, but this method didn't seem
too horrible. All this function does is loop through each char in the
string to check if it's a quotation mark. If it is, it skips over it
and puts the next char in the place the quote would go, effectively
doing a `tr -d '\'` on the MAC string. It then fills the rest of the
output array with null bytes before returning it. If the MAC string
doesn't have any quotes in it, it just returns the input string.
I suppose I could have just checked to make sure the first and last
chars were quotes and then returned the MAC string sans those chars,
but that didn't occur to me at the time I was writing that function.
--
Forest Crossman
On Tue, Jun 24, 2014 at 9:01 AM, John Crispin j...@phrozen.org wrote:
Hi,
On 22/06/2014 22:20, Forest Crossman wrote:
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/nvram.c
b/target/linux/ar71xx/files/arch/mips/ath79/nvram.c index
43911b8..41c3542 100644 ---
a/target/linux/ar71xx/files/arch/mips/ath79/nvram.c +++
b/target/linux/ar71xx/files/arch/mips/ath79/nvram.c @@ -16,6
+16,21 @@
#include nvram.h
+char *ath79_nvram_sanitize_mac(char *input) +{ + int i,j; + char
*output=input; + for (i = 0, j = 0; istrlen(input); i++,j++) + {
+ if (input[i]!='\') + output[j]=input[i]; +
else + j--; + }
+ output[j]=0; + return output; +} + char
*ath79_nvram_find_var(const char *name, const char *buf, unsigned
buf_len) { unsigned len = strlen(name);
this loop is a bit weird. ca you tell us in what way the mac is broken
on your board ?
John
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] netifd: Crash when netifd reload is handled during netifd startup
Hi, Applied the ubus patch but netifd_reload is still called while config_init_all is processing the config and thus leading to a crash when netifd_reload is done Added extra traces in netifd which confirms this : un 24 16:00:44 OpenWrt daemon.notice netifd: config_init_all : Enter Jun 24 16:00:44 OpenWrt daemon.notice netifd: Create interface 'loopback' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Create simple device 'lo' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Initialize device 'lo' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Remove a route from device lo Jun 24 16:00:44 OpenWrt daemon.notice netifd: Remove a route from device lo Jun 24 16:00:44 OpenWrt daemon.notice netifd: Remove a route from device lo Jun 24 16:00:44 OpenWrt daemon.notice netifd: Network device 'lo' is now present Jun 24 16:00:44 OpenWrt daemon.notice netifd: Add user for device 'lo', refcount=1 Jun 24 16:00:44 OpenWrt daemon.notice netifd: Interface 'loopback', available=1 Jun 24 16:00:44 OpenWrt daemon.notice netifd: Add user for device 'lo', refcount=2 Jun 24 16:00:44 OpenWrt daemon.notice netifd: netifd_reload : Enter Jun 24 16:00:44 OpenWrt daemon.notice netifd: config_init_all : Enter Jun 24 16:00:44 OpenWrt daemon.notice netifd: Update interface 'loopback' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Create new device 'br-lan' (Bridge) Jun 24 16:00:44 OpenWrt daemon.notice netifd: Initialize device 'br-lan' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Create interface 'lan' . Jun 24 16:00:45 OpenWrt daemon.notice netifd: config_init_all : Exit Jun 24 16:00:45 OpenWrt daemon.notice netifd: netifd_reload : Exit Hans On Tue, Jun 24, 2014 at 2:05 PM, Felix Fietkau n...@openwrt.org wrote: On 2014-06-24 12:46, Hans Dedecker wrote: Netifd is crashing when when a network reload (ubus call network reload) is handled during the parsing of the network config in the function config_init_all (called from main) at startup. As an ubus_invoke function call is issued when the interfaces are created; ubus will also process the pending ubus calls in this case the network reload during the invoke. As netifd_reload calls again config_init_all network config will be parsed again; on return from netifd_reload the original config_init_all function call will continue but will crash as references hold to interface/device/etc ... lists are not correct anymore. This potential problem has always been present but due to netifd_reload timing behavior change in netifd commit 5db02763d61785529bef538f196c180e968b7c26 this problem can easily be triggered. To solve the issue I was thinking about deferring the network reload when the function config_init_all is parsing the config. Any opinion if this is the correct way to go or any other alternatives ? Please try applying this patch to ubus: http://nbd.name/libubus-req-defer.patch It should ensure that no invoke will be processed while netifd is busy with registering/unregistering objects or sending notify calls. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Hi John, yes i know my way around ;-) so please do share the patch so i can test... Thank you, -paul On Tue, 2014-06-24 at 09:36 +0200, John Crispin wrote: On 23/06/2014 20:22, Paul Blazejowski wrote: Hello list, Have found bug in the ubifs component when mounting images on wndr3700v4/4300 routers. This happens in trunk builds after r41130 but does not happen before r41118. Please take a look at bug https://dev.openwrt.org/ticket/16803 i have filed on this issue. Unfortunately i do not have any fixes for this but i am willing to test patches and debug in hopes of getting this fixed. On a side note, sysupgrade image for wndr4300 does work from the web interface on my 3700v4 router but the wndr3700v4 image does not. Guess one bugat a time ;-). cheerios, -paulb Hi, do you know how to build your own image and could you test a patch if i send one ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update MT7530 switch driver.
On 24/06/2014 15:54, Xiongfei(Alex) GUO wrote:
hi,
I'm test it on Mercury MW305R with a modified dts file for
RT-N14U. Maybe I can give a dts patch for this board later.
Actually, MT7530 is the ethernet switch inside the MTK MT7620A/N.
So you can try it with any MT7620 based board.
it is also the ip core inside the external chip and its inside the
mt7621. that is why i ask, testing on mt7620 only is not enough we need
to test a few more boards.
DTS file patches are welcome ...
thanks for the info i hope to look at this the next 2 days
John
Xiongfei Guo Credo Semi.
On Tue, Jun 24, 2014 at 8:54 PM, John Crispin j...@phrozen.org
mailto:j...@phrozen.org wrote:
Hi,
On 21/06/2014 17:10, xf...@credosemi.com
mailto:xf...@credosemi.com wrote:
From: Xiongfei Guo xf...@credosemi.com
mailto:xf...@credosemi.com
- Support set VLAN ID of each vlan. - Support untag feature. -
Replace register address with C MACRO. - There are 8 ports for
MT7530 actually.
Signed-off-by: Xiongfei Guo xf...@credosemi.com
mailto:xf...@credosemi.com
on which boards did you test this ? i want to give it a quick try
on the eval kit today before merging the patch. i have so far not
seen any boards in the wild with this switch
John
--- ...8-NET-MIPS-add-ralink-SoC-ethernet-driver.patch | 268
++--- 1 file changed, 186 insertions(+), 82
deletions(-)
diff --git
a/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
b/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
index 75f78bf..c8ec17c 100644
---
a/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
+++
b/target/linux/ramips/patches-3.10/0118-NET-MIPS-add-ralink-SoC-ethernet-driver.patch
@@ -2814,7 +2814,7 @@ Signed-off-by: John Crispin
blo...@openwrt.org mailto:blo...@openwrt.org +#endif ---
/dev/null +++
b/drivers/net/ethernet/ralink/mt7530.c -@@ -0,0 +1,467 @@ +@@
-0,0 +1,571 @@ +/* + * This program is free software; you can
redistribute it and/or + * modify it under the terms of the GNU
General Public License @@ -2851,25 +2851,45 @@ Signed-off-by:
John Crispin blo...@openwrt.org mailto:blo...@openwrt.org
+#include
mt7530.h + +#define
MT7530_CPU_PORT 6 -+#define MT7530_NUM_PORTS7
++#define
MT7530_NUM_PORTS 8 +#define MT7530_NUM_VLANS 16
-+#define MT7530_NUM_VIDS 16 ++#define
MT7530_MAX_VID
4095 ++#define
MT7530_MIN_VID0 + -+#define REG_ESW_VLAN_VTCR
0x90
-+#define
REG_ESW_VLAN_VAWD10x94 -+#define REG_ESW_VLAN_VAWD2
0x98
++/*
registers */ ++#define REG_ESW_VLAN_VTCR 0x90
++#define REG_ESW_VLAN_VAWD10x94 ++#define
REG_ESW_VLAN_VAWD2
0x98
++#define REG_ESW_VLAN_VTIM(x)(0x100 + 4 * ((x) / 2)) ++
++#define
REG_ESW_VLAN_VAWD1_IVL_MACBIT(30) ++#define
REG_ESW_VLAN_VAWD1_VTAG_ENBIT(28) ++#define
REG_ESW_VLAN_VAWD1_VALID BIT(0) ++ ++/* vlan egress mode */
++enum
{ ++ ETAG_CTRL_UNTAG = 0, ++ ETAG_CTRL_TAG = 2, ++
ETAG_CTRL_SWAP =
1, ++ ETAG_CTRL_STACK = 3, ++}; + ++#define REG_ESW_PORT_PCR(x)
(0x2004 | ((x) 8)) ++#define REG_ESW_PORT_PVC(x) (0x2010 |
((x) 8)) ++#define REG_ESW_PORT_PPBV1(x)(0x2014 | ((x)
8)) +enum
{ + /* Global attributes. */ + MT7530_ATTR_ENABLE_VLAN,
+}; + -+struct mt7530_port { ++struct mt7530_port_entry { + u16
pvid; +}; + -+struct mt7530_vlan { -+ u8 ports;
++struct mt7530_vlan_entry { ++u16 vid; ++ u8
member; ++
u8 etags; +}; +
+struct mt7530_priv { @@ -2878,23 +2898,29 @@ Signed-off-by:
John Crispin blo...@openwrt.org mailto:blo...@openwrt.org +
struct switch_dev swdev; + + bool
global_vlan_enable; -+struct mt7530_vlan
vlans[MT7530_NUM_VLANS];
-+struct mt7530_port ports[MT7530_NUM_PORTS]; ++
struct mt7530_vlan_entry vlan_entries[MT7530_NUM_VLANS]; ++
struct mt7530_port_entry port_entries[MT7530_NUM_PORTS]; +};
+ +struct mt7530_mapping { +char*name; -+ u8
pvids[6]; -+
u8 vlans[8]; ++
u16 pvids[MT7530_NUM_PORTS]; ++ u8
members[MT7530_NUM_VLANS]; ++ u8
etags[MT7530_NUM_VLANS]; ++ u16 vids[MT7530_NUM_VLANS]; +}
mt7530_defaults[] = { + { + .name = w,
-+
.pvids = { 1, 1,
1, 1, 2, 1 }, -+ .vlans = { 0, 0x6f, 0x50 }, ++
.pvids = { 1, 1,
1, 1, 2, 1, 1 }, ++ .members = { 0x6f, 0x50 }, ++
.etags = {
0x40, 0x40 }, ++ .vids = { 1, 2 }, + }, { +
.name = w, -+
.pvids = { 2, 1, 1, 1, 1, 1 }, -+ .vlans = { 0,
0x7e,
0x41 }, ++
.pvids = { 2, 1, 1, 1, 1, 1, 1 }, ++ .members = { 0x7e,
0x41 }, ++
.etags = { 0x40, 0x40 }, ++ .vids = { 1, 2 }, + },
+}; + @@
-2921,10 +2947,14 @@ Signed-off-by: John Crispin
blo...@openwrt.org mailto:blo...@openwrt.org + +
mt7530-global_vlan_enable
Re: [OpenWrt-Devel] [RFC] netifd: Crash when netifd reload is handled during netifd startup
Hi Hans, thanks for testing. I uploaded a new patch (same URL), which uses a uloop timer to defer processing of incoming invoke msgs. Note that this changes the ubus context data structure and thus affects everything that depends on ubus, so it's better to reflash after rebuilding. - Felix On 2014-06-24 16:11, Hans Dedecker wrote: Hi, Applied the ubus patch but netifd_reload is still called while config_init_all is processing the config and thus leading to a crash when netifd_reload is done Added extra traces in netifd which confirms this : un 24 16:00:44 OpenWrt daemon.notice netifd: config_init_all : Enter Jun 24 16:00:44 OpenWrt daemon.notice netifd: Create interface 'loopback' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Create simple device 'lo' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Initialize device 'lo' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Remove a route from device lo Jun 24 16:00:44 OpenWrt daemon.notice netifd: Remove a route from device lo Jun 24 16:00:44 OpenWrt daemon.notice netifd: Remove a route from device lo Jun 24 16:00:44 OpenWrt daemon.notice netifd: Network device 'lo' is now present Jun 24 16:00:44 OpenWrt daemon.notice netifd: Add user for device 'lo', refcount=1 Jun 24 16:00:44 OpenWrt daemon.notice netifd: Interface 'loopback', available=1 Jun 24 16:00:44 OpenWrt daemon.notice netifd: Add user for device 'lo', refcount=2 Jun 24 16:00:44 OpenWrt daemon.notice netifd: netifd_reload : Enter Jun 24 16:00:44 OpenWrt daemon.notice netifd: config_init_all : Enter Jun 24 16:00:44 OpenWrt daemon.notice netifd: Update interface 'loopback' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Create new device 'br-lan' (Bridge) Jun 24 16:00:44 OpenWrt daemon.notice netifd: Initialize device 'br-lan' Jun 24 16:00:44 OpenWrt daemon.notice netifd: Create interface 'lan' . Jun 24 16:00:45 OpenWrt daemon.notice netifd: config_init_all : Exit Jun 24 16:00:45 OpenWrt daemon.notice netifd: netifd_reload : Exit Hans On Tue, Jun 24, 2014 at 2:05 PM, Felix Fietkau n...@openwrt.org wrote: On 2014-06-24 12:46, Hans Dedecker wrote: Netifd is crashing when when a network reload (ubus call network reload) is handled during the parsing of the network config in the function config_init_all (called from main) at startup. As an ubus_invoke function call is issued when the interfaces are created; ubus will also process the pending ubus calls in this case the network reload during the invoke. As netifd_reload calls again config_init_all network config will be parsed again; on return from netifd_reload the original config_init_all function call will continue but will crash as references hold to interface/device/etc ... lists are not correct anymore. This potential problem has always been present but due to netifd_reload timing behavior change in netifd commit 5db02763d61785529bef538f196c180e968b7c26 this problem can easily be triggered. To solve the issue I was thinking about deferring the network reload when the function config_init_all is parsing the config. Any opinion if this is the correct way to go or any other alternatives ? Please try applying this patch to ubus: http://nbd.name/libubus-req-defer.patch It should ensure that no invoke will be processed while netifd is busy with registering/unregistering objects or sending notify calls. - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] brcm47xx: migrate basic network settings from old releases
Old OpenWrt releases were using network configs that are not valid anymore. They were specifying ports tagging in a different way (or were not tagging CPU at all) and were using VID 0 which is a reserved value. Modifying network configuration to apply all needed changes would be pretty tricky. Script /etc/init.d/netconfig that generates new config is quite complex itself. So instead let's save the most important settings, regenerate config from the scratch and restore values. This should work for 99% of users. Signed-off-by: Rafał Miłecki zaj...@gmail.com --- .../etc/uci-defaults/03_network_migration | 29 ++ 1 file changed, 29 insertions(+) create mode 100644 target/linux/brcm47xx/base-files/etc/uci-defaults/03_network_migration diff --git a/target/linux/brcm47xx/base-files/etc/uci-defaults/03_network_migration b/target/linux/brcm47xx/base-files/etc/uci-defaults/03_network_migration new file mode 100644 index 000..cef5add --- /dev/null +++ b/target/linux/brcm47xx/base-files/etc/uci-defaults/03_network_migration @@ -0,0 +1,29 @@ +#!/bin/sh +# +# Copyright (C) 2014 OpenWrt.org +# + +uci show network | grep \.vlan=0 +[ $? -ne 0 ] exit 0 + +logger -t network network config is invalid, creating new one + +local lan_proto=$(uci -q get network.lan.proto) +local lan_ipaddr=$(uci -q get network.lan.ipaddr) +local lan_netmask=$(uci -q get network.lan.netmask) +local wan_proto=$(uci -q get network.wan.proto) +local wan_ipaddr=$(uci -q get network.wan.ipaddr) +local wan_netmask=$(uci -q get network.wan.netmask) + +rm /etc/config/network +/etc/init.d/netconfig start + +uci set network.lan.proto=$lan_proto +uci set network.lan.ipaddr=$lan_ipaddr +uci set network.lan.netmask=$lan_netmask +uci set network.wan.proto=$wan_proto +uci set network.wan.ipaddr=$wan_ipaddr +uci set network.wan.netmask=$wan_netmask +uci commit network + +exit 0 -- 1.8.4.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] PKG_CHECK_FORMAT_SECURITY: fix rbcfg
Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr --- package/boot/rbcfg/src/main.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/package/boot/rbcfg/src/main.c b/package/boot/rbcfg/src/main.c index 5614a6c..b7cf79f 100644 --- a/package/boot/rbcfg/src/main.c +++ b/package/boot/rbcfg/src/main.c @@ -724,7 +724,7 @@ usage(void) const struct rbcfg_command *cmd; cmd = rbcfg_commands[i]; - len = snprintf(buf, sizeof(buf), cmd-usage); + len = snprintf(buf, sizeof(buf), %s, cmd-usage); buf[len] = '\0'; fprintf(stderr, %s\n, buf); } -- 1.7.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] PKG_CHECK_FORMAT_SECURITY: disable the check for the failing packages
The idea is to gradually fix the packages Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr --- package/libs/gettext-full/Makefile|1 + package/network/utils/comgt/Makefile |1 + package/network/utils/iperf/Makefile |1 + package/network/utils/linux-atm/Makefile |1 + package/network/utils/xtables-addons/Makefile |1 + package/system/fstools/Makefile |1 + package/system/mountd/Makefile|1 + package/system/ubox/Makefile |1 + package/utils/busybox/Makefile|1 + package/utils/px5g-standalone/Makefile|1 + package/utils/xfsprogs/Makefile |1 + 11 files changed, 11 insertions(+), 0 deletions(-) diff --git a/package/libs/gettext-full/Makefile b/package/libs/gettext-full/Makefile index 11dc1f5..510566b 100644 --- a/package/libs/gettext-full/Makefile +++ b/package/libs/gettext-full/Makefile @@ -23,6 +23,7 @@ PKG_FIXUP:=autoreconf PKG_INSTALL:=1 PKG_BUILD_PARALLEL:=0 PKG_BUILD_DEPENDS:=gettext-full/host +PKG_CHECK_FORMAT_SECURITY:=0 include $(INCLUDE_DIR)/package.mk include $(INCLUDE_DIR)/host-build.mk diff --git a/package/network/utils/comgt/Makefile b/package/network/utils/comgt/Makefile index 89a21be..9fbc7f9 100644 --- a/package/network/utils/comgt/Makefile +++ b/package/network/utils/comgt/Makefile @@ -18,6 +18,7 @@ PKG_MD5SUM:=db2452680c3d953631299e331daf49ef PKG_MAINTAINER:=Felix Fietkau n...@openwrt.org PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME).$(PKG_VERSION) +PKG_CHECK_FORMAT_SECURITY:=0 include $(INCLUDE_DIR)/package.mk diff --git a/package/network/utils/iperf/Makefile b/package/network/utils/iperf/Makefile index 2937460..b126c03 100644 --- a/package/network/utils/iperf/Makefile +++ b/package/network/utils/iperf/Makefile @@ -19,6 +19,7 @@ PKG_MD5SUM:=44b5536b67719f4250faed632a3cd016 PKG_MAINTAINER:=Felix Fietkau n...@openwrt.org PKG_BUILD_PARALLEL:=1 +PKG_CHECK_FORMAT_SECURITY:=0 include $(INCLUDE_DIR)/uclibc++.mk include $(INCLUDE_DIR)/package.mk diff --git a/package/network/utils/linux-atm/Makefile b/package/network/utils/linux-atm/Makefile index 9238b88..b74d3ae 100644 --- a/package/network/utils/linux-atm/Makefile +++ b/package/network/utils/linux-atm/Makefile @@ -18,6 +18,7 @@ PKG_MD5SUM:=d49499368c3cf15f73a05d9bce8824a8 PKG_INSTALL:=1 PKG_BUILD_PARALLEL:=1 +PKG_CHECK_FORMAT_SECURITY:=0 include $(INCLUDE_DIR)/package.mk diff --git a/package/network/utils/xtables-addons/Makefile b/package/network/utils/xtables-addons/Makefile index 227332c..4e18988 100644 --- a/package/network/utils/xtables-addons/Makefile +++ b/package/network/utils/xtables-addons/Makefile @@ -25,6 +25,7 @@ PKG_SOURCE_URL:=@SF/xtables-addons PKG_BUILD_DEPENDS:=iptables PKG_INSTALL:=1 PKG_BUILD_PARALLEL:=1 +PKG_CHECK_FORMAT_SECURITY:=0 PKG_MAINTAINER:=Jo-Philipp Wich j...@openwrt.org diff --git a/package/system/fstools/Makefile b/package/system/fstools/Makefile index 08b3be4..64dee6b 100644 --- a/package/system/fstools/Makefile +++ b/package/system/fstools/Makefile @@ -18,6 +18,7 @@ PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) PKG_SOURCE_VERSION:=d04e58946eff771bf59db90d7a2301b746141ac4 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz CMAKE_INSTALL:=1 +PKG_CHECK_FORMAT_SECURITY:=0 PKG_LICENSE:=GPLv2 PKG_LICENSE_FILES:= diff --git a/package/system/mountd/Makefile b/package/system/mountd/Makefile index 10534cc..a208c1e 100644 --- a/package/system/mountd/Makefile +++ b/package/system/mountd/Makefile @@ -11,6 +11,7 @@ PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 PKG_SOURCE_URL:=http://mirror2.openwrt.org/sources PKG_MD5SUM:=b77253ee4321d24d200fffc4f7ca3d15 PKG_MAINTAINER:=John Crispin blo...@openwrt.org +PKG_CHECK_FORMAT_SECURITY:=0 include $(INCLUDE_DIR)/package.mk diff --git a/package/system/ubox/Makefile b/package/system/ubox/Makefile index 9128a8d..d60b273 100644 --- a/package/system/ubox/Makefile +++ b/package/system/ubox/Makefile @@ -10,6 +10,7 @@ PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) PKG_SOURCE_VERSION:=1c2a9c1cbe9d18bf342edfa617eff319c1d3ce3a PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.gz CMAKE_INSTALL:=1 +PKG_CHECK_FORMAT_SECURITY:=0 PKG_LICENSE:=GPLv2 PKG_LICENSE_FILES:= diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 6dbd54d..6c5fa39 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -19,6 +19,7 @@ PKG_MD5SUM:=337d1a15ab1cb1d4ed423168b1eb7d7e PKG_BUILD_DEPENDS:=BUSYBOX_USE_LIBRPC:librpc PKG_BUILD_PARALLEL:=1 +PKG_CHECK_FORMAT_SECURITY:=0 PKG_LICENSE:=GPLv2 BSD-4c PKG_LICENSE_FILES:=LICENSE archival/libarchive/bz/LICENSE diff --git a/package/utils/px5g-standalone/Makefile b/package/utils/px5g-standalone/Makefile index 2577796..fc5f391 100644 --- a/package/utils/px5g-standalone/Makefile +++ b/package/utils/px5g-standalone/Makefile @@ -11,6 +11,7 @@
[OpenWrt-Devel] [PATCH 3/3] Introduce PKG_CHECK_FORMAT_SECURITY
The idea is to get rid of http://en.wikipedia.org/wiki/Uncontrolled_format_string by using -Wformat -Werror=format-security by default Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr --- include/package.mk |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/package.mk b/include/package.mk index f7da9e3..7d75f08 100644 --- a/include/package.mk +++ b/include/package.mk @@ -14,6 +14,7 @@ PKG_INSTALL_DIR ?= $(PKG_BUILD_DIR)/ipkg-install PKG_MD5SUM ?= unknown PKG_BUILD_PARALLEL ?= PKG_USE_MIPS16 ?= 1 +PKG_CHECK_FORMAT_SECURITY ?= 1 ifneq ($(CONFIG_PKG_BUILD_USE_JOBSERVER),) MAKE_J:=$(if $(MAKE_JOBSERVER),$(MAKE_JOBSERVER) -j) @@ -33,6 +34,9 @@ ifdef CONFIG_USE_MIPS16 TARGET_CFLAGS += -mips16 -minterlink-mips16 endif endif +ifeq ($(strip $(PKG_CHECK_FORMAT_SECURITY)),1) + TARGET_CFLAGS += -Wformat -Werror=format-security +endif include $(INCLUDE_DIR)/prereq.mk include $(INCLUDE_DIR)/host.mk -- 1.7.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] Update MT7530 switch driver.
Hi, thanks for the patch, i just tested it on the external switch and it works there as well (but you already knew that i guess :-) ). i added the patch to my local queue and will push later on today. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Hi, On 23/06/2014 20:22, Paul Blazejowski wrote: Hello list, Have found bug in the ubifs component when mounting images on wndr3700v4/4300 routers. This happens in trunk builds after r41130 but does not happen before r41118. Please take a look at bug https://dev.openwrt.org/ticket/16803 i have filed on this issue. Unfortunately i do not have any fixes for this but i am willing to test patches and debug in hopes of getting this fixed. looking at that log it looks like you flashed different to me :) do you perhaps use the recovery method ? i am currently using an initramfs which i boot and then i sysupgrade from there. because of this i dont see the 0xdeadc0de that you see as it is only in the ubi file -- echo -ne '\xde\xad\xc0\xde' $(KDIR_TMP)/jffs2.eof $(call ubinize,ubinize-$(9).ini,$(KDIR_TMP),$(KDIR_TMP)/$(2)-root.ubi,128KiB,2048,-E 5) however to test further i need to know how you flashed :) John On a side note, sysupgrade image for wndr4300 does work from the web interface on my 3700v4 router but the wndr3700v4 image does not. Guess one bugat a time ;-). cheerios, -paulb ___ 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] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul On Tue, 2014-06-24 at 18:48 +0200, John Crispin wrote: Hi, On 23/06/2014 20:22, Paul Blazejowski wrote: Hello list, Have found bug in the ubifs component when mounting images on wndr3700v4/4300 routers. This happens in trunk builds after r41130 but does not happen before r41118. Please take a look at bug https://dev.openwrt.org/ticket/16803 i have filed on this issue. Unfortunately i do not have any fixes for this but i am willing to test patches and debug in hopes of getting this fixed. looking at that log it looks like you flashed different to me :) do you perhaps use the recovery method ? i am currently using an initramfs which i boot and then i sysupgrade from there. because of this i dont see the 0xdeadc0de that you see as it is only in the ubi file -- echo -ne '\xde\xad\xc0\xde' $(KDIR_TMP)/jffs2.eof $(call ubinize,ubinize-$(9).ini,$(KDIR_TMP),$(KDIR_TMP)/$(2)-root.ubi,128KiB,2048,-E 5) however to test further i need to know how you flashed :) John On a side note, sysupgrade image for wndr4300 does work from the web interface on my 3700v4 router but the wndr3700v4 image does not. Guess one bugat a time ;-). cheerios, -paulb ___ 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 signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
This is much appreciated, but what is really needed for upstream merge is converting the target to device tree usage. On Tue, 2014-06-10 at 04:29 +0400, Sergey Ryazanov wrote: This series is an attempt to cleanup checkpatch generated warnings and errors to make AR231x patches suitable for upstream merge. Sergey Ryazanov (17): atheros: avoid CamelCase atheros: various comments fixes atheros: parenthesis around complex macroses value atheros: remove parentheses around return values atheros: do not assignment in if condition atheros: remove trailing whitespace atheros: do not initialize statics to 0 or false atheros: various braces fixes atheros: various printk(...) fixes atheros: fix includes atheros: indent fixes atheros: spaces fixes atheros: trailing statements fixes atheros: avoid __FUNCTION__ usage atheros: constify some static structures atheros: shorten lines atheros: fix too short msleep target/linux/atheros/patches-3.10/100-board.patch | 864 +++-- .../patches-3.10/101-early-printk-support.patch| 8 +- .../atheros/patches-3.10/105-ar2315_pci.patch | 64 +- .../atheros/patches-3.10/110-ar2313_ethernet.patch | 369 - .../linux/atheros/patches-3.10/120-spiflash.patch | 68 +- .../linux/atheros/patches-3.10/130-watchdog.patch | 85 +- .../patches-3.10/140-redboot_boardconfig.patch | 14 +- .../patches-3.10/141-redboot_partition_scan.patch | 4 +- .../142-redboot_various_erase_size_fix.patch | 12 +- .../atheros/patches-3.10/210-reset_button.patch| 4 +- .../patches-3.10/220-enet_micrel_workaround.patch | 28 +- .../atheros/patches-3.10/230-3_10-updates.patch| 10 +- 12 files changed, 781 insertions(+), 749 deletions(-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
2014-06-24 12:15 GMT-07:00 Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us: This is much appreciated, but what is really needed for upstream merge is converting the target to device tree usage. Well, that is all debatable, Device Tree only makes sense if there are: - new platforms/SoCs variants/boards being productized - there is potential driver re-usability with another platform - there is code duplication in the existing code base I think AR231x has none of those, it's an End of Life platform, the code base has been mostly static and well know for a while, so I would argue that Device Tree should not be made a requirement here as it will just delay Sergey's upstreaming effort even more. Most people working on enforcing Device Tree (especially in the ARM world) never really had to support an entire line of SoCs and try to get that upstream, or even transitioning from a non-DT kernel to a DT-aware. When Device Tree is there from day 1, it's easy to adopt and model the rest of the code against it, when it's not, and your code has been working and self-contained, this is mostly like rewriting stuff from scratch, for a benefit that is close to zero. Also, MIPS does not have any multi-platform kernels, so using Device Tree might make even less sense here for such old platforms that are submitted just so we get maintenance for free. On Tue, 2014-06-10 at 04:29 +0400, Sergey Ryazanov wrote: This series is an attempt to cleanup checkpatch generated warnings and errors to make AR231x patches suitable for upstream merge. Sergey Ryazanov (17): atheros: avoid CamelCase atheros: various comments fixes atheros: parenthesis around complex macroses value atheros: remove parentheses around return values atheros: do not assignment in if condition atheros: remove trailing whitespace atheros: do not initialize statics to 0 or false atheros: various braces fixes atheros: various printk(...) fixes atheros: fix includes atheros: indent fixes atheros: spaces fixes atheros: trailing statements fixes atheros: avoid __FUNCTION__ usage atheros: constify some static structures atheros: shorten lines atheros: fix too short msleep target/linux/atheros/patches-3.10/100-board.patch | 864 +++-- .../patches-3.10/101-early-printk-support.patch| 8 +- .../atheros/patches-3.10/105-ar2315_pci.patch | 64 +- .../atheros/patches-3.10/110-ar2313_ethernet.patch | 369 - .../linux/atheros/patches-3.10/120-spiflash.patch | 68 +- .../linux/atheros/patches-3.10/130-watchdog.patch | 85 +- .../patches-3.10/140-redboot_boardconfig.patch | 14 +- .../patches-3.10/141-redboot_partition_scan.patch | 4 +- .../142-redboot_various_erase_size_fix.patch | 12 +- .../atheros/patches-3.10/210-reset_button.patch| 4 +- .../patches-3.10/220-enet_micrel_workaround.patch | 28 +- .../atheros/patches-3.10/230-3_10-updates.patch| 10 +- 12 files changed, 781 insertions(+), 749 deletions(-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
Hi Sergey, 2014-06-09 17:29 GMT-07:00 Sergey Ryazanov ryazanov@gmail.com: This series is an attempt to cleanup checkpatch generated warnings and errors to make AR231x patches suitable for upstream merge. You might want to take a look at the recent SPI-NOR framework that MTD came up with, this might allow you to get the SPI flash driver integrated in a nicer way. AFAIR it's only available on 3.15+ though. Sergey Ryazanov (17): atheros: avoid CamelCase atheros: various comments fixes atheros: parenthesis around complex macroses value atheros: remove parentheses around return values atheros: do not assignment in if condition atheros: remove trailing whitespace atheros: do not initialize statics to 0 or false atheros: various braces fixes atheros: various printk(...) fixes atheros: fix includes atheros: indent fixes atheros: spaces fixes atheros: trailing statements fixes atheros: avoid __FUNCTION__ usage atheros: constify some static structures atheros: shorten lines atheros: fix too short msleep target/linux/atheros/patches-3.10/100-board.patch | 864 +++-- .../patches-3.10/101-early-printk-support.patch| 8 +- .../atheros/patches-3.10/105-ar2315_pci.patch | 64 +- .../atheros/patches-3.10/110-ar2313_ethernet.patch | 369 - .../linux/atheros/patches-3.10/120-spiflash.patch | 68 +- .../linux/atheros/patches-3.10/130-watchdog.patch | 85 +- .../patches-3.10/140-redboot_boardconfig.patch | 14 +- .../patches-3.10/141-redboot_partition_scan.patch | 4 +- .../142-redboot_various_erase_size_fix.patch | 12 +- .../atheros/patches-3.10/210-reset_button.patch| 4 +- .../patches-3.10/220-enet_micrel_workaround.patch | 28 +- .../atheros/patches-3.10/230-3_10-updates.patch| 10 +- 12 files changed, 781 insertions(+), 749 deletions(-) -- 1.8.1.5 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
On 06/24/2014 07:38 PM, Florian Fainelli wrote: 2014-06-24 12:15 GMT-07:00 Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us: This is much appreciated, but what is really needed for upstream merge is converting the target to device tree usage. Well, that is all debatable, Device Tree only makes sense if there are: - new platforms/SoCs variants/boards being productized - there is potential driver re-usability with another platform - there is code duplication in the existing code base I think AR231x has none of those, it's an End of Life platform, the code base has been mostly static and well know for a while, so I would argue that Device Tree should not be made a requirement here as it will just delay Sergey's upstreaming effort even more. Still, there's a couple of variants around that got made, but no-one's taken the time to convert them to either separate platforms, or device tree (I agree it shouldn't stop any other work, but there are variants of this platform out there) The dragino MS12 http://wiki.openwrt.org/toh/dragino/ms12 which is built into https://www.flukso.net/content/fluksometer-v2 and http://www.seeedstudio.com/depot/Dragrove-Generic-gateway-for-internet-of-things-p-1118.html and http://www.remakeelectric.com/solutions/#prod-reeye (at least, there's probably more) Compared to the atheros target, which I believe suits the picostation and fonera routers, this has different reset button and led configs _at least_, and I seem to recall someone else on IRC or the list some months ago that had something else different. (This is before you even start to customize what's attached to the inner connectors) It's definitely an end of life platform, no question though :) Cheers, Karl P ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
sorry i meant https://dev.openwrt.org/ticket/16803 the previous one is closed for good ;-) On Tue, 2014-06-24 at 16:25 -0400, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ 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 signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
On Tue, 2014-06-24 at 12:38 -0700, Florian Fainelli wrote: I think AR231x has none of those, it's an End of Life platform, the code base has been mostly static and well know for a while, so I would argue that Device Tree should not be made a requirement here as it will just delay Sergey's upstreaming effort even more. Very valuable input. Still, there is no way for software to determine which AR231x board it's running on, and they all have different uses of GPIO, plus the AR2317 watchdog operates completely differently from the AR2315 one. What solution do you propose? Some earlier discussion: http://patchwork.openwrt.org/patch/4351/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
On 24/06/2014 22:25, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... i tested 4300 and it works. you need to use the *-ubi-sysupgrade.tar file. Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
i get The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. from web interface. this is what i have: -rw-r--r-- 1 diffie diffie 8919040 2014-06-24 15:58 bin/ar71xx/openwrt-ar71xx-nand-wndr3700v4-squashfs-sysupgrade.tar should i push it from shell using sysupgrade script? thanks! On Tue, 2014-06-24 at 22:32 +0200, John Crispin wrote: On 24/06/2014 22:25, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... i tested 4300 and it works. you need to use the *-ubi-sysupgrade.tar file. Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
2014-06-24 13:30 GMT-07:00 Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us: On Tue, 2014-06-24 at 12:38 -0700, Florian Fainelli wrote: I think AR231x has none of those, it's an End of Life platform, the code base has been mostly static and well know for a while, so I would argue that Device Tree should not be made a requirement here as it will just delay Sergey's upstreaming effort even more. Very valuable input. Still, there is no way for software to determine which AR231x board it's running on, and they all have different uses of GPIO, plus the AR2317 watchdog operates completely differently from the AR2315 one. What solution do you propose? Some earlier discussion: http://patchwork.openwrt.org/patch/4351/ For GPIOs, since the way they are used most likely varies on a per-board basis, we could probably come up with the same mechanism as used on ath79 where we end-up patching the kernel command-line to insert a MIPS machine id for instance. For the watchdog driver, if we have access to a revision register we can read at runtime, then we could use a separate platform driver name (e.g: ar2315-wdt vs ar2317-wdt) that would lead to either two separate drivers to get registered, or have different code-paths being used in the same ar231x driver. In case we do not have that revision register, we can leverage solution 1) for GPIOs. -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
On Tue, 2014-06-24 at 13:51 -0700, Florian Fainelli wrote: For the watchdog driver, if we have access to a revision register we can read at runtime, then we could use a separate platform driver name (e.g: ar2315-wdt vs ar2317-wdt) that would lead to either two separate drivers to get registered, or have different code-paths being used in the same ar231x driver. In case we do not have that revision register, we can leverage solution 1) for GPIOs. AFAIK, at least as far as RedBoot goes, that's determined at compile time. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 3/3] Introduce PKG_CHECK_FORMAT_SECURITY
patch for package feed ready to merge https://github.com/openwrt/packages/pull/57 - Mail original - De: Etienne CHAMPETIER etienne.champet...@free.fr À: openwrt-devel@lists.openwrt.org Cc: Etienne CHAMPETIER etienne.champet...@free.fr Envoyé: Mardi 24 Juin 2014 18:12:47 Objet: [PATCH 3/3] Introduce PKG_CHECK_FORMAT_SECURITY The idea is to get rid of http://en.wikipedia.org/wiki/Uncontrolled_format_string by using -Wformat -Werror=format-security by default Signed-off-by: Etienne CHAMPETIER etienne.champet...@free.fr --- include/package.mk |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/include/package.mk b/include/package.mk index f7da9e3..7d75f08 100644 --- a/include/package.mk +++ b/include/package.mk @@ -14,6 +14,7 @@ PKG_INSTALL_DIR ?= $(PKG_BUILD_DIR)/ipkg-install PKG_MD5SUM ?= unknown PKG_BUILD_PARALLEL ?= PKG_USE_MIPS16 ?= 1 +PKG_CHECK_FORMAT_SECURITY ?= 1 ifneq ($(CONFIG_PKG_BUILD_USE_JOBSERVER),) MAKE_J:=$(if $(MAKE_JOBSERVER),$(MAKE_JOBSERVER) -j) @@ -33,6 +34,9 @@ ifdef CONFIG_USE_MIPS16 TARGET_CFLAGS += -mips16 -minterlink-mips16 endif endif +ifeq ($(strip $(PKG_CHECK_FORMAT_SECURITY)),1) + TARGET_CFLAGS += -Wformat -Werror=format-security +endif include $(INCLUDE_DIR)/prereq.mk include $(INCLUDE_DIR)/host.mk -- 1.7.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
On 24/06/2014 22:43, Paul Blazejowski wrote: i get The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. from web interface. this is what i have: -rw-r--r-- 1 diffie diffie 8919040 2014-06-24 15:58 bin/ar71xx/openwrt-ar71xx-nand-wndr3700v4-squashfs-sysupgrade.tar should i push it from shell using sysupgrade script? it will work from shell, i will look into why it fails via webui. thanks! On Tue, 2014-06-24 at 22:32 +0200, John Crispin wrote: On 24/06/2014 22:25, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... i tested 4300 and it works. you need to use the *-ubi-sysupgrade.tar file. Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
On Tue, 2014-06-24 at 23:15 +0200, John Crispin wrote: On 24/06/2014 22:43, Paul Blazejowski wrote: i get The uploaded image file does not contain a supported format. Make sure that you choose the generic image format for your platform. from web interface. this is what i have: -rw-r--r-- 1 diffie diffie 8919040 2014-06-24 15:58 bin/ar71xx/openwrt-ar71xx-nand-wndr3700v4-squashfs-sysupgrade.tar should i push it from shell using sysupgrade script? it will work from shell, i will look into why it fails via webui. guess not ;-( root@router:/tmp# sysupgrade -v -T openwrt-ar71xx-nand-wndr3700v4-squashfs-sysupgrade.tar Invalid sysupgrade file. Image check 'platform_check_image' failed. thanks! On Tue, 2014-06-24 at 22:32 +0200, John Crispin wrote: On 24/06/2014 22:25, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... i tested 4300 and it works. you need to use the *-ubi-sysupgrade.tar file. Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
2014-06-24 23:39 GMT+04:00 Florian Fainelli flor...@openwrt.org: Hi Sergey, 2014-06-09 17:29 GMT-07:00 Sergey Ryazanov ryazanov@gmail.com: This series is an attempt to cleanup checkpatch generated warnings and errors to make AR231x patches suitable for upstream merge. You might want to take a look at the recent SPI-NOR framework that MTD came up with, this might allow you to get the SPI flash driver integrated in a nicer way. AFAIR it's only available on 3.15+ though. Yep, I have seen this wonderful framework and planned to use it. -- BR Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
2014-06-24 23:38 GMT+04:00 Florian Fainelli flor...@openwrt.org: 2014-06-24 12:15 GMT-07:00 Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us: This is much appreciated, but what is really needed for upstream merge is converting the target to device tree usage. Well, that is all debatable, Device Tree only makes sense if there are: - new platforms/SoCs variants/boards being productized - there is potential driver re-usability with another platform - there is code duplication in the existing code base I think AR231x has none of those, it's an End of Life platform, the code base has been mostly static and well know for a while, so I would argue that Device Tree should not be made a requirement here. I fully agree with you. Device tree may be a nice feature, but for these particular WiSoCs it is not so critical. -- BR Sergey ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
2014-06-24 15:30 GMT-07:00 Sergey Ryazanov ryazanov@gmail.com: 2014-06-25 0:30 GMT+04:00 Daniel Gimpelevich dan...@gimpelevich.san-francisco.ca.us: plus the AR2317 watchdog operates completely differently from the AR2315 one. Hm, I am missed that. Thank you Daniel for your note. What solution do you propose? As Florian mention, as a solution we can register different platform devices: ar2315-wdt for AR2315/16 SoCs and ar2317-wdt for AR2317/18 SoCs. This should be easy since the code already contains the model detection of chip. As for the boards differences, I've thought about it and came to the same conclusion that Florian: we should build separate images for different boards each of which have own board=XXX kernel argument. I think, if the differences we have to abstract for are (hopefully) limited to GPIOs and the watchdog driver differences, we can have a small data-base in the kernel, nobdoy should hopefully yell at you for doing that. If we are talking about a few dozen regulators, SPI, i2c peripherals, that's another story, and DT could be one way to get that done in a generic way. There are another one solution: RedBoot has a builtin string with board's name, which is located just after Board: %s format string and we could find and use this string. But this solution seems ugly. Right, I would not count on that since: - there might be platforms that do not use RedBoot - people might be recompiling their own RedBoot which could place the string at a different location in the binary -- Florian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 00/17] atheros: checkpatch fixes
On Tue, 2014-06-24 at 15:33 -0700, Florian Fainelli wrote: I think, if the differences we have to abstract for are (hopefully) limited to GPIOs and the watchdog driver differences, we can have a small data-base in the kernel, nobdoy should hopefully yell at you for doing that. If we are talking about a few dozen regulators, SPI, i2c peripherals, that's another story, and DT could be one way to get that done in a generic way. If we could catalogue all known AR231x devices, we could have a reference to see whether any might use regulators, SPI, or I2C. If we find none, we'll just need to build a separate image for each device that will each have its own board ID to refer to, which can sort out the GPIO differences and tell the watchdog driver which protocol to use. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Few question about compiling your own firmware images
So I recently decided to compile my own OpenWRT images, and I have a few questions: 1. Is there a way to preset the default IP address? The default is 192.168.1.1 but I want to change it to something like 10.0.0.1, so that my compiled firmware’s IP address would be that. 2. Is there a way to pre-include files and folders? Thanks in advance, John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Geez, it must be true that you should only sleep when you're dead...damn Aussie time zones... I'll test with latest trunk as well will confirm. But looks promising! -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Paul Blazejowski Sent: Wednesday, 25 June 2014 6:27 AM To: John Crispin Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300. sorry i meant https://dev.openwrt.org/ticket/16803 the previous one is closed for good ;-) On Tue, 2014-06-24 at 16:25 -0400, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Few question about compiling your own firmware images
On 25 June 2014 01:07, Jonas Liepuonius thinker...@gmail.com wrote: 1. Is there a way to preset the default IP address? The default is 192.168.1.1 but I want to change it to something like 10.0.0.1, so that my compiled firmware's IP address would be that. Yes. 2. Is there a way to pre-include files and folders? Yes. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Few question about compiling your own firmware images
On 24/06/14 22:01, Damian Kaczkowski wrote: On 25 June 2014 01:07, Jonas Liepuonius thinker...@gmail.com mailto:thinker...@gmail.com wrote: 1. Is there a way to preset the default IP address? The default is 192.168.1.1 but I want to change it to something like 10.0.0.1, so that my compiled firmware’s IP address would be that. Yes. 2. Is there a way to pre-include files and folders? Yes. I'm still laughing out loud xD Jonas, one possible way: http://wiki.openwrt.org/doc/howto/obtain.firmware.generate#files.variable cheers! ___ 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] Few question about compiling your own firmware images
Hello, On Jun 24, 2014 4:07 PM, Jonas Liepuonius thinker...@gmail.com wrote: So I recently decided to compile my own OpenWRT images, and I have a few questions: 1. Is there a way to preset the default IP address? The default is 192.168.1.1 but I want to change it to something like 10.0.0.1, so that my compiled firmware’s IP address would be that. You should should be able to do that directly from menuconfig. 2. Is there a way to pre-include files and folders? Anything you drop in files/ from the top-level of your checkout will get included in the final image Thanks in advance, John ___ 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] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Adam, what do you know? hehehe when one sleeps another fixes things ;-) so far so good, my router has been up for few hours without problems... there's still issue with the sysupgrade image that John is already aware of ... and may have a fix for us to test ... one fix at a time they say. glad we made much progress today! thank you all! On Wed, 2014-06-25 at 00:07 +, Adam Kuklycz wrote: Geez, it must be true that you should only sleep when you're dead...damn Aussie time zones... I'll test with latest trunk as well will confirm. But looks promising! -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Paul Blazejowski Sent: Wednesday, 25 June 2014 6:27 AM To: John Crispin Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300. sorry i meant https://dev.openwrt.org/ticket/16803 the previous one is closed for good ;-) On Tue, 2014-06-24 at 16:25 -0400, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel signature.asc Description: This is a digitally signed message part ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Hi all, I've flashed my Netgear WNDR4300 with trunk r41336 and have run a series of tests. Everything looks great! I can restore backed up settings, I can configure it from scratch too should I desire. Sysupgrade works fine on my WNDR4300 via the web UI. Paul if you're still having issues with this on your WNDR3700v4 it may be specific to that model; I do not have one of these to test on unfortunately. But sysupgrade on the WNDR4300 works and works well. All settings are kept when sysupgrading too. If it helps Paul out I can email him my config file, write me directly for it; that should eliminate any mistakes that have been overlooked. Easy to do. Will run the router for a few hours on the test bench and do some traffic through it, should that play nice then it's problems resolved on my end :) Cheers Adam On 25/06/14 13:14, Paul Blazejowski wrote: Adam, what do you know? hehehe when one sleeps another fixes things ;-) so far so good, my router has been up for few hours without problems... there's still issue with the sysupgrade image that John is already aware of ... and may have a fix for us to test ... one fix at a time they say. glad we made much progress today! thank you all! On Wed, 2014-06-25 at 00:07 +, Adam Kuklycz wrote: Geez, it must be true that you should only sleep when you're dead...damn Aussie time zones... I'll test with latest trunk as well will confirm. But looks promising! -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Paul Blazejowski Sent: Wednesday, 25 June 2014 6:27 AM To: John Crispin Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300. sorry i meant https://dev.openwrt.org/ticket/16803 the previous one is closed for good ;-) On Tue, 2014-06-24 at 16:25 -0400, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300.
Hi, can someone with a 3700v4 run cat /tmp/sysinfo/* on a 3700 ? the sysupgrade fails because the board id is not added yet in the upgrade script. however i fail to figure out what id it gets from the ar71xx.sh script John On 25/06/2014 06:27, Adam Kuklycz wrote: Hi all, I've flashed my Netgear WNDR4300 with trunk r41336 and have run a series of tests. Everything looks great! I can restore backed up settings, I can configure it from scratch too should I desire. Sysupgrade works fine on my WNDR4300 via the web UI. Paul if you're still having issues with this on your WNDR3700v4 it may be specific to that model; I do not have one of these to test on unfortunately. But sysupgrade on the WNDR4300 works and works well. All settings are kept when sysupgrading too. If it helps Paul out I can email him my config file, write me directly for it; that should eliminate any mistakes that have been overlooked. Easy to do. Will run the router for a few hours on the test bench and do some traffic through it, should that play nice then it's problems resolved on my end :) Cheers Adam On 25/06/14 13:14, Paul Blazejowski wrote: Adam, what do you know? hehehe when one sleeps another fixes things ;-) so far so good, my router has been up for few hours without problems... there's still issue with the sysupgrade image that John is already aware of ... and may have a fix for us to test ... one fix at a time they say. glad we made much progress today! thank you all! On Wed, 2014-06-25 at 00:07 +, Adam Kuklycz wrote: Geez, it must be true that you should only sleep when you're dead...damn Aussie time zones... I'll test with latest trunk as well will confirm. But looks promising! -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Paul Blazejowski Sent: Wednesday, 25 June 2014 6:27 AM To: John Crispin Cc: openwrt-devel@lists.openwrt.org Subject: Re: [OpenWrt-Devel] [BUG] NAND sysupgrade broke ubifs on Netgear WNDR3700v4/4300. sorry i meant https://dev.openwrt.org/ticket/16803 the previous one is closed for good ;-) On Tue, 2014-06-24 at 16:25 -0400, Paul Blazejowski wrote: Hi again, thanks for the tftp fix, flushing just became so much faster and easier. Tested trunk r41336 after your jffs2 fix and the image boots fine, restored my configuration changes, rebooted the router and all changes are saved now. I will post the working dmesg to the ticket at https://dev.openwrt.org/ticket/16840 but it is safe to say that you can close it ;-) now. Sysupgrade image(s) for 3700v4 and 4300 do not work now, guess this is next on the list... Thank you, -paul On Tue, 2014-06-24 at 20:18 +0200, John Crispin wrote: On 24/06/2014 19:05, Paul Blazejowski wrote: John, Yes i use the reset with pin and from there i tftp the original firmware from netgear after that i go to the gui and upload the open-wrt image because the router will not accept the wndr3700v4 image (there's a cosmetic fix for that, i created a patch that someone from the forums has sent months ago to this list but it was never accepted...) https://dev.openwrt.org/ticket/16840 With that patch tftp'ing the openwrt-ar71xx-nand-wndr3700v4-ubi-factory.img works without need to flash the original firmware. If there's another method that can be used to flash the image(s) please let me know i would want to try any alternative ways of flashing and could learn a thing or two in the process as well ;-) Thank you, -paul Hi, i just pushed the V vs v fix and another fix that removes the jffs2 magic. i think this might have been the cause of the problems. please retry with current trunk and let me know if the problem is gone or still there John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ 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
