Re: Flagship AX routers
On 19.05.21 00:09, Paul Spooren wrote: Hi, On 5/18/21 11:52 PM, Philip Prindeville wrote: Hi all, I noticed that there are several AX routers from TP-Link, Netgear, D-Link, etc. and some of them have even had OpenWRT ported to them. Which of these various platforms has the most CPU/RAM/FLASH? A few are discussed, but I'm not seeing consensus on "the best one currently is this..." I'm using both a Belkin RT3200 and a Linksys AX3200 (aka E8450), which are conveniently pretty much the same thing and I'm having a pretty good time. Would flash again. Best, Paul this is the goto unit for AX right now ... https://openwrt.org/toh/linksys/linksys_e8450 consider using this to flash the unit https://github.com/dangowrt/linksys-e8450-openwrt-installer John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: opkg fails to install manually downloaded packages
Hauke, thanks for the pointer. My comments in the original thread. Sven Am Sonntag, 16. Mai 2021, 23:34:04 CEST schrieb Hauke Mehrtens: > > I debugged a similar problem a week ago and added this patch to opkg: > https://patchwork.ozlabs.org/project/openwrt/patch/20210502205912.23753-1-ha > u...@hauke-m.de/ > > This shows the missing dependencies, but I am not sure if the > pkg_hash_check_unresolved() function could also fail in good cases. > > Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH opkg] libopkg: pkg_hash: print unresolved dependencies
Hi,
Am Montag, 3. Mai 2021, 19:46:22 CEST schrieb Hauke Mehrtens:
> On 5/3/21 2:38 PM, Baptiste Jonglez wrote:
> > Hi,
> >
> > On 02-05-21, Hauke Mehrtens wrote:
> >> When a package is not installed because it has unresolved dependencies
> >>
> >> normally we get only an error message like this:
> >> * pkg_hash_fetch_best_installation_candidate: Packages for ltq-vdsl-app
> >> found, but incompatible with the architectures configured *
> >> opkg_install_cmd: Cannot install package ltq-vdsl-app.
> >>
> >> Log in addition the following error message:
> >> * pkg_hash_check_unresolved: can not find dependency ltq-dsl-base for
> >> ltq-vdsl-app>
> > Since the error has probably nothing to do with "architectures", wouldn't
> > it make more sense to remove or improve the first error message? Or
> > understand why it fails for seemingly unrelated reasons.
>
> This "incompatible with the architectures configured" error message is
> shown for more error cases than the newly added one, see here:
> https://lxr.openwrt.org/source/opkg-lede/libopkg/pkg_hash.c#L395
>
> It would probably be good to improve the error messages, but I do not
> understand the full code. If someone has some suggestions on how to
> improve this it would be nice.
>
Hauke mentioined this patch in relation to FS#3814. I build a patched version
myself and gave it a test - It fixes the problem
Having no packagelist avail an trying to install luci-proto-ipip results in a
message pointing towards the missing dependent package
~# opkg install /tmp/luci-proto-ipip_git-19.307.61018-284918b_all.ipk
Unknown package 'luci-proto-ipip'.
Collected errors:
* pkg_hash_check_unresolved: can not find dependency ipip for luci-proto-ipip
* pkg_hash_fetch_best_installation_candidate: Packages for luci-proto-ipip
found, but incompatible with the architectures configured
* opkg_install_cmd: Cannot install package luci-proto-ipip.
The "Unknown package 'luci-proto-ipip'." line is still incorrect, but "can not
find dependency ipip" is the key.
So maybe not the last change to the code, but a big improvement.
Sven
> >> Signed-off-by: Hauke Mehrtens
> >> ---
> >>
> >> I am not sure if this would happen in normal cases too and spam the
> >> error log, I only saw this in an error case.
> >>
> >> libopkg/pkg_hash.c | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libopkg/pkg_hash.c b/libopkg/pkg_hash.c
> >> index a07a25e..6c04ab2 100644
> >> --- a/libopkg/pkg_hash.c
> >> +++ b/libopkg/pkg_hash.c
> >> @@ -263,8 +263,10 @@ pkg_hash_check_unresolved(pkg_t *maybe)
> >>
> >>if (unresolved) {
> >>
> >>res = 1;
> >>tmp = unresolved;
> >>
> >> - while (*tmp)
> >> + while (*tmp) {
> >> + opkg_msg(ERROR, "can not find dependency %s for %s\n",
> >> *tmp,
> >> maybe->name);>>
> >>free(*(tmp++));
> >>
> >> + }
> >>
> >>free(unresolved);
> >>
> >>}
> >>pkg_vec_free(depends);
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Flagship AX routers
Hi, On 5/18/21 11:52 PM, Philip Prindeville wrote: Hi all, I noticed that there are several AX routers from TP-Link, Netgear, D-Link, etc. and some of them have even had OpenWRT ported to them. Which of these various platforms has the most CPU/RAM/FLASH? A few are discussed, but I'm not seeing consensus on "the best one currently is this..." I'm using both a Belkin RT3200 and a Linksys AX3200 (aka E8450), which are conveniently pretty much the same thing and I'm having a pretty good time. Would flash again. Best, Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Flagship AX routers
Hi all, I noticed that there are several AX routers from TP-Link, Netgear, D-Link, etc. and some of them have even had OpenWRT ported to them. Which of these various platforms has the most CPU/RAM/FLASH? A few are discussed, but I'm not seeing consensus on "the best one currently is this..." https://forum.openwrt.org/t/802-11ax-routers/10484/281 Also saw this: https://10-0-0-0-1.org/reviews/routers/openwrt/ But it only lists AC routers. Was looking at this: https://www.amazon.com/TP-Link-WiFi-AX3000-Smart-Router/dp/B07YMFZ28Q/ But it doesn't call out CPU, memory, or storage. Got there from this page: https://www.amazon.com/OpenWrt-Routers-Networking-Products/s?k=OpenWrt&rh=n%3A300189 Thanks, -Philip ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] base-files: migrate old UCI network sections defining bridges
From: Rafał Miłecki
Old "interface" sections for bridges were mixing layer 2 and layer 3.
That syntax got deprecated and UCI section "device" is used for bridge
configuration now.
Backward compatibility may be dropped from netifd soon now so migrate
old configs using uci-defaults script.
Signed-off-by: Rafał Miłecki
---
That "soon" is relative, I'm not planning to push this patch yet. We may
give updated /etc/config/network few months to receive proper testing.
---
.../uci-defaults/11_network-migrate-bridges | 24 +++
1 file changed, 24 insertions(+)
diff --git
a/package/base-files/files/etc/uci-defaults/11_network-migrate-bridges
b/package/base-files/files/etc/uci-defaults/11_network-migrate-bridges
index 745648531f..7188c06ce3 100644
--- a/package/base-files/files/etc/uci-defaults/11_network-migrate-bridges
+++ b/package/base-files/files/etc/uci-defaults/11_network-migrate-bridges
@@ -17,7 +17,31 @@ migrate_ports() {
uci delete network.$config.ifname
}
+migrate_bridge() {
+ local config="$1"
+ local type ifname
+
+ config_get type "$config" type
+ [ "$type" != "bridge" ] && return
+
+ config_get ifname "$config" ifname
+
+ uci -q batch <<-EOF
+ add network device
+ set network.@device[-1].name='br-$config'
+ set network.@device[-1].type='bridge'
+ EOF
+ for port in $ifname; do uci add_list network.@device[-1].ports="$port";
done
+
+ uci -q batch <<-EOF
+ delete network.$config.type
+ set network.$config.ifname='br-$config'
+ EOF
+}
+
config_load network
config_foreach migrate_ports device
+config_foreach migrate_bridge interface
+uci commit network
exit 1
--
2.26.2
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 2/2] ramips: mt7621: Add support for ZyXEL LTE3301-Plus
The ZyXEL LTE3301-Plus is an 4G indoor CPE with 2 external LTE antennas.
Specifications:
- SoC: MediaTek MT7621AT
- RAM: 256 MB
- Flash: 128 MB MB NAND (MX30LF1G18AC)
- WiFi: MediaTek MT7615E
- Switch: 4 LAN ports (Gigabit)
- LTE: Quectel EG506 connected by USB3 to SoC
- SIM: 1 micro-SIM slot
- USB: USB3 port
- Buttons: Reset, WPS
- LEDs: Multicolour power, internet, LTE, signal, Wifi, USB
- Power: 12V, 1.5A
The device is built as an indoor ethernet to LTE bridge or router with Wifi.
UART Serial:
57600N1
Located on populated 5 pin header J5:
[o] GND
[ ] key - no pin
[o] 3.3V Vcc
[o] RX
[o] TX
MAC assignment:
lan: 98:0d:67:ee:85:54 (base, on the device back)
wlan: 98:0d:67:ee:85:55
For more details about flashing see commit
2449a632084b29632605e5a79ce5d73028eb15dd .
Signed-off-by: André Valentin
---
package/boot/uboot-envtools/files/ramips | 1 +
.../ramips/dts/mt7621_zyxel_lte3301-plus.dts | 213 ++
target/linux/ramips/image/mt7621.mk | 19 ++
.../mt7621/base-files/etc/board.d/01_leds | 3 +
.../mt7621/base-files/etc/board.d/02_network | 3 +-
.../base-files/etc/board.d/03_gpio_switches | 4 +
.../mt7621/base-files/etc/init.d/bootcount| 1 +
.../mt7621/base-files/lib/upgrade/platform.sh | 1 +
8 files changed, 244 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
diff --git a/package/boot/uboot-envtools/files/ramips
b/package/boot/uboot-envtools/files/ramips
index bce2e5f0fb..4d0e608911 100644
--- a/package/boot/uboot-envtools/files/ramips
+++ b/package/boot/uboot-envtools/files/ramips
@@ -53,6 +53,7 @@ xiaomi,mi-router-ac2100|\
xiaomi,redmi-router-ac2100)
ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x1000" "0x2"
;;
+zyxel,lte3301-plus|\
zyxel,nr7101)
idx="$(find_mtd_index Config)"
[ -n "$idx" ] && \
diff --git a/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
new file mode 100644
index 00..af2e792cb8
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "zyxel,lte3301-plus", "mediatek,mt7621-soc";
+ model = "ZyXEL LTE3301-PLUS";
+
+ aliases {
+ label-mac-device = &gmac0;
+ led-boot = &led_power;
+ led-failsafe = &led_power;
+ led-running = &led_power;
+ led-upgrade = &led_power;
+ };
+
+ gpio_export {
+ compatible = "gpio-export";
+
+ lte_power {
+ gpio-export,name = "lte_power";
+ gpio-export,output = <1>;
+ gpios = <&gpio 27 GPIO_ACTIVE_LOW>;
+ };
+
+ usb_power {
+ gpio-export,name = "usb_power";
+ gpio-export,output = <1>;
+ gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power: power {
+ label = "white:power";
+ gpios = <&gpio 5 GPIO_ACTIVE_HIGH>;
+ };
+
+ wifi {
+ label = "white:wifi";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ internet {
+ label = "white:internet";
+ gpios = <&gpio 23 GPIO_ACTIVE_LOW>;
+ };
+
+ usb {
+ label = "white:usb";
+ gpios = <&gpio 24 GPIO_ACTIVE_LOW>;
+ trigger-sources = <&xhci_ehci_port1>, <&ehci_port2>;
+ linux,default-trigger = "usbport";
+ };
+
+ lte {
+ label = "white:lte";
+ gpios = <&gpio 26 GPIO_ACTIVE_LOW>;
+ };
+
+ mobile_green {
+ label = "green:mobile";
+ gpios = <&gpio 31 GPIO_ACTIVE_LOW>;
+ };
+
+ mobile_orange {
+ label = "orange:mobile";
+ gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
+ };
+
+ mobile_red {
+ label = "red:mobile";
+ gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ wps {
+ label = "wps";
+ gpios = <&gpio 6 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+
[PATCH v3 1/2] firmware-utils: zytrx: Add support for ZyXEL LTE3301-Plus
This adds a new device id to the image tools.
Signed-off-by: André Valentin
---
tools/firmware-utils/src/zytrx.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/tools/firmware-utils/src/zytrx.c b/tools/firmware-utils/src/zytrx.c
index 302efc6010..b3bbbe3c69 100644
--- a/tools/firmware-utils/src/zytrx.c
+++ b/tools/firmware-utils/src/zytrx.c
@@ -96,6 +96,7 @@ static struct board_t {
uint32_t modelid;
} boards[] = {
{ "MT7621A", "NR7101", 0x07010001 },
+ { "MT7621A", "LTE3301-PLUS", 0x03030001 },
{}
};
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3 0/2] Add support for ZyXEL LTE3301-Plus
This set adds support for the ZyXEL LTE3301-Plus, an indoor 3G/4G indoor LTE router with Wifi. André Valentin (2): firmware-utils: zytrx: Add support for ZyXEL LTE3301-Plus ramips: mt7621: Add support for ZyXEL LTE3301-Plus package/boot/uboot-envtools/files/ramips | 1 + .../ramips/dts/mt7621_zyxel_lte3301-plus.dts | 213 ++ target/linux/ramips/image/mt7621.mk | 19 ++ .../mt7621/base-files/etc/board.d/01_leds | 3 + .../mt7621/base-files/etc/board.d/02_network | 3 +- .../base-files/etc/board.d/03_gpio_switches | 4 + .../mt7621/base-files/etc/init.d/bootcount| 1 + .../mt7621/base-files/lib/upgrade/platform.sh | 1 + tools/firmware-utils/src/zytrx.c | 1 + 9 files changed, 245 insertions(+), 1 deletion(-) create mode 100644 target/linux/ramips/dts/mt7621_zyxel_lte3301-plus.dts -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 2/2] hostapd: wolfssl: add RNG to EC key
Since upstream commit 6467de5a8840 ("Randomize z ordinates in
scalar mult when timing resistant") WolfSSL requires a RNG for
the EC key when built hardened which is the default.
Set the RNG for the EC key to fix connections for OWE clients.
Signed-off-by: David Bauer
---
package/network/services/hostapd/Makefile | 2 +-
.../0001-wolfssl-init-RNG-with-ECC-key.patch | 48 +++
2 files changed, 49 insertions(+), 1 deletion(-)
create mode 100644
package/network/services/hostapd/patches/0001-wolfssl-init-RNG-with-ECC-key.patch
diff --git a/package/network/services/hostapd/Makefile
b/package/network/services/hostapd/Makefile
index bd2a7c96ad..0779421b8d 100644
--- a/package/network/services/hostapd/Makefile
+++ b/package/network/services/hostapd/Makefile
@@ -7,7 +7,7 @@
include $(TOPDIR)/rules.mk
PKG_NAME:=hostapd
-PKG_RELEASE:=32
+PKG_RELEASE:=33
PKG_SOURCE_URL:=http://w1.fi/hostap.git
PKG_SOURCE_PROTO:=git
diff --git
a/package/network/services/hostapd/patches/0001-wolfssl-init-RNG-with-ECC-key.patch
b/package/network/services/hostapd/patches/0001-wolfssl-init-RNG-with-ECC-key.patch
new file mode 100644
index 00..89d111e991
--- /dev/null
+++
b/package/network/services/hostapd/patches/0001-wolfssl-init-RNG-with-ECC-key.patch
@@ -0,0 +1,48 @@
+From 21ce83b4ae2b9563175fdb4fc4312096cc399cf8 Mon Sep 17 00:00:00 2001
+From: David Bauer
+Date: Wed, 5 May 2021 00:44:34 +0200
+Subject: [PATCH] wolfssl: add RNG to EC key
+
+Since upstream commit 6467de5a8840 ("Randomize z ordinates in
+scalar mult when timing resistant") WolfSSL requires a RNG for
+the EC key when built hardened which is the default.
+
+Set the RNG for the EC key to fix connections for OWE clients.
+
+Signed-off-by: David Bauer
+---
+ src/crypto/crypto_wolfssl.c | 4
+ 1 file changed, 4 insertions(+)
+
+diff --git a/src/crypto/crypto_wolfssl.c b/src/crypto/crypto_wolfssl.c
+index 2e4bf8962..ed2528159 100644
+--- a/src/crypto/crypto_wolfssl.c
b/src/crypto/crypto_wolfssl.c
+@@ -1303,6 +1303,7 @@ int ecc_projective_add_point(ecc_point *P, ecc_point *Q,
ecc_point *R,
+
+ struct crypto_ec {
+ ecc_key key;
++ WC_RNG rng;
+ mp_int a;
+ mp_int prime;
+ mp_int order;
+@@ -1357,6 +1358,8 @@ struct crypto_ec * crypto_ec_init(int group)
+ return NULL;
+
+ if (wc_ecc_init(&e->key) != 0 ||
++ wc_InitRng(&e->rng) != 0 ||
++ wc_ecc_set_rng(&e->key, &e->rng) != 0 ||
+ wc_ecc_set_curve(&e->key, 0, curve_id) != 0 ||
+ mp_init(&e->a) != MP_OKAY ||
+ mp_init(&e->prime) != MP_OKAY ||
+@@ -1388,6 +1391,7 @@ void crypto_ec_deinit(struct crypto_ec* e)
+ mp_clear(&e->order);
+ mp_clear(&e->prime);
+ mp_clear(&e->a);
++ wc_FreeRng(&e->rng);
+ wc_ecc_free(&e->key);
+ os_free(e);
+ }
+--
+2.31.1
+
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 0/2] Fix OWE mode with hostapd-wolfssl
OWE operation of WolfSSL hostapd and wpad daemons has been broken since WolfSSL was updated to 4.5.0. This is due to the fact WolfSSL now requires a RNG for EC keys, however there is no stable interface available for hardened as well as non-hardened builds. Patch hostapd to add the RNG to the EC key and WolfSSL to export the interface regardless of the build settings. David Bauer (2): wolfssl: always export wc_ecc_set_rng hostapd: wolfssl: add RNG to EC key package/libs/wolfssl/Makefile | 2 +- .../libs/wolfssl/patches/200-ecc-rng.patch| 50 +++ package/network/services/hostapd/Makefile | 2 +- .../0001-wolfssl-init-RNG-with-ECC-key.patch | 48 ++ 4 files changed, 100 insertions(+), 2 deletions(-) create mode 100644 package/libs/wolfssl/patches/200-ecc-rng.patch create mode 100644 package/network/services/hostapd/patches/0001-wolfssl-init-RNG-with-ECC-key.patch -- 2.31.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH 1/2] wolfssl: always export wc_ecc_set_rng
Since commit 6467de5a8840 ("Randomize z ordinates in scalar
mult when timing resistant") wolfssl requires a RNG for an EC
key when the hardened built option is selected.
wc_ecc_set_rng is only available when built hardened, so there
is no safe way to install the RNG to the key regardless whether
or not wolfssl is compiled hardened.
Always export wc_ecc_set_rng so tools such as hostapd can install
RNG regardless of the built settings for wolfssl.
Signed-off-by: David Bauer
---
package/libs/wolfssl/Makefile | 2 +-
.../libs/wolfssl/patches/200-ecc-rng.patch| 50 +++
2 files changed, 51 insertions(+), 1 deletion(-)
create mode 100644 package/libs/wolfssl/patches/200-ecc-rng.patch
diff --git a/package/libs/wolfssl/Makefile b/package/libs/wolfssl/Makefile
index 53cd932d1f..030a0224f5 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.7.0-stable
-PKG_RELEASE:=1
+PKG_RELEASE:=2
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=https://github.com/wolfSSL/wolfssl/archive/v$(PKG_VERSION)
diff --git a/package/libs/wolfssl/patches/200-ecc-rng.patch
b/package/libs/wolfssl/patches/200-ecc-rng.patch
new file mode 100644
index 00..2d33c06209
--- /dev/null
+++ b/package/libs/wolfssl/patches/200-ecc-rng.patch
@@ -0,0 +1,50 @@
+Since commit 6467de5a8840 ("Randomize z ordinates in scalar
+mult when timing resistant") wolfssl requires a RNG for an EC
+key when the hardened built option is selected.
+
+wc_ecc_set_rng is only available when built hardened, so there
+is no safe way to install the RNG to the key regardless whether
+or not wolfssl is compiled hardened.
+
+Always export wc_ecc_set_rng so tools such as hostapd can install
+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)
+
+ #endif /* FP_ECC */
+
+-#ifdef ECC_TIMING_RESISTANT
+ int wc_ecc_set_rng(ecc_key* key, WC_RNG* rng)
+ {
+ int err = 0;
+
++#ifdef ECC_TIMING_RESISTANT
+ if (key == NULL) {
+ err = BAD_FUNC_ARG;
+ }
+ else {
+ key->rng = rng;
+ }
++#endif
+
+ return err;
+ }
+-#endif
+
+ #ifdef HAVE_ECC_ENCRYPT
+
+--- a/wolfssl/wolfcrypt/ecc.h
b/wolfssl/wolfcrypt/ecc.h
+@@ -584,10 +584,8 @@ WOLFSSL_API
+ void wc_ecc_fp_free(void);
+ WOLFSSL_LOCAL
+ void wc_ecc_fp_init(void);
+-#ifdef ECC_TIMING_RESISTANT
+ WOLFSSL_API
+ int wc_ecc_set_rng(ecc_key* key, WC_RNG* rng);
+-#endif
+
+ WOLFSSL_API
+ int wc_ecc_set_curve(ecc_key* key, int keysize, int curve_id);
--
2.31.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mvebu: 5.10: fix DVFS caused random boot crashes
On Tue, May 18, 2021 at 8:36 PM Hauke Mehrtens wrote:
>
> On 5/18/21 7:03 PM, Robert Marko wrote:
> > 5.10.37 introduced a lot of DVFS changes for Armada 37xx from 5.13 kernel.
> >
> > Unfortunately commit:
> > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/cpufreq/armada-37xx-cpufreq.c?h=v5.10.37&id=a13b110e7c9e0dc2edcc7a19d4255fc88abd83cc
> >
> > This patch actually corrects the things so that 1 or 1.2GHz models would
> > actually get scaled to their native frequency.
> >
> > However, due to a AVS setting voltages too low this will cause random
> > crashes on 1.2GHz models.
> >
> > So, until a new safe for everybody voltage is agreed on
> > lets revert the patch.
> >
> > Fixes: d337731 ("kernel: bump 5.10 to 5.10.37")
> > Signed-off-by: Robert Marko
>
> This commit was also backported to v5.4.119 and is now in OpenWrt 21.02
> branch, we should probably also revbert it there.
Ok, I can make a patch for that as well as part of v2.
>
> @Robert Are you working with upstream Linux to fix this problem upstream
> too? For now this revert should be fine.
Yes, I was talking to Pali who did most of the CPUFreq changes to see
what can be done.
Essentially, it seems like Marvell is not cooperating at all, their
docs state incorrect recommended voltage, etc.
I was only able to get my board stable under 30m stress test with 1.2V
which is listed as max voltage but in the boards
OTP 1.26V is hardcoded as the starting voltage, so it's currently a mess.
Robert
>
> hauke
--
Robert Marko
Staff Embedded Linux Engineer
Sartura Ltd.
Lendavska ulica 16a
1 Zagreb, Croatia
Email: robert.ma...@sartura.hr
Web: www.sartura.hr
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] mvebu: 5.10: fix DVFS caused random boot crashes
On 5/18/21 7:03 PM, Robert Marko wrote:
5.10.37 introduced a lot of DVFS changes for Armada 37xx from 5.13 kernel.
Unfortunately commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/cpufreq/armada-37xx-cpufreq.c?h=v5.10.37&id=a13b110e7c9e0dc2edcc7a19d4255fc88abd83cc
This patch actually corrects the things so that 1 or 1.2GHz models would
actually get scaled to their native frequency.
However, due to a AVS setting voltages too low this will cause random crashes
on 1.2GHz models.
So, until a new safe for everybody voltage is agreed on
lets revert the patch.
Fixes: d337731 ("kernel: bump 5.10 to 5.10.37")
Signed-off-by: Robert Marko
This commit was also backported to v5.4.119 and is now in OpenWrt 21.02
branch, we should probably also revbert it there.
@Robert Are you working with upstream Linux to fix this problem upstream
too? For now this revert should be fine.
hauke
OpenPGP_0x93DD20630910B515.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Resize of ath79 / ZyXEL NBG6716 kernel partition
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! The NBG6716 has recently been disabled because of size problems with the kernel partition. I'm thinking about extending it to 8MB, shouldn't be a problem. But I'm afraid users will brick their device when doing a sysupgrade to the new flash layout. First time / in upgrade case it must be installed via manufacturer webif or via bootloader. What do you propose in these cases? Kind regards, André --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mvebu: 5.10: fix DVFS caused random boot crashes
5.10.37 introduced a lot of DVFS changes for Armada 37xx from 5.13 kernel.
Unfortunately commit:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/drivers/cpufreq/armada-37xx-cpufreq.c?h=v5.10.37&id=a13b110e7c9e0dc2edcc7a19d4255fc88abd83cc
This patch actually corrects the things so that 1 or 1.2GHz models would
actually get scaled to their native frequency.
However, due to a AVS setting voltages too low this will cause random crashes
on 1.2GHz models.
So, until a new safe for everybody voltage is agreed on
lets revert the patch.
Fixes: d337731 ("kernel: bump 5.10 to 5.10.37")
Signed-off-by: Robert Marko
---
...rmada-37xx-Fix-setting-TBG-parent-fo.patch | 101 ++
1 file changed, 101 insertions(+)
create mode 100644
target/linux/mvebu/patches-5.10/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch
diff --git
a/target/linux/mvebu/patches-5.10/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch
b/target/linux/mvebu/patches-5.10/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch
new file mode 100644
index 00..1a44d89ac9
--- /dev/null
+++
b/target/linux/mvebu/patches-5.10/803-Revert-cpufreq-armada-37xx-Fix-setting-TBG-parent-fo.patch
@@ -0,0 +1,101 @@
+From 2dd652976b099f4234fcb8812a2d504bb78f5a24 Mon Sep 17 00:00:00 2001
+From: Robert Marko
+Date: Tue, 18 May 2021 13:24:30 +0200
+Subject: [PATCH] Revert "cpufreq: armada-37xx: Fix setting TBG parent for load
+ levels"
+
+This reverts commit a13b110e7c9e0dc2edcc7a19d4255fc88abd83cc.
+
+This commit broke Espressobin Ultra boards with weird and random
+kernel crashes during booting.
+
+Signed-off-by: Robert Marko
+---
+ drivers/cpufreq/armada-37xx-cpufreq.c | 35 +--
+ 1 file changed, 12 insertions(+), 23 deletions(-)
+
+--- a/drivers/cpufreq/armada-37xx-cpufreq.c
b/drivers/cpufreq/armada-37xx-cpufreq.c
+@@ -25,10 +25,6 @@
+
+ #include "cpufreq-dt.h"
+
+-/* Clk register set */
+-#define ARMADA_37XX_CLK_TBG_SEL 0
+-#define ARMADA_37XX_CLK_TBG_SEL_CPU_OFF 22
+-
+ /* Power management in North Bridge register set */
+ #define ARMADA_37XX_NB_L0L1 0x18
+ #define ARMADA_37XX_NB_L2L3 0x1C
+@@ -126,15 +122,10 @@ static struct armada_37xx_dvfs *armada_3
+ * will be configured then the DVFS will be enabled.
+ */
+ static void __init armada37xx_cpufreq_dvfs_setup(struct regmap *base,
+- struct regmap *clk_base, u8
*divider)
++ struct clk *clk, u8 *divider)
+ {
+- u32 cpu_tbg_sel;
+ int load_lvl;
+-
+- /* Determine to which TBG clock is CPU connected */
+- regmap_read(clk_base, ARMADA_37XX_CLK_TBG_SEL, &cpu_tbg_sel);
+- cpu_tbg_sel >>= ARMADA_37XX_CLK_TBG_SEL_CPU_OFF;
+- cpu_tbg_sel &= ARMADA_37XX_NB_TBG_SEL_MASK;
++ struct clk *parent;
+
+ for (load_lvl = 0; load_lvl < LOAD_LEVEL_NR; load_lvl++) {
+ unsigned int reg, mask, val, offset = 0;
+@@ -153,11 +144,6 @@ static void __init armada37xx_cpufreq_dv
+ mask = (ARMADA_37XX_NB_CLK_SEL_MASK
+ << ARMADA_37XX_NB_CLK_SEL_OFF);
+
+- /* Set TBG index, for all levels we use the same TBG */
+- val = cpu_tbg_sel << ARMADA_37XX_NB_TBG_SEL_OFF;
+- mask = (ARMADA_37XX_NB_TBG_SEL_MASK
+- << ARMADA_37XX_NB_TBG_SEL_OFF);
+-
+ /*
+* Set cpu divider based on the pre-computed array in
+* order to have balanced step.
+@@ -176,6 +162,14 @@ static void __init armada37xx_cpufreq_dv
+
+ regmap_update_bits(base, reg, mask, val);
+ }
++
++ /*
++ * Set cpu clock source, for all the level we keep the same
++ * clock source that the one already configured. For this one
++ * we need to use the clock framework
++ */
++ parent = clk_get_parent(clk);
++ clk_set_parent(clk, parent);
+ }
+
+ /*
+@@ -401,16 +395,11 @@ static int __init armada37xx_cpufreq_dri
+ struct platform_device *pdev;
+ unsigned long freq;
+ unsigned int cur_frequency, base_frequency;
+- struct regmap *nb_clk_base, *nb_pm_base, *avs_base;
++ struct regmap *nb_pm_base, *avs_base;
+ struct device *cpu_dev;
+ int load_lvl, ret;
+ struct clk *clk, *parent;
+
+- nb_clk_base =
+-
syscon_regmap_lookup_by_compatible("marvell,armada-3700-periph-clock-nb");
+- if (IS_ERR(nb_clk_base))
+- return -ENODEV;
+-
+ nb_pm_base =
+ syscon_regmap_lookup_by_compatible("marvell,armada-3700-nb-pm");
+
+@@ -487,7 +476,7 @@ static int __init armada37xx_cpufreq_dri
+ armada37xx_cpufreq_avs_configure(avs_base, dvfs);
+ armada37xx_cpufreq_avs_setup(avs_base, dvfs);
+
+- armada37xx_cpufreq_dvfs_setup(nb_pm_base, nb_clk_base, dvfs->divider);
++ armada37xx_cpufreq_dvfs_setup(nb_pm_base, clk, dvfs
Re: [RFC] OpenWrt within a Docker container
On 5/17/21 11:09 PM, Fernando Frediani wrote: Hello Certainly run /sbin/init or 'procd' to have *OpenWrt-like experience* is a better approach in my view. So do you prefer to disable some services and make some init-scripts "container aware"? Regards Fernando On 17/05/2021 15:39, Paul Spooren wrote: Hello, after some back and forth I'd like to request some more opinions on what kind of Docker containers to offer containing the OpenWrt rootfs. This is not about the SDK or ImageBuilder Docker containers. tl;dr: Should we ship `slim` containers only, running a OpenWrt shell (ash) and nothing more? Whoever wants services to run (e.g. ubus) should run additional containers and glue them together via mounts? Or should we run /sbin/init or `procd` to have a *OpenWrt-like experience*, with LuCI, ubusd and friends. /tl;dr Currently the `openwrt/rootfs` container is shipped with minimal modifications and starts `/sbin/init` as default action. Running the container for e.g. LuCI development within a local shell results in the following output: ``` user@reactor:~$ docker run -it openwrt/rootfs Failed to resize receive buffer: Operation not permitted /etc/preinit: line 5: can't create /sys/devices/system/cpu/microcode/reload: Read-only file system ip: RTNETLINK answers: Operation not permitted Press the [f] key and hit [enter] to enter failsafe mode Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level ip: can't send flush request: Operation not permitted ip: SIOCSIFFLAGS: Operation not permitted Please press Enter to activate this console. --- %< --- root@da3dfbdc5ae4:/# ``` Some init scripts fail due to missing privileges. The console input is only possible by using a patched /etc/inittab file and multiple services keep failing, most problematic the `network` service since it tries and fails in a fast loop to flush some interfaces. A possible patch is available[1] which disables services obsolete within a Docker environment, however this would "flaw" the *OpenWrt-like experience*. Another, probably better approach could be to have *slim-containers* which only run `ash` and let the user start whatever is needed, e.g. `ubusd && uhttpd` and thereby have access to a LuCI interface to play with. This would follow the experience from other popular containers like `alpine` or `debian`. This would also allow us to become an "official" container, which would allow to be used as `docker run -it openwrt` rather than `docker run -it openwrt/rootfs`. Some efforts were made here[2]. I'd prefer the latter option; only offer SDK and ImageBuilder and let the rootfs become a "official" Docker container without any running services. Whoever needs services can use `FROM openwrt` within a Dockerfile and run whatever is needed. Best, Paul [1]: https://gitlab.com/openwrt/docker/-/merge_requests/47 [2]: https://github.com/docker-library/official-images/pull/7975 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] busybox: use $(AUTORELEASE) and SPDX
use AUTORELEASE since BusyBox is often updaten and PKG_RELEASE is not consistently bumped. Also use SPDX license headers to be machine readable and bump the copyright year to 2021. Signed-off-by: Paul Spooren --- I'd like to see this backported as well. package/utils/busybox/Makefile | 9 +++-- 1 file changed, 3 insertions(+), 6 deletions(-) diff --git a/package/utils/busybox/Makefile b/package/utils/busybox/Makefile index 76a910361e..242a2428ac 100644 --- a/package/utils/busybox/Makefile +++ b/package/utils/busybox/Makefile @@ -1,15 +1,12 @@ +# SPDX-License-Identifier: GPL-2.0-or-later # -# Copyright (C) 2006-2020 OpenWrt.org -# -# This is free software, licensed under the GNU General Public License v2. -# See /LICENSE for more information. -# +# Copyright (C) 2006-2021 OpenWrt.org include $(TOPDIR)/rules.mk PKG_NAME:=busybox PKG_VERSION:=1.33.1 -PKG_RELEASE:=1 +PKG_RELEASE:=$(AUTORELEASE) PKG_FLAGS:=essential PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.bz2 -- 2.30.2 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: Uniquely identifying a platform programmatically
On Mon, May 17, 2021 at 04:43:24PM -0600, Philip Prindeville wrote: > Hi, > > I was wondering what the best way to map a running box back to a candidate > image would be. > > It seems like the tuple ($CONFIG_TARGET_BOARD, $CONFIG_TARGET_SUBTARGET, > $CONFIG_TARGET_PROFILE) would provide this, since you can mangle them into a > bin/targets/$CONFIG_TARGET_BOARD/$CONFIG_TARGET_SUBTARGET/openwrt-*-$CONFIG_TARGET_BOARD-$CONFIG_TARGET_SUBTARGET-$CONFIG_TARGET_PROFILE-squashfs-sysupgrade.bin > (or -factory.bin) image for provisioning... > ... > > Any suggestions welcome. ubus call system board That's what is used also by `auc` and `luci-app-attendedsysupgrade`, it contains all information you need to know in order to decide which target/subtarget ImageBuilder to use and which profile (=board) to select. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH luci] luci-mod-network: use "ports" option for setting bridge ports
On 17.05.2021 14:10, Rafał Miłecki wrote:
From: Rafał Miłecki
netifd has been recently patched to use more accurate "ports" option
instead of "ifname"
Signed-off-by: Rafał Miłecki
---
.../htdocs/luci-static/resources/tools/network.js | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
a/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
b/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
index b4d941c60d..370617397b 100644
--- a/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
+++ b/modules/luci-mod-network/htdocs/luci-static/resources/tools/network.js
@@ -499,7 +499,7 @@ return baseclass.extend({
o.multiple = true;
o.noaliases = true;
o.nobridges = true;
- o.ucioption = 'ifname';
+ o.ucioption = 'ports';
o.write = o.remove = setIfActive;
o.default = L.toArray(dev ? dev.getPorts() :
null).filter(function(p) { return p.getType() != 'wifi' }).map(function(p) {
return p.getName() });
o.filter = function(section_id, device_name) {
@@ -509,7 +509,7 @@ return baseclass.extend({
/* only show wifi networks which are already present in "option ifname" */
if (choice_dev.getType() == 'wifi') {
- var ifnames = L.toArray(uci.get('network',
section_id, 'ifname'));
+ var ifnames = L.toArray(uci.get('network',
section_id, 'ports'));
for (var i = 0; i < ifnames.length; i++)
if (ifnames[i] == device_name)
Missed bit:
diff --git a/htdocs/luci-static/resources/tools/network.js
b/htdocs/luci-static/resources/tools/network.js
index b4d941c..64aa7b1 100644
--- a/htdocs/luci-static/resources/tools/network.js
+++ b/htdocs/luci-static/resources/tools/network.js
@@ -918,8 +918,8 @@ return baseclass.extend({
var seen_ports = {};
- L.toArray(uci.get('network', s.section,
'ifname')).forEach(function(ifname) {
- seen_ports[ifname] = true;
+ L.toArray(uci.get('network', s.section,
'ports')).forEach(function(port) {
+ seen_ports[port] = true;
});
uci.sections('network', 'bridge-vlan', function(bvs) {
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH netifd] interface: rename "ifname" attribute to "device"
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 --- > Op 17 mei 2021, om 17:47 heeft Rafał Miłecki het volgende > geschreven: > > On 17.05.2021 17:32, Paul Oranje wrote: >> Op 17 mei 2021, om 16:49 heeft Rafał Miłecki het volgende >> geschreven: >>> >>> From: Rafał Miłecki >>> >>> Interfaces need to be assigned to devices. For that purpose a "device" >>> option should be more accurate than "ifname" one. >>> >>> For backward compatibility add a temporary config translation. >>> >>> Config example: >>> >>> config device >>> option name 'lan' >>> option type 'bridge' >>> list ports 'lan1' >>> list ports 'lan2' >>> >>> config interface 'home' >>> option device 'lan' >>> option proto 'static' >> A bit off-topic: the disparency between config section names and an option >> named name is not always clear. > > What do you mean by "not always"? I think it should be consistent: > "interface" UCI section should always use "device" for referencing > "device" UCI section (by its "name"). Indeed. > As for "name" option in the "device" UCI section I thought we could make > it section name instead, but it can't be done due to UCI limitations for > section names: > > [2021-05-14] [16:59:17 CEST] jow: nbd: quick question - could we > have "config device " and drop "option name " ? i see two > advantages: > [2021-05-14] [16:59:21 CEST] 1. it would not allow duplicated names > [2021-05-14] [16:59:21 CEST] 2. referencing devices from "config > interface" would be more natural > [2021-05-14] [17:06:32 CEST] rmilecki: uci section names have > restrictions on what characters are allowed > [2021-05-14] [17:09:40 CEST] nbd: right, thanks > [2021-05-14] [17:10:15 CEST] ah yes, the babeld uci integration > used to do this (interface name in section name), but we had to drop it Ah, that explains. Your reasoning why using section names would be better stands. Assuming the uci limitation in this case concerns not having dashes in section names: Maybe, as long as uci has these restrictions on section naming and the dash cannot be used therein, one could still use an (allowed) device section name and use that for reference from interface sections and using an device option name to override (the name defaults to the section name), or, change how netifd names devices that it (implicitly) creates. Good luck with your endeavour. That proces itself helps understanding the currently implemented model. --- End Message --- ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
