[PATCH uhttpd] ubus: parse "call" method params only for relevant call
From: Rafał Miłecki
There is no point in parsing "call" specific params for other ("list")
method calls. This is a minor cleanup that doesn't change uhttpd ubus
behaviour.
Signed-off-by: Rafał Miłecki
---
ubus.c | 40 +++-
1 file changed, 23 insertions(+), 17 deletions(-)
diff --git a/ubus.c b/ubus.c
index 8578631..97cc1e2 100644
--- a/ubus.c
+++ b/ubus.c
@@ -409,14 +409,7 @@ static void uh_ubus_send_list(struct client *cl,
json_object *obj, struct blob_a
static bool parse_json_rpc(struct rpc_data *d, struct blob_attr *data)
{
- const struct blobmsg_policy data_policy[] = {
- { .type = BLOBMSG_TYPE_STRING },
- { .type = BLOBMSG_TYPE_STRING },
- { .type = BLOBMSG_TYPE_STRING },
- { .type = BLOBMSG_TYPE_TABLE },
- };
struct blob_attr *tb[__RPC_MAX];
- struct blob_attr *tb2[4];
struct blob_attr *cur;
blobmsg_parse(rpc_policy, __RPC_MAX, tb, blob_data(data),
blob_len(data));
@@ -440,24 +433,35 @@ static bool parse_json_rpc(struct rpc_data *d, struct
blob_attr *data)
if (!d->params)
return false;
- blobmsg_parse_array(data_policy, ARRAY_SIZE(data_policy), tb2,
+ return true;
+}
+
+static void parse_call_params(struct rpc_data *d)
+{
+ const struct blobmsg_policy data_policy[] = {
+ { .type = BLOBMSG_TYPE_STRING },
+ { .type = BLOBMSG_TYPE_STRING },
+ { .type = BLOBMSG_TYPE_STRING },
+ { .type = BLOBMSG_TYPE_TABLE },
+ };
+ struct blob_attr *tb[4];
+
+ blobmsg_parse_array(data_policy, ARRAY_SIZE(data_policy), tb,
blobmsg_data(d->params),
blobmsg_data_len(d->params));
- if (tb2[0])
- d->sid = blobmsg_data(tb2[0]);
+ if (tb[0])
+ d->sid = blobmsg_data(tb[0]);
if (conf.ubus_noauth && (!d->sid || !*d->sid))
d->sid = UH_UBUS_DEFAULT_SID;
- if (tb2[1])
- d->object = blobmsg_data(tb2[1]);
-
- if (tb2[2])
- d->function = blobmsg_data(tb2[2]);
+ if (tb[1])
+ d->object = blobmsg_data(tb[1]);
- d->data = tb2[3];
+ if (tb[2])
+ d->function = blobmsg_data(tb[2]);
- return true;
+ d->data = tb[3];
}
static void uh_ubus_init_batch(struct client *cl)
@@ -528,6 +532,8 @@ static void uh_ubus_handle_request_object(struct client
*cl, struct json_object
goto error;
if (!strcmp(data.method, "call")) {
+ parse_call_params();
+
if (!data.sid || !data.object || !data.function || !data.data)
goto error;
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH firewall3] zones: apply tcp mss clamping also on ingress path
Fixes FS#3231 Signed-off-by: Yousong Zhou --- zones.c | 8 1 file changed, 8 insertions(+) diff --git a/zones.c b/zones.c index 68b02ab..d5e756c 100644 --- a/zones.c +++ b/zones.c @@ -580,6 +580,14 @@ print_interface_rule(struct fw3_ipt_handle *handle, struct fw3_state *state, fw3_ipt_rule_target(r, "TCPMSS"); fw3_ipt_rule_addarg(r, false, "--clamp-mss-to-pmtu", NULL); fw3_ipt_rule_replace(r, "FORWARD"); + + r = fw3_ipt_rule_create(handle, , dev, NULL, NULL, sub); + fw3_ipt_rule_addarg(r, false, "--tcp-flags", "SYN,RST"); + fw3_ipt_rule_addarg(r, false, "SYN", NULL); + fw3_ipt_rule_comment(r, "Zone %s MTU fixing", zone->name); + fw3_ipt_rule_target(r, "TCPMSS"); + fw3_ipt_rule_addarg(r, false, "--clamp-mss-to-pmtu", NULL); + fw3_ipt_rule_replace(r, "FORWARD"); } } else if (handle->table == FW3_TABLE_RAW) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCHv2] kexec-tools: update to 2.0.20
kdump was removed in 7acd257ae67b4ca94f8c23cb8bda0ee0709b9216 gdb can be used as an alternative. Backported patch to fix compilation with GCC10. Backported several openembedded patches, some of which are upstream backports. Signed-off-by: Rosen Penev --- v2: backported openembedded patches to fix compilation errors. package/boot/kexec-tools/Makefile | 40 +--- .../kexec-tools/patches/010-powerpc.patch | 35 +++ .../kexec-tools/patches/020-arm-lpae.patch| 49 + .../boot/kexec-tools/patches/100-gcc10.patch | 99 +++ ...rela-relocation-R_X86_64_PLT32-error.patch | 14 --- .../kexec-tools/patches/110-arm-syscall.patch | 34 +++ .../boot/kexec-tools/patches/120-i386.patch | 65 7 files changed, 285 insertions(+), 51 deletions(-) create mode 100644 package/boot/kexec-tools/patches/010-powerpc.patch create mode 100644 package/boot/kexec-tools/patches/020-arm-lpae.patch create mode 100644 package/boot/kexec-tools/patches/100-gcc10.patch delete mode 100644 package/boot/kexec-tools/patches/100-kexec-tools-fix-for-Unhandled-rela-relocation-R_X86_64_PLT32-error.patch create mode 100644 package/boot/kexec-tools/patches/110-arm-syscall.patch create mode 100644 package/boot/kexec-tools/patches/120-i386.patch diff --git a/package/boot/kexec-tools/Makefile b/package/boot/kexec-tools/Makefile index 269345aa9d..db6dac333e 100644 --- a/package/boot/kexec-tools/Makefile +++ b/package/boot/kexec-tools/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=kexec-tools -PKG_VERSION:=2.0.16 -PKG_RELEASE:=2 +PKG_VERSION:=2.0.20 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@KERNEL/linux/utils/kernel/kexec -PKG_HASH:=5b103351ad752c9badd1d65b00eb6de4bce579f944f4df4e3ef3a755ba567010 +PKG_HASH:=dad8077f0315445d1f6335579fc4ade222facf82a67124974c7be5303ba4f8c8 PKG_FIXUP:=autoreconf @@ -51,17 +51,6 @@ define Package/kexec/description The kexec utility allows to load and boot another kernel. endef -define Package/kdump - $(call Package/kexec-tools/Default) - TITLE:=Kernel crash analysis - DEPENDS:=+kexec @(i386||x86_64||arm) @KERNEL_CRASH_DUMP -endef - -define Package/kdump/description - The kdump package allows to automatically boot into a - special kernel for analyzing kernel crashes using kdump. -endef - define Package/kexec/config source "$(SOURCE)/Config.in" endef @@ -108,28 +97,5 @@ define Package/kexec/install $(LN) ../usr/sbin/kexec $(1)/sbin/kexec endef -define Package/kdump/install - $(INSTALL_DIR) $(1)/usr/sbin $(1)/etc/init.d $(1)/etc/config $(1)/etc/uci-defaults - $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/kdump $(PKG_INSTALL_DIR)/usr/sbin/vmcore-dmesg $(1)/usr/sbin - $(INSTALL_BIN) ./files/kdump.init $(1)/etc/init.d/kdump - $(INSTALL_BIN) ./files/kdump.defaults $(1)/etc/uci-defaults/kdump - $(INSTALL_CONF) ./files/kdump.config $(1)/etc/config/kdump -endef - -define Package/kdump/prerm -#!/bin/sh - -case $$(uname -m) in - i?86|x86_64) - if grep -q " crashkernel=" /boot/grub/grub.cfg; then - mount /boot -o remount,rw - sed -i 's/ crashkernel=[^ ]*//' /boot/grub/grub.cfg - mount /boot -o remount,ro - fi - ;; -esac -endef - $(eval $(call BuildPackage,kexec-tools)) $(eval $(call BuildPackage,kexec)) -$(eval $(call BuildPackage,kdump)) diff --git a/package/boot/kexec-tools/patches/010-powerpc.patch b/package/boot/kexec-tools/patches/010-powerpc.patch new file mode 100644 index 00..029650f35c --- /dev/null +++ b/package/boot/kexec-tools/patches/010-powerpc.patch @@ -0,0 +1,35 @@ +From 211cae4b6a02a4d9d37bfcd76f3702696e095fc3 Mon Sep 17 00:00:00 2001 +From: Quanyang Wang +Date: Tue, 16 Jun 2015 12:59:57 +0800 +Subject: [PATCH] powerpc: change the memory size limit + +When run "kexec" in powerpc board, the kexec has a limit that +the kernel text and bss size must be less than 24M. But now +some kernel size exceed the limit. So we need to change the limit, +else will get the error log as below: + +my_load:669: do +Could not find a free area of memory of 0x12400 bytes... +Could not find a free area of memory of 0x13000 bytes... +locate_hole failed + +Upstream-Status: Pending + +Signed-off-by: Quanyang Wang +--- + kexec/arch/ppc/kexec-ppc.h | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +diff --git a/kexec/arch/ppc/kexec-ppc.h b/kexec/arch/ppc/kexec-ppc.h +index 04e728e..6bae9ec 100644 +--- a/kexec/arch/ppc/kexec-ppc.h b/kexec/arch/ppc/kexec-ppc.h +@@ -44,7 +44,7 @@ void dol_ppc_usage(void); + * During inital setup the kernel does not map the whole memory but a part of + * it. On Book-E that is 64MiB, 601 24MiB or 256MiB (if possible). + */ +-#define KERNEL_ACCESS_TOP (24 * 1024 * 1024) ++#define KERNEL_ACCESS_TOP (36 * 1024 * 1024) + + /* boot block version 17 as defined by the linux kernel
[PATCH] uboot-mediatek: remove swig requirement
Ever since this package was introduced, the SDK for mt7629 failed to build as it started failing on this package. Fixed by porting Hauke's similar patch for uboot-sunxi to uboot-mediatek. Signed-off-by: Rosen Penev --- package/boot/uboot-mediatek/Makefile | 2 +- .../patches/010-no-binman.patch | 25 +++ 2 files changed, 26 insertions(+), 1 deletion(-) create mode 100644 package/boot/uboot-mediatek/patches/010-no-binman.patch diff --git a/package/boot/uboot-mediatek/Makefile b/package/boot/uboot-mediatek/Makefile index f6745f6cad..a7b47ecae5 100644 --- a/package/boot/uboot-mediatek/Makefile +++ b/package/boot/uboot-mediatek/Makefile @@ -2,7 +2,7 @@ include $(TOPDIR)/rules.mk include $(INCLUDE_DIR)/kernel.mk PKG_VERSION:=2020.04 -PKG_RELEASE:=1 +PKG_RELEASE:=2 PKG_HASH:=fe732aaf037d9cc3c0909bad8362af366ae964bbdac6913a34081ff4ad565372 include $(INCLUDE_DIR)/u-boot.mk diff --git a/package/boot/uboot-mediatek/patches/010-no-binman.patch b/package/boot/uboot-mediatek/patches/010-no-binman.patch new file mode 100644 index 00..8a05a2d41d --- /dev/null +++ b/package/boot/uboot-mediatek/patches/010-no-binman.patch @@ -0,0 +1,25 @@ +--- a/Makefile b/Makefile +@@ -1667,8 +1667,10 @@ u-boot-elf.lds: arch/u-boot-elf.lds prepare FORCE + ifeq ($(CONFIG_SPL),y) + spl/u-boot-spl-mtk.bin: spl/u-boot-spl + +-u-boot-mtk.bin: u-boot.dtb u-boot.img spl/u-boot-spl-mtk.bin FORCE +- $(call if_changed,binman) ++OBJCOPYFLAGS_u-boot-mtk.bin = -I binary -O binary \ ++ --pad-to=$(CONFIG_SPL_PAD_TO) --gap-fill=0xff ++u-boot-mtk.bin: u-boot.img spl/u-boot-spl-mtk.bin FORCE ++ $(call if_changed,pad_cat) + else + MKIMAGEFLAGS_u-boot-mtk.bin = -T mtk_image \ + -a $(CONFIG_SYS_TEXT_BASE) -e $(CONFIG_SYS_TEXT_BASE) \ +--- a/arch/arm/mach-mediatek/Kconfig b/arch/arm/mach-mediatek/Kconfig +@@ -36,7 +36,6 @@ config TARGET_MT7629 + bool "MediaTek MT7629 SoC" + select CPU_V7A + select SPL +- select BINMAN + help + The MediaTek MT7629 is a ARM-based SoC with a dual-core Cortex-A7 + including DDR3, crypto engine, 3x3 11n/ac Wi-Fi, Gigabit Ethernet, -- 2.26.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] tools: add PKG_{VERSION,RELEASE} to flock
The stored source code of flock contains the version string of version 2.18, reflect that in the Makefile. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. Signed-off-by: Paul Spooren --- v2: * Add release * Lowercase after ':' tools/flock/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/flock/Makefile b/tools/flock/Makefile index 9939d12116..cd3561bb69 100644 --- a/tools/flock/Makefile +++ b/tools/flock/Makefile @@ -7,6 +7,8 @@ include $(TOPDIR)/rules.mk PKG_NAME := flock +PKG_VERSION := 2.18 +PKG_RELEASE := 1 include $(INCLUDE_DIR)/host-build.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] tools: add PKG_{VERSION,RELEASE} to sstrip
Comparing the in tree stored source file of sstrip suggests it's version 2.0[0], reflect that in the Makefile. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. [0]: https://github.com/BR903/ELFkickers/commit/df4426a0f0ada861064d75c08cbebaac7c16b3ae#diff-d3ba694d91432a068d5d3b36abf8cd0f Signed-off-by: Paul Spooren --- v2: * Add release * Lowercase after ':' tools/sstrip/Makefile | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile index 180bd1743e..bab172a95a 100644 --- a/tools/sstrip/Makefile +++ b/tools/sstrip/Makefile @@ -7,6 +7,8 @@ include $(TOPDIR)/rules.mk PKG_NAME:=sstrip +PKG_VERSION:=2.0 +PKG_RELEASE:=1 include $(INCLUDE_DIR)/host-build.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] tools: Add PKG_VERSION to sstrip
> > This obviously applies to all the similar patches you sent in parallel. > > Despite, note that the common practice for PKG_RELEASE is to use plain > integer numbers, so no major.minor. I don't think that's as important as my > first point, but I'd say only deviate from the plain integer numbers when > having a reason (since, actually, if the code remains untouched for several > years, nobody will maintain a reasonable major/minor versioning anyway, > and it's easier to just bump by "1" on each change). > > > > Personally, to be honest, I'd just add PKG_RELEASE := 1 to all of the > previously unversioned packages. > Isn't it cleaner to state the upstream version of a package in the Makefile > even if the code is stored locally? I know sstrip is locally patch-hacked but > I > think it's better to state version 2.0 instead of release 1. Let's say > version 3.1a > brings some legit binary size improvements, no one could tell by reading > release 1. If there really is an upstream version and the local code is still in a state where tracking that version makes sense, I'm all in for using that. I'd even use PKG_VERSION and PKG_RELEASE then, as for any real package with upstream content. If the code is truly local, or in a state where it cannot be compared with an "upstream" version reasonably, I'd go for plain PKG_RELEASE. Best Adrian > >> Motivation is the tracking of changes in the buildsystem, which > >> requires versioning of packages. > >> > >> [0]: > >> > https://github.com/BR903/ELFkickers/commit/df4426a0f0ada861064d75c08c > >> bebaac7c16b3ae#diff-d3ba694d91432a068d5d3b36abf8cd0f > >> > >> Signed-off-by: Paul Spooren > >> --- > >> tools/sstrip/Makefile | 1 + > >> 1 file changed, 1 insertion(+) > >> > >> diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile index > >> 180bd1743e..99be063f4c 100644 > >> --- a/tools/sstrip/Makefile > >> +++ b/tools/sstrip/Makefile > >> @@ -7,6 +7,7 @@ > >> include $(TOPDIR)/rules.mk > >> > >> PKG_NAME:=sstrip > >> +PKG_VERSION:=2.0 > >> > >> include $(INCLUDE_DIR)/host-build.mk > >> > >> -- > >> 2.25.1 > >> > >> > >> ___ > >> openwrt-devel mailing list > >> openwrt-devel@lists.openwrt.org > >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 0/1] Introduce UCI support for configuring DSA VLAN filter rules
One thing which is a bit awkward as long as the bridge itself is configured as an interface, is that as far as I have understood, creating a tagged interface to the bridge requires first setting up an interface for the bridge, e.g. with protocol Unmanaged, and then setting up one or more vlan tagged interfaces on top of it which can then be configured with ip addresses. (Maybe this isn't such a big deal though.) On Thu, 16 Jul 2020 at 06:00, Felix Fietkau wrote: > > On 2020-07-15 13:52, John Crispin wrote: > > > > On 15.07.20 13:39, Jo-Philipp Wich wrote: > >> Hi, > >> > >>> If we can't come up with a working automatic scheme, maybe we could have > >>> an option to disable the cpu port per vlan? > >> Having a default-enabled "option self" or "option local" was my idea as > >> well. Any idea which name fits better? > >> > >> ~ Jo > >> > > self is what ip-bridge uses as a parameter name for this feature > I think local is a better fit - self/master seems to be used for bridge > vlan filter command target selection, not just for this feature. > > - Felix > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] tools: add PKG_RELEASE to firmware-utils
There is no versioning information in the firmware-utils code nor the Makefile. Consider it as first release by adding PKG_RELEASE. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. Also update copyright. Signed-off-by: Paul Spooren --- tools/firmware-utils/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile index 3dd9ac5c2c..ee0ef3a6fd 100644 --- a/tools/firmware-utils/Makefile +++ b/tools/firmware-utils/Makefile @@ -1,5 +1,5 @@ # -# Copyright (C) 2006-2012 OpenWrt.org +# Copyright (C) 2006-2020 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -7,6 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME := firmware-utils +PKG_RELEASE := 1 include $(INCLUDE_DIR)/host-build.mk include $(INCLUDE_DIR)/kernel.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] tools: add PKG_RELEASE to patch-image
There is no versioning information in the patch-image code nor the Makefile. Consider it as first release by adding PKG_RELEASE. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. Also update copyright. Signed-off-by: Paul Spooren --- tools/patch-image/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/patch-image/Makefile b/tools/patch-image/Makefile index 6f2900b96c..89cd25e19d 100644 --- a/tools/patch-image/Makefile +++ b/tools/patch-image/Makefile @@ -1,5 +1,5 @@ # -# Copyright (C) 2007-2012 OpenWrt.org +# Copyright (C) 2007-2020 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -7,6 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=patch-image +PKG_RELEASE:=1 include $(INCLUDE_DIR)/host-build.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] tools: Add PKG_VERSION to sstrip
On 22.07.20 12:49, m...@adrianschmutzler.de wrote: Hi Paul, -Original Message- From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] On Behalf Of Paul Spooren Sent: Donnerstag, 23. Juli 2020 00:15 To: openwrt-devel@lists.openwrt.org Cc: Paul Spooren Subject: [PATCH] tools: Add PKG_VERSION to sstrip Comparing the in tree stored source file of sstrip suggests it's version 2.0[0], reflect that in the Makefile. note that conceptually, PKG_VERSION is for _external_ packages: https://openwrt.org/docs/guide-developer/packages#buildpackage_variables "PKG_VERSION - The upstream version number that we're downloading" So, effectively this is to be used when there is some PKG_SOURCE_URL in the file. For packages that just consist of "local" code, one should just use "PKG_RELEASE". Actually, I've only recently enforced that for the package directory: https://github.com/openwrt/openwrt/commit/9c170cb92f4fbb316592c11567a080eb3f6a1fc3 I'd be happy if we could (continue to) follow that same scheme for the packages in tools as well. Works for me, I missed that specific patch but will just send a v2. For your ultimate goal, it shouldn't matter anyway, just replace the PKG_VERSION by PKG_RELEASE where we are using local code/there is no external code pulled. True, either is fine. This obviously applies to all the similar patches you sent in parallel. Despite, note that the common practice for PKG_RELEASE is to use plain integer numbers, so no major.minor. I don't think that's as important as my first point, but I'd say only deviate from the plain integer numbers when having a reason (since, actually, if the code remains untouched for several years, nobody will maintain a reasonable major/minor versioning anyway, and it's easier to just bump by "1" on each change). Personally, to be honest, I'd just add PKG_RELEASE := 1 to all of the previously unversioned packages. Isn't it cleaner to state the upstream version of a package in the Makefile even if the code is stored locally? I know sstrip is locally patch-hacked but I think it's better to state version 2.0 instead of release 1. Let's say version 3.1a brings some legit binary size improvements, no one could tell by reading release 1. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. [0]: https://github.com/BR903/ELFkickers/commit/df4426a0f0ada861064d75c08c bebaac7c16b3ae#diff-d3ba694d91432a068d5d3b36abf8cd0f Signed-off-by: Paul Spooren --- tools/sstrip/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile index 180bd1743e..99be063f4c 100644 --- a/tools/sstrip/Makefile +++ b/tools/sstrip/Makefile @@ -7,6 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=sstrip +PKG_VERSION:=2.0 include $(INCLUDE_DIR)/host-build.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] tools: Add PKG_VERSION to sstrip
Hi Paul, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Paul Spooren > Sent: Donnerstag, 23. Juli 2020 00:15 > To: openwrt-devel@lists.openwrt.org > Cc: Paul Spooren > Subject: [PATCH] tools: Add PKG_VERSION to sstrip > > Comparing the in tree stored source file of sstrip suggests it's version > 2.0[0], > reflect that in the Makefile. note that conceptually, PKG_VERSION is for _external_ packages: https://openwrt.org/docs/guide-developer/packages#buildpackage_variables "PKG_VERSION - The upstream version number that we're downloading" So, effectively this is to be used when there is some PKG_SOURCE_URL in the file. For packages that just consist of "local" code, one should just use "PKG_RELEASE". Actually, I've only recently enforced that for the package directory: https://github.com/openwrt/openwrt/commit/9c170cb92f4fbb316592c11567a080eb3f6a1fc3 I'd be happy if we could (continue to) follow that same scheme for the packages in tools as well. For your ultimate goal, it shouldn't matter anyway, just replace the PKG_VERSION by PKG_RELEASE where we are using local code/there is no external code pulled. This obviously applies to all the similar patches you sent in parallel. Despite, note that the common practice for PKG_RELEASE is to use plain integer numbers, so no major.minor. I don't think that's as important as my first point, but I'd say only deviate from the plain integer numbers when having a reason (since, actually, if the code remains untouched for several years, nobody will maintain a reasonable major/minor versioning anyway, and it's easier to just bump by "1" on each change). Personally, to be honest, I'd just add PKG_RELEASE := 1 to all of the previously unversioned packages. Best Adrian > > Motivation is the tracking of changes in the buildsystem, which requires > versioning of packages. > > [0]: > https://github.com/BR903/ELFkickers/commit/df4426a0f0ada861064d75c08c > bebaac7c16b3ae#diff-d3ba694d91432a068d5d3b36abf8cd0f > > Signed-off-by: Paul Spooren > --- > tools/sstrip/Makefile | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile index > 180bd1743e..99be063f4c 100644 > --- a/tools/sstrip/Makefile > +++ b/tools/sstrip/Makefile > @@ -7,6 +7,7 @@ > include $(TOPDIR)/rules.mk > > PKG_NAME:=sstrip > +PKG_VERSION:=2.0 > > include $(INCLUDE_DIR)/host-build.mk > > -- > 2.25.1 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] kexec-tools: update to 2.0.20
kdump was removed in 7acd257ae67b4ca94f8c23cb8bda0ee0709b9216 gdb can be used as an alternative. Backported patch to fix compilation with GCC10. Signed-off-by: Rosen Penev --- package/boot/kexec-tools/Makefile | 40 +--- .../boot/kexec-tools/patches/010-gcc10.patch | 99 +++ ...rela-relocation-R_X86_64_PLT32-error.patch | 14 --- 3 files changed, 102 insertions(+), 51 deletions(-) create mode 100644 package/boot/kexec-tools/patches/010-gcc10.patch delete mode 100644 package/boot/kexec-tools/patches/100-kexec-tools-fix-for-Unhandled-rela-relocation-R_X86_64_PLT32-error.patch diff --git a/package/boot/kexec-tools/Makefile b/package/boot/kexec-tools/Makefile index 269345aa9d..db6dac333e 100644 --- a/package/boot/kexec-tools/Makefile +++ b/package/boot/kexec-tools/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=kexec-tools -PKG_VERSION:=2.0.16 -PKG_RELEASE:=2 +PKG_VERSION:=2.0.20 +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz PKG_SOURCE_URL:=@KERNEL/linux/utils/kernel/kexec -PKG_HASH:=5b103351ad752c9badd1d65b00eb6de4bce579f944f4df4e3ef3a755ba567010 +PKG_HASH:=dad8077f0315445d1f6335579fc4ade222facf82a67124974c7be5303ba4f8c8 PKG_FIXUP:=autoreconf @@ -51,17 +51,6 @@ define Package/kexec/description The kexec utility allows to load and boot another kernel. endef -define Package/kdump - $(call Package/kexec-tools/Default) - TITLE:=Kernel crash analysis - DEPENDS:=+kexec @(i386||x86_64||arm) @KERNEL_CRASH_DUMP -endef - -define Package/kdump/description - The kdump package allows to automatically boot into a - special kernel for analyzing kernel crashes using kdump. -endef - define Package/kexec/config source "$(SOURCE)/Config.in" endef @@ -108,28 +97,5 @@ define Package/kexec/install $(LN) ../usr/sbin/kexec $(1)/sbin/kexec endef -define Package/kdump/install - $(INSTALL_DIR) $(1)/usr/sbin $(1)/etc/init.d $(1)/etc/config $(1)/etc/uci-defaults - $(INSTALL_BIN) $(PKG_INSTALL_DIR)/usr/sbin/kdump $(PKG_INSTALL_DIR)/usr/sbin/vmcore-dmesg $(1)/usr/sbin - $(INSTALL_BIN) ./files/kdump.init $(1)/etc/init.d/kdump - $(INSTALL_BIN) ./files/kdump.defaults $(1)/etc/uci-defaults/kdump - $(INSTALL_CONF) ./files/kdump.config $(1)/etc/config/kdump -endef - -define Package/kdump/prerm -#!/bin/sh - -case $$(uname -m) in - i?86|x86_64) - if grep -q " crashkernel=" /boot/grub/grub.cfg; then - mount /boot -o remount,rw - sed -i 's/ crashkernel=[^ ]*//' /boot/grub/grub.cfg - mount /boot -o remount,ro - fi - ;; -esac -endef - $(eval $(call BuildPackage,kexec-tools)) $(eval $(call BuildPackage,kexec)) -$(eval $(call BuildPackage,kdump)) diff --git a/package/boot/kexec-tools/patches/010-gcc10.patch b/package/boot/kexec-tools/patches/010-gcc10.patch new file mode 100644 index 00..2af315c0fc --- /dev/null +++ b/package/boot/kexec-tools/patches/010-gcc10.patch @@ -0,0 +1,99 @@ +From cc087b11462af9f971a2c090d07e8d780a867b50 Mon Sep 17 00:00:00 2001 +From: Kairui Song +Date: Wed, 29 Jan 2020 13:38:19 +0800 +Subject: kexec-tools: Remove duplicated variable declarations + +When building kexec-tools for Fedora 32, following error is observed: + +/usr/bin/ld: kexec/arch/x86_64/kexec-bzImage64.o:(.bss+0x0): multiple definition of `bzImage_support_efi_boot'; +kexec/arch/i386/kexec-bzImage.o:(.bss+0x0): first defined here + +/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm/../../fs2dt.h:33: multiple definition of `my_debug'; +kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/kexec/fs2dt.h:33: first defined here + +/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:68: multiple definition of `arm64_mem'; +kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:68: first defined here + +/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:54: multiple definition of `initrd_size'; +kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:54: first defined here + +/builddir/build/BUILD/kexec-tools-2.0.20/kexec/arch/arm64/kexec-arm64.h:53: multiple definition of `initrd_base'; +kexec/fs2dt.o:/builddir/build/BUILD/kexec-tools-2.0.20/././kexec/arch/arm64/kexec-arm64.h:53: first defined here + +And apparently, these variables are wrongly declared multiple times. So +remove duplicated declaration. + +Signed-off-by: Kairui Song +Signed-off-by: Simon Horman +--- + kexec/arch/arm64/kexec-arm64.h | 6 +++--- + kexec/arch/ppc64/kexec-elf-ppc64.c | 2 -- + kexec/arch/x86_64/kexec-bzImage64.c | 1 - + kexec/fs2dt.h | 2 +- + 4 files changed, 4 insertions(+), 7 deletions(-) + +diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h +index 628de79..ed447ac 100644 +--- a/kexec/arch/arm64/kexec-arm64.h
RES: openwrt-devel Digest, Vol 27, Issue 119
Senhores,
Não consigo logar no ip , erro: 92.168.1.1 recusou a conexão.
Pesquise na Web por 192 168 1 1
ERR_CONNECTION_REFUSED
Luciano Gualberto
-Mensagem original-
De: openwrt-devel Em nome de
openwrt-devel-requ...@lists.openwrt.org
Enviada em: quarta-feira, 22 de julho de 2020 19:34
Para: openwrt-devel@lists.openwrt.org
Assunto: openwrt-devel Digest, Vol 27, Issue 119
Send openwrt-devel mailing list submissions to
openwrt-devel@lists.openwrt.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
or, via email, send a message with subject or body 'help' to
openwrt-devel-requ...@lists.openwrt.org
You can reach the person managing the list at
openwrt-devel-ow...@lists.openwrt.org
When replying, please edit your Subject line so it is more specific than "Re:
Contents of openwrt-devel digest..."
Today's Topics:
1. ipq806x: support for Linksys E8350 v1 (Todor Colov)
2. [PATCH 1/1] ipq806x: add support for Linksys e8350 v1
(Todor Colov)
3. [PATCH] tools: Add PKG_VERSION to flock (Paul Spooren)
4. [PATCH] tools: Add PKG_VERSION to sstrip (Paul Spooren)
5. [PATCH] tools: add PKG_VERSION to patch-image (Paul Spooren)
6. [PATCH] tools: add PKG_VERSION to firmware-utils (Paul Spooren)
7. Re: [PATCH] dropbear: allow disabling support for scp
(Paul Spooren)
--
Message: 1
Date: Wed, 22 Jul 2020 21:44:47 +0300
From: Todor Colov
To: openwrt-devel@lists.openwrt.org
Cc: Todor Colov
Subject: ipq806x: support for Linksys E8350 v1
Message-ID: <20200722184448.333-1-todorco...@abv.bg>
Content-Type: text/plain; charset=UTF-8
Todor Colov (1):
ipq806x: add support for Linksys e8350 v1
.../ipq806x/base-files/etc/board.d/01_leds| 3 +
.../ipq806x/base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 5 +
.../arm/boot/dts/qcom-ipq8064-e8350-v1.dts| 246 ++
target/linux/ipq806x/image/Makefile | 29 +++
.../0069-arm-boot-add-dts-files.patch | 3 +-
6 files changed, 286 insertions(+), 1 deletion(-) create mode 100644
target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-e8350-v1.dts
--
2.27.0
--
Message: 2
Date: Wed, 22 Jul 2020 21:44:48 +0300
From: Todor Colov
To: openwrt-devel@lists.openwrt.org
Cc: Todor Colov
Subject: [PATCH 1/1] ipq806x: add support for Linksys e8350 v1
Message-ID: <20200722184448.333-2-todorco...@abv.bg>
Content-Type: text/plain; charset=UTF-8
Device specifications:
Device specifications:
* SoC: Qualcomm dual-core IPQ8064 @ 1.4 GHz
* RAM: 512MiB
* Flash: 4MiB SPI-NOR + 128 Nand
* Wireless 2.4GHz (SoC): b/g/n, Qualcomm QCA9880
* Wireless 5Ghz (QCA9886): a/n/ac, Quantenna QSR1000
* Ethernet (QCA8337): 1? 1GbE WAN + 4 x 1GbE LAN
* 1 x USB3.0 + 1 x USB2.0
* 1 eSata up to 3.0 Gbps
Flashing instructions:
* Upgrade with factory image via web interface
Debricking:
* Get the original firmware:
https://downloads.linksys.com/downloads/firmware/FW_E8350_1.0.03.003_20180929.bin
1. power off the device and disconnect the WAN port. (Only LAN port to be
connected)
2. press & hold the ?Reset? button
3. power on the deiece & wait for 10 seconds with pressed ?Reset? button
- the Router will open Firmware Recovery ?http? server on IP: 192.168.1.1
4. set IP on your PC from 192.168.1.0/24 network ( Router is on IP 192.168.1.1 )
5. open in browser URL:
http://192.168.1.1/index.shtml
MAC addresses:
MAC address (as on device label) is stored in u-boot env
WLAN uses address incremented by 1.
Signed-off-by: Todor Colov
---
.../ipq806x/base-files/etc/board.d/01_leds| 3 +
.../ipq806x/base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 5 +
.../arm/boot/dts/qcom-ipq8064-e8350-v1.dts| 246 ++
target/linux/ipq806x/image/Makefile | 29 +++
.../0069-arm-boot-add-dts-files.patch | 3 +-
6 files changed, 286 insertions(+), 1 deletion(-)
create mode 100644
target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-e8350-v1.dts
diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
b/target/linux/ipq806x/base-files/etc/board.d/01_leds
index f8b6c32358..802fb41d74 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
+++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
@@ -19,6 +19,9 @@ compex,wpq864)
ucidef_set_led_usbport "usb" "USB" "wpq864:green:usb" "usb1-port1"
"usb2-port1"
ucidef_set_led_usbport "pcie-usb" "PCIe USB" "wpq864:green:usb-pcie"
"usb3-port1"
;;
+linksys,e8350-v1)
+ucidef_set_led_wlan "wlan" "WLAN" "${boardname}:green:wifi" "phy0tpt"
+;;
nec,wg2600hp)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "${boardname}:green:wlan2g"
"phy1tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "${boardname}:green:wlan5g"
Re: [PATCH] dropbear: allow disabling support for scp
Hi Rui, I imagine it could be helpful if you use sstrip[0] on the created binaries to give a clearer size comparison. [0]: https://github.com/BR903/ELFkickers/blob/master/sstrip/ Best, Paul On 22.07.20 03:31, Rui Salvaterra wrote: If not needed, disabling scp allows for a nice size reduction. Dropbear executable size comparison: 153621 bytes (baseline) 133077 bytes (without scp) In other words, we trim a total of 20544 bytes. [Note: This patch is on top of "dropbear: fix ssh alternative when dbclient isn't built"] Signed-off-by: Rui Salvaterra --- package/network/services/dropbear/Config.in | 4 package/network/services/dropbear/Makefile | 8 +--- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/package/network/services/dropbear/Config.in b/package/network/services/dropbear/Config.in index 0ac84ee206..b9ecbc815b 100644 --- a/package/network/services/dropbear/Config.in +++ b/package/network/services/dropbear/Config.in @@ -102,4 +102,8 @@ config DROPBEAR_DBCLIENT bool "Build dropbear with dbclient" default y +config DROPBEAR_SCP + bool "Build dropbear with scp" + default y + endmenu diff --git a/package/network/services/dropbear/Makefile b/package/network/services/dropbear/Makefile index edd20909b1..8b57b214ae 100644 --- a/package/network/services/dropbear/Makefile +++ b/package/network/services/dropbear/Makefile @@ -31,7 +31,7 @@ PKG_CONFIG_DEPENDS:= \ CONFIG_DROPBEAR_RSA CONFIG_DROPBEAR_CURVE25519 CONFIG_DROPBEAR_ZLIB \ CONFIG_DROPBEAR_ED25519 CONFIG_DROPBEAR_CHACHA20POLY1305 \ CONFIG_DROPBEAR_UTMP CONFIG_DROPBEAR_PUTUTLINE \ - CONFIG_DROPBEAR_DBCLIENT + CONFIG_DROPBEAR_DBCLIENT CONFIG_DROPBEAR_SCP include $(INCLUDE_DIR)/package.mk @@ -53,7 +53,9 @@ define Package/dropbear CATEGORY:=Base system TITLE:=Small SSH2 client/server DEPENDS:= +DROPBEAR_ZLIB:zlib - ALTERNATIVES:=100:/usr/bin/scp:/usr/sbin/dropbear + ALTERNATIVES:= + $(if $(CONFIG_DROPBEAR_SCP),ALTERNATIVES+= \ + 100:/usr/bin/scp:/usr/sbin/dropbear,) $(if $(CONFIG_DROPBEAR_DBCLIENT),ALTERNATIVES+= \ 100:/usr/bin/ssh:/usr/sbin/dropbear,) @@ -149,7 +151,7 @@ endef define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ $(TARGET_CONFIGURE_OPTS) \ - PROGRAMS="dropbear $(if $(CONFIG_DROPBEAR_DBCLIENT),dbclient,) dropbearkey scp" \ + PROGRAMS="dropbear $(if $(CONFIG_DROPBEAR_DBCLIENT),dbclient,) dropbearkey $(if $(CONFIG_DROPBEAR_SCP),scp,)" \ MULTI=1 SCPPROGRESS=1 +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ $(TARGET_CONFIGURE_OPTS) \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools: add PKG_VERSION to firmware-utils
There is no versioning information in the firmware-utils code nor the Makefile. Due to the infrequent changes to the file I'm assuming a version 1.0.0, reflected in the Makefile. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. Also update copyright. Signed-off-by: Paul Spooren --- tools/firmware-utils/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile index 3dd9ac5c2c..4ea3f773b9 100644 --- a/tools/firmware-utils/Makefile +++ b/tools/firmware-utils/Makefile @@ -1,5 +1,5 @@ # -# Copyright (C) 2006-2012 OpenWrt.org +# Copyright (C) 2006-2020 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -7,6 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME := firmware-utils +PKG_VERSION := 1.0.0 include $(INCLUDE_DIR)/host-build.mk include $(INCLUDE_DIR)/kernel.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools: add PKG_VERSION to patch-image
Based on no modifications for 5 years I'm assuming it's safe to call it a version 1.0.0, reflect that in the Makefile. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. Also update copyright. Signed-off-by: Paul Spooren --- tools/patch-image/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/tools/patch-image/Makefile b/tools/patch-image/Makefile index 6f2900b96c..7accd59597 100644 --- a/tools/patch-image/Makefile +++ b/tools/patch-image/Makefile @@ -1,5 +1,5 @@ # -# Copyright (C) 2007-2012 OpenWrt.org +# Copyright (C) 2007-2020 OpenWrt.org # # This is free software, licensed under the GNU General Public License v2. # See /LICENSE for more information. @@ -7,6 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=patch-image +PKG_VERSION:=1.0.0 include $(INCLUDE_DIR)/host-build.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools: Add PKG_VERSION to sstrip
Comparing the in tree stored source file of sstrip suggests it's version 2.0[0], reflect that in the Makefile. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. [0]: https://github.com/BR903/ELFkickers/commit/df4426a0f0ada861064d75c08cbebaac7c16b3ae#diff-d3ba694d91432a068d5d3b36abf8cd0f Signed-off-by: Paul Spooren --- tools/sstrip/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/sstrip/Makefile b/tools/sstrip/Makefile index 180bd1743e..99be063f4c 100644 --- a/tools/sstrip/Makefile +++ b/tools/sstrip/Makefile @@ -7,6 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=sstrip +PKG_VERSION:=2.0 include $(INCLUDE_DIR)/host-build.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools: Add PKG_VERSION to flock
The stored source code of flock contains the version string of version 2.18, reflect that in the Makefile. Motivation is the tracking of changes in the buildsystem, which requires versioning of packages. Signed-off-by: Paul Spooren --- tools/flock/Makefile | 1 + 1 file changed, 1 insertion(+) diff --git a/tools/flock/Makefile b/tools/flock/Makefile index 9939d12116..83922a79aa 100644 --- a/tools/flock/Makefile +++ b/tools/flock/Makefile @@ -7,6 +7,7 @@ include $(TOPDIR)/rules.mk PKG_NAME := flock +PKG_VERSION := 2.18 include $(INCLUDE_DIR)/host-build.mk -- 2.25.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ipq806x: support for Linksys E8350 v1
Todor Colov (1): ipq806x: add support for Linksys e8350 v1 .../ipq806x/base-files/etc/board.d/01_leds| 3 + .../ipq806x/base-files/etc/board.d/02_network | 1 + .../base-files/lib/upgrade/platform.sh| 5 + .../arm/boot/dts/qcom-ipq8064-e8350-v1.dts| 246 ++ target/linux/ipq806x/image/Makefile | 29 +++ .../0069-arm-boot-add-dts-files.patch | 3 +- 6 files changed, 286 insertions(+), 1 deletion(-) create mode 100644 target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-e8350-v1.dts -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/1] ipq806x: add support for Linksys e8350 v1
Device specifications:
Device specifications:
* SoC: Qualcomm dual-core IPQ8064 @ 1.4 GHz
* RAM: 512MiB
* Flash: 4MiB SPI-NOR + 128 Nand
* Wireless 2.4GHz (SoC): b/g/n, Qualcomm QCA9880
* Wireless 5Ghz (QCA9886): a/n/ac, Quantenna QSR1000
* Ethernet (QCA8337): 1× 1GbE WAN + 4 x 1GbE LAN
* 1 x USB3.0 + 1 x USB2.0
* 1 eSata up to 3.0 Gbps
Flashing instructions:
* Upgrade with factory image via web interface
Debricking:
* Get the original firmware:
https://downloads.linksys.com/downloads/firmware/FW_E8350_1.0.03.003_20180929.bin
1. power off the device and disconnect the WAN port. (Only LAN port to be
connected)
2. press & hold the “Reset” button
3. power on the deiece & wait for 10 seconds with pressed “Reset” button
- the Router will open Firmware Recovery “http” server on IP: 192.168.1.1
4. set IP on your PC from 192.168.1.0/24 network ( Router is on IP 192.168.1.1 )
5. open in browser URL:
http://192.168.1.1/index.shtml
MAC addresses:
MAC address (as on device label) is stored in u-boot env
WLAN uses address incremented by 1.
Signed-off-by: Todor Colov
---
.../ipq806x/base-files/etc/board.d/01_leds| 3 +
.../ipq806x/base-files/etc/board.d/02_network | 1 +
.../base-files/lib/upgrade/platform.sh| 5 +
.../arm/boot/dts/qcom-ipq8064-e8350-v1.dts| 246 ++
target/linux/ipq806x/image/Makefile | 29 +++
.../0069-arm-boot-add-dts-files.patch | 3 +-
6 files changed, 286 insertions(+), 1 deletion(-)
create mode 100644
target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-e8350-v1.dts
diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds
b/target/linux/ipq806x/base-files/etc/board.d/01_leds
index f8b6c32358..802fb41d74 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/01_leds
+++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds
@@ -19,6 +19,9 @@ compex,wpq864)
ucidef_set_led_usbport "usb" "USB" "wpq864:green:usb" "usb1-port1"
"usb2-port1"
ucidef_set_led_usbport "pcie-usb" "PCIe USB" "wpq864:green:usb-pcie"
"usb3-port1"
;;
+linksys,e8350-v1)
+ucidef_set_led_wlan "wlan" "WLAN" "${boardname}:green:wifi" "phy0tpt"
+;;
nec,wg2600hp)
ucidef_set_led_wlan "wlan2g" "WLAN2G" "${boardname}:green:wlan2g"
"phy1tpt"
ucidef_set_led_wlan "wlan5g" "WLAN5G" "${boardname}:green:wlan5g"
"phy0tpt"
diff --git a/target/linux/ipq806x/base-files/etc/board.d/02_network
b/target/linux/ipq806x/base-files/etc/board.d/02_network
index 529a8d9f39..5e26fa2a8b 100755
--- a/target/linux/ipq806x/base-files/etc/board.d/02_network
+++ b/target/linux/ipq806x/base-files/etc/board.d/02_network
@@ -14,6 +14,7 @@ board=$(board_name)
case "$board" in
buffalo,wxr-2533dhp |\
compex,wpq864 |\
+linksys,e8350-v1 |\
netgear,d7800 |\
netgear,r7500 |\
netgear,r7500v2 |\
diff --git a/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
b/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
index 560e64af3a..34b9da47af 100644
--- a/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ipq806x/base-files/lib/upgrade/platform.sh
@@ -27,6 +27,11 @@ platform_do_upgrade() {
zyxel,nbg6817)
zyxel_do_upgrade "$1"
;;
+ linksys,e8350-v1)
+ # KERNEL_IN_UBI first remove metadata trailer from the UBI
volume
+ /tmp/fwtool -q -t -i /dev/null "$1"
+ nand_do_upgrade "$1"
+ ;;
linksys,ea7500-v1 |\
linksys,ea8500)
platform_do_upgrade_linksys "$1"
diff --git
a/target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-e8350-v1.dts
b/target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-e8350-v1.dts
new file mode 100644
index 00..5b8cdd205d
--- /dev/null
+++ b/target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-e8350-v1.dts
@@ -0,0 +1,246 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+#include "qcom-ipq8064-v2.0.dtsi"
+
+#include
+#include
+
+/ {
+ model = "Linksys EA8350 V1 WiFi Router";
+ compatible = "linksys,e8350-v1", "qcom,ipq8064";
+
+ memory@0 {
+ reg = <0x4200 0x1e00>;
+ device_type = "memory";
+ };
+
+ aliases {
+ serial0 = _serial;
+
+ led-boot = _power;
+ led-failsafe = _power;
+ led-running = _power;
+ led-upgrade = _power;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+ pinctrl-0 = <_pins>;
+ pinctrl-names = "default";
+
+ reset {
+ label = "reset";
+ gpios = <_pinmux 68 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = <_pinmux 65 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wifi {
+
RE: [OpenWrt-Devel] [RFT PATCH] arc770: bump kernel to 5.4
Hi Hauke, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Hauke Mehrtens > Sent: Montag, 25. Mai 2020 15:56 > To: Evgeniy Didin ; Alexey Brodkin > > Cc: Adrian Schmutzler ; openwrt- > de...@lists.openwrt.org > Subject: Re: [OpenWrt-Devel] [RFT PATCH] arc770: bump kernel to 5.4 > > On 4/13/20 12:33 PM, Adrian Schmutzler wrote: > > Update config with make kernel_oldconfig and copy patch. > > > > Directly switch to kernel 5.4. > > > > Signed-off-by: Adrian Schmutzler > > > > --- > > > > I just stupidly copied/refreshed the patch and the config. > > > > Build-tested, run-test required as I have no hardware. > > Hi Evgeniy and Alexey, > > Could you please test, if this patch works? > > We would like to get all targets to kernel 5.4 for the next release and this > is > one of the targets still at an older kernel. Adrian and I do not have any > hardware to test this. just looked at this one again. This target appears to be upstream with almost no local adjustments. I wonder whether I should just push the kernel bump to master if it builds fine, without a device test. (would do a new refresh and build-test beforehand, of course). Nobody seems to care anyway. Do you have an opinion here? Best Adrian > > You can find this patch also on patchwork: > https://patchwork.ozlabs.org/project/openwrt/patch/20200413103352.7429- > 1-freif...@adrianschmutzler.de/ > > Hauke > > > > > --- > > target/linux/arc770/Makefile | 2 +- > > target/linux/arc770/config-5.4| 198 ++ > > ...c-Disable-frame-filtering-completely.patch | 31 +++ > > 3 files changed, 230 insertions(+), 1 deletion(-) create mode 100644 > > target/linux/arc770/config-5.4 create mode 100644 > > target/linux/arc770/patches-5.4/700-stmmac-Disable-frame-filtering-com > > pletely.patch > > > > diff --git a/target/linux/arc770/Makefile > > b/target/linux/arc770/Makefile index 8150f147c5..a182ef16a5 100644 > > --- a/target/linux/arc770/Makefile > > +++ b/target/linux/arc770/Makefile > > @@ -11,7 +11,7 @@ BOARD:=arc770 > > BOARDNAME:=Synopsys DesignWare ARC 770D SUBTARGETS:=generic > > > > -KERNEL_PATCHVER:=4.14 > > +KERNEL_PATCHVER:=5.4 > > > > DEVICE_TYPE:=developerboard > > > > diff --git a/target/linux/arc770/config-5.4 > > b/target/linux/arc770/config-5.4 new file mode 100644 index > > 00..ce712b4c34 > > --- /dev/null > > +++ b/target/linux/arc770/config-5.4 > > @@ -0,0 +1,198 @@ > > +# CONFIG_16KSTACKS is not set > > +CONFIG_ARC=y > > +CONFIG_ARCH_32BIT_OFF_T=y > > +CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y > > +CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y > > +CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y > > +CONFIG_ARCH_HAS_PTE_SPECIAL=y > > +CONFIG_ARCH_HAS_SETUP_DMA_OPS=y > > +CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y > > +CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y > > +CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y > > +CONFIG_ARC_BUILTIN_DTB_NAME="" > > +CONFIG_ARC_CACHE=y > > +CONFIG_ARC_CACHE_LINE_SHIFT=5 > > +CONFIG_ARC_CACHE_PAGES=y > > +# CONFIG_ARC_CACHE_VIPT_ALIASING is not set # > > +CONFIG_ARC_COMPACT_IRQ_LEVELS is not set # > CONFIG_ARC_CPU_750D is not > > +set CONFIG_ARC_CPU_770=y CONFIG_ARC_CURR_IN_REG=y > CONFIG_ARC_DBG=y # > > +CONFIG_ARC_DBG_TLB_PARANOIA is not set > CONFIG_ARC_DW2_UNWIND=y > > +CONFIG_ARC_EMUL_UNALIGNED=y # > CONFIG_ARC_FPU_SAVE_RESTORE is not set > > +CONFIG_ARC_HAS_DCACHE=y # CONFIG_ARC_HAS_DCCM is not set > > +CONFIG_ARC_HAS_ICACHE=y # CONFIG_ARC_HAS_ICCM is not set > > +CONFIG_ARC_HAS_LLSC=y CONFIG_ARC_HAS_SWAPE=y > > +CONFIG_ARC_KVADDR_SIZE=256 > > +# CONFIG_ARC_METAWARE_HLINK is not set # CONFIG_ARC_MMU_V1 > is not set > > +# CONFIG_ARC_MMU_V2 is not set CONFIG_ARC_MMU_V3=y # > > +CONFIG_ARC_PAGE_SIZE_16K is not set # CONFIG_ARC_PAGE_SIZE_4K is > not > > +set CONFIG_ARC_PAGE_SIZE_8K=y CONFIG_ARC_PLAT_AXS10X=y # > > +CONFIG_ARC_PLAT_EZNPS is not set # CONFIG_ARC_PLAT_TB10X is not > set > > +CONFIG_ARC_TIMERS=y CONFIG_AXS101=y > CONFIG_CC_HAS_KASAN_GENERIC=y # > > +CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE_O3 is not set > > +CONFIG_CLKDEV_LOOKUP=y CONFIG_CLONE_BACKWARDS=y > CONFIG_COMMON_CLK=y > > +CONFIG_COMPAT_32BIT_TIME=y CONFIG_CPU_NO_EFFICIENT_FFS=y > > +CONFIG_CRC16=y CONFIG_CRYPTO_CRC32C=y > CONFIG_CRYPTO_HASH=y > > +CONFIG_CRYPTO_HASH2=y CONFIG_CRYPTO_RNG2=y > CONFIG_DMA_DIRECT_REMAP=y > > +CONFIG_DMA_REMAP=y CONFIG_DTC=y CONFIG_DWMAC_ANARION=y > > +CONFIG_DWMAC_GENERIC=y CONFIG_DW_APB_ICTL=y > CONFIG_EXT4_FS=y # > > +CONFIG_EZNPS_GIC is not set CONFIG_FIXED_PHY=y > CONFIG_FS_IOMAP=y > > +CONFIG_FS_MBCACHE=y CONFIG_FW_LOADER_PAGED_BUF=y > > +CONFIG_GENERIC_ALLOCATOR=y CONFIG_GENERIC_ATOMIC64=y > > +CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CSUM=y > > +CONFIG_GENERIC_FIND_FIRST_BIT=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_GPIOLIB=y CONFIG_GPIO_DWAPB=y > CONFIG_GPIO_GENERIC=y # > >
Re: [RFC PATCH v2 1/6] ath79: ensure QCA956x gmac0 mux selects sgmii
Hi David, On Wed, 2020-07-22 at 12:28 +0200, David Bauer wrote: > Hi Sander, > > this looks good, however there are two minor improvements still open. > > > + int err = 0; > > Remove this, as it is only assigned but never accessed. > > > + u32 serdes_cal; > > This is never used. > I had copied the bulk of this function from the qca956x serdes init function (patch 2/6), so I missed these when editing the code. Should be all cleaned up now. Since the err variable was also unused in patch 2/6, I've removed it there too. > I'll test this patch on my QCA9563 and QCA9561 devices and report > back. I've now tested it on my EAP245 v1 and v3. Both have a QCA9563, but only the latter has the ethernet interface enabled correctly by the bootloader (and didn't need this patch). Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 19.07] ramips: add support for Asus RT-N10P V3 / RT-N11P B1 / RT-N12 VP B1
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Ernst Spielmann
> Sent: Samstag, 18. Juli 2020 14:24
> To: openwrt-devel@lists.openwrt.org
> Cc: Ernst Spielmann
> Subject: [PATCH 19.07] ramips: add support for Asus RT-N10P V3 / RT-N11P
> B1 / RT-N12 VP B1
Hi,
device support backport typically does not happen:
https://openwrt.org/docs/guide-developer/device-support-policies#backports
I will leave this open in case one of the committers is specifically
interested, and will mark it "Rejected" if nothing happens for a few weeks.
Best
Adrian
>
> Specifications:
>
> - MT7628NN @ 580 MHz
> - 32 MB RAM
> - 8 MB Flash
> - 5x 10/100 Mbps Ethernet (built-in switch)
> - 2.4 GHz WLAN
> - 2x external, non-detachable antennas (1x for RT-N10P V3)
>
> Flash instructions:
>
> 1. Set PC network interface to 192.168.1.75/24.
> 2. Connect PC to the router via LAN.
> 3. Turn router off, press and hold reset button, then turn it on.
> 4. Keep the button pressed till power led starts to blink.
> 5. Upload the firmware file via TFTP. (Any filename is accepted.) 6. Wait
> until
> the router reboots.
>
> Signed-off-by: Ernst Spielmann
> ---
> Backport commit c3dc52e39ac83704b7a376d8d5610bdb91807e3f
> .../ramips/base-files/etc/board.d/01_leds | 6 ++
> .../ramips/base-files/etc/board.d/02_network | 3 +
> .../ramips/dts/mt7628an_asus_rt-n10p-v3.dts | 34 ++
> .../ramips/dts/mt7628an_asus_rt-n11p-b1.dts | 34 ++
> .../ramips/dts/mt7628an_asus_rt-n12-vp-b1.dts | 34 ++
> .../ramips/dts/mt7628an_asus_rt-n1x.dtsi | 100 ++
> target/linux/ramips/image/mt76x8.mk | 21
> 7 files changed, 232 insertions(+)
> create mode 100644 target/linux/ramips/dts/mt7628an_asus_rt-n10p-v3.dts
> create mode 100644 target/linux/ramips/dts/mt7628an_asus_rt-n11p-b1.dts
> create mode 100644 target/linux/ramips/dts/mt7628an_asus_rt-n12-vp-
> b1.dts
> create mode 100644 target/linux/ramips/dts/mt7628an_asus_rt-n1x.dtsi
>
> diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
> b/target/linux/ramips/base-files/etc/board.d/01_leds
> index 5c005db0c1..f040f53359 100755
> --- a/target/linux/ramips/base-files/etc/board.d/01_leds
> +++ b/target/linux/ramips/base-files/etc/board.d/01_leds
> @@ -65,6 +65,12 @@ asl26555-16M)
> ucidef_set_led_netdev "eth" "ETH" "asl26555:green:eth" "eth0"
> set_wifi_led "asl26555:green:wlan"
> ;;
> +asus,rt-n10p-v3|\
> +asus,rt-n11p-b1|\
> +asus,rt-n12-vp-b1)
> + ucidef_set_led_switch "lan" "lan" "$boardname:green:lan" "switch0"
> "0xf"
> + ucidef_set_led_switch "wan" "wan" "$boardname:green:wan"
> "switch0" "0x10"
> + ;;
> bdcom,wap2100-sk|\
> hiwifi,hc5861b)
> set_wifi_led "$boardname:green:wlan2g"
> 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 f743ce851a..ef18da0ef8 100755
> --- a/target/linux/ramips/base-files/etc/board.d/02_network
> +++ b/target/linux/ramips/base-files/etc/board.d/02_network
> @@ -80,6 +80,9 @@ ramips_setup_interfaces()
> 3g-6200n|\
> ai-br100|\
> alfa-network,ac1200rm|\
> + asus,rt-n10p-v3|\
> + asus,rt-n11p-b1|\
> + asus,rt-n12-vp-b1|\
> mediatek,ap-mt7621a-v60|\
> xzwifi,creativebox-v1|\
> d240|\
> diff --git a/target/linux/ramips/dts/mt7628an_asus_rt-n10p-v3.dts
> b/target/linux/ramips/dts/mt7628an_asus_rt-n10p-v3.dts
> new file mode 100644
> index 00..ec00030cf2
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_asus_rt-n10p-v3.dts
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include "mt7628an_asus_rt-n1x.dtsi"
> +
> +/ {
> + compatible = "asus,rt-n10p-v3", "mediatek,mt7628an-soc";
> + model = "Asus RT-N10P V3";
> +
> + leds {
> + compatible = "gpio-leds";
> +
> + led_power: power {
> + label = "rt-n10p-v3:green:power";
> + gpios = < 5 GPIO_ACTIVE_LOW>;
> + };
> +
> + wlan {
> + label = "rt-n10p-v3:green:wlan";
> + gpios = < 12 GPIO_ACTIVE_LOW>;
> + linux,default-trigger = "phy0tpt";
> + };
> +
> + wan {
> + label = "rt-n10p-v3:green:wan";
> + gpios = < 11 GPIO_ACTIVE_LOW>;
> + };
> +
> + lan {
> + label = "rt-n10p-v3:green:lan";
> + gpios = < 10 GPIO_ACTIVE_LOW>;
> + };
> + };
> +};
> diff --git a/target/linux/ramips/dts/mt7628an_asus_rt-n11p-b1.dts
> b/target/linux/ramips/dts/mt7628an_asus_rt-n11p-b1.dts
> new file mode 100644
> index 00..8aee2f73aa
> --- /dev/null
> +++ b/target/linux/ramips/dts/mt7628an_asus_rt-n11p-b1.dts
> @@ -0,0 +1,34 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +/dts-v1/;
> +
> +#include
RE: [PATCH 1/1] update factory reset for generic handling of all type of devices(jffs2, ubi, etc)
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Todor Colov > Sent: Montag, 20. Juli 2020 21:19 > To: openwrt-devel@lists.openwrt.org > Cc: Todor Colov > Subject: [PATCH 1/1] update factory reset for generic handling of all type of > devices(jffs2, ubi, etc) Despite the formal requirements not met (commit title/message), one comment below. > > Signed-off-by: Todor Colov > --- > package/base-files/files/etc/rc.button/reset | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/package/base-files/files/etc/rc.button/reset b/package/base- > files/files/etc/rc.button/reset > index 2403122ad2..0c11bfe462 100755 > --- a/package/base-files/files/etc/rc.button/reset > +++ b/package/base-files/files/etc/rc.button/reset > @@ -23,7 +23,7 @@ released) > elif [ "$SEEN" -ge 5 -a -n "$OVERLAY" ] > then > echo "FACTORY RESET" > /dev/console > - jffs2reset -y && reboot & > + rm -f /etc/config/* && cp -a /rom/etc/* /etc/. ; sync ; reboot As far as I understand it, jffs2reset will really reset the file system, just throwing away all diffs to the "rom". What you do here looks to me like it will essentially remove the files, and then recreate them, both increasing the diff between the overlay fs and the rom part, eating up precious space. Or is this healed somewhere magically I'm not aware of? Best Adrian > fi > ;; > esac > -- > 2.27.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC PATCH 5/5] ipq40xx: add target for Google WiFi (Gale)
> I'll spin up a new revision sooner or later, but I'm hoping I'll get some
> opinion
> on the RFC portion (cover letter / first ~3 patches) before doing that.
Yes, just wait for some comments on the actual content. :-)
> > I'd like a bit more detailed flashing instructions here. What you have right
> now only works if the reader knows what to do anyway.
>
> Well, it's not exactly trivial, but I guess not that difficult, relative to
> the
> average device OpenWRT supports. As luck would have it, somebody has
> already documented it:
>
> https://github.com/marcosscriven/galeforce#how-to-apply-an-image
>
> Would it be best to summarize, link, or both?
Both. I'm a fan of putting information directly into the commit message, as
that is the safest way of preserving it when links change, content changes etc.
The linked resources seem to be too much content for just pasting, though, so a
helpful summary seems to be appropriate here.
Despite, also consider adding the full information to our Wiki's device page.
>
> > > +++ b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gale-
> v2.
> > > +++ dts
> > > @@ -0,0 +1,402 @@
> > > +// SPDX-License-Identifier: GPL-2.0
> > > +/*
> > > + * Copyright (c) 2016, 2018 The Linux Foundation. All rights reserved.
> > > + * Copyright (c) 2016 Google, Inc
> > > + */
> > > +
> > > +#include "qcom-ipq4019.dtsi"
> > > +#include #include
> > > +
> > > +
> > > + {
> >
> > I'd have expected the root node first.
>
> I've learned muscle memory to put things like pinctrl first, because they're
> often referenced by other nodes (possibly including in the root node) via
> phandle, and at least in the past, DTC would not support out-of-order
> references for phandles.
>
> But that doesn't apply here (no phandles from the root section), so that
> doesn't apply. Will change.
>
> > > +/ {
> > > + model = "Google IPQ4019/Gale";
> >
> > This should be generally consistent with what you choose for
> DEVICE_MODEL. See my others comments there below.
> >
> > > + compatible = "google,gale-v2", "qcom,ipq4019";
> ...
> > > --- a/target/linux/ipq40xx/image/Makefile
> > > +++ b/target/linux/ipq40xx/image/Makefile
> > > @@ -218,6 +218,20 @@ define Device/avm_fritzbox-4040 endef
> > > TARGET_DEVICES += avm_fritzbox-4040
> > >
> > > +define Device/google_gale-v2
> >
> > Alphabetic sorting.
> >
> > > + DEVICE_VENDOR := Google
> > > + DEVICE_MODEL := WiFi (Gale)
> >
> > This uses yet another name compared to device definition/compatible and
> model in DTS.
> > Please be more consistent. Despite, if the device node (and thus the
> > image) has a v2 in it, please also add
> >
> > DEVICE_VARIANT := v2
> >
> > here.
>
> Thanks for the scrutiny! I do have some questions here: is the
> VENDOR/MODEL supposed to match closer to a marketing-friendly/user-
> friendly name, or a developer/low-level name?
I typically prefer something that the user can read on the device, as
everything else will add to the confusion.
> Or just some balance of both? Because there's several constraints
> here:
> * The bootloader recognizes compatible="google,gale-v2" -- I don't believe I
> can reliably drop the "v2" there, but I suppose that doesn't require the file
> names, etc., to include it
> * There really is no v1 publicly-available; as noted in the commit message, I
> believe that was pre-release hardware, and the revisions just stuck around
> through development
> * the "v2" here does *not* mean second generation, as in
> https://en.wikipedia.org/wiki/Google_Nest_Wifi#Second_generation
I don't think we have to care too much about the v1 here; however, if there is
a different "second generation" with the same name, then we should include a
"1st-gen" in the name somewhere, maybe even instead of the v2 if there is no v3
to be expected for the "1st-gen".
The Wiki article is not entirely precise here, so is the gale-v2 the "first
generation" in the nest article or is there actually a 1st and 2nd generation
of that Nest devices and gale something even different?
> * "WiFi" doesn't really make for a good MODEL on its own, although it's OK
> when paired with the VENDOR. But I still preferred sticking the codename
> (Gale) around, since that's the unambiguous way hackers can recognize the
> model.
>
> What do you think? Should I try to keep the keywords "google", "wifi", and
> "gale" in all of the config, image, and DTS name? And I'll avoid the "v2"
> labeling (and DEVICE_VARIANT) outside of "compatible", because I think that
> would be misleading.
If you call this gale, the question is how you proceed with the nest series
then. Will you switch to marketing-based "nest" then, or will you use the
internal name though the user will read something different on the device?
Unfortunately, this stuff is never easy to decide. Personally, I always lean
towards what's printed on the thing.
Best
Adrian
>
> Anyway, I'll try to figure out a better balance of the above on the next
>
[PATCH] dropbear: allow disabling support for scp
If not needed, disabling scp allows for a nice size reduction. Dropbear executable size comparison: 153621 bytes (baseline) 133077 bytes (without scp) In other words, we trim a total of 20544 bytes. [Note: This patch is on top of "dropbear: fix ssh alternative when dbclient isn't built"] Signed-off-by: Rui Salvaterra --- package/network/services/dropbear/Config.in | 4 package/network/services/dropbear/Makefile | 8 +--- 2 files changed, 9 insertions(+), 3 deletions(-) diff --git a/package/network/services/dropbear/Config.in b/package/network/services/dropbear/Config.in index 0ac84ee206..b9ecbc815b 100644 --- a/package/network/services/dropbear/Config.in +++ b/package/network/services/dropbear/Config.in @@ -102,4 +102,8 @@ config DROPBEAR_DBCLIENT bool "Build dropbear with dbclient" default y +config DROPBEAR_SCP + bool "Build dropbear with scp" + default y + endmenu diff --git a/package/network/services/dropbear/Makefile b/package/network/services/dropbear/Makefile index edd20909b1..8b57b214ae 100644 --- a/package/network/services/dropbear/Makefile +++ b/package/network/services/dropbear/Makefile @@ -31,7 +31,7 @@ PKG_CONFIG_DEPENDS:= \ CONFIG_DROPBEAR_RSA CONFIG_DROPBEAR_CURVE25519 CONFIG_DROPBEAR_ZLIB \ CONFIG_DROPBEAR_ED25519 CONFIG_DROPBEAR_CHACHA20POLY1305 \ CONFIG_DROPBEAR_UTMP CONFIG_DROPBEAR_PUTUTLINE \ - CONFIG_DROPBEAR_DBCLIENT + CONFIG_DROPBEAR_DBCLIENT CONFIG_DROPBEAR_SCP include $(INCLUDE_DIR)/package.mk @@ -53,7 +53,9 @@ define Package/dropbear CATEGORY:=Base system TITLE:=Small SSH2 client/server DEPENDS:= +DROPBEAR_ZLIB:zlib - ALTERNATIVES:=100:/usr/bin/scp:/usr/sbin/dropbear + ALTERNATIVES:= + $(if $(CONFIG_DROPBEAR_SCP),ALTERNATIVES+= \ + 100:/usr/bin/scp:/usr/sbin/dropbear,) $(if $(CONFIG_DROPBEAR_DBCLIENT),ALTERNATIVES+= \ 100:/usr/bin/ssh:/usr/sbin/dropbear,) @@ -149,7 +151,7 @@ endef define Build/Compile +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ $(TARGET_CONFIGURE_OPTS) \ - PROGRAMS="dropbear $(if $(CONFIG_DROPBEAR_DBCLIENT),dbclient,) dropbearkey scp" \ + PROGRAMS="dropbear $(if $(CONFIG_DROPBEAR_DBCLIENT),dbclient,) dropbearkey $(if $(CONFIG_DROPBEAR_SCP),scp,)" \ MULTI=1 SCPPROGRESS=1 +$(MAKE) $(PKG_JOBS) -C $(PKG_BUILD_DIR) \ $(TARGET_CONFIGURE_OPTS) \ -- 2.27.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: increase SPI frequency for MT7620 Archer
> -Original Message-
> From: David Bauer [mailto:m...@david-bauer.net]
> Sent: Mittwoch, 22. Juli 2020 14:21
> To: m...@adrianschmutzler.de
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: [PATCH] ramips: increase SPI frequency for MT7620 Archer
>
> Hello Adrian,
>
> On 7/22/20 11:29 AM, m...@adrianschmutzler.de wrote:
> >> -Original Message-
> >> From: openwrt-devel [mailto:openwrt-devel-
> boun...@lists.openwrt.org]
> >> On Behalf Of David Bauer
> >> Sent: Dienstag, 21. Juli 2020 23:40
> >> To: openwrt-devel@lists.openwrt.org
> >> Subject: [PATCH] ramips: increase SPI frequency for MT7620 Archer
> >>
> >> Increase the SPI frequency for the MT7620 based TP-Link Archer series
> >> to 30MHz.
> >
> > Acked-by: Adrian Schmutzler
> >
> > I'm not sure which are the frequency steps actually observed on that
> target, but raising it above the abundant copy/pasted 10 MHz seems a good
> idea in any case.
>
> The SPI master can be operated in a range of {2..128}/SYS_CLK. (2..128 has to
> be power of two). So in the end it will transfer at around 18 MHz.
>
> I don't want to crank this up further, as TP-Link uses a broad selection of
> SPI
> chips on a single hardware revision on many of their devices.
> Increasing performance might come at the cost of compatibility here.
Yes, no objection.
I just asked in case the next step would have been close, e.g. 33 MHz, then one
could have thought about raising it a little more.
But I'm fine with anything faster than the 10 Mhz :-)
Best
Adrian
>
> Best wishes
> David
>
> >
> > Best
> >
> > Adrian
> >
> >>
> >> TP-Link uses different SPI flash chips for the same board revision,
> >> so be conservative to not break boards with a different chip. 30MHz
> >> should be well supported by all chips.
> >>
> >> Tested on Archer C2 v1 (GD25Q64B) and Archer C20i (W25Q64FV).
> >>
> >> Archer C20i (before)
> >>
> >> root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
> >> 122+0 records in
> >> 122+0 records out
> >> real 0m 15.30s
> >> user 0m 0.00s
> >> sys0m 15.29s
> >>
> >> Archer C20i (after)
> >> ===
> >> root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
> >> 122+0 records in
> >> 122+0 records out
> >> real 0m 5.99s
> >> user 0m 0.00s
> >> sys0m 5.98s
> >>
> >> Signed-off-by: David Bauer
> >> ---
> >> target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts | 2 +-
> >> target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts | 2 +-
> >> target/linux/ramips/dts/mt7620a_tplink_archer.dtsi | 2 +-
> >> 3 files changed, 3 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> >> b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> >> index c0b2c1ae92..75ddc5fb5d 100644
> >> --- a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> >> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> >> @@ -82,7 +82,7 @@
> >>flash@0 {
> >>compatible = "jedec,spi-nor";
> >>reg = <0>;
> >> - spi-max-frequency = <1000>;
> >> + spi-max-frequency = <3000>;
> >>
> >>partitions {
> >>compatible = "fixed-partitions"; diff --git
> >> a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> >> b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> >> index c3c0efdfe6..0c0f4bb8e9 100644
> >> --- a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> >> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> >> @@ -121,7 +121,7 @@
> >>flash@0 {
> >>compatible = "jedec,spi-nor";
> >>reg = <0>;
> >> - spi-max-frequency = <1000>;
> >> + spi-max-frequency = <3000>;
> >>
> >>partitions {
> >>compatible = "fixed-partitions"; diff --git
> >> a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> >> b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> >> index 184627b9f4..670bad615d 100644
> >> --- a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> >> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> >> @@ -43,7 +43,7 @@
> >>flash@0 {
> >>compatible = "jedec,spi-nor";
> >>reg = <0>;
> >> - spi-max-frequency = <1000>;
> >> + spi-max-frequency = <3000>;
> >>
> >>partitions {
> >>compatible = "fixed-partitions";
> >> --
> >> 2.27.0
> >>
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
> >>
> >> ___
> >> openwrt-devel mailing list
> >> openwrt-devel@lists.openwrt.org
> >> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
Re: [PATCH] ramips: increase SPI frequency for MT7620 Archer
Hello Adrian,
On 7/22/20 11:29 AM, m...@adrianschmutzler.de wrote:
-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of David Bauer
Sent: Dienstag, 21. Juli 2020 23:40
To: openwrt-devel@lists.openwrt.org
Subject: [PATCH] ramips: increase SPI frequency for MT7620 Archer
Increase the SPI frequency for the MT7620 based TP-Link Archer series to
30MHz.
Acked-by: Adrian Schmutzler
I'm not sure which are the frequency steps actually observed on that target,
but raising it above the abundant copy/pasted 10 MHz seems a good idea in any
case.
The SPI master can be operated in a range of {2..128}/SYS_CLK. (2..128
has to be power of two). So in the end it will transfer at around 18 MHz.
I don't want to crank this up further, as TP-Link uses a broad selection
of SPI chips on a single hardware revision on many of their devices.
Increasing performance might come at the cost of compatibility here.
Best wishes
David
Best
Adrian
TP-Link uses different SPI flash chips for the same board revision, so be
conservative to not break boards with a different chip. 30MHz should be well
supported by all chips.
Tested on Archer C2 v1 (GD25Q64B) and Archer C20i (W25Q64FV).
Archer C20i (before)
root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
122+0 records in
122+0 records out
real0m 15.30s
user0m 0.00s
sys 0m 15.29s
Archer C20i (after)
===
root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
122+0 records in
122+0 records out
real0m 5.99s
user0m 0.00s
sys 0m 5.98s
Signed-off-by: David Bauer
---
target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts | 2 +-
target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts | 2 +-
target/linux/ramips/dts/mt7620a_tplink_archer.dtsi | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
index c0b2c1ae92..75ddc5fb5d 100644
--- a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
+++ b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
@@ -82,7 +82,7 @@
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <1000>;
+ spi-max-frequency = <3000>;
partitions {
compatible = "fixed-partitions";
diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
index c3c0efdfe6..0c0f4bb8e9 100644
--- a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
+++ b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
@@ -121,7 +121,7 @@
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <1000>;
+ spi-max-frequency = <3000>;
partitions {
compatible = "fixed-partitions";
diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
index 184627b9f4..670bad615d 100644
--- a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
+++ b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
@@ -43,7 +43,7 @@
flash@0 {
compatible = "jedec,spi-nor";
reg = <0>;
- spi-max-frequency = <1000>;
+ spi-max-frequency = <3000>;
partitions {
compatible = "fixed-partitions";
--
2.27.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC PATCH v2 1/6] ath79: ensure QCA956x gmac0 mux selects sgmii
Hi Sander,
this looks good, however there are two minor improvements still open.
On 7/19/20 11:24 PM, Sander Vanheule wrote:
Some bootloaders do not set up gmac0 properly, leaving it disconnected
from the sgmii interface. If the user specificies phy-mode sgmii, then
use the gmac-config/device node to ensure the mux is configured
correctly.
Signed-off-by: Sander Vanheule
Cc: David Bauer
---
.../net/ethernet/atheros/ag71xx/ag71xx_main.c | 38 +++
1 file changed, 38 insertions(+)
diff --git
a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index d611007a86..e86dbfffcf 100644
--- a/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ b/target/linux/ath79/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -665,6 +665,40 @@ out:
of_node_put(np);
}
+static void ag71xx_mux_select_sgmii_qca956x(struct device_node *np)
+{
+ struct device_node *np_dev;
+ void __iomem *gmac_base;
+ int err = 0;
Remove this, as it is only assigned but never accessed.
+ u32 serdes_cal;
This is never used.
I'll test this patch on my QCA9563 and QCA9561 devices and report back.
Best wishes
David
+ u32 t;
+
+ np = of_get_child_by_name(np, "gmac-config");
+ if (!np)
+ return;
+
+ np_dev = of_parse_phandle(np, "device", 0);
+ if (!np_dev)
+ goto out;
+
+ gmac_base = of_iomap(np_dev, 0);
+ if (!gmac_base) {
+ pr_err("%pOF: can't map GMAC registers\n", np_dev);
+ err = -ENOMEM;
+ goto err_iomap;
+ }
+
+ t = __raw_readl(gmac_base + QCA956X_GMAC_REG_ETH_CFG);
+ t |= QCA956X_ETH_CFG_GE0_SGMII;
+ __raw_writel(t, gmac_base + QCA956X_GMAC_REG_ETH_CFG);
+
+ iounmap(gmac_base);
+err_iomap:
+ of_node_put(np_dev);
+out:
+ of_node_put(np);
+}
+
static void ath79_mii_ctrl_set_if(struct ag71xx *ag, unsigned int mii_if)
{
u32 t;
@@ -1566,6 +1600,10 @@ static int ag71xx_probe(struct platform_device *pdev)
return ag->phy_if_mode;
}
+ if (of_device_is_compatible(np, "qca,qca9560-eth") &&
+ ag->phy_if_mode == PHY_INTERFACE_MODE_SGMII)
+ ag71xx_mux_select_sgmii_qca956x(np);
+
if (of_property_read_u32(np, "qca,mac-idx", >mac_idx))
ag->mac_idx = -1;
if (ag->mii_base)
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: increase SPI frequency for MT7620 Archer
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of David Bauer
> Sent: Dienstag, 21. Juli 2020 23:40
> To: openwrt-devel@lists.openwrt.org
> Subject: [PATCH] ramips: increase SPI frequency for MT7620 Archer
>
> Increase the SPI frequency for the MT7620 based TP-Link Archer series to
> 30MHz.
Acked-by: Adrian Schmutzler
I'm not sure which are the frequency steps actually observed on that target,
but raising it above the abundant copy/pasted 10 MHz seems a good idea in any
case.
Best
Adrian
>
> TP-Link uses different SPI flash chips for the same board revision, so be
> conservative to not break boards with a different chip. 30MHz should be well
> supported by all chips.
>
> Tested on Archer C2 v1 (GD25Q64B) and Archer C20i (W25Q64FV).
>
> Archer C20i (before)
>
> root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
> 122+0 records in
> 122+0 records out
> real 0m 15.30s
> user 0m 0.00s
> sys 0m 15.29s
>
> Archer C20i (after)
> ===
> root@OpenWrt:~# time dd if=/dev/mtd1 of=/tmp/test.bin bs=64k
> 122+0 records in
> 122+0 records out
> real 0m 5.99s
> user 0m 0.00s
> sys 0m 5.98s
>
> Signed-off-by: David Bauer
> ---
> target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts | 2 +-
> target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts | 2 +-
> target/linux/ramips/dts/mt7620a_tplink_archer.dtsi | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> index c0b2c1ae92..75ddc5fb5d 100644
> --- a/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer-c2-v1.dts
> @@ -82,7 +82,7 @@
> flash@0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
> - spi-max-frequency = <1000>;
> + spi-max-frequency = <3000>;
>
> partitions {
> compatible = "fixed-partitions";
> diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> index c3c0efdfe6..0c0f4bb8e9 100644
> --- a/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer-mr200.dts
> @@ -121,7 +121,7 @@
> flash@0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
> - spi-max-frequency = <1000>;
> + spi-max-frequency = <3000>;
>
> partitions {
> compatible = "fixed-partitions";
> diff --git a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> index 184627b9f4..670bad615d 100644
> --- a/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> +++ b/target/linux/ramips/dts/mt7620a_tplink_archer.dtsi
> @@ -43,7 +43,7 @@
> flash@0 {
> compatible = "jedec,spi-nor";
> reg = <0>;
> - spi-max-frequency = <1000>;
> + spi-max-frequency = <3000>;
>
> partitions {
> compatible = "fixed-partitions";
> --
> 2.27.0
>
>
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel
openpgp-digital-signature.asc
Description: PGP signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH] ramips: switch MT7620 subtarget to 5.4
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of David Bauer > Sent: Dienstag, 21. Juli 2020 23:41 > To: openwrt-devel@lists.openwrt.org > Subject: [PATCH] ramips: switch MT7620 subtarget to 5.4 > > MT7620 seems to work fine with kernel 5.4. Set the default kernel version to > 5.4 to bring this to a broader audience. > > Tested on Archer C2 v1 / Archer C20i > > Signed-off-by: David Bauer > --- > target/linux/ramips/mt7620/target.mk | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/target/linux/ramips/mt7620/target.mk > b/target/linux/ramips/mt7620/target.mk > index 56ceaee37f..ff890c5540 100644 > --- a/target/linux/ramips/mt7620/target.mk > +++ b/target/linux/ramips/mt7620/target.mk > @@ -9,6 +9,8 @@ CPU_TYPE:=24kc > > DEFAULT_PACKAGES += kmod-rt2800-soc wpad-basic swconfig > > +KERNEL_PATCHVER:=5.4 > + Hi David, thanks for taking care. I wonder whether it would be better to invert the statements, i.e. have KERNEL_PATCHVER:=5.4 in target Makefile and KERNEL_PATCHVER:=4.14 KERNEL_TESTING_PATCHVER:=5.4 in the rt subtarget Makefiles, as in the meantime those have become the "exceptions" after all. It's a mere matter of taste, though, feel free to ignore it. Best Adrian > define Target/Description > Build firmware images for Ralink MT7620 based boards. > endef > -- > 2.27.0 > > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel openpgp-digital-signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
