[PATCH] ipq40xx: cut ath10k board file for mikrotik subtarget
Avoid shipping ath10k board file in Mikrotik initram images
Most will only ever need to use these initram images once—to initially
load OpenWrt, but fix these images for more consistent Wi-Fi performance
between the initram and installed squashfs images.
OpenWrt BUILDBOT config ignores -cut packages in the initram images build.
This results in BUILDBOT initram images including the linux-firmware
qca4019 board-2.bin, and (initram image booted) Mikrotik devices loading
a generic BDF, rather than the intended BDF data loaded
from NOR as an api 1 board_file.
buildbot snapshot booted as initram image:
cat /etc/openwrt_version
r19679-810eac8c7f
dmesg | grep ath10k | grep -E board\|BDF
[9.794556] ath10k_ahb a00.wifi: Loading BDF type 0
[9.807192] ath10k_ahb a00.wifi: board_file api 2 bmi_id 0:16
crc32 11892f9b
[ 12.457105] ath10k_ahb a80.wifi: Loading BDF type 0
[ 12.464945] ath10k_ahb a80.wifi: board_file api 2 bmi_id 0:17
crc32 11892f9b
CC: Robert Marko
Fixes: 5eee67a72fed ("ipq40xx: mikrotik: dont include ath10k-board-qca4019 by
default")
Signed-off-by: John Thomson
---
target/linux/ipq40xx/Makefile | 2 +-
target/linux/ipq40xx/chromium/target.mk | 1 +
target/linux/ipq40xx/generic/target.mk | 1 +
target/linux/ipq40xx/mikrotik/target.mk | 1 -
4 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/target/linux/ipq40xx/Makefile b/target/linux/ipq40xx/Makefile
index 7df920e2d8..19b63cdd65 100644
--- a/target/linux/ipq40xx/Makefile
+++ b/target/linux/ipq40xx/Makefile
@@ -19,6 +19,6 @@ DEFAULT_PACKAGES += \
kmod-leds-gpio kmod-gpio-button-hotplug swconfig \
kmod-ath10k-ct wpad-basic-wolfssl \
kmod-usb3 kmod-usb-dwc3 ath10k-firmware-qca4019-ct \
- ath10k-board-qca4019 uboot-envtools
+ uboot-envtools
$(eval $(call BuildTarget))
diff --git a/target/linux/ipq40xx/chromium/target.mk
b/target/linux/ipq40xx/chromium/target.mk
index 3983a9281a..98bd37ed71 100644
--- a/target/linux/ipq40xx/chromium/target.mk
+++ b/target/linux/ipq40xx/chromium/target.mk
@@ -1,2 +1,3 @@
BOARDNAME:=Google Chromium
FEATURES += emmc boot-part rootfs-part
+DEFAULT_PACKAGES += ath10k-board-qca4019
diff --git a/target/linux/ipq40xx/generic/target.mk
b/target/linux/ipq40xx/generic/target.mk
index e158b1c98b..90c1b762af 100644
--- a/target/linux/ipq40xx/generic/target.mk
+++ b/target/linux/ipq40xx/generic/target.mk
@@ -1,2 +1,3 @@
BOARDNAME:=Generic
FEATURES+=emmc
+DEFAULT_PACKAGES += ath10k-board-qca4019
diff --git a/target/linux/ipq40xx/mikrotik/target.mk
b/target/linux/ipq40xx/mikrotik/target.mk
index 8b17c61585..4530a90985 100644
--- a/target/linux/ipq40xx/mikrotik/target.mk
+++ b/target/linux/ipq40xx/mikrotik/target.mk
@@ -2,4 +2,3 @@ BOARDNAME:=MikroTik
FEATURES += minor
KERNEL_IMAGES:=vmlinux
IMAGES_DIR:=compressed
-DEFAULT_PACKAGES += -ath10k-board-qca4019
--
2.36.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4] tplink-safeloader: Patch to handle partitions with alternate names.
Hi Ole Kristian,
Thanks for the updates, this has turned into a pretty clean patch :)
On Mon, 2022-05-16 at 15:50 +0200, Ole Kristian Lona wrote:
> Some devices, specifically Deco M4R-v3 / M5 have partition names that
> deviate from the scheme other devices use. They have an added "@0"
> and "@1" for some partition names.
>
> The devices have fallback partitions which will be used in case the
> device determines that the primary partition set is unbootable.
>
> This patch introduces an option to set these alternate partition names
> in the device definition of tplink-safeloader.
>
> Signed-off-by: Ole Kristian Lona
With one minor comment below:
Reviewed-by: Sander Vanheule
> ---
>
> @@ -2993,9 +3022,9 @@ static struct image_partition_entry
> make_partition_table(const struct
> flash_part
> *(s++) = 0x00;
>
> size_t i;
> - for (i = 0; p[i].name; i++) {
> + for (i = 0; p->partitions[i].name; i++) {
> size_t len = end-s;
> - size_t w = snprintf(s, len, "partition %s base 0x%05x size
> 0x%05x\n", p[i].name,
> p[i].base, p[i].size);
> + size_t w = snprintf(s, len, "partition %s base 0x%05x size
> 0x%05x\n", p-
> >partitions[i].name, p->partitions[i].base, p->partitions[i].size);
If feel it would be better to split this line. There are long lines in this
file, but 155 characters
seems a bit excessive.
As far as I'm concerned, you don't have to resubmit this patch if this is the
only comment left.
Reflowing a single line can be done when merging.
Best,
Sander
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Wrong hash for firewall package?
Hi again, please ignore my previous message, that was an incorrect observation on my side. In fact my locally generated source archive matches the one on the source mirror, so I assume Rui's recent bump simply added a wrong checksum. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Wrong hash for firewall package?
Hi, I compared the package stored on the source mirror with the locally generated mismatching one. The contained .tar has the same checksum but the compressed xz file is different. I suppose this is due to the recent enabling of multithreaded xz compression which yields different results on different machines. ~ Jo signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Wrong hash for firewall package?
I notice that firewall hash is different for firewall package The one we have is 307baf09c61ce727b4edb4283144b0d8128ebba34b858cc6389571421f829a24 but the correct one is ce9e8ac1bcf22afbb0a80c3da1a8e8e887851299681097e3dfbfc347f2c4c80f Did someone force pushed something to the firewall git or the hash was just wrong? Looks strange to me. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/4] pcre2: adds pcre2 to base
Rui Salvaterra writes: > On Thu, 19 May 2022 at 18:35, Daniel Golle wrote: >> >> On Thu, May 19, 2022 at 06:37:28PM +0200, Dominick Grift wrote: >> > libselinux-3.4 requires pcre2 >> > >> > Signed-off-by: Dominick Grift >> > --- >> > package/libs/pcre2/Config.in | 30 >> > package/libs/pcre2/Makefile | 92 >> > 2 files changed, 122 insertions(+) >> > create mode 100644 package/libs/pcre2/Config.in >> > create mode 100644 package/libs/pcre2/Makefile >> > >> > diff --git a/package/libs/pcre2/Config.in b/package/libs/pcre2/Config.in >> > new file mode 100644 >> > index 00..8777a4e84c >> > --- /dev/null >> > +++ b/package/libs/pcre2/Config.in >> > @@ -0,0 +1,30 @@ >> > +config PCRE2_JIT_ENABLED >> > + bool >> > + depends on PACKAGE_libpcre2 && (aarch64 || aarch64_be || arm || >> > i386 || i686 || x86_64 || mips || mipsel || mips64 || mips64el || >> > powerpc || powerpc64 || powerpcle || sparc) >> > + default y if (arm || i686 || x86_64) >> >> Can you explain the choice of architectures for which you are >> suggesting to enable JIT by default? >> Wouldn't e.g. aarch64 benefit just as well? > > I'd go even further and set it as default y if !arc (which is already > "special" enough). I think all of our other targets are supported by > the JIT. But that would be for a follow-up patch, of course. I am not a huge fan of JIT in general as I associate it with execution of anonymous memory and buffer overflows, whether that is justified or not. Besides this is a "heavyweight" optimization that is not alway's benificial. It adds 100KiB in size. I doubt that enabling this feature brings much to the table in OpenWrt (except 100KiB). I would actually consider taking the opposite route and disable JIT by default for all architectures. > > Cheers, > Rui > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel -- gpg --locate-keys dominick.gr...@defensec.nl Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 Dominick Grift ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/4] pcre2: adds pcre2 to base
On Thu, 19 May 2022 at 18:35, Daniel Golle wrote: > > On Thu, May 19, 2022 at 06:37:28PM +0200, Dominick Grift wrote: > > libselinux-3.4 requires pcre2 > > > > Signed-off-by: Dominick Grift > > --- > > package/libs/pcre2/Config.in | 30 > > package/libs/pcre2/Makefile | 92 > > 2 files changed, 122 insertions(+) > > create mode 100644 package/libs/pcre2/Config.in > > create mode 100644 package/libs/pcre2/Makefile > > > > diff --git a/package/libs/pcre2/Config.in b/package/libs/pcre2/Config.in > > new file mode 100644 > > index 00..8777a4e84c > > --- /dev/null > > +++ b/package/libs/pcre2/Config.in > > @@ -0,0 +1,30 @@ > > +config PCRE2_JIT_ENABLED > > + bool > > + depends on PACKAGE_libpcre2 && (aarch64 || aarch64_be || arm || i386 > > || i686 || x86_64 || mips || mipsel || mips64 || mips64el || powerpc || > > powerpc64 || powerpcle || sparc) > > + default y if (arm || i686 || x86_64) > > Can you explain the choice of architectures for which you are > suggesting to enable JIT by default? > Wouldn't e.g. aarch64 benefit just as well? I'd go even further and set it as default y if !arc (which is already "special" enough). I think all of our other targets are supported by the JIT. But that would be for a follow-up patch, of course. Cheers, Rui ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 1/4] pcre2: adds pcre2 to base
Dominick Grift writes: > Daniel Golle writes: > >> On Thu, May 19, 2022 at 06:37:28PM +0200, Dominick Grift wrote: >>> libselinux-3.4 requires pcre2 >>> >>> Signed-off-by: Dominick Grift >>> --- >>> package/libs/pcre2/Config.in | 30 >>> package/libs/pcre2/Makefile | 92 >>> 2 files changed, 122 insertions(+) >>> create mode 100644 package/libs/pcre2/Config.in >>> create mode 100644 package/libs/pcre2/Makefile >>> >>> diff --git a/package/libs/pcre2/Config.in b/package/libs/pcre2/Config.in >>> new file mode 100644 >>> index 00..8777a4e84c >>> --- /dev/null >>> +++ b/package/libs/pcre2/Config.in >>> @@ -0,0 +1,30 @@ >>> +config PCRE2_JIT_ENABLED >>> + bool >>> + depends on PACKAGE_libpcre2 && (aarch64 || aarch64_be || arm || >>> i386 || i686 || x86_64 || mips || mipsel || mips64 || mips64el || >>> powerpc || powerpc64 || powerpcle || sparc) >>> + default y if (arm || i686 || x86_64) >> >> Can you explain the choice of architectures for which you are >> suggesting to enable JIT by default? >> Wouldn't e.g. aarch64 benefit just as well? > > I did not choose anything. This commit is a 1-to-1 copy from pcre2 in > the packages feed. By the way, legacy pcre also only enables JIT for arm, i686 and x86_64 by default. A list of supported architectures can be found here: https://pcre.org/current/doc/html/pcre2jit.html#SEC2 But. Yes. I did not change anything in that regard. Last thing I want to do is add distraction. I only did what I had to do to get the job done. If you want to change the JIT defaults then probably best to address that in a separate patch. > >> >>> + prompt "Enable JIT compiler support" >>> + help >>> + Enable JIT (Just-In-Time) compiler support. >>> + >>> + Just-in-time compiling is a heavyweight optimization that can >>> greatly >>> + speed up pattern matching. However, it comes at the cost of >>> extra >>> + processing before the match is performed, so it is of most >>> benefit when >>> + the same pattern is going to be matched many times. This does >>> not >>> + necessarily mean many calls of a matching function; if the >>> pattern is >>> + not anchored, matching attempts may take place many times at >>> various >>> + positions in the subject, even for a single call. Therefore, if >>> the >>> + subject string is very long, it may still pay to use JIT even >>> for >>> + one-off matches. JIT support is available for all of the 8-bit, >>> 16-bit >>> + and 32-bit PCRE2 libraries and adds about 100KB to the resulting >>> + libpcre2.so. JIT support applies only to the traditional >>> Perl-compatible >>> + matching function. It does not apply when the DFA matching >>> function is >>> + being used. >>> + >>> + Enabling this option can give an about 10x performance increase >>> on JIT >>> + operations. It can be desireable for e.g. high performance >>> Apache >>> + mod_rewrite or HA-Proxy reqrep operations. >>> + >>> + However, JIT should _only_ be enabled on architectures that are >>> supported. >>> + Enabling JIT on unsupported platforms will result in a >>> compilation >>> + failure. A list of supported architectures can be found here: >>> + https://pcre.org/current/doc/html/pcre2jit.html#SEC2 >>> diff --git a/package/libs/pcre2/Makefile b/package/libs/pcre2/Makefile >>> new file mode 100644 >>> index 00..4e75a1cda9 >>> --- /dev/null >>> +++ b/package/libs/pcre2/Makefile >>> @@ -0,0 +1,92 @@ >>> +# >>> +# Copyright (C) 2017 Shane Peelar >>> +# >>> +# This is free software, licensed under the GNU General Public License v2. >>> +# See /LICENSE for more information. >>> +# >>> + >>> +include $(TOPDIR)/rules.mk >>> + >>> +PKG_NAME:=pcre2 >>> +PKG_VERSION:=10.37 >>> +PKG_RELEASE:=$(AUTORELEASE) >>> + >>> +PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 >>> +PKG_SOURCE_URL:=@SF/pcre/$(PKG_NAME)/$(PKG_VERSION) >>> +PKG_HASH:=4d95a96e8b80529893b4562be12648d798b957b1ba1aae39606bbc2ab956d270 >>> + >>> +PKG_MAINTAINER:=Shane Peelar >>> +PKG_LICENSE:=BSD-3-Clause >>> +PKG_LICENSE_FILES:=LICENCE >>> +PKG_CPE_ID:=cpe:/a:pcre:pcre >>> + >>> +PKG_CONFIG_DEPENDS:=\ >>> + CONFIG_PACKAGE_libpcre2-16 \ >>> + CONFIG_PACKAGE_libpcre2-32 \ >>> + CONFIG_PCRE2_JIT_ENABLED >>> + >>> +include $(INCLUDE_DIR)/package.mk >>> +include $(INCLUDE_DIR)/cmake.mk >>> + >>> +define Package/libpcre2/default >>> + SECTION:=libs >>> + CATEGORY:=Libraries >>> + URL:=https://www.pcre.org/ >>> +endef >>> + >>> +define Package/libpcre2/config >>> + source "$(SOURCE)/Config.in" >>> +endef >>> + >>> +define Package/libpcre2 >>> + $(call Package/libpcre2/default) >>> + TITLE:=A Perl Compatible Regular Expression library >>> +endef >>> + >>> +define Package/libpcre2-16 >>> + $(call Package/libpcre2/default) >>> + TITLE:=A
Re: libubox: How to terminate uloop orderly?
On 17/05/2022 11:04, Koch, Alexander via openwrt-devel wrote: So I'm wondering: what is the correct way to terminate the uloop? It's been a while and details are vague, but this works for me: https://github.com/openwrt/openwrt/blob/master/package/network/config/ltq-vdsl-app/src/src/dsl_cpe_ubus.c#L857-L883 ubus_init()/ubus_deinit() are called from the main thread, and the thread function just contains uloop_run(). Cheers, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
