[RFC PATCH 2/2] wolfssl: compile with --enable-opensslall
This enables all OpenSSL API available. It is required to avoid some silent failures, such as when performing client certificate validation. Package size increases from 356.6K to 374.7K for arm_cortex-a9_vfpv3-d16. Signed-off-by: Eneas U de Queiroz diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index 4b891d634a..aeea1b7b7b 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wolfssl PKG_VERSION:=4.5.0-stable -PKG_RELEASE:=3 +PKG_RELEASE:=4 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION) @@ -62,6 +62,7 @@ TARGET_LDFLAGS += -flto # --enable-stunnel needed for OpenSSL API compatibility bits CONFIGURE_ARGS += \ --enable-lighty \ + --enable-opensslall \ --enable-opensslextra \ --enable-sni \ --enable-stunnel \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 0/2] wolfssl: build with --enable-opensslall
While looking at lighttpd failure to run with wolfssl as its backend[1], it was suggested to configure wolfssl with both '--enable-lighty', and '--enable-opensslall'. While '--enable-lighty', in theory should make it work, wolfssl's crazy maze of preprocessor macros, combined with many empty functions and different data structures, make its behaviour unpredictable. Nonetheless, use of '--enable-lighty' should be harmless. Size increase is a little over 100 bytes, and it should make it easier for lighttpd to feature-test the library using 'HAVE_LIGHTY' instead of having to rely on support for other software, like 'HAVE_STUNNEL'. Changes in data structures that depend on compile options also make it hard to use alternative packages, like wolfssl-full and wolfssl-light. Pesonally, I think the size increase is not so dramatic, and there are so much code that gets disabled by its absence that I believe it should be enabled. I know that size matters, but having a library that works consistently is even more important. I am marking this RFC, as it has a broad impact. Please notice that the option name opensslall is somewhat misleading, since it is not a superset of opensslextra. Eneas [1] https://github.com/openwrt/packages/issues/14142 Eneas U de Queiroz (2): wolfssl: add lighty support, skip crypttests wolfssl: compile with --enable-opensslall package/libs/wolfssl/Makefile | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC PATCH 1/2] wolfssl: add lighty support, skip crypttests
Tnis adds the --enable-lighty option to configure, enabling the minimum API needed to run lighttpd, in the packages feed. Size increase is about 120 bytes for arm_cortex-a9_vfpv3-d16. While at it, speed up build by disabling crypt bench/test. Signed-off-by: Eneas U de Queiroz diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index dc8ca2b262..4b891d634a 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -9,7 +9,7 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wolfssl PKG_VERSION:=4.5.0-stable -PKG_RELEASE:=2 +PKG_RELEASE:=3 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION) @@ -61,9 +61,11 @@ TARGET_LDFLAGS += -flto # --enable-stunnel needed for OpenSSL API compatibility bits CONFIGURE_ARGS += \ + --enable-lighty \ --enable-opensslextra \ --enable-sni \ --enable-stunnel \ + --disable-crypttests \ --disable-examples \ --disable-jobserver \ --$(if $(CONFIG_IPV6),enable,disable)-ipv6 \ ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
> Having all this features diabled gives for the kernel of a Nanostation M XM > ubnt_nanostation-m-kernel.bin: > - ath79-generic: 1792151 > - ath79-tiny: 1500108 > vmlinux: > - ath79-generic: 5588220 > - ath79-tiny: 4687644 > > So a bit more than 16% smaller size, or 900k absolute. A direct runtime > comparision I can't provide at the moment, as my test device is running other > stuff already. This doesn't look like buildbot settings. If we discuss default setup/images here, we should discuss buildbot figures as this will involve a lot of additional symbols enabled that might change the situation drastically. So, buildbot settings and all feeds installed should be the setup. Best Adrian > > Sven > > > > > ___ > 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 0/5] ath79: add a lower RAM-using version of 8/32 devices
> I agree, that some of the "small_flash" defaults are probably not the optimal > choice for 8MB-flash devices. > A new subtarget might be an option, but is it really worth to define a new > one for "deprecated" boards? Esp. as it's to be expected that both will vanish > in the release following 20.xx. A new subtarget feels to me like just adding > additional maintenance and additional confusion to the users. IMO it's simply like this: "Do we want to specifically put efforts into providing a better _default_ experience for this subgroup of devices for a limited time." YES: Do it properly (which IMO means having a low-mem target for low-mem devices) NO: Leave the stuff as it is right now. I personally lean towards "No.". If people still want to use these devices, they are the ones who know best where they can disable stuff and where they can't. This is all perfectly possible with the current implementation as it is right now. As you state yourself, the devices still work well with standard OpenWrt. The problems arise when you add additional features to them. So, it seems logical to me that you address the results of these additional features at the place where you introduce them, as you will actually know the precise nature of the use case (while we can just provide a framework for a myriad of possible scenarios). > > Adrian, as you mentioned there is currently only one board build for ath79- > tiny at all. So it's a target that might not be interesting for the average > user at > all. For this it might be a good idea to stop now building this target anyway > in > favor of using the build ressouces more effectively. Getting more images for > the tiny-subtarget will only change when customizing the config . > > By writing this I wonder if it gives sense to add a new subtarget "deprecated" > (to all relevant targets) to include all boards that might fall out of support > "soon" as of limited ressources? This will be a clear statement to the users > and even easy to determ, when a board belonge to this subtarget. As we > currently see "tiny" was introduced for the 4/32MB boards but in the > meanwhile should include the 8/32MB boards, too. In the "next wave" I > assume 8/64MB boards will belong to this category in some years. Very likely > the 4/32 and > 8/32 boards have become unsupportable then anyway and removed from > the code- basis. That's the task of documentation, not of code. Again, we have to distinguish between default builds (buildbots) and support itself. If a device can't be built anymore by buildbots (or is really broken otherwise), it gets disabled via "DEFAULT := n". Any other action of rearrangement would just increase the chance of breaking it with no reason. A deprecated target would even more increase the necessity to maintain config etc. for devices nobody uses anymore. In contrast, with the current setup we essentially still maintain the 8/32 accidentally as we maintain the rest and they benefit from it. I do see no reason to change that. > > > I also ran a quick check on the usage of the "small_flash" and "low_mem" flag > features. They are defined for some targets and used to set the > "SMALL_FLASH" > and "LOW_MEMORY_FOOTPRINT" config-features. But there seems no > other use of them, or did I miss something? If I'm right, the most difference > between generic and tiny is the "config-default" file. > When there is no further use of the features, it's nor probably an option to > think of combining both into something like "low_ressources". Based on this > some default config-choices can be changed, like "optimize for size", > disabling some "comfort features". As said before, a smaller binary / kernel > will save flash-space and RAM-space, even the flash-space might not be > relevant for all "low_ressources" boards. Yes, but what falls into which category is always a matter of judgement. Otherwise, we would just enable small_flash and low_mem for all devices ... Best Adrian > > Sven > > > > ___ > 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 2/5] kernel: deactivate usb on ath79-tiny
Am Sonntag, 6. Dezember 2020, 14:05:15 CET schrieb Adrian Schmutzler: > > Apart from that, I don't see disabling basic features like USB on a device > with USB ports as an option for pure OpenWrt. > Disabling USB was just a pragmatic solution, as without SCSI-support, partition-handling and USB-ACM, I did not see a usecae the USB-port might be needed for. > If the basic configuration does not run or build, we should simply put > "DEFAULT := n" and have the user select the configuration he/she needs. One > might reorganize features between kernel and modules or remove really > optional stuff, but this patch is too much of forcing here. > To me it looked like kernel USB-support is present, even the OpenWrt USB- support is not enabled I've choosen the hardcoded way. So I was able to test the change and ask for comments, without long rework of the config-menu options. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
Am Sonntag, 6. Dezember 2020, 11:03:56 CET schrieb Baptiste Jonglez: > Hi, > > On 06-12-20, Sven Roederer wrote: > > Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as > > they work quite well for basic usage (including full LuCI). > > On some projects with advanced features (e.g. Freifunk) the lack of RAM > > turns them into unstable devices. Mostly caused by several OOM problems > > per day. This series tries to prolong the usage of these boards by moving > > them to the ath79-tiny target. Indeed it makes these boards available on > > ath79-tiny in addition to the current ath79-generic variant. > > Can't you just move the boards instead of duplicating them? > For sure this should be done, in the final merge. Having the same board in different subtargets might confuse ... > > [RFC PATCH 4/5] kernel: ath79-tiny deactivate usually not needed features > > Can you provide an overview of kernel memory consumption before and after? > /proc/vmstat just after boot would give an idea. > Having all this features diabled gives for the kernel of a Nanostation M XM ubnt_nanostation-m-kernel.bin: - ath79-generic: 1792151 - ath79-tiny: 1500108 vmlinux: - ath79-generic: 5588220 - ath79-tiny: 4687644 So a bit more than 16% smaller size, or 900k absolute. A direct runtime comparision I can't provide at the moment, as my test device is running other stuff already. Sven ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[no subject]
The sender domain has a DMARC Reject/Quarantine policy which disallows sending mailing list messages using the original "From" header. To mitigate this problem, the original message has been wrapped automatically by the mailing list software.--- Begin Message --- Branch: refs/heads/master Home: https://github.com/sdwalker/sdwalker.github.io Commit: 260b079881c111afa4601cd3ce71017d88691dc1 https://github.com/sdwalker/sdwalker.github.io/commit/260b079881c111afa4601cd3ce71017d88691dc1 Author: Stephen Walker Date: 2020-12-06 (Sun, 06 Dec 2020) Changed paths: M uscan/index-18.06.html M uscan/index-19.07.html M uscan/index.html Log Message: --- This week's update --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
Am Sonntag, 6. Dezember 2020, 13:59:52 CET schrieb Adrian Schmutzler:
> > -Original Message-
> > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> > On Behalf Of Sven Roederer
> > Sent: Sonntag, 6. Dezember 2020 02:07
> > To: openwrt-devel@lists.openwrt.org
> > Subject: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
> >
> > Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as
> > they work quite well for basic usage (including full LuCI).
> > On some projects with advanced features (e.g. Freifunk) the lack of RAM
> > turns them into unstable devices. Mostly caused by several OOM problems
> > per day.
> > This series tries to prolong the usage of these boards by moving them to
> > the ath79-tiny target. Indeed it makes these boards available on
> > ath79-tiny in addition to the current ath79-generic variant.
> > To improve the low RAM situation the default kernel-config for the tiny
> > sub- target will also disable some uncommon features. So the kernel image
> > becomes smaller, which results in lower flash- and RAM-footprint.
>
> As stated in the earlier discussion, I never liked mixing low-flash ("tiny")
> and low-RAM (???) devices.
>
> In contrast, David has made clear that this also is not possible due to
> conflicting goals for both approaches.
>
> So, rather than mixing things up here and making it even harder to
> understand what "tiny" is supposed to be, this proposal IMO should rather
> aim at introducing a new subtarget aiming specifically at low-RAM devices.
> One could then just stop building "tiny" by default (there is only one
> device left, and I doubt people will have much benefit from prebuilt
> packages when they have to strip stuff anyway), and build the new subtarget
> _instead_ (i.e. no additional building overhead).
>
I agree, that some of the "small_flash" defaults are probably not the optimal
choice for 8MB-flash devices.
A new subtarget might be an option, but is it really worth to define a new one
for "deprecated" boards? Esp. as it's to be expected that both will vanish in
the release following 20.xx. A new subtarget feels to me like just adding
additional maintenance and additional confusion to the users.
Adrian, as you mentioned there is currently only one board build for ath79-
tiny at all. So it's a target that might not be interesting for the average
user at all. For this it might be a good idea to stop now building this target
anyway in favor of using the build ressouces more effectively. Getting more
images for the tiny-subtarget will only change when customizing the config .
By writing this I wonder if it gives sense to add a new subtarget "deprecated"
(to all relevant targets) to include all boards that might fall out of support
"soon" as of limited ressources? This will be a clear statement to the users
and even easy to determ, when a board belonge to this subtarget. As we
currently see "tiny" was introduced for the 4/32MB boards but in the meanwhile
should include the 8/32MB boards, too. In the "next wave" I assume 8/64MB
boards will belong to this category in some years. Very likely the 4/32 and
8/32 boards have become unsupportable then anyway and removed from the code-
basis.
I also ran a quick check on the usage of the "small_flash" and "low_mem" flag
features. They are defined for some targets and used to set the "SMALL_FLASH"
and "LOW_MEMORY_FOOTPRINT" config-features. But there seems no other use of
them, or did I miss something? If I'm right, the most difference between
generic and tiny is the "config-default" file.
When there is no further use of the features, it's nor probably an option to
think of combining both into something like "low_ressources". Based on this
some default config-choices can be changed, like "optimize for size",
disabling some "comfort features". As said before, a smaller binary / kernel
will save flash-space and RAM-space, even the flash-space might not be
relevant for all "low_ressources" boards.
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 19.07] mac80211: Update to version 4.19.161-1
The removed patches were applied upstream.
The changes to 357-mac80211-optimize-skb-resizing.patch are more
complex. I think the patch already took care of the new changes done
upstream.
Signed-off-by: Hauke Mehrtens
---
package/kernel/mac80211/Makefile | 8 +--
.../patches/ath/404-regd_no_assoc_hints.patch | 4 +-
...-of-peer_bw_rxnss_override-parameter.patch | 2 +-
...rolling-support-for-various-chipsets.patch | 12 ++--
...rd_type-used-for-nvram-file-selectio.patch | 2 +-
...-add-credit-numbers-updating-support.patch | 10 ++--
...c-handle-compressed-tx-status-signal.patch | 16 +++---
...dd-support-for-CYW43012-SDIO-chipset.patch | 4 +-
...43012-F2-watermark-setting-to-fix-DM.patch | 2 +-
...and-dump-trap-info-during-sdio-probe.patch | 6 +-
...e-bphy_err-in-all-wiphy-related-code.patch | 30 +-
...fix-NULL-pointer-derefence-during-US.patch | 2 +-
...rcmf_attach-and-brcmf_detach-functio.patch | 2 +-
...-F2-blocksize-and-watermark-for-4359.patch | 2 +-
...mac-use-true-false-for-bool-variable.patch | 2 +-
...x-OOB-interrupt-initialization-on-br.patch | 4 +-
...e-linux-stddef.h-instead-of-stddef.h.patch | 33 ---
.../110-mac80211_keep_keys_on_stop_ap.patch | 2 +-
.../subsys/140-tweak-TSQ-setting.patch| 2 +-
.../mac80211/patches/subsys/210-ap_scan.patch | 2 +-
...d-stop-start-logic-for-software-TXQs.patch | 4 +-
...l-remove-unnecessary-debugfs-cleanup.patch | 12 ++--
...l-merge-with-minstrel_ht-always-enab.patch | 6 +-
...l_ht-improve-rate-probing-for-device.patch | 2 +-
.../320-mac80211-Add-TXQ-scheduling-API.patch | 4 +-
...-Add-airtime-statistics-and-settings.patch | 6 +-
...time-accounting-and-scheduling-to-TX.patch | 12 ++--
...pose-ieee80211_schedule_txq-function.patch | 2 +-
...allow-bigger-VHT-MPDUs-than-the-hard.patch | 34
...0211-add-hdrlen-to-ieee80211_tx_data.patch | 6 +-
...1-add-TX_NEEDS_ALIGNED4_SKBS-hw-flag.patch | 14 ++---
...locking-for-txq-scheduling-airtime-f.patch | 10 ++--
...te-hash-for-fq-without-holding-fq-lo.patch | 6 +-
...e-dequeue-late-tx-handlers-without-h.patch | 8 +--
.../357-mac80211-optimize-skb-resizing.patch | 55 ---
...ee80211_schedule_txq-schedule-empty-.patch | 6 +-
...ing-iTXQ-select-the-queue-in-ieee802.patch | 4 +-
...l-remove-divisions-in-tx-status-path.patch | 6 +-
...l_ht-replace-rate-stats-ewma-with-a-.patch | 10 ++--
...l_ht-rename-prob_ewma-to-prob_avg-us.patch | 6 +-
...domize-BA-session-dialog-token-alloc.patch | 2 +-
...al-BSS-receive-time-to-survey-inform.patch | 2 +-
...11-fix-misplaced-while-instead-of-if.patch | 31 ---
.../522-mac80211_configure_antenna_gain.patch | 6 +-
44 files changed, 158 insertions(+), 243 deletions(-)
delete mode 100644
package/kernel/mac80211/patches/subsys/090-wireless-Use-linux-stddef.h-instead-of-stddef.h.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/331-mac80211-do-not-allow-bigger-VHT-MPDUs-than-the-hard.patch
delete mode 100644
package/kernel/mac80211/patches/subsys/370-mac80211-fix-misplaced-while-instead-of-if.patch
diff --git a/package/kernel/mac80211/Makefile b/package/kernel/mac80211/Makefile
index 8faf5b65b5..02d717127b 100644
--- a/package/kernel/mac80211/Makefile
+++ b/package/kernel/mac80211/Makefile
@@ -10,10 +10,10 @@ include $(INCLUDE_DIR)/kernel.mk
PKG_NAME:=mac80211
-PKG_VERSION:=4.19.137-1
-PKG_RELEASE:=2
-PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v4.19.137/
-PKG_HASH:=dc5eea4f77fc5c43b69e38f46fbf766880fa4bdeef83dcc8dcc85aa6b645bb7c
+PKG_VERSION:=4.19.161-1
+PKG_RELEASE:=1
+PKG_SOURCE_URL:=@KERNEL/linux/kernel/projects/backports/stable/v4.19.161/
+PKG_HASH:=01a4173ba180eb8ca67c898239d5accb49a3ea9aea51510e17d5c937d6e93f9a
PKG_SOURCE:=backports-$(PKG_VERSION).tar.xz
PKG_BUILD_DIR:=$(KERNEL_BUILD_DIR)/backports-$(PKG_VERSION)
diff --git a/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch
b/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch
index dc4068e542..16e40380e7 100644
--- a/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch
+++ b/package/kernel/mac80211/patches/ath/404-regd_no_assoc_hints.patch
@@ -1,6 +1,6 @@
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
-@@ -3034,6 +3034,8 @@ void regulatory_hint_country_ie(struct w
+@@ -3037,6 +3037,8 @@ void regulatory_hint_country_ie(struct w
enum environment_cap env = ENVIRON_ANY;
struct regulatory_request *request = NULL, *lr;
@@ -9,7 +9,7 @@
/* IE len must be evenly divisible by 2 */
if (country_ie_len & 0x01)
return;
-@@ -3259,6 +3261,7 @@ static bool is_wiphy_all_set_reg_flag(en
+@@ -3262,6 +3264,7 @@ static bool is_wiphy_all_set_reg_flag(en
void regulatory_hint_disconnect(void)
{
diff --git
a/package/kernel/mac80211/patches/ath/972-ath10k_fix-crash-due-to-wrong-handling-of-peer_bw_rxnss_override-parameter.patch
Merged: firewall3: fix duplicate defaults section detection
Merged into project/firewall3.git, branch master at http://git.openwrt.org/?p=project/firewall3.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Merged: ipsets: allow blank/commented lines withloadfile
Merged into project/firewall3.git, branch master at http://git.openwrt.org/?p=project/firewall3.git. Thank you! ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
RE: [RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny
Hi, > -Original Message- > From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org] > On Behalf Of Sven Roederer > Sent: Sonntag, 6. Dezember 2020 02:07 > To: openwrt-devel@lists.openwrt.org > Cc: adminuser > Subject: [RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny > > From: adminuser This has various obvious formal shortcomings: - From without name - Missing SOB - Missing description (why?) Apart from that, I don't see disabling basic features like USB on a device with USB ports as an option for pure OpenWrt. If the basic configuration does not run or build, we should simply put "DEFAULT := n" and have the user select the configuration he/she needs. One might reorganize features between kernel and modules or remove really optional stuff, but this patch is too much of forcing here. Best Adrian > > --- > target/linux/ath79/image/tiny-tp-link.mk | 4 > target/linux/ath79/image/tiny-ubnt.mk| 2 -- > target/linux/ath79/image/tiny.mk | 1 - > target/linux/ath79/tiny/config-default | 5 +++-- > 4 files changed, 3 insertions(+), 9 deletions(-) > > diff --git a/target/linux/ath79/image/tiny-tp-link.mk > b/target/linux/ath79/image/tiny-tp-link.mk > index d5b36de577..ab931f02fb 100644 > --- a/target/linux/ath79/image/tiny-tp-link.mk > +++ b/target/linux/ath79/image/tiny-tp-link.mk > @@ -16,7 +16,6 @@ define Device/tplink_tl-mr3020-v1 >SOC := ar9331 >DEVICE_MODEL := TL-MR3020 >DEVICE_VARIANT := v1 > - DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport >TPLINK_HWID := 0x3021 >SUPPORTED_DEVICES += tl-mr3020 > endef > @@ -27,7 +26,6 @@ define Device/tplink_tl-mr3040-v2 >SOC := ar9331 >DEVICE_MODEL := TL-MR3040 >DEVICE_VARIANT := v2 > - DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport >TPLINK_HWID := 0x3042 >SUPPORTED_DEVICES += tl-mr3040-v2 > endef > @@ -39,7 +37,6 @@ define Device/tplink_tl-mr3220-v1 >DEVICE_MODEL := TL-MR3220 >DEVICE_VARIANT := v1 >TPLINK_HWID := 0x3221 > - DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport >SUPPORTED_DEVICES += tl-mr3220 > endef > TARGET_DEVICES += tplink_tl-mr3220-v1 > @@ -238,7 +235,6 @@ define Device/tplink_tl-wr703n >$(Device/tplink-4mlzma) >SOC := ar9331 >DEVICE_MODEL := TL-WR703N > - DEVICE_PACKAGES := kmod-usb-chipidea2 >TPLINK_HWID := 0x07030101 >SUPPORTED_DEVICES += tl-wr703n > endef > diff --git a/target/linux/ath79/image/tiny-ubnt.mk > b/target/linux/ath79/image/tiny-ubnt.mk > index a8c5a2cf68..be7dd46761 100644 > --- a/target/linux/ath79/image/tiny-ubnt.mk > +++ b/target/linux/ath79/image/tiny-ubnt.mk > @@ -31,7 +31,6 @@ endef > # UBNT_VERSION e.g. one of (6.0.0, 8.5.3) define Device/ubnt >DEVICE_VENDOR := Ubiquiti > - DEVICE_PACKAGES := kmod-usb2 >IMAGES += factory.bin >IMAGE/factory.bin := append-kernel | pad-to (BLOCKSIZE) | \ > append-rootfs | pad-rootfs | check-size | mkubntimage-split @@ - > 40,7 +39,6 @@ endef define Device/ubnt-xm >$(Device/ubnt) >DEVICE_VARIANT := XM > - DEVICE_PACKAGES += kmod-usb-ohci >IMAGE_SIZE := 7448k >UBNT_BOARD := XM >UBNT_CHIP := ar7240 > diff --git a/target/linux/ath79/image/tiny.mk > b/target/linux/ath79/image/tiny.mk > index 83c34d718b..800b2055db 100644 > --- a/target/linux/ath79/image/tiny.mk > +++ b/target/linux/ath79/image/tiny.mk > @@ -34,7 +34,6 @@ define Device/pqi_air-pen >SOC := ar9330 >DEVICE_VENDOR := PQI >DEVICE_MODEL := Air-Pen > - DEVICE_PACKAGES := kmod-usb2 >IMAGE_SIZE := 7680k >SUPPORTED_DEVICES += pqi-air-pen > endef > diff --git a/target/linux/ath79/tiny/config-default > b/target/linux/ath79/tiny/config-default > index 42243cfc48..8a83323bc2 100644 > --- a/target/linux/ath79/tiny/config-default > +++ b/target/linux/ath79/tiny/config-default > @@ -7,7 +7,8 @@ CONFIG_NET_DSA_MV88E6060=y > CONFIG_NET_DSA_TAG_TRAILER=y CONFIG_NET_SWITCHDEV=y > CONFIG_PHYLINK=y -CONFIG_PHY_AR7100_USB=y - > CONFIG_PHY_AR7200_USB=y > +# CONFIG_PHY_AR7100_USB is not set > +# CONFIG_PHY_AR7200_USB is not set > CONFIG_REGULATOR=y > CONFIG_REGULATOR_FIXED_VOLTAGE=y > +# CONFIG_USB_SUPPORT is not set > -- > 2.20.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 0/5] ath79: add a lower RAM-using version of 8/32 devices
> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Sven Roederer
> Sent: Sonntag, 6. Dezember 2020 02:07
> To: openwrt-devel@lists.openwrt.org
> Subject: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
>
> Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as
> they work quite well for basic usage (including full LuCI).
> On some projects with advanced features (e.g. Freifunk) the lack of RAM
> turns them into unstable devices. Mostly caused by several OOM problems
> per day.
> This series tries to prolong the usage of these boards by moving them to the
> ath79-tiny target. Indeed it makes these boards available on ath79-tiny in
> addition to the current ath79-generic variant.
> To improve the low RAM situation the default kernel-config for the tiny sub-
> target will also disable some uncommon features. So the kernel image
> becomes smaller, which results in lower flash- and RAM-footprint.
As stated in the earlier discussion, I never liked mixing low-flash ("tiny")
and low-RAM (???) devices.
In contrast, David has made clear that this also is not possible due to
conflicting goals for both approaches.
So, rather than mixing things up here and making it even harder to understand
what "tiny" is supposed to be, this proposal IMO should rather aim at
introducing a new subtarget aiming specifically at low-RAM devices. One could
then just stop building "tiny" by default (there is only one device left, and I
doubt people will have much benefit from prebuilt packages when they have to
strip stuff anyway), and build the new subtarget _instead_ (i.e. no additional
building overhead).
You still will have problems to find allies for your proposal, but that way it
would make much more sense that now IMO.
Best
Adrian
>
> [RFC PATCH 1/5] ath79: put some 8/32MB devices to tiny subtarget [RFC
> PATCH 2/5] kernel: deactivate usb on ath79-tiny [RFC PATCH 3/5] ath79:
> deactivate PARTITION_ADVANCED [RFC PATCH 4/5] kernel: ath79-tiny
> deactivate usually not needed features [RFC PATCH 5/5] kernel: ath79-tiny:
> enable CONFIG_BLOCK
>
>
> ___
> 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 1/5] ath79: put some 8/32MB devices to tiny subtarget
> --- a/target/linux/ath79/image/common-tp-link.mk > +++ b/target/linux/ath79/image/common-tp-link.mk > @@ -40,6 +40,7 @@ define Device/tplink-4m >$(Device/tplink-nolzma) >TPLINK_FLASHLAYOUT := 4M >IMAGE_SIZE := 3904k > + FEATURES := small_flash Features are a target property, defining them per-device is wrong and won't work as expected. Best Adrian >DEFAULT := n > endef > > @@ -47,6 +48,7 @@ define Device/tplink-4mlzma >$(Device/tplink-v1) >TPLINK_FLASHLAYOUT := 4Mlzma >IMAGE_SIZE := 3904k > + FEATURES := small_flash >DEFAULT := n > endef > > diff --git a/target/linux/ath79/image/tiny-tp-link.mk > b/target/linux/ath79/image/tiny-tp-link.mk > index c918c6baa6..d5b36de577 100644 > --- a/target/linux/ath79/image/tiny-tp-link.mk > +++ b/target/linux/ath79/image/tiny-tp-link.mk > @@ -223,6 +223,17 @@ define Device/tplink_tl-wa901nd-v5 endef > TARGET_DEVICES += tplink_tl-wa901nd-v5 > > +define Device/tplink_tl-wr1043nd-v1 > + $(Device/tplink-8m) > + SOC := ar9132 > + DEVICE_MODEL := TL-WR1043N/ND > + DEVICE_VARIANT := v1 > + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x10430001 > + SUPPORTED_DEVICES += tl-wr1043nd > +endef > +TARGET_DEVICES += tplink_tl-wr1043nd-v1 > + > define Device/tplink_tl-wr703n >$(Device/tplink-4mlzma) >SOC := ar9331 > @@ -243,6 +254,29 @@ define Device/tplink_tl-wr740n-v1 endef > TARGET_DEVICES += tplink_tl-wr740n-v1 > > +define Device/tplink_tl-wr710n-v1 > + $(Device/tplink-8mlzma) > + SOC := ar9331 > + DEVICE_MODEL := TL-WR710N > + DEVICE_VARIANT := v1 > + DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x0711 > + SUPPORTED_DEVICES += tl-wr710n > +endef > +TARGET_DEVICES += tplink_tl-wr710n-v1 > + > +define Device/tplink_tl-wr710n-v2.1 > + $(Device/tplink-8mlzma) > + SOC := ar9331 > + DEVICE_MODEL := TL-WR710N > + DEVICE_VARIANT := v2.1 > + DEVICE_PACKAGES := kmod-usb-chipidea2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x0712 > + TPLINK_HWREV := 0x2 > + SUPPORTED_DEVICES += tl-wr710n > +endef > +TARGET_DEVICES += tplink_tl-wr710n-v2.1 > + > define Device/tplink_tl-wr740n-v3 >$(Device/tplink-4m) >SOC := ar7240 > @@ -327,6 +361,16 @@ define Device/tplink_tl-wr802n-v2 endef > TARGET_DEVICES += tplink_tl-wr802n-v2 > > +define Device/tplink_tl-wr810n-v2 > + $(Device/tplink-8mlzma) > + SOC := qca9533 > + DEVICE_MODEL := TL-WR810N > + DEVICE_VARIANT := v2 > + TPLINK_HWID := 0x812 > + SUPPORTED_DEVICES += tl-wr810n-v2 > +endef > +TARGET_DEVICES += tplink_tl-wr810n-v2 > + > define Device/tplink_tl-wr841-v5 >$(Device/tplink-4m) >SOC := ar7240 > @@ -403,6 +447,28 @@ define Device/tplink_tl-wr841-v12 endef > TARGET_DEVICES += tplink_tl-wr841-v12 > > +define Device/tplink_tl-wr842n-v1 > + $(Device/tplink-8m) > + SOC := ar7241 > + DEVICE_MODEL := TL-WR842N/ND > + DEVICE_VARIANT := v1 > + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x8420001 > + SUPPORTED_DEVICES += tl-mr3420 > +endef > +TARGET_DEVICES += tplink_tl-wr842n-v1 > + > +define Device/tplink_tl-wr842n-v2 > + $(Device/tplink-8mlzma) > + SOC := ar9341 > + DEVICE_MODEL := TL-WR842N/ND > + DEVICE_VARIANT := v2 > + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport > + TPLINK_HWID := 0x8420002 > + SUPPORTED_DEVICES += tl-wr842n-v2 > +endef > +TARGET_DEVICES += tplink_tl-wr842n-v2 > + > define Device/tplink_tl-wr940n-v3 >$(Device/tplink-4mlzma) >SOC := tp9343 > diff --git a/target/linux/ath79/image/tiny-ubnt.mk > b/target/linux/ath79/image/tiny-ubnt.mk > new file mode 100644 > index 00..a8c5a2cf68 > --- /dev/null > +++ b/target/linux/ath79/image/tiny-ubnt.mk > @@ -0,0 +1,132 @@ > +DEVICE_VARS += UBNT_BOARD UBNT_CHIP UBNT_TYPE UBNT_VERSION > +UBNT_REVISION > + > +# On M (XW) devices the U-Boot as of version 1.1.4-s1039 doesn't like # > +VERSION_DIST being on the place of major(?) version number, so we need > +to # use some number. > +UBNT_REVISION := $(VERSION_DIST)-$(REVISION) > + > +# mkubntimage is using the kernel image direct # routerboard creates > +partitions out of the ubnt header define Build/mkubntimage > + -$(STAGING_DIR_HOST)/bin/mkfwimage -B $(UBNT_BOARD) \ > + -v $(UBNT_TYPE).$(UBNT_CHIP).v6.0.0-$(VERSION_DIST)- > $(REVISION) \ > + -k $(IMAGE_KERNEL) -r $@ -o $@ > +endef > + > +# all UBNT XM/WA devices expect the kernel image to have 1024k while > +flash, when # booting the image, the size doesn't matter. > +define Build/mkubntimage-split > + -[ -f $@ ] && ( \ > + dd if=$@ of=$@.old1 bs=1024k count=1; \ > + dd if=$@ of=$@.old2 bs=1024k skip=1; \ > + $(STAGING_DIR_HOST)/bin/mkfwimage -B $(UBNT_BOARD) \ > + -v $(UBNT_TYPE).$(UBNT_CHIP).v$(UBNT_VERSION)- > $(UBNT_REVISION) \ > + -k $@.old1 -r $@.old2 -o $@; \ > + rm $@.old1 $@.old2 ) > +endef > + > +# UBNT_BOARD e.g. one of (XS2, XS5, RS, XM) # UBNT_TYPE e.g. one of >
Re: Lightweight policy-based routing
On 04-12-20, Philip Prindeville wrote: > But I’m trying: > > config rule > option src '192.168.3.6' > option lookup 200 > > Per the cheatsheet and it’s resulting in: > > root@OpenWrt2:~# ip rule ls > 0:from all lookup local > 1:from all lookup 200 > 32766:from all lookup main > 32767:from all lookup default > > i.e. the ’src’ is being ignored. Several years ago (probably with LEDE 17.01) I was using this configuration and it worked: config rule option in 'lan' option src '172.23.184.111/32' option lookup '666' Try with the /32. If it still doesn't work, then it's a regression. > Also trying: > > config route > option target '151.101.0.0/16' > option interface ‘xfrm0' > option gateway '192.168.1.252' > option table 200 > option proto ‘static' > > But that works great. > > > > On Dec 4, 2020, at 1:00 PM, Jo-Philipp Wich wrote: > > > > Hi Philip, > > > > ip rules are possible in uci, but not sure if all the bits you require are > > covered: > > > > https://openwrt.org/docs/guide-user/network/ucicheatsheet#ip_rules_for_both_rule_and_rule6 > > > > `config route` sections allow specifying `option table` as well to stage the > > routes in the non-main rttable. > > > > Since the device options for uci rules and routes require logical networks > > and > > not Linux network device names, you might need to declare a dummy interface > > for xfrm0, like this: > > > > config interface vpn > > option proto static > > option ifname xfrm0 > > > > It might be that netifd will clear out any IP addresses on the xfrm0 > > interface, so you would need to encode those in uci as well: > > > > config interface vpn > > option proto static > > option ifname xfrm0 > > option ipaddr 192.168.1.0/24 > > option table 200 # will instruct netifd to put any related routes into > > table 200 > > > > > > Netifd understands aliases set up in /etc/iproute2/rt_tables but there is no > > uci way to declare new symbolic aliases. So either you need to manage that > > file externally or you stick to numeric table IDs. > > > > ~ Jo > > > > ___ > > 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 signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFC 0/5] ath79: add a lower RAM-using version of 8/32 devices
Hi, On 06-12-20, Sven Roederer wrote: > Currently 8MB flash / 32MB RAM devices are fully supported in OpenWrt, as they > work quite well for basic usage (including full LuCI). > On some projects with advanced features (e.g. Freifunk) the lack of RAM turns > them into unstable devices. Mostly caused by several OOM problems per day. > This series tries to prolong the usage of these boards by moving them to the > ath79-tiny target. Indeed it makes these boards available on ath79-tiny in > addition to the current ath79-generic variant. Can't you just move the boards instead of duplicating them? > To improve the low RAM situation the default kernel-config for the tiny sub- > target will also disable some uncommon features. So the kernel image becomes > smaller, which results in lower flash- and RAM-footprint. Some of the patches below have broken SoB. > [RFC PATCH 1/5] ath79: put some 8/32MB devices to tiny subtarget > [RFC PATCH 2/5] kernel: deactivate usb on ath79-tiny > [RFC PATCH 3/5] ath79: deactivate PARTITION_ADVANCED > [RFC PATCH 4/5] kernel: ath79-tiny deactivate usually not needed features Can you provide an overview of kernel memory consumption before and after? /proc/vmstat just after boot would give an idea. > [RFC PATCH 5/5] kernel: ath79-tiny: enable CONFIG_BLOCK What does this do? Thanks, Baptiste signature.asc Description: PGP signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFC] remove x86 qemu images
Hi, openwrt.git includes an old version of QEMU (0.14 vs 5.1.0 in packages.git) only to convert x86 images to vdi and vmdk. Is there anyone actively using the vanilla x86 QEMU images from the upstream servers or can can we remove that "feature"? This would allow to remove tools/qemu and create less files per build. Best, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mtd-utils: remove lzo build dependency
Because of the patch removing LZO support, LZO as a build dependency is not needed. zlib is a build dependency of util-linux. Might as well remove. Signed-off-by: Rosen Penev --- package/utils/mtd-utils/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/package/utils/mtd-utils/Makefile b/package/utils/mtd-utils/Makefile index 6e5e72783f..5a4b03da96 100644 --- a/package/utils/mtd-utils/Makefile +++ b/package/utils/mtd-utils/Makefile @@ -20,7 +20,7 @@ PKG_FIXUP:=autoreconf PKG_FLAGS:=nonshared -PKG_BUILD_DEPENDS:=util-linux lzo zlib +PKG_BUILD_DEPENDS:=util-linux PKG_LICENSE:=GPLv2 PKG_LICENSE_FILES:= -- 2.28.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
