Re: Build issues gcc10

2021-09-13 Thread Rui Salvaterra
Hi, Adrian,

On Mon, 13 Sept 2021 at 23:10, Adrian Schmutzler
 wrote:
>
> Just had one try before I went to bed, but it appears the problem is that 
> cc1plus generated by the toolchain has no execute bit set:

How in blazes…?

> /data/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-10.3.0_musl_eabi/gcc-10.3.0-final/./gcc/cc1plus
>
> If I chmod +x on that file, the build continues.

Talk about weirdness…! I'm glad you were able to sort it out, though.

Cheers,
Rui

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


RE: Build issues gcc10

2021-09-13 Thread Adrian Schmutzler
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Rui Salvaterra
> Sent: Sonntag, 12. September 2021 19:12
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: Build issues gcc10
> 
> Hi, Adrian,
> 
> On Sun, 12 Sept 2021 at 15:15, Adrian Schmutzler
>  wrote:
> >
> > I'm having build issues with master and (default) gcc10 on ipq targets.
> 
> I don't know about ipq, but I jumped straight to GCC 11.2. Does it make sense
> to bother with 10? That said…
> 
> > xgcc: fatal error: cannot execute 'cc1plus': execvp: No such file or
> > directory
> 
> … you seem to be missing the C++ compiler.

Just had one try before I went to bed, but it appears the problem is that 
cc1plus generated by the toolchain has no execute bit set:

/data/openwrt/build_dir/toolchain-arm_cortex-a15+neon-vfpv4_gcc-10.3.0_musl_eabi/gcc-10.3.0-final/./gcc/cc1plus

If I chmod +x on that file, the build continues.

Best

Adrian

> 
> Cheers,
> Rui
> 
> ___
> 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 v2] libtool: bump to 2.4.6

2021-09-13 Thread Eneas U de Queiroz
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 
---
Changelog:

Rebased after upgrade to 2.4.2

---
 tools/libtool/Makefile|  11 +-
 tools/libtool/patches/000-relocatable.patch   | 108 ++---
 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 ++-
 10 files changed, 444 insertions(+), 334 deletions(-)
 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 2bc9db7d0d..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.2
+PKG_VERSION:=2.4.6
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.xz
 PKG_SOURCE_URL:=@GNU/$(PKG_NAME)
-PKG_HASH:=1d7b6862c1ed162e327f083a6f78f40eae29218f0db8c38393d61dab764c4407
+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 6d1651be31..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
-@@ -334,15 +334,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}"}
- : ${Xsed="$SED -e 1s/^X//"}
- 
-@@ -2487,10 +2494,17 @@ func_check_macros ()
 

RE: Build issues gcc10

2021-09-13 Thread Adrian Schmutzler
Hi,

> -Original Message-
> From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
> On Behalf Of Stefan Lippers-Hollmann
> Sent: Montag, 13. September 2021 00:30
> To: Adrian Schmutzler 
> Cc: openwrt-devel@lists.openwrt.org
> Subject: Re: Build issues gcc10
> 
> Hi
> 
> On 2021-09-12, Adrian Schmutzler wrote:
> > Hi,
> >
> > I'm having build issues with master and (default) gcc10 on ipq targets.
> 
> Just for reference, I've just (successfully) tried an ipq806x build on a
long-
> standing, but fully updated, Debian/ unstable host, using gcc-10 on the
host

I was not able to get it working. I tried various additional packages, but
no luck.

Could you export a list of installed packages on your (working) machine?

Best

Adrian

