Re: [PATCH] RFC: ARM: dts: Proposed Goramo MultiLink device tree
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 ---
Hi Linus,
First, thanks for your continued work on those old platforms.
I'm not exactly sure how to proceed.
> It requires writing a new 74hc4094 GPIO driver and moving a bunch
> of the boardfile code into the HSS driver as it is anyways the only
> user of this facility. If there are other boards supporting HSS they
> can be added too.
I'm not aware of any other supported hw using HSS.
The 74HC4094... I appears it's used mostly for HSS (optional signals
depending on the hardware port version), but one of it's outputs drives
PCI reset as well. There is also /write-protect for a couple of serial
EEPROMs (one of them usually not installed). AFAIR the EEPROMs were
never used for anything, but were available for some custom sw etc.
Also, the EEPROM(s) should be functional without driving 74HC4094, they
would only be unprotected (the protection wouldn't be needed in
practically all cases anyway).
> To proceed with this I need to be sure someone is willing to test
> and help develop this and has interest in supporting the Goramo
> MultiLink with recent kernels on e.g. OpenWrt.
TBH, the last time I was running such a device it was using a kernel
within something like 3.1x range. I *think* I still have some of the
hardware (definitely not all types, but perhaps one of the later
versions). Also, I think I should have some serial sync hardware, so in
theory both the DTS conversion and the HSS operation could be tested.
OTOH I don't know if it's worth the effort. But, since you already wrote
the DTS file, perhaps it's better to just leave it in place (knowing
that certain functionality of certain versions will be unavailable). If
I can test and possibly fix something here, I will try to.
The following is:
Acked-by: Krzysztof Hałasa
Some notes:
> +++ b/arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
> @@ -0,0 +1,201 @@
> +// SPDX-License-Identifier: ISC
> +/*
> + * Device Tree file for the Goramo MultiLink Router
> + * There are two variants:
> + * - MultiLink Basic (a box)
> + * - MultiLink Max (19" rack mount)
The Max was usually not 19" rack version, it's the same circa 10" plastic
box as the basic (base?). The 19" case was available independently of
the router hw version (well, not for "micro" version).
As I remember it:
- there was MultiLink Micro: a small router module mounted inside
a DSL-class modem. At least 2 versions, with small differences (maybe
number of Ethernet ports or something like this). 32 MB of RAM, the
latter were using (I think) 64 MB. HSS V.35 connector, the other HSS
was used by the modem. No PCI, no USB.
- Basic: it had 64 MB of RAM. Standalone plastic box. 2 10/100 Ethernets
(built-in, using LXT971 phy - in newer versions (v. 2.x) 2 additional
optional Intel PCI 10/100 Mbps Ethernets). 2 HSS ports (usually V.35
but could be configured, in hardware, as - I imagine - X.21, and even
as T1 or E1 with additional PHY).
- Max: Basic on steroids. 128 MB of RAM (optionally 256 MB), mini PCI
slot (mostly for WiFi).
Original version: NEC USB 2.0 host controller (2 ports).
Newer versions: IDE (PATA) connector, 4 USB 2.0 ports, all provided by
a CS5536 ("Geode compation chip"). I *think* Basic version lacked this
CS5536 (and Basic v. 1.0 lacked NEC USB). Also 2 Intel PCI Gigabit
Ethernets.
All of those hw details were described in a config record in the flash.
> + * This device tree supports MultiLink Basic.
> + * This machine is based on IXP425.
> + * This is one of the few devices supporting the IXP4xx High-Speed Serial
> + * (HSS) link for a V.35 WAN interface.
> + * The hardware seems to originate in Poland.
s/seems to originate/originated/ :-)
> + /*
> + * The Goramo MultiLink Router uses different txready queues
> than any other router,
> + * which makes it likely that it uses non-default firmware for
> the NPE units.
> + */
It used standard firmware, the txready queue # was configurable in
software. I guess it was different from other boards to avoid some
conflict with HSS.
IIRC the queue numbers changed at some point with firmware version.
But all those boards (not only Goramo MultiLinks but generally all
IXP4xx) were supposed to use the last firmware available.
--
Krzysztof "Chris" Hałasa
Sieć Badawcza Łukasiewicz
Przemysłowy Instytut Automatyki i Pomiarów PIAP
Al. Jerozolimskie 202, 02-486 Warszawa
--- End Message ---
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: OpenWrt 21.02 status - DSA documentation status
Folks, I made a start at documentation for the DSA networking in 21.02. I now realize that I have neither the knowledge necessary to write good docs, nor will I have the time to organize this work. Consequently, I have to step back from the following pages: Upgrading to OpenWrt 21.02.0: https://openwrt.org/playground/richb/to2102 DSA Mini-Tutorial: https://openwrt.org/playground/richb/dsa-mini-tutorial Converting to DSA: https://openwrt.org/playground/richb/converting-to-dsa I've already had some help from Arınç ÜNAL (and from Rafał Miłecki's early draft), but I would hope a small team could come together to get this information together before we release 21.02. Thanks. Rich > On Jul 17, 2021, at 5:04 PM, Rich Brown wrote: > > Hauke and all, > > Thanks for the hard work to corral all those outstanding bug reports. > > As we move forward, I want to be sure the documentation side is as good as > the software... I have these comments/questions: > > 1) I created a new "Upgrading to OpenWrt 21.02.0" page at: > https://openwrt.org/playground/richb/to2102 I distilled the announcement page > (https://openwrt.org/releases/21.02/notes-21.02.0) to make this checklist for > people that won't read that entire page. > > Did I get the new page right? Please feel free to edit and make it correct. > > 2) I was pretty fuzzy about what people should do if their target did migrate > to DSA. Do we have a guide to help those people through the transition? > > 3) Is there any OpenWrt document that describes how DSA affects the files in > /etc/config and how it affects LuCI? Do we need to worry that a bunch of > people will glibly upgrade, then be knocked off the air? > > As always, I really appreciate all the effort that goes into OpenWrt. > > Best, > > Rich > >> On Jul 17, 2021, at 11:45 AM, Hauke Mehrtens wrote: >> >> Hi, >> >> In general the 21.02-rc3 looks good, but we still have some problems. >> >> Currently we still have these problem: >> >> - IPv6 broken with flow offloading (according to reports, potentially >> related to hw flow offloading) >> - PPPoE allegedly broken (according to reports, not fully reproducible, >> likely related to hw flow offloading too) >> - https://bugs.openwrt.org/index.php?do=details_id=3909 >> - https://bugs.openwrt.org/index.php?do=details_id=3835 >> - >> https://forum.openwrt.org/t/21-02-snapshot-ipv4-pppoe-session-keeps-terminating/90552 >> - DHCPv6 broken if lease times < 12h chosen >> - >> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/137 >> - >> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/162 >> - WDS with bridge-vlan broken (missing backport from master) >> - cron jobs are triggered in UTC even when the system uses a different time >> zone: >> - >> https://forum.openwrt.org/t/openwrt-21-02-0-third-release-candidate/99363/184 >> >> Thank you Jo for collecting most of them. >> These problems should at least get some investigation and better should get >> fixed before the final release. >> >> In addition there are multiple problems with specific device, if they get >> fixed it would be nice otherwise we just leave it like it is now. >> >> The problem fixed here was also reported in 21.02: >> https://git.openwrt.org/ba5bd8e556b2e7573d27b16e005ba287e066f795 >> @Kevin: Any objections to backport this change to 21.02? Are there any other >> changes needed? >> >> @John: Did you look into the IPv6 Flow offloading problem? >> >> I would like to get some of them fixed or at least investigated and then do >> the final or a rc4, depending of the number of changes. >> I will try to find some time in the next days to investigate some of these >> problems. >> >> Hauke >> ___ >> 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] RFC: ARM: dts: Proposed Goramo MultiLink device tree
This is an example of how I think the Goramo MultiLink device can
be supported in the device tree.
It requires writing a new 74hc4094 GPIO driver and moving a bunch
of the boardfile code into the HSS driver as it is anyways the only
user of this facility. If there are other boards supporting HSS they
can be added too.
To proceed with this I need to be sure someone is willing to test
and help develop this and has interest in supporting the Goramo
MultiLink with recent kernels on e.g. OpenWrt.
I am happy to dry-code most of the code and DT bindings but it
needs to be tested and debugged on target.
I am also willing to write just the device tree bindings so the
device tree can be merged and the implementation be filled in
later. As long as I know there is active interest I'm willing to
do at least this even if it cannot be tested just to have the base
in place.
So is someone up for it? Krysztof?
If not, the boardfile will be deleted as part of the IXP4xx
migration to device tree, yet this shows how to bring it back.
Cc: openwrt-devel@lists.openwrt.org
Signed-off-by: Linus Walleij
---
arch/arm/boot/dts/Makefile| 1 +
.../dts/intel-ixp42x-goramo-multilink.dts | 201 ++
arch/arm/boot/dts/intel-ixp4xx.dtsi | 17 ++
3 files changed, 219 insertions(+)
create mode 100644 arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ac8a4a77584d..2dfb073b31a7 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -247,6 +247,7 @@ dtb-$(CONFIG_ARCH_IXP4XX) += \
intel-ixp46x-ixdp465.dtb \
intel-ixp42x-adi-coyote.dtb \
intel-ixp42x-ixdpg425.dtb \
+ intel-ixp42x-goramo-multilink.dtb \
intel-ixp42x-iomega-nas100d.dtb \
intel-ixp42x-dlink-dsm-g600.dtb \
intel-ixp42x-gateworks-gw2348.dtb \
diff --git a/arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
b/arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
new file mode 100644
index ..bd9a17fb2837
--- /dev/null
+++ b/arch/arm/boot/dts/intel-ixp42x-goramo-multilink.dts
@@ -0,0 +1,201 @@
+// SPDX-License-Identifier: ISC
+/*
+ * Device Tree file for the Goramo MultiLink Router
+ * There are two variants:
+ * - MultiLink Basic (a box)
+ * - MultiLink Max (19" rack mount)
+ * This device tree supports MultiLink Basic.
+ * This machine is based on IXP425.
+ * This is one of the few devices supporting the IXP4xx High-Speed Serial
+ * (HSS) link for a V.35 WAN interface.
+ * The hardware seems to originate in Poland.
+ */
+
+/dts-v1/;
+
+#include "intel-ixp42x.dtsi"
+#include
+
+/ {
+ model = "Goramo MultiLink Router";
+ compatible = "goramo,multilink-router", "intel,ixp42x";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ memory@0 {
+ /*
+* 64 MB of RAM according to the manual. The MultiLink
+* Max has 128 MB.
+*/
+ device_type = "memory";
+ reg = <0x 0x400>;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ stdout-path = "uart0:115200n8";
+ };
+
+ aliases {
+ serial0 =
+ serial1 =
+ };
+
+ /*
+* 74HC4094 which is used as a rudimentary GPIO expander
+* FIXME:
+* - Create device tree bindings for this as GPIO expander
+* - Write a pure DT GPIO driver using these bindings
+* - Support cascading in the style of gpio-74x164.c (cannot be reused,
very different)
+*/
+ gpio_74: gpio-74hc4094 {
+ compatible = "nxp,74hc4094";
+ cp-gpios = < 0 GPIO_ACTIVE_HIGH>;
+ d-gpios = < 1 GPIO_ACTIVE_HIGH>;
+ str-gpios = < 2 GPIO_ACTIVE_HIGH>;
+ /* oe-gpios is optional */
+ gpio-controller;
+ #gpio-cells = <2>;
+ /* We are not cascaded */
+ registers-number = <1>;
+ gpio-line-names = "CONTROL_HSS0_CLK_INT",
"CONTROL_HSS1_CLK_INT", "CONTROL_HSS0_DTR_N",
+ "CONTROL_HSS1_DTR_N", "CONTROL_EXT",
"CONTROL_AUTO_RESET",
+ "CONTROL_PCI_RESET_N", "CONTROL_EEPROM_WC_N";
+ };
+
+ soc {
+ bus@c400 {
+ flash@0,0 {
+ compatible = "intel,ixp4xx-flash", "cfi-flash";
+ bank-width = <2>;
+ /* Enable writes on the expansion bus */
+ intel,ixp4xx-eb-write-enable = <1>;
+ /* 16 MB of Flash mapped in at CS0 */
+ reg = <0 0x 0x100>;
+
+ partitions {
+ compatible = "redboot-fis";
+ /*
Re: OpenWrt 21.02 status
On 7/20/21 9:40 AM, Andy Botting wrote:
- IPv6 broken with flow offloading (according to reports, potentially
related to hw flow offloading)
There is a bug report about this at:
- https://bugs.openwrt.org/index.php?do=details_id=3373
I've reproduced it with and without hw flow offloading on mt7621.
I think it's very important to do something about this issue before
the release, as it took me nearly a week to track down. I found it
quite hard to isolate as it's like some packets just disappear, so
makes for a very bad user experience.
Hi,
Thank you for the link and the description on how to reproduce this:
while [ 1 ]; do curl -k -s -o /dev/null -L -I -w "%{http_code}
'%{time_total}'\n" -H 'Host: www.6connect.com'
https://[2607:fae0:a000::9]; sleep 1; done
I see this problem once every 250 tries, but I got a wireshak capture.
A TCP package is lost and we get the next one after 6 seconds. I would
have expected a retransmission much earlier.
I have to check that I do not see this without the offloading and then
also capture before the device.
Hauke
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 1/2] libtool: bump to 2.4.6
This updates libtool to its current release, from 2015. Current patches
were renumbered and given a description text. The fix in
160-passthrough-ssp.patch is no longer needed.
A patch to speed up build was cherry-picked, and another openwrt
specific patch was needed to not use quotes in $(SHELL), to acommodate
our "SHELL=/usr/bin/env bash" usage.
The already present call to ./bootstrap ensures that generated files are
refreshed, so the patches are applied only to their sources. Also, that
bootstrap call was adjusted to run at the appropriate time when QUILT=1.
Signed-off-by: Eneas U de Queiroz
---
tools/libtool/Makefile| 11 +-
tools/libtool/patches/000-relocatable.patch | 108 ++---
.../libtool/patches/001-fix-func_append.patch | 22 --
tools/libtool/patches/100-libdir-fixes.patch | 97 +++-
...10-dont-use-target-dir-for-relinking.patch | 51 ++--
.../120-strip-unsafe-dirs-for-relinking.patch | 36 +--
...ingslash.patch => 130-trailingslash.patch} | 33 +--
...140-don-t-quote-SHELL-in-Makefile.am.patch | 72 ++
...itigate-the-sed_quote_subst-slowdown.patch | 224 ++
.../libtool/patches/160-passthrough-ssp.patch | 12 -
.../patches/200-openwrt-branding.patch| 134 ++-
11 files changed, 444 insertions(+), 356 deletions(-)
delete mode 100644 tools/libtool/patches/001-fix-func_append.patch
rename tools/libtool/patches/{150-trailingslash.patch =>
130-trailingslash.patch} (57%)
create mode 100644
tools/libtool/patches/140-don-t-quote-SHELL-in-Makefile.am.patch
create mode 100644
tools/libtool/patches/150-libtool-mitigate-the-sed_quote_subst-slowdown.patch
delete mode 100644 tools/libtool/patches/160-passthrough-ssp.patch
diff --git a/tools/libtool/Makefile b/tools/libtool/Makefile
index dd4a7f6380..b237884b64 100644
--- a/tools/libtool/Makefile
+++ b/tools/libtool/Makefile
@@ -8,11 +8,11 @@ include $(TOPDIR)/rules.mk
PKG_NAME:=libtool
PKG_CPE_ID:=cpe:/a:gnu:libtool
-PKG_VERSION:=2.4
+PKG_VERSION:=2.4.6
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
PKG_SOURCE_URL:=@GNU/$(PKG_NAME)
-PKG_HASH:=afcce660d3dc54c63a0a5ba3cf05272239dc3c54bbeba20f6bad250f9dc007ae
+PKG_HASH:=7c87a8c2c8c0fc9cd5019e402bed4292462d00a718a7cd5f11218153bf28b26f
HOST_BUILD_PARALLEL:=1
@@ -24,7 +24,12 @@ HOST_CONFIGURE_VARS += \
define Host/Prepare
$(call Host/Prepare/Default)
(cd $(STAGING_DIR_HOST)/share/aclocal/ && rm -f libtool.m4 ltdl.m4
lt~obsolete.m4 ltoptions.m4 ltsugar.m4 ltversion.m4)
- (cd $(HOST_BUILD_DIR); $(AM_TOOL_PATHS) ./bootstrap)
+ $(if $(QUILT),,(cd $(HOST_BUILD_DIR); touch README-release;
$(AM_TOOL_PATHS) ./bootstrap --skip-git --skip-po --force))
+endef
+
+define Host/Configure
+ $(if $(QUILT),(cd $(HOST_BUILD_DIR); touch README-release;
$(AM_TOOL_PATHS) ./bootstrap --skip-git --skip-po --force))
+ $(call Host/Configure/Default)
endef
define Host/Install
diff --git a/tools/libtool/patches/000-relocatable.patch
b/tools/libtool/patches/000-relocatable.patch
index 55265fe533..88d1eaed02 100644
--- a/tools/libtool/patches/000-relocatable.patch
+++ b/tools/libtool/patches/000-relocatable.patch
@@ -1,46 +1,24 @@
a/libltdl/config/general.m4sh
-+++ b/libltdl/config/general.m4sh
-@@ -45,15 +45,22 @@ progpath="$0"
- M4SH_VERBATIM([[
- : ${CP="cp -f"}
- test "${ECHO+set}" = set || ECHO=${as_echo-'printf %s\n'}
--: ${EGREP="@EGREP@"}
--: ${FGREP="@FGREP@"}
--: ${GREP="@GREP@"}
- : ${LN_S="@LN_S@"}
- : ${MAKE="make"}
- : ${MKDIR="mkdir"}
- : ${MV="mv -f"}
- : ${RM="rm -f"}
--: ${SED="@SED@"}
-+if test -n "$STAGING_DIR"; then
-+ : ${EGREP="$STAGING_DIR/../host/bin/grep -E"}
-+ : ${FGREP="$STAGING_DIR/../host/bin/grep -F"}
-+ : ${GREP="$STAGING_DIR/../host/bin/grep"}
-+ : ${SED="$STAGING_DIR/../host/bin/sed"}
-+else
-+ : ${EGREP="@EGREP@"}
-+ : ${FGREP="@FGREP@"}
-+ : ${GREP="@GREP@"}
-+ : ${SED="@SED@"}
-+fi
- : ${SHELL="${CONFIG_SHELL-/bin/sh}"}
- : ${Xsed="$SED -e 1s/^X//"}
-
+From ca10caa502f971f90d8c041aa2476de54ef0ce2b Mon Sep 17 00:00:00 2001
+From: Eneas U de Queiroz
+Date: Tue, 20 Jul 2021 16:41:11 -0300
+Subject: openwrt: make relocatable, search resources relative to STAGING_DIR
+
+This was originally commited to openwrt by Jo-Philipp Wich
+.
+
+(adjusted to v2.4.6)
+Signed-off-by: Eneas U de Queiroz
+
--- a/libtoolize.in
+++ b/libtoolize.in
-@@ -326,15 +326,22 @@ as_unset=as_fn_unset
+@@ -40,11 +40,18 @@
- : ${CP="cp -f"}
- test "${ECHO+set}" = set || ECHO=${as_echo-'printf %s\n'}
+ : ${AUTOCONF="autoconf"}
+ : ${AUTOMAKE="automake"}
-: ${EGREP="@EGREP@"}
-: ${FGREP="@FGREP@"}
-: ${GREP="@GREP@"}
: ${LN_S="@LN_S@"}
- : ${MAKE="make"}
- : ${MKDIR="mkdir"}
- : ${MV="mv -f"}
- : ${RM="rm -f"}
-: ${SED="@SED@"}
+if test -n "$STAGING_DIR"; then
+ : ${EGREP="$STAGING_DIR/../host/bin/grep -E"}
@@ -53,58 +31,12 @@
+ : ${GREP="@GREP@"}
+ : ${SED="@SED@"}
+fi
- : ${SHELL="${CONFIG_SHELL-/bin/sh}"}
- :
[PATCH v2 2/2] wolfssl: bump to v4.8.1-stable
Release 4.8.1 of wolfSSL embedded TLS has bug fixes and new features including this vulnerability: * [high] OCSP verification issue when response is for a certificate with no relation to the chain in question BUT that response contains the NoCheck extension which effectively disables ALL verification of that one cert. * [Low] OCSP request/response verification issue. In the case that the serial number in the OCSP request differs from the serial number in the OCSP response the error from the comparison was not resulting in a failed verification. (fixed in 4.8.0) Signed-off-by: Eneas U de Queiroz --- package/libs/wolfssl/Makefile | 6 +++--- .../libs/wolfssl/patches/100-disable-hardening-check.patch | 2 +- package/libs/wolfssl/patches/200-ecc-rng.patch | 4 ++-- 3 files changed, 6 insertions(+), 6 deletions(-) diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile index 0c95288a2a..6ef80e88a9 100644 --- a/package/libs/wolfssl/Makefile +++ b/package/libs/wolfssl/Makefile @@ -8,12 +8,12 @@ include $(TOPDIR)/rules.mk PKG_NAME:=wolfssl -PKG_VERSION:=4.7.0-stable -PKG_RELEASE:=2 +PKG_VERSION:=4.8.1-stable +PKG_RELEASE:=1 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION) -PKG_HASH:=b0e740b31d4d877d540ad50cc539a8873fc41af02bd3091c4357b403f7106e31 +PKG_HASH:=50db45f348f47e00c93dd244c24108220120cb3cc9d01434789229c32937c444 PKG_FIXUP:=libtool libtool-abiver PKG_INSTALL:=1 diff --git a/package/libs/wolfssl/patches/100-disable-hardening-check.patch b/package/libs/wolfssl/patches/100-disable-hardening-check.patch index c89ff1be9d..4141e28750 100644 --- a/package/libs/wolfssl/patches/100-disable-hardening-check.patch +++ b/package/libs/wolfssl/patches/100-disable-hardening-check.patch @@ -1,6 +1,6 @@ --- a/wolfssl/wolfcrypt/settings.h +++ b/wolfssl/wolfcrypt/settings.h -@@ -2255,7 +2255,7 @@ extern void uITRON4_free(void *p) ; +@@ -2274,7 +2274,7 @@ extern void uITRON4_free(void *p) ; #endif /* warning for not using harden build options (default with ./configure) */ diff --git a/package/libs/wolfssl/patches/200-ecc-rng.patch b/package/libs/wolfssl/patches/200-ecc-rng.patch index 2d33c06209..d8581be7eb 100644 --- a/package/libs/wolfssl/patches/200-ecc-rng.patch +++ b/package/libs/wolfssl/patches/200-ecc-rng.patch @@ -11,7 +11,7 @@ RNG regardless of the built settings for wolfssl. --- a/wolfcrypt/src/ecc.c +++ b/wolfcrypt/src/ecc.c -@@ -10293,21 +10293,21 @@ void wc_ecc_fp_free(void) +@@ -10938,21 +10938,21 @@ void wc_ecc_fp_free(void) #endif /* FP_ECC */ @@ -37,7 +37,7 @@ RNG regardless of the built settings for wolfssl. --- a/wolfssl/wolfcrypt/ecc.h +++ b/wolfssl/wolfcrypt/ecc.h -@@ -584,10 +584,8 @@ WOLFSSL_API +@@ -616,10 +616,8 @@ WOLFSSL_API void wc_ecc_fp_free(void); WOLFSSL_LOCAL void wc_ecc_fp_init(void); ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 0/2] Bump WolfSSL and libtool
v1->v2: WolfSSL was updated from 4.8.0, in the original series, to
4.8.1 due to a high-risk vulnerability. Patches were refreshed.
WolfSSL has decided it needs at least libtool 2.4.2 to build. From
their commit 92854a5dd message:
advance LT_PREREQ from 2.2 (2008) to 2.4.2 (2011) to reflect current
automated testing coverage.
We could easily patch our way out of it, but I decided to try the
upgrade first. It appears to work just fine. I've just rebuilt the
whole tree for my Linksys E8450 (mt7622), and tested the WolfSSL update
with hostapd and uhttpd. I've had no hickups, but of course ymmv.
My major concern while bumping a core building tool was how it could
affect the changes we have in place. I've looked at both our patches,
and at what was changed upstream.
The major changes were related to getting the gnulib sources from git,
and refreshing them when running bootstrap. Since we are applying
patches, getting fresh copies are not viable, but there's a command-line
option to avoid doing it.
I'm not so sure what to do about 21.02.
1. Patch WolfSSL to accept building with libtool 2.4;
2. Bump libtool to 2.4.2: 11 *relevant* files changed from 2.4,
424 insertions(+), 198 deletions(-).
This was before the gnulib changes. For a comparison, there are
71 files changed, 17143 insertions(+), 5697 deletions(-), when going
from 2.4 to 2.4.6.
3. Bump both to keep in sync with master.
My vote: do 1 now, and wait for possible fallout from master. Then,
perhaps try to keep them in sync, at the following point release.
Cheers
Eneas U de Queiroz (2):
libtool: bump to 2.4.6
wolfssl: bump to v4.8.1-stable
package/libs/wolfssl/Makefile | 6 +-
.../patches/100-disable-hardening-check.patch | 2 +-
.../libs/wolfssl/patches/200-ecc-rng.patch| 4 +-
tools/libtool/Makefile| 11 +-
tools/libtool/patches/000-relocatable.patch | 108 ++---
.../libtool/patches/001-fix-func_append.patch | 22 --
tools/libtool/patches/100-libdir-fixes.patch | 97 +++-
...10-dont-use-target-dir-for-relinking.patch | 51 ++--
.../120-strip-unsafe-dirs-for-relinking.patch | 36 +--
...ingslash.patch => 130-trailingslash.patch} | 33 +--
...140-don-t-quote-SHELL-in-Makefile.am.patch | 72 ++
...itigate-the-sed_quote_subst-slowdown.patch | 224 ++
.../libtool/patches/160-passthrough-ssp.patch | 12 -
.../patches/200-openwrt-branding.patch| 134 ++-
14 files changed, 450 insertions(+), 362 deletions(-)
delete mode 100644 tools/libtool/patches/001-fix-func_append.patch
rename tools/libtool/patches/{150-trailingslash.patch =>
130-trailingslash.patch} (57%)
create mode 100644
tools/libtool/patches/140-don-t-quote-SHELL-in-Makefile.am.patch
create mode 100644
tools/libtool/patches/150-libtool-mitigate-the-sed_quote_subst-slowdown.patch
delete mode 100644 tools/libtool/patches/160-passthrough-ssp.patch
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
