Re: [PATCH] netifd: add support for dhcp fallback to static ip
On 2024-07-14 22:39, Roman Yeryomin wrote: It is pretty common use case for a network device to be configured as DHCP client but having some fallback static IP address where it would be reachable for, e.g., configuration. This adds 'fallbackip' network config option, which will be used on an interface until device receives an IP from DHCP server. Hi Felix, I hope I got your points on this implementation in the right way. Would be nice to hear what is your word on this! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] netifd: add support for dhcp fallback to static ip
It is pretty common use case for a network device to be configured
as DHCP client but having some fallback static IP address where it
would be reachable for, e.g., configuration.
This adds 'fallbackip' network config option, which will be used
on an interface until device receives an IP from DHCP server.
Signed-off-by: Roman Yeryomin
---
.../network/config/netifd/files/lib/netifd/dhcp.script| 8 +++-
.../network/config/netifd/files/lib/netifd/proto/dhcp.sh | 7 +--
2 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/package/network/config/netifd/files/lib/netifd/dhcp.script
b/package/network/config/netifd/files/lib/netifd/dhcp.script
index db8deac9e6..da7c30f72c 100755
--- a/package/network/config/netifd/files/lib/netifd/dhcp.script
+++ b/package/network/config/netifd/files/lib/netifd/dhcp.script
@@ -98,7 +98,13 @@ setup_interface () {
}
deconfig_interface() {
- proto_init_update "*" 0
+ if [ -z "$FALLBACKIP" ]; then
+ proto_init_update "*" 0
+ else
+ proto_init_update "*" 1
+ proto_add_ipv4_address "$FALLBACKIP" "255.255.255.0"
+ fi
+
proto_send_update "$INTERFACE"
}
diff --git a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
index 636b4654ff..020038f0f8 100755
--- a/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
+++ b/package/network/config/netifd/files/lib/netifd/proto/dhcp.sh
@@ -10,6 +10,7 @@ proto_dhcp_init_config() {
renew_handler=1
proto_config_add_string 'ipaddr:ipaddr'
+ proto_config_add_string 'fallbackip:fallbackip'
proto_config_add_string 'hostname:hostname'
proto_config_add_string clientid
proto_config_add_string vendorid
@@ -35,8 +36,8 @@ proto_dhcp_setup() {
local config="$1"
local iface="$2"
- local ipaddr hostname clientid vendorid broadcast norelease reqopts
defaultreqopts iface6rd sendopts delegate zone6rd zone mtu6rd customroutes
classlessroute
- json_get_vars ipaddr hostname clientid vendorid broadcast norelease
reqopts defaultreqopts iface6rd delegate zone6rd zone mtu6rd customroutes
classlessroute
+ local ipaddr fallbackip hostname clientid vendorid broadcast norelease
reqopts defaultreqopts iface6rd sendopts delegate zone6rd zone mtu6rd
customroutes classlessroute
+ json_get_vars ipaddr fallbackip hostname clientid vendorid broadcast
norelease reqopts defaultreqopts iface6rd delegate zone6rd zone mtu6rd
customroutes classlessroute
local opt dhcpopts
for opt in $reqopts; do
@@ -63,6 +64,8 @@ proto_dhcp_setup() {
[ "$classlessroute" = "0" ] || append dhcpopts "-O 121"
proto_export "INTERFACE=$config"
+ proto_export "FALLBACKIP=$fallbackip"
+
proto_run_command "$config" udhcpc \
-p /var/run/udhcpc-$iface.pid \
-s /lib/netifd/dhcp.script \
--
2.43.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] netifd: add support for dhcp fallback to static ip
On 2024-07-14 14:11, Felix Fietkau wrote: On 14.07.24 11:47, Roman Yeryomin wrote: On 2024-07-14 10:42, Felix Fietkau wrote: On 14.07.24 02:34, Roman Yeryomin wrote: It is pretty common use case for a network device to be configured as DHCP client but having some fallback static IP address where it would be reachable for, e.g., configuration. This reacts on udhcpc events and sets/removes ipaddr which is configured on an iface from network config. This means that for an interface with proto set to dhcp but with fallback static IP disabled (ipaddr parameter is not set in config) cost of this feature is one uci call. If static fallback is enabled (ipaddr is present) then the cost is 3 uci calls and one ip call for each deconfig/renew/bound udhcpc event. It is not nothing but to me it seem like it's a very small overhead for such a convenience and I think it should be OpenWrt default at least for targets with one ethernet port. Signed-off-by: Roman Yeryomin --- diff --git a/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh new file mode 100644 index 00..79984e9a2f --- /dev/null +++ b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh @@ -0,0 +1,23 @@ +#!/bin/sh + +[ -z "$1" ] && echo "Error: should be run by udhcpc" && exit 1 + +ipaddr=$(uci get network.$INTERFACE.ipaddr) +[ -z "$ipaddr" ] && exit 0 + +ifname=$(uci get network.$INTERFACE.ifname) +[ -z "$ifname" ] && exit 0 + +netmask=$(uci get network.$INTERFACE.netmask) +[ -z "$netmask" ] && netmask=24 + +case "$1" in + deconfig) + ip ad add $ipaddr/$netmask dev $ifname + ;; + renew|bound) + ip ad del $ipaddr dev $ifname + ;; +esac + +exit 0 Here's my take on this patch: 1. The feature should be opt-in via an extra config option, since it changes the behavior in a meaningful way that might be problematic for some users. 2. IP addresses should be set from within netifd, e.g. via the same mechanism that the dhcp script uses to bring up the interface. 3. IP settings should not be read directly from uci, but passed down from the netifd proto handler, e.g. via env vars. Agree on 2. and 3. Can't say I agree on 1. -- could you please give an example in which situation it could be problematic? If you use the ipaddr to request a specific address from the DHCP server, but don't want the link to be up when the server is not reachable. Ah, got it, let me send updated version then with 'fallbackip' option. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC] netifd: add support for dhcp fallback to static ip
On 2024-07-14 10:42, Felix Fietkau wrote: On 14.07.24 02:34, Roman Yeryomin wrote: It is pretty common use case for a network device to be configured as DHCP client but having some fallback static IP address where it would be reachable for, e.g., configuration. This reacts on udhcpc events and sets/removes ipaddr which is configured on an iface from network config. This means that for an interface with proto set to dhcp but with fallback static IP disabled (ipaddr parameter is not set in config) cost of this feature is one uci call. If static fallback is enabled (ipaddr is present) then the cost is 3 uci calls and one ip call for each deconfig/renew/bound udhcpc event. It is not nothing but to me it seem like it's a very small overhead for such a convenience and I think it should be OpenWrt default at least for targets with one ethernet port. Signed-off-by: Roman Yeryomin --- diff --git a/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh new file mode 100644 index 00..79984e9a2f --- /dev/null +++ b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh @@ -0,0 +1,23 @@ +#!/bin/sh + +[ -z "$1" ] && echo "Error: should be run by udhcpc" && exit 1 + +ipaddr=$(uci get network.$INTERFACE.ipaddr) +[ -z "$ipaddr" ] && exit 0 + +ifname=$(uci get network.$INTERFACE.ifname) +[ -z "$ifname" ] && exit 0 + +netmask=$(uci get network.$INTERFACE.netmask) +[ -z "$netmask" ] && netmask=24 + +case "$1" in + deconfig) + ip ad add $ipaddr/$netmask dev $ifname + ;; + renew|bound) + ip ad del $ipaddr dev $ifname + ;; +esac + +exit 0 Here's my take on this patch: 1. The feature should be opt-in via an extra config option, since it changes the behavior in a meaningful way that might be problematic for some users. 2. IP addresses should be set from within netifd, e.g. via the same mechanism that the dhcp script uses to bring up the interface. 3. IP settings should not be read directly from uci, but passed down from the netifd proto handler, e.g. via env vars. Agree on 2. and 3. Can't say I agree on 1. -- could you please give an example in which situation it could be problematic? Thanks for feedback! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC] netifd: add support for dhcp fallback to static ip
It is pretty common use case for a network device to be configured as DHCP client but having some fallback static IP address where it would be reachable for, e.g., configuration. This reacts on udhcpc events and sets/removes ipaddr which is configured on an iface from network config. This means that for an interface with proto set to dhcp but with fallback static IP disabled (ipaddr parameter is not set in config) cost of this feature is one uci call. If static fallback is enabled (ipaddr is present) then the cost is 3 uci calls and one ip call for each deconfig/renew/bound udhcpc event. It is not nothing but to me it seem like it's a very small overhead for such a convenience and I think it should be OpenWrt default at least for targets with one ethernet port. Signed-off-by: Roman Yeryomin --- package/network/config/netifd/Makefile| 1 - .../files/etc/udhcpc.user.d/fallbackip.sh | 23 +++ 2 files changed, 23 insertions(+), 1 deletion(-) create mode 100644 package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh diff --git a/package/network/config/netifd/Makefile b/package/network/config/netifd/Makefile index d80c2eeed6..8ef391d913 100644 --- a/package/network/config/netifd/Makefile +++ b/package/network/config/netifd/Makefile @@ -42,7 +42,6 @@ define Package/netifd/install $(INSTALL_DIR) $(1)/sbin $(INSTALL_BIN) $(PKG_BUILD_DIR)/netifd $(1)/sbin/ $(CP) ./files/* $(1)/ - $(INSTALL_DIR) $(1)/etc/udhcpc.user.d/ $(CP) \ $(PKG_BUILD_DIR)/scripts/utils.sh \ $(PKG_BUILD_DIR)/scripts/netifd-proto.sh \ diff --git a/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh new file mode 100644 index 00..79984e9a2f --- /dev/null +++ b/package/network/config/netifd/files/etc/udhcpc.user.d/fallbackip.sh @@ -0,0 +1,23 @@ +#!/bin/sh + +[ -z "$1" ] && echo "Error: should be run by udhcpc" && exit 1 + +ipaddr=$(uci get network.$INTERFACE.ipaddr) +[ -z "$ipaddr" ] && exit 0 + +ifname=$(uci get network.$INTERFACE.ifname) +[ -z "$ifname" ] && exit 0 + +netmask=$(uci get network.$INTERFACE.netmask) +[ -z "$netmask" ] && netmask=24 + +case "$1" in + deconfig) + ip ad add $ipaddr/$netmask dev $ifname + ;; + renew|bound) + ip ad del $ipaddr dev $ifname + ;; +esac + +exit 0 -- 2.43.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] iproute2: m_xt.so depends on dynsyms.list
When doing parallel build on a fast machine with bottleneck in i/o,
m_xt.so may start linking faster than dynsyms.list gets populated,
resulting in error:
ld:dynsyms.list:0: syntax error in dynamic list
Fix this by adding dynsyms.list as make dependency to m_xt.so
Described also here:
https://bugs.openwrt.org/index.php?do=details&task_id=3353
Change from v1:
- add dynsysms.list dependancy only when shared libs are enabled
Signed-off-by: Roman Yeryomin
Fixes: FS#3353
---
.../utils/iproute2/patches/175-reduce-dynamic-syms.patch | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git
a/package/network/utils/iproute2/patches/175-reduce-dynamic-syms.patch
b/package/network/utils/iproute2/patches/175-reduce-dynamic-syms.patch
index da961a183b..c3892e5a0e 100644
--- a/package/network/utils/iproute2/patches/175-reduce-dynamic-syms.patch
+++ b/package/network/utils/iproute2/patches/175-reduce-dynamic-syms.patch
@@ -26,13 +26,14 @@
q_atm.so: q_atm.c
$(QUIET_CC)$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -shared -fpic -o
q_atm.so q_atm.c -latm
-@@ -205,4 +206,15 @@ static-syms.h: $(wildcard *.c)
+@@ -205,4 +206,16 @@ static-syms.h: $(wildcard *.c)
sed -n '/'$$s'[^ ]* =/{s:.* \([^ ]*'$$s'[^ ]*\) .*:extern char
\1[] __attribute__((weak)); if (!strcmp(sym, "\1")) return \1;:;p}' $$files ; \
done > $@
+else
+
+tc: dynsyms.list
++m_xt.so: dynsyms.list
+dynsyms.list: $(wildcard *.c)
+ files="$(filter-out $(patsubst %.so,%.c,$(TCSO)), $^)" ; \
+ echo "{" > $@ ; \
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] iproute2: m_xt.so depends on dynsyms.list
On 2021-09-03 02:28, Roman Yeryomin wrote: When doing parallel build on a fast machine with bottleneck in i/o, m_xt.so may start linking faster than dynsyms.list gets populated, resulting in error: ld:dynsyms.list:0: syntax error in dynamic list Fix this by adding dynsyms.list as make dependency to m_xt.so Described also here: https://bugs.openwrt.org/index.php?do=details&task_id=3353 Signed-off-by: Roman Yeryomin Fixes: FS#3353 --- Please discard this. Making m_xt.so dependant on dynsyms.list unconditionally was bad idea. Will re-send proper version. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] iproute2: m_xt.so depends on dynsyms.list
When doing parallel build on a fast machine with bottleneck in i/o,
m_xt.so may start linking faster than dynsyms.list gets populated,
resulting in error:
ld:dynsyms.list:0: syntax error in dynamic list
Fix this by adding dynsyms.list as make dependency to m_xt.so
Described also here:
https://bugs.openwrt.org/index.php?do=details&task_id=3353
Signed-off-by: Roman Yeryomin
Fixes: FS#3353
---
.../utils/iproute2/patches/175-reduce-dynamic-syms.patch| 6 ++
1 file changed, 6 insertions(+)
diff --git
a/package/network/utils/iproute2/patches/175-reduce-dynamic-syms.patch
b/package/network/utils/iproute2/patches/175-reduce-dynamic-syms.patch
index da961a183b..aa98c97549 100644
--- a/package/network/utils/iproute2/patches/175-reduce-dynamic-syms.patch
+++ b/package/network/utils/iproute2/patches/175-reduce-dynamic-syms.patch
@@ -26,6 +26,12 @@
q_atm.so: q_atm.c
$(QUIET_CC)$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -shared -fpic -o
q_atm.so q_atm.c -latm
+
+-m_xt.so: m_xt.c
++m_xt.so: m_xt.c dynsyms.list
+ $(QUIET_CC)$(CC) $(CFLAGS) $(CPPFLAGS) $(LDFLAGS) -shared -fpic -o
m_xt.so m_xt.c $$($(PKG_CONFIG) xtables --cflags --libs)
+
+ m_xt_old.so: m_xt_old.c
@@ -205,4 +206,15 @@ static-syms.h: $(wildcard *.c)
sed -n '/'$$s'[^ ]* =/{s:.* \([^ ]*'$$s'[^ ]*\) .*:extern char
\1[] __attribute__((weak)); if (!strcmp(sym, "\1")) return \1;:;p}' $$files ; \
done > $@
--
2.25.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build: improve ccache support
On 2020-06-04 22:29, Michael Jones wrote: I agree with Felix. Having one ccache directory for multiple repos doesn't make much sense to me as most probably they are for different platforms. And even if they are for same platform there are more chances for ccache corruption and deleting it will affect all those repos. So it still can be done with symlink but IMO should be done manually to make sure you know what you are doing. Also BASEDIR should be changed too, probably, if we want to go that way. I am already using a shared ccache directory for multiple builds in my continuous integration system. I'm accomplishing this by patching the build system to change the directory for the ccache directory. If it were a .config option, your use-case would be directly supported, as well as my use-case, without as much custom patching. I imagine that there are plenty of other organizations which would use the .config based functionality to customize things to their liking. If ccache is corrupted there are much larger problems than slowing down other builds. Please see v2 Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] build: improve ccache support
Set CCACHE_DIR to $(TOPDIR)/.ccache and CCACHE_BASEDIR to $(TOPDIR). This allows to do clean and dirclean. Cache hit rate for test build after dirclean is ~65%. If CCACHE is enabled stats are printed out at the end of building process. CCACHE_DIR config variable allows to override default, which could be useful when sharing cache with many builds. cacheclean make target allows to clean the cache. Changes from v1: - remove ccache directory using CCACHE_DIR variable - remove ccache leftovers from sdk and toolchain make files - introduce CONFIG_CCACHE_DIR variable - introduce cacheclean make target Signed-off-by: Roman Yeryomin --- .gitignore| 1 + Makefile | 8 config/Config-devel.in| 7 +++ include/host-build.mk | 4 +++- include/package.mk| 4 +++- include/toplevel.mk | 2 +- rules.mk | 3 +++ target/sdk/Makefile | 8 ++-- target/toolchain/Makefile | 2 +- 9 files changed, 29 insertions(+), 10 deletions(-) diff --git a/.gitignore b/.gitignore index 6549af83be..b6bfe1a525 100644 --- a/.gitignore +++ b/.gitignore @@ -28,3 +28,4 @@ TAGS*~ git-src .project .cproject +.ccache diff --git a/Makefile b/Makefile index 32c050bb48..24f5955c90 100644 --- a/Makefile +++ b/Makefile @@ -62,6 +62,11 @@ dirclean: clean rm -rf $(TMP_DIR) $(MAKE) -C $(TOPDIR)/scripts/config clean +cacheclean: +ifneq ($(CONFIG_CCACHE),) + rm -rf $(if $(call qstrip,$(CONFIG_CCACHE_DIR)),$(call qstrip,$(CONFIG_CCACHE_DIR)),$(TOPDIR)/.ccache) +endif + ifndef DUMP_TARGET_DB $(BUILD_DIR)/.prepared: Makefile @mkdir -p $$(dirname $@) @@ -119,6 +124,9 @@ world: prepare $(target/stamp-compile) $(package/stamp-compile) $(package/stamp- $(_SINGLE)$(SUBMAKE) -r package/index $(_SINGLE)$(SUBMAKE) -r json_overview_image_info $(_SINGLE)$(SUBMAKE) -r checksum +ifneq ($(CONFIG_CCACHE),) + $(STAGING_DIR_HOST)/bin/ccache -s +endif .PHONY: clean dirclean prereq prepare world package/symlinks package/symlinks-install package/symlinks-clean diff --git a/config/Config-devel.in b/config/Config-devel.in index 70ec0ce9a7..11741c7070 100644 --- a/config/Config-devel.in +++ b/config/Config-devel.in @@ -69,6 +69,13 @@ menuconfig DEVEL help Compiler cache; see https://ccache.samba.org/ + config CCACHE_DIR + string "Set ccache directory" if CCACHE + default "" + help + Store ccache in this directory. + If not set, uses './.ccache' + config EXTERNAL_KERNEL_TREE string "Use external kernel tree" if DEVEL default "" diff --git a/include/host-build.mk b/include/host-build.mk index 9fc14241c6..7d84ab0f5f 100644 --- a/include/host-build.mk +++ b/include/host-build.mk @@ -132,7 +132,9 @@ define Host/Exports/Default $(1) : export STAGING_PREFIX=$$(HOST_BUILD_PREFIX) $(1) : export PKG_CONFIG_PATH=$$(STAGING_DIR_HOST)/lib/pkgconfig:$$(HOST_BUILD_PREFIX)/lib/pkgconfig $(1) : export PKG_CONFIG_LIBDIR=$$(HOST_BUILD_PREFIX)/lib/pkgconfig - $(if $(CONFIG_CCACHE),$(1) : export CCACHE_DIR:=$(STAGING_DIR_HOST)/ccache) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_BASEDIR:=$(TOPDIR)) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_DIR:=$(if $(call qstrip,$(CONFIG_CCACHE_DIR)),$(call qstrip,$(CONFIG_CCACHE_DIR)),$(TOPDIR)/.ccache)) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_COMPILERCHECK:=%compiler% -dumpmachine; %compiler% -dumpversion) $(if $(HOST_CONFIG_SITE),$(1) : export CONFIG_SITE:=$(HOST_CONFIG_SITE)) $(if $(IS_PACKAGE_BUILD),$(1) : export PATH=$$(TARGET_PATH_PKG)) endef diff --git a/include/package.mk b/include/package.mk index 0575692742..a93d6b78f3 100644 --- a/include/package.mk +++ b/include/package.mk @@ -173,7 +173,9 @@ define Build/Exports/Default $(1) : export CONFIG_SITE:=$$(CONFIG_SITE) $(1) : export PKG_CONFIG_PATH:=$$(PKG_CONFIG_PATH) $(1) : export PKG_CONFIG_LIBDIR:=$$(PKG_CONFIG_PATH) - $(if $(CONFIG_CCACHE),$(1) : export CCACHE_DIR:=$(STAGING_DIR)/ccache) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_BASEDIR:=$(TOPDIR)) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_DIR:=$(if $(call qstrip,$(CONFIG_CCACHE_DIR)),$(call qstrip,$(CONFIG_CCACHE_DIR)),$(TOPDIR)/.ccache)) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_COMPILERCHECK:=%compiler% -dumpmachine; %compiler% -dumpversion) endef Build/Exports=$(Build/Exports/Default) diff --git a/include/toplevel.mk b/include/toplevel.mk index 5cf93ce7ef..c773206e6a 100644 --- a/include/toplevel.mk +++ b/include/toplevel.mk @@ -251,7 +251,7 @@ package/symlinks-clean: help: cat README -distclean: +distclean: cacheclean rm -rf bin build_dir .config* dl feeds key-build* logs package/feeds package/openwrt-packages staging_dir tmp @$(_SINGLE)$(SUBMAKE) -C scripts/config clean diff --git a/rules
Re: [OpenWrt-Devel] [PATCH] build: improve ccache support
On 2020-06-01 23:51, Petr Štetiar wrote: Roman Yeryomin [2020-06-01 18:32:26]: Hi, Set CCACHE_DIR to $(TOPDIR)/.ccache and CCACHE_BASEDIR to $(TOPDIR). this changes location of ccache directory (people would need to move it, symlink back or override it) and with CCACHE_BASEDIR it probably also invalidates the current cache/hashes, doesn't it? Yes. I'm not 100% sure but for me it makes more sense to make separate ccache dirs for each repo -- easier to manage and less corruption possibility. BTW you've missed following hardcoded patterns: target/toolchain/Makefile:EXCLUDE_DIRS:=*/ccache target/sdk/Makefile:EXCLUDE_DIRS:=*/ccache/* Hmm, missed that, will look. This allows to do clean and dirclean. Isn't it desired to remove potentially broken ccache as well with clean/dirclean? Do I want to remove my config, downloads, feeds etc. in order to remove ccache? IMO it's desired to ccache host tools, which are cleaned only with dirclean. It's always possible to just rm -rf ./.ccache same as with ./tmp/ Of cause we can make another make target, like cacheclean but not sure if it's worth doing. +++ b/include/host-build.mk + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_COMPILERCHECK:=%compiler% -dumpmachine; %compiler% -dumpversion) you've missed to describe this change This pattern was taken from package ccache, which looks sane to me. If you have other opinion, please share. distclean: rm -rf bin build_dir .config* dl feeds key-build* logs package/feeds package/openwrt-packages staging_dir tmp + rm -rf $(TOPDIR)/.ccache Other CCACHE_DIR variable occurencies can be overriden, this is hardcoded path. OK, this should be rm -rf $(CCACHE_DIR) probably. Michael Jones [2020-06-01 13:34:51]: Having build behavior change based on a symlink is undesirable. `make CCACHE_DIR=/whatever` should work as well Additionally, having the ccache directory be a configuration option allows it to persist across clones of the git repository, if the .config file is stored in git. BTW .config is .gitignored for a reason. Anyway, I don't think, that bloating the menu config with every Make variable from now on is desired. System has sane defaults and is flexible enough to allow fine tunning if needed. -- ynezz ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] build: improve ccache support
On 2020-06-01 21:34, Michael Jones wrote: On Mon, Jun 1, 2020 at 1:22 PM Felix Fietkau wrote: On 2020-06-01 19:11, Michael Jones wrote: > > > On Mon, Jun 1, 2020 at 10:33 AM Roman Yeryomin <mailto:ro...@advem.lv>> wrote: > > Set CCACHE_DIR to $(TOPDIR)/.ccache and CCACHE_BASEDIR to $(TOPDIR). > This allows to do clean and dirclean. Cache hit rate for test build > after dirclean is ~65%. > If CCACHE is enabled stats are printed out at the end of building > process. > > Signed-off-by: Roman Yeryomin mailto:ro...@advem.lv >> > > > This certainly looks like an improvement. > > However, there is an important usage case that this change doesn't address. > > Frequently when I am working on OpenWRT related things, I have many > different workspaces all tied to the same git repository hosted > externally. The reason for this is to allow multiple builds to live and > run independently. > > Having the CCACHE_DIR be located *inside* the repository doesn't share > the cache between multiple workspaces. > > So can the CCACHE_DIR be made configurable at build time based on the > .config file? Perhaps it can default to this, and only be set to the > value in .config if provided? For my purposes, I would always set the > CCACHE_DIR to a path that all of my workspaces use. I don't think there's a need for that config option. You could simply add a .ccache symlink in your source dir and point it to your shared cache. I do the same with dl on my trees. - Felix I disagree. Having build behavior change based on a symlink is undesirable. If it were a config option, it becomes a documented feature that is easily discoverable in the menu config. Additionally, having the ccache directory be a configuration option allows it to persist across clones of the git repository, if the .config file is stored in git. A symlink would need to be manually re-configured on each clone. I agree with Felix. Having one ccache directory for multiple repos doesn't make much sense to me as most probably they are for different platforms. And even if they are for same platform there are more chances for ccache corruption and deleting it will affect all those repos. So it still can be done with symlink but IMO should be done manually to make sure you know what you are doing. Also BASEDIR should be changed too, probably, if we want to go that way. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] build: improve ccache support
Set CCACHE_DIR to $(TOPDIR)/.ccache and CCACHE_BASEDIR to $(TOPDIR). This allows to do clean and dirclean. Cache hit rate for test build after dirclean is ~65%. If CCACHE is enabled stats are printed out at the end of building process. Signed-off-by: Roman Yeryomin --- .gitignore| 1 + Makefile | 3 +++ include/host-build.mk | 4 +++- include/package.mk| 4 +++- include/toplevel.mk | 1 + rules.mk | 3 +++ 6 files changed, 14 insertions(+), 2 deletions(-) diff --git a/.gitignore b/.gitignore index 6549af83be..b6bfe1a525 100644 --- a/.gitignore +++ b/.gitignore @@ -28,3 +28,4 @@ TAGS*~ git-src .project .cproject +.ccache diff --git a/Makefile b/Makefile index 32c050bb48..dfeaf83e2c 100644 --- a/Makefile +++ b/Makefile @@ -119,6 +119,9 @@ world: prepare $(target/stamp-compile) $(package/stamp-compile) $(package/stamp- $(_SINGLE)$(SUBMAKE) -r package/index $(_SINGLE)$(SUBMAKE) -r json_overview_image_info $(_SINGLE)$(SUBMAKE) -r checksum +ifneq ($(CONFIG_CCACHE),) + $(STAGING_DIR_HOST)/bin/ccache -s +endif .PHONY: clean dirclean prereq prepare world package/symlinks package/symlinks-install package/symlinks-clean diff --git a/include/host-build.mk b/include/host-build.mk index 9fc14241c6..4adac0883e 100644 --- a/include/host-build.mk +++ b/include/host-build.mk @@ -132,7 +132,9 @@ define Host/Exports/Default $(1) : export STAGING_PREFIX=$$(HOST_BUILD_PREFIX) $(1) : export PKG_CONFIG_PATH=$$(STAGING_DIR_HOST)/lib/pkgconfig:$$(HOST_BUILD_PREFIX)/lib/pkgconfig $(1) : export PKG_CONFIG_LIBDIR=$$(HOST_BUILD_PREFIX)/lib/pkgconfig - $(if $(CONFIG_CCACHE),$(1) : export CCACHE_DIR:=$(STAGING_DIR_HOST)/ccache) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_BASEDIR:=$(TOPDIR)) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_DIR:=$(TOPDIR)/.ccache) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_COMPILERCHECK:=%compiler% -dumpmachine; %compiler% -dumpversion) $(if $(HOST_CONFIG_SITE),$(1) : export CONFIG_SITE:=$(HOST_CONFIG_SITE)) $(if $(IS_PACKAGE_BUILD),$(1) : export PATH=$$(TARGET_PATH_PKG)) endef diff --git a/include/package.mk b/include/package.mk index 0575692742..eee5bbbf80 100644 --- a/include/package.mk +++ b/include/package.mk @@ -173,7 +173,9 @@ define Build/Exports/Default $(1) : export CONFIG_SITE:=$$(CONFIG_SITE) $(1) : export PKG_CONFIG_PATH:=$$(PKG_CONFIG_PATH) $(1) : export PKG_CONFIG_LIBDIR:=$$(PKG_CONFIG_PATH) - $(if $(CONFIG_CCACHE),$(1) : export CCACHE_DIR:=$(STAGING_DIR)/ccache) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_BASEDIR:=$(TOPDIR)) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_DIR:=$(TOPDIR)/.ccache) + $(if $(CONFIG_CCACHE),$(1) : export CCACHE_COMPILERCHECK:=%compiler% -dumpmachine; %compiler% -dumpversion) endef Build/Exports=$(Build/Exports/Default) diff --git a/include/toplevel.mk b/include/toplevel.mk index 5cf93ce7ef..f4a9dccd5e 100644 --- a/include/toplevel.mk +++ b/include/toplevel.mk @@ -253,6 +253,7 @@ help: distclean: rm -rf bin build_dir .config* dl feeds key-build* logs package/feeds package/openwrt-packages staging_dir tmp + rm -rf $(TOPDIR)/.ccache @$(_SINGLE)$(SUBMAKE) -C scripts/config clean ifeq ($(findstring v,$(DEBUG)),) diff --git a/rules.mk b/rules.mk index 66ddea2883..fb2f6bf57f 100644 --- a/rules.mk +++ b/rules.mk @@ -298,6 +298,9 @@ ifneq ($(CONFIG_CCACHE),) TARGET_CXX:= ccache_cxx HOSTCC:= ccache $(HOSTCC) HOSTCXX:= ccache $(HOSTCXX) + export CCACHE_BASEDIR:=$(TOPDIR) + export CCACHE_DIR:=$(TOPDIR)/.ccache + export CCACHE_COMPILERCHECK:=%compiler% -dumpmachine; %compiler% -dumpversion endif TARGET_CONFIGURE_OPTS = \ -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/2] libubox: update to latest git HEAD
eb30a03 libubox, jshn: add option to write output to a file Signed-off-by: Roman Yeryomin --- package/libs/libubox/Makefile | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/package/libs/libubox/Makefile b/package/libs/libubox/Makefile index 1c318b3e48..e5f4dcf8fe 100644 --- a/package/libs/libubox/Makefile +++ b/package/libs/libubox/Makefile @@ -5,9 +5,9 @@ PKG_RELEASE=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_URL=$(PROJECT_GIT)/project/libubox.git -PKG_SOURCE_DATE:=2019-06-16 -PKG_SOURCE_VERSION:=ecf56174da9614a0b3107d33def463eefb4d7785 -PKG_MIRROR_HASH:=e3dd137d69848b8cf2dbc58d70452586dd4178b55977896ea3a9dedaf62c768c +PKG_SOURCE_DATE:=2019-10-21 +PKG_SOURCE_VERSION:=eb30a03048f83e733a9530b5741808d7d0932ff2 +PKG_MIRROR_HASH:=04c0edc0df8c9336ca3d68d3e3536de42805837c72ceb5fb4ecaab87a59ff2cd CMAKE_INSTALL:=1 PKG_LICENSE:=ISC -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/2] base-files: uci-defaults: do config flush in one shot
Moving a file between tmpfs and other fs is neither
faster nor safer, thus no point in doing it in two steps.
Use new jshn option to write output directly to file.
Originally discussed here:
http://lists.openwrt.org/pipermail/openwrt-devel/2017-December/010127.html
Signed-off-by: Roman Yeryomin
---
package/base-files/files/lib/functions/uci-defaults.sh | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
b/package/base-files/files/lib/functions/uci-defaults.sh
index c2c6dc3fdc..0d2dcd5241 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -615,6 +615,5 @@ board_config_update() {
}
board_config_flush() {
- json_dump -i > /tmp/.board.json
- mv /tmp/.board.json ${CFG}
+ json_dump -i -o ${CFG}
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] libubox, jshn: add option to write output to a file
On 2019-09-14 01:22, Roman Yeryomin wrote: This would allow board_config_flush to run one command instead of two and would be faster and safer than redirecting output and moving a file between filesystems. Originally discussed here: http://lists.openwrt.org/pipermail/openwrt-devel/2017-December/010127.html Anybody? I would like to submit a patch to base files which depends on this. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] libubox, jshn: add option to write output to a file
This would allow board_config_flush to run one command instead
of two and would be faster and safer than redirecting output
and moving a file between filesystems.
Originally discussed here:
http://lists.openwrt.org/pipermail/openwrt-devel/2017-December/010127.html
Signed-off-by: Roman Yeryomin
---
jshn.c | 18 ++
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/jshn.c b/jshn.c
index 24e3265..0aa120c 100644
--- a/jshn.c
+++ b/jshn.c
@@ -275,7 +275,7 @@ out:
return obj;
}
-static int jshn_format(bool no_newline, bool indent)
+static int jshn_format(bool no_newline, bool indent, FILE *stream)
{
json_object *obj;
const char *output;
@@ -297,7 +297,7 @@ static int jshn_format(bool no_newline, bool indent)
goto out;
output = blobmsg_output;
}
- fprintf(stdout, "%s%s", output, no_newline ? "" : "\n");
+ fprintf(stream, "%s%s", output, no_newline ? "" : "\n");
free(blobmsg_output);
ret = 0;
@@ -342,6 +342,7 @@ int main(int argc, char **argv)
int i;
int ch;
int fd;
+ FILE *fp = NULL;
struct stat sb;
char *fbuf;
int ret;
@@ -366,7 +367,7 @@ int main(int argc, char **argv)
avl_insert(&env_vars, &vars[i].avl);
}
- while ((ch = getopt(argc, argv, "p:nir:R:w")) != -1) {
+ while ((ch = getopt(argc, argv, "p:nir:R:o:w")) != -1) {
switch(ch) {
case 'p':
var_prefix = optarg;
@@ -400,7 +401,16 @@ int main(int argc, char **argv)
close(fd);
return ret;
case 'w':
- return jshn_format(no_newline, indent);
+ return jshn_format(no_newline, indent, stdout);
+ case 'o':
+ fp = fopen(optarg, "w");
+ if (!fp) {
+ fprintf(stderr, "Error opening %s\n", optarg);
+ return 3;
+ }
+ jshn_format(no_newline, indent, fp);
+ fclose(fp);
+ return 0;
case 'n':
no_newline = true;
break;
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] tools: libressl: update to 2.9.2 version
To keep in sync with OpenSSL 1.1.x branch version options. Signed-off-by: Roman Yeryomin --- tools/libressl/Makefile | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/tools/libressl/Makefile b/tools/libressl/Makefile index 8894a058e4..d02911 100644 --- a/tools/libressl/Makefile +++ b/tools/libressl/Makefile @@ -8,8 +8,8 @@ include $(TOPDIR)/rules.mk PKG_NAME:=libressl -PKG_VERSION:=2.8.1 -PKG_HASH:=334bf7050f1db4087feebb30571ec13d9fa975bf05d6003ce3ab6d7d2452cf42 +PKG_VERSION:=2.9.2 +PKG_HASH:=c4c78167fae325b47aebd8beb54b6041d6f6a56b3743f4bd5d79b15642f9d5d4 PKG_RELEASE:=1 PKG_CPE_ID:=cpe:/a:openbsd:libressl -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] build: fix external module symbol collection if build_dir is a symlink
e26ffb31dfa30d498b963a86d231835e3af7d3df fixed only embedded modules symbol collection. If we are building external modules, like broadcom-wl or lantiq dsl stuff then modules which do EXPORT_SYMBOL have unresolved paths in Module.symvers and external module which depend on other external modules will have empty dependencies, leading to broken module loading. This was discussed on IRC with Jonas some time ago. Fix this by handling both resolved and unresolved paths. Signed-off-by: Roman Yeryomin --- include/kernel.mk | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/include/kernel.mk b/include/kernel.mk index 3195090a0a..8dfe903bcc 100644 --- a/include/kernel.mk +++ b/include/kernel.mk @@ -141,7 +141,10 @@ endef define collect_module_symvers for subdir in $(PKG_EXTMOD_SUBDIRS); do \ - grep -F (readlink -f $(PKG_BUILD_DIR)) $(PKG_BUILD_DIR)/subdir/Module.symvers >> $(PKG_BUILD_DIR)/Module.symvers.tmp; \ + realdir=(readlink -f $(PKG_BUILD_DIR)); \ + grep -F $(PKG_BUILD_DIR) $(PKG_BUILD_DIR)/subdir/Module.symvers >> $(PKG_BUILD_DIR)/Module.symvers.tmp; \ + [ "$(PKG_BUILD_DIR)" = "realdir" ] || \ + grep -F realdir $(PKG_BUILD_DIR)/subdir/Module.symvers >> $(PKG_BUILD_DIR)/Module.symvers.tmp; \ done; \ sort -u $(PKG_BUILD_DIR)/Module.symvers.tmp > $(PKG_BUILD_DIR)/Module.symvers; \ mv $(PKG_BUILD_DIR)/Module.symvers $(PKG_INFO_DIR)/$(PKG_NAME).symvers -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] toolchain: musl: update to 1.1.22
On 2019-04-12 17:39, Koen Vandeputte wrote: On 12.04.19 16:32, Roman Yeryomin wrote: Compile and run tested on mt7621 and ar71xx new features: - priority-inheritance mutexes - membarrier syscall, pre-registration to use it, fallback emulation - header-level support for new linux features in 4.19, 4.20, 5.0 major internal changes: - complete, async-safe view of all existent threads as global list - robust __synccall based on new thread list - new dynamic TLS is installed synchronously at dlopen - TLSDESC resolver functions no longer make bad ABI assumptions to call C - resolved shared library dependencies are now recorded compatibility & conformance: - dependency-order shared library constructor execution - sigaltstack no longer rejects SS_AUTODISARM, future flags - FILE is now a complete (dummy) type in pre-C11 feature profiles - setvbuf reports failure on invalid arguments - TSVTX is exposed unconditionally in tar.h - multithreaded set*id() no longer depends on /proc - key slot reuse after pthread_key_delete no longer depends on /proc bugs fixed: - failures in multithreaded set*id() with concurrent thread creation/exit - interposed free was called from invalid/inconsistent contexts - freeaddrinfo performed invalid free of some partial results lists - dlsym dependency order search had false negatives and false positives - dn_skipname gave wrong results for labels with 8-bit content - dcngettext clobbered errno, often breaking printing of error messages - sscanf read past end of buffer under certain conditions (1.1.21 regression) - pthread_key_create spuriously failed under race condition (1.1.21 regression) - fdopendir wrongly succeeded with O_PATH file descriptors - gets behaved incorrectly in presence of null bytes - namespace violations in c11 tsd and mutex function dependencies - incorrect prototype for makecontext (unimplemented) arch-specfic bugs fixed: - s390x had wrong values for POSIX_FADV_DONTNEED/_NOREUSE Signed-off-by: Dainis Jonitis Signed-off-by: Roman Yeryomin --- toolchain/musl/common.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk index b52263c43b..ae7758e8b5 100644 --- a/toolchain/musl/common.mk +++ b/toolchain/musl/common.mk @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/target.mk PKG_NAME:=musl -PKG_VERSION:=1.1.21 +PKG_VERSION:=1.1.22 PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) -PKG_SOURCE_VERSION:=1691b23955590d1eb66a11158fdd91c86337e886 -PKG_MIRROR_HASH:=4fa312d0ca020d31603ced84a7103fb328c6ae9508239491a228be17e7807147 +PKG_SOURCE_VERSION:=e97681d6f2c44bf5fa9ecdd30607cb63c780062e +PKG_MIRROR_HASH:=a6655418698735e19fe1c2deffb7335bbda634385c636206dd3cd5c8194a3ce0 PKG_SOURCE_URL:=git://git.musl-libc.org/musl PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz Thanks for the patch, but: 2 comments: - I've already got it in my staging tree [1] That's a strange one, making me feel like I should look into every existing staging tree/branch before I send a patch :) - The custom patches are not refreshed here (see my commit) True, didn't notice it needs a refresh. I can add your SoB's (or Tested-by's) in mine if you like? Well we did test it and Dainis was an original author of few fixes there. But that's ok, you first, do whatever you think is ok. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] toolchain: musl: update to 1.1.22
Compile and run tested on mt7621 and ar71xx new features: - priority-inheritance mutexes - membarrier syscall, pre-registration to use it, fallback emulation - header-level support for new linux features in 4.19, 4.20, 5.0 major internal changes: - complete, async-safe view of all existent threads as global list - robust __synccall based on new thread list - new dynamic TLS is installed synchronously at dlopen - TLSDESC resolver functions no longer make bad ABI assumptions to call C - resolved shared library dependencies are now recorded compatibility & conformance: - dependency-order shared library constructor execution - sigaltstack no longer rejects SS_AUTODISARM, future flags - FILE is now a complete (dummy) type in pre-C11 feature profiles - setvbuf reports failure on invalid arguments - TSVTX is exposed unconditionally in tar.h - multithreaded set*id() no longer depends on /proc - key slot reuse after pthread_key_delete no longer depends on /proc bugs fixed: - failures in multithreaded set*id() with concurrent thread creation/exit - interposed free was called from invalid/inconsistent contexts - freeaddrinfo performed invalid free of some partial results lists - dlsym dependency order search had false negatives and false positives - dn_skipname gave wrong results for labels with 8-bit content - dcngettext clobbered errno, often breaking printing of error messages - sscanf read past end of buffer under certain conditions (1.1.21 regression) - pthread_key_create spuriously failed under race condition (1.1.21 regression) - fdopendir wrongly succeeded with O_PATH file descriptors - gets behaved incorrectly in presence of null bytes - namespace violations in c11 tsd and mutex function dependencies - incorrect prototype for makecontext (unimplemented) arch-specfic bugs fixed: - s390x had wrong values for POSIX_FADV_DONTNEED/_NOREUSE Signed-off-by: Dainis Jonitis Signed-off-by: Roman Yeryomin --- toolchain/musl/common.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/toolchain/musl/common.mk b/toolchain/musl/common.mk index b52263c43b..ae7758e8b5 100644 --- a/toolchain/musl/common.mk +++ b/toolchain/musl/common.mk @@ -8,13 +8,13 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/target.mk PKG_NAME:=musl -PKG_VERSION:=1.1.21 +PKG_VERSION:=1.1.22 PKG_RELEASE:=1 PKG_SOURCE_PROTO:=git PKG_SOURCE_SUBDIR:=$(PKG_NAME)-$(PKG_VERSION) -PKG_SOURCE_VERSION:=1691b23955590d1eb66a11158fdd91c86337e886 -PKG_MIRROR_HASH:=4fa312d0ca020d31603ced84a7103fb328c6ae9508239491a228be17e7807147 +PKG_SOURCE_VERSION:=e97681d6f2c44bf5fa9ecdd30607cb63c780062e +PKG_MIRROR_HASH:=a6655418698735e19fe1c2deffb7335bbda634385c636206dd3cd5c8194a3ce0 PKG_SOURCE_URL:=git://git.musl-libc.org/musl PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION)-$(PKG_SOURCE_VERSION).tar.xz -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] stop accepting 4/32M board patches
On 2018-12-15 15:08, Jo-Philipp Wich wrote: Hi, I'm against rejecting such submissions if they're self-contained enough (e.g. for DTS based targets as mentioned by Piotr). I'd favor accepting the basic board support for such boards but disabling the image generation (commented out). I agree with jow here. If there are tiny targets already, which work, it doesn't make sense not to accept new ones. So it's basically either we don't support tiny targets at all (and remove currently supported) or continue accepting new ones. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] rb532: drop 4.9 support
Signed-off-by: Roman Yeryomin --- target/linux/rb532/config-4.9 | 182 -- .../rb532/patches-4.9/001-cmdline_hack.patch | 20 -- .../004-rb532-fix-partition-info.patch| 17 -- ...overflow-and-tx-underflow-interrupts.patch | 156 --- ...actor-rx-descriptor-flags-processing.patch | 110 --- .../107-use-NAPI_POLL_WEIGHT.patch| 11 -- .../patches-4.9/108-korina-use-gro.patch | 11 -- .../109-korina-whitespace-cleanup-2.patch | 135 - .../110-korina-update-authors.patch | 17 -- .../patches-4.9/111-korina-version-bump.patch | 13 -- 10 files changed, 672 deletions(-) delete mode 100644 target/linux/rb532/config-4.9 delete mode 100644 target/linux/rb532/patches-4.9/001-cmdline_hack.patch delete mode 100644 target/linux/rb532/patches-4.9/004-rb532-fix-partition-info.patch delete mode 100644 target/linux/rb532/patches-4.9/106-dont-use-rx-overflow-and-tx-underflow-interrupts.patch delete mode 100644 target/linux/rb532/patches-4.9/107-korina-refactor-rx-descriptor-flags-processing.patch delete mode 100644 target/linux/rb532/patches-4.9/107-use-NAPI_POLL_WEIGHT.patch delete mode 100644 target/linux/rb532/patches-4.9/108-korina-use-gro.patch delete mode 100644 target/linux/rb532/patches-4.9/109-korina-whitespace-cleanup-2.patch delete mode 100644 target/linux/rb532/patches-4.9/110-korina-update-authors.patch delete mode 100644 target/linux/rb532/patches-4.9/111-korina-version-bump.patch diff --git a/target/linux/rb532/config-4.9 b/target/linux/rb532/config-4.9 deleted file mode 100644 index a02dc03bb3..00 --- a/target/linux/rb532/config-4.9 +++ /dev/null @@ -1,182 +0,0 @@ -CONFIG_ARCH_BINFMT_ELF_STATE=y -CONFIG_ARCH_CLOCKSOURCE_DATA=y -CONFIG_ARCH_DISCARD_MEMBLOCK=y -CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y -CONFIG_ARCH_HAS_ELF_RANDOMIZE=y -# CONFIG_ARCH_HAS_GCOV_PROFILE_ALL is not set -# CONFIG_ARCH_HAS_SG_CHAIN is not set -CONFIG_ARCH_HIBERNATION_POSSIBLE=y -CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y -CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y -CONFIG_ARCH_REQUIRE_GPIOLIB=y -CONFIG_ARCH_SUPPORTS_UPROBES=y -CONFIG_ARCH_SUSPEND_POSSIBLE=y -CONFIG_ARCH_USE_BUILTIN_BSWAP=y -CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y -CONFIG_ATA=y -CONFIG_BLK_DEV_LOOP=y -CONFIG_BLK_DEV_SD=y -CONFIG_CEVT_R4K=y -CONFIG_CLONE_BACKWARDS=y -CONFIG_CPU_GENERIC_DUMP_TLB=y -CONFIG_CPU_HAS_PREFETCH=y -CONFIG_CPU_HAS_SYNC=y -CONFIG_CPU_LITTLE_ENDIAN=y -CONFIG_CPU_MIPS32=y -CONFIG_CPU_MIPS32_R1=y -CONFIG_CPU_MIPSR1=y -CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y -CONFIG_CPU_R4K_CACHE_TLB=y -CONFIG_CPU_R4K_FPU=y -CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y -CONFIG_CPU_SUPPORTS_HIGHMEM=y -CONFIG_CRC16=y -CONFIG_CRYPTO_CRC32C=y -CONFIG_CRYPTO_DEFLATE=y -CONFIG_CRYPTO_HASH=y -CONFIG_CRYPTO_HASH2=y -CONFIG_CRYPTO_LZO=y -CONFIG_CRYPTO_RNG2=y -CONFIG_CRYPTO_WORKQUEUE=y -CONFIG_CSRC_R4K=y -CONFIG_DMA_NONCOHERENT=y -# CONFIG_ENABLE_WARN_DEPRECATED is not set -CONFIG_EXT4_FS=y -# CONFIG_F2FS_CHECK_FS is not set -CONFIG_F2FS_FS=y -# CONFIG_F2FS_FS_SECURITY is not set -CONFIG_F2FS_FS_XATTR=y -CONFIG_F2FS_STAT_FS=y -CONFIG_FS_MBCACHE=y -CONFIG_GENERIC_ATOMIC64=y -CONFIG_GENERIC_CLOCKEVENTS=y -CONFIG_GENERIC_CMOS_UPDATE=y -CONFIG_GENERIC_IO=y -CONFIG_GENERIC_IRQ_CHIP=y -CONFIG_GENERIC_IRQ_SHOW=y -CONFIG_GENERIC_PCI_IOMAP=y -CONFIG_GENERIC_SCHED_CLOCK=y -CONFIG_GENERIC_SMP_IDLE_THREAD=y -CONFIG_GENERIC_TIME_VSYSCALL=y -CONFIG_GLOB=y -CONFIG_GPIOLIB=y -CONFIG_GPIO_SYSFS=y -CONFIG_HARDWARE_WATCHPOINTS=y -CONFIG_HAS_DMA=y -CONFIG_HAS_IOMEM=y -CONFIG_HAS_IOPORT_MAP=y -# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set -# CONFIG_HAVE_ARCH_BITREVERSE is not set -CONFIG_HAVE_ARCH_JUMP_LABEL=y -CONFIG_HAVE_ARCH_KGDB=y -CONFIG_HAVE_ARCH_SECCOMP_FILTER=y -CONFIG_HAVE_ARCH_TRACEHOOK=y -# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set -CONFIG_HAVE_CC_STACKPROTECTOR=y -CONFIG_HAVE_CONTEXT_TRACKING=y -CONFIG_HAVE_C_RECORDMCOUNT=y -CONFIG_HAVE_DEBUG_KMEMLEAK=y -CONFIG_HAVE_DEBUG_STACKOVERFLOW=y -CONFIG_HAVE_DMA_API_DEBUG=y -CONFIG_HAVE_DMA_ATTRS=y -CONFIG_HAVE_DMA_CONTIGUOUS=y -CONFIG_HAVE_DYNAMIC_FTRACE=y -CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y -CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y -CONFIG_HAVE_FUNCTION_TRACER=y -CONFIG_HAVE_GENERIC_DMA_COHERENT=y -CONFIG_HAVE_IDE=y -CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y -CONFIG_HAVE_LATENCYTOP_SUPPORT=y -CONFIG_HAVE_MEMBLOCK=y -CONFIG_HAVE_MEMBLOCK_NODE_MAP=y -CONFIG_HAVE_MOD_ARCH_SPECIFIC=y -CONFIG_HAVE_NET_DSA=y -CONFIG_HAVE_OPROFILE=y -CONFIG_HAVE_PERF_EVENTS=y -CONFIG_HAVE_SYSCALL_TRACEPOINTS=y -CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y -# CONFIG_HIGH_RES_TIMERS is not set -CONFIG_HW_HAS_PCI=y -CONFIG_HW_RANDOM=y -CONFIG_HZ=250 -# CONFIG_HZ_100 is not set -CONFIG_HZ_250=y -CONFIG_HZ_PERIODIC=y -CONFIG_IMAGE_CMDLINE_HACK=y -CONFIG_INITRAMFS_SOURCE="" -CONFIG_IRQ_DOMAIN=y -CONFIG_IRQ_FORCED_THREADING=y -CONFIG_IRQ_MIPS_CPU=y -CONFIG_IRQ_WORK=y -CONFIG_JBD2=y -CONFIG_KEXEC=y -CONFIG_KEXEC_CORE=y -CONFIG_KORINA=y -CONFIG_LEDS_MIKROT
[OpenWrt-Devel] [PATCH 1/3] rb532: add 4.14 support
Signed-off-by: Roman Yeryomin --- target/linux/rb532/config-4.14| 182 ++ .../rb532/patches-4.14/001-cmdline_hack.patch | 20 ++ .../004-rb532-fix-partition-info.patch| 17 ++ ...overflow-and-tx-underflow-interrupts.patch | 156 +++ ...actor-rx-descriptor-flags-processing.patch | 110 +++ .../107-use-NAPI_POLL_WEIGHT.patch| 11 ++ .../patches-4.14/108-korina-use-gro.patch | 11 ++ .../109-korina-whitespace-cleanup-2.patch | 135 + .../110-korina-update-authors.patch | 17 ++ .../111-korina-version-bump.patch | 13 ++ 10 files changed, 672 insertions(+) create mode 100644 target/linux/rb532/config-4.14 create mode 100644 target/linux/rb532/patches-4.14/001-cmdline_hack.patch create mode 100644 target/linux/rb532/patches-4.14/004-rb532-fix-partition-info.patch create mode 100644 target/linux/rb532/patches-4.14/106-dont-use-rx-overflow-and-tx-underflow-interrupts.patch create mode 100644 target/linux/rb532/patches-4.14/107-korina-refactor-rx-descriptor-flags-processing.patch create mode 100644 target/linux/rb532/patches-4.14/107-use-NAPI_POLL_WEIGHT.patch create mode 100644 target/linux/rb532/patches-4.14/108-korina-use-gro.patch create mode 100644 target/linux/rb532/patches-4.14/109-korina-whitespace-cleanup-2.patch create mode 100644 target/linux/rb532/patches-4.14/110-korina-update-authors.patch create mode 100644 target/linux/rb532/patches-4.14/111-korina-version-bump.patch diff --git a/target/linux/rb532/config-4.14 b/target/linux/rb532/config-4.14 new file mode 100644 index 00..a02dc03bb3 --- /dev/null +++ b/target/linux/rb532/config-4.14 @@ -0,0 +1,182 @@ +CONFIG_ARCH_BINFMT_ELF_STATE=y +CONFIG_ARCH_CLOCKSOURCE_DATA=y +CONFIG_ARCH_DISCARD_MEMBLOCK=y +CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y +CONFIG_ARCH_HAS_ELF_RANDOMIZE=y +# CONFIG_ARCH_HAS_GCOV_PROFILE_ALL is not set +# CONFIG_ARCH_HAS_SG_CHAIN is not set +CONFIG_ARCH_HIBERNATION_POSSIBLE=y +CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y +CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y +CONFIG_ARCH_REQUIRE_GPIOLIB=y +CONFIG_ARCH_SUPPORTS_UPROBES=y +CONFIG_ARCH_SUSPEND_POSSIBLE=y +CONFIG_ARCH_USE_BUILTIN_BSWAP=y +CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y +CONFIG_ATA=y +CONFIG_BLK_DEV_LOOP=y +CONFIG_BLK_DEV_SD=y +CONFIG_CEVT_R4K=y +CONFIG_CLONE_BACKWARDS=y +CONFIG_CPU_GENERIC_DUMP_TLB=y +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_CPU_LITTLE_ENDIAN=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPS32_R1=y +CONFIG_CPU_MIPSR1=y +CONFIG_CPU_NEEDS_NO_SMARTMIPS_OR_MICROMIPS=y +CONFIG_CPU_R4K_CACHE_TLB=y +CONFIG_CPU_R4K_FPU=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_CRC16=y +CONFIG_CRYPTO_CRC32C=y +CONFIG_CRYPTO_DEFLATE=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_HASH2=y +CONFIG_CRYPTO_LZO=y +CONFIG_CRYPTO_RNG2=y +CONFIG_CRYPTO_WORKQUEUE=y +CONFIG_CSRC_R4K=y +CONFIG_DMA_NONCOHERENT=y +# CONFIG_ENABLE_WARN_DEPRECATED is not set +CONFIG_EXT4_FS=y +# CONFIG_F2FS_CHECK_FS is not set +CONFIG_F2FS_FS=y +# CONFIG_F2FS_FS_SECURITY is not set +CONFIG_F2FS_FS_XATTR=y +CONFIG_F2FS_STAT_FS=y +CONFIG_FS_MBCACHE=y +CONFIG_GENERIC_ATOMIC64=y +CONFIG_GENERIC_CLOCKEVENTS=y +CONFIG_GENERIC_CMOS_UPDATE=y +CONFIG_GENERIC_IO=y +CONFIG_GENERIC_IRQ_CHIP=y +CONFIG_GENERIC_IRQ_SHOW=y +CONFIG_GENERIC_PCI_IOMAP=y +CONFIG_GENERIC_SCHED_CLOCK=y +CONFIG_GENERIC_SMP_IDLE_THREAD=y +CONFIG_GENERIC_TIME_VSYSCALL=y +CONFIG_GLOB=y +CONFIG_GPIOLIB=y +CONFIG_GPIO_SYSFS=y +CONFIG_HARDWARE_WATCHPOINTS=y +CONFIG_HAS_DMA=y +CONFIG_HAS_IOMEM=y +CONFIG_HAS_IOPORT_MAP=y +# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set +# CONFIG_HAVE_ARCH_BITREVERSE is not set +CONFIG_HAVE_ARCH_JUMP_LABEL=y +CONFIG_HAVE_ARCH_KGDB=y +CONFIG_HAVE_ARCH_SECCOMP_FILTER=y +CONFIG_HAVE_ARCH_TRACEHOOK=y +# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set +CONFIG_HAVE_CC_STACKPROTECTOR=y +CONFIG_HAVE_CONTEXT_TRACKING=y +CONFIG_HAVE_C_RECORDMCOUNT=y +CONFIG_HAVE_DEBUG_KMEMLEAK=y +CONFIG_HAVE_DEBUG_STACKOVERFLOW=y +CONFIG_HAVE_DMA_API_DEBUG=y +CONFIG_HAVE_DMA_ATTRS=y +CONFIG_HAVE_DMA_CONTIGUOUS=y +CONFIG_HAVE_DYNAMIC_FTRACE=y +CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y +CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y +CONFIG_HAVE_FUNCTION_TRACER=y +CONFIG_HAVE_GENERIC_DMA_COHERENT=y +CONFIG_HAVE_IDE=y +CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y +CONFIG_HAVE_LATENCYTOP_SUPPORT=y +CONFIG_HAVE_MEMBLOCK=y +CONFIG_HAVE_MEMBLOCK_NODE_MAP=y +CONFIG_HAVE_MOD_ARCH_SPECIFIC=y +CONFIG_HAVE_NET_DSA=y +CONFIG_HAVE_OPROFILE=y +CONFIG_HAVE_PERF_EVENTS=y +CONFIG_HAVE_SYSCALL_TRACEPOINTS=y +CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y +# CONFIG_HIGH_RES_TIMERS is not set +CONFIG_HW_HAS_PCI=y +CONFIG_HW_RANDOM=y +CONFIG_HZ=250 +# CONFIG_HZ_100 is not set +CONFIG_HZ_250=y +CONFIG_HZ_PERIODIC=y +CONFIG_IMAGE_CMDLINE_HACK=y +CONFIG_INITRAMFS_SOURCE="" +CONFIG_IRQ_DOMAIN=y +CONFIG_IRQ_FORCED_THREADING=y +CONFIG_IRQ_MIPS_CPU=y +CONFIG_IRQ_WORK=y +CONFIG_JBD2=y +CONFIG_KEXEC=y +CONFIG_KEXEC_CORE=y +CONFIG_KORINA=y +CONFIG_LEDS_MIKROT
[OpenWrt-Devel] [PATCH 2/3] rb532: switch to 4.14
Signed-off-by: Roman Yeryomin --- target/linux/rb532/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/rb532/Makefile b/target/linux/rb532/Makefile index 364a3a8b29..5aa8a6dc55 100644 --- a/target/linux/rb532/Makefile +++ b/target/linux/rb532/Makefile @@ -12,7 +12,7 @@ BOARDNAME:=Mikrotik RouterBoard 532 FEATURES:=pci targz squashfs minor nand MAINTAINER:=Roman Yeryomin -KERNEL_PATCHVER:=4.9 +KERNEL_PATCHVER:=4.14 include $(INCLUDE_DIR)/target.mk -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: fix ethernet for f5d8235-v2 board
Belkin F5D8235 v2 has two ethernet switches on board.
One internal rt3052 and rtl8366rb on rgmii interface.
Looks like internal switch settings were lost in
translation to device tree infrastructure.
Signed-off-by: Roman Yeryomin
---
.../linux/ramips/base-files/etc/board.d/02_network | 2 +-
target/linux/ramips/dts/F5D8235_V2.dts | 13 -
target/linux/ramips/image/rt305x.mk | 1 +
3 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 9e9ecbcb51..7a6b4c76b4 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -200,7 +200,6 @@ ramips_setup_interfaces()
awm002-evb-8M|\
c20i|\
dir-645|\
- f5d8235-v2|\
gl-mt300a|\
gl-mt300n|\
gl-mt750|\
@@ -371,6 +370,7 @@ ramips_setup_interfaces()
"0:lan" "2:lan" "6t@eth0"
;;
f5d8235-v1|\
+ f5d8235-v2|\
tew-714tru|\
v11st-fe|\
wzr-agl300nh)
diff --git a/target/linux/ramips/dts/F5D8235_V2.dts
b/target/linux/ramips/dts/F5D8235_V2.dts
index a3a1255941..1a86557ca4 100644
--- a/target/linux/ramips/dts/F5D8235_V2.dts
+++ b/target/linux/ramips/dts/F5D8235_V2.dts
@@ -111,7 +111,7 @@
&pinctrl {
state_default: pinctrl0 {
gpio {
- ralink,group = "spi", "i2c", "jtag", "rgmii", "mdio",
"uartf";
+ ralink,group = "spi", "i2c", "jtag", "mdio", "uartf";
ralink,function = "gpio";
};
};
@@ -119,10 +119,21 @@
ðernet {
mtd-mac-address = <&uboot 0x40004>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&rgmii_pins>;
};
&esw {
+ ralink,rgmii = <1>;
mediatek,portmap = <0x3f>;
+ ralink,fct2 = <0x0002500c>;
+ /*
+* ext phy base addr 31, rx/tx clock skew 0,
+* turbo mii off, rgmi 3.3v off, port 5 polling off
+* port5: enabled, gige, full-duplex, rx/tx-flow-control
+* port6: enabled, gige, full-duplex, rx/tx-flow-control
+ */
+ ralink,fpa2 = <0x1f003fff>;
};
&wmac {
diff --git a/target/linux/ramips/image/rt305x.mk
b/target/linux/ramips/image/rt305x.mk
index 066cef23cb..cc743c609d 100644
--- a/target/linux/ramips/image/rt305x.mk
+++ b/target/linux/ramips/image/rt305x.mk
@@ -329,6 +329,7 @@ define Device/f5d8235-v2
DTS := F5D8235_V2
IMAGE_SIZE := 7744k
DEVICE_TITLE := Belkin F5D8235 v2
+ DEVICE_PACKAGES := kmod-switch-rtl8366rb
endef
TARGET_DEVICES += f5d8235-v2
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-05 16:35, Linus Walleij wrote: On Sat, May 5, 2018 at 11:25 AM, Linus Walleij wrote: On Fri, May 4, 2018 at 11:49 PM, Linus Walleij wrote: On Fri, May 4, 2018 at 11:37 PM, Roman Yeryomin wrote: The GPIO LEDs does not come up though? CONFIG_LEDS_GPIO is not in config, and /sys/class/leds is empty. Does it need a separate kmod? kmod-leds-gpio is part of DEFAULT_PACKAGES now I guess you should run menuconfig and/or clean tmp/ to refresh profile package set. Hm I ran menuconfig and it doesn't work, and removing tmp/ didn't help either, but selecting a different target and then selecting CS351x again worked... shaky. OK rebuilding this overnight and retesting. It is still not working. Do you get GPIO LEDs on your device with this? AFAICT the problem is that there is no script in /etc/modules-boot.d to load the GPIO LED module. I'm digging into it to figure out more about how this module load is supposed to work... Sorry probably bad mechanics from my side, like replacing the rootfs but not the kernel :( The good news is: it works like a charm. All vital components are running, drivers probe, modules load correctly from the hard drive. Yeah.. they should be, that's one of the most common modules here :) On Raidsonic: root@OpenWrt:/# lsmod | grep led leds_gpio 2772 0 ledtrig_heartbeat 1570 0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-05 17:32, Linus Walleij wrote: On Tue, May 1, 2018 at 8:44 PM, Roman Yeryomin wrote: Linus, if you have time, could you check if this helps to bring network up on dir-685? https://github.com/yeryomin/openwrt/commit/b0296b1f71bd3d677c931addd6de341203fbf18f Sadly not. At least not outofthebox. I do not know what other devices using the RTL8366RB is doing apart from this. What did dmesg say about it? Did you try swconfig tool? E.g. `swconfig list` and/or `swconfig dev switch0 show` Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-04 20:15, Linus Walleij wrote: On Fri, May 4, 2018 at 5:26 PM, Roman Yeryomin wrote: [ 11.345619] kmodloader: 3 modules could not be probed [ 11.376633] kmodloader: dependency not loaded mbcache [ 11.407619] kmodloader: dependency not loaded jbd2 I think those should be fixed now (after compiling in jbd2 and mbcache): https://github.com/yeryomin/openwrt/commit/14ff513daeb81a47d179c55f440ed652e407c32b It's working pretty well :) Thanks for efforts and testing! :) My harddisk never goes to sleep but keeps spinning due to the missing hdparm script (I guess you dropped it), but we can always fix that later, it would ideally need a way to indicate that this busybox command should get built and I don't know how to do that. Yeah... that should be addressed separately. I still have few things in TODO, will add this one too. The GPIO LEDs does not come up though? CONFIG_LEDS_GPIO is not in config, and /sys/class/leds is empty. Does it need a separate kmod? kmod-leds-gpio is part of DEFAULT_PACKAGES now I guess you should run menuconfig and/or clean tmp/ to refresh profile package set. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: rework _ucidef_set_interface to be more generic
This is a rework of previously submitted patch reworking
ucidef_set_interface_raw [1]. Here, keep the idea but instead
make _ucidef_set_interface more generic and use it instead of
ucidef_set_interface_raw.
Also change the users like ucidef_set_interface_lan and others.
[1] https://patchwork.ozlabs.org/patch/844961/
Signed-off-by: Roman Yeryomin
---
.../base-files/files/lib/functions/uci-defaults.sh | 74 +++---
.../linux/ar71xx/base-files/etc/board.d/02_network | 6 +-
2 files changed, 27 insertions(+), 53 deletions(-)
diff --git a/package/base-files/files/lib/functions/uci-defaults.sh
b/package/base-files/files/lib/functions/uci-defaults.sh
index 3126fe6510..8065af24a5 100755
--- a/package/base-files/files/lib/functions/uci-defaults.sh
+++ b/package/base-files/files/lib/functions/uci-defaults.sh
@@ -27,29 +27,26 @@ json_select_object() {
json_select "$1"
}
-_ucidef_set_interface() {
- local name="$1"
- local iface="$2"
- local proto="$3"
+ucidef_set_interface() {
+ local network=$1
- json_select_object "$name"
- json_add_string ifname "$iface"
-
- if ! json_is_a protocol string || [ -n "$proto" ]; then
- case "$proto" in
- static|dhcp|none|pppoe) : ;;
- *)
- case "$name" in
- lan) proto="static" ;;
- wan) proto="dhcp" ;;
- *) proto="none" ;;
- esac
- ;;
- esac
+ [ -z "$network" ] && return
- json_add_string protocol "$proto"
- fi
+ json_select_object network
+ json_select_object "$network"
+ shift
+
+ while [ -n "$1" ]; do
+ local opt="$1"
+ local val="$2"
+ shift; shift;
+ [ -n "$opt" -a -n "$val" ] || break
+
+ json_add_string "$opt" "$val"
+ done
+
+ json_select ..
json_select ..
}
@@ -66,31 +63,19 @@ ucidef_set_model_name() {
}
ucidef_set_interface_lan() {
- json_select_object network
- _ucidef_set_interface lan "$@"
- json_select ..
+ ucidef_set_interface "lan" ifname "$1" protocol "${2:-static}"
}
ucidef_set_interface_wan() {
- json_select_object network
- _ucidef_set_interface wan "$@"
- json_select ..
+ ucidef_set_interface "wan" ifname "$1" protocol "${2:-dhcp}"
}
ucidef_set_interfaces_lan_wan() {
local lan_if="$1"
local wan_if="$2"
- json_select_object network
- _ucidef_set_interface lan "$lan_if"
- _ucidef_set_interface wan "$wan_if"
- json_select ..
-}
-
-ucidef_set_interface_raw() {
- json_select_object network
- _ucidef_set_interface "$@"
- json_select ..
+ ucidef_set_interface_lan "$lan_if"
+ ucidef_set_interface_wan "$wan_if"
}
_ucidef_add_switch_port() {
@@ -185,9 +170,9 @@ _ucidef_finish_switch_roles() {
devices="${devices:+$devices }$device"
fi
json_select ..
-
- _ucidef_set_interface "$role" "$devices"
json_select ..
+
+ ucidef_set_interface "$role" ifname "$devices"
done
}
@@ -300,18 +285,7 @@ ucidef_set_interface_macaddr() {
local network="$1"
local macaddr="$2"
- json_select_object network
-
- json_select "$network"
- [ $? -eq 0 ] || {
- json_select ..
- return
- }
-
- json_add_string macaddr "$macaddr"
- json_select ..
-
- json_select ..
+ ucidef_set_interface "$network" macaddr "$macaddr"
}
ucidef_add_atm_bridge() {
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index cbbcf53946..0c7034525b 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -400,7 +400,7 @@ ar71xx_setup_interfaces()
"0@eth0" "1:lan:4" "2:lan:3" "3:lan:2" "4:lan:1" "5:wan"
;;
ew-balin)
- ucidef_set_interface_raw "usb2" "usb0" "static"
+
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-02 11:01, Linus Walleij wrote: There is some moaning in dmesg: [ 10.071561] Btrfs loaded, crc32c=crc32c-generic [ 10.105705] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.161586] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.209501] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.264368] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.312050] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.368142] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.415827] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.500774] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.548542] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.604267] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver [ 10.651342] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.699520] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.754306] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.802014] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.855212] ehci-platform: EHCI generic platform driver [ 10.895311] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 10.943323] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.998070] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.045793] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.102146] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.150097] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.205504] usbcore: registered new interface driver usb-storage [ 11.249732] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) [ 11.297491] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 11.345619] kmodloader: 3 modules could not be probed [ 11.376633] kmodloader: dependency not loaded mbcache [ 11.407619] kmodloader: dependency not loaded jbd2 I think those should be fixed now (after compiling in jbd2 and mbcache): https://github.com/yeryomin/openwrt/commit/14ff513daeb81a47d179c55f440ed652e407c32b Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ipq40xx: fix ethernet on ap-dk01.1
Not sure how it worked before but ethernet is disabled
by default in ipq4019 dtsi.
Signed-off-by: Roman Yeryomin
---
...-09-dts-ipq4019-ap-dk01.1-enable-ethernet.patch | 25 ++
1 file changed, 25 insertions(+)
create mode 100644
target/linux/ipq40xx/patches-4.14/864-09-dts-ipq4019-ap-dk01.1-enable-ethernet.patch
diff --git
a/target/linux/ipq40xx/patches-4.14/864-09-dts-ipq4019-ap-dk01.1-enable-ethernet.patch
b/target/linux/ipq40xx/patches-4.14/864-09-dts-ipq4019-ap-dk01.1-enable-ethernet.patch
new file mode 100644
index 00..625c18dcc8
--- /dev/null
+++
b/target/linux/ipq40xx/patches-4.14/864-09-dts-ipq4019-ap-dk01.1-enable-ethernet.patch
@@ -0,0 +1,25 @@
+--- a/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
b/arch/arm/boot/dts/qcom-ipq4019-ap.dk01.1.dtsi
+@@ -121,6 +121,22 @@
+ status = "ok";
+ };
+
++ mdio@9 {
++ status = "okay";
++ };
++
++ ess-switch@c00 {
++ status = "okay";
++ };
++
++ ess-psgmii@98000 {
++ status = "okay";
++ };
++
++ edma@c08 {
++ status = "okay";
++ };
++
+ usb3_ss_phy: ssphy@9a000 {
+ status = "ok";
+ };
--
2.14.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ipq40xx cpu frequency
Hi Christian, I'm seeing this [1.275858] cpufreq: cpufreq_online: CPU0: Running at unlisted freq: 632000 KHz [1.276620] cpufreq: cpufreq_online: CPU0: Unlisted initial frequency changed to: 716000 KHz on ap-dk01 board (I suspect others may be affected too, I don't have hw to test). Looks like related to your commit a44d435c1d ipq40xx: fix apss cpu overclocking spam While it fixes the original problem described, it would be nice not to misconfigure the clock anyway. Also, since the official highest frequency is 716.8MHz, wouldn't it be more logical to fix it in appropriate board dts (if needed) and not in the common dtsi? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-05-02 11:01, Linus Walleij wrote: On Wed, May 2, 2018 at 12:18 AM, Linus Walleij wrote: On Sun, Apr 29, 2018 at 8:32 PM, Roman Yeryomin wrote: Linus, could you test that branch on your device and see if network is working by default? I've pulled in the branch and building it for D-Link DNS-313 right now. Will report back. I found some initial snags and sent you a patch for it, mostly some chicken-and-egg problem for harddisk boot and clumsy attempt to patch the command line from my side that I replaced with bootargs in the device tree. It boots, mounts root and gets to prompt now. I will submit the bootargs patches upstream. There is some moaning in dmesg: [ 10.071561] Btrfs loaded, crc32c=crc32c-generic [ 10.105705] mbcache: exports duplicate symbol __mb_cache_entry_free (owned by kernel) [ 10.161586] jbd2: exports duplicate symbol jbd2__journal_restart (owned by kernel) Oh.. wait... I've missed that DNS-313 doesn't have any onboard flash and boots from hdd! Seems we need CONFIG_JBD2=y and CONFIG_FS_MBCACHE=y (along with ext4 and other fs) back. I guess you see this too? Related to the USB mess I guess, we can live with it. No, I don't have the same, Raidsonic (and other boards, afaik) have onboard flash which can be used for system. So hard drives can be used for pure storage, which is more convenient, IMO. Network does not come up either, I suspect it is because of missing the Realtek PHY driver, so will investigate this further. Could be... what does dmesg say about that? does it read any phy_id ? Raidsonic has Marvell 88e1116 phy but works as generic phy just fine: [5.731760] Generic PHY gpio-0:01: attached PHY driver [Generic PHY] (mii_bus:phy_addr=gpio-0:01, irq=POLL) [5.731781] phy_id=0x01410e11, phy_mode=rgmii Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-29 21:32, Roman Yeryomin wrote:
On 2018-04-27 09:18, John Crispin wrote:
On 17/04/18 00:34, Roman Yeryomin wrote:
On 2018-04-15 20:22, Roman Yeryomin wrote:
On 2018-04-14 20:36, Hans Ulli Kroll wrote:
Hi Roman
On Tue, 10 Apr 2018, Linus Walleij wrote:
On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin
wrote:
> I have tested them quickly yesterday on nas4220b board. Although I've
> managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> And I didn't check anything else.
> I didn't yet look at the code but before I dive there I have a question: did
> you have a chance to test it yourself on any of the boards? And if yes,
> which one?
I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself
+diff --git a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct
usb_hcd
*hcd, u16 typeReq, u16 wValue,
+ /* see what we found out */
+ temp = check_reset_complete(fotg210, wIndex,
status_reg,
+ fotg210_readl(fotg210, status_reg));
++
++ /* restart schedule */
++ fotg210->command |= CMD_RUN;
++ fotg210_writel(fotg210, fotg210->command,
&fotg210->regs->command);
+ }
+
+ if (!(temp & (PORT_RESUME|PORT_RESET))) {
+--
+2.16.2
+
Didn't work for me :(
I've found why it didn't work:
[ 5.845199] Warning! fotg210_hcd should always be loaded before
uhci_hcd and ohci_hcd, not after
After fixing kernel config and applying your patch it works.
So your patch works and is needed indeed.
But there are other problems.
Second USB (USB1) port cannot be initialized and only USB0 is
working:
[ 5.843831] fotg210_hcd: FOTG210 Host Controller (EHCI) Driver
[ 5.844298] pinctrl-gemini 4000.syscon:pinctrl: ACTIVATE
function "usb" with group "usbgrp"
[ 5.845067] fotg210-hcd 6800.usb: initialized Gemini PHY
[ 5.845095] fotg210-hcd 6800.usb: Faraday USB2.0 Host
Controller
[ 5.845176] fotg210-hcd 6800.usb: new USB bus registered,
assigned bus number 1
[ 5.845696] fotg210-hcd 6800.usb: irq 29, io mem 0x6800
[ 5.877212] fotg210-hcd 6800.usb: USB 2.0 started, EHCI 1.00
[ 5.880314] hub 1-0:1.0: USB hub found
[ 5.880546] hub 1-0:1.0: 1 port detected
[ 5.904768] pinctrl-gemini 4000.syscon:pinctrl: pin T6 USB
GNDA U20 already requested by 6800.usb; cannot claim for
6900.usb
[ 5.904807] pinctrl-gemini 4000.syscon:pinctrl: pin-305
(6900.usb) status -22
[ 5.904845] pinctrl-gemini 4000.syscon:pinctrl: could not
request pin 305 (T6 USB GNDA U20) from group usbgrp on device
pinctrl-gemini
[ 5.904872] fotg210-hcd 6900.usb: Error applying setting,
reverse things back
[ 5.904928] fotg210-hcd: probe of 6900.usb failed with error
-22
After removing pinctrl from USB1 it is initialized but then only USB1
is working, USB0 is seen but there are no interrupts.
Didn't yet look at the code, maybe you will know where to fix right
away.
Regards,
Roman
Hi,
how shall we proceed ? merge 1, 2 and 3, let roman fix the regressions
and then merge 4 ? or drop the series for now and let you guys send a
V2 with the regression fixes integrated ?
Hi John,
I've prepared 4.14 branch here
https://github.com/yeryomin/openwrt/commits/gemini-4.14
I think it can be merged in it's current state. The only problem I'm
aware of is that usb is not fully working (afaik, Hans is working on
it).
Linus, could you test that branch on your device and see if network is
working by default?
Linus, if you have time, could you check if this helps to bring network
up on dir-685?
https://github.com/yeryomin/openwrt/commit/b0296b1f71bd3d677c931addd6de341203fbf18f
Note I have disabled video and input drivers, since dir-685 seems is the
only board which could potentially use them. And ili display wasn't
enabled anyway.
All those modules can be enabled via kernel modules. If you could test
the needed set we could add them to dir-685 packages.
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Second RGMII ethernet on MT7621?
On 2018-04-30 22:10, John Crispin wrote: On 30/04/18 19:08, Bjørn Mork wrote: Hello, I have been playing with a ZyXEL WAP6805, which appears to be an OEM version of the https://wikidevi.com/wiki/ZyXEL_WAP6806_(Armor_X1) This thing has an oversized mini-PCIe Quantenna module. Or that's the mechanical form factor. The connection between the MT7621 and the Quantenna QT3840BC appears to be RGMII, ref the OEM bootlog below. Notice how this brings up both eth2 and eth3 and add them to the br0 bridge. The Quantenna module loads u-boot and a firmware image using tftp, and it is then managed over the ethernet interface. So I was looking for a quick way to enable the second ethernet port on the MT7621, but can't find any. Am I looking the wrong place, or am I right that the support for this is still lacking? Any idea how many bits and pieces are missing? Bjørn Hi Bjørn making gmac2 work s not trivial with the current driver. however making the upstream mtk_eth_soc driver work on mt7621 is pretty easy i think and will give you dual gmac support. upstream only supports mt7623 arm atm. its been on my todo list for a while but i simply have not been able to find the 2-3 days required to make it work. John, include me in testing list when you do :) Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-27 09:18, John Crispin wrote:
On 17/04/18 00:34, Roman Yeryomin wrote:
On 2018-04-15 20:22, Roman Yeryomin wrote:
On 2018-04-14 20:36, Hans Ulli Kroll wrote:
Hi Roman
On Tue, 10 Apr 2018, Linus Walleij wrote:
On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin
wrote:
> I have tested them quickly yesterday on nas4220b board. Although I've
> managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> And I didn't check anything else.
> I didn't yet look at the code but before I dive there I have a question: did
> you have a chance to test it yourself on any of the boards? And if yes,
> which one?
I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself
+diff --git a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct
usb_hcd
*hcd, u16 typeReq, u16 wValue,
+ /* see what we found out */
+ temp = check_reset_complete(fotg210, wIndex,
status_reg,
+ fotg210_readl(fotg210, status_reg));
++
++ /* restart schedule */
++ fotg210->command |= CMD_RUN;
++ fotg210_writel(fotg210, fotg210->command,
&fotg210->regs->command);
+ }
+
+ if (!(temp & (PORT_RESUME|PORT_RESET))) {
+--
+2.16.2
+
Didn't work for me :(
I've found why it didn't work:
[ 5.845199] Warning! fotg210_hcd should always be loaded before
uhci_hcd and ohci_hcd, not after
After fixing kernel config and applying your patch it works.
So your patch works and is needed indeed.
But there are other problems.
Second USB (USB1) port cannot be initialized and only USB0 is working:
[ 5.843831] fotg210_hcd: FOTG210 Host Controller (EHCI) Driver
[ 5.844298] pinctrl-gemini 4000.syscon:pinctrl: ACTIVATE
function "usb" with group "usbgrp"
[ 5.845067] fotg210-hcd 6800.usb: initialized Gemini PHY
[ 5.845095] fotg210-hcd 6800.usb: Faraday USB2.0 Host
Controller
[ 5.845176] fotg210-hcd 6800.usb: new USB bus registered,
assigned bus number 1
[ 5.845696] fotg210-hcd 6800.usb: irq 29, io mem 0x6800
[ 5.877212] fotg210-hcd 6800.usb: USB 2.0 started, EHCI 1.00
[ 5.880314] hub 1-0:1.0: USB hub found
[ 5.880546] hub 1-0:1.0: 1 port detected
[ 5.904768] pinctrl-gemini 4000.syscon:pinctrl: pin T6 USB GNDA
U20 already requested by 6800.usb; cannot claim for 6900.usb
[ 5.904807] pinctrl-gemini 4000.syscon:pinctrl: pin-305
(6900.usb) status -22
[ 5.904845] pinctrl-gemini 4000.syscon:pinctrl: could not
request pin 305 (T6 USB GNDA U20) from group usbgrp on device
pinctrl-gemini
[ 5.904872] fotg210-hcd 6900.usb: Error applying setting,
reverse things back
[ 5.904928] fotg210-hcd: probe of 6900.usb failed with error
-22
After removing pinctrl from USB1 it is initialized but then only USB1
is working, USB0 is seen but there are no interrupts.
Didn't yet look at the code, maybe you will know where to fix right
away.
Regards,
Roman
Hi,
how shall we proceed ? merge 1, 2 and 3, let roman fix the regressions
and then merge 4 ? or drop the series for now and let you guys send a
V2 with the regression fixes integrated ?
Hi John,
I've prepared 4.14 branch here
https://github.com/yeryomin/openwrt/commits/gemini-4.14
I think it can be merged in it's current state. The only problem I'm
aware of is that usb is not fully working (afaik, Hans is working on
it).
Linus, could you test that branch on your device and see if network is
working by default?
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-15 20:22, Roman Yeryomin wrote:
On 2018-04-14 20:36, Hans Ulli Kroll wrote:
Hi Roman
On Tue, 10 Apr 2018, Linus Walleij wrote:
On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin
wrote:
> I have tested them quickly yesterday on nas4220b board. Although I've
> managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> And I didn't check anything else.
> I didn't yet look at the code but before I dive there I have a question: did
> you have a chance to test it yourself on any of the boards? And if yes,
> which one?
I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself
+diff --git a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct usb_hcd
*hcd, u16 typeReq, u16 wValue,
+ /* see what we found out */
+ temp = check_reset_complete(fotg210, wIndex, status_reg,
+ fotg210_readl(fotg210, status_reg));
++
++ /* restart schedule */
++ fotg210->command |= CMD_RUN;
++ fotg210_writel(fotg210, fotg210->command,
&fotg210->regs->command);
+ }
+
+ if (!(temp & (PORT_RESUME|PORT_RESET))) {
+--
+2.16.2
+
Didn't work for me :(
I've found why it didn't work:
[5.845199] Warning! fotg210_hcd should always be loaded before
uhci_hcd and ohci_hcd, not after
After fixing kernel config and applying your patch it works.
So your patch works and is needed indeed.
But there are other problems.
Second USB (USB1) port cannot be initialized and only USB0 is working:
[5.843831] fotg210_hcd: FOTG210 Host Controller (EHCI) Driver
[5.844298] pinctrl-gemini 4000.syscon:pinctrl: ACTIVATE function
"usb" with group "usbgrp"
[5.845067] fotg210-hcd 6800.usb: initialized Gemini PHY
[5.845095] fotg210-hcd 6800.usb: Faraday USB2.0 Host Controller
[5.845176] fotg210-hcd 6800.usb: new USB bus registered,
assigned bus number 1
[5.845696] fotg210-hcd 6800.usb: irq 29, io mem 0x6800
[5.877212] fotg210-hcd 6800.usb: USB 2.0 started, EHCI 1.00
[5.880314] hub 1-0:1.0: USB hub found
[5.880546] hub 1-0:1.0: 1 port detected
[5.904768] pinctrl-gemini 4000.syscon:pinctrl: pin T6 USB GNDA
U20 already requested by 6800.usb; cannot claim for 6900.usb
[5.904807] pinctrl-gemini 4000.syscon:pinctrl: pin-305
(6900.usb) status -22
[5.904845] pinctrl-gemini 4000.syscon:pinctrl: could not request
pin 305 (T6 USB GNDA U20) from group usbgrp on device pinctrl-gemini
[5.904872] fotg210-hcd 6900.usb: Error applying setting, reverse
things back
[5.904928] fotg210-hcd: probe of 6900.usb failed with error -22
After removing pinctrl from USB1 it is initialized but then only USB1 is
working, USB0 is seen but there are no interrupts.
Didn't yet look at the code, maybe you will know where to fix right
away.
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-17 00:36, Linus Walleij wrote: On Mon, Apr 16, 2018 at 2:00 AM, Roman Yeryomin wrote: Looking at your tree... I don't see any (affecting) differences in ethernet driver itself. Probably it's something else.. MDIO? After looking into ethernet I've found several issues. 1. skew delay settings were not ported from old driver to dts for nas4220b board 2. kernel config in you patches (accidentally?) disabled bridge support 3. driver crashes if you try to disable unused gmac in dts because of access to uninitialized port(0|1) member of struct gemini_ethernet Ouch. Sorry for my sucky backport. :( So after fixing all above ethernet on nas4220b is working ok. You are my hero :) Can you confirm that after enabling bridge support back (just remove CONFIG_BRIDGE from gemini kernel config and rebuild) ethernet comes up on D-link boards? That is with default network config. I think it's best if I test your entire set-up on the D-Link routers. Do you have a git branch I can grab? Will try to prepare that tomorrow. Target kernel config must be cleaned up, it's redundant in some places and overrides some things which it should not. I've managed to get usb working, it was kernel config error again (and Hans' patch he sent earlier is actually working). But still usb has problems, e.g. I couldn't get both ports working, only one of them. SATA seems to be working out of the box, which is good! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-12 00:37, Roman Yeryomin wrote: On 2018-04-11 00:51, Linus Walleij wrote: On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin wrote: I have tested them quickly yesterday on nas4220b board. Although I've managed to boot it (had to fix rootfs image) ethernet and usb didn't work. And I didn't check anything else. I didn't yet look at the code but before I dive there I have a question: did you have a chance to test it yourself on any of the boards? And if yes, which one? Hm I tested mostly the rootfs and that the kernel would get to prompt. But for my D-Link devices I tested mostly with kernel v4.16 because I'm working close to mainline. Testing now it seems network is not coming up here either :/ as it works like a charm on v4.16 it must be some minor issue. Looking at your tree... I don't see any (affecting) differences in ethernet driver itself. Probably it's something else.. MDIO? After looking into ethernet I've found several issues. 1. skew delay settings were not ported from old driver to dts for nas4220b board 2. kernel config in you patches (accidentally?) disabled bridge support 3. driver crashes if you try to disable unused gmac in dts because of access to uninitialized port(0|1) member of struct gemini_ethernet So after fixing all above ethernet on nas4220b is working ok. Can you confirm that after enabling bridge support back (just remove CONFIG_BRIDGE from gemini kernel config and rebuild) ethernet comes up on D-link boards? That is with default network config. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-14 20:36, Hans Ulli Kroll wrote:
Hi Roman
On Tue, 10 Apr 2018, Linus Walleij wrote:
On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin
wrote:
> I have tested them quickly yesterday on nas4220b board. Although I've
> managed to boot it (had to fix rootfs image) ethernet and usb didn't work.
> And I didn't check anything else.
> I didn't yet look at the code but before I dive there I have a question: did
> you have a chance to test it yourself on any of the boards? And if yes,
> which one?
I think the fotg controller gets stalled after a port reset.
Please check attached (untested) patch for openwrt.
I can test this next week by myself
+diff --git a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+index 2acc51b0be5a..bc9efb49adc7 100644
+--- a/drivers/usb/host/fotg210-hcd.c
b/drivers/usb/host/fotg210-hcd.c
+@@ -1653,6 +1653,10 @@ static int fotg210_hub_control(struct usb_hcd
*hcd, u16 typeReq, u16 wValue,
+ /* see what we found out */
+ temp = check_reset_complete(fotg210, wIndex, status_reg,
+ fotg210_readl(fotg210, status_reg));
++
++ /* restart schedule */
++ fotg210->command |= CMD_RUN;
++ fotg210_writel(fotg210, fotg210->command,
&fotg210->regs->command);
+ }
+
+ if (!(temp & (PORT_RESUME|PORT_RESET))) {
+--
+2.16.2
+
Didn't work for me :(
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-11 00:51, Linus Walleij wrote: On Mon, Apr 9, 2018 at 12:38 PM, Roman Yeryomin wrote: I have tested them quickly yesterday on nas4220b board. Although I've managed to boot it (had to fix rootfs image) ethernet and usb didn't work. And I didn't check anything else. I didn't yet look at the code but before I dive there I have a question: did you have a chance to test it yourself on any of the boards? And if yes, which one? Hm I tested mostly the rootfs and that the kernel would get to prompt. But for my D-Link devices I tested mostly with kernel v4.16 because I'm working close to mainline. Testing now it seems network is not coming up here either :/ as it works like a charm on v4.16 it must be some minor issue. Looking at your tree... I don't see any (affecting) differences in ethernet driver itself. Probably it's something else.. MDIO? I would guess Hans Ulli Kroll can help with USB, I just applied the patches and have nothing to test it with. I never used USB... Hans, did you have a chance to test 4.14 (or 4.16) on any of gemini boards? The v4.16 stack is pretty small and there the network for sure works (not a finished patch set): https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-nomadik.git/log/?h=openwrt-v4.16 If it's hard to get v4.14 to backport we could maybe aim to use v4.16 instead? Or is there some OpenWRT baselining involved? Yeah, generic comes first and that's not 10min work :) Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] kernel version status
On 2018-04-01 17:48, Hauke Mehrtens wrote: The next OpenWrt release will use kernel 4.9 and kernel 4.14 depending on the target. All targets that are *not* on either kernel 4.9 or 4.14 will not be included in the next release. The following targets are on kernel 4.4 and will probably not be included in the next release: * gemini There are patches for kernel 4.14 on the mailing list, we will probably get them in before the release and ship this with 4.14 Hi Hauke, I have a working 4.9, is it too late to submit? I'll also work on 4.14 submitted by Linus, but it didn't work out of the box, so probably will take more time. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 0/4] Gemini forward-port to kernel v4.14
On 2018-04-04 23:34, Linus Walleij wrote: This patch set forward-ports Gemini to v4.14 with as good support as I can get. I don't know if all or any patches actually make it through to the devel list. They are also posted here: https://dflund.se/~triad/krad/gemini/openwrt/ It would be nice if we could apply this and get a working modernized base for the Gemini platforms. The v4.14 is a bit patchy. With v4.16 we will be looking pretty neat. Linus Walleij (4): firmware-utils: Add the DNS-313 image header tool gemini: Forward-port to v4.14 gemini: Add kernel v4.14 patches gemini: Delete kernel 4.4 patches Hi Linus, thanks for the patches! I have tested them quickly yesterday on nas4220b board. Although I've managed to boot it (had to fix rootfs image) ethernet and usb didn't work. And I didn't check anything else. I didn't yet look at the code but before I dive there I have a question: did you have a chance to test it yourself on any of the boards? And if yes, which one? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Booting D-Link DNS-313, for for 18.03 ??
On 2018-02-23 16:07, Linus Walleij wrote: With kernel v4.14 we would probably have to backport a bunch of patches from HEAD to get into proper shape but it can be done. looks like v4.16 is going to look real nice though. Which device are you using as target? Raidsonic IB4220-B Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Booting D-Link DNS-313, for for 18.03 ??
On 2018-02-22 09:58, Linus Walleij wrote: On Wed, Feb 21, 2018 at 6:10 PM, Hans Ulli Kroll wrote: Hi Linus Since Openwrt codebase is *very* outdated and old, v4.4 with mach files and only one/two I've done some work on updating this mess. Now I can build with v4.14.x, now I need to sort out how I can append DTB and build the flash binaries / hardddisk images. Does Roman have plans? It seems he is still the maintainer. Yes, just didn't have enough time :/ I have 4.9 in my staging but 4.14 with dts sounds better of cause. Though it's a major change and I would probably better update to 4.9 first, so it could be included in release and then update to 4.14 with conversion to Device/ infrastructure. I looked at it briefly but couldn't get anywhere with it, but the OpenWRT build system seems to have built-in rules to append DTB as used by bcm and others. Many improvements in the build system overall, seems very neat. Yes, it's pretty easy to use A bunch of stuff (like appending machine code to set the machine type) can simply be dropped. We should build all DTBs and create images for them. When we bump to v4.16 I can patch in my DNS-313 image creation utility as well. This is my (unfinished) rewritten fragment for v4.14 based mostly on bcm: target/linux/gemini/Makefile # # Copyright (C) 2009-2018 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. # include $(TOPDIR)/rules.mk ARCH:=arm BOARD:=gemini BOARDNAME:=Cortina Systems CS351x FEATURES:=squashfs pci rtc MAINTAINER:=Roman Yeryomin CPU_TYPE:=fa526 KERNEL_PATCHVER:=4.14 define Target/Description Build firmware images for the StorLink/Cortina Gemini CS351x ARM FA526 CPU endef include $(INCLUDE_DIR)/target.mk KERNELNAME:=zImage dtbs $(eval $(call BuildTarget)) target/linux/gemini/image/Makefile # # Copyright (C) 2009-2014 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. # include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/image.mk define Build/wbd-nops # work around the bootloader's bug with extra nops mv $@ $@.tmp echo -en "\x00\x00\xa0\xe1\x00\x00\xa0\xe1\x00\x00\xa0\xe1\x00\x00\xa0\xe1" > $@ cat $@.tmp >> $@ rm -f $@.tmp endef define Device/Default # All DTB files are prefixed with "gemini-" DEVICE_DTS := $(patsubst %.dtb,%,$(notdir $(wildcard $(if $(IB),$(KDIR),$(DTS_DIR))/*-$(1).dtb))) KERNEL := kernel-bin | append-dtb KERNEL_DEPENDS = $$(wildcard $(DTS_DIR)/$$(DEVICE_DTS).dts) KERNEL_NAME := zImage IMAGE_NAME := $$(IMAGE_PREFIX)-$$(1).$$(2) BLOCKSIZE := 128k endef define Device/dlink-dir-685 DEVICE_TITLE := D-Link DIR-685 Xtreme N Storage Router endef TARGET_DEVICES += dlink-dir-685 define Device/nas4220b DEVICE_TITLE := Raidsonic NAS IB-4220-B endef TARGET_DEVICES += nas4220b define Device/rut1xx DEVICE_TITLE := Teltonika RUT1xx endef TARGET_DEVICES += rut1xx define Device/sq201 DEVICE_TITLE := ITian Square One SQ201 endef TARGET_DEVICES += sq201 define Device/wbd111 DEVICE_TITLE := Wiliboard WBD-111 endef TARGET_DEVICES += wbd111 define Device/wbd222 DEVICE_TITLE := Wiliboard WBD-222 endef TARGET_DEVICES += wbd222 $(eval $(call BuildImage)) Looks valid, did you try building it? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: mt7621: add Mediatek AP-MT7621A-V60 EVB support
This board has:
- mt7621 SoC
- 8MB SPI flash
- 128MB RAM
- 5x ethernet ports from internal (SoC) switch
- 1x ethernet port sitting on gmac2 and IC+ phy (not yet supported)
- 3x PCIe slots
- 1x USB 2.0 and 1x USB 3.0
- sound based on wm8960
- SDXC card slot (full size)
First fw write from interactive u-boot menu, interrupt with 2.
After that sysupgrade.
Tested both with 4.9 and 4.14
Signed-off-by: Roman Yeryomin
---
.../linux/ramips/base-files/etc/board.d/02_network | 1 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/AP-MT7621A-V60.dts | 127 +
target/linux/ramips/image/mt7621.mk| 8 ++
4 files changed, 137 insertions(+)
create mode 100644 target/linux/ramips/dts/AP-MT7621A-V60.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index fe19a226f8..33f08e91ce 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -73,6 +73,7 @@ ramips_setup_interfaces()
3g-6200n|\
ai-br100|\
alfa-network,ac1200rm|\
+ mediatek,ap-mt7621a-v60|\
d240|\
db-wrt01|\
dir-300-b7|\
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index a0610b257f..0bcefddf11 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -22,6 +22,7 @@ platform_check_image() {
all0256n-8M|\
all5002|\
all5003|\
+ mediatek,ap-mt7621a-v60|\
ar725w|\
asl26555-8M|\
asl26555-16M|\
diff --git a/target/linux/ramips/dts/AP-MT7621A-V60.dts
b/target/linux/ramips/dts/AP-MT7621A-V60.dts
new file mode 100644
index 00..a98d8a6467
--- /dev/null
+++ b/target/linux/ramips/dts/AP-MT7621A-V60.dts
@@ -0,0 +1,127 @@
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+/ {
+ compatible = "mediatek,ap-mt7621a-v60", "mediatek,mt7621-soc";
+ model = "Mediatek AP-MT7621A-V60 EVB";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x800>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,57600";
+ };
+
+ sound {
+ compatible = "simple-audio-card";
+ simple-audio-card,name = "Audio-I2S";
+ simple-audio-card,format = "i2s";
+ simple-audio-card,bitclock-master = <&dailink0_master>;
+ simple-audio-card,frame-master = <&dailink0_master>;
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Headphone", "Headphone Jack";
+ simple-audio-card,routing =
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "Headphone Jack", "HP_L",
+ "Headphone Jack", "HP_R";
+ simple-audio-card,mclk-fs = <256>;
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s>;
+ };
+
+ dailink0_master: simple-audio-card,codec {
+ sound-dai = <&codec>;
+ };
+ };
+};
+
+&pinctrl {
+ state_default: pinctrl0 {
+ gpio {
+ ralink,group = "uart2", "rgmii2";
+ ralink,function = "gpio";
+ };
+ };
+ i2s_pins: i2s {
+ i2s {
+ ralink,group = "uart3";
+ ralink,function = "i2s";
+ };
+ };
+};
+
+&i2c {
+ status = "okay";
+
+ codec: wm8960@1a {
+ #sound-dai-cells = <0>;
+ compatible = "wlf,wm8960";
+ reg = <0x1a>;
+ wlf,shared-lrclk;
+ };
+};
+
+&gdma {
+ status = "okay";
+};
+
+&i2s {
+ #sound-dai-cells = <0>;
+ status = "okay";
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s_pins>;
+};
+
+&spi0 {
+ status = "okay";
+
+ mx25l6405d@0 {
+ #address-cells = <1>;
+ #size-cells = <1>;
+ compatible = "mx25l6405d","jedec,spi-nor";
+ reg = <0 0>;
+ spi-max-frequency = <1000>;
+ m25p,chunked-io = <32>;
+
+ partition@0 {
+ la
[OpenWrt-Devel] [PATCH] ramips: mt7621: fix usb init
In 4.14 reg-names is required to identify resources. Otherwise init fails with: [5.900501] xhci-mtk 1e1c.xhci: invalid resource [5.910499] xhci-mtk: probe of 1e1c.xhci failed with error -22 Signed-off-by: Roman Yeryomin --- target/linux/ramips/dts/mt7621.dtsi | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ramips/dts/mt7621.dtsi b/target/linux/ramips/dts/mt7621.dtsi index d68ddf3bc6..23b5455d68 100644 --- a/target/linux/ramips/dts/mt7621.dtsi +++ b/target/linux/ramips/dts/mt7621.dtsi @@ -342,6 +342,7 @@ compatible = "mediatek,mt8173-xhci"; reg = <0x1e1c 0x1000 0x1e1d0700 0x0100>; + reg-names = "mac", "ippc"; clocks = <&sysclock>; clock-names = "sys_ck"; -- 2.14.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [LEDE-DEV] LEDE call for vote on remerge proposal V3
On 19 September 2017 at 18:22, Zoltan HERPAI wrote: > Hi John, > > On Tue, 19 Sep 2017, John Crispin wrote: > >> Hi Zoltan, >> >> actually its been 29 days since the domain transfer had been completed and >> ownership has been set properly. >> >> i already had a chat with some devs last week about what to do next, >> people are all very busy with their daytime jobs at the moment and starting >> on the next step does obviously require some lead time. I was actually >> hoping to start consolidating the git trees this week but as it turns out i >> wont have time. hopefully next week will be less busy. > > > Sounds great - I know the feeling unfortunately. Obviously it'd be great if > the coordination would be done public to some degree so each of us could > pick tasks. Really good news! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PROPOSAL] move OpenWrt codebase to Git and GitHub
On 24 May 2016 at 18:51, Eric Schultz wrote: > I think this is a great idea! I very much support a move to Github; despite > it's issues, it's just where development is happening today. Keeping a > non-Github channel for submitting patches is also a great idea I think. > > My free-software side worries about using something non-free like drone.io > for CI but this is a huge task certainly and I'm not sure a free tool would > meet everyone's needs (plus there's the huge added burden of maintenance). How about something like kernelci.org? I'm not sure how to run all this https://github.com/kernelci but the result looks very interesting. > Eric > > On Tue, May 24, 2016 at 9:06 AM, Luka Perkov wrote: >> >> Dear OpenWrt mailing list readers, >> >> as the subject says I'd like to make proposal to move the OpenWrt >> codebase to Git. This was already discussed before [1] and now when >> there are no blockers [2] for this change I'd like that we as a >> community move forward with this switch. >> >> Also, I'd like to propose that we move the project to GitHub and here >> are the reasons why I see this as a good decision: >> >> * GitHub will allow people to contribute more easily >> >> The bigger amount of contributions has already happened and can be seen >> on the packages feed which is already hosted on GitHub. With this I'm >> also hoping to avoid comments regarding invalid patches on the mailing >> list. >> >> For now I am proposing that the current development workflow is also >> accepted - aka. patches that are sent to the mailing list are also >> accepted. >> >> * GitHub and similar services will allow us to integrate more easily >> with other projects >> >> Here specifically I mean integration with modern CI. Here is an example >> of integration with drone.io [3][4]. At the moment this is only in the >> POC stage but what I'd like to do down the line is to: >> >> - build OpenWrt images for all architectures for every pull request >> >> - build OpenWrt package binary for every package pull request for all >> architectures and make it available for download >> >> - build and host OpenWrt qemu and/or Docker image for every pull request >> >> This will allow easy review of the work since flags will be shown in the >> pull request if the build was sucessful or not. Also, this will allow >> people to test changes without building the image and thus lowering the >> time that needs to be spent on maintenance work. >> >> If this proposal gets accepted I'll be sending out an email to get >> access to more build servers so this new build infrastructure can >> properly support the project in a timely fashion. >> >> Please share your thoughts regarding this proposal. >> >> Regards, >> Luka >> >> [1] >> https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html >> [2] https://lists.openwrt.org/pipermail/openwrt-devel/2016-May/041329.html >> [3] https://github.com/makkrnic/openwrt-qemu-x86 >> [4] http://sartura-drone.makkrnic.com/makkrnic/openwrt-qemu-x86/5 >> ___ >> openwrt-devel mailing list >> openwrt-devel@lists.openwrt.org >> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel > > > > > -- > Eric Schultz, Community Manager, prpl Foundation > http://www.prplfoundation.org > eschu...@prplfoundation.org > cell: 920-539-0404 > skype: ericschultzwi > @EricPrpl > > ___ > 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] OpenWrt / LEDE
On 24 May 2016 at 23:31, Hauke Mehrtens wrote: > Hi, > > As it looks like the IRC meeting will not happen, because not so big > interest by the people not already involved in LEDE and problems finding > a time, lets discuss on the mailing list like suggested by Jow. > > Currently it looks like only Luka is working on OpenWrt as he committed > many patches from LEDE to OpenWrt, which is fine. > > What will happen to the OpenWrt project? To me it looks like nobody > except Luka is interested in working on OpenWrt. Are there any plans to > continue the OpenWrt project or will it just die, only nobody wants to > say it? > Currently this is a bad situation for people that want to contribute > patches because they do not exactly know were to contribute, some post > them just to both list which is probably the best solution for the time > we do not have a real solution. > > I do not plan to contribute much to OpenWrt any more and I do not know > if I can commit anything any more, at least it looks like I was kicked > from the openwrt-hackers mailing list without informing me. I believe LEDE didn't plan to contribute to OpenWrt from the very beginning. LEDE words are pretty contrary to the works. > I would like to see a reunion of LEDE and OpenWrt, so do any of the non > LEDE but OpenWrt core devs have any problems with the LEDE rules and so on? How many devs do you think it's possible to attract to OpenWrt having the promotion LEDE does and remembering the fact that most active devs went to LEDE? Same rules could be applied inside OpenWrt as I see it. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 16 May 2016 at 19:04, Dave Taht wrote: > On Mon, May 16, 2016 at 1:14 AM, Roman Yeryomin wrote: >> On 16 May 2016 at 01:34, Roman Yeryomin wrote: >>> On 6 May 2016 at 22:43, Dave Taht wrote: >>>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin >>>> wrote: >>>>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>>>>> >>>>>>> I've created a OpenWRT ticket[1] on this issue, as it seems that >>>>>>> someone[2] >>>>>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>>>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>>>>> is in some kind of conflict. >>>>>>> >>>>>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>>>>> >>>>>>> [2] >>>>>>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>>>>> >>>>>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>>>>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>>>>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >>>>> >>>>> Forgot to mention, I've reduced drop_batch_size down to 32 >>>> >>>> 0) Not clear to me if that's the right line, there are 4 wifi queues, >>>> and the third one >>>> is the BE queue. >>> >>> That was an example, sorry, should have stated that. I've applied same >>> settings to all 4 queues. >>> >>>> That is too low a limit, also, for normal use. And: >>>> for the purpose of this particular UDP test, flows 16 is ok, but not >>>> ideal. >>> >>> I played with different combinations, it doesn't make any >>> (significant) difference: 20-30Mbps, not more. >>> What numbers would you propose? >>> >>>> 1) What's the tcp number (with a simultaneous ping) with this latest >>>> patchset? >>>> (I care about tcp performance a lot more than udp floods - surviving a >>>> udp flood yes, performance, no) >>> >>> During the test (both TCP and UDP) it's roughly 5ms in average, not >>> running tests ~2ms. Actually I'm now wondering if target is working at >>> all, because I had same result with target 80ms.. >>> So, yes, latency is good, but performance is poor. >>> >>>> before/after? >>>> >>>> tc -s qdisc show dev wlan0 during/after results? >>> >>> during the test: >>> >>> qdisc mq 0: root >>> Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues >>> 17) >>> backlog 1545794b 1021p requeues 17 >>> qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues >>> 17) >>> backlog 1541252b 1018p requeues 17 >>> maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 >>> new_flows_len 0 old_flows_len 1 >>> qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 >>> target 80.0ms ce_threshold 32us interval 100.0ms ecn >>> Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) >>> backlog 0b 0p requeues 0 >>> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 >>> new_flows_len 0 old_flows_len 0 >>> >>> >>> after the test (60sec): >>> >>> qdisc mq 0: root >>> Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues >>> 28) &g
Re: [OpenWrt-Devel] [Make-wifi-fast] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 16 May 2016 at 11:12, David Lang wrote: > On Mon, 16 May 2016, Roman Yeryomin wrote: > >> On 6 May 2016 at 22:43, Dave Taht wrote: >>> >>> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin >>> wrote: >>>> >>>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>>> >>>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer >>>>> wrote: >>>>>> >>>>>> >> >>> That is too low a limit, also, for normal use. And: >>> for the purpose of this particular UDP test, flows 16 is ok, but not >>> ideal. >> >> >> I played with different combinations, it doesn't make any >> (significant) difference: 20-30Mbps, not more. >> What numbers would you propose? > > > How many different flows did you have going at once? I believe that the > reason for higher numbers isn't for throughput, but to allow for more flows > to be isolated from each other. If you have too few buckets, different flows > will end up being combined into one bucket so that one will affect the other > more. I'm testing with one flow, I never saw bigger performance with more flows (e.g. -P8 to iperf3). Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 16 May 2016 at 01:34, Roman Yeryomin wrote: > On 6 May 2016 at 22:43, Dave Taht wrote: >> On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin >> wrote: >>> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>>> >>>>> I've created a OpenWRT ticket[1] on this issue, as it seems that >>>>> someone[2] >>>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>>> is in some kind of conflict. >>>>> >>>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>>> >>>>> [2] >>>>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>>> >>>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >>> >>> Forgot to mention, I've reduced drop_batch_size down to 32 >> >> 0) Not clear to me if that's the right line, there are 4 wifi queues, >> and the third one >> is the BE queue. > > That was an example, sorry, should have stated that. I've applied same > settings to all 4 queues. > >> That is too low a limit, also, for normal use. And: >> for the purpose of this particular UDP test, flows 16 is ok, but not >> ideal. > > I played with different combinations, it doesn't make any > (significant) difference: 20-30Mbps, not more. > What numbers would you propose? > >> 1) What's the tcp number (with a simultaneous ping) with this latest >> patchset? >> (I care about tcp performance a lot more than udp floods - surviving a >> udp flood yes, performance, no) > > During the test (both TCP and UDP) it's roughly 5ms in average, not > running tests ~2ms. Actually I'm now wondering if target is working at > all, because I had same result with target 80ms.. > So, yes, latency is good, but performance is poor. > >> before/after? >> >> tc -s qdisc show dev wlan0 during/after results? > > during the test: > > qdisc mq 0: root > Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues 17) > backlog 1545794b 1021p requeues 17 > qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues 17) > backlog 1541252b 1018p requeues 17 > maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 > new_flows_len 0 old_flows_len 1 > qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > > > after the test (60sec): > > qdisc mq 0: root > Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) > backlog 0b 0p requeues 28 > qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) > backlog 0b 0p requeues 0 > maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 > new_flows_len 0 old_flows_len 0 > qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 > target 80.0ms ce_threshold 32us interval 100.0ms ecn > Sent 3084996052 bytes 2037744 pkt (dropped 277017
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 16 May 2016 at 02:07, Eric Dumazet wrote: > On Mon, 2016-05-16 at 01:34 +0300, Roman Yeryomin wrote: > >> qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 >> target 80.0ms ce_threshold 32us interval 100.0ms ecn >> Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues >> 17) >> backlog 1541252b 1018p requeues 17 >> maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 >> new_flows_len 0 old_flows_len 1 > > Why do you have ce_threshold set ? You really should not (even if it > does not matter for the kind of traffic you have at this moment) No idea, it was there always. How do I unset it? Setting it to 0 doesn't help. > If your expected link speed is around 1Gbps, or 80,000 packets per > second, then you have to understand that 1024 packets limit is about 12 > ms at most. > > Even if the queue is full, max sojourn time of a packet would be 12 ms. > > I really do not see how 'target 80 ms' could be hit. Well, as I said, I've tried different options. Neither target 20ms (as Dave proposed) not 12ms save the situation. > You basically have FQ, with no Codel effect, but with the associated > cost of Codel (having to take timestamps) > > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 6 May 2016 at 22:43, Dave Taht wrote: > On Fri, May 6, 2016 at 11:56 AM, Roman Yeryomin wrote: >> On 6 May 2016 at 21:43, Roman Yeryomin wrote: >>> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote: >>>> >>>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2] >>>> closed Felix'es OpenWRT email account (bad choice! emails bouncing). >>>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project >>>> is in some kind of conflict. >>>> >>>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349 >>>> >>>> [2] >>>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335 >>> >>> OK, so, after porting the patch to 4.1 openwrt kernel and playing a >>> bit with fq_codel limits I was able to get 420Mbps UDP like this: >>> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256 >> >> Forgot to mention, I've reduced drop_batch_size down to 32 > > 0) Not clear to me if that's the right line, there are 4 wifi queues, > and the third one > is the BE queue. That was an example, sorry, should have stated that. I've applied same settings to all 4 queues. > That is too low a limit, also, for normal use. And: > for the purpose of this particular UDP test, flows 16 is ok, but not > ideal. I played with different combinations, it doesn't make any (significant) difference: 20-30Mbps, not more. What numbers would you propose? > 1) What's the tcp number (with a simultaneous ping) with this latest patchset? > (I care about tcp performance a lot more than udp floods - surviving a > udp flood yes, performance, no) During the test (both TCP and UDP) it's roughly 5ms in average, not running tests ~2ms. Actually I'm now wondering if target is working at all, because I had same result with target 80ms.. So, yes, latency is good, but performance is poor. > before/after? > > tc -s qdisc show dev wlan0 during/after results? during the test: qdisc mq 0: root Sent 1600496000 bytes 1057194 pkt (dropped 1421568, overlimits 0 requeues 17) backlog 1545794b 1021p requeues 17 qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 1601271168 bytes 1057706 pkt (dropped 1422304, overlimits 0 requeues 17) backlog 1541252b 1018p requeues 17 maxpacket 1514 drop_overlimit 1422304 new_flow_count 35 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 after the test (60sec): qdisc mq 0: root Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) backlog 0b 0p requeues 28 qdisc fq_codel 8001: parent :1 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8002: parent :2 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 qdisc fq_codel 8003: parent :3 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 3084996052 bytes 2037744 pkt (dropped 2770176, overlimits 0 requeues 28) backlog 0b 0p requeues 28 maxpacket 1514 drop_overlimit 2770176 new_flow_count 64 ecn_mark 0 new_flows_len 0 old_flows_len 1 qdisc fq_codel 8004: parent :4 limit 1024p flows 16 quantum 1514 target 80.0ms ce_threshold 32us interval 100.0ms ecn Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0) backlog 0b 0p requeues 0 maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0 new_flows_len 0 old_flows_len 0 > IF you are doing builds for the archer c7v2, I can join in on this... (?) I'm not
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 6 May 2016 at 21:43, Roman Yeryomin wrote:
> On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote:
>>
>> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2]
>> closed Felix'es OpenWRT email account (bad choice! emails bouncing).
>> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project
>> is in some kind of conflict.
>>
>> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349
>>
>> [2]
>> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335
>
> OK, so, after porting the patch to 4.1 openwrt kernel and playing a
> bit with fq_codel limits I was able to get 420Mbps UDP like this:
> tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256
Forgot to mention, I've reduced drop_batch_size down to 32
> This is certainly better than 30Mbps but still more than two times
> less than before (900).
> TCP also improved a little (550 to ~590).
>
> Felix, others, do you want to see the ported patch, maybe I did something
> wrong?
> Doesn't look like it will save ath10k from performance regression.
>
>>
>> On Fri, 6 May 2016 11:42:43 +0200
>> Jesper Dangaard Brouer wrote:
>>
>>> Hi Felix,
>>>
>>> This is an important fix for OpenWRT, please read!
>>>
>>> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024,
>>> without also adjusting q->flows_cnt. Eric explains below that you must
>>> also adjust the buckets (q->flows_cnt) for this not to break. (Just
>>> adjust it to 128)
>>>
>>> Problematic OpenWRT commit in question:
>>> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e
>>> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from
>>> causing too much cpu load with higher speed (#21326)")
>>>
>>>
>>> I also highly recommend you cherry-pick this very recent commit:
>>> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()")
>>> https://git.kernel.org/davem/net-next/c/9d18562a227
>>>
>>> This should fix very high CPU usage in-case fq_codel goes into drop mode.
>>> The problem is that drop mode was considered rare, and implementation
>>> wise it was chosen to be more expensive (to save cycles on normal mode).
>>> Unfortunately is it easy to trigger with an UDP flood. Drop mode is
>>> especially expensive for smaller devices, as it scans a 4K big array,
>>> thus 64 cache misses for small devices!
>>>
>>> The fix is to allow drop-mode to bulk-drop more packets when entering
>>> drop-mode (default 64 bulk drop). That way we don't suddenly
>>> experience a significantly higher processing cost per packet, but
>>> instead can amortize this.
>>>
>>> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk
>>> drop, given we also recommend bucket size to be 128 ? (thus the amount
>>> of memory to scan is less, but their CPU is also much smaller).
>>>
>>> --Jesper
>>>
>>>
>>> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet
>>> wrote:
>>>
>>> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote:
>>> > > On 5 May 2016 at 19:12, Eric Dumazet wrote:
>>> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote:
>>> > > >
>>> > > >>
>>> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>>> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn
>>> > > >> Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0)
>>> > > >> backlog 0b 0p requeues 0
>>> > > >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>>> > > >> new_flows_len 0 old_flows_len 0
>>> > > >
>>> > > >
>>> > > > Limit of 1024 packets and 1024 flows is not wise I think.
>>> > > >
>>> > > > (If all buckets are in use, each bucket has a virtual queue of 1
>>> > > > packet,
>>> > > > which is almost the same than having no queue at all)
>>> > > >
>>> > > > I suggest to have at least 8 packets per bucket, to let Codel have a
>>> > > > chance to trigger.
>>> > > >
>>> > > > So you could either reduce number of buckets to 128 (if memory is
>>> > > > tight), or increase limit to 8192.
>>> > >
>>> > > Will try, but what I've posted is default, I didn't change/configure
>>> > > that.
>>> >
>>> > fq_codel has a default of 10240 packets and 1024 buckets.
>>> >
>>> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413
>>> >
>>> > If someone changed that in the linux variant you use, he probably should
>>> > explain the rationale.
>>
>> --
>> Best regards,
>> Jesper Dangaard Brouer
>> MSc.CS, Principal Kernel Engineer at Red Hat
>> Author of http://www.iptv-analyzer.org
>> LinkedIn: http://www.linkedin.com/in/brouer
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] OpenWRT wrong adjustment of fq_codel defaults (Was: [Codel] fq_codel_drop vs a udp flood)
On 6 May 2016 at 15:47, Jesper Dangaard Brouer wrote:
>
> I've created a OpenWRT ticket[1] on this issue, as it seems that someone[2]
> closed Felix'es OpenWRT email account (bad choice! emails bouncing).
> Sounds like OpenWRT and the LEDE https://www.lede-project.org/ project
> is in some kind of conflict.
>
> OpenWRT ticket [1] https://dev.openwrt.org/ticket/22349
>
> [2]
> http://thread.gmane.org/gmane.comp.embedded.openwrt.devel/40298/focus=40335
OK, so, after porting the patch to 4.1 openwrt kernel and playing a
bit with fq_codel limits I was able to get 420Mbps UDP like this:
tc qdisc replace dev wlan0 parent :1 fq_codel flows 16 limit 256
This is certainly better than 30Mbps but still more than two times
less than before (900).
TCP also improved a little (550 to ~590).
Felix, others, do you want to see the ported patch, maybe I did something wrong?
Doesn't look like it will save ath10k from performance regression.
>
> On Fri, 6 May 2016 11:42:43 +0200
> Jesper Dangaard Brouer wrote:
>
>> Hi Felix,
>>
>> This is an important fix for OpenWRT, please read!
>>
>> OpenWRT changed the default fq_codel sch->limit from 10240 to 1024,
>> without also adjusting q->flows_cnt. Eric explains below that you must
>> also adjust the buckets (q->flows_cnt) for this not to break. (Just
>> adjust it to 128)
>>
>> Problematic OpenWRT commit in question:
>> http://git.openwrt.org/?p=openwrt.git;a=patch;h=12cd6578084e
>> 12cd6578084e ("kernel: revert fq_codel quantum override to prevent it from
>> causing too much cpu load with higher speed (#21326)")
>>
>>
>> I also highly recommend you cherry-pick this very recent commit:
>> net-next: 9d18562a2278 ("fq_codel: add batch ability to fq_codel_drop()")
>> https://git.kernel.org/davem/net-next/c/9d18562a227
>>
>> This should fix very high CPU usage in-case fq_codel goes into drop mode.
>> The problem is that drop mode was considered rare, and implementation
>> wise it was chosen to be more expensive (to save cycles on normal mode).
>> Unfortunately is it easy to trigger with an UDP flood. Drop mode is
>> especially expensive for smaller devices, as it scans a 4K big array,
>> thus 64 cache misses for small devices!
>>
>> The fix is to allow drop-mode to bulk-drop more packets when entering
>> drop-mode (default 64 bulk drop). That way we don't suddenly
>> experience a significantly higher processing cost per packet, but
>> instead can amortize this.
>>
>> To Eric, should we recommend OpenWRT to adjust default (max) 64 bulk
>> drop, given we also recommend bucket size to be 128 ? (thus the amount
>> of memory to scan is less, but their CPU is also much smaller).
>>
>> --Jesper
>>
>>
>> On Thu, 05 May 2016 12:23:27 -0700 Eric Dumazet
>> wrote:
>>
>> > On Thu, 2016-05-05 at 19:25 +0300, Roman Yeryomin wrote:
>> > > On 5 May 2016 at 19:12, Eric Dumazet wrote:
>> > > > On Thu, 2016-05-05 at 17:53 +0300, Roman Yeryomin wrote:
>> > > >
>> > > >>
>> > > >> qdisc fq_codel 0: dev eth0 root refcnt 2 limit 1024p flows 1024
>> > > >> quantum 1514 target 5.0ms interval 100.0ms ecn
>> > > >> Sent 12306 bytes 128 pkt (dropped 0, overlimits 0 requeues 0)
>> > > >> backlog 0b 0p requeues 0
>> > > >> maxpacket 0 drop_overlimit 0 new_flow_count 0 ecn_mark 0
>> > > >> new_flows_len 0 old_flows_len 0
>> > > >
>> > > >
>> > > > Limit of 1024 packets and 1024 flows is not wise I think.
>> > > >
>> > > > (If all buckets are in use, each bucket has a virtual queue of 1
>> > > > packet,
>> > > > which is almost the same than having no queue at all)
>> > > >
>> > > > I suggest to have at least 8 packets per bucket, to let Codel have a
>> > > > chance to trigger.
>> > > >
>> > > > So you could either reduce number of buckets to 128 (if memory is
>> > > > tight), or increase limit to 8192.
>> > >
>> > > Will try, but what I've posted is default, I didn't change/configure
>> > > that.
>> >
>> > fq_codel has a default of 10240 packets and 1024 buckets.
>> >
>> > http://lxr.free-electrons.com/source/net/sched/sch_fq_codel.c#L413
>> >
>> > If someone changed that in the linux variant you use, he probably should
>> > explain the rationale.
>
> --
> Best regards,
> Jesper Dangaard Brouer
> MSc.CS, Principal Kernel Engineer at Red Hat
> Author of http://www.iptv-analyzer.org
> LinkedIn: http://www.linkedin.com/in/brouer
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 6 May 2016 at 03:53, Luka Perkov wrote: >>On 2016-05-05 20:22, mbm wrote: >>> On 5/5/2016 7:40 AM, Felix Fietkau wrote: Many of the changes that we previously tried to introduce were often squashed by internal disagreements. Resulting discussions often turned toxic quickly and led to nothing being done to address the issues. Setting up the LEDE project was our way of creating a testbed for changes that we believe are important for the survival of the project. >>> >>> Change is not easy. Discussions need to happen. The problem is simply >>> kicking out people you didn't agree with by starting a new organization >>> in secret; you've created the public perception that we're somehow >>> against you when really we all want the same things. >> >> Years of internal discussion led nowhere. Maybe it helps now that we're >> making the whole issue public. > > For the sake of transparency, we've had public discussions, about a number of > things, for example switching to Git: > > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036390.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036480.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036486.html > - https://lists.openwrt.org/pipermail/openwrt-devel/2015-October/036500.html > > And based on these inputs from you the switch was not made even though several > OpenWrt developers wanted to switch. > > Also, server outages can happen to anybody: > - https://lists.openwrt.org/pipermail/openwrt-devel/2016-January/038547.html > > However, we do not want to point fingers. What we do want is to make a great > community around OpenWrt and to drive innovation - just like it has been done > for more then a decade now. > > There has been a long history - mostly good, sometimes bad - since the project > started from a garage project, to now having a project used by an awesome > amount of users. This can be seen from the constructive discussions in this > list on a daily basis, and in this very thread. Also, the project is used as > the main SDK by many silicon vendors internally, and by vast number of > companies on the embedded market. > > We are open for a discussion and would like to keep the OpenWrt's and it's > community interests in the first place. Splitting the project does not make > sense. Do you agree? > We appreciate your effort to have an open discussion about this, however the sudden deletion of our widely published openwrt.org email addresses somewhat undermines this. We will not respond in kind and we will continue to maintain the critical parts of OpenWrt infrastructure that we control. >>> >>> Let's be clear on this subject; no commit access was revoked, you still >>> have full read and write access to the entire OpenWrt tree. >>> >>> Email forwarding was temporarily disabled following the LEDE announcement >>> - LEDE's own rules prohibit project based email addresses >> No, they don't. They state that the LEDE project won't provide project >> email addresses. Interpreting that as meaning that we shouldn't be able >> to access our openwrt.org addresses is more than a bit of a stretch. > > In any case, due to the events that happened and the fact that the OpenWrt > name > is being used in a manner opposite of the projects best interest, we felt that > these actions were needed in order to avoid the further damages to the > project. > >>> - It's unclear if LEDE still represents OpenWrt >> So? Asking us to not send any further emails about LEDE from our >> openwrt.org addresses should have been enough. > > Actually, this was discussed on #lede-adm. IRC history is hard to follow, I'd better assume that something not written here never happened. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 20:09, Daniel Dickinson wrote: > On 16-05-05 12:59 PM, Roman Yeryomin wrote: >> On 5 May 2016 at 19:29, Daniel Dickinson >> wrote: >>> On 16-05-05 12:24 PM, Daniel Dickinson wrote: >>>> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >>>> [snip] > [snip] >>> When I say broken I mean I think openwrt was dying and I pointed out not >>> all that long ago that openwrt was in bad position and that something >>> needed to change, and I think that may have been *part* of the reason >>> accepting the status quo was no longer an acceptable answer. >> >> I don't believe that those who are in LEDE now couldn't do anything >> (that means is was dying in their hands). Actually I'm still under > > I guess the real test will be what happens going forward - if LEDE dies > for the same reasons OpenWrt was dying then that puts paid to LEDE's > story; it it succeeds then it vindicates them. I hope the problems will be resolved and we will have one project. >> impression that they controlled pretty much everything. And the part >> they didn't control (what exactly?) was only important to them. > > I have no clue about this part, I'm not exactly in the loop. I think > part of the problem has been that there is no means to add new > developers, and that suggestions for adding developers have been opposed > (that's a guess though). I don't think it was opposed. And I don't think it was a major problem. >> But I guess we will never know full story, unless both parties are >> willing to disclose all their private conversations related to >> project. > > Yeah, pretty much we're left guessing unless there is more information > given. I'm thinking the LEDE split was not like a conspiratorial split > where everything is carefully planned out and orchestrated, but more of > a rapid response (given that this isn't part of paid work for the most > of them, and even then the LEDE split wouldn't likely be part of the > job/contract) to something behind the scenes. Even if the LEDE team is > unable to post to this list, I hope they give more information using the > avenues available to them, once they get the chance to do so. Look at mailing list, commits and domain. It was all started back in March and was not disclosed. That means the plans were even earlier. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 19:29, Daniel Dickinson wrote: > On 16-05-05 12:24 PM, Daniel Dickinson wrote: >> On 16-05-05 12:21 PM, Jonathan Bennett wrote: >> [snip] >>> > The changes that the Lede guys are suggesting would be welcome, but >>> > splitting the project and community with an ugly fork is very much not >>> > welcome. >>> >>> Let's just say that there are strong personalities who haven't been >>> working well together and that this has been a long time coming; perhaps >>> if something like using a mediator had been considered before things got >>> to this point it would have helped. At this point I'm not sure >>> there is a >>> solution unless both sides are willing to bend a little (I'm really not >>> sure who has been flexible and who has not, but as I have said I suspect >>> a large part of the issue is that 'management' (who aren't and don't, >>> really) has overruled those doing the majority of the work and in an >>> open source project that doesn't fly). >>> >>> I don't disagree. I just see the current state of Openwrt/Lede as a >>> mess for the community. >> >> I agree, I just don't see how the LEDE team could have avoided it >> without giving up and accepting the broken status quo. > > When I say broken I mean I think openwrt was dying and I pointed out not > all that long ago that openwrt was in bad position and that something > needed to change, and I think that may have been *part* of the reason > accepting the status quo was no longer an acceptable answer. I don't believe that those who are in LEDE now couldn't do anything (that means is was dying in their hands). Actually I'm still under impression that they controlled pretty much everything. And the part they didn't control (what exactly?) was only important to them. But I guess we will never know full story, unless both parties are willing to disclose all their private conversations related to project. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 17:43, Daniel Dickinson wrote: > On 16-05-05 05:34 AM, Roman Yeryomin wrote: >> On 5 May 2016 at 06:48, Daniel Dickinson >> wrote: >>> On 16-05-04 04:01 PM, mbm wrote: >>>> Dear OpenWrt community, >>>> > [snip] >> >> One simple question: >> If LEDE team members are the ones who were suffering from some >> non-democratic decisions, why didn't they bring it to public >> discussion for community? At least on devel maillist? >> >> If it was clear problem in remaining OpenWrt team then LEDE would win >> the community right away or maybe problematic people would just go >> away. Either way it would be more fair and open. And this is one of my >> biggest concerns - LEDE team is promoting openness but didn't do their >> moves openly (looking at maillists it seems they were hiding it for >> month at least). Hate double standards. > > Perhaps for fear of repercussions such as what has happened since the > fork where all LEDE members @openwrt.org email addresses have been deleted? AFAIK, that was done after LEDE announcement but IMO was a wrong move anyway. > There are a number of people in the LEDE group I've found to be pretty > decent people, and great to work with, so I find it unlikely that they > simply acted without good reason. This only add more shock to the announcement. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 5 May 2016 at 13:16, John Clark wrote: >>Could you elaborate more and explain how exactly LEDE is going to fix > the listed problems? And why it's not possible to fix them inside > existing project? > > The hasty reasons given and the secret and abrupt severing of ties make me > wonder if a "follow the money" approach will yield more plausible answers to > the questions being raised. maybe a good point, how do you "follow the money"? > On Thu, May 5, 2016 at 5:34 AM, Roman Yeryomin > wrote: >> >> On 5 May 2016 at 06:48, Daniel Dickinson >> wrote: >> > On 16-05-04 04:01 PM, mbm wrote: >> >> Dear OpenWrt community, >> >> >> >> spin off the OpenWrt project in the first place as a way to fix the >> >> project and its community. Also, the phrases such as a "reboot" are >> >> both >> >> vague and misleading and the LEDE project failed to identify its true >> >> nature. The LEDE announcement contains a number of very valid points >> > >> > Can you be more specific about what you believe is LEDE's 'true nature'? >> > >> >> which we hoped we had an opportunity to discuss and attempt to fix, in >> >> a >> >> public manner, before this more radical outcome. At this point, the >> >> email as well as actions taken are very confusing to a lot of us. >> > >> > This is a guess: perhaps it is connected to the fact that Felix's >> > n...@openwrt.org address now bounces, and that actions were taken which >> > were deemed to be over-the-top by the LEDE team? Certainly there is a >> > great deal more doing on that either side is saying in public (which >> > might be just as well since there seems to be a fair amount of bad >> > feelings on both sides). >> >> One simple question: >> If LEDE team members are the ones who were suffering from some >> non-democratic decisions, why didn't they bring it to public >> discussion for community? At least on devel maillist? >> >> If it was clear problem in remaining OpenWrt team then LEDE would win >> the community right away or maybe problematic people would just go >> away. Either way it would be more fair and open. And this is one of my >> biggest concerns - LEDE team is promoting openness but didn't do their >> moves openly (looking at maillists it seems they were hiding it for >> month at least). Hate double standards. >> >> >> >> We do acknowledge there has been internal disagreements, on several >> >> occasions about some directions of the project, about the release >> >> model, >> >> the lack of testing, the centralized infrastructure, however, there >> >> have >> >> been actual work going on under the hoods to solve things one step at a >> > >> > Perhaps 'under-the-hood' is the problem. Did everyone with concerns >> > know or have insight into what steps were currently being taken and what >> > was planned, and have planned actions been followed through on, once >> > *agreed* as a solution? >> > >> > Also, is the decision making process egalitarian and democratic amongst >> > those still actively in the project, or are some 'more equal' than >> > others? >> > >> > Regards, >> > >> > Daniel >> > ___ >> > 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] Introducing the LEDE project
On 5 May 2016 at 06:48, Daniel Dickinson wrote: > On 16-05-04 04:01 PM, mbm wrote: >> Dear OpenWrt community, >> >> spin off the OpenWrt project in the first place as a way to fix the >> project and its community. Also, the phrases such as a "reboot" are both >> vague and misleading and the LEDE project failed to identify its true >> nature. The LEDE announcement contains a number of very valid points > > Can you be more specific about what you believe is LEDE's 'true nature'? > >> which we hoped we had an opportunity to discuss and attempt to fix, in a >> public manner, before this more radical outcome. At this point, the >> email as well as actions taken are very confusing to a lot of us. > > This is a guess: perhaps it is connected to the fact that Felix's > n...@openwrt.org address now bounces, and that actions were taken which > were deemed to be over-the-top by the LEDE team? Certainly there is a > great deal more doing on that either side is saying in public (which > might be just as well since there seems to be a fair amount of bad > feelings on both sides). One simple question: If LEDE team members are the ones who were suffering from some non-democratic decisions, why didn't they bring it to public discussion for community? At least on devel maillist? If it was clear problem in remaining OpenWrt team then LEDE would win the community right away or maybe problematic people would just go away. Either way it would be more fair and open. And this is one of my biggest concerns - LEDE team is promoting openness but didn't do their moves openly (looking at maillists it seems they were hiding it for month at least). Hate double standards. >> We do acknowledge there has been internal disagreements, on several >> occasions about some directions of the project, about the release model, >> the lack of testing, the centralized infrastructure, however, there have >> been actual work going on under the hoods to solve things one step at a > > Perhaps 'under-the-hood' is the problem. Did everyone with concerns > know or have insight into what steps were currently being taken and what > was planned, and have planned actions been followed through on, once > *agreed* as a solution? > > Also, is the decision making process egalitarian and democratic amongst > those still actively in the project, or are some 'more equal' than others? > > Regards, > > Daniel > ___ > 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] Introducing the LEDE project
On 4 May 2016 at 23:19, tapper wrote: > On 04/05/2016 21:01, mbm wrote: >> >> Dear OpenWrt community, >> >> It is with a great amount of surprise that, like all of you, we read >> about the announcement of the LEDE project yesterday, as there was no >> prior announcement nor clues this would happen. >> >> While we recognize the current OpenWrt project suffers from a number of >> issues outlined by Jo-Philip, in each of the 5 bullet points, we do not >> agree with the conclusions withdrawn, and even less so in deciding to >> spin off the OpenWrt project in the first place as a way to fix the >> project and its community. Also, the phrases such as a "reboot" are both >> vague and misleading and the LEDE project failed to identify its true >> nature. The LEDE announcement contains a number of very valid points >> which we hoped we had an opportunity to discuss and attempt to fix, in a >> public manner, before this more radical outcome. At this point, the >> email as well as actions taken are very confusing to a lot of us. >> >> OpenWrt is primarily developed by individuals who may have a day job >> more or less related to the purpose or the technologies of the project, >> but who strive to maintain OpenWrt as independent as possible from any >> company, organization or interest group, thus maintaining its own >> infrastructure (website, forums, mailing-lists, bugtracker...), which >> has been usually at the heart of all debates. >> >> We do acknowledge there has been internal disagreements, on several >> occasions about some directions of the project, about the release model, >> the lack of testing, the centralized infrastructure, however, there have >> been actual work going on under the hoods to solve things one step at a >> time, starting with a more decentralized infrastructure, which was >> discussed with the LEDE developers as well. >> >> At this point, we do not have much to offer to the LEDE developers but >> to encourage them to publicly discuss on >> openwrt-devel@lists.openwrt.org the different items we should all be >> fixing together, and avoid spinning off so that all decisions can be >> taken with the community's involvement, and accountability and >> transparency can rule us as one community. >> >> As a user, developer, contributor, or just community member, whatever >> choice you make, keep the choice that matters to you: the ability to >> utilize superior quality open source software to power whatever embedded >> device that matters to you! >> >> We would like to stress that we do want to have an open discussion and >> resolve matters at hand. Our goal is to work with all parties who can >> and want to contribute to OpenWrt, including the LEDE team. >> >> Sincerely, >> Your OpenWrt team >> __ > > > But just who is "Your OpenWrt team?" > After all the talk about fixing the website and the forum we as the openwrt > end users got jack shit! Even wen we offered to do things for you. > Probably one of the problems is that not all read all communication channels. I think that developers are more used to mailing list. Blaming only those who left doesn't make any sense, IMO all are responsible. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 4 May 2016 at 21:35, Luiz Angelo Daros de Luca wrote: > It is really strange that the decision to create a new project was so opaque > when it was motivated to be a more "transparent project". > They could've started to be more transparent already with the decision to > create a new project. > > Maybe the answer for the need of an external reboot might be not in the > names that jumped into but on those left behind. > Maybe it was easier to create a new project than to boot out the problems. Well, like you said yourself, why they didn't start discussing the problems (and possible solutions) in open space then? Then the reasons would be more or less clear. But now it seems that community will be confused a lot. At least I'm completely confused. > My 2 cents, > > Em qua, 4 de mai de 2016 às 14:50, Roman Yeryomin > escreveu: >> >> On 4 May 2016 at 19:25, Kathy Giori wrote: >> > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich >> > wrote: >> >> Hi, >> >> >> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> >> . >> >> >> >> The project is founded as a spin-off of the OpenWrt project and shares >> >> many of the same goals. >> > >> > While I appreciate the enthusiasm, I do not see why you cannot apply >> > these same "principles" of openness and transparency to the OpenWrt >> > project. Makes no sense to me to branch the project. That simply >> > divides the resources in the community into fewer numbers working on >> > each fork. >> >> Exactly, tearing down the project and community without any real >> explanations (and plans to solve the stated issues) is just wrong. >> >> > Also wearing my hat within the prpl Foundation, which is funded by >> > industry sponsorships that in turn provides financial support for >> > OpenWrt, no one I have spoken to in prpl understands the reason for >> > this spin-off either. It'll cause more confusion and inefficiency in >> > industry. prpl will stick with OpenWrt, and I expect most companies >> > who follow and/or contribute to OpenWrt will stick with it too. >> > >> > kathy >> > ___ >> > 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 > > -- > > Luiz Angelo Daros de Luca > luizl...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 4 May 2016 at 19:25, Kathy Giori wrote: > On Tue, May 3, 2016 at 10:59 AM, Jo-Philipp Wich wrote: >> Hi, >> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> . >> >> The project is founded as a spin-off of the OpenWrt project and shares >> many of the same goals. > > While I appreciate the enthusiasm, I do not see why you cannot apply > these same "principles" of openness and transparency to the OpenWrt > project. Makes no sense to me to branch the project. That simply > divides the resources in the community into fewer numbers working on > each fork. Exactly, tearing down the project and community without any real explanations (and plans to solve the stated issues) is just wrong. > Also wearing my hat within the prpl Foundation, which is funded by > industry sponsorships that in turn provides financial support for > OpenWrt, no one I have spoken to in prpl understands the reason for > this spin-off either. It'll cause more confusion and inefficiency in > industry. prpl will stick with OpenWrt, and I expect most companies > who follow and/or contribute to OpenWrt will stick with it too. > > kathy > ___ > 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] Introducing the LEDE project
On 4 May 2016 at 10:31, Roman Yeryomin wrote: > On 4 May 2016 at 09:13, Reinoud Koornstra wrote: >> On Tue, May 3, 2016 at 7:54 PM, Outback Dingo wrote: >>> >>> >>> On Wed, May 4, 2016 at 12:50 AM, Roman Yeryomin >>> wrote: >>>> >>>> On 3 May 2016 at 23:19, Bruno Randolf wrote: >>>> > On 03/05/16 18:59, Jo-Philipp Wich wrote: >>>> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >>>> >> ... >>>> >> Jo-Philipp Wich, >>>> >> John Crispin, >>>> >> Daniel Golle, >>>> >> Felix Fietkau, >>>> >> Hauke Mehrtens >>>> >> John Crispin >>>> >> Matthias Schiffer, >>>> >> Steven Barth >>>> > >>>> > While a fresh start and a more open process is good move, given this >>>> > list of supporters it sounds a bit ridiculous... who is left in the >>>> > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? >>> >>> >>> come on.. is this a joke? same names, same faces, if you sliced this list >>> off from the current dev group, who is actually left anyway on that >>> note, if its legit, ill jump onboard and throw my hat in the ring also due >>> to my trust and respect for those that are listed. >> >> I am kind of surprised. >> There are still daily checkins in the tree. >> Still some people are adding support for boards. >> Hence I must not understand the notion of inactiveness. >> The value of openwrt is still invaluable. >> If rebranding helps pumping additional life into it, why not... > > I'm not against rebranding but I don't see how it fixes the problem. > IMO it only makes it worse. > >>> >>>> >>>> >>>> Indeed. Looks like silent rebranding. Without public discussion of the >>>> issues (and possible ways to fix them) in mailing list Same people, >>>> rules and methods. >>>> Could you elaborate more and explain how exactly LEDE is going to fix >>>> the listed problems? And why it's not possible to fix them inside >>>> existing project? >>>> >>>> John, others, "The name LEDE stands for Linux Embedded Development Environment." sounds like build system only. I would vote for separating build system into separate project. Actually, if you remember, I was proposing this several years ago. It would make more sense and would better fit LEDE name. Though "Linux" can be subtracted from there as it's capable of building also MCU projects. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 4 May 2016 at 09:13, Reinoud Koornstra wrote: > On Tue, May 3, 2016 at 7:54 PM, Outback Dingo wrote: >> >> >> On Wed, May 4, 2016 at 12:50 AM, Roman Yeryomin >> wrote: >>> >>> On 3 May 2016 at 23:19, Bruno Randolf wrote: >>> > On 03/05/16 18:59, Jo-Philipp Wich wrote: >>> >> we'd like to introduce LEDE, a reboot of the OpenWrt community >>> >> ... >>> >> Jo-Philipp Wich, >>> >> John Crispin, >>> >> Daniel Golle, >>> >> Felix Fietkau, >>> >> Hauke Mehrtens >>> >> John Crispin >>> >> Matthias Schiffer, >>> >> Steven Barth >>> > >>> > While a fresh start and a more open process is good move, given this >>> > list of supporters it sounds a bit ridiculous... who is left in the >>> > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? >> >> >> come on.. is this a joke? same names, same faces, if you sliced this list >> off from the current dev group, who is actually left anyway on that >> note, if its legit, ill jump onboard and throw my hat in the ring also due >> to my trust and respect for those that are listed. > > I am kind of surprised. > There are still daily checkins in the tree. > Still some people are adding support for boards. > Hence I must not understand the notion of inactiveness. > The value of openwrt is still invaluable. > If rebranding helps pumping additional life into it, why not... I'm not against rebranding but I don't see how it fixes the problem. IMO it only makes it worse. >> >>> >>> >>> Indeed. Looks like silent rebranding. Without public discussion of the >>> issues (and possible ways to fix them) in mailing list Same people, >>> rules and methods. >>> Could you elaborate more and explain how exactly LEDE is going to fix >>> the listed problems? And why it's not possible to fix them inside >>> existing project? >>> >>> ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Introducing the LEDE project
On 3 May 2016 at 23:19, Bruno Randolf wrote: > On 03/05/16 18:59, Jo-Philipp Wich wrote: >> we'd like to introduce LEDE, a reboot of the OpenWrt community >> ... >> Jo-Philipp Wich, >> John Crispin, >> Daniel Golle, >> Felix Fietkau, >> Hauke Mehrtens >> John Crispin >> Matthias Schiffer, >> Steven Barth > > While a fresh start and a more open process is good move, given this > list of supporters it sounds a bit ridiculous... who is left in the > OpenWRT boat and why not do it as OpenWRT (V2 or whatever)??? Indeed. Looks like silent rebranding. Without public discussion of the issues (and possible ways to fix them) in mailing list Same people, rules and methods. Could you elaborate more and explain how exactly LEDE is going to fix the listed problems? And why it's not possible to fix them inside existing project? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] base-files: allow to set arbitrary ip address and netmask
Signed-off-by: Roman Yeryomin
---
package/base-files/files/bin/config_generate | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/package/base-files/files/bin/config_generate
b/package/base-files/files/bin/config_generate
index 4256d3c..03d1a36 100755
--- a/package/base-files/files/bin/config_generate
+++ b/package/base-files/files/bin/config_generate
@@ -56,11 +56,11 @@ generate_static_network() {
addr_offset=2
generate_network() {
- local ifname macaddr protocol type
+ local ifname macaddr protocol type ipaddr netmask
json_select network
json_select "$1"
- json_get_vars ifname macaddr protocol
+ json_get_vars ifname macaddr protocol ipaddr netmask
json_select ..
json_select ..
@@ -88,16 +88,18 @@ generate_network() {
case "$protocol" in
static)
- local ipaddr
+ local ipad
case "$1" in
- lan) ipaddr="192.168.1.1" ;;
- *) ipaddr="192.168.$((addr_offset++)).1" ;;
+ lan) ipad=${ipaddr:-"192.168.1.1"} ;;
+ *)
ipad=${ipaddr:-"192.168.$((addr_offset++)).1"} ;;
esac
+ netm=${netmask:-"255.255.255.0"}
+
uci -q batch <<-EOF
set network.$1.proto='static'
- set network.$1.ipaddr='$ipaddr'
- set network.$1.netmask='255.255.255.0'
+ set network.$1.ipaddr='$ipad'
+ set network.$1.netmask='$netm'
set network.$1.ip6assign='60'
EOF
;;
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 5/5] ramips: mt7621: fix Ubiquiti EdgeRouter X profile
Remove unnecessary packages to reduce image size so it fits in initramfs (to enable upgrading from factory firmware). Signed-off-by: Roman Yeryomin --- target/linux/ramips/mt7621/profiles/ubnt.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/ramips/mt7621/profiles/ubnt.mk b/target/linux/ramips/mt7621/profiles/ubnt.mk index b66b206..3f1af02 100644 --- a/target/linux/ramips/mt7621/profiles/ubnt.mk +++ b/target/linux/ramips/mt7621/profiles/ubnt.mk @@ -8,7 +8,8 @@ define Profile/UBNT-ERX NAME:=Ubiquiti EdgeRouter X FEATURES+=nand -usb - PACKAGES:=-kmod-mt76 -wpad-mini -kmod-cfg80211 + PACKAGES:=-kmod-mt76 -kmod-rt2800-pci -kmod-cfg80211 \ + -wpad-mini -iwinfo endef define Profile/UBNT-ERX/Description -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 4/5] ramips: mt7621: sync MQmaker WiTi profile name to dts name
Signed-off-by: Roman Yeryomin --- target/linux/ramips/mt7621/profiles/mqmaker.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/target/linux/ramips/mt7621/profiles/mqmaker.mk b/target/linux/ramips/mt7621/profiles/mqmaker.mk index ae35e7d..a9c79df 100644 --- a/target/linux/ramips/mt7621/profiles/mqmaker.mk +++ b/target/linux/ramips/mt7621/profiles/mqmaker.mk @@ -5,7 +5,7 @@ # See /LICENSE for more information. # -define Profile/witi +define Profile/WITI NAME:=MQmaker WiTi FEATURES+=rtc PACKAGES:=\ @@ -14,7 +14,7 @@ define Profile/witi kmod-rtc-pcf8563 kmod-i2c-mt7621 endef -define Profile/witi/Description +define Profile/WITI/Description Package set compatible with MQmaker WiTi board. endef -$(eval $(call Profile,witi)) +$(eval $(call Profile,WITI)) -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/5] ramips: enable device profiling by dts
Signed-off-by: Roman Yeryomin --- target/linux/ramips/image/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ramips/image/Makefile b/target/linux/ramips/image/Makefile index ddd67a2..6e0349f 100644 --- a/target/linux/ramips/image/Makefile +++ b/target/linux/ramips/image/Makefile @@ -32,6 +32,7 @@ KERNEL_LOADADDR := $(loadaddr-y) KERNEL_DTB = kernel-bin | patch-dtb | lzma define Device/Default + PROFILES = Default $$(DTS) KERNEL_DEPENDS = $$(wildcard ../dts/$$(DTS).dts) KERNEL := $(KERNEL_DTB) | uImage lzma IMAGES := sysupgrade.bin -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/5] ramips: mt7621: add a device to TARGET_DEVICES after it's definition
Signed-off-by: Roman Yeryomin --- target/linux/ramips/image/mt7621.mk | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/target/linux/ramips/image/mt7621.mk b/target/linux/ramips/image/mt7621.mk index 76b4e48..628954f 100644 --- a/target/linux/ramips/image/mt7621.mk +++ b/target/linux/ramips/image/mt7621.mk @@ -33,29 +33,29 @@ define Build/ubnt-erx-factory-image fi endef -ifeq ($(SUBTARGET),mt7621) - TARGET_DEVICES += mt7621 wsr-600 wsr-1166 dir-860l-b1 firewrt pbr-m1 re6500 sap-g3200u3 ubnt-erx witi wf-2881 zbt-wg2626 -endif - define Device/mt7621 DTS := MT7621 IMAGE_SIZE := $(ralink_default_fw_size_4M) endef +TARGET_DEVICES += mt7621 define Device/wsr-600 DTS := WSR-600 IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += wsr-600 define Device/re6500 DTS := RE6500 endef +TARGET_DEVICES += re6500 define Device/wsr-1166 DTS := WSR-1166 IMAGE/sysupgrade.bin := trx | pad-rootfs IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += wsr-1166 define Device/dir-860l-b1 DTS := DIR-860L-B1 @@ -71,30 +71,36 @@ define Device/dir-860l-b1 seama-seal -m "signature=wrgac13_dlink.2013gui_dir860lb" | \ check-size (IMAGE_SIZE) endef +TARGET_DEVICES += dir-860l-b1 define Device/firewrt DTS := FIREWRT IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += firewrt define Device/pbr-m1 DTS := PBR-M1 IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += pbr-m1 define Device/sap-g3200u3 DTS := SAP-G3200U3 endef +TARGET_DEVICES += sap-g3200u3 define Device/witi DTS := WITI IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += witi define Device/zbt-wg2626 DTS := ZBT-WG2626 IMAGE_SIZE := $(ralink_default_fw_size_16M) endef +TARGET_DEVICES += zbt-wg2626 define Device/wf-2881 DTS := WF-2881 @@ -105,6 +111,7 @@ define Device/wf-2881 KERNEL := $(KERNEL_DTB) | pad-offset 131072 64 | uImage lzma IMAGE/sysupgrade.bin := append-kernel | append-ubi | check-size (IMAGE_SIZE) endef +TARGET_DEVICES += wf-2881 define Device/ubnt-erx DTS := UBNT-ERX @@ -116,6 +123,7 @@ define Device/ubnt-erx ubnt-erx-factory-image $(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar IMAGE/sysupgrade.tar := sysupgrade-nand endef +TARGET_DEVICES += ubnt-erx # FIXME: is this still needed? define Image/Prepare -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/5] ramips: mt7621: fix initramfs image for ubnt-erx
Signed-off-by: Roman Yeryomin
---
target/linux/ramips/image/mt7621.mk | 66 +++--
1 file changed, 20 insertions(+), 46 deletions(-)
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index 745611f..76b4e48 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -11,51 +11,28 @@ define Build/seama-seal
$(call Build/seama,-s $@.seama $(1))
endef
-define Build/ubnt-erx-factory-compat
- echo '21001:6' > $@.compat
- $(TAR) -cf $@ --transform='s/^.*/compat/' $@.compat
- $(RM) $@.compat
-endef
-
-define Build/ubnt-erx-factory-kernel
+define Build/ubnt-erx-factory-image
if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) ]; then \
- $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp/'
$(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE); \
+ echo '21001:6' > $(1).compat; \
+ $(TAR) -cf $(1) --transform='s/^.*/compat/' $(1).compat; \
+ \
+ $(TAR) -rf $(1) --transform='s/^.*/vmlinux.tmp/'
$(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE); \
+ md5sum --binary $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) | awk
'{print $$1}'> $(1).md5; \
+ $(TAR) -rf $(1) --transform='s/^.*/vmlinux.tmp.md5/' $(1).md5; \
+ \
+ echo "dummy" > $(1).rootfs; \
+ $(TAR) -rf $(1) --transform='s/^.*/squashfs.tmp/' $(1).rootfs; \
\
- md5sum --binary $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) | awk
'{print $$1}'> $@.md5; \
- $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp.md5/' $@.md5; \
- $(RM) $@.md5; \
+ md5sum --binary $(1).rootfs | awk '{print $$1}'> $(1).md5; \
+ $(TAR) -rf $(1) --transform='s/^.*/squashfs.tmp.md5/' $(1).md5;
\
+ \
+ echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' >
$(1).version; \
+ $(TAR) -rf $(1) --transform='s/^.*/version.tmp/' $(1).version; \
+ \
+ $(CP) $(1) $(BIN_DIR)/; \
fi
endef
-define Build/ubnt-erx-factory-rootfs
- echo "dummy" > $@.rootfs
- $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp/' $@.rootfs
-
- md5sum --binary $@.rootfs | awk '{print $$1}'> $@.md5
- $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp.md5/' $@.md5
- $(RM) $@.md5
- $(RM) $@.rootfs
-endef
-
-define Build/ubnt-erx-factory-version
- echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' > $@.version
- $(TAR) -rf $@ --transform='s/^.*/version.tmp/' $@.version
- $(RM) $@.version
-endef
-
-# We need kernel+initrams fit into kernel partition
-define Build/ubnt-erx-factory-check-size
- @[ $$(($(subst k,* 1024,$(subst m, * 1024k,$(1) -ge "$$($(TAR) -xf
$@ vmlinux.tmp -O | wc -c)" ] || { \
- echo "WARNING: Initramfs kernel for image $@ is too big (kernel
size: $$($(TAR) -xf $@ vmlinux.tmp -O | wc -c), max size $(1))" >&2; \
- $(RM) -f $@; \
- }
-
- @[ "$$($(TAR) -xf $@ vmlinux.tmp -O | wc -c)" -gt 0 ] || { \
- echo "WARNING: Kernel for image $@ not found" >&2; \
- $(RM) -f $@; \
- }
-endef
-
ifeq ($(SUBTARGET),mt7621)
TARGET_DEVICES += mt7621 wsr-600 wsr-1166 dir-860l-b1 firewrt pbr-m1 re6500
sap-g3200u3 ubnt-erx witi wf-2881 zbt-wg2626
endif
@@ -134,12 +111,9 @@ define Device/ubnt-erx
FILESYSTEMS := squashfs
KERNEL_SIZE := 3145728
KERNEL := $(KERNEL_DTB) | uImage lzma
- IMAGES := sysupgrade.tar $(if
$(CONFIG_TARGET_ROOTFS_INITRAMFS),factory-initramfs.tar)
- IMAGE/factory-initramfs.tar := ubnt-erx-factory-compat | \
-ubnt-erx-factory-kernel | \
-ubnt-erx-factory-rootfs | \
-ubnt-erx-factory-version | \
-ubnt-erx-factory-check-size $$(KERNEL_SIZE)
+ IMAGES := sysupgrade.tar
+ KERNEL_INITRAMFS := $$(KERNEL) | check-size $$(KERNEL_SIZE) | \
+ ubnt-erx-factory-image
$(KDIR)/tmp/$$(KERNEL_INITRAMFS_PREFIX)-factory.tar
IMAGE/sysupgrade.tar := sysupgrade-nand
endef
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: move different subtarget image generation to separate makefiles to improve maintainability
- all subtarget specific defines are in their own files
- common defines left in main Makefile
- each subtarget makefile idefed with SUBTARGET
- all subtargets compile tested
- few seems to be broken/unneeded things marked with FIXME
Signed-off-by: Roman Yeryomin
---
target/linux/ramips/image/Makefile | 949 +---
target/linux/ramips/image/mt7620.mk | 160 ++
target/linux/ramips/image/mt7621.mk | 153 ++
target/linux/ramips/image/mt7628.mk | 17 +
target/linux/ramips/image/mt7688.mk | 11 +
target/linux/ramips/image/rt288x.mk | 59 +++
target/linux/ramips/image/rt305x.mk | 392 +++
target/linux/ramips/image/rt3883.mk | 59 +++
8 files changed, 865 insertions(+), 935 deletions(-)
create mode 100644 target/linux/ramips/image/mt7620.mk
create mode 100644 target/linux/ramips/image/mt7621.mk
create mode 100644 target/linux/ramips/image/mt7628.mk
create mode 100644 target/linux/ramips/image/mt7688.mk
create mode 100644 target/linux/ramips/image/rt288x.mk
create mode 100644 target/linux/ramips/image/rt305x.mk
create mode 100644 target/linux/ramips/image/rt3883.mk
diff --git a/target/linux/ramips/image/Makefile
b/target/linux/ramips/image/Makefile
index 0cfb8fb..ddd67a2 100644
--- a/target/linux/ramips/image/Makefile
+++ b/target/linux/ramips/image/Makefile
@@ -52,15 +52,6 @@ define Build/trx
-a 4 -f $(word 2,$^)
endef
-define Build/seama
- $(STAGING_DIR_HOST)/bin/seama -i $@ $(1)
- mv $@.seama $@
-endef
-
-define Build/seama-seal
- $(call Build/seama,-s $@.seama $(1))
-endef
-
define Build/relocate-kernel
( \
dd if=$(KDIR)/loader.bin bs=32 conv=sync && \
@@ -70,51 +61,6 @@ define Build/relocate-kernel
mv $@.new $@
endef
-define Build/ubnt-erx-factory-compat
- echo '21001:6' > $@.compat
- $(TAR) -cf $@ --transform='s/^.*/compat/' $@.compat
- $(RM) $@.compat
-endef
-
-define Build/ubnt-erx-factory-kernel
- if [ -e $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) ]; then \
- $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp/'
$(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE); \
- \
- md5sum --binary $(KDIR)/tmp/$(KERNEL_INITRAMFS_IMAGE) | awk
'{print $$1}'> $@.md5; \
- $(TAR) -rf $@ --transform='s/^.*/vmlinux.tmp.md5/' $@.md5; \
- $(RM) $@.md5; \
- fi
-endef
-
-define Build/ubnt-erx-factory-rootfs
- echo "dummy" > $@.rootfs
- $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp/' $@.rootfs
-
- md5sum --binary $@.rootfs | awk '{print $$1}'> $@.md5
- $(TAR) -rf $@ --transform='s/^.*/squashfs.tmp.md5/' $@.md5
- $(RM) $@.md5
- $(RM) $@.rootfs
-endef
-
-define Build/ubnt-erx-factory-version
- echo '$(BOARD) $(VERSION_CODE) $(VERSION_NUMBER)' > $@.version
- $(TAR) -rf $@ --transform='s/^.*/version.tmp/' $@.version
- $(RM) $@.version
-endef
-
-#We need kernel+initrams fit into kernel partition
-define Build/ubnt-erx-factory-check-size
- @[ $$(($(subst k,* 1024,$(subst m, * 1024k,$(1) -ge "$$($(TAR) -xf
$@ vmlinux.tmp -O | wc -c)" ] || { \
- echo "WARNING: Initramfs kernel for image $@ is too big (kernel
size: $$($(TAR) -xf $@ vmlinux.tmp -O | wc -c), max size $(1))" >&2; \
- $(RM) -f $@; \
- }
-
- @[ "$$($(TAR) -xf $@ vmlinux.tmp -O | wc -c)" -gt 0 ] || { \
- echo "WARNING: Kernel for image $@ not found" >&2; \
- $(RM) -f $@; \
- }
-endef
-
define MkCombineduImage
$(call PatchKernelLzma,$(2),$(3))
if [ `stat -c%s "$(KDIR)/vmlinux-$(2).bin.lzma"` -gt `expr $(4) - 64`
]; then \
@@ -127,7 +73,6 @@ define MkCombineduImage
$(call MkImage,lzma,$(KDIR)/vmlinux-$(2).bin.lzma.combined,$(call
sysupname,$(1),$(2)),$(6))
endef
-
#
# The real magic happens inside these templates
#
@@ -156,23 +101,6 @@ define MkImageSysupgrade/squashfs
fi
endef
-define MkImageTpl/squashfs
- $(eval output_name=$(IMG_PREFIX)-$(2)-$(1)-$(if
$(4),$(4),sysupgrade).bin)
- -$(STAGING_DIR_HOST)/bin/mktplinkfw2 -V "ver. 2.0" -B "$(2)" -j \
- -o $(KDIR)/$(output_name) \
- -k $(KDIR)/vmlinux-$(1)$(4).bin.lzma \
- -r $(KDIR)/root.$(1) && \
- $(CP) $(KDIR)/$(output_name) $(BIN_DIR)/$(output_name)
-endef
-
-define MkImageTpl/initramfs
- $(eval output_name=$(IMG_PREFIX)-$(2)-$(1).bin)
- -$(STAGING_DIR_HOST)/bin/mktplinkfw2 -V "ver. 2.0" -B "$(2)" -c \
- -o $(KDIR)/$(output_name) \
- -k $(KDIR)/vmlinux-$(1).bin.lzma && \
- $(CP) $(KDIR)/$(output_name) $(BIN_DIR)/$(output_name)
-endef
-
# $(1), lowerca
Re: [OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago
On 18 March 2016 at 15:32, John Crispin wrote: >> >> please use this svn server for now. it will be online for 4-6 weeks so >> that people have time to migrate away from svn. i will send out a notice >> 1 week before we finally turn it of. please start migrating now. > > if you do 10 things at once you forget to paste the url :-) > > svn://svn.mein.io/openwrt John, you just made people suffer for 4-6 weeks longer :) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago
On 18 March 2016 at 19:36, John Crispin wrote: > > > On 18/03/2016 18:19, Roman Yeryomin wrote: >> On 18 March 2016 at 15:32, John Crispin wrote: >>>> >>>> please use this svn server for now. it will be online for 4-6 weeks so >>>> that people have time to migrate away from svn. i will send out a notice >>>> 1 week before we finally turn it of. please start migrating now. >>> >>> if you do 10 things at once you forget to paste the url :-) >>> >>> svn://svn.mein.io/openwrt >> >> John, you just made people suffer for 4-6 weeks longer :) >> > > > i think you are mistaken, think before you post please. Sorry, maybe it was way too sarcastic but IMO switching from svn to git is fairly simple and there is nothing to dramatize. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Read-only mirror https://github.com/openwrt/openwrt is stuck since 12 days ago
On 18 March 2016 at 04:40, Shankar Unni wrote: > On Wed, Mar 16, 2016 at 1:53 AM, Karl Vogel wrote: >> >> Doesn't look like the SVN server is back yet either. >> >> Are there any plans to resurrect the anon SVN server? Or should everybody >> move to git.openwrt.org instead? >> > > Yeah, I've been waiting for this, too (svn.openwrt.org). > > It would be good to hear an official word from someone as to whether > this is ever going to come back up (i.e. is this only a delay?), or is > it a final decision to turn it off for good. It's dead, Jim. Just switch and free yourself. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] fstools/overlayfs race condition
On 7 March 2016 at 15:09, John Crispin wrote: > > > On 07/03/2016 14:03, Roman Yeryomin wrote: >> There is a race between `cp -a /tmp/root/* /rom/overlay` from >> libfstools/overlay.c and a process creating new file(s) before >> pivot(/rom, /mnt) occured. >> That is a process can create a file and it will not be copied. >> >> Currently I do additional copy after jffs2 is ready, which is kind of >> cumbersome (see attached patch), but there are still few potentially >> erroneous scenarios: >> 1. a process may recreate the file by the time second cp occurs >> 2. a process may delete a file (not existing at that moment) and >> second cp will copy it again >> 3. a process may want to read created file before second cp occurs >> >> If attached patch is the way to go I will properly submit it. >> Otherwise there should be a more fundamental fix but I don't see a way >> to fix this properly. >> >> > > Hi Roman > > that race has been there since the day we do overlayfs. i am always > surprised that it has not exploded in a big way yet. the only way i see > are workarounds such as yours or sending out lots of SIGSTOP and the > continues when we copied the files. either way it will be ugly and > require protective gear. > > i'll ponder this and see if we can find a better way Actually I met this long ago, just didn't understand/investigate it was exactly this. What will happen if a process opens a file (t.i. it will have an open descriptor) in tmp root, writes to it and then, in the process of writing, pivot_root() executes? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC] fstools/overlayfs race condition
There is a race between `cp -a /tmp/root/* /rom/overlay` from
libfstools/overlay.c and a process creating new file(s) before
pivot(/rom, /mnt) occured.
That is a process can create a file and it will not be copied.
Currently I do additional copy after jffs2 is ready, which is kind of
cumbersome (see attached patch), but there are still few potentially
erroneous scenarios:
1. a process may recreate the file by the time second cp occurs
2. a process may delete a file (not existing at that moment) and
second cp will copy it again
3. a process may want to read created file before second cp occurs
If attached patch is the way to go I will properly submit it.
Otherwise there should be a more fundamental fix but I don't see a way
to fix this properly.
Regards,
Roman
--- a/libfstools/overlay.c
+++ b/libfstools/overlay.c
@@ -223,6 +223,9 @@ jffs2_switch(struct volume *v)
ULOG_INFO("performing overlay whiteout\n");
umount2("/tmp/root", MNT_DETACH);
foreachdir("/overlay/", handle_whiteout);
+ /* try hard to be in sync */
+ ULOG_INFO("syncronizing overlay\n");
+ system("cp -a /tmp/root/upper/* / 2>/dev/null");
}
break;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] New Ubiquiti AC products locked against 3rd party firmware?
https://github.com/openwrt/openwrt/commit/de350dcae493b2b71a0850b1d1d4ee0483552faa On 22 February 2016 at 14:05, valent.turko...@gmail.com wrote: > Nice that you checked... I would understand this stance from a company > that doesn't rely on so much open source software without which they > wouldn't even exists. Shame, just shame. > > On 30 November 2015 at 09:48, John Crispin wrote: >> >> >> On 30/11/2015 09:38, Petr Štetiar wrote: >>> Ben West [2015-11-27 10:00:51]: >>> >>> Hi, >>> This person is reporting a new Ubiquiti AC AP where there the bootloader does an RSA signature check on the firmware image. >>> >>> let's hope, that it would be possible to replace/patch that unfriendly >>> U-Boot. >>> Could anyone else confirm if they've observed the same, and if it now prevents loading OpenWRT, etc? Or at least, confirm if the RSA signature checking by the bootloader was not present before? >>> >>> We're using UBNT products and I can confirm, that there wasn't any RSA >>> firmware signature checking previously and we're able to run OpenWRT on >>> them. >>> Maybe it's time to look around for alternatives... >>> >>> -- ynezz >>> >> >> >> Hi, >> >> i contacted UBNT customer support. they specifically stated that they do >> not want users to install openwrt and prefer not to cooperate with us. >> it is a concious decision to *not* support the free software movement >> and be capitalist pigs. the reasoning given to me was not related to FCC >> ruling but specifically stated that they dont like users installing free >> software on their routers. they prefer to have submissive users that >> will do as they are told. >> >> John >> >> -- Forwarded message -- From: Andrew Margarit | Cucumber WiFI Date: Fri, Nov 27, 2015 at 7:59 AM Subject: Re: [FCC] New AP with the lockdown To: f...@lists.prplfoundation.org Hi there, Just to let you know, I've been looking at the Ubiquiti new AC APs, and it looks like they added a RSA check in the bootloader. Firmware Version: BZ.qca956x.v3.4.7.3284.150911.1650 RSA Signed Firmware. Verfiying please wait... Decrypted hash: f8 2b 45 72 9f e4 5f 46 a0 96 43 37 57 4f 49 ab 43 dc 1e 8c Image hash: f8 2b 45 72 9f e4 5f 46 a0 96 43 37 57 4f 49 ab 43 dc 1e 8c All fun and good! -- Andrew Margarit Wi-FI Chief | Cucumber Tony and...@polkaspots.com cucumberwifi.io twitter/cucumbertony ___ FCC mailing list f...@lists.prplfoundation.org http://lists.prplfoundation.org/cgi-bin/mailman/listinfo/fcc -- Ben West http://gowasabi.net b...@gowasabi.net 314-246-9434 ___ 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
Re: [OpenWrt-Devel] [PATCH] brcm2708: fix RPi model B plus support
On 17 January 2016 at 13:15, Felix Fietkau wrote:
> On 2016-01-10 00:13, Roman Yeryomin wrote:
>> Not sure if B+ is used or not (mine has B Plus) so leave both
>>
>> Signed-off-by: Roman Yeryomin
>> ---
>> target/linux/brcm2708/base-files/lib/brcm2708.sh | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/target/linux/brcm2708/base-files/lib/brcm2708.sh
>> b/target/linux/brcm2708/base-files/lib/brcm2708.sh
>> index 13c1aa9..cb4089d 100644
>> --- a/target/linux/brcm2708/base-files/lib/brcm2708.sh
>> +++ b/target/linux/brcm2708/base-files/lib/brcm2708.sh
>> @@ -11,6 +11,7 @@ brcm2708_detect() {
>> "Raspberry Pi Model B Rev"*)
>> board_name="rpi-b"
>> ;;
>> + "Raspberry Pi Model B Plus Rev"* |\
>> "Raspberry Pi Model B+ Rev"*)
> Why would it have "B Plus" instead of "B+"? I only see "B+" in the
> kernel .dts file.
Didn't investigate the exact reason
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: Mark broken; no working images
On 14 January 2016 at 18:25, Daniel Dickinson wrote: > Ah, ok, so there likley there are are pobablly not any working *stock* > devices. That merits the @BROKEN flag - if you're running modified hardware > you can surely build with BROKEN enabled. https://downloads.openwrt.org/snapshots/trunk/brcm47xx/ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] brcm47xx: Mark broken; no working images
On 14 January 2016 at 17:31, wrote: > From: Daniel Dickinson > > To my knowledge there are no working images, nor a way to get them, > even using maximum stripping and dropping of packages, kmods, and > compile options due to the small size of the targets for this > architecture. Therefore mark this arch broken and maybe remove > unless someone decides to fix it. > > Signed-off-by: Daniel Dickinson > --- > target/linux/brcm47xx/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/target/linux/brcm47xx/Makefile b/target/linux/brcm47xx/Makefile > index e0c44c8..fae1f59 100644 > --- a/target/linux/brcm47xx/Makefile > +++ b/target/linux/brcm47xx/Makefile > @@ -12,6 +12,7 @@ BOARDNAME:=Broadcom BCM47xx/53xx (MIPS) > FEATURES:=squashfs usb > SUBTARGETS:=generic mips74k legacy > MAINTAINER:=Hauke Mehrtens > +DEPENDS:=@BROKEN > > KERNEL_PATCHVER:=4.1 > m? at least Asus rt-n16 and wl-500gp work fine! Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] optimizing network performance
On 9 January 2016 at 17:21, Roman Yeryomin wrote: > While trying to optimize ag71xx driver performance I've noticed a > weird thing: NAT performance may vary across reboots. > For example on Archer C7 the difference can be 80Mbps: 440 one boot, > 360 another. On AP152 the numbers differ but the difference across > reboots still present. > That is with iperf3, TCP download, 1m average, confirmed environment, > trunk version. > > Did someone notice this before? Is this driver specific? MIPS > specific? Something else? > > Unfortunately I don't have any other board with gigabit ports I can > test with currently. > Such behavior makes it very hard to test any optimizations. > Really? nobody noticed this? Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] brcm2708: fix RPi model B plus support
Not sure if B+ is used or not (mine has B Plus) so leave both
Signed-off-by: Roman Yeryomin
---
target/linux/brcm2708/base-files/lib/brcm2708.sh | 1 +
1 file changed, 1 insertion(+)
diff --git a/target/linux/brcm2708/base-files/lib/brcm2708.sh
b/target/linux/brcm2708/base-files/lib/brcm2708.sh
index 13c1aa9..cb4089d 100644
--- a/target/linux/brcm2708/base-files/lib/brcm2708.sh
+++ b/target/linux/brcm2708/base-files/lib/brcm2708.sh
@@ -11,6 +11,7 @@ brcm2708_detect() {
"Raspberry Pi Model B Rev"*)
board_name="rpi-b"
;;
+ "Raspberry Pi Model B Plus Rev"* |\
"Raspberry Pi Model B+ Rev"*)
board_name="rpi-b-plus"
;;
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ar71xx: fix ap152 support
- ethernet gigabit pll
- switch configuration
- sysupgrade
Signed-off-by: Roman Yeryomin
---
target/linux/ar71xx/base-files/etc/board.d/02_network | 1 +
target/linux/ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/files/arch/mips/ath79/mach-ap152.c | 1 -
3 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/target/linux/ar71xx/base-files/etc/board.d/02_network
b/target/linux/ar71xx/base-files/etc/board.d/02_network
index 6b6c6a4..190b693 100755
--- a/target/linux/ar71xx/base-files/etc/board.d/02_network
+++ b/target/linux/ar71xx/base-files/etc/board.d/02_network
@@ -23,6 +23,7 @@ ubnt-unifi-outdoor)
;;
ap132 |\
+ap152 |\
wlr8100)
ucidef_add_switch "switch0" \
"0@eth0" "2:lan" "3:lan" "4:lan" "5:lan" "1:wan"
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
index e662524..1f6eaf2 100755
--- a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
@@ -184,6 +184,7 @@ platform_check_image() {
ap136-020 | \
ap135-020 | \
ap147-010 | \
+ ap152 | \
ap96 | \
bxu2000n-2-a1 | \
db120 | \
diff --git a/target/linux/ar71xx/files/arch/mips/ath79/mach-ap152.c
b/target/linux/ar71xx/files/arch/mips/ath79/mach-ap152.c
index a1eb06b..e669325 100644
--- a/target/linux/ar71xx/files/arch/mips/ath79/mach-ap152.c
+++ b/target/linux/ar71xx/files/arch/mips/ath79/mach-ap152.c
@@ -132,7 +132,6 @@ static void __init ap152_setup(void)
ath79_eth0_data.duplex = DUPLEX_FULL;
ath79_eth0_data.phy_mask = BIT(0);
ath79_eth0_data.mii_bus_dev = &ath79_mdio0_device.dev;
- ath79_eth0_pll_data.pll_1000 = 0x0600;
ath79_register_eth(0);
}
--
2.5.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] optimizing network performance
While trying to optimize ag71xx driver performance I've noticed a weird thing: NAT performance may vary across reboots. For example on Archer C7 the difference can be 80Mbps: 440 one boot, 360 another. On AP152 the numbers differ but the difference across reboots still present. That is with iperf3, TCP download, 1m average, confirmed environment, trunk version. Did someone notice this before? Is this driver specific? MIPS specific? Something else? Unfortunately I don't have any other board with gigabit ports I can test with currently. Such behavior makes it very hard to test any optimizations. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: fix generating network configuration
On 30 December 2015 at 14:32, Yousong Zhou wrote: > On 30 December 2015 at 20:12, Jo-Philipp Wich wrote: >> Hi Yousong. >> >> NAK - thats by design. If a network config is present then there is no >> point in regenerating it. >> >> I'd prefer if the Malta target would simply drop its default config and >> switch to board.d, this could be useful to e.g. dynamically handle >> different amounts of eth* devices: >> > > The default network config was provided by package/base-files, not > malta target... You can easily override it, no need to modify defaults. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: generic 4.1 & 4.4 perf: musl compatibility
On 29 December 2015 at 12:14, Kevin Darbyshire-Bryant
wrote:
> Enable linux perf tools to compile under musl.
>
> Tested on MIPS Archer c7 v2 & ARM Linksys 1200ac.
>
> With thanks to Dave Taht who
> did the heavy lifting.
>
> Signed-off-by: Kevin Darbyshire-Bryant
> ---
> package/devel/perf/Makefile| 2 +-
> .../patches-4.1/280-perf-fixes-for-musl.patch | 148
> +
> .../patches-4.4/280-perf-fixes-for-musl.patch | 147
> 3 files changed, 296 insertions(+), 1 deletion(-)
> create mode 100644
> target/linux/generic/patches-4.1/280-perf-fixes-for-musl.patch
> create mode 100644
> target/linux/generic/patches-4.4/280-perf-fixes-for-musl.patch
>
> diff --git a/package/devel/perf/Makefile b/package/devel/perf/Makefile
> index 5e3d63f..46ddb92 100644
> --- a/package/devel/perf/Makefile
> +++ b/package/devel/perf/Makefile
> @@ -19,7 +19,7 @@ include $(INCLUDE_DIR)/package.mk
> define Package/perf
>SECTION:=devel
>CATEGORY:=Development
> - DEPENDS:= @USE_GLIBC +libelf1 +libdw +libpthread +librt +binutils
> + DEPENDS:= @USE_MUSL +libelf1 +libdw +libpthread +librt +binutils
>TITLE:=Linux performance monitoring tool
>VERSION:=$(LINUX_VERSION)-$(PKG_RELEASE)
>URL:=http://www.kernel.org
> diff --git a/target/linux/generic/patches-4.1/280-perf-fixes-for-musl.patch
> b/target/linux/generic/patches-4.1/280-perf-fixes-for-musl.patch
> new file mode 100644
> index 000..0e8b6d8
> --- /dev/null
> +++ b/target/linux/generic/patches-4.1/280-perf-fixes-for-musl.patch
> @@ -0,0 +1,148 @@
> +kernel: 4.1 perf: musl compatibility
> +
> +Allow linux perf tool to compile under musl.
> +
> +Backport to 4.1 by Kevin D-B with thanks to Dave
> +Taht for the heavy lifting.
> +
> +Signed-off-by: Kevin Darbyshire-Bryant
> +
> +---
> + tools/lib/api/fs/debugfs.c | 4
> + tools/lib/traceevent/event-parse.c | 4
> + tools/perf/perf.c | 17 -
> + tools/perf/util/cache.h| 2 +-
> + tools/perf/util/cloexec.c | 4
> + tools/perf/util/cloexec.h | 4
> + tools/perf/util/util.h | 4
> + 7 files changed, 29 insertions(+), 10 deletions(-)
> +
> +diff --git a/tools/lib/api/fs/debugfs.c b/tools/lib/api/fs/debugfs.c
> +index 8305b3e..5d1745c 100644
> +--- a/tools/lib/api/fs/debugfs.c
> b/tools/lib/api/fs/debugfs.c
> +@@ -17,6 +17,10 @@
> + #define DEBUGFS_DEFAULT_PATH "/sys/kernel/debug"
> + #endif
> +
> ++/* musl has a xpg compliant strerror_r by default */
> ++#define strerror_r(err, buf, buflen) \
> ++ (strerror_r(err, buf, buflen) ? NULL : buf)
> ++
> + char debugfs_mountpoint[PATH_MAX + 1] = DEBUGFS_DEFAULT_PATH;
> +
> + static const char * const debugfs_known_mountpoints[] = {
> +diff --git a/tools/lib/traceevent/event-parse.c
> b/tools/lib/traceevent/event-parse.c
> +index ed5461f..f151369 100644
> +--- a/tools/lib/traceevent/event-parse.c
> b/tools/lib/traceevent/event-parse.c
> +@@ -36,6 +36,10 @@
> + #include "event-parse.h"
> + #include "event-utils.h"
> +
> ++/* musl has a xpg compliant strerror_r by default */
> ++#define strerror_r(err, buf, buflen) \
> ++(strerror_r(err, buf, buflen) ? NULL : buf)
> ++
> + static const char *input_buf;
> + static unsigned long long input_buf_ptr;
> + static unsigned long long input_buf_siz;
> +diff --git a/tools/perf/perf.c b/tools/perf/perf.c
> +index b857fcb..3e67fa2 100644
> +--- a/tools/perf/perf.c
> b/tools/perf/perf.c
> +@@ -505,6 +505,21 @@ void pthread__unblock_sigwinch(void)
> + pthread_sigmask(SIG_UNBLOCK, &set, NULL);
> + }
> +
> ++unsigned cache_line_size(void);
> ++
> ++unsigned cache_line_size(void) {
> ++ FILE * p = 0;
> ++ unsigned int i = 0;
> ++ p =
> fopen("/sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size", "r");
> ++ if (p) {
> ++ if(fscanf(p, "%d", &i) != 1) {
> ++ perror("cannot determine cache line size");
> ++ }
> ++ fclose(p);
> ++ }
> ++ return i;
> ++}
> ++
Kevin, are you sure this works?
I don't have /sys/devices/system/cpu/cpu0/cache/index0/coherency_line_size
on my Archer C7
I did a little bit more simple way adding a header from eglibc. If
anybody interested I can submit the patch for RFC.
Regards,
Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/3] ar71xx: add support for QCA956x ethernet
On 22 December 2015 at 01:03, wrote: > > Hi Roman, > > are you sure about the value of QCA956X_PLL_VAL_10, > which is 0x1919 in your patch? > > At least for the UAPAC LITE I have the problem that packet transmission > on 10MBit/s links does not work with 0x1919. > Instead, with QCA956X_PLL_VAL_10 = 0x1313 everything is fine. > > Is this specific to the UAPAC LITE or the QCA9563? Honestly I don't remember where it comes from, Possibly from codeaurora repo. So no, I'm not sure. But still it can be overriden from board file. Sorry didn't bother testing with 10Mbit links :) Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] rb532: switch to 4.1
Signed-off-by: Roman Yeryomin --- target/linux/rb532/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/rb532/Makefile b/target/linux/rb532/Makefile index 3086462..9033eb4 100644 --- a/target/linux/rb532/Makefile +++ b/target/linux/rb532/Makefile @@ -11,7 +11,7 @@ BOARD:=rb532 BOARDNAME:=Mikrotik RouterBoard 532 FEATURES:=pci targz squashfs -KERNEL_PATCHVER:=3.18 +KERNEL_PATCHVER:=4.1 include $(INCLUDE_DIR)/target.mk DEFAULT_PACKAGES += wpad-mini kmod-ath5k kmod-input-rb532 -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 2/3] rb532: build squashfs image by default
Signed-off-by: Roman Yeryomin --- target/linux/rb532/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/rb532/Makefile b/target/linux/rb532/Makefile index e5c6ad7..3086462 100644 --- a/target/linux/rb532/Makefile +++ b/target/linux/rb532/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk ARCH:=mipsel BOARD:=rb532 BOARDNAME:=Mikrotik RouterBoard 532 -FEATURES:=pci targz +FEATURES:=pci targz squashfs KERNEL_PATCHVER:=3.18 -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 1/3] rb532: increase kernel partition
4.1 got little bit larger than 4MB and I couldn't get lzma loader working on this platform Signed-off-by: Roman Yeryomin --- target/linux/rb532/image/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/target/linux/rb532/image/Makefile b/target/linux/rb532/image/Makefile index 284b3d4..1a1f343 100644 --- a/target/linux/rb532/image/Makefile +++ b/target/linux/rb532/image/Makefile @@ -72,7 +72,7 @@ define Image/Build $(CP) $(KDIR)/vmlinux.elf $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel $(STAGING_DIR_HOST)/bin/patch-cmdline $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel '$(strip $(call Image/cmdline/$(1))) ' ./gen_image.sh $(BIN_DIR)/$(IMG_PREFIX)-combined-$(1).bin \ - 4 $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel \ + 5 $(BIN_DIR)/$(IMG_PREFIX)-$(1).kernel \ $(CONFIG_TARGET_ROOTFS_PARTSIZE) $(KDIR)/root.$(1) \ 128 endef -- 2.5.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] kernel: add at803x fix for sgmii mode
On 20 December 2015 at 15:13, Christian Lamparter wrote: > Hello, > > On Sunday, December 20, 2015 02:30:39 AM Roman Yeryomin wrote: >> Some (possibly broken) bootloaders incorreclty initialize at8033 >> phy. This patch enables sgmii autonegotiation mode. >> >> Signed-off-by: Roman Yeryomin >> --- > Can you tell us a bit about the "possibly broken" bootloaders you talk > about? Like what devices (based "possibly" on QCA956x) have those and > from where you are getting this information? The device is uapac. But I'm taking about phy setup itself... > I'm asking because we (Chris and I) encountered similar issues with the > Cisco Merakin MR18. It has a AR8035-A (confirmed by opening up the device) > but calls it a AR8033. The PHY apparently connected via RGMII > (uses QCA955X_ETH_CFG_RGMII_EN [0]) but the device needs to write some > calibration values to SGMII and SERDES registers in order to work [1]. > We are quite keen to know what's going on since this seems counter-intuitive. ..and you are talking about SoC's gmac setup, which is completely different thing. Also, FYI, AR8035 doesn't have sgmii, it has rgmii only. Regards, Roman ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH 3/3] ar71xx: refresh patches
Signed-off-by: Roman Yeryomin
---
.../621-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 2 +-
.../patches-4.1/630-MIPS-ath79-fix-chained-irq-disable.patch | 10 +-
.../patches-4.1/631-MIPS-ath79-wmac-enable-set-led-pin.patch | 2 +-
.../patches-4.1/633-MIPS-ath79-add-gpio-irq-support.patch | 6 +++---
...739-MIPS-ath79-add-gpio-func-register-for-QCA955x-SoC.patch | 6 +++---
.../742-MIPS-ath79-add-qca955x-mac-tx-rx-delay-defs.patch | 6 +++---
.../patches-4.1/820-MIPS-ath79-add_gpio_function2_setup.patch | 6 +++---
7 files changed, 19 insertions(+), 19 deletions(-)
diff --git
a/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
b/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
index 888a7b6..dfad42f 100644
---
a/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
+++
b/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
@@ -236,7 +236,7 @@
static bool __init
ar93xx_wmac_otp_read_word(void __iomem *base, int addr, u32 *data)
{
-@@ -392,6 +410,8 @@ void __init ath79_register_wmac(u8 *cal_
+@@ -392,6 +412,8 @@ void __init ath79_register_wmac(u8 *cal_
qca953x_wmac_setup();
else if (soc_is_qca955x())
qca955x_wmac_setup();
diff --git
a/target/linux/ar71xx/patches-4.1/630-MIPS-ath79-fix-chained-irq-disable.patch
b/target/linux/ar71xx/patches-4.1/630-MIPS-ath79-fix-chained-irq-disable.patch
index 8c0cc95..1d9cb41 100644
---
a/target/linux/ar71xx/patches-4.1/630-MIPS-ath79-fix-chained-irq-disable.patch
+++
b/target/linux/ar71xx/patches-4.1/630-MIPS-ath79-fix-chained-irq-disable.patch
@@ -9,7 +9,7 @@
static void ath79_misc_irq_handler(unsigned int irq, struct irq_desc *desc)
{
-@@ -149,8 +151,7 @@ static void ar934x_ip2_irq_init(void)
+@@ -150,8 +152,7 @@ static void ar934x_ip2_irq_init(void)
for (i = ATH79_IP2_IRQ_BASE;
i < ATH79_IP2_IRQ_BASE + ATH79_IP2_IRQ_COUNT; i++)
@@ -19,7 +19,7 @@
irq_set_chained_handler(ATH79_CPU_IRQ(2), ar934x_ip2_irq_dispatch);
}
-@@ -182,7 +183,7 @@ static void qca953x_irq_init(void)
+@@ -183,7 +184,7 @@ static void qca953x_irq_init(void)
for (i = ATH79_IP2_IRQ_BASE;
i < ATH79_IP2_IRQ_BASE + ATH79_IP2_IRQ_COUNT; i++)
@@ -28,7 +28,7 @@
irq_set_chained_handler(ATH79_CPU_IRQ(2), qca953x_ip2_irq_dispatch);
}
-@@ -256,15 +257,13 @@ static void qca955x_irq_init(void)
+@@ -257,15 +258,13 @@ static void qca955x_irq_init(void)
for (i = ATH79_IP2_IRQ_BASE;
i < ATH79_IP2_IRQ_BASE + ATH79_IP2_IRQ_COUNT; i++)
@@ -46,7 +46,7 @@
irq_set_chained_handler(ATH79_CPU_IRQ(3), qca955x_ip3_irq_dispatch);
}
-@@ -345,13 +344,13 @@ static void qca956x_irq_init(void)
+@@ -346,13 +345,13 @@ static void qca956x_irq_init(void)
for (i = ATH79_IP2_IRQ_BASE;
i < ATH79_IP2_IRQ_BASE + ATH79_IP2_IRQ_COUNT; i++)
@@ -62,7 +62,7 @@
irq_set_chained_handler(ATH79_CPU_IRQ(3), qca956x_ip3_irq_dispatch);
-@@ -466,8 +465,35 @@ static void qca953x_ip3_handler(void)
+@@ -467,8 +466,35 @@ static void qca953x_ip3_handler(void)
do_IRQ(ATH79_CPU_IRQ(3));
}
diff --git
a/target/linux/ar71xx/patches-4.1/631-MIPS-ath79-wmac-enable-set-led-pin.patch
b/target/linux/ar71xx/patches-4.1/631-MIPS-ath79-wmac-enable-set-led-pin.patch
index 03b32b1..16a0b90 100644
---
a/target/linux/ar71xx/patches-4.1/631-MIPS-ath79-wmac-enable-set-led-pin.patch
+++
b/target/linux/ar71xx/patches-4.1/631-MIPS-ath79-wmac-enable-set-led-pin.patch
@@ -1,6 +1,6 @@
--- a/arch/mips/ath79/dev-wmac.c
+++ b/arch/mips/ath79/dev-wmac.c
-@@ -398,6 +398,11 @@ void __init ath79_wmac_set_ext_lna_gpio(
+@@ -400,6 +400,11 @@ void __init ath79_wmac_set_ext_lna_gpio(
ar934x_set_ext_lna_gpio(chain, gpio);
}
diff --git
a/target/linux/ar71xx/patches-4.1/633-MIPS-ath79-add-gpio-irq-support.patch
b/target/linux/ar71xx/patches-4.1/633-MIPS-ath79-add-gpio-irq-support.patch
index e8183e7..48c6e1c 100644
--- a/target/linux/ar71xx/patches-4.1/633-MIPS-ath79-add-gpio-irq-support.patch
+++ b/target/linux/ar71xx/patches-4.1/633-MIPS-ath79-add-gpio-irq-support.patch
@@ -29,7 +29,7 @@
static void __ath79_gpio_set_value(unsigned gpio, int value)
{
void __iomem *base = ath79_gpio_base;
-@@ -233,6 +245,132 @@ void __init ath79_gpio_output_select(uns
+@@ -235,6 +247,132 @@ void __init ath79_gpio_output_select(uns
spin_unlock_irqrestore(&ath79_gpio_lock, flags);
}
@@ -162,7 +162,7 @@
void __init ath79_gpio_init(void)
{
int err;
-@@ -269,6 +407,10 @@ void __init ath79_gpio_init(void)
+@@ -271,6 +409,10 @@ void __init ath79_gpio_init(void)
err = gpiochip_add(&ath79_gpio_chip);
if (err)
panic("cannot add AR71xx GPIO chip, error=%d", err);
@@ -173,7 +173,7 @@
}
int gpio_get_value(unsi
[OpenWrt-Devel] [PATCH 2/3] ar71xx: add support for QCA956x ethernet
Signed-off-by: Roman Yeryomin
---
...PS-ath79-add-support-for-QCA956x-ethernet.patch | 166 +
1 file changed, 166 insertions(+)
create mode 100644
target/linux/ar71xx/patches-4.1/622-MIPS-ath79-add-support-for-QCA956x-ethernet.patch
diff --git
a/target/linux/ar71xx/patches-4.1/622-MIPS-ath79-add-support-for-QCA956x-ethernet.patch
b/target/linux/ar71xx/patches-4.1/622-MIPS-ath79-add-support-for-QCA956x-ethernet.patch
new file mode 100644
index 000..6a6a2e4
--- /dev/null
+++
b/target/linux/ar71xx/patches-4.1/622-MIPS-ath79-add-support-for-QCA956x-ethernet.patch
@@ -0,0 +1,166 @@
+--- a/arch/mips/ath79/dev-eth.c
b/arch/mips/ath79/dev-eth.c
+@@ -198,7 +198,6 @@ void __init ath79_register_mdio(unsigned
+ case ATH79_SOC_AR9330:
+ case ATH79_SOC_AR9331:
+ case ATH79_SOC_QCA9533:
+- case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
+ mdio_dev = &ath79_mdio1_device;
+ mdio_data = &ath79_mdio1_data;
+@@ -209,6 +208,7 @@ void __init ath79_register_mdio(unsigned
+ case ATH79_SOC_AR9344:
+ case ATH79_SOC_QCA9556:
+ case ATH79_SOC_QCA9558:
++ case ATH79_SOC_QCA956X:
+ if (id == 0) {
+ mdio_dev = &ath79_mdio0_device;
+ mdio_data = &ath79_mdio0_data;
+@@ -258,7 +258,6 @@ void __init ath79_register_mdio(unsigned
+ break;
+
+ case ATH79_SOC_QCA9533:
+- case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
+ mdio_data->builtin_switch = 1;
+ break;
+@@ -268,6 +267,11 @@ void __init ath79_register_mdio(unsigned
+ mdio_data->is_ar934x = 1;
+ break;
+
++ case ATH79_SOC_QCA956X:
++ if (id == 1)
++ mdio_data->builtin_switch = 1;
++ break;
++
+ default:
+ break;
+ }
+@@ -387,6 +391,16 @@ static void qca955x_set_speed_sgmii(int
+ iounmap(base);
+ }
+
++static void qca956x_set_speed_sgmii(int speed)
++{
++ void __iomem *base;
++ u32 val = ath79_get_eth_pll(0, speed);
++
++ base = ioremap_nocache(AR71XX_PLL_BASE, AR71XX_PLL_SIZE);
++ __raw_writel(val, base + QCA955X_PLL_ETH_SGMII_CONTROL_REG);
++ iounmap(base);
++}
++
+ static void ath79_set_speed_dummy(int speed)
+ {
+ }
+@@ -517,6 +531,10 @@ struct ag71xx_switch_platform_data ath79
+ #define AR934X_PLL_VAL_1000x0101
+ #define AR934X_PLL_VAL_10 0x1616
+
++#define QCA956X_PLL_VAL_1000 0x0300
++#define QCA956X_PLL_VAL_100 0x0101
++#define QCA956X_PLL_VAL_100x1919
++
+ static void __init ath79_init_eth_pll_data(unsigned int id)
+ {
+ struct ath79_eth_pll_data *pll_data;
+@@ -575,13 +593,18 @@ static void __init ath79_init_eth_pll_da
+ case ATH79_SOC_QCA9533:
+ case ATH79_SOC_QCA9556:
+ case ATH79_SOC_QCA9558:
+- case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
+ pll_10 = AR934X_PLL_VAL_10;
+ pll_100 = AR934X_PLL_VAL_100;
+ pll_1000 = AR934X_PLL_VAL_1000;
+ break;
+
++ case ATH79_SOC_QCA956X:
++ pll_10 = QCA956X_PLL_VAL_10;
++ pll_100 = QCA956X_PLL_VAL_100;
++ pll_1000 = QCA956X_PLL_VAL_1000;
++ break;
++
+ default:
+ BUG();
+ }
+@@ -656,6 +679,7 @@ static int __init ath79_setup_phy_if_mod
+
+ case ATH79_SOC_QCA9556:
+ case ATH79_SOC_QCA9558:
++ case ATH79_SOC_QCA956X:
+ switch (pdata->phy_if_mode) {
+ case PHY_INTERFACE_MODE_MII:
+ case PHY_INTERFACE_MODE_RGMII:
+@@ -666,11 +690,6 @@ static int __init ath79_setup_phy_if_mod
+ }
+ break;
+
+- case ATH79_SOC_QCA9561:
+- if (!pdata->phy_if_mode)
+- pdata->phy_if_mode = PHY_INTERFACE_MODE_MII;
+- break;
+-
+ default:
+ BUG();
+ }
+@@ -699,7 +718,7 @@ static int __init ath79_setup_phy_if_mod
+ case ATH79_SOC_AR7241:
+ case ATH79_SOC_AR9330:
+ case ATH79_SOC_AR9331:
+- case ATH79_SOC_QCA9561:
++ case ATH79_SOC_QCA956X:
+ case ATH79_SOC_TP9343:
+ pdata->phy_if_mode = PHY_INTERFACE_MODE_GMII;
+ break;
+@@ -1032,7 +1051,6 @@ void __init ath79_register_eth(unsigned
+ pdata->fifo_cfg3 = 0x01f00140;
+ break;
+
+- case ATH79_SOC_QCA9561:
+ case ATH79_SOC_TP9343:
+ if (id == 0) {
+ pdata->reset_bit = AR933X_RESET_GE0_MAC |
+@@ -1100,6 +1118,34 @@ void __init ath79_register_eth(unsigned
+ pdata->fifo_cfg3 = 0x01
[OpenWrt-Devel] [PATCH 1/3] ar71xx: update QCA956x support
- separate qca956x and tp9343 (they use different IDs)
- rename qca9561->qca956x for consistency
- add missing bits (device reset, gpio output select)
- fix wmac setup
Signed-off-by: Roman Yeryomin
---
...21-MIPS-ath79-add-support-for-QCA956x-SoC.patch | 131 ++---
...79-add-gpio-func-register-for-QCA955x-SoC.patch | 7 +-
2 files changed, 92 insertions(+), 46 deletions(-)
diff --git
a/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
b/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
index ca92d0e..888a7b6 100644
---
a/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
+++
b/target/linux/ar71xx/patches-4.1/621-MIPS-ath79-add-support-for-QCA956x-SoC.patch
@@ -129,7 +129,7 @@
qca953x_clocks_init();
else if (soc_is_qca955x())
qca955x_clocks_init();
-+ else if (soc_is_qca956x())
++ else if (soc_is_qca956x() || soc_is_tp9343())
+ qca956x_clocks_init();
else
BUG();
@@ -140,7 +140,7 @@
reg = QCA953X_RESET_REG_RESET_MODULE;
else if (soc_is_qca955x())
reg = QCA955X_RESET_REG_RESET_MODULE;
-+ else if (soc_is_qca956x())
++ else if (soc_is_qca956x() || soc_is_tp9343())
+ reg = QCA956X_RESET_REG_RESET_MODULE;
else
panic("Reset register not defined for this SOC");
@@ -149,20 +149,30 @@
reg = QCA953X_RESET_REG_RESET_MODULE;
else if (soc_is_qca955x())
reg = QCA955X_RESET_REG_RESET_MODULE;
-+ else if (soc_is_qca956x())
++ else if (soc_is_qca956x() || soc_is_tp9343())
+ reg = QCA956X_RESET_REG_RESET_MODULE;
else
panic("Reset register not defined for this SOC");
+@@ -133,6 +137,8 @@ u32 ath79_device_reset_get(u32 mask)
+ reg = AR933X_RESET_REG_RESET_MODULE;
+ else if (soc_is_ar934x())
+ reg = AR934X_RESET_REG_RESET_MODULE;
++ else if (soc_is_qca956x() || soc_is_tp9343())
++ reg = QCA956X_RESET_REG_RESET_MODULE;
+ else
+ BUG();
+
--- a/arch/mips/ath79/dev-common.c
+++ b/arch/mips/ath79/dev-common.c
-@@ -94,7 +94,8 @@ void __init ath79_register_uart(void)
+@@ -94,7 +94,9 @@ void __init ath79_register_uart(void)
soc_is_ar913x() ||
soc_is_ar934x() ||
soc_is_qca953x() ||
- soc_is_qca955x()) {
+ soc_is_qca955x() ||
-+ soc_is_qca956x()) {
++ soc_is_qca956x() ||
++ soc_is_tp9343()) {
ath79_uart_data[0].uartclk = uart_clk_rate;
platform_device_register(&ath79_uart_device);
} else if (soc_is_ar933x()) {
@@ -192,14 +202,14 @@
qca953x_usb_setup();
else if (soc_is_qca955x())
qca955x_usb_setup();
-+ else if (soc_is_qca9561())
++ else if (soc_is_qca956x())
+ qca956x_usb_setup();
else
BUG();
}
--- a/arch/mips/ath79/dev-wmac.c
+++ b/arch/mips/ath79/dev-wmac.c
-@@ -189,6 +189,24 @@ static void qca955x_wmac_setup(void)
+@@ -189,6 +189,26 @@ static void qca955x_wmac_setup(void)
ath79_wmac_data.is_clk_25mhz = true;
}
@@ -219,6 +229,8 @@
+ ath79_wmac_data.is_clk_25mhz = false;
+ else
+ ath79_wmac_data.is_clk_25mhz = true;
++
++ ath79_wmac_data.get_mac_revision = ar93xx_get_soc_revision;
+}
+
static bool __init
@@ -228,7 +240,7 @@
qca953x_wmac_setup();
else if (soc_is_qca955x())
qca955x_wmac_setup();
-+ else if (soc_is_qca956x())
++ else if (soc_is_qca956x() || soc_is_tp9343())
+ qca956x_wmac_setup();
else
BUG();
@@ -240,27 +252,38 @@
case REV_ID_MAJOR_QCA9556:
case REV_ID_MAJOR_QCA9558:
+ case REV_ID_MAJOR_TP9343:
-+ case REV_ID_MAJOR_QCA9561:
++ case REV_ID_MAJOR_QCA956X:
_prom_putchar = prom_putchar_ar71xx;
break;
--- a/arch/mips/ath79/gpio.c
+++ b/arch/mips/ath79/gpio.c
-@@ -148,7 +148,8 @@ static void __iomem *ath79_gpio_get_func
+@@ -148,7 +148,10 @@ static void __iomem *ath79_gpio_get_func
soc_is_ar913x() ||
soc_is_ar933x())
reg = AR71XX_GPIO_REG_FUNC;
- else if (soc_is_ar934x() || soc_is_qca953x())
+ else if (soc_is_ar934x() ||
-+ soc_is_qca953x() || soc_is_qca956x())
++ soc_is_qca953x() ||
++ soc_is_qca956x() ||
++ soc_is_tp9343())
reg = AR934X_GPIO_REG_FUNC;
else
BUG();
-@@ -228,12 +229,15 @@ void __init ath79_gpio_init(void)
+@@ -187,7 +190,7 @@ void __init ath79_gpio_output_select(uns
+ unsigned int reg;
+ u32 t, s;
+
+- BUG_ON(!soc_is_ar934x() &&