> 
>   $ gcc --version
>   gcc (Debian 10.3.0-10) 10.3.0
>   Copyright (C) 2020 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There
is
> NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A
> PARTICULAR PURPOSE.
> 
> and for the OpenWrt build
> 
>   $ grep CONFIG_GCC_VERSION .config
>   CONFIG_GCC_VERSION="10.3.0"
> 
> $ git describe
> reboot-17502-g0470159552
> 
> Rather minimal build-config (no feeds installed), roughly matching the
> buildbot configs (just omitting the imagebuilder):
> 
> $ ./scripts/diffconfig.sh
> CONFIG_TARGET_ipq806x=y
> CONFIG_TARGET_ipq806x_generic=y
> CONFIG_TARGET_MULTI_PROFILE=y
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_askey_rt4230w-rev6=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_askey_rt42
> 30w-rev6=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_asrock_g10=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_asrock_g10
> =""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_buffalo_wxr-
> 2533dhp=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_buffalo_wx
> r-2533dhp=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_compex_wpq864=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_compex_w
> pq864=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_edgecore_ecw5410=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_edgecore_
> ecw5410=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_linksys_ea7500-v1=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_linksys_ea7
> 500-v1=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_linksys_ea8500=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_linksys_ea8
> 500=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_nec_wg2600hp=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_nec_wg260
> 0hp=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_nec_wg2600hp3=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_nec_wg260
> 0hp3=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_netgear_d7800=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_netgear_d7
> 800=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_netgear_r7500=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_netgear_r7
> 500=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_netgear_r7500v2=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_netgear_r7
> 500v2=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_netgear_r7800=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_netgear_r7
> 800=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_qcom_ipq8064-ap148-
> legacy=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_qcom_ipq8
> 064-ap148-legacy=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_qcom_ipq8064-ap148=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_qcom_ipq8
> 064-ap148=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_qcom_ipq8064-ap161=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_qcom_ipq8
> 064-ap161=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_qcom_ipq8064-
> db149=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_qcom_ipq8
> 064-db149=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_tplink_ad7200=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_tplink_ad72
> 00=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_tplink_c2600=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_tplink_c260
> 0=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_tplink_vr2600v=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_tplink_vr26
> 00v=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_ubnt_unifi-ac-hd=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_ubnt_unifi-
> ac-hd=""
> CONFIG_TARGET_DEVICE_ipq806x_generic_DEVICE_zyxel_nbg6817=y
> CONFIG_TARGET_DEVICE_PACKAGES_ipq806x_generic_DEVICE_zyxel_nbg6
> 817=""
> CONFIG_ALL_KMODS=y
> CONFIG_ALL_NONSHARED=y
> CONFIG_DEVEL=y
> CONFIG_TARGET_PER_DEVICE_ROOTFS=y
> CONFIG_TARGET_ALL_PROFILES=y
> 
> $ ls -gG bin/targets/ipq806x/generic/
> insgesamt 442620
> -rw-r--r-- 1 3160 13. Sep 00:11 config.buildinfo
> -rw-r--r-- 1  231 13. Sep 00:11 feeds.buildinfo
> -rw-r--r-- 1  5892899 13. Sep 00:17 openwrt-ipq806x-generic-askey_rt4230w-
> rev6-initramfs-uImage
> -rw-r--r-- 1 

Re: [PATCH 0/2] Bump WolfSSL and libtool

2021-09-13 Thread Hauke Mehrtens

On 7/22/21 9:44 PM, Eneas U de Queiroz wrote:

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.0-stable



Hi Eneas U de Queiroz,

libtool was updated to version 2.4.2 in this commmit:
https:/git.openwrt.org/cdc646c03282b91d7e9518bb726f29c1de5d24fc
The wolfssl update was applied here:
https://git.openwrt.org/7d92bb0509615550b98e2dc71091073c8258d564

I would also like to get libtool to 2.4.6 in master, could you please 
rebase your patch on top of current master please.


@Jow: Do you have any objections to updating libtool in master to 
version 2.4.6?


I would prefer to patch wolfssl in 21.02 to work with older libtool.

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


Re: Help with WiFi Streaming (ie noack) mode.

2021-09-13 Thread Ben Greear

On 9/11/21 5:08 PM, Nick Dennis wrote:

("WiFi Streaming" is just a more descriptive name for the desired wifi 
behaviour.
The wifi keeps streaming packets without waiting for ACKS/Block ACKs.)

I'm working with ath10k-ct, the boot announceent shows:

[   17.250943] ath10k_pci :00:00.0: qca988x hw2.0 target 0x4100016c chip_id 
0x043222ff sub :
[   17.260370] ath10k_pci :00:00.0: kconfig debug 0 debugfs 1 tracing 0 dfs 
1 testmode 0
[   23.753344] ath10k_pci :00:00.0: firmware ver 10.1-ct-8x-__fH-022-ecad3248 api 2 features 
wmi-10.x,mfp,txstatus-noack,wmi-10.x-CT,ratemask-CT,txrate-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT crc32 
1b2a161c


In noack mode, rate control algorithms won't know whether a packet transmission 
was successful or not, so a fixed rate has to be set, normally with only 1 try.

So far, I've patched mac80211 and ath10k-ct so that

root@Openwrt:/#iw dev wlan0 set bitrates ht-mcs-5 vht-mcs-5 1:9 2:9 sgi-5

