Re: [PATCH] busybox: use settimeofday() instead of syscall
On Thu, Aug 6, 2020 at 9:49 PM wrote:
>
> From: Masafumi UTSUGI
>
> SYS_settimeofday syscall is not time64 safe.
> Using settimeofday() instead of syscall() is recommended or
> some C libraries such as musl might cause compile error.
Eh no.
The reason for using the syscall is that musl ignores the tz
parameter. See:
https://github.com/openwrt/openwrt/commit/5a7c064bdbb71bfbcded073c7c0a8723be306009
A proper fix is here:
https://github.com/openwrt/openwrt/pull/3004/commits/bd6af541da7b27399143ce91081c44c3c9a155d9
I will resend once busybox 1.3.2 gets merged.
>
> Signed-off-by: Masafumi UTSUGI
> ---
> Makefile | 2 +-
> patches/250-date-k-flag.patch | 26 +++---
> 2 files changed, 12 insertions(+), 16 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 01441d1..baf375e 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
>
> PKG_NAME:=busybox
> PKG_VERSION:=1.31.1
> -PKG_RELEASE:=1
> +PKG_RELEASE:=2
> PKG_FLAGS:=essential
>
> PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
> diff --git a/patches/250-date-k-flag.patch b/patches/250-date-k-flag.patch
> index 5aadbb2..ef0545c 100644
> --- a/patches/250-date-k-flag.patch
> +++ b/patches/250-date-k-flag.patch
> @@ -8,19 +8,15 @@
> //usage: "\n"
> //usage: "\nRecognized TIME formats:"
> //usage: "\n hh:mm[:ss]"
> -@@ -139,9 +140,8 @@
> -
> - #include "libbb.h"
> - #include "common_bufsiz.h"
> --#if ENABLE_FEATURE_DATE_NANO
> --# include
> --#endif
> +@@ -142,6 +143,7 @@
> + #if ENABLE_FEATURE_DATE_NANO
> + # include
> + #endif
> +#include
> -+#include
>
> enum {
> OPT_RFC2822 = (1 << 0), /* R */
> -@@ -149,8 +149,9 @@ enum {
> +@@ -149,8 +151,9 @@ enum {
> OPT_UTC = (1 << 2), /* u */
> OPT_DATE = (1 << 3), /* d */
> OPT_REFERENCE = (1 << 4), /* r */
> @@ -32,7 +28,7 @@
> };
>
> #if ENABLE_LONG_OPTS
> -@@ -162,6 +163,7 @@ static const char date_longopts[] ALIGN1
> +@@ -162,6 +165,7 @@ static const char date_longopts[] ALIGN1 =
> /* "universal\0" No_argument "u" */
> "date\0" Required_argument "d"
> "reference\0" Required_argument "r"
> @@ -40,7 +36,7 @@
> ;
> #endif
>
> -@@ -181,6 +183,8 @@ static void maybe_set_utc(int opt)
> +@@ -181,6 +185,8 @@ static void maybe_set_utc(int opt)
> int date_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
> int date_main(int argc UNUSED_PARAM, char **argv)
> {
> @@ -49,7 +45,7 @@
> struct timespec ts;
> struct tm tm_time;
> char buf_fmt_dt2str[64];
> -@@ -193,7 +197,7 @@ int date_main(int argc UNUSED_PARAM, cha
> +@@ -193,7 +199,7 @@ int date_main(int argc UNUSED_PARAM, char **argv)
> char *isofmt_arg = NULL;
>
> opt = getopt32long(argv, "^"
> @@ -58,7 +54,7 @@
> IF_FEATURE_DATE_ISOFMT("I::D:")
> "\0"
> "d--s:s--d"
> -@@ -256,6 +260,31 @@ int date_main(int argc UNUSED_PARAM, cha
> +@@ -256,6 +262,31 @@ int date_main(int argc UNUSED_PARAM, char **argv)
> if (*argv)
> bb_show_usage();
>
> @@ -69,7 +65,7 @@
> +
> + /* workaround warp_clock() on first invocation */
> + memset(&tz, 0, sizeof(tz));
> -+ syscall(SYS_settimeofday, NULL, &tz);
> ++ settimeofday(NULL, &tz);
> +
> + memset(&tz, 0, sizeof(tz));
> +#ifdef __USE_MISC
> @@ -78,7 +74,7 @@
> + tz.tz_minuteswest = -(tm_time.__tm_gmtoff / 60);
> +#endif
> +
> -+ if (syscall(SYS_settimeofday, NULL, &tz))
> ++ if (settimeofday(NULL, &tz))
> + {
> + bb_perror_msg("can't set kernel time zone");
> + return EXIT_FAILURE;
> --
> 2.7.4
>
>
> ___
> 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] busybox: use settimeofday() instead of syscall
From: Masafumi UTSUGI
SYS_settimeofday syscall is not time64 safe.
Using settimeofday() instead of syscall() is recommended or
some C libraries such as musl might cause compile error.
Signed-off-by: Masafumi UTSUGI
---
Makefile | 2 +-
patches/250-date-k-flag.patch | 26 +++---
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/Makefile b/Makefile
index 01441d1..baf375e 100644
--- a/Makefile
+++ b/Makefile
@@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=busybox
PKG_VERSION:=1.31.1
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_FLAGS:=essential
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2
diff --git a/patches/250-date-k-flag.patch b/patches/250-date-k-flag.patch
index 5aadbb2..ef0545c 100644
--- a/patches/250-date-k-flag.patch
+++ b/patches/250-date-k-flag.patch
@@ -8,19 +8,15 @@
//usage: "\n"
//usage: "\nRecognized TIME formats:"
//usage: "\n hh:mm[:ss]"
-@@ -139,9 +140,8 @@
-
- #include "libbb.h"
- #include "common_bufsiz.h"
--#if ENABLE_FEATURE_DATE_NANO
--# include
--#endif
+@@ -142,6 +143,7 @@
+ #if ENABLE_FEATURE_DATE_NANO
+ # include
+ #endif
+#include
-+#include
enum {
OPT_RFC2822 = (1 << 0), /* R */
-@@ -149,8 +149,9 @@ enum {
+@@ -149,8 +151,9 @@ enum {
OPT_UTC = (1 << 2), /* u */
OPT_DATE = (1 << 3), /* d */
OPT_REFERENCE = (1 << 4), /* r */
@@ -32,7 +28,7 @@
};
#if ENABLE_LONG_OPTS
-@@ -162,6 +163,7 @@ static const char date_longopts[] ALIGN1
+@@ -162,6 +165,7 @@ static const char date_longopts[] ALIGN1 =
/* "universal\0" No_argument "u" */
"date\0" Required_argument "d"
"reference\0" Required_argument "r"
@@ -40,7 +36,7 @@
;
#endif
-@@ -181,6 +183,8 @@ static void maybe_set_utc(int opt)
+@@ -181,6 +185,8 @@ static void maybe_set_utc(int opt)
int date_main(int argc, char **argv) MAIN_EXTERNALLY_VISIBLE;
int date_main(int argc UNUSED_PARAM, char **argv)
{
@@ -49,7 +45,7 @@
struct timespec ts;
struct tm tm_time;
char buf_fmt_dt2str[64];
-@@ -193,7 +197,7 @@ int date_main(int argc UNUSED_PARAM, cha
+@@ -193,7 +199,7 @@ int date_main(int argc UNUSED_PARAM, char **argv)
char *isofmt_arg = NULL;
opt = getopt32long(argv, "^"
@@ -58,7 +54,7 @@
IF_FEATURE_DATE_ISOFMT("I::D:")
"\0"
"d--s:s--d"
-@@ -256,6 +260,31 @@ int date_main(int argc UNUSED_PARAM, cha
+@@ -256,6 +262,31 @@ int date_main(int argc UNUSED_PARAM, char **argv)
if (*argv)
bb_show_usage();
@@ -69,7 +65,7 @@
+
+ /* workaround warp_clock() on first invocation */
+ memset(&tz, 0, sizeof(tz));
-+ syscall(SYS_settimeofday, NULL, &tz);
++ settimeofday(NULL, &tz);
+
+ memset(&tz, 0, sizeof(tz));
+#ifdef __USE_MISC
@@ -78,7 +74,7 @@
+ tz.tz_minuteswest = -(tm_time.__tm_gmtoff / 60);
+#endif
+
-+ if (syscall(SYS_settimeofday, NULL, &tz))
++ if (settimeofday(NULL, &tz))
+ {
+ bb_perror_msg("can't set kernel time zone");
+ return EXIT_FAILURE;
--
2.7.4
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH 3/4] build: image: remove strange useless comment
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Jo-Philipp Wich > Sent: Donnerstag, 6. August 2020 16:34 > To: openwrt-devel@lists.openwrt.org > Subject: Re: [PATCH 3/4] build: image: remove strange useless comment > > Hi Adrian, > > > compat_version=$(if > > $(DEVICE_COMPAT_VERSION),$(DEVICE_COMPAT_VERSION),1.0) > > json_quote=$(subst ','\'',$(subst ",\",$(1))) > > -#")') > > This commit was most likely added to aid text editors with naive syntax > highlighting capabilities that fail to properly detect the end of the string > due > to the unique Make escape semantics. I'd propose to leave it in place. > > If you want, you could prefix it with something like "fix bad syntax > highlighting: " I see. Thanks for the enlightenment. I will just not touch it and drop the patch. > > ~ Jo 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: Upcoming 19.07.4 and 18.07.9 stable releases
> Hi, > There is also a new mbedtls version which fixes some security bugs, we > should also update this: > https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.7 > Hauke FYI: This PR is marked as 19.07 and also is related to mac80211, but I cannot really judge its content: https://github.com/openwrt/openwrt/pull/3182 Best Adrian 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] ath10k-ct-firmware: update firmware
Fix at least one rare wave-2 crash. Tested on R7800. Signed-off-by: Michael Yartys --- package/firmware/ath10k-ct-firmware/Makefile | 56 ++-- 1 file changed, 28 insertions(+), 28 deletions(-) diff --git a/package/firmware/ath10k-ct-firmware/Makefile b/package/firmware/ath10k-ct-firmware/Makefile index 18370b7d85..10c72ae4c2 100644 --- a/package/firmware/ath10k-ct-firmware/Makefile +++ b/package/firmware/ath10k-ct-firmware/Makefile @@ -95,14 +95,14 @@ define Download/ct-firmware-htt URL_FILE:=$($(1)_FIRMWARE_FILE_CT_HTT) endef -QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018 +QCA988X_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019 define Download/ath10k-firmware-qca988x-ct $(call Download/ct-firmware,QCA988X,) HASH:=8b4c99253aa309d35f2e060c190091b8db1b84dbda06a6a15c83ac0f9a938126 endef $(eval $(call Download,ath10k-firmware-qca988x-ct)) -QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 +QCA988X_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019 define Download/ath10k-firmware-qca988x-ct-full-htt $(call Download/ct-firmware-full-htt,QCA988X,) HASH:=a7168916d6aa5e4d7858f8b620c0c980c76d03f390929db6f4077685ce2051e7 @@ -110,14 +110,14 @@ endef $(eval $(call Download,ath10k-firmware-qca988x-ct-full-htt)) -QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.018 +QCA9887_FIRMWARE_FILE_CT:=firmware-2-ct-full-community-22.bin.lede.019 define Download/ath10k-firmware-qca9887-ct $(call Download/ct-firmware,QCA9887,ath10k-9887) HASH:=459692deb186a63ab8eeddb7ad5d54779266e68ca686e7c46062554db6dca12b endef $(eval $(call Download,ath10k-firmware-qca9887-ct)) -QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.018 +QCA9887_FIRMWARE_FILE_CT_FULL_HTT:=firmware-2-ct-full-htt-mgt-community-22.bin.lede.019 define Download/ath10k-firmware-qca9887-ct-full-htt $(call Download/ct-firmware-full-htt,QCA9887,ath10k-9887) HASH:=fd126a457d0927d0c8ea10d66ef5b67d5e1e0741f8692bb3016bb602d0af3098 @@ -125,90 +125,90 @@ endef $(eval $(call Download,ath10k-firmware-qca9887-ct-full-htt)) -QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 +QCA99X0_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019 define Download/ath10k-firmware-qca99x0-ct $(call Download/ct-firmware,QCA99X0,ath10k-10-4b) - HASH:=cf26eb37524de54af51fe9b2efffc85e0e70ab849e8607ef63ce5a8ecffeaa42 + HASH:=7dc934f934bc4973c9273a4f22cfead8e26ec6f579647af31b718a860eca0a4b endef $(eval $(call Download,ath10k-firmware-qca99x0-ct)) -QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 +QCA99X0_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019 define Download/ath10k-firmware-qca99x0-ct-full-htt $(call Download/ct-firmware-full-htt,QCA99X0,ath10k-10-4b) - HASH:=e9737538d7379e13ad4e4c8c519a63659b5e34a35455ed9ac4399ae8097caabc + HASH:=71a27b245a382fe009938d2826d5c97a90dceb10ddf638325268df91837ea302 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-full-htt)) -QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018 +QCA99X0_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.019 define Download/ath10k-firmware-qca99x0-ct-htt $(call Download/ct-firmware-htt,QCA99X0,ath10k-10-4b) - HASH:=4d4f74afca487d452f244cd48304cf9710d8941eb97a6346a949ed6b6877d657 + HASH:=9ed4fe41e5b0f30172f71ae0fe382dc0aab8aa4f8a898417af4f7ee936575ef6 endef $(eval $(call Download,ath10k-firmware-qca99x0-ct-htt)) -QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.018 +QCA9984_FIRMWARE_FILE_CT:=firmware-5-ct-full-community-12.bin-lede.019 define Download/ath10k-firmware-qca9984-ct $(call Download/ct-firmware,QCA9984,ath10k-9984-10-4b) - HASH:=a6b3d66efe640a430a837f238e91eddcd423eed6b887d3ae19716d87a71fd0b1 + HASH:=32d13f432691fe759ded7d027052e925233adb436cd8f729f85ec3d19ccd1dfd endef $(eval $(call Download,ath10k-firmware-qca9984-ct)) -QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.018 +QCA9984_FIRMWARE_FILE_CT_FULL_HTT:=firmware-5-ct-full-htt-mgt-community-12.bin-lede.019 define Download/ath10k-firmware-qca9984-ct-full-htt $(call Download/ct-firmware-full-htt,QCA9984,ath10k-9984-10-4b) - HASH:=96060227e372b3b210badccbe6b0bd75d9a35335a7a0f2966964e9e89f66b00f + HASH:=e8ab69777bd00b5fc6b1b7acccb55b903553a99932a5b0351602b5f690106588 endef $(eval $(call Download,ath10k-firmware-qca9984-ct-full-htt)) -QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.018 +QCA9984_FIRMWARE_FILE_CT_HTT:=firmware-5-ct-htt-mgt-community-12.bin-lede.019 define Download/ath10k-firmware-qca9984-ct-htt $(call Download/ct-firmware-htt,QCA9984,ath10k-9984-10-4b) - HASH:=ee593fb5724d75c372de02ac7894e1630ee9f909fcb2e2bbf17aadef67cb9d43 + HASH:=74449b303b626e0713b3fd
Re: Upcoming 19.07.4 and 18.07.9 stable releases
On 8/6/20 11:46 PM, Adrian Schmutzler wrote: >>> In addition to the stated goals, we should also do a kernel bump. >>> Currently we have 4.14.187 and 4.9.229. >> Hi, >> I would also like to have a release for 19.07 and 18.06. >> I started the update to kernel version 4.14.191 for 19.07 here: >> https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/openwrt-19.07 >> >> I plan to do the same for 18.06 too. >> In addition I will update mac80211 in 19.07 and master to the latest >> stable version. >> Hauke > > Thanks, I plan to add the wpad-basic-wolfssl "package" to master tomorrow, > and then would like to backport it (_not_ by default, of course) to 19.07 > before the bump as well. > > Best > > Adrian > Hi, There is also a new mbedtls version which fixes some security bugs, we should also update this: https://github.com/ARMmbed/mbedtls/releases/tag/mbedtls-2.16.7 Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: ramips/rt**** and kernel 5.4
> -Original Message- > From: Eneas Queiroz [mailto:cotequei...@gmail.com] > Sent: Donnerstag, 6. August 2020 23:29 > To: Adrian Schmutzler > Cc: OpenWrt Development List > Subject: Re: ramips/rt and kernel 5.4 > > On Thu, Aug 6, 2020 at 6:13 PM Adrian Schmutzler > wrote: > > > > > I've tested 5.4 (a3ffeb413b to be precise) with an Asus RT-N56U > > > (rt3883) lightly, and all appears to be in order. It is a backup > > > remote AP with light traffic. There is nothing unusual in the logs, > > > and the single client I have there can connect fine. I imagine this > > > would be enough to avoid dropping support for rt3883. > > > > Thanks, perfect, would you provide a Tested-by? > > > > Best > > > > Adrian > Tested-by: Eneas U de Queiroz [rt3883/Asus RT- > N56U] Thanks, I've just bumped it to 5.4 in master. So, only rt288x is left, with only 1 device > 4 MiB flash. Best Adrian 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 v2] busybox: bump to 1.32.0
On 7/28/20 10:14 AM, Petr Štetiar wrote: > Refreshed patches and config options. Removed upstreamed patches: > > 001-remove-stime-function-calls.patch > 110-no_static_libgcc.patch > > Run tested on x86_64 under QEMU. > > Signed-off-by: Petr Štetiar Acked-by: Hauke Mehrtens Tested on lantiq mips. > --- > > changed in v2: > > * refreshed config options > > package/utils/busybox/Config-defaults.in | 21 +++ > package/utils/busybox/Makefile| 4 +- > package/utils/busybox/config/Config.in| 18 ++- > .../utils/busybox/config/archival/Config.in | 2 +- > .../utils/busybox/config/coreutils/Config.in | 3 +- > .../utils/busybox/config/editors/Config.in| 2 +- > .../utils/busybox/config/findutils/Config.in | 8 ++ > .../utils/busybox/config/miscutils/Config.in | 7 + > .../utils/busybox/config/networking/Config.in | 6 + > package/utils/busybox/config/shell/Config.in | 124 ++ > .../utils/busybox/config/sysklogd/Config.in | 8 ++ > .../utils/busybox/config/util-linux/Config.in | 10 +- > .../001-remove-stime-function-calls.patch | 84 > .../patches/110-no_static_libgcc.patch| 11 -- > .../busybox/patches/120-lto-jobserver.patch | 6 +- > .../patches/200-udhcpc_reduce_msgs.patch | 4 +- > .../patches/201-udhcpc_changed_ifindex.patch | 2 +- > .../203-udhcpc_renew_no_deconfig.patch| 2 +- > .../patches/230-add_nslookup_lede.patch | 6 +- > .../busybox/patches/250-date-k-flag.patch | 14 +- > 20 files changed, 169 insertions(+), 173 deletions(-) > delete mode 100644 > package/utils/busybox/patches/001-remove-stime-function-calls.patch > delete mode 100644 package/utils/busybox/patches/110-no_static_libgcc.patch > signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: Upcoming 19.07.4 and 18.07.9 stable releases
> > In addition to the stated goals, we should also do a kernel bump. > > Currently we have 4.14.187 and 4.9.229. > Hi, > I would also like to have a release for 19.07 and 18.06. > I started the update to kernel version 4.14.191 for 19.07 here: > https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/openwrt-19.07 > > I plan to do the same for 18.06 too. > In addition I will update mac80211 in 19.07 and master to the latest > stable version. > Hauke Thanks, I plan to add the wpad-basic-wolfssl "package" to master tomorrow, and then would like to backport it (_not_ by default, of course) to 19.07 before the bump as well. Best Adrian 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: Upcoming 19.07.4 and 18.07.9 stable releases
On 8/4/20 4:59 PM, m...@adrianschmutzler.de wrote: >> -Original Message- >> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] >> On Behalf Of Baptiste Jonglez >> Sent: Donnerstag, 30. Juli 2020 20:58 >> To: openwrt-devel@lists.openwrt.org >> Cc: Thomas Endt >> Subject: Upcoming 19.07.4 and 18.07.9 stable releases >> >> Hi, >> >> New point releases for 19.07 and 18.06 are starting to be overdue, and I >> would like to help 19.07.4 and 18.06.9 get released somewhere around mid- >> August. >> >> The main motivation are fixes for a libubox regression and for the musl >> synchronisation bug, as well as a LuCI regression (see "release goals" >> below). But there are many other fixes, mostly device-related, that also >> motivate these new point releases. If you have more fixes to backport, >> please consider doing so soon, especially for 18.06.9 which will likely be >> the >> last release for 18.06. > > In addition to the stated goals, we should also do a kernel bump. > Currently we have 4.14.187 and 4.9.229. Hi, I would also like to have a release for 19.07 and 18.06. I started the update to kernel version 4.14.191 for 19.07 here: https://git.openwrt.org/?p=openwrt/staging/hauke.git;a=shortlog;h=refs/heads/openwrt-19.07 I plan to do the same for 18.06 too. In addition I will update mac80211 in 19.07 and master to the latest stable version. Hauke signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [OpenWrt-Devel] [PATCH] build: reflect DEVICE_TYPE to top level config
Hi,
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Linus Walleij
> Sent: Freitag, 29. Mai 2020 14:21
> To: openwrt-devel@lists.openwrt.org
> Cc: Linus Walleij
> Subject: [OpenWrt-Devel] [PATCH] build: reflect DEVICE_TYPE to top level
> config
>
> I made a patch to select a tool inside busybox by default on NAS type boxes,
> but this does not properly work because the package and image build
> processes are cleanly separate entities.
>
> I also noticed that this becomes a problem if you build multiple profiles:
> maybe one of them is NAS and one of them is a router. You still want the
> least common denominator to decide: if you selected both NAS:es and
> routers, build packages that will be suitable for both NAS and routers.
>
> To achieve this I reflect the DEVICE_TYPE up to the Kconfig level and define
> two Kconfig symbols:
>
> config DEVICE_TYPE_ROUTER
>bool
>
> config DEVICE_TYPE_NAS
>bool
I just had a look at this again, and had a different idea:
You could exploit the "FEATURES" at the target/subtarget level, as e.g. done
for small_flash:
E.g. at ath79/tiny "small_flash" is added to FEATURES:
https://github.com/openwrt/openwrt/blob/80c61c161ac5943137ade233d62cf89d746de5a2/target/linux/ath79/tiny/target.mk#L2
Then a config symbol SMALL_FLASH is defined:
https://github.com/openwrt/openwrt/blob/4a0f426ba5044af2fe45be8cc553f1580484883c/target/Config.in#L79
This CONFIG would be selected based on FEATURES in target_metadata.pl:
https://github.com/openwrt/openwrt/blob/e9f7923a1d4b327ef4b9ac25fbe197f2b4ea61d7/scripts/target-metadata.pl#L40
And then you could make other config symbols dependent on the config symbol,
e.g.
https://github.com/openwrt/openwrt/blob/7f2b230b3b9d0a7fb758db3a9b1958845506a5a3/package/libs/openssl/Config.in#L19
This could essentially work the same way for a feature "nas". You could then
either use CONFIG_NAS directly or, as in the last example, via dependencies. I
think this would actually be the easiest way to get this working for switching
stuff in packages.
Best
Adrian
>
> These will be set from the DEVICE_TYPE of each profile and it is possible to
> select both.
>
> I then modify the busybox config to take this into account and conditionally
> build hdparm for CONFIG_DEVICE_TYPE_NAS.
>
> Signed-off-by: Linus Walleij
> ---
> include/image.mk | 1 +
> include/target.mk | 1 +
> package/utils/busybox/Makefile | 2 +-
> scripts/metadata.pm| 2 ++
> scripts/target-metadata.pl | 12
> 5 files changed, 17 insertions(+), 1 deletion(-)
>
> diff --git a/include/image.mk b/include/image.mk index
> 984b64fb9c73..8104c040a1f7 100644
> --- a/include/image.mk
> +++ b/include/image.mk
> @@ -634,6 +634,7 @@ endef
> define Device/DumpInfo
> Target-Profile: DEVICE_$(1)
> Target-Profile-Name: $(DEVICE_DISPLAY)
> +Target-Profile-Devicetype: $(DEVICE_TYPE)
> Target-Profile-Packages: $(DEVICE_PACKAGES)
> Target-Profile-hasImageMetadata: $(if $(foreach
> image,$(IMAGES),$(findstring append-metadata,$(IMAGE/$(image,1,0)
> Target-Profile-SupportedDevices: $(SUPPORTED_DEVICES) diff --git
> a/include/target.mk b/include/target.mk index 9bd4c14936c1..e6f26cbfdf3d
> 100644
> --- a/include/target.mk
> +++ b/include/target.mk
> @@ -73,6 +73,7 @@ define Profile
> echo "Target-Profile: $(1)"; \
> $(if $(PRIORITY), echo "Target-Profile-Priority: $(PRIORITY)"; ) \
> echo "Target-Profile-Name: $(NAME)"; \
> + echo "Target-Profile-Devicetype: $(DEVICE_TYPE)"; \
> echo "Target-Profile-Packages: $(PACKAGES) $(call
> extra_packages,$(DEFAULT_PACKAGES) $(PACKAGES))"; \
> echo "Target-Profile-Description:"; \
> echo "$(call shvar,Profile/$(1)/Description)"; \ diff --git
> a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index
> 01441d1e87d1..f504117f60f3 100644
> --- a/package/utils/busybox/Makefile
> +++ b/package/utils/busybox/Makefile
> @@ -94,7 +94,7 @@ endif
> define Build/Configure
> rm -f $(PKG_BUILD_DIR)/.config
> touch $(PKG_BUILD_DIR)/.config
> -ifeq ($(DEVICE_TYPE),nas)
> +ifeq ($(CONFIG_DEVICE_TYPE_NAS),y)
> echo "CONFIG_HDPARM=y" >> $(PKG_BUILD_DIR)/.config endif
> grep 'CONFIG_BUSYBOX_$(BUSYBOX_SYM)' $(TOPDIR)/.config | sed
> -e "s,\\(#
> \)\\?CONFIG_BUSYBOX_$(BUSYBOX_SYM)_\\(.*\\),\\1CONFIG_\\2,g" >>
> $(PKG_BUILD_DIR)/.config diff --git a/scripts/metadata.pm
> b/scripts/metadata.pm index 1826a040a116..5062dba37ec0 100644
> --- a/scripts/metadata.pm
> +++ b/scripts/metadata.pm
> @@ -140,6 +140,7 @@ sub parse_target_metadata($) {
> $profile = {
> id => $1,
> name => $1,
> + device_type => "router",
> has_image_metadata => 0,
> supported_devices => [],
>
Re: ramips/rt**** and kernel 5.4
On Thu, Aug 6, 2020 at 6:13 PM Adrian Schmutzler wrote: > > > I've tested 5.4 (a3ffeb413b to be precise) with an Asus RT-N56U > > (rt3883) lightly, and all appears to be in order. It is a backup remote AP > > with > > light traffic. There is nothing unusual in the logs, and the single client > > I have > > there can connect fine. I imagine this would be enough to avoid dropping > > support for rt3883. > > Thanks, perfect, would you provide a Tested-by? > > Best > > Adrian Tested-by: Eneas U de Queiroz [rt3883/Asus RT-N56U] ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: ramips/rt**** and kernel 5.4
> -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Eneas Queiroz > Sent: Donnerstag, 6. August 2020 20:37 > To: m...@adrianschmutzler.de > Cc: OpenWrt Development List > Subject: Re: ramips/rt and kernel 5.4 > > Hi > > On Sat, Aug 1, 2020 at 10:54 AM wrote: > > > > Hi, > > > > with a 20.xx branch coming closer, we still have 3 of 6 ramips subtargets > (rt288x, rt305x, rt3883) on kernel 4.14 by default (though 5.4 testing support > is available in principle). > > > > I've recently tried to build those with 5.4 and buildbot settings (including > packages), they all compile nicely (4M devices have already been disabled) > out-of-the-box. > > > > However, I don't have any devices for these platforms, and I have not > followed the ramips 5.4 transitions closely enough to know which problems > might appear on the devices. > > > > At the moment, we have the following number of supported devices (i.e. > > 4M): > > rt288x: 1 device > > rt305x: 57 devices > > rt3883: 10 devices > > I've tested 5.4 (a3ffeb413b to be precise) with an Asus RT-N56U > (rt3883) lightly, and all appears to be in order. It is a backup remote AP > with > light traffic. There is nothing unusual in the logs, and the single client I > have > there can connect fine. I imagine this would be enough to avoid dropping > support for rt3883. Thanks, perfect, would you provide a Tested-by? Best Adrian > > Cheers, > > Eneas > > > > So, any input on the situation on those platform and/or on-device testing > would be quite helpful. > > > > Otherwise, we would have to drop these subtargets for 20.xx release. > > > > Best > > > > Adrian > > ___ > 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 v2] tools/firmware-utils: use UTC for image timestamps
By using localtime() to determine the timestamp that goes into factory
images, the resulting image depends on the timezone of the build system.
Use gmtime() instead, which results in more reproducible images.
Signed-off-by: Sander Vanheule
---
tools/firmware-utils/Makefile| 2 +-
tools/firmware-utils/src/addpattern.c| 2 +-
tools/firmware-utils/src/tplink-safeloader.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/tools/firmware-utils/Makefile b/tools/firmware-utils/Makefile
index ee0ef3a6fd..4fcda7e439 100644
--- a/tools/firmware-utils/Makefile
+++ b/tools/firmware-utils/Makefile
@@ -7,7 +7,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME := firmware-utils
-PKG_RELEASE := 1
+PKG_RELEASE := 2
include $(INCLUDE_DIR)/host-build.mk
include $(INCLUDE_DIR)/kernel.mk
diff --git a/tools/firmware-utils/src/addpattern.c
b/tools/firmware-utils/src/addpattern.c
index 9bc4865335..9791527878 100644
--- a/tools/firmware-utils/src/addpattern.c
+++ b/tools/firmware-utils/src/addpattern.c
@@ -296,7 +296,7 @@ int main(int argc, char **argv)
return EXIT_FAILURE;
}
- ptm = localtime(&t);
+ ptm = gmtime(&t);
if (3 != sscanf(version, "v%d.%d.%d", &v0, &v1, &v2)) {
fprintf(stderr, "bad version string \"%s\"\n", version);
diff --git a/tools/firmware-utils/src/tplink-safeloader.c
b/tools/firmware-utils/src/tplink-safeloader.c
index a5f3ced16d..0af1fe4c6e 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -2079,7 +2079,7 @@ static struct image_partition_entry
make_soft_version(uint32_t rev) {
else if (time(&t) == (time_t)(-1))
error(1, errno, "time");
- struct tm *tm = localtime(&t);
+ struct tm *tm = gmtime(&t);
s->magic = htonl(0x000c);
s->zero = 0;
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] tools/firmware-utils: use UTC for image timestamps
Please increase the PKG_RELEASE on code changes.
On 06.08.20 09:10, Sander Vanheule wrote:
By using localtime() to determine the timestamp that goes into factory
images, the resulting image depends on the timezone of the build system.
Use gmtime() instead, which results in more reproducible images.
Signed-off-by: Sander Vanheule
---
Tested by building factory images with tplink-safeloader
tools/firmware-utils/src/addpattern.c| 2 +-
tools/firmware-utils/src/tplink-safeloader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/firmware-utils/src/addpattern.c
b/tools/firmware-utils/src/addpattern.c
index 9bc4865335..9791527878 100644
--- a/tools/firmware-utils/src/addpattern.c
+++ b/tools/firmware-utils/src/addpattern.c
@@ -296,7 +296,7 @@ int main(int argc, char **argv)
return EXIT_FAILURE;
}
- ptm = localtime(&t);
+ ptm = gmtime(&t);
if (3 != sscanf(version, "v%d.%d.%d", &v0, &v1, &v2)) {
fprintf(stderr, "bad version string \"%s\"\n", version);
diff --git a/tools/firmware-utils/src/tplink-safeloader.c
b/tools/firmware-utils/src/tplink-safeloader.c
index a5f3ced16d..0af1fe4c6e 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -2079,7 +2079,7 @@ static struct image_partition_entry
make_soft_version(uint32_t rev) {
else if (time(&t) == (time_t)(-1))
error(1, errno, "time");
- struct tm *tm = localtime(&t);
+ struct tm *tm = gmtime(&t);
s->magic = htonl(0x000c);
s->zero = 0;
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] tools/firmware-utils: use UTC for image timestamps
By using localtime() to determine the timestamp that goes into factory
images, the resulting image depends on the timezone of the build system.
Use gmtime() instead, which results in more reproducible images.
Signed-off-by: Sander Vanheule
---
Tested by building factory images with tplink-safeloader
tools/firmware-utils/src/addpattern.c| 2 +-
tools/firmware-utils/src/tplink-safeloader.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/tools/firmware-utils/src/addpattern.c
b/tools/firmware-utils/src/addpattern.c
index 9bc4865335..9791527878 100644
--- a/tools/firmware-utils/src/addpattern.c
+++ b/tools/firmware-utils/src/addpattern.c
@@ -296,7 +296,7 @@ int main(int argc, char **argv)
return EXIT_FAILURE;
}
- ptm = localtime(&t);
+ ptm = gmtime(&t);
if (3 != sscanf(version, "v%d.%d.%d", &v0, &v1, &v2)) {
fprintf(stderr, "bad version string \"%s\"\n", version);
diff --git a/tools/firmware-utils/src/tplink-safeloader.c
b/tools/firmware-utils/src/tplink-safeloader.c
index a5f3ced16d..0af1fe4c6e 100644
--- a/tools/firmware-utils/src/tplink-safeloader.c
+++ b/tools/firmware-utils/src/tplink-safeloader.c
@@ -2079,7 +2079,7 @@ static struct image_partition_entry
make_soft_version(uint32_t rev) {
else if (time(&t) == (time_t)(-1))
error(1, errno, "time");
- struct tm *tm = localtime(&t);
+ struct tm *tm = gmtime(&t);
s->magic = htonl(0x000c);
s->zero = 0;
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Archer C50v1 causing "transmit queue 0 timed out" on other devices
Hi, I have an Archer C50v1 running gluon based on "19.07-SNAPSHOT r11019+10-5feb0df9bb" It seems to cause "transmit queue 0 timed out"[1] of a r8169 system. First I thought the r8169 nic is broken and changed the motherboard, but with another board with r8169 the issue is also appearing. Changing the switch did not help either. Sometimes the r8169 box is completely unreachable until I power off the Archer C50v1. Now I stumbled upon the mt7621 Flow Control thread and I'm just wondering if this issue is related. Cheers, Bjoern [1] https://p.rrbone.net/paste/sK5YP9yj#-J2yUQyP4w8q8ciD25KbPAc2y2DO0y7a+o8Xial2UHD ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ramips/rt**** and kernel 5.4
Hi On Sat, Aug 1, 2020 at 10:54 AM wrote: > > Hi, > > with a 20.xx branch coming closer, we still have 3 of 6 ramips subtargets > (rt288x, rt305x, rt3883) on kernel 4.14 by default (though 5.4 testing > support is available in principle). > > I've recently tried to build those with 5.4 and buildbot settings (including > packages), they all compile nicely (4M devices have already been disabled) > out-of-the-box. > > However, I don't have any devices for these platforms, and I have not > followed the ramips 5.4 transitions closely enough to know which problems > might appear on the devices. > > At the moment, we have the following number of supported devices (i.e. > 4M): > rt288x: 1 device > rt305x: 57 devices > rt3883: 10 devices I've tested 5.4 (a3ffeb413b to be precise) with an Asus RT-N56U (rt3883) lightly, and all appears to be in order. It is a backup remote AP with light traffic. There is nothing unusual in the logs, and the single client I have there can connect fine. I imagine this would be enough to avoid dropping support for rt3883. Cheers, Eneas > > So, any input on the situation on those platform and/or on-device testing > would be quite helpful. > > Otherwise, we would have to drop these subtargets for 20.xx release. > > Best > > Adrian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [PATCH v2 3/3] apm821xx: set DEVICE_TYPE to "nas" for sata subtarget
Hi, > -Original Message- > From: Linus Walleij [mailto:linus.wall...@linaro.org] > Sent: Donnerstag, 6. August 2020 16:57 > To: Adrian Schmutzler > Cc: OpenWrt Development List ; > Christian Lamparter ; Sungbo Eo > > Subject: Re: [PATCH v2 3/3] apm821xx: set DEVICE_TYPE to "nas" for sata > subtarget > > Hi Adrian, > > I got back to trying to fix the NAS packages for the Gemini. > > On Sat, May 30, 2020 at 11:29 AM Adrian Schmutzler > wrote: > > > Since DEVICE_TYPE cannot be set per device, just set DEVICE_TYPE to > > "nas" for the entire subtarget, which only contains this single > > device. > > > > Note that while this looks like a cosmetic change in combination with > > the previous patches, this particular patch actually changes the > > packages for the device. > > > > Suggested-by: Christian Lamparter > > Cc: Christian Lamparter > > Cc: Sungbo Eo > > Cc: Linus Walleij > > Signed-off-by: Adrian Schmutzler > > So if I understand correctly, what I need to do it to split Gemini into > subtargets (such as "boots from flash" and "boots from harddisk") like the > APM does, so I can establish two profiles, and then that means I can also > split > the Makefile for the images like the APM does? the question is what's your goal at the end. Just taking care of adding/removing packages can be done for the device individually without touching DEVICE_TYPE at all. Switching parameters in packages based on a DEVICE_TYPE will be another story, I remember that Matthias said it currently was broken anyway IIRC. We would technically also still have the option to make DEVICE_TYPE a real per-device variable, but then this would only work for package _selection_ again. If you really desire to change package config stuff, you will indeed need a "NAS" subtarget then. And then you'd still have to check whether the package is really built "per-subtarget", and not just per arch or similar ... So, as you see, it's hard to discuss this in general, but we would need to base the discussion on the individual packages affected. Best Adrian > > Yours, > Linus Walleij 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 v2 3/3] apm821xx: set DEVICE_TYPE to "nas" for sata subtarget
Hi Adrian, I got back to trying to fix the NAS packages for the Gemini. On Sat, May 30, 2020 at 11:29 AM Adrian Schmutzler wrote: > Since DEVICE_TYPE cannot be set per device, just set DEVICE_TYPE > to "nas" for the entire subtarget, which only contains this single > device. > > Note that while this looks like a cosmetic change in combination > with the previous patches, this particular patch actually changes > the packages for the device. > > Suggested-by: Christian Lamparter > Cc: Christian Lamparter > Cc: Sungbo Eo > Cc: Linus Walleij > Signed-off-by: Adrian Schmutzler So if I understand correctly, what I need to do it to split Gemini into subtargets (such as "boots from flash" and "boots from harddisk") like the APM does, so I can establish two profiles, and then that means I can also split the Makefile for the images like the APM does? Yours, Linus Walleij ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 3/4] build: image: remove strange useless comment
Hi Adrian, > compat_version=$(if $(DEVICE_COMPAT_VERSION),$(DEVICE_COMPAT_VERSION),1.0) > json_quote=$(subst ','\'',$(subst ",\",$(1))) > -#")') This commit was most likely added to aid text editors with naive syntax highlighting capabilities that fail to properly detect the end of the string due to the unique Make escape semantics. I'd propose to leave it in place. If you want, you could prefix it with something like "fix bad syntax highlighting: " ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 4/4] build: improve message for incompatible image on "legacy" devices
It has been reported that the current message displayed during
upgrade with compat_version change is misleading for "legacy"
devices, i.e. those without the "new" fwtool. This is partially
caused by the fact that we need to exploit the supported_devices
string to get some message text displayed for these devices.
This patch modifies the message to make it more helpful and
include additional information, e.g.
Device linksys,wrt3200acm not supported by this image
Supported devices: linksys,wrt3200acm linksys-whateverelse - Image
version mismatch: image 1.1, device 1.0. Please wipe config during
upgrade (force required) or reinstall. Reason: Config cannot be
migrated from swconfig to DSA
Note that the line breaks (except the one before Supported devices)
are added manually here, I hesitate to hack \n into the
supported_devices as well. The "Reason:" will only be displayed if
DEVICE_COMPAT_MESSAGE is set for the device, otherwise
"Please check documentation ..." will be shown instead.
While at it, also rearrange the code in image-commands.mk to
make lines shorter and remove the double filter-out command.
Signed-off-by: Adrian Schmutzler
---
include/image-commands.mk | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/include/image-commands.mk b/include/image-commands.mk
index 089ed93c67..74d9877698 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -382,15 +382,19 @@ endef
compat_version=$(if $(DEVICE_COMPAT_VERSION),$(DEVICE_COMPAT_VERSION),1.0)
json_quote=$(subst ','\'',$(subst ",\",$(1)))
+legacy_supported_message=$(SUPPORTED_DEVICES) - Image version mismatch: image
$(compat_version), \
+ device 1.0. Please wipe config during upgrade (force required) or
reinstall. \
+ $(if $(DEVICE_COMPAT_MESSAGE),Reason: $(DEVICE_COMPAT_MESSAGE),Please
check documentation ...)
+
metadata_devices=$(if $(1),$(subst "$(space)","$(comma)",$(strip $(foreach
v,$(1),"$(call json_quote,$(v))"
metadata_json = \
'{ $(if $(IMAGE_METADATA),$(IMAGE_METADATA)$(comma)) \
"metadata_version": "1.1", \
"compat_version": "$(call json_quote,$(compat_version))", \
$(if $(DEVICE_COMPAT_MESSAGE),"compat_message": "$(call
json_quote,$(DEVICE_COMPAT_MESSAGE))"$(comma)) \
- $(if $(filter-out
1.0,$(compat_version)),"new_supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
- $(if $(filter-out 1.0,$(compat_version)),"supported_devices": \
- ["$(call json_quote,Image version $(compat_version)
incompatible to device: $(if
$(DEVICE_COMPAT_MESSAGE),$(DEVICE_COMPAT_MESSAGE),Please check documentation
...))"]$(comma)) \
+ $(if $(filter-out
1.0,$(compat_version)),"new_supported_devices": \
+ [$(call metadata_devices,$(SUPPORTED_DEVICES))]$(comma)
\
+ "supported_devices": ["$(call
json_quote,$(legacy_supported_message))"]$(comma)) \
$(if $(filter
1.0,$(compat_version)),"supported_devices":[$(call
metadata_devices,$(SUPPORTED_DEVICES))]$(comma)) \
"version": { \
"dist": "$(call json_quote,$(VERSION_DIST))", \
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/4] mvebu: fix sysupgrade experience for early DSA-adopters
Conceptually, the compat-version during sysupgrade is meant to describe the config. Therefore, if somebody starts with a device on 19.07 and swconfig, and that person does a forceful upgrade into a DSA-based firmware without wiping his/her config, then the local compat-version should stay at 1.0 according to the config present (and not get updated). However, this poses a problem for those people that early-adopted DSA in master, as they already have adjusted their config for DSA, but it still is "1.0" as far as sysupgrade is concerned. This can be healed by a simple uci set system.@system[0].compat_version="1.1" uci commit system But this needs to be applied _after_ the upgrade (as the "old" fwtool on the old installation does not know about compat_version) and it requires access via SSH (i.e. no pure GUI solution is available for this group of people, apart from wiping their config _again_ for no technical reason). Despite, the situation will not become obvious to those just upgrading via GUI, they will just have the experience of a "broken upgrade". This is a conflict which cannot be resolved by achieving both goals, we have to decide to either keep the strict concept or improve the situation for early adopters. In this patch, we address the issue by providing a uci-defaults script that will raise the compat_version for _all_ people upgrading into a 1.1 image, no matter whether they have reset config or not. The idea is implement this as a _temporary_ solution, so early adopters can upgrade into the new mechanism without issues, and after a few weeks/months we could remove the uci-defaults script again. If we e.g. remove the script just before 20.xx.0-rc1, early adopters should have moved on by then, and existing stable users would still get the intended experience. Signed-off-by: Adrian Schmutzler --- .../etc/uci-defaults/05_fix-compat-version| 21 +++ 1 file changed, 21 insertions(+) create mode 100644 target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version diff --git a/target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version b/target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version new file mode 100644 index 00..5965fdc2f5 --- /dev/null +++ b/target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version @@ -0,0 +1,21 @@ +# +# Copyright (C) 2020 OpenWrt.org +# + +. /lib/functions.sh + +case "$(board_name)" in + linksys,wrt1200ac|\ + linksys,wrt1900ac-v1|\ + linksys,wrt1900ac-v2|\ + linksys,wrt1900acs|\ + linksys,wrt3200acm|\ + linksys,wrt32x|\ + solidrun,clearfog-base-a1|\ + solidrun,clearfog-pro-a1) + uci set system.@system[0].compat_version="1.1" + uci commit system + ;; +esac + +exit 0 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/4] Improve upgrade experience with compat_version
This patchset aims at improving the user experience for sysupgrade with compat_version as based on recent reports from users. Adrian Schmutzler (4): mvebu: fix sysupgrade experience for early DSA-adopters kirkwood: fix sysupgrade experience for early DSA-adopters build: image: remove strange useless comment build: improve message for incompatible image on "legacy" devices include/image-commands.mk | 12 +++ .../etc/uci-defaults/05_fix-compat-version| 16 ++ .../etc/uci-defaults/05_fix-compat-version| 21 +++ 3 files changed, 45 insertions(+), 4 deletions(-) create mode 100644 target/linux/kirkwood/base-files/etc/uci-defaults/05_fix-compat-version create mode 100644 target/linux/mvebu/cortexa9/base-files/etc/uci-defaults/05_fix-compat-version -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 3/4] build: image: remove strange useless comment
This "comment" seems to be a leftover from some development work.
Remove it.
Fixes: 77265e00c70a ("build: add support code for appending metadata to images")
Signed-off-by: Adrian Schmutzler
---
include/image-commands.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/image-commands.mk b/include/image-commands.mk
index 8ed705a7f4..089ed93c67 100644
--- a/include/image-commands.mk
+++ b/include/image-commands.mk
@@ -381,7 +381,7 @@ endef
compat_version=$(if $(DEVICE_COMPAT_VERSION),$(DEVICE_COMPAT_VERSION),1.0)
json_quote=$(subst ','\'',$(subst ",\",$(1)))
-#")')
+
metadata_devices=$(if $(1),$(subst "$(space)","$(comma)",$(strip $(foreach
v,$(1),"$(call json_quote,$(v))"
metadata_json = \
'{ $(if $(IMAGE_METADATA),$(IMAGE_METADATA)$(comma)) \
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/4] kirkwood: fix sysupgrade experience for early DSA-adopters
Conceptually, the compat-version during sysupgrade is meant to describe the config. Therefore, if somebody starts with a device on 19.07 and swconfig, and that person does a forceful upgrade into a DSA-based firmware without wiping his/her config, then the local compat-version should stay at 1.0 according to the config present (and not get updated). However, this poses a problem for those people that early-adopted DSA in master, as they already have adjusted their config for DSA, but it still is "1.0" as far as sysupgrade is concerned. This can be healed by a simple uci set system.@system[0].compat_version="1.1" uci commit system But this needs to be applied _after_ the upgrade (as the "old" fwtool on the old installation does not know about compat_version) and it requires access via SSH (i.e. no pure GUI solution is available for this group of people, apart from wiping their config _again_ for no technical reason). Despite, the situation will not become obvious to those just upgrading via GUI, they will just have the experience of a "broken upgrade". This is a conflict which cannot be resolved by achieving both goals, we have to decide to either keep the strict concept or improve the situation for early adopters. In this patch, we address the issue by providing a uci-defaults script that will raise the compat_version for _all_ people upgrading into a 1.1 image, no matter whether they have reset config or not. The idea is implement this as a _temporary_ solution, so early adopters can upgrade into the new mechanism without issues, and after a few weeks/months we could remove the uci-defaults script again. If we e.g. remove the script just before 20.xx.0-rc1, early adopters should have moved on by then, and existing stable users would still get the intended experience. Signed-off-by: Adrian Schmutzler --- .../etc/uci-defaults/05_fix-compat-version | 16 1 file changed, 16 insertions(+) create mode 100644 target/linux/kirkwood/base-files/etc/uci-defaults/05_fix-compat-version diff --git a/target/linux/kirkwood/base-files/etc/uci-defaults/05_fix-compat-version b/target/linux/kirkwood/base-files/etc/uci-defaults/05_fix-compat-version new file mode 100644 index 00..d7f8488e88 --- /dev/null +++ b/target/linux/kirkwood/base-files/etc/uci-defaults/05_fix-compat-version @@ -0,0 +1,16 @@ +# +# Copyright (C) 2020 OpenWrt.org +# + +. /lib/functions.sh + +case "$(board_name)" in + linksys,e4200-v2|\ + linksys,ea3500|\ + linksys,ea4500) + uci set system.@system[0].compat_version="1.1" + uci commit system + ;; +esac + +exit 0 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH uhttpd] ubus: rename JSON-RPC format related functions
Hi, > Use "_json_rpc_" in their names so it's clear they are related to the > JSON-RPC format. This cleans up code a bit and will allow adding more > formats in the future. > > Signed-off-by: Rafał Miłecki Acked-by: Jo-Philipp Wich signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT7621 Flow Control
On Thu, Aug 6, 2020 at 2:35 PM John Crispin wrote: > > > On 06.08.20 14:31, Andre Valentin wrote: > > Hi Jaap, > > > > > > Am 06.08.20 um 13:43 schrieb Jaap Buurman: > >> Dear all, > >> > >> I have noticed the flow control work for mt7621 in the following > >> Openwrt patch: > >> https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0 > >> > >> However, the problem that the patch is supposed to fix is still > >> occurring, even in combination with other experimental patches > >> submitted. These experiences can be read about here: > >> https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/5/ > >> > >> However, on this mailing list a user by the name of Kristian claims > >> that disabling flow control helps fix this problem, as can be read > >> here: > >> https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html > >> > >> From what I understood, he was running many mt7621 devices > >> commercially, with many of them experiencing the issue, which were all > >> fixed with his own flow control patch. My question is why the decision > >> was made to only disable flow control on port 5 in the above mentioned > >> Openwrt patch? AFAIK, Kristian's own patch disables flow control on > >> all of the ports and he claims the issue is fixed for him. Perhaps the > >> current patch should be extended to disable flow control on all ports? > >> What are people's thoughts on this? > > I'm facing the same issue now after upgrading to 5.4 kernel more often than > > before. > > Every second reboot reboot with 5.4 fails with this timeout error. > > > >> Yours sincerely, > >> > >> Jaap > > André > > > > > from previous discussions with MTK and looking at the SDK code, the flow > control should always be disabled. > > John > Dear John, Thank you for your information! Does that mean the current patch might be insufficient in the sense that it only disabled flow control on port 5, rather than on all ports? Because as evident, people are still facing the issue, that is supposedly fixed for Kristian, which used his own patch to disable Flow Control on all ports. What is your opinion on this? Jaap ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT7621 Flow Control
Hi Jaap, Am 06.08.20 um 13:43 schrieb Jaap Buurman: > Dear all, > > I have noticed the flow control work for mt7621 in the following > Openwrt patch: > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0 > > However, the problem that the patch is supposed to fix is still > occurring, even in combination with other experimental patches > submitted. These experiences can be read about here: > https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/5/ > > However, on this mailing list a user by the name of Kristian claims > that disabling flow control helps fix this problem, as can be read > here: > https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html > > From what I understood, he was running many mt7621 devices > commercially, with many of them experiencing the issue, which were all > fixed with his own flow control patch. My question is why the decision > was made to only disable flow control on port 5 in the above mentioned > Openwrt patch? AFAIK, Kristian's own patch disables flow control on > all of the ports and he claims the issue is fixed for him. Perhaps the > current patch should be extended to disable flow control on all ports? > What are people's thoughts on this? I'm facing the same issue now after upgrading to 5.4 kernel more often than before. Every second reboot reboot with 5.4 fails with this timeout error. > > Yours sincerely, > > Jaap André smime.p7s Description: S/MIME Cryptographic Signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: MT7621 Flow Control
On 06.08.20 14:31, Andre Valentin wrote: Hi Jaap, Am 06.08.20 um 13:43 schrieb Jaap Buurman: Dear all, I have noticed the flow control work for mt7621 in the following Openwrt patch: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0 However, the problem that the patch is supposed to fix is still occurring, even in combination with other experimental patches submitted. These experiences can be read about here: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/5/ However, on this mailing list a user by the name of Kristian claims that disabling flow control helps fix this problem, as can be read here: https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html From what I understood, he was running many mt7621 devices commercially, with many of them experiencing the issue, which were all fixed with his own flow control patch. My question is why the decision was made to only disable flow control on port 5 in the above mentioned Openwrt patch? AFAIK, Kristian's own patch disables flow control on all of the ports and he claims the issue is fixed for him. Perhaps the current patch should be extended to disable flow control on all ports? What are people's thoughts on this? I'm facing the same issue now after upgrading to 5.4 kernel more often than before. Every second reboot reboot with 5.4 fails with this timeout error. Yours sincerely, Jaap André from previous discussions with MTK and looking at the SDK code, the flow control should always be disabled. John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
MT7621 Flow Control
Dear all, I have noticed the flow control work for mt7621 in the following Openwrt patch: https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=c8f8e59816eca49d776562d2d302bf990a87faf0 However, the problem that the patch is supposed to fix is still occurring, even in combination with other experimental patches submitted. These experiences can be read about here: https://forum.openwrt.org/t/mtk-soc-eth-watchdog-timeout-after-r11573/5/ However, on this mailing list a user by the name of Kristian claims that disabling flow control helps fix this problem, as can be read here: https://lists.openwrt.org/pipermail/openwrt-devel/2017-November/009882.html >From what I understood, he was running many mt7621 devices commercially, with many of them experiencing the issue, which were all fixed with his own flow control patch. My question is why the decision was made to only disable flow control on port 5 in the above mentioned Openwrt patch? AFAIK, Kristian's own patch disables flow control on all of the ports and he claims the issue is fixed for him. Perhaps the current patch should be extended to disable flow control on all ports? What are people's thoughts on this? Yours sincerely, Jaap ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
