[OpenWrt-Devel] [PATCH] [lantiq] Add support for Astoria ARV7519RW.
Add support for Astoria ARV7519RW.
These patches add support for the Astoria ARV7519RW aka Livebox 2.1
The PCI and PCIe interfaces have been disabled. Also, because there are
two revisions of this board with differen GPHY firmwares, two targets
were defined.
Signed off by: Esteban Benito esteban...@gmail.com
Signed off by: Carles Gadea carles...@gmail.com
Tested by: José Vázquez Fernández ppvazquez...@gmail.com
diff --git a/target/linux/lantiq/base-files/etc/uci-defaults/02_network
b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
index 6e17d4d..a1f7b6a 100644
--- a/target/linux/lantiq/base-files/etc/uci-defaults/02_network
+++ b/target/linux/lantiq/base-files/etc/uci-defaults/02_network
@@ -114,6 +114,11 @@ TDW8970)
lan_mac=$(mtd_get_mac_binary boardconfig 61696)
wan_mac=$(macaddr_add $lan_mac 1)
;;
+
+ARV7519*)
+ lan_mac=$(mtd_get_mac_binary boardconfig 22)
+ wan_mac=$(macaddr_add $lan_mac 1)
+ ;;
esac
[ -z $(ls /lib/modules/`uname -r`/ltq_atm*) ] || set_atm_wan $vpi
$vci $encaps $payload
diff --git a/target/linux/lantiq/dts/ARV7519RW.dtsi
b/target/linux/lantiq/dts/ARV7519RW.dtsi
new file mode 100644
index 000..7790470
--- /dev/null
+++ b/target/linux/lantiq/dts/ARV7519RW.dtsi
@@ -0,0 +1,186 @@
+/include/ vr9.dtsi
+
+/ {
+
+ model = ARV7519 - Astoria Networks ARV7519RW22-A-LT;
+
+ chosen {
+ bootargs = console=ttyLTQ0,115200 init=/etc/preinit;
+ };
+
+ memory@0 {
+ reg = 0x0 0x800;
+ };
+
+ fpi@1000 {
+
+ gpio: pinmux@E100B10 {
+ pinctrl-names = default;
+ pinctrl-0 = state_default;
+
+ state_default: pinmux {
+ mdio {
+ lantiq,groups = mdio;
+ lantiq,function = mdio;
+ };
+ gphy-leds {
+ lantiq,groups = gphy0 led1, gphy1
led1;
+ lantiq,function = gphy;
+ lantiq,pull = 2;
+ lantiq,open-drain = 0;
+ lantiq,output = 1;
+ };
+ phy-rst {
+ lantiq,pins = io42;
+ lantiq,pull = 0;
+ lantiq,open-drain = 0;
+ lantiq,output = 1;
+ };
+ pcie-rst {
+ lantiq,pins = io21;
+ lantiq,pull = 0;
+ lantiq,output = 1;
+ };
+ };
+ };
+
+ eth@E108000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ compatible = lantiq,xrx200-net;
+ reg = 0xE108000 0x3000 /* switch */
+ 0xE10B100 0x70 /* mdio */
+ 0xE10B1D8 0x30 /* mii */
+ 0xE10B308 0x30 /* pmac */
+ ;
+ interrupt-parent = icu0;
+ interrupts = 73 72;
+
+ lan: interface@0 {
+ compatible = lantiq,xrx200-pdi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 0;
+ mac-address = [ 00 11 22 33 44 55 ];
+
+ ethernet@2 {
+ compatible = lantiq,xrx200-pdi-port;
+ reg = 2;
+ phy-mode = gmii;
+ phy-handle = phy11;
+ };
+ ethernet@3 {
+ compatible = lantiq,xrx200-pdi-port;
+ reg = 4;
+ phy-mode = gmii;
+ phy-handle = phy13;
+ };
+ };
+
+ wan: interface@1 {
+ compatible = lantiq,xrx200-pdi;
+ #address-cells = 1;
+ #size-cells = 0;
+ reg = 1;
+ mac-address = [ 00 11 22 33 44 56 ];
+ lantiq,wan;
+ ethernet@4 {
+
Re: [OpenWrt-Devel] AP-mode drivers for BCM4360
On Fri, Mar 7, 2014 at 11:34 AM, Rafał Miłecki zaj...@gmail.com wrote: If you don't have any access to specs, it may be hard. Do you have any plan how to develop a driver? Some kind of RE? I don’t have any specs and I don’t have prior driver developing experience :( The only thing I have are the WiFi card and willingness to learn ;-) But if it’s too hard without specs I could also return the card.. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] luaposix: Update source links and urls
From: Karl Palsson ka...@remake.is No functional change. The difference in the md5sum of the tarball is the inclusion of a .gitignore file in the github provided tarball. This change allows https://home.comcast.net/~sdwalker/uscan/index.html to more accurately track the state of this package, and includes links that actually work. It eliminates the need for this package to be hosted on mirror2.openwrt.org, and indeed, due to the md5sum change, won't even be compatible with the package hosted there. Signed-off-by: Karl Palsson ka...@remake.is --- lang/luaposix/Makefile | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/lang/luaposix/Makefile b/lang/luaposix/Makefile index 46cb211..86952a4 100644 --- a/lang/luaposix/Makefile +++ b/lang/luaposix/Makefile @@ -9,12 +9,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=luaposix PKG_VERSION:=5.1.11 -PKG_RELEASE:=1 +PKG_RELEASE:=2 -PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz -PKG_SOURCE_URL:=http://luaforge.net/frs/download.php/4813 -PKG_MD5SUM:=edb76911dbdabe98dec49e3d8a126227 -PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME) +PKG_SOURCE:=v$(PKG_VERSION).tar.gz +PKG_SOURCE_URL:=https://github.com/luaposix/luaposix/archive/ +PKG_MD5SUM:=8254576c52bd2d0e160353d24880bb89 +PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION) include $(INCLUDE_DIR)/package.mk @@ -23,7 +23,7 @@ define Package/luaposix SECTION:=lang CATEGORY:=Languages TITLE:=luaposix - URL:=http://luaposix.luaforge.net/ + URL:=http://luaforge.net/projects/luaposix/ DEPENDS:=+lua +librt endef -- 1.8.3.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] netifd: Assign interface metric to route metric when route is created
Interface metric needs to be assigned to the route metric parameter at route
creation time. Otherwise if the interface metric is different from 0 route_cmp
will wrongly conclude the routes are different.
In this case the route will be added/deleted and could end up with the route
missing in the kernel depending on the add/delete order.
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
interface-ip.c |6 ++
1 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/interface-ip.c b/interface-ip.c
index b1abbc6..d5a3832 100644
--- a/interface-ip.c
+++ b/interface-ip.c
@@ -322,7 +322,8 @@ interface_ip_add_route(struct interface *iface, struct
blob_attr *attr, bool v6)
if ((cur = tb[ROUTE_METRIC]) != NULL) {
route-metric = blobmsg_get_u32(cur);
route-flags |= DEVROUTE_METRIC;
- }
+ } else
+ route-metric = iface-metric;
if ((cur = tb[ROUTE_MTU]) != NULL) {
route-mtu = blobmsg_get_u32(cur);
@@ -588,9 +589,6 @@ interface_update_proto_route(struct vlist_tree *tree,
if (node_new) {
bool _enabled = enable_route(ip, route_new);
- if (!(route_new-flags DEVROUTE_METRIC))
- route_new-metric = iface-metric;
-
if (!(route_new-flags DEVADDR_EXTERNAL) !keep _enabled)
if (system_add_route(dev, route_new))
route_new-failed = true;
--
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 1/3] netifd: Fix bridge MTU setting when a bridge member is added
Reapply bridge mtu setting as adding a bridge member will override the bridge
mtu in the kernel
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
bridge.c | 13 +++--
device.c |2 +-
interface.c|2 +-
system-dummy.c |2 +-
system-linux.c | 15 +--
system.h |4 ++--
6 files changed, 25 insertions(+), 13 deletions(-)
diff --git a/bridge.c b/bridge.c
index 7bd1cf0..778fead 100644
--- a/bridge.c
+++ b/bridge.c
@@ -233,8 +233,17 @@ bridge_member_cb(struct device_user *dev, enum
device_event ev)
if (bst-n_present == 1)
device_set_present(bst-dev, true);
- if (bst-dev.active)
- bridge_enable_member(bm);
+ if (bst-dev.active) {
+ if (!bridge_enable_member(bm)) {
+ /*
+* Adding a bridge member can overwrite the
bridge mtu
+* in the kernel, apply the bridge settings in
case the
+* bridge mtu is set
+*/
+ system_if_apply_settings(bst-dev,
bst-dev.settings,
+ DEV_OPT_MTU);
+ }
+ }
break;
case DEV_EVENT_REMOVE:
diff --git a/device.c b/device.c
index 6a770ac..2fb68d7 100644
--- a/device.c
+++ b/device.c
@@ -623,7 +623,7 @@ device_create(const char *name, const struct device_type
*type,
odev-current_config = true;
change = device_set_config(odev, type, config);
if (odev-external) {
- system_if_apply_settings(odev, odev-settings);
+ system_if_apply_settings(odev, odev-settings,
odev-settings.flags);
change = DEV_CONFIG_APPLIED;
}
switch (change) {
diff --git a/interface.c b/interface.c
index f0fd43f..43ba773 100644
--- a/interface.c
+++ b/interface.c
@@ -839,7 +839,7 @@ interface_handle_link(struct interface *iface, const char
*name, bool add)
if (iface-device_config)
device_set_config(dev, simple_device_type,
iface-config);
- system_if_apply_settings(dev, dev-settings);
+ system_if_apply_settings(dev, dev-settings,
dev-settings.flags);
ret = interface_add_link(iface, dev);
} else {
ret = interface_remove_link(iface, dev);
diff --git a/system-dummy.c b/system-dummy.c
index c8379ff..3ab22b0 100644
--- a/system-dummy.c
+++ b/system-dummy.c
@@ -120,7 +120,7 @@ system_if_dump_stats(struct device *dev, struct blob_buf *b)
}
void
-system_if_apply_settings(struct device *dev, struct device_settings *s)
+system_if_apply_settings(struct device *dev, struct device_settings *s,
unsigned int apply_mask)
{
}
diff --git a/system-linux.c b/system-linux.c
index 12682dc..7cec649 100644
--- a/system-linux.c
+++ b/system-linux.c
@@ -798,23 +798,26 @@ system_if_get_settings(struct device *dev, struct
device_settings *s)
}
void
-system_if_apply_settings(struct device *dev, struct device_settings *s)
+system_if_apply_settings(struct device *dev, struct device_settings *s,
unsigned int apply_mask)
{
struct ifreq ifr;
+ if (!apply_mask)
+ return;
+
memset(ifr, 0, sizeof(ifr));
strncpy(ifr.ifr_name, dev-ifname, sizeof(ifr.ifr_name));
- if (s-flags DEV_OPT_MTU) {
+ if (s-flags DEV_OPT_MTU apply_mask) {
ifr.ifr_mtu = s-mtu;
if (ioctl(sock_ioctl, SIOCSIFMTU, ifr) 0)
s-flags = ~DEV_OPT_MTU;
}
- if (s-flags DEV_OPT_TXQUEUELEN) {
+ if (s-flags DEV_OPT_TXQUEUELEN apply_mask) {
ifr.ifr_qlen = s-txqueuelen;
if (ioctl(sock_ioctl, SIOCSIFTXQLEN, ifr) 0)
s-flags = ~DEV_OPT_TXQUEUELEN;
}
- if ((s-flags DEV_OPT_MACADDR) !dev-external) {
+ if ((s-flags DEV_OPT_MACADDR apply_mask) !dev-external) {
ifr.ifr_hwaddr.sa_family = ARPHRD_ETHER;
memcpy(ifr.ifr_hwaddr.sa_data, s-macaddr, sizeof(s-macaddr));
if (ioctl(sock_ioctl, SIOCSIFHWADDR, ifr) 0)
@@ -825,7 +828,7 @@ system_if_apply_settings(struct device *dev, struct
device_settings *s)
int system_if_up(struct device *dev)
{
system_if_get_settings(dev, dev-orig_settings);
- system_if_apply_settings(dev, dev-settings);
+ system_if_apply_settings(dev, dev-settings, dev-settings.flags);
device_set_ifindex(dev, system_if_resolve(dev));
return system_if_flags(dev-ifname, IFF_UP, 0);
}
@@ -834,7 +837,7 @@ int system_if_down(struct device *dev)
{
int ret = system_if_flags(dev-ifname, 0, IFF_UP);
dev-orig_settings.flags =
[OpenWrt-Devel] [PATCH 3/3] netifd: Set interface state in teardown state before launching an interface event
Interface state needs to be set in teardown state before launching an interface
event otherwise the up state will be reported as true in the ubus interface
notify message
Signed-off-by: Hans Dedecker dedec...@gmail.com
---
interface.c |7 +--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/interface.c b/interface.c
index 43ba773..39460e4 100644
--- a/interface.c
+++ b/interface.c
@@ -222,11 +222,14 @@ mark_interface_down(struct interface *iface)
void
__interface_set_down(struct interface *iface, bool force)
{
- switch (iface-state) {
+ enum interface_state state = iface-state;
+ switch (state) {
case IFS_UP:
- interface_event(iface, IFEV_DOWN);
case IFS_SETUP:
iface-state = IFS_TEARDOWN;
+ if (state == IFS_UP)
+ interface_event(iface, IFEV_DOWN);
+
interface_proto_event(iface-proto, PROTO_CMD_TEARDOWN, force);
if (force)
interface_flush_state(iface);
--
1.7.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] arecord intermittent behavior
Ok, I didn't imagine better title for this curious bug, don't think this is an arecord problem, it might be a deeper problem in Openwrt. Scenario: USB sound card installed in a MIPS BE router (bcm63xx), using OHCI module, alsa-utils installed. Let's make some recordings with arecord. arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test01.wav -- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test02.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test03.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test04.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test05.wav -- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test06.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test07.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test08.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test09.wav -- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test10.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test11.wav -- bad .. As you can see, there is a pattern, after exactly 4 recordings it seems the audio card, or maybe unknown stuff at the system returns to a sane state where arecord can make a good job. I tested it dozen times, always with the same pattern: 1 good recording, 3 bad I suspected it might be an endianess problem, and decided to do the same in a LE device, this time bcm47xx, an asus wl500g-premium v1, using UHCI module for the usb audiostick. arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test01.wav -- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test02.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test03.wav -- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test04.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test05.wav -- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test06.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test07.wav -- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test08.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test09.wav -- good arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test10.wav -- bad arecord -q -d 1 -r44100 -f S16_LE -c1 -t wav test11.wav -- good The problem persists, but this time the pattern changed to 1 good, 1 bad recording In both cases I used the same last trunk revisions. But I noticed this problem is present long time ago in OpenWrt. It didn't happen in my x86 PC, and never found people complaining about this problem in x86 PCs where arecord is commonly used. Ok, I don't pretend to use arecord for anything. The problem is other apps are affected by this bug. I use LIRC (audio_alsa) connected to the microphone input to send IR commands with a remote, and sometimes works others don't. This was reported elsewhere by other people. So arecord is revealing a problem in OpenWrt. If you want to see how does look a bad or good recording, link: https://drive.google.com/folderview?id=0B-EMoBe-_OdBOXdPdTBaQTVOc00usp=sharing They are button press with an IR remote. So, I have a simple question: What's going on? ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Openwrt future release strategy? kernel strategy?
On Fri, Mar 07, 2014 at 06:37:43PM +0100, Felix Fietkau wrote: On 2014-03-07 16:40, Hannu Nyman wrote: So far I have not seen any response from the devs, which is a bit disappointing :-( In any case, I thought to add that apparently 3.12 has been named a long-term kernel last week: https://lkml.org/lkml/2014/2/26/596 https://www.kernel.org/category/releases.html But I guess that Openwrt has already gone past the possibility of using 3.12, as some platforms are already at 3.13 and 3.14 got first checkins today. We're still working on our build infrastructure for the release. As for the kernel version: The important targets that should get a binary release are still at 3.10. That sounds good! I think some targets have been upgraded because they depend on new kernel infrastructure where a backport is not feasible, and such targets do not need to be maintained for the release in the same way as the others. At this point it does not make sense to destabilize the main targets by updating them to 3.12, because the amount of time necessary to stabilize them would further delay a release. Makes sense. Thanks a lot for the reply and the info! -- Pasi - Felix ___ 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] Unloadable modules generated for powerpc
Hello, We use our own kernel source (official linux 3.8.13 plus a drivers) and build openwrt for x86 and powerpc 85xx. Now the modules generated for powerpc don't load. When trying to insmod, then the kernel message (e.g.) xt_LOG: no symbol version for module_layout is issued on the console. I tracked that down to the generation of the *.mod.c files: When I am at the top level of the kernel which was just fully built (make vmlinux), and do the following: rm vmlinux System.map make modules the *.mod.c files that are generated are invalid: their static const struct modversion_info versions[] is empty. However rm vmlinux System.map make generates valid *.mod.c files, and the modules *do* load later. The removal of vmlinux and System.map comes from openwrt commit d6ce92de580 of Wed Apr 25 22:26:40 2007, where the commit message says: add workaround for occasional kernel module build failures related to kernel config changes Can anyone shed some light on this? Why is that apparently no problem with x86? Do we need special openwrt kernel patches so that make modules produces correct modules even in the absence of vmlinux? -- Nils Rennebarth Software developer bintec elmeg security GmbH Mönchhaldenstraße 28 D-70191 Stuttgart Germany Tel: +49-711-900600-64 Email: nils.renneba...@bintec-elmeg.com www: www.bintec-elmeg.com Location: Nuremberg, Local Court Nuremberg, HRB 25481br Managing Director: Bernd Büttner The information contained in this e-mail has been carefully researched, but the possibility of it being inapplicable in individual cases cannot be ruled out. We therefore regret that we cannot accept responsibility or liability of any kind whatsoever for the correctness of the information given. Please notify us if you discover that information is inapplicable. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