sets a single rate bit in the ath10k_vif bitrate_mask.control[ band ].vht_mcs[ 
0 ]
and

root@Openwrt:/#iw wlan0 set noack_map 0x00ff

sets the ieee80211_tx_info flag IEEE80211_TX_CTL_NO_ACK for data packets.

Also needed a patch to ath10k function ath10k_htt_tx_32 for the fixed rate to 
show in the gui association list
- detect info->flags & IEEE80211_TX_CTL_NO_ACK and
- set the variables pream_type, nss, mcs and num_retries from ath10k_vif
- which then set up txbuf->cmd_tx.peerid.

While running iperf across a link:
- setting the fixed rate causes the throughput to change accordingly
- but setting the noack_map causes
-- the rate shown on the gui to drop from 400 to 173 Mbps
-- packets stop being aggregated.
so the throughput drops from about 200 Mbps to about 80 Mbps

What am i missing?


Not sure, but maybe try leaving rate-control and rest of the stack alone.  
Instead use ath10k 'set_rate_overrides'
debugfs to set rate as you wish and disable retries?

Thanks,
Ben




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel



--
Ben Greear 
Candela Technologies Inc  http://www.candelatech.com

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel


[PATCH] arm-trusted-firmware-mvebu: CZ.NIC's Secure Firmware bump to v2021.09.07

2021-09-13 Thread sean lee

bump version and remove patches that have been applied

176d701 wtmi: Wait 1s after putting PHYs INTn pin low
2eeccfe wtmi: Change comment describing reset workaround
e8c94a5 wtmi: Count RAM size from both CS0 and CS1
995979e wtmi: Rename macro
e29eb29 wtmi: soc: Fix start_ap_workaround() for TF-A with debug
81245ed wtmi: Use constant name PLAT_MARVELL_MAILBOX_BASE
18ccb83 wtmi: Do a proper UART reset with clock change as described in spec
15ff106 avs: Validate VDD value from OTP
3f33626 fix: clock: a3700: change pwm clock for 600/600 and 1200/750 preset
fb5e436 wtmi: uart: fix UART baudrate divisor calculation

Signed-off-by: sean lee 
---
 .../boot/arm-trusted-firmware-mvebu/Makefile  |  4 +-
 ...ix-UART-baudrate-divisor-calculation.patch | 66 ---
 ...change-pwm-clock-for-600-600-and-120.patch | 48 --
 .../102-avs-Validate-VDD-value-from-OTP.patch | 52 ---
 4 files changed, 2 insertions(+), 168 deletions(-)
 delete mode 100644 
package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/100-wtmi-uart-fix-UART-baudrate-divisor-calculation.patch
 delete mode 100644 
package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/101-fix-clock-a3700-change-pwm-clock-for-600-600-and-120.patch
 delete mode 100644 
package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/102-avs-Validate-VDD-value-from-OTP.patch


diff --git a/package/boot/arm-trusted-firmware-mvebu/Makefile 
b/package/boot/arm-trusted-firmware-mvebu/Makefile

index 2369a193..8836388b 100644
--- a/package/boot/arm-trusted-firmware-mvebu/Makefile
+++ b/package/boot/arm-trusted-firmware-mvebu/Makefile
@@ -149,13 +149,13 @@ define Download/mv-ddr-marvell
 endef

 MOX_BB_NAME:=mox-boot-builder
-MOX_BB_RELEASE:=v2021.04.09
+MOX_BB_RELEASE:=v2021.09.07
 MOX_BB_SOURCE:=$(MOX_BB_NAME)-$(MOX_BB_RELEASE).tar.bz2

 define Download/mox-boot-builder
   FILE:=$(MOX_BB_SOURCE)

URL:=https://gitlab.nic.cz/turris/mox-boot-builder/-/archive/$(MOX_BB_RELEASE)
-  HASH:=f0ed4fa25006e36a07d4256f633e3f25d6f8898dbe2e081e578251a182885520
+  HASH:=fd5fe276a3b0dee3177d61c017907a8eb23cd2169478fa78e9a3a836cfe3a4a8
 endef

 CM3_GCC_NAME:=gcc-arm
diff --git 
a/package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/100-wtmi-uart-fix-UART-baudrate-divisor-calculation.patch 
b/package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/100-wtmi-uart-fix-UART-baudrate-divisor-calculation.patch

deleted file mode 100644
index 4bd66f91..
--- 
a/package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/100-wtmi-uart-fix-UART-baudrate-divisor-calculation.patch

+++ /dev/null
@@ -1,66 +0,0 @@
-From fb5e436843614f93b30aec0a2a00e5e59a133aab Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Marek=20Beh=C3=BAn?= 
-Date: Sat, 15 May 2021 17:44:24 +0200
-Subject: [PATCH] wtmi: uart: fix UART baudrate divisor calculation
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-The UART code uses the xtal clock as parent for UART baudrate
-generation, but it assumes that xtal runs at 25 MHz, which isn't
-necessarily the case for all A3720 boards.
-
-Use get_ref_clk() to determine xtal clock rate.
-
-Use rounding division to compute the divisor value.
-
-Signed-off-by: Marek Behún 
-Suggested-by: Pali Rohár 

- wtmi/types.h | 5 +
- wtmi/uart.c  | 7 ---
- 2 files changed, 9 insertions(+), 3 deletions(-)
-
-diff --git a/wtmi/types.h b/wtmi/types.h
-index 7a6c6c6..ea873fc 100644
 a/wtmi/types.h
-+++ b/wtmi/types.h
-@@ -47,4 +47,9 @@ typedef u32  size_t;
-
- #define maybe_unused __attribute__((unused))
-
-+static inline u32 div_round_closest_u32(u32 x, u32 d)
-+{
-+  return (x + d / 2) / d;
-+}
-+
- #endif /* __TYPES_H */
-diff --git a/wtmi/uart.c b/wtmi/uart.c
-index d40633d..75864b5 100644
 a/wtmi/uart.c
-+++ b/wtmi/uart.c
-@@ -40,8 +40,6 @@
- #include "stdio.h"
- #include "debug.h"
-
--#define UART_CLOCK_FREQ   25804800
--
- const struct uart_info uart1_info = {
-   .rx = 0xc0012000,
-   .tx = 0xc0012004,
-@@ -76,8 +74,11 @@ void uart_set_stdio(const struct uart_info *info)
-
- void uart_reset(const struct uart_info *info, unsigned int baudrate)
- {
-+  u32 parent_rate = get_ref_clk() * 100;
-+
-   /* set baudrate */
--  writel((UART_CLOCK_FREQ / baudrate / 16), info->baud);
-+  writel(div_round_closest_u32(parent_rate, baudrate * 16), info->baud);
-+
- 	/* set Programmable Oversampling Stack to 0, UART defaults to 16X 
scheme */

-   writel(0, info->possr);
-
---
-2.30.2
-
diff --git 
a/package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/101-fix-clock-a3700-change-pwm-clock-for-600-600-and-120.patch 
b/package/boot/arm-trusted-firmware-mvebu/patches-mox-boot-builder/101-fix-clock-a3700-change-pwm-clock-for-600-600-and-120.patch

deleted file mode 100644
index 6d74a053..
--- 

[PATCH] ipq40xx: add support for GL.iNet GL-B2200

2021-09-13 Thread Li Zhang
This patch adds supports for GL-B2200.

Specifications:
- SOC: Qualcomm IPQ4019 ARM Quad-Core
- RAM: 512 MiB
- Flash: 16 MiB NOR - SPI0
- EMMC: 8GB EMMC
- ETH: Qualcomm QCA8075
- WLAN1: Qualcomm Atheros QCA4019 2.4GHz 802.11b/g/n 2x2
- WLAN2: Qualcomm Atheros QCA4019 5GHz 802.11n/ac W2 2x2
- WLAN3: Qualcomm Atheros QCA9886 5GHz 802.11n/ac W2 2x2
- INPUT: Reset, WPS
- LED: Power, Internet
- UART1: On board pin header near to LED (3.3V, TX, RX, GND), 3.3V 
without pin - 115200 8N1
- UART2: On board with BLE module
- SPI1: On board socket for Zigbee module

Update firmware instructions

Pleae update firmware on uboot web(default 192.168.1.1).

Signed-off-by: Li Zhang 
---
 package/firmware/ipq-wifi/Makefile |   2 +
 .../ipq-wifi/board-glinet_gl-b2200.qca4019 | Bin 0 -> 24308 bytes
 .../ipq-wifi/board-glinet_gl-b2200.qca9888 | Bin 0 -> 12200 bytes
 target/linux/ipq40xx/Makefile  |   2 +-
 .../ipq40xx/base-files/etc/board.d/02_network  |   5 +
 .../etc/hotplug.d/firmware/11-ath10k-caldata   |   3 +
 .../arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts| 364 +
 target/linux/ipq40xx/image/generic.mk  |  27 ++
 .../patches-5.4/901-arm-boot-add-dts-files.patch   |   3 +-
 9 files changed, 404 insertions(+), 2 deletions(-)
 create mode 100644 package/firmware/ipq-wifi/board-glinet_gl-b2200.qca4019
 create mode 100644 package/firmware/ipq-wifi/board-glinet_gl-b2200.qca9888
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4019-gl-b2200.dts

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index e3b25bb..c7a388e 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -39,6 +39,7 @@ ALLWIFIBOARDS:= \
engenius_emr3500 \
ezviz_cs-w3-wd1200g-eup \
glinet_gl-ap1300 \
+   glinet_gl-b2200 \
glinet_gl-s1300 \
linksys_ea8300 \
linksys_mr8300-v0 \
@@ -124,6 +125,7 @@ $(eval $(call 
generate-ipq-wifi-package,engenius_emd1,EnGenius EMD1))
 $(eval $(call generate-ipq-wifi-package,engenius_emr3500,EnGenius EMR3500))
 $(eval $(call generate-ipq-wifi-package,ezviz_cs-w3-wd1200g-eup,EZVIZ 
CS-W3-WD1200G EUP))
 $(eval $(call generate-ipq-wifi-package,glinet_gl-ap1300,GL.iNet GL-AP1300))
+$(eval $(call generate-ipq-wifi-package,glinet_gl-b2200,GL.iNet GL-B2200))
 $(eval $(call generate-ipq-wifi-package,glinet_gl-s1300,GL.iNet GL-S1300))
 $(eval $(call generate-ipq-wifi-package,linksys_ea8300,Linksys EA8300))
 $(eval $(call generate-ipq-wifi-package,linksys_mr8300-v0,Linksys MR8300))
diff --git a/package/firmware/ipq-wifi/board-glinet_gl-b2200.qca4019 
b/package/firmware/ipq-wifi/board-glinet_gl-b2200.qca4019
new file mode 100644
index 
..ac1850160aead29cee0fb96664272b8a620a4e6a
GIT binary patch
literal 24308
zcmeHPdr(tX8b1jj>SE!BfCzXAAv{7MK%g2V@)iT6U{R3(i$E30tx+C^hoKAYC{l=s
zKrI*|Xc?48Q$)ta7qM7dJEP40v48CBA8ltJ-I;aQcCLna&8
z!7IvLW4{*NNZ>gXcuZf@TlE@SlXXWzx%bckIO$*H5j;jxpDANrJ>r>8pthc<;p4LO
zFWA5$8ub~IVOWb{+S}XP+1c3`2mp8RnOZ0=(9STq!n$Fyu$yT!M<~;kWv-Mo58=y3
zFS92zKBQ`@KA4@FEEvD0YO9uI?@5jyA5fiYER(*Kyk?5{LMj?5?%CBs)V8s(0|89p6i8)lgnyGW#&)FdGlkwUvO9>6tCB*50Oq%E*KM
znVzW=ZDqAdGTwfd_^zx%G~lh2Xi_jPqE6K3;G%hEf#BgWOCc@)op9#CSQ*(U<$A9iqn9D?N
zd{WUJQtMUXoWHzKqM{`cu(MzHs|}8bv&+U!9-GMze1j7IjD3;7e&7WWp3&)a8lKzO
zz^~;sda=J!mlf*v;N4w(l*93Xf4*#QZy*65mq42dci5rM3%j5Ide3y$#9
zPfx#}n!>Mu1YBPqUE6=Y|KoRtZMflP2Yb4$?SG-2BRpX<{?DF0d91Tt#BhnOONQX}
z2-Heyn}_g(HwNk@0E!<6m!+u@6EMmU6hY$9I3x@WLrUbwYfpU8+}1Hy0Ybgpwn|~3
z3?Abl193;)dG2B-)CqAzLJ7AJ5MqAYB8xAy;bH_T?yBu)Eq2X0u)LVN@ftCmWCN%
zW;L%$lx877RVV}~1SkY31SkY31XeKu8~Ga%FUC&(P9@5|n9X@vQ|*#8Nv;`dUIZ;@o28=pz7NS*7e5
zePmn)2Et#z;m_Y}7NxC343^MRG#N@PK!Edi+=NctJK02U4NfFyUnjBMh+F
zo}O$YX@~7|TiNW~HVzO9XyC`A0JPg9wAcs$0@flx2!yuzYY;$pp|8({rIQn}>1Z-0
zs?@O;>TNv9uxI}mVpnQpuGBPbW4kh2?uGM_ea7W{DS8U4y!>F?*u`6ZKX=T5g*
zr`w$q@7j}fu3VRmH6Zpu#f%1WCzRL&
z6~{M_yP(AWr%#T-SbSPG4E5%*=*4
z#Y8+@}IPk=i8%*p@)w5ZokIH#4&2*3$4z^6d==!vB}SKo)@K
z(Io=92ejOc4le(mMx=UJ
z)_+R_RUA4P7@~v0AL!uGm<@O$v;~fLY(dO+JAk;@*x4^k2vjc=0u%zP4uKiIyeYo@
zzyJQ1Z@>BG4-gd{2OsC#KmX_7{`C0qUtya$zP(Tw5vt?sPfh*nhlS_ho8sFC=>@0V
z{%PC%wZYteIj?HY3Jaebb2
zdtY%@@$8!mqnfGri(%W>BieR#g(6cD^7Rd^N?oJKlL)le)#ntYk|cqzc0|*wRA3T;
zC;mTTx9|D~0O-)BmMiv3c$34Lv?+Bux;c{jIuHA(O-lSh
zm|==cMdsv9O_x%R?UroS+*F>!%0!6*K6GeP93~ycC;Yi!^0wxJvI6$|hIUx#$=*6LCEAS%_U_uwol-$bKv^n
zb7)l`R~9MK;K2*ZDr}b|1P0QnkV{ep+{x>j^U5+TUBtm1KAYe|l&)zz)#b`OMdIWb
zJXo#Zq9H7a^9h0u_RueK-eeWC>pCQz2P$0x6Uzl*}No5|)OUsZq_V
z7J-hDBbQ^^gBv_5E^2p5CtTIkZu7apc(L__mM+
z5BbP<>%Z|hdZs6{IqWzKb4>f9|8Q$;ov&v5ZvHi@mj%>gwViXUCGcs6ZW0I4wZZ)#3f}jUx#aa}
zq}_>USaKx4f3RFFJjpI~l8knjH7C>r$y_rYe45e}RK2OlXLaF;Yqsv+6CLIpF0Lgw_mqlW0-)SYN8M@iNGAX{WBvoOUWJ!ZD$n5
zYOB7CZ%;g92LFwkO=%Pc|NnJB^6dQ}i>4P+hd2%}K^9CbIDB>~+0r
mM)B=m6*pJ+8D3jzj85S3pID+VNxf)UhC)x=qn

netifd brings up interfaces set admin-down with "ip link set $I down"

2021-09-13 Thread B



netifd will immediately and automatically set an interface active/up 
which has been administratively disabled with either the "ip link set $I 
down" or "ifconfig $I down" commands.


Below is an example log after "ip link set eth0.1 down" is used against 
the "lan" configuration/policy. Note that identical behavior is observed 
on a typical ethernet interface (eth0) where there is no intermediate 
switch or VLAN sub interfaces involved.


Sat Sep 11 00:39:59 2021 daemon.notice netifd: VLAN 'eth0.1' link is down
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' has link 
connectivity loss
Sat Sep 11 00:39:59 2021 kern.info kernel: [48844.417075] device eth0 
left promiscuous mode
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (28106): udhcpc: 
received SIGTERM

Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' is now down
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' is disabled
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' is enabled
Sat Sep 11 00:39:59 2021 daemon.notice netifd: VLAN 'eth0.1' link is up
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' has link 
connectivity
Sat Sep 11 00:39:59 2021 daemon.notice netifd: Interface 'lan' is 
setting up now
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (29997): udhcpc: 
started, v1.30.1
Sat Sep 11 00:39:59 2021 kern.info kernel: [48845.042493] device eth0 
entered promiscuous mode
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (29997): udhcpc: 
sending discover
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (29997): udhcpc: 
sending select for 192.168.0.148
Sat Sep 11 00:39:59 2021 daemon.notice netifd: lan (29997): udhcpc: 
lease of 192.168.0.148 obtained, lease time 43200

Sat Sep 11 00:40:00 2021 daemon.notice netifd: Interface 'lan' is now up
Sat Sep 11 00:40:01 2021 user.notice firewall: Reloading firewall due to 
ifup of lan (eth0.1)




Before I go into filing bugs or making a case for why this is a problem, 
I should ask: Is this behavior intentional?




___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel