expat update broke build on ubuntu 22.04 server

[Koen Vandeputte]

Hi Nick,

Regarding commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4a3f430d726e0713f4936844f26ccaf5077ef881


I'm seeing this when building:
Any idea how to fix it?



checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -std=c++11... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with +std=c++11... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -h std=c++11... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -std:c++11... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -std=c++0x... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with +std=c++0x... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -h std=c++0x... no
checking whether ccache
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/bin/g++
supports C++11 features with -std:c++0x... no
configure: error: *** A compiler with support for C++11 language
features is required.
make[3]: *** [Makefile:34:
/home/koen/firmware/builds/generic_dr40x9/build_dir/host/expat-2.6.0/.configured]
Error 1
make[3]: Leaving directory
'/home/koen/firmware/builds/generic_dr40x9/tools/expat'
time: tools/expat/compile#0.94#0.25#1.17
ERROR: tools/expat failed to build.
make[2]: *** [tools/Makefile:228: tools/expat/compile] Error 1
make[2]: Leaving directory '/home/koen/firmware/builds/generic_dr40x9'
make[1]: *** [tools/Makefile:224:
/home/koen/firmware/builds/generic_dr40x9/staging_dir/host/stamp/.tools_compile_nyyynyynnnnynyyynyyynnynyynnynnyynyyynynnyyy]
Error 2
make[1]: Leaving directory '/home/koen/firmware/builds/generic_dr40x9'
make: *** [/home/koen/firmware/builds/generic_dr40x9/include/toplevel.mk:232:
world] Error 2


koen@roemer:~/firmware/builds/generic_dr40x9$ uname -a
Linux roemer 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux


koen@roemer:~/firmware/builds/generic_dr40x9$ gcc --version
gcc (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0
Copyright (C) 2021 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.


Koen

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

Re: [VOTE] New member proposal: Robimarko (Robert Marko)

[Koen Vandeputte]

On Tue, Jan 30, 2024 at 7:16 PM Christian Marangi (Ansuel)
 wrote:
>
> Robert is active in OpenWrt since 2017 and with some recent stats, he
> has more than 310 commits merged in OpenWrt.
> He also have uncounted Reviewed-by tag on various PR and merged commits
> and generally helps in everything related to IPQ (ipq806x, ipq40xx and
> ipq807x) and some mvebu targets.
>
> He did the conversion of ipq40xx target to DSA and made possible the
> introduction of the ipq807x target by sorting all the QSDK downstream
> patch and pushing them upstream.
>
> With his help, also the ipq60xx is very close on getting merged and
> actually used permitting support of even more device for OpenWrt.
>
> Also he is almost always reachable on IRC openwrt-devel and never had
> a problem in coordinating and collaborating with him.
>
> I think Robert is a good addition to our team and would massively help
> me (Ansuel) in maintaining each IPQ target and review all the related
> PR on github and patchwork.
> I would like to add Robert to the OpenWrt committers team.
>
> The vote shall be concluded within 14 days. (13/02/2024)
>
> ___
> openwrt-adm mailing list
> openwrt-...@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-adm

+1

It's always a pleasure to interact with Robert.
Very professional.

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

[PATCH] libnl: add support for cli

[Koen Vandeputte]

Some packages (like wavemon >= 0.9.4) depend on libnl-cli

Add support for this part of the lib.
libnl-cli itself depends on libnl-genl and libnl-nf
On MIPS, this component adds 81kB

Signed-off-by: Koen Vandeputte 
---
 package/libs/libnl/Makefile | 19 ++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/package/libs/libnl/Makefile b/package/libs/libnl/Makefile
index 56549dcc0a..f8c7437668 100644
--- a/package/libs/libnl/Makefile
+++ b/package/libs/libnl/Makefile
@@ -55,10 +55,16 @@ $(call Package/libnl/default)
   DEPENDS:=+libnl-route
 endef
 
+define Package/libnl-cli
+$(call Package/libnl/default)
+  TITLE:=CLI Netlink Library
+  DEPENDS:=+libnl-genl +libnl-nf
+endef
+
 define Package/libnl
 $(call Package/libnl/default)
   TITLE:=Full Netlink Library
-  DEPENDS:=+libnl-genl +libnl-route +libnl-nf
+  DEPENDS:=+libnl-genl +libnl-route +libnl-nf +libnl-cli
 endef
 
 define Package/libnl-core/description
@@ -77,6 +83,10 @@ define Package/libnl-nf/description
  Netfilter Netlink Library Functions
 endef
 
+define Package/libnl-cli/description
+ CLI Netlink Library Functions
+endef
+
 define Package/libnl/description
  Socket handling, connection management, sending and receiving of data,
  message construction and parsing, object caching system, etc.
@@ -98,6 +108,7 @@ define Build/InstallDev
$(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-genl-3.so 
$(1)/usr/lib/libnl-genl.so
$(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so $(1)/usr/lib/libnl-nf.so
$(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-route-3.so 
$(1)/usr/lib/libnl-route.so
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-cli-3.so 
$(1)/usr/lib/libnl-cli.so
 endef
 
 define Package/libnl-core/install
@@ -120,6 +131,11 @@ define Package/libnl-nf/install
$(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-nf-3.so.* $(1)/usr/lib/
 endef
 
+define Package/libnl-cli/install
+   $(INSTALL_DIR) $(1)/usr/lib
+   $(CP) $(PKG_INSTALL_DIR)/usr/lib/libnl-cli-3.so.* $(1)/usr/lib/
+endef
+
 define Package/libnl/install
:
 endef
@@ -128,4 +144,5 @@ $(eval $(call BuildPackage,libnl-core))
 $(eval $(call BuildPackage,libnl-genl))
 $(eval $(call BuildPackage,libnl-route))
 $(eval $(call BuildPackage,libnl-nf))
+$(eval $(call BuildPackage,libnl-cli))
 $(eval $(call BuildPackage,libnl))
-- 
2.34.1


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

typo in module config

[Koen Vandeputte]

Hi Yousong,

By reading some mk files I noticed your commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=4f443c885dede3331b969e6265a41a0ff1e3059a

within netfilter.mk:

+define KernelPackage/nf-socket
..
+  KCONFIG:= $(KCOFNIG_NF_SOCKET)

+define KernelPackage/nf-tproxy
..
+  KCONFIG:= $(KCOFNIG_NF_TPROXY)


Looks like it contains 2 typos? :) --> KCOFNIG

Koen

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

Re: [PATCH] base-files: fix nand_upgrade_ubinized()

[Koen Vandeputte]

On Tue, Apr 11, 2023 at 10:33 AM Koen Vandeputte
 wrote:
>
> On Tue, Apr 11, 2023 at 1:36 AM Lanchon  wrote:
> >
> >
> >
> > On 4/10/23 15:38, Daniel Golle wrote:
> > > On Mon, Apr 10, 2023 at 07:01:35PM +0200, Rafał Miłecki wrote:
> > >> From: Rafał Miłecki 
> > >>
> > >> When using "ubiformat" with stdin it requires passing image size using
> > >> the -S argument. Provide it just like we do for "ubiupdatevol".
> > >>
> > >> This fixes:
> > >> ubiformat: error!: must use '-S' with non-zero value when reading from 
> > >> stdin
> > >>
> > >> This change fixes sysupgrade for bcm53xx and bcm4908 NAND devices
> > >> possibly some other targets too.
> > >>
> > >> Cc: Rodrigo Balerdi 
> > >> Cc: Daniel Golle 
> > >> Fixes: 971071212052 ("base-files: accept gzipped nand sysupgrade images")
> > >> Signed-off-by: Rafał Miłecki 
> > > Acked-by: Daniel Golle 
> > >
> > > Please apply asap.
> >
> > (Dan, do you want me to PR?)
> >
> > hi Rafa, thanks!
> >
> > i wonder how it is possible that the code as is worked for me; i tested
> > many times with compressed ubinized image.
> >
> >
> > >
> > >> ---
> > >>   package/base-files/files/lib/upgrade/nand.sh | 4 +++-
> > >>   1 file changed, 3 insertions(+), 1 deletion(-)
> > >>
> > >> diff --git a/package/base-files/files/lib/upgrade/nand.sh 
> > >> b/package/base-files/files/lib/upgrade/nand.sh
> > >> index 907945b349..fa29d575a8 100644
> > >> --- a/package/base-files/files/lib/upgrade/nand.sh
> > >> +++ b/package/base-files/files/lib/upgrade/nand.sh
> > >> @@ -261,10 +261,12 @@ nand_upgrade_ubinized() {
> > >>  local ubi_file="$1"
> > >>  local gz="$2"
> > >>
> > >> +local ubi_length=$( (${gz}cat "$ubi_file" | wc -c) 2> /dev/null)
> > >> +
> > >>  nand_detach_ubi "$CI_UBIPART" || return 1
> > >>
> > >>  local mtdnum="$( find_mtd_index "$CI_UBIPART" )"
> > >> -${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && 
> > >> ubiattach -m "$mtdnum"
> > >> +${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -S "$ubi_length" 
> > >> -y -f - && ubiattach -m "$mtdnum"
> > >>   }
> > >>
> > >>   # Write the UBIFS image to UBI rootfs volume
> > >> --
> > >> 2.34.1
> > >>
>
> I wonder if this also fixes the sysupgrade issues I reported on imx6 ..
> Will test today

Yep .. it also fixes the upgrade issue on imx6 boards.
Thanks!

Tested-by: Koen Vandeputte 

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

Re: [PATCH] base-files: fix nand_upgrade_ubinized()

[Koen Vandeputte]

On Tue, Apr 11, 2023 at 1:36 AM Lanchon  wrote:
>
>
>
> On 4/10/23 15:38, Daniel Golle wrote:
> > On Mon, Apr 10, 2023 at 07:01:35PM +0200, Rafał Miłecki wrote:
> >> From: Rafał Miłecki 
> >>
> >> When using "ubiformat" with stdin it requires passing image size using
> >> the -S argument. Provide it just like we do for "ubiupdatevol".
> >>
> >> This fixes:
> >> ubiformat: error!: must use '-S' with non-zero value when reading from 
> >> stdin
> >>
> >> This change fixes sysupgrade for bcm53xx and bcm4908 NAND devices
> >> possibly some other targets too.
> >>
> >> Cc: Rodrigo Balerdi 
> >> Cc: Daniel Golle 
> >> Fixes: 971071212052 ("base-files: accept gzipped nand sysupgrade images")
> >> Signed-off-by: Rafał Miłecki 
> > Acked-by: Daniel Golle 
> >
> > Please apply asap.
>
> (Dan, do you want me to PR?)
>
> hi Rafa, thanks!
>
> i wonder how it is possible that the code as is worked for me; i tested
> many times with compressed ubinized image.
>
>
> >
> >> ---
> >>   package/base-files/files/lib/upgrade/nand.sh | 4 +++-
> >>   1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/package/base-files/files/lib/upgrade/nand.sh 
> >> b/package/base-files/files/lib/upgrade/nand.sh
> >> index 907945b349..fa29d575a8 100644
> >> --- a/package/base-files/files/lib/upgrade/nand.sh
> >> +++ b/package/base-files/files/lib/upgrade/nand.sh
> >> @@ -261,10 +261,12 @@ nand_upgrade_ubinized() {
> >>  local ubi_file="$1"
> >>  local gz="$2"
> >>
> >> +local ubi_length=$( (${gz}cat "$ubi_file" | wc -c) 2> /dev/null)
> >> +
> >>  nand_detach_ubi "$CI_UBIPART" || return 1
> >>
> >>  local mtdnum="$( find_mtd_index "$CI_UBIPART" )"
> >> -${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && 
> >> ubiattach -m "$mtdnum"
> >> +${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -S "$ubi_length" 
> >> -y -f - && ubiattach -m "$mtdnum"
> >>   }
> >>
> >>   # Write the UBIFS image to UBI rootfs volume
> >> --
> >> 2.34.1
> >>

I wonder if this also fixes the sysupgrade issues I reported on imx6 ..
Will test today

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

[PATCH v3 2/2] ipq40xx: add support for Wallystech DR40x9

[Koen Vandeputte]

From: Robert Marko 

Adds support for the Wallys DR40x9 series boards.
They come in IPQ4019 and IPQ4029 versions.
IPQ4019/4029 only differ in that that IPQ4029 is the industrial version that is 
rated to higher temperatures.

Specifications are:
* CPU: Qualcomm IPQ40x9 (4x ARMv7A Cortex A7) at 716 MHz
* RAM: 512 MB
* Storage: 2MB of SPI-NOR, 128 MB of parallel NAND
* USB 3.0 TypeA port for users
* MiniPCI-E with PCI-E 2.0 link
* MiniPCI-E for LTE modems with only USB2.0 link
* 2 SIM card slots that are selected via GPIO11
* MicroSD card slot
* Ethernet: 2x GBe with 24~48V passive POE
* SFP port (Does not work, I2C and GPIO's not connected on hardware)
* DC Jack
* UART header
* WLAN: In-SoC 2x2 802.11b/g/n and 2x2 802.11a/n/ac
* 4x MMCX connectors for WLAN
* Reset button
* 8x LED-s

Installation instructions:
Connect to UART, pins are like this:
-> 3.3V | TX | RX | GND

Settings are 115200 8n1

Boot initramfs from TFTP:
tftpboot 0x8400 
openwrt-ipq40xx-generic-wallys_dr40x9-initramfs-fit-uImage.itb

bootm

Then copy the sysupgrade image to the /tmp folder and execute sysupgrade -n 


The board file binary was provided from Wallystech on March 14th 2023
including full permission to use and distribute.

Signed-off-by: Robert Marko 
Signed-off-by: Koen Vandeputte 
---

v2:
- Remove unused alias
- Use original labels

v3:
- Remove bracketed comments
- get actual bdf from side repo

 package/firmware/ipq-wifi/Makefile|   2 +
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../base-files/etc/board.d/03_gpio_switches   |   3 +
 .../base-files/lib/upgrade/platform.sh|   3 +-
 .../arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts | 422 ++
 target/linux/ipq40xx/image/generic.mk |  13 +
 6 files changed, 443 insertions(+), 1 deletion(-)
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index 846032c96f..f3bf1185f8 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -54,6 +54,7 @@ ALLWIFIBOARDS:= \
redmi_ax6 \
sony_ncp-hg100-cellular \
teltonika_rutx \
+   wallys_dr40x9 \
xiaomi_ax3600 \
xiaomi_ax9000 \
zte_mf18a \
@@ -158,6 +159,7 @@ $(eval $(call 
generate-ipq-wifi-package,qxwlan_e2600ac-c2,Qxwlan E2600AC C2))
 $(eval $(call generate-ipq-wifi-package,redmi_ax6,Redmi AX6))
 $(eval $(call generate-ipq-wifi-package,sony_ncp-hg100-cellular,Sony 
NCP-HG100/Cellular))
 $(eval $(call generate-ipq-wifi-package,teltonika_rutx,Teltonika RUTX))
+$(eval $(call generate-ipq-wifi-package,wallys_dr40x9,Wallys DR40X9))
 $(eval $(call generate-ipq-wifi-package,xiaomi_ax3600,Xiaomi AX3600))
 $(eval $(call generate-ipq-wifi-package,xiaomi_ax9000,Xiaomi AX9000))
 $(eval $(call generate-ipq-wifi-package,zte_mf18a,ZTE MF18A))
diff --git a/target/linux/ipq40xx/base-files/etc/board.d/02_network 
b/target/linux/ipq40xx/base-files/etc/board.d/02_network
index 3625938e38..37b9ca268b 100644
--- a/target/linux/ipq40xx/base-files/etc/board.d/02_network
+++ b/target/linux/ipq40xx/base-files/etc/board.d/02_network
@@ -39,6 +39,7 @@ ipq40xx_setup_interfaces()
mikrotik,cap-ac|\
netgear,wac510|\
sony,ncp-hg100-cellular|\
+   wallys,dr40x9|\
zte,mf18a|\
zte,mf289f)
ucidef_set_interfaces_lan_wan "lan" "wan"
diff --git a/target/linux/ipq40xx/base-files/etc/board.d/03_gpio_switches 
b/target/linux/ipq40xx/base-files/etc/board.d/03_gpio_switches
index 4918e2ccc1..f76fe9402d 100644
--- a/target/linux/ipq40xx/base-files/etc/board.d/03_gpio_switches
+++ b/target/linux/ipq40xx/base-files/etc/board.d/03_gpio_switches
@@ -32,6 +32,9 @@ mikrotik,hap-ac3-lte6-kit)
 sony,ncp-hg100-cellular)
ucidef_add_gpio_switch "uart_dbgcon_en" "debug console enable" "427" "1"
;;
+wallys,dr40x9)
+   ucidef_add_gpio_switch "sim_card_select" "SIM card select" "423" "0"
+   ;;
 zte,mf286d|\
 zte,mf289f)
ucidef_add_gpio_switch "power_btn_block" "Power button blocker" "421" 
"0"
diff --git a/target/linux/ipq40xx/base-files/lib/upgrade/platform.sh 
b/target/linux/ipq40xx/base-files/lib/upgrade/platform.sh
index 2012213a56..988921fa8c 100644
--- a/target/linux/ipq40xx/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ipq40xx/base-files/lib/upgrade/platform.sh
@@ -119,7 +119,8 @@ platform_do_upgrade() {
netgear,wac510 |\
p2w,r619ac-64m |\
p2w,r619ac-128m |\
-   qxwlan,e2600ac-c2)
+   qxwlan,e2600ac-c2 |\
+   wallys,dr40x9)
nand_do_upgrade "$1"
;;
glinet,gl-b2200)
diff --git 
a/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts 
b/target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq4

[PATCH v3 1/2] ipq-wifi: bump to latest git HEAD

[Koen Vandeputte]

f9cece0 ipq40xx: add support for Wallystech DR40x9

Signed-off-by: Koen Vandeputte 
---
 package/firmware/ipq-wifi/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index 57cd226bb7..846032c96f 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -6,9 +6,9 @@ PKG_RELEASE:=1
 
 PKG_SOURCE_PROTO:=git
 PKG_SOURCE_URL=$(PROJECT_GIT)/project/firmware/qca-wireless.git
-PKG_SOURCE_DATE:=2023-03-19
-PKG_SOURCE_VERSION:=31ff96d9f99f993cb43d79f0c411fe6bf55633bb
-PKG_MIRROR_HASH:=8005a884059925a627024b9022ed06a36ebf4ed7a20e8aab191585afbdd6895f
+PKG_SOURCE_DATE:=2023-03-20
+PKG_SOURCE_VERSION:=f9cece02724b8ca2c1a166a46f0afa89e632d431
+PKG_MIRROR_HASH:=89c20798c7ec83114aa69467f2467fe32cbb74ebeca277c60a033af960ca6c04
 
 PKG_FLAGS:=nonshared
 
-- 
2.34.1


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

[PATCH] ipq40xx: add support for Wallystech DR40x9

[Koen Vandeputte]

Adds support for the Wallys DR40x9 series boards.
They come in IPQ4019 and IPQ4029 versions.
IPQ4019/4029 only differ in that that IPQ4029 is the industrial version that is 
rated to higher temperatures.

Specifications are:
* CPU: Qualcomm IPQ40x9 (4x ARMv7A Cortex A7) at 716 MHz
* RAM: 512 MB
* Storage: 2MB of SPI-NOR, 128 MB of parallel NAND
* USB 3.0 TypeA port for users
* MiniPCI-E with PCI-E 2.0 link
* MiniPCI-E for LTE modems with only USB2.0 link
* 2 SIM card slots that are selected via GPIO11
* MicroSD card slot
* Ethernet: 2x GBe with 24~48V passive POE
* SFP port (Does not work, I2C and GPIO's not connected on hardware)
* DC Jack
* UART header
* WLAN: In-SoC 2x2 802.11b/g/n and 2x2 802.11a/n/ac
* 4x MMCX connectors for WLAN
* Reset button
* 8x LED-s

Installation instructions:
Connect to UART, pins are like this:
-> 3.3V | TX | RX | GND

Settings are 115200 8n1

Boot initramfs from TFTP:
tftpboot 0x8400 
openwrt-ipq40xx-generic-wallys_dr40x9-initramfs-fit-uImage.itb

bootm

Then copy the sysupgrade image to the /tmp folder and execute sysupgrade -n 


The board file binary was provided from Wallystech on March 14th 2023
including full permission to use and distribute.

Signed-off-by: Robert Marko 
Signed-off-by: Koen Vandeputte 
---

Board file commit for the Wallys DR40x9
Looks like I don't have access to push to that repo ..

 board-wallys_dr40x9.qca4019 | Bin 0 -> 24316 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 board-wallys_dr40x9.qca4019

diff --git a/board-wallys_dr40x9.qca4019 b/board-wallys_dr40x9.qca4019
new file mode 100644
index 
..f23ecdfabbb90dc8d293676c4449a5fa9e90e721
GIT binary patch
literal 24316
zcmeHPdr(tX8b1jj%4*?;fV{kf@JeV1A*2{2@{BY<3KkU!un1IR1@j)RX
z0<|DS&^joOrihHi2gGV^?Tj+*=8pf3%%_bZ6FG+tKc{GrNm>?hSzi5={iA0qz
zIp6v2`Of*yFDJ>p_x!kTCdP-x?-Ye|QbQBc<1>UnE|+C1F?~E+ii)iT#f7Xw
zxis{xVrglpbnjLUUMoCUP`($dayhKZf^uoWfkRt&7nGFLRD=pMc$};#ISKmHU|+N_
zk%}*aB_5k3IJ39UWvdp(;1UV$GQR_A|m3aCr?NM>KgFNUrxp9
zlO62fCFS;9zZTs{;29KnY`Qkx>f+qi`nof%|#kfeL*k60U;wiCa!dygd@C>95wMV
zbdcc=eXx__>{LDjcGp@{nw`PtOgjV{$M=F-4U`u+NN<7~^5Owh~Y>J+tLyz1UPx
z6}2xo(1g*lgps%q&5mgwpV^i|2mIJlh
zq^umbn9uubK1e^ouGsX}jlrtUH=07Le2PX-7FWmYV`d^zH(@)WjGf~ebE!|-A!>ZJ
z%DedbN0mKcb-typ`O6C>B3eBH4vy=7v%wj0b=%|_2vCk9O4?H2lGBTM=
z!g4!1__MrbS{yIeXK_64zq6f-1_b!Szd*X5pFiD?PS3PoJLjB49}-b6Ap%)h8EJI7
zFC5|LpP&3NHHDo4@tJ}CI@^DL_|x}>Hmu>M^^RnF`~Sgq^?&;G@grT^B@7qu
zx^xJhk3g-ou6YPcm@zVv$I~UKa5-#NNF-KWu*QRZaPeLiN5dyDCqqyKiAUp+a5Nk#
zRUEE6`d)Ke$9x3{rsbAZ3I(OGDGw-!7wX0K61$)-hzFX0Ca@D8Bp@kh3Ohv{hsGfy
zl#6oN+y`7_3%Z59Ma)4t2p^pZLVdxsIunyXFcTG_=3>fy5Pcee8;Oquy+9aUz=d
zI1x!jQ`xEF2sGkx1QLx#v!lhjH^DH+htfg66Fdf%}6X|tzJMzVe5sFyN0>`(%-sr{ut}@vS?$h;BSqtVz
zv9z7}9`VatER;zkPAI>e|J#Xx$H=D(>O%2{dkDR%iPH0x6VUvr}AgDNi
z0N3xC^#Fu}Ajr@0g>0YzNQI)qgq1Cna6qT~_|WG_JG9TY(&@Qv0YJbffu9Zn(C
z;&=cs)*?Uv1oruB5I}Y#JLSUC#RcDVG>C*yR~iD(hSyWcAf!>T7SS`AJ4io*JaZh;QOFrN`rnU6yF0CCp74HLGk@hF}Fd#18O~pW<6Fuy31x6
ztgJvS*)vYd%qwa>bFNQwP5Xs8ePy9CI~(d074boR*gj$^5KajZF)C(@#X`WF;voW5
zz!r#ki*|iIJE}FBJJ%gSDM{QUB#jcujYMK7*=MoW{66%*bNX_*T;f>ExetFK=iWg>
zB0<7^bqme_ck6|S*PdBR#diWnXz>8!+|#CChNED*agU3@^`}y)084stcXtO^(uV8Z)kO)L!aW)Z1<}_wDZW?!{7;>HHrH-k@9v(Q?CxE^-k1(!+{T*P
zs@%#YCT+Gv)2NIr+!}9odBv2hd1_MK6F!&=GJRGwF
zj|KL?dE6evZgl{No1KH>;)Fo-LLfjOu<8()<;IQI+ErkVB}7He@dQwxmX-0Q9|
zZ_Qq4u0qw4`zMBMd!3F$rbBDVb8PJz^6fEwft33|aTa!?d;FpC6~=7M)aS*}_RWa4
zU0tcnl!SeAUE8IuRpv?f+H2}F$}{agBzzz2|HN+H4rT!8(56->cS+cj
z!Uo)!imB}P*oY?N#N5khw(eX!2oY2Q)VhNCvRxFRSMY-$!5(B
z)frj2NXX|xhc;!2-eKZSFcVDP(wtLO!hT=V4r@MC)ygCifkvz9k{uFlV|d^rye-So
zg`~X$Lz=v<=~5q2$z|KLS2P#YjnFwwb5qqRs}zYC-r6zs`*=vcSV*_;GME5PwMTPG
ztx)B|kksm9sxqZSb4A@FlZ)c{VUssC7gRN}-Fz>d12YJlL#z6*sz{jz51vz1%eG6x
zU?81Jg(Q{FoV=zvt16eJivlo*Pwy}xN>{a=>Izk!QaCvV4^}91WhpSs^AO88J_?U^
ztE*&*B2V1m9-M_Nr
z!AIQXnk$M6(T(&<%AUr~^y9or56ODb)xkaQ^WXKAyXEz1q&>n@GzF61KUkp_9HW=H
zNJe|gn-gnUa`%k;AEz|2YCMZvcJ~kO?@ekAI7}_-7)wlS!hT5zdT+7P1%+3%X#
zclqGi=%fDS)V#C(1)cFteif9w_CD!Z!Eyfz*W8oMyWio-=sA?Qk%5Ztw3Cb~kA16l
z;Sdui5Lf{SEc6K+@HtqsVgirhhJ3yY{sfM|zySCMpT0r!_w%FsWdfUd0>^wlyqO9>x~-EK}8tF8KC>s7!E6hf#3YL
zISuFBV-Lh(Olu)CnyuLI=j$+nu)FsQMxBr@adu(iibC2(Jy=+Es?q3!;!p~+Auw>8J9M9g+ZnG0yU|https://lists.openwrt.org/mailman/listinfo/openwrt-devel

[PATCH v2] ipq40xx: add support for Wallystech DR40x9

[Koen Vandeputte]

From: Robert Marko 

Adds support for the Wallys DR40x9 series boards.
They come in IPQ4019 and IPQ4029 versions.
IPQ4019/4029 only differ in that that IPQ4029 is the industrial version that is 
rated to higher temperatures.

Specifications are:
* CPU: Qualcomm IPQ40x9 (4x ARMv7A Cortex A7) at 716 MHz
* RAM: 512 MB
* Storage: 2MB of SPI-NOR, 128 MB of parallel NAND
* USB 3.0 TypeA port for users
* MiniPCI-E with PCI-E 2.0 link
* MiniPCI-E for LTE modems with only USB2.0 link
* 2 SIM card slots that are selected via GPIO11
* MicroSD card slot
* Ethernet: 2x GBe with 24~48V passive POE
* SFP port (Does not work, I2C and GPIO's not connected on hardware)
* DC Jack
* UART header
* WLAN: In-SoC 2x2 802.11b/g/n and 2x2 802.11a/n/ac
* 4x MMCX connectors for WLAN
* Reset button
* 8x LED-s

Installation instructions:
Connect to UART, pins are like this:
-> 3.3V | TX | RX | GND

Settings are 115200 8n1

Boot initramfs from TFTP:
tftpboot 0x8400 
openwrt-ipq40xx-generic-wallys_dr40x9-initramfs-fit-uImage.itb

bootm

Then copy the sysupgrade image to the /tmp folder and execute sysupgrade -n 


Signed-off-by: Robert Marko 
[Fixup dts for 2 missing crypto options]
[Remove sfp from dts]
[Add 'config' partition]
[Update to latest wifi board bin files - received from Wallystech R]
[Extensively tested on DR4029-V04]
Signed-off-by: Koen Vandeputte 
---

v2:
- Remove unused alias
- Use original labels

 package/firmware/ipq-wifi/Makefile|   2 +
 .../ipq-wifi/board-wallys_dr40x9.qca4019  | Bin 0 -> 24316 bytes
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../base-files/etc/board.d/03_gpio_switches   |   3 +
 .../base-files/lib/upgrade/platform.sh|   3 +-
 .../arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts | 422 ++
 target/linux/ipq40xx/image/generic.mk |  13 +
 7 files changed, 443 insertions(+), 1 deletion(-)
 create mode 100644 package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index f1c60a7782..dc2a8e1e3b 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -50,6 +50,7 @@ ALLWIFIBOARDS:= \
redmi_ax6 \
sony_ncp-hg100-cellular \
teltonika_rutx \
+   wallys_dr40x9 \
xiaomi_ax3600 \
xiaomi_ax9000 \
zte_mf18a \
@@ -150,6 +151,7 @@ $(eval $(call 
generate-ipq-wifi-package,qxwlan_e2600ac-c2,Qxwlan E2600AC C2))
 $(eval $(call generate-ipq-wifi-package,redmi_ax6,Redmi AX6))
 $(eval $(call generate-ipq-wifi-package,sony_ncp-hg100-cellular,Sony 
NCP-HG100/Cellular))
 $(eval $(call generate-ipq-wifi-package,teltonika_rutx,Teltonika RUTX))
+$(eval $(call generate-ipq-wifi-package,wallys_dr40x9,Wallys DR40X9))
 $(eval $(call generate-ipq-wifi-package,xiaomi_ax3600,Xiaomi AX3600))
 $(eval $(call generate-ipq-wifi-package,xiaomi_ax9000,Xiaomi AX9000))
 $(eval $(call generate-ipq-wifi-package,zte_mf18a,ZTE MF18A))
diff --git a/package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019 
b/package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019
new file mode 100644
index 
..f23ecdfabbb90dc8d293676c4449a5fa9e90e721
GIT binary patch
literal 24316
zcmeHPdr(tX8b1jj%4*?;fV{kf@JeV1A*2{2@{BY<3KkU!un1IR1@j)RX
z0<|DS&^joOrihHi2gGV^?Tj+*=8pf3%%_bZ6FG+tKc{GrNm>?hSzi5={iA0qz
zIp6v2`Of*yFDJ>p_x!kTCdP-x?-Ye|QbQBc<1>UnE|+C1F?~E+ii)iT#f7Xw
zxis{xVrglpbnjLUUMoCUP`($dayhKZf^uoWfkRt&7nGFLRD=pMc$};#ISKmHU|+N_
zk%}*aB_5k3IJ39UWvdp(;1UV$GQR_A|m3aCr?NM>KgFNUrxp9
zlO62fCFS;9zZTs{;29KnY`Qkx>f+qi`nof%|#kfeL*k60U;wiCa!dygd@C>95wMV
zbdcc=eXx__>{LDjcGp@{nw`PtOgjV{$M=F-4U`u+NN<7~^5Owh~Y>J+tLyz1UPx
z6}2xo(1g*lgps%q&5mgwpV^i|2mIJlh
zq^umbn9uubK1e^ouGsX}jlrtUH=07Le2PX-7FWmYV`d^zH(@)WjGf~ebE!|-A!>ZJ
z%DedbN0mKcb-typ`O6C>B3eBH4vy=7v%wj0b=%|_2vCk9O4?H2lGBTM=
z!g4!1__MrbS{yIeXK_64zq6f-1_b!Szd*X5pFiD?PS3PoJLjB49}-b6Ap%)h8EJI7
zFC5|LpP&3NHHDo4@tJ}CI@^DL_|x}>Hmu>M^^RnF`~Sgq^?&;G@grT^B@7qu
zx^xJhk3g-ou6YPcm@zVv$I~UKa5-#NNF-KWu*QRZaPeLiN5dyDCqqyKiAUp+a5Nk#
zRUEE6`d)Ke$9x3{rsbAZ3I(OGDGw-!7wX0K61$)-hzFX0Ca@D8Bp@kh3Ohv{hsGfy
zl#6oN+y`7_3%Z59Ma)4t2p^pZLVdxsIunyXFcTG_=3>fy5Pcee8;Oquy+9aUz=d
zI1x!jQ`xEF2sGkx1QLx#v!lhjH^DH+htfg66Fdf%}6X|tzJMzVe5sFyN0>`(%-sr{ut}@vS?$h;BSqtVz
zv9z7}9`VatER;zkPAI>e|J#Xx$H=D(>O%2{dkDR%iPH0x6VUvr}AgDNi
z0N3xC^#Fu}Ajr@0g>0YzNQI)qgq1Cna6qT~_|WG_JG9TY(&@Qv0YJbffu9Zn(C
z;&=cs)*?Uv1oruB5I}Y#JLSUC#RcDVG>C*yR~iD(hSyWcAf!>T7SS`AJ4io*JaZh;QOFrN`rnU6yF0CCp74HLGk@hF}Fd#18O~pW<6Fuy31x6
ztgJvS*)vYd%qwa>bFNQwP5Xs8ePy9CI~(d074boR*gj$^5KajZF)C(@#X`WF;voW5
zz!r#ki*|iIJE}FBJJ%gSDM{QUB#jcujYMK7*=MoW{66%*bNX_*T;f>ExetFK=iWg>
zB0<7^bqme_ck6|S*PdBR#diWnXz>8!+|#CChNED*agU3@^`}y)084stcXtO^(uV8Z)kO)L!aW)Z1<}_wDZW?!{7;>HHrH-k@9v(Q?CxE^-k1(!+{T*P
zs@%#YCT+Gv)2NIr+!}9odBv2hd1_MK6F!&=GJRGwF
zj|KL?d

[PATCH] ipq40xx: add support for Wallystech DR40x9

[Koen Vandeputte]

From: Robert Marko 

Adds support for the Wallys DR40x9 series boards.
They come in IPQ4019 and IPQ4029 versions.
IPQ4019/4029 only differ in that that IPQ4029 is the industrial version that is 
rated to higher temperatures.

Specifications are:
* CPU: Qualcomm IPQ40x9 (4x ARMv7A Cortex A7) at 716 MHz
* RAM: 512 MB
* Storage: 2MB of SPI-NOR, 128 MB of parallel NAND
* USB 3.0 TypeA port for users
* MiniPCI-E with PCI-E 2.0 link
* MiniPCI-E for LTE modems with only USB2.0 link
* 2 SIM card slots that are selected via GPIO11
* MicroSD card slot
* Ethernet: 2x GBe with 24~48V passive POE
* SFP port (Does not work, I2C and GPIO's not connected on hardware)
* DC Jack
* UART header
* WLAN: In-SoC 2x2 802.11b/g/n and 2x2 802.11a/n/ac
* 4x MMCX connectors for WLAN
* Reset button
* 8x LED-s

Installation instructions:
Connect to UART, pins are like this:
-> 3.3V | TX | RX | GND

Settings are 115200 8n1

Boot initramfs from TFTP:
tftpboot 0x8400 
openwrt-ipq40xx-generic-wallys_dr40x9-initramfs-fit-uImage.itb

bootm

Then copy the sysupgrade image to the /tmp folder and execute sysupgrade -n 


Signed-off-by: Robert Marko 
[Fixup dts for 2 missing crypto options]
[Remove sfp from dts]
[Add 'config' partition]
[Update to latest wifi board bin files - received from Wallystech R]
[Extensively tested on DR4029-V04]
Signed-off-by: Koen Vandeputte 
---
 package/firmware/ipq-wifi/Makefile|   2 +
 .../ipq-wifi/board-wallys_dr40x9.qca4019  | Bin 0 -> 24316 bytes
 .../ipq40xx/base-files/etc/board.d/02_network |   1 +
 .../base-files/etc/board.d/03_gpio_switches   |   3 +
 .../base-files/lib/upgrade/platform.sh|   3 +-
 .../arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts | 425 ++
 target/linux/ipq40xx/image/generic.mk |  13 +
 7 files changed, 446 insertions(+), 1 deletion(-)
 create mode 100644 package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019
 create mode 100644 
target/linux/ipq40xx/files/arch/arm/boot/dts/qcom-ipq40x9-dr40x9.dts

diff --git a/package/firmware/ipq-wifi/Makefile 
b/package/firmware/ipq-wifi/Makefile
index 8e7fc4da39..6feac277b3 100644
--- a/package/firmware/ipq-wifi/Makefile
+++ b/package/firmware/ipq-wifi/Makefile
@@ -47,6 +47,7 @@ ALLWIFIBOARDS:= \
redmi_ax6 \
sony_ncp-hg100-cellular \
teltonika_rutx \
+   wallys_dr40x9 \
xiaomi_ax3600 \
xiaomi_ax9000 \
zte_mf18a \
@@ -147,6 +148,7 @@ $(eval $(call 
generate-ipq-wifi-package,qxwlan_e2600ac-c2,Qxwlan E2600AC C2))
 $(eval $(call generate-ipq-wifi-package,redmi_ax6,Redmi AX6))
 $(eval $(call generate-ipq-wifi-package,sony_ncp-hg100-cellular,Sony 
NCP-HG100/Cellular))
 $(eval $(call generate-ipq-wifi-package,teltonika_rutx,Teltonika RUTX))
+$(eval $(call generate-ipq-wifi-package,wallys_dr40x9,Wallys DR40X9))
 $(eval $(call generate-ipq-wifi-package,xiaomi_ax3600,Xiaomi AX3600))
 $(eval $(call generate-ipq-wifi-package,xiaomi_ax9000,Xiaomi AX9000))
 $(eval $(call generate-ipq-wifi-package,zte_mf18a,ZTE MF18A))
diff --git a/package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019 
b/package/firmware/ipq-wifi/board-wallys_dr40x9.qca4019
new file mode 100644
index 
..f23ecdfabbb90dc8d293676c4449a5fa9e90e721
GIT binary patch
literal 24316
zcmeHPdr(tX8b1jj%4*?;fV{kf@JeV1A*2{2@{BY<3KkU!un1IR1@j)RX
z0<|DS&^joOrihHi2gGV^?Tj+*=8pf3%%_bZ6FG+tKc{GrNm>?hSzi5={iA0qz
zIp6v2`Of*yFDJ>p_x!kTCdP-x?-Ye|QbQBc<1>UnE|+C1F?~E+ii)iT#f7Xw
zxis{xVrglpbnjLUUMoCUP`($dayhKZf^uoWfkRt&7nGFLRD=pMc$};#ISKmHU|+N_
zk%}*aB_5k3IJ39UWvdp(;1UV$GQR_A|m3aCr?NM>KgFNUrxp9
zlO62fCFS;9zZTs{;29KnY`Qkx>f+qi`nof%|#kfeL*k60U;wiCa!dygd@C>95wMV
zbdcc=eXx__>{LDjcGp@{nw`PtOgjV{$M=F-4U`u+NN<7~^5Owh~Y>J+tLyz1UPx
z6}2xo(1g*lgps%q&5mgwpV^i|2mIJlh
zq^umbn9uubK1e^ouGsX}jlrtUH=07Le2PX-7FWmYV`d^zH(@)WjGf~ebE!|-A!>ZJ
z%DedbN0mKcb-typ`O6C>B3eBH4vy=7v%wj0b=%|_2vCk9O4?H2lGBTM=
z!g4!1__MrbS{yIeXK_64zq6f-1_b!Szd*X5pFiD?PS3PoJLjB49}-b6Ap%)h8EJI7
zFC5|LpP&3NHHDo4@tJ}CI@^DL_|x}>Hmu>M^^RnF`~Sgq^?&;G@grT^B@7qu
zx^xJhk3g-ou6YPcm@zVv$I~UKa5-#NNF-KWu*QRZaPeLiN5dyDCqqyKiAUp+a5Nk#
zRUEE6`d)Ke$9x3{rsbAZ3I(OGDGw-!7wX0K61$)-hzFX0Ca@D8Bp@kh3Ohv{hsGfy
zl#6oN+y`7_3%Z59Ma)4t2p^pZLVdxsIunyXFcTG_=3>fy5Pcee8;Oquy+9aUz=d
zI1x!jQ`xEF2sGkx1QLx#v!lhjH^DH+htfg66Fdf%}6X|tzJMzVe5sFyN0>`(%-sr{ut}@vS?$h;BSqtVz
zv9z7}9`VatER;zkPAI>e|J#Xx$H=D(>O%2{dkDR%iPH0x6VUvr}AgDNi
z0N3xC^#Fu}Ajr@0g>0YzNQI)qgq1Cna6qT~_|WG_JG9TY(&@Qv0YJbffu9Zn(C
z;&=cs)*?Uv1oruB5I}Y#JLSUC#RcDVG>C*yR~iD(hSyWcAf!>T7SS`AJ4io*JaZh;QOFrN`rnU6yF0CCp74HLGk@hF}Fd#18O~pW<6Fuy31x6
ztgJvS*)vYd%qwa>bFNQwP5Xs8ePy9CI~(d074boR*gj$^5KajZF)C(@#X`WF;voW5
zz!r#ki*|iIJE}FBJJ%gSDM{QUB#jcujYMK7*=MoW{66%*bNX_*T;f>ExetFK=iWg>
zB0<7^bqme_ck6|S*PdBR#diWnXz>8!+|#CChNED*agU3@^`}y)084stcXtO^(uV8Z)kO)L!aW)Z1<}_wDZW?!{7;>HHrH-k@9v(Q?CxE^-k1(!+{T*P
zs@%#YCT+Gv)2NIr+!}9odBv2hd1_MK6F!&=GJRGwF
zj|KL?dE6evZgl{No1KH>;)Fo-LLfjOu<8()<;IQI+ErkVB}7He@

[PATCH] tools: meson: bump to 1.0.0

[Koen Vandeputte]

Drop upstreamed patch.

Tested by compiling the complete gstreamer package which heavily
depends on this one.

Signed-off-by: Koen Vandeputte 
---

This patch is a requirement to build gstreamer 1.22.0 for which a PR is ready 
to submit in package feed

 tools/meson/Makefile   |  4 ++--
 tools/meson/patches/010-wsl2.patch | 21 -
 2 files changed, 2 insertions(+), 23 deletions(-)
 delete mode 100644 tools/meson/patches/010-wsl2.patch

diff --git a/tools/meson/Makefile b/tools/meson/Makefile
index d53ed897a3..75fae42b37 100644
--- a/tools/meson/Makefile
+++ b/tools/meson/Makefile
@@ -1,11 +1,11 @@
 include $(TOPDIR)/rules.mk
 
 PKG_NAME:=meson
-PKG_VERSION:=0.61.5
+PKG_VERSION:=1.0.0
 
 PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
 
PKG_SOURCE_URL:=https://github.com/mesonbuild/meson/releases/download/$(PKG_VERSION)
-PKG_HASH:=5e9a0d65c1a51936362b9686d1c5e9e184a6fd245d57e7269750ce50c20f5d9a
+PKG_HASH:=aa50a4ba4557c25e7d48446abfde857957dcdf58385fffbe670ba0e8efacce05
 
 PKG_MAINTAINER:=Andre Heider 
 PKG_LICENSE:=Apache-2.0
diff --git a/tools/meson/patches/010-wsl2.patch 
b/tools/meson/patches/010-wsl2.patch
deleted file mode 100644
index 4ab799d699..00
--- a/tools/meson/patches/010-wsl2.patch
+++ /dev/null
@@ -1,21 +0,0 @@
-From 7d1ef4343ed5b2b7ab51469177a42c32c47f0528 Mon Sep 17 00:00:00 2001
-From: Rosen Penev 
-Date: Tue, 6 Sep 2022 01:36:17 -0700
-Subject: [PATCH] minstall: handle extra error for selinuxenabled
-
-Microsoft's WSL2 uses a Plan 9 filesystem, which returns IOError when file is 
missing.

- mesonbuild/minstall.py | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
 a/mesonbuild/minstall.py
-+++ b/mesonbuild/minstall.py
-@@ -229,7 +229,7 @@ def restore_selinux_contexts() -> None:
- '''
- try:
- subprocess.check_call(['selinuxenabled'])
--except (FileNotFoundError, NotADirectoryError, PermissionError, 
subprocess.CalledProcessError):
-+except (FileNotFoundError, NotADirectoryError, OSError, PermissionError, 
subprocess.CalledProcessError):
- # If we don't have selinux or selinuxenabled returned 1, failure
- # is ignored quietly.
- return
-- 
2.34.1


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

Re: sysupgrade broken on imx nand targets (and maybe others too)

[Koen Vandeputte]

On Tue, Jan 24, 2023 at 11:43 PM Lanchon  wrote:
>
>
>
> On 1/24/23 18:08, Koen Vandeputte wrote:
> >
> > Hi,
> >
> > I think our previous mails overlapped a bit as  I didn't notice your
> > previous response :)
> >
> > I'll send the data tomorrow.
> > I'm also wondering if adding a sleep before ubiformat in the old way
> > would influence/break it's behaviour?
> possibly yes
> >
> >
> > Piotr,
> > Would you have any idea here?
> >
> >
> > Thanks again for your efforts,
> >
> > Koen
>
>
> if your active watchdog device is /dev/MyWatchdog, then...
>
>
> just before the line:
>
> ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
> -m "$mtdnum"
>
> you could add this to try disable the watchdog:
>
> echo -n V >/dev/MyWatchdog
>
>
> or else you could tickle the watchdog while flashing like this:
>
> ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - 2>&1 | tee
> /dev/MyWatchdog && ubiattach -m "$mtdnum"
>
> BUT... this is a hack, cause shell option pipefail would be needed to
> detect a failure of ubiformat then, as normally only the exit code of
> the last piped process gets returned from the pipe expression.
>
>
> so these are just tests, not fixes.
>
>
> another dirty thing you could do is doubling the watchdog timeout period
> for your platform. this at least could maybe be accepted as a stopgap
> band aid in the openwrt tree. but the race condition remains, and it
> will bite back sometime. a real fix for the race should be implemented.
>
> BTW your watchdog seems to be:
> https://www.kernelconfig.io/config_imx2_wdt
>
>
> thanks!
>
>


Hi all,

Hardware:
Gateworks Ventana gw5200, naked without any additional hardware attached.

Full normal bootlog:
https://pastebin.com/raw/nSBnrHxN

Watchdog info:
root@OpenWrt:~# ubus call system watchdog
{
"status": "running",
"timeout": 30,
"frequency": 5,
"magicclose": false
}


Normal reboot command issued as user after boot:
--> a reboot on Gateworks Ventana is handled by waking the watchdog
which triggers a GPIO, controlling a PMIC to reset power

[   56.791836] br-wan: port 1(eth0) entered disabled state
[   56.801236] device eth0 left promiscuous mode
[   56.805828] br-wan: port 1(eth0) entered disabled state
* reboot command issued by me here *
crond[1416]: USER root pid 2191 cmd /usr/sbin/logrotate
/etc/logrotate/logrotate.conf > /var/log/logrotate.log
[   61.139944] ci_hdrc ci_hdrc.1: remove, state 1
[   61.144418] usb usb2: USB disconnect, device number 1
[   61.150316] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
[   61.155792] ci_hdrc ci_hdrc.0: remove, state 1
[   61.160257] usb usb1: USB disconnect, device number 1
[   61.166336] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
[   61.173094] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot!
[   61.179787] reboot: Restarting system


Full log sysupgrade failing:  (cat ubifile | ubiformat -f -)
https://pastebin.com/raw/QPNbe49K
Time from sysupgrade-start to reboot --> 23.38 sec

Full log sysupgrade working:  (ubiformat -f /tmp/ubifile)
https://pastebin.com/raw/qtSMnbDh
Time from sysupgrade-start to reboot --> 33.55 sec



Again ..
I'm NOT saying that feeding the ubi directly is a proper fix.
I'm saying that the watchdog itself seems NOT to be the cause.
It is used as a way to powercycle the board when a "reboot" command is issued.

According to me, somewhere during upgrade a 'reboot' command gets
triggered somewhere at a wrong time ..

Kind regards,

Koen

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

Re: sysupgrade broken on imx nand targets (and maybe others too)

[Koen Vandeputte]

On Tue, Jan 24, 2023 at 9:46 PM Lanchon  wrote:
>
>
>
> On 1/24/23 17:35, Lanchon wrote:
> >
> >
> > On 1/24/23 13:25, Koen Vandeputte wrote:
> >> On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
> >>  wrote:
> >>> On Tue, Jan 24, 2023 at 7:59 AM Lanchon  wrote:
> >>>> hi Koen, thanks again.
> >>>>
> >>>> i copied your log here for ease of reference:
> >>>> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
> >>>>
> >>>>
> >>>> first let me say:
> >>>>
> >>>> - ubinized sysupgrade is not used by any of my devices.
> >>>>
> >>>> - ubinized sysupgrade happens when when an ubi partition image is
> >>>> fed as
> >>>> an upgrade file. the image contains the complete set of ubi volumes
> >>>> that
> >>>> are normally stored within the ubi partition on your device: typically
> >>>> kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during
> >>>> said sysupgrade, the current configuration is first copied to RAM,
> >>>> then
> >>>> the ubi partition image is written, and finally -if current config is
> >>>> kept- the RAM contents are written back to the new overlay volume.
> >>>>
> >>>> - ubinized sysupgrades were known to be broken by other people at the
> >>>> time of my commits, and they wanted to remove the feature altogether
> >>>> because it was unused (look it up in the relevant pull request for my
> >>>> commits on github). as i remember it, it was broken because some ubi
> >>>> volumes within the ubi partition were sometimes mounted or R/O block
> >>>> devices were created on top of them (/dev/ubiblock*), locking the ubi
> >>>> partition and preventing the upgrade.
> >>>>
> >>>> - although my devices would normally not use such upgrades, i could
> >>>> still take a whole ubi partition backup and then test ubinized
> >>>> sysupgrade with it on my devices. in fact, if you restore the ubi
> >>>> partition image without conserving the current configuration, then
> >>>> this
> >>>> procedure is the best way to do a backup/restore of the complete state
> >>>> of the router: kernel, rootfs, and overlay are completely saved and
> >>>> restored. btw, i think this should be documented. (and this is mostly
> >>>> the reason why i added gzip support on sysupgrade: ubinized images of
> >>>> backed-up ubi partitions compress like crazy.)
> >>>>
> >>>> - my tests of ubinized sysupgrade worked after these changes but not
> >>>> before. specifically the fix is in: af34733593 base-files: fix
> >>>> ubinized
> >>>> nand sysupgrade
> >>>>
> >>>>
> >>>> regarding your log:
> >>>>
> >>>> - nand_do_platform_check succeeds:
> >>>> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469
> >>>>
> >>>> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192
> >>>>
> >>>>
> >>>> - next comes the actual nand_do_flash_file:
> >>>> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405
> >>>>
> >>>> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061
> >>>>
> >>>>
> >>>> - it is determined that passed file is a ubi partition image, so
> >>>> nand_upgrade_ubinized is invoked:
> >>>> https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269
> >>>>
> >>>> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088
> >>>>
> >>>>
> >>>> nand_upgrade_ubinized is basically a one-liner:
> >>>> ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - &&
> >>>> ubiattach
> >>>> -m "$mtdnum"
> >>>>
> >>>> cat/zcat the imag

Re: sysupgrade broken on imx nand targets (and maybe others too)

[Koen Vandeputte]

On Tue, Jan 24, 2023 at 5:49 PM  wrote:
>
> On 24.01.2023 17:13, Lanchon wrote:
> > the problem lies elsewhere: on your platform something is rebooting the 
> > system asynchronously while it is updating. this is very dangerous and must 
> > be fixed elsewhere in code.
>
> just a wild guess. faulty power supplies sometimes lead to reboots if the 
> power supplied does not suffice. maybe a direction to investigate? ..sunny 
> regards ede
>

Hi,

In this case it should be faulty on all of my 53 boards.
Some are powered using a DC supply, others through PoE.

I don't think this is the issue here. :-)

Regards,

Koen

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

Re: sysupgrade broken on imx nand targets (and maybe others too)

[Koen Vandeputte]

On Tue, Jan 24, 2023 at 4:26 PM Koen Vandeputte
 wrote:
>
> On Tue, Jan 24, 2023 at 7:59 AM Lanchon  wrote:
> >
> > hi Koen, thanks again.
> >
> > i copied your log here for ease of reference:
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db
> >
> >
> > first let me say:
> >
> > - ubinized sysupgrade is not used by any of my devices.
> >
> > - ubinized sysupgrade happens when when an ubi partition image is fed as
> > an upgrade file. the image contains the complete set of ubi volumes that
> > are normally stored within the ubi partition on your device: typically
> > kernel (raw image), R/O rootfs (sqfs), and R/W overlay (ubifs). during
> > said sysupgrade, the current configuration is first copied to RAM, then
> > the ubi partition image is written, and finally -if current config is
> > kept- the RAM contents are written back to the new overlay volume.
> >
> > - ubinized sysupgrades were known to be broken by other people at the
> > time of my commits, and they wanted to remove the feature altogether
> > because it was unused (look it up in the relevant pull request for my
> > commits on github). as i remember it, it was broken because some ubi
> > volumes within the ubi partition were sometimes mounted or R/O block
> > devices were created on top of them (/dev/ubiblock*), locking the ubi
> > partition and preventing the upgrade.
> >
> > - although my devices would normally not use such upgrades, i could
> > still take a whole ubi partition backup and then test ubinized
> > sysupgrade with it on my devices. in fact, if you restore the ubi
> > partition image without conserving the current configuration, then this
> > procedure is the best way to do a backup/restore of the complete state
> > of the router: kernel, rootfs, and overlay are completely saved and
> > restored. btw, i think this should be documented. (and this is mostly
> > the reason why i added gzip support on sysupgrade: ubinized images of
> > backed-up ubi partitions compress like crazy.)
> >
> > - my tests of ubinized sysupgrade worked after these changes but not
> > before. specifically the fix is in: af34733593 base-files: fix ubinized
> > nand sysupgrade
> >
> >
> > regarding your log:
> >
> > - nand_do_platform_check succeeds:
> > https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L438-L469
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L192
> >
> > - next comes the actual nand_do_flash_file:
> > https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L379-L405
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2061
> >
> > - it is determined that passed file is a ubi partition image, so
> > nand_upgrade_ubinized is invoked:
> > https://github.com/openwrt/openwrt/blob/ac21dff5b67698c09f54a4b98d6f9f12af17edd4/package/base-files/files/lib/upgrade/nand.sh#L260-L269
> > https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2088
> >
> > nand_upgrade_ubinized is basically a one-liner:
> > ${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - && ubiattach
> > -m "$mtdnum"
> >
> > cat/zcat the image, feeding that to ubiformat -f - which writes it.
> >
> >
> > and the write does take place, but take a look:
> >
> > ---
> >
> > + cat /tmp/nandnew.ubi
> > + ubiformat /dev/mtd2 -y -f -
> > ubiformat: mtd2 (nand), size 250609664 bytes (239.0 MiB), 1912
> > eraseblocks of 131072 bytes (128.0 KiB), min. I/O size 2048 bytes
> >
> > libscan: scanning eraseblock 0 --  0 % complete
> > libscan: scanning eraseblock 1 --  0 % complete
> > libscan: scanning eraseblock 2 --  0 % complete
> > ...
> > libscan: scanning eraseblock 1868 -- 97 % complete
> >
> > libscan: scanning eraseblock
> > [  207.876200] ci_hdrc ci_hdrc.1: remove, state 1
> > 1869 -- 97 % complete
> >
> > libscan:
> > [  207.883339] usb usb2: USB disconnect, device number 1
> > scanning eraseblock 1870 -- 97 %
> > [  207.891238] usb 2-1: USB disconnect, device number 2
> > complete
> >
> > libscan: scanning eras
> > [  207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
> > eblock 1871 -- 97 % complete
> >
> >

Re: sysupgrade broken on imx nand targets (and maybe others too)

[Koen Vandeputte]

---
>
>
> while sysupgrade is flashing UBI the partition, the system is rebooted;
> i don't know why.
>
> here are the cleaned-up kernel messages:
>
> [  207.876200] ci_hdrc ci_hdrc.1: remove, state 1
> [  207.883339] usb usb2: USB disconnect, device number 1
> [  207.891238] usb 2-1: USB disconnect, device number 2
> [  207.901522] ci_hdrc ci_hdrc.1: USB bus 2 deregistered
> [  207.910396] ci_hdrc ci_hdrc.0: remove, state 4
> [  207.917055] usb usb1: USB disconnect, device number 1
> [  207.925651] ci_hdrc ci_hdrc.0: USB bus 1 deregistered
> [  207.934010] imx2-wdt 20bc000.watchdog: Device shutdown: Expect reboot!
> [  207.942382] reboot: Restarting system
>
>
> next the reboot takes place. u-boot mounts what it knows as mtd3 as an
> ubi partition:
> https://gist.github.com/Lanchon/f24ea9c16eda5ffaa5085a7b240238db#file-imx6dl-gw52xx-ubinized-sysupgrade-log-txt-L2183
>
> but openwrt used mtd2 to write to ubi, not mtd3. i don't know if in your
> device what openwrt calls mtd2 is called mtd3 by your current (default)
> u-boot config.
>
>
> so some takeaways...
>
> - something is rebooting the system while i write the sysupgrade image.
> maybe another thread? maybe an unattended watchdog?
>
> - the reboot happens while 98% of the image is written. maybe this issue
> is time dependent and only shows up with my code because it is a little
> slower than the previous code. maybe the previous code reached 100%
> before being rebooted and thus the upgrade went through.
>
> - the image *IS* written, albeit partially, which means that the
> previous image that was there is definitely erased. what is booted then?
> IDK, it depends on the details of your device. maybe it is booting a
> recovery image? or maybe the ubi partition format is not finished, but
> the ubi volumes within are fully written before the reboot, so the
> system doesn't brick by chance. (but then the newer image would be
> booted, but you say that the sysupgrade has no effect and the prior
> image is booted instead, so that can't be it.) maybe two ubi partitions
> are used on your device to implement an A/B dual system boot. so maybe a
> flag needs to be toggled to switch between A and B after the image is
> written, but since that code is never executed, the previous system is
> booted instead.
>
> - several issues cropped up with a set of sysupgrade changes i did
> (among them, these you mention here). there are many device types and
> several sysupgrade mechanisms with their own files, and then some common
> files. i assumed other types of upgrades would invoke common routines
> but not -for instance- nand flash routines. i was wrong: the codebase is
> spaghetti calling any file form any sysupgrade method, and this caused a
> couple of issues with my nand sysupgrade changes. i don't think this is
> one of those instances though. i think that the sysupgrade code is doing
> the right thing and the fault is elsewhere, but i may be wrong. without
> knowledge of your device and without a device to test, it is hard to tell.
>
>
> maybe we should could call the attention of the device maintainer to
> this thread now?
>
>
> thanks!
>
>

Hi,

Many thanks for the very detailed reply.
It aided hugely in debugging this further.

I'm happy to share that I found the culprit and it works nicely again now.

within nand.sh:


nand_upgrade_ubinized() {
local ubi_file="$1"
local gz="$2"

nand_detach_ubi "$CI_UBIPART" || return 1

local mtdnum="$( find_mtd_index "$CI_UBIPART" )"
${gz}cat "$ubi_file" | ubiformat "/dev/mtd$mtdnum" -y -f - &&
ubiattach -m "$mtdnum"
}

I changed the last line to:

ubiformat "/dev/mtd$mtdnum" -y -f "$ubi_file" && ubiattach -m "$mtdnum"


Although ubiformat indeed states "-f -" to use stdinput, it does not
seem to work.
Writing the image seemed to be simply skipped using that method.

actually presenting the absolute filepath to "-f" fixed it.

Any thoughts?

Thanks again for your prompt reply,

Koen




>
> On 1/23/23 12:37, Koen Vandeputte wrote:
> > Hi Rodrigo,
> >
> > After a long absence and now testing the latest master, I noticed that
> > imx nand flash sysupgrade was broken:
> >
> > expected behaviour:
> > - scan the nand
> > - write image
> > - format empty space
> > -reboot
> >
> > Seen behaviour:
> > - Scan the nand
> > - reboots
> >
> > I traced it back to this batch of commits by you:
> >
> > 9d1e687da3 base-files: verify nand sysupgrade images
> > 9710712120 base-files: accept gzipped nand sysupgrade images
> > af34733593 base-files: fix ubinized nand sysupgrade
> > e25e6d8e54 base-files: fix and clean up nand sysupgrade code
> >
> >
> > It can be easily confirmed by reverting /lib/upgrade/nand.sh with a
> > version before these commits are applied to it.
> >
> > I added a "set -x" to nand.sh to get more detailed logs:
> > https://pastebin.com/raw/yxY0SK1x
> >
> > Any idea?
> >
> > Thanks,
> >
> > Koen
>

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

sysupgrade broken on imx nand targets (and maybe others too)

[Koen Vandeputte]

Hi Rodrigo,

After a long absence and now testing the latest master, I noticed that
imx nand flash sysupgrade was broken:

expected behaviour:
- scan the nand
- write image
- format empty space
-reboot

Seen behaviour:
- Scan the nand
- reboots

I traced it back to this batch of commits by you:

9d1e687da3 base-files: verify nand sysupgrade images
9710712120 base-files: accept gzipped nand sysupgrade images
af34733593 base-files: fix ubinized nand sysupgrade
e25e6d8e54 base-files: fix and clean up nand sysupgrade code


It can be easily confirmed by reverting /lib/upgrade/nand.sh with a
version before these commits are applied to it.

I added a "set -x" to nand.sh to get more detailed logs:
https://pastebin.com/raw/yxY0SK1x

Any idea?

Thanks,

Koen

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

Dynack on ath10k

[Koen Vandeputte]

Hi Ben,

Early 2021, we discussed a bit regarding auto-distance using ath10k.
You mentioned back then that another party was working on that and they 
would release it as open source somewhere in Q3/Q4 of 2021.


Do you know the status regarding that?

If they do not intend to open-source it:

- Does ath10k expose any TSF (like ath9k) does which could be used for 
dynack?



Thanks,

Koen


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

Re: [PATCH] toolchain: musl: Update to version 1.2.3

[Koen Vandeputte]

Tested-by: Koen Vandeputte 

Tested on ath79 (mikrotik)


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

Re: [PATCH] base-files: call "sync" after initial setup

[Koen Vandeputte]

On 01.03.22 19:57, Hauke Mehrtens wrote:

On 3/1/22 18:46, Rafał Miłecki wrote:

From: Rafał Miłecki 

OpenWrt uses a lot of (b)ash scripts for initial setup. This isn't the
best solution as they almost never consider syncing files / data. Still
this is what we have and we need to try living with it.

Without proper syncing OpenWrt can easily get into an inconsistent state
on power cut. It's because:
1. Actual (flash) inode and data writes are not synchronized
2. Data writeback can take up to 30 seconds (dirty_expire_centisecs)
3. ubifs adds extra 5 seconds (dirty_writeback_centisecs) "delay"

Some possible cases (examples) for new files:
1. Power cut during 5 seconds after write() can result in all data loss
2. Power cut happening between 5 and 35 seconds after write() can result
    in empty file (inode flushed after 5 seconds, data flush queued)

Above affects e.g. uci-defaults. After executing some migration script
it may get deleted (whited out) without generated data getting actually
written. Power cut will result in missing data and deleted file.

There are three ways of dealing with that:
1. Rewriting all user-space init to proper C with syncs
2. Trying bash hacks (like creating tmp files & moving them)
3. Adding sync and hoping for no power cut during critical section

This change introduces the last solution that is the simplest. It
reduces time during which things may go wrong from ~35 seconds to
probably less than a second. Of course it applies only to IO operations
performed before /etc/init.d/boot . It's probably the stage when the
most new files get created.

All later changes are usually done using smarter C apps (e.g. busybox or
uci) that creates tmp files and uses rename() that is expected to be
atomic.

Signed-off-by: Rafał Miłecki 


Acked-by: Hauke Mehrtens 

This is not the best solution as you said but a simple one.

How do we handle the situation in the first boot when the overlay file 
system is not ready yet and we are in a ramdisk in the beginning?


Hauke


As a small addendum on this topic:

There is another way:

I also have issues with data loss on power cuts using ubifs since a few 
years now,

exactly as described above.

As in my usecase writes are only happening at the absolute minimum (the 
user changing a config setting), I 'solved' it by simply adding 
rootflags=sync to the kernel cmdline.


This seems to force immediate flushed to nand (at the cost of maybe a 
little bit faster wear) and reduced the issue with a huge factor.


In the past before this flag, it happened nearly every powercut that 
some file got corrupted.

after using this .. I can only recall a single case in roughly 3 years.


[    0.00] Kernel command line: console=ttymxc4,115200 ubi0:ubi 
ubi.mtd=2 rootfstype=squashfs,ubifs rootflags=sync pci=nomsi

[    2.298922] UBIFS: parse sync


Regards,

Koen


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

Re: [PATCH v2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD

[Koen Vandeputte]

On 19.01.22 11:50, Sergey Ryazanov wrote:

On Wed, Jan 19, 2022 at 1:25 PM Denis Kalashnikov  wrote:

On MikroTik RB91x board series a reset key shares SoC gpio
line #15 with NAND ALE and NAND IO7. So we need a custom
gpio driver to manage this non-trivial connection schema.
Also rb91x-nand needs to have an ability to disable a polling
of the key while it works with NAND.

While we've been integrating rb91x-key into a firmware, we've
figured out that:
* In the gpio-latch driver we need to add a "cansleep" suffix to
several gpiolib calls,
* When gpio-latch and rb91x-nand fail to get a gpio and an error
is -EPROBE_DEFER, they shouldn't report about this, since this
actually is not an error and occurs when the gpio-latch probe
function is called before the rb91x-key probe.
We fix these related things here too.

Signed-off-by: Denis Kalashnikov 

Reviewed-by: Sergey Ryazanov 



Works as advertised.
Pushed to master.

Thanks!

Koen


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

Re: [PATCH v2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD

[Koen Vandeputte]

On 19.01.22 11:25, Denis Kalashnikov wrote:

On MikroTik RB91x board series a reset key shares SoC gpio
line #15 with NAND ALE and NAND IO7. So we need a custom
gpio driver to manage this non-trivial connection schema.
Also rb91x-nand needs to have an ability to disable a polling
of the key while it works with NAND.

While we've been integrating rb91x-key into a firmware, we've
figured out that:
* In the gpio-latch driver we need to add a "cansleep" suffix to
several gpiolib calls,
* When gpio-latch and rb91x-nand fail to get a gpio and an error
is -EPROBE_DEFER, they shouldn't report about this, since this
actually is not an error and occurs when the gpio-latch probe
function is called before the rb91x-key probe.
We fix these related things here too.

Signed-off-by: Denis Kalashnikov 
---

Changelog:

v1 --> v2:
* Remove support for kernel 5.4,
* gpio-latch and rb91x-nand don't report about -EPROBE_DEFER.


This one is actually v3 :-)

No worries :y


Koen


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

ath10k_ct firmware crashes

[Koen Vandeputte]

Hi Ben,

After stress testing some wave 1 2x2 radios on multiple boards using 
openwrt master I noticed this crash on 2 of them.

Any idea?

01:00.0 Network controller: Qualcomm Atheros QCA986x/988x 802.11ac 
Wireless Network Adapter


Thanks,

Koen


[   16.441327] ath10k 5.15 driver, optimized for CT firmware, probing 
pci device: 0x3c.
[   16.468523] ath10k_pci :01:00.0: pci irq legacy oper_irq_mode 1 
irq_mode 0 reset_mode 0
[   17.719409] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043222ff sub 19b6:d042
[   17.728819] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 1 testmode 0
[   17.740820] ath10k_pci :01: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
[   18.063728] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[   18.993270] ath10k_pci :01:00.0: 10.1 wmi init: vdevs: 16 peers: 
127  tid: 256

[   19.011087] ath10k_pci :01:00.0: wmi print 'P 128 V 8 T 410'
[   19.017226] ath10k_pci :01:00.0: wmi print 'msdu-desc: 1424  
sw-crypt: 0 ct-sta: 0'
[   19.025374] ath10k_pci :01:00.0: wmi print 'alloc rem: 25000 
iram: 38944'
[   19.082086] ath10k_pci :01:00.0: htt-ver 2.2 wmi-op 2 htt-op 2 
cal file max-sta 128 raw 0 hwcrypto 1
[   19.097374] ath10k_pci :01:00.0: NOTE:  Firmware DBGLOG output 
disabled in debug_mask: 0x1000

[   19.228812] ath: EEPROM regdomain sanitized
[   19.228825] ath: EEPROM regdomain: 0x64
[   19.228830] ath: EEPROM indicates we should expect a direct regpair map
[   19.228849] ath: Country alpha2 being used: 00
[   19.228854] ath: Regpair used: 0x64
[   19.282229] usbcore: registered new interface driver option
[   19.288009] usbserial: USB Serial support registered for GSM modem 
(1-port)

[   19.318937] usbcore: registered new interface driver qcserial
[   19.324852] usbserial: USB Serial support registered for Qualcomm USB 
modem

[   19.342601] qcserial 2-1:1.0: Qualcomm USB modem converter detected
[   19.349298] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB0
[   19.359080] qcserial 2-1:1.2: Qualcomm USB modem converter detected
[   19.365777] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB1
[   19.389826] qcserial 2-1:1.3: Qualcomm USB modem converter detected
[   19.396484] usb 2-1: Qualcomm USB modem converter now attached to ttyUSB2
[   19.429616] kmodloader: done loading kernel modules from /etc/modules.d/*
[   26.341428] eth0: link up (1000Mbps/Full duplex)
[   26.346711] br-wan: port 1(eth0) entered blocking state
[   26.352077] br-wan: port 1(eth0) entered disabled state
[   26.357631] device eth0 entered promiscuous mode
[   26.375076] br-wan: port 1(eth0) entered blocking state
[   26.380431] br-wan: port 1(eth0) entered forwarding state
[   32.696768] ag71xx: max retries for SGMII fixup exceeded
[   32.702172] eth1: link up (1000Mbps/Full duplex)
[   32.727999] br-wan: port 2(eth1) entered blocking state
[   32.733310] br-wan: port 2(eth1) entered disabled state
[   32.738882] device eth1 entered promiscuous mode
[   32.808555] br-wan: port 2(eth1) entered blocking state
[   32.813867] br-wan: port 2(eth1) entered forwarding state
[   37.660591] EXT4-fs (sda1): mounted filesystem with ordered data 
mode. Opts: (null)
[   85.293759] ath10k_pci :01:00.0: 10.1 wmi init: vdevs: 16 peers: 
127  tid: 256

[   85.311655] ath10k_pci :01:00.0: wmi print 'P 128 V 8 T 410'
[   85.317869] ath10k_pci :01:00.0: wmi print 'msdu-desc: 1424  
sw-crypt: 0 ct-sta: 0'
[   85.326004] ath10k_pci :01:00.0: wmi print 'alloc rem: 25000 
iram: 38944'
[   85.398523] ath10k_pci :01:00.0: pdev param 0 not supported by 
firmware

[   85.413584] ath10k_pci :01:00.0: rts threshold -1
[   85.428114] device wlan0 entered promiscuous mode
[   85.435115] device wlan0 left promiscuous mode
[ 5578.497296] ath10k_pci :01:00.0: Failed to synchronize setup for 
vdev 0 restart 0: -145, will restart firmware
[ 5578.507831] ath10k_pci :01:00.0: failed to start vdev 0 addr 
00:00:00:00:00:00 on freq 5320: -145
[ 5578.518005] ath10k_pci :01:00.0: firmware crashed! (guid 
b696878d-15a0-434c-9d17-81052d629e31)
[ 5578.527126] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c 
chip_id 0x043222ff sub 19b6:d042
[ 5578.536571] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 
tracing 0 dfs 1 testmode 0
[ 5578.548738] ath10k_pci :01: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,regdump-CT,txrate-CT,flush-all-CT,pingpong-CT,ch-regs-CT,nop-CT,set-special-CT,get-temp-CT,tx-rc-CT,cust-stats-CT,retry-gt2-CT,txrate2-CT,beacon-cb-CT,wmi-block-ack-CT 
crc32 1b2a161c
[ 5578.578143] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A 
crc32 bebc7c08
[ 5578.585563] ath10k_pci :01:00.0: htt-ver 

Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD

[Koen Vandeputte]

On 17.01.22 09:51, Denis K wrote:

I'm seeing this in the bootlogs when using this patch:

[5.183305] gpio-latch gpio_latch: failed to get gpio 7: -517
[5.235889] rb91x-nand nand_gpio: failed to get gpios: -517

I still think this should be avoided somehow.

It's okay. The gpio-latch probe function seems to be called before the
rb91x-key probe, but it also returns  EPROBE_DEFER (-517), so it will
be called later. I've tested master with reset key patch and Koen's
patch that sets ref clock freq to 2500. All is working: nand,
leds, key and Gigabit Ethernet (setting 100 -- pings okay, setting
back 1000 -- pings still okay).

Should I delete from my rb91x-key patch support for kernel 5.4 and submit v2?

Please do :-)


Thanks,
Denis


Thanks!

Koen


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

Re: Custom thread names not working in htop anymore

[Koen Vandeputte]

On 11.01.22 12:55, Hannu Nyman wrote:

Koen Vandeputte wrote at Tue Jan 11 02:03:33 PST 2022:

> I noticed that custom thread names don't seem to work anymore these 
days.

> Htop got bumped recently but the issue still isn't fixed.
>
> This feature was very useful to check which thread consumes a lot of 
cpu

> during debugging applications.
>
> I think this got broken with the bump to a newer musl version as 
this is

> the only delta I haven't tested yet.
>
> Someone any idea?


Might be related to this upstream issue?


https://github.com/htop-dev/htop/issues/915



got it.

https://github.com/htop-dev/htop/issues/877

The workaround works too.


Koen


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

Re: ath79: MikroTik RB912UAG: not working Wi-Fi card in mPCIe slot

[Koen Vandeputte]

On 10.12.21 12:13, Denis K wrote:

Thomas Hühn  wrote:

We have 5 Mikrotik 912UAG in our Freifunk Network and just build and updated
them today with latest tunk .. we moved vom ar71xx to ath79 successfully,
so far so good .. thx for your upstream work!

The only thing that is not working: we can not get your 2nd wifi card in the
mPCIe port up and running. Only the USB Port is working. We have tried
several things to switch from USB to mPCIe .. without success:

* change the dts file ar9342_mikrotik_routerboard-912uag-2hpnd.dts in
   the gpio-export section to have usb_power output = 0 and pcie_power = 1
   mPCIe port is powered with 3,3V (measured on in 2 & 4) but mPCIe WiFi
   cards (ath9k - mikrotik) are not detected, tried to rescan the PCI bus
   as well
* change on a running 912UAG i the /sys/class/gpio/power_usb
   ../power-pcie/values ... not WiFi Card detection
* compare the running und working mPCIe port ar71xx image on the router ...
   found out there is gpio52 used, but different latch setup .. our good
   gues was that GPIO20 could be responsible for the usb switch for the mPCIe
   port .. add gpio20 to the export folder and set it to 1.. but no WiFi card
   detection

Who has some troubleshooting tips for how to disable the usb port and enable
the mPCIe port?

I've done some tests with RB912UAG-2HPnD and R11e-5HacT.
It seems that you need to set power-pcie gpio before pci controller
driver starts. Since it doesn't support hotplug or rescan (I suppose).
gpio-export starts after, so I've used this temporarily hack in ssr
node in dts (gpio-hog):

ssr: ssr@1 {
 compatible = "fairchild,74hc595";
 gpio-controller;
 #gpio-cells = <2>;
 registers-number = <1>;
 reg = <1>;
 spi-max-frequency = <5000>;

 power_pcie {
 gpio-hog;
 gpios = <7 0>;
 output-high;
 };

 power_usb {
 gpio-hog;
 gpios = <6 0>;
 output-low;
 };
};

root@OpenWrt:~# lspci
00:00.0 Class 0280: 168c:003c

This workaround works, but it is better to make pci rescan working.

power_usb and power_pcie gpio lines are on the Serial Shift Register (ssr).
It seems that RouterBoot left both =1. But SSR while init set them =0. Then
the PCI controller (arch/mips/pci-ar724x) starts... and says: "PCIe link is
down", remembers this in the internal link_up field and never re-check
AR724x_PCI_RESET_LINK_UP register bit. When link_up is false, pci read/write
handlers always return error. When I patched it to actually check link status
before reading, I had kernel panic with Device bus error when trying to read
Vendor ID from config register (see "MIPS: pci-ar724x: avoid data bus error
due to a missing PCIe module" Gabor Juhos patch). It seems that we need to
somehow reinit the PCI host controller.

Does anyone have any ideas?

Regards, Denis


Checking ar71xx code shows that this same issue is avoided
by simply putting the PCI init function at the bottom of the complete hw 
init sequence function.


So this workaround is fine for me as it's way better
to have working PCI today (and basically mimicing behaviour as done in 
ar71xx)

than no PCI at all out of "principle".

Let's use evolution here iso revolution. :-)

Regards,

Koen


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

Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD

[Koen Vandeputte]

On 10.12.21 23:04, Thomas Hühn wrote:

Hi all,

We have 5 Mikrotik 912UAG in our Freifunk Network and just build and updated 
them this week from ar71xx 2020 to latest tunk ath79...so far so cool.. all 
wifi routers mesh .. thx for the upstream work!

The first thing that was (is) not working: we can not get your 2nd wifi card in 
the mPCIe port up and running.. Denis provided a test patch to enable pcie 
early in the dts file .. works now… thx a mill!

Second issue:

5/5 of our productive Freifunk mesh  rb912uag  nodes are able to provide 1G 
Ethernet with the old ar71xx but not with current ath79 trunk … force a 
Ethernet speed downgrade to just 100M (ethtool -s eth0 advertise 0x008) works 
for 4/5 … 1 node does not even work with this… there is a 30m CAT5 ethernet 
cable between the  rb912uag mesh router and the first openwrt xiaomi 4A AP 
(Gigabit version) .. working properly under ar71xx with 1G … with ath79 trunk 
1G is not working and 100M is not working either… my guess is that the ethernet 
power for tx or rx or both is in ath79 different compared to ar71xx … so I 
would expect to find different register settings on ar71xx and ath79 for the 
ar8003 chip.. what do you think ? .. devmem2 read the register space from 
ar71xx und ath79 and compare ?

Greetings Thomas


Regarding ethernet --> Should be fixed

https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=f25bbb361f33dc92c70f601eb335d67b64f15f54


Please give my staging tree a try for that.

Thanks,

Koen


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

Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD

[Koen Vandeputte]

On 17.11.21 00:42, Sergey Ryazanov wrote:

On Tue, Nov 16, 2021 at 7:07 PM Denis Kalashnikov  wrote:

On MikroTik RB91x board series a reset key shares SoC gpio
line #15 with NAND ALE and NAND IO7. So we need a custom
gpio driver to manage this non-trivial connection schema.
Also rb91x-nand needs to have ability to disable a polling
of the key while it works with NAND, and we need to add
"cansleep" suffix to several gpiolib calls in gpio-latch.

Signed-off-by: Denis Kalashnikov 

Please find below one nonsignificant nitpick, in all other respects:

Reviewed-by: Sergey Ryazanov 


+struct gpio_rb91x_key {
+   struct gpio_chip gc;
+   struct mutex mutex;
+   struct mutex poll_mutex;

These mutexes are worth a line of documentation. I do not care too
much, but if by some other reason you will submit v3, please consider
to describe their purpose.


+   int polling_disabled;
+   struct gpio_desc *gpio;
+};



I'm seeing this in the bootlogs when using this patch:

[    5.183305] gpio-latch gpio_latch: failed to get gpio 7: -517
[    5.235889] rb91x-nand nand_gpio: failed to get gpios: -517


Thanks,

Koen


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

Re: [PATCH 1/3] generic: platform/mikrotik: make soft_config writable without 4K sectors

[Koen Vandeputte]

On 12.01.22 10:51, Koen Vandeputte wrote:


On 09.01.22 14:57, Sven Roederer wrote:

Am Dienstag, 21. Dezember 2021, 08:45:59 CET schrieb Oskari Lemmela:

Make soft_config writable in all cases. Performing soft_config commit
will fail if mtd partition is not writable.

Signed-off-by: Oskari Lemmela 
---
  .../drivers/platform/mikrotik/rb_softconfig.c   | 17 
+++--

  1 file changed, 3 insertions(+), 14 deletions(-)

diff --git
a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
index 070bd32d5a..31d06c423a 100644
--- 
a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
+++ 
b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c

@@ -59,20 +59,9 @@
  #define RB_SOFTCONFIG_VER  "0.03"
  #define RB_SC_PR_PFX   "[rb_softconfig] "

Oskari,

maybe also good to bump version to 0.04 .

Sven



I can do this when grabbing the patches.
I got the "reset key" series also in my staging which was also lacking 
the bump.


So i'll probably bump this one to 0.06 then.


correction: 0.05

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

Re: [PATCH 1/3] generic: platform/mikrotik: make soft_config writable without 4K sectors

[Koen Vandeputte]

On 09.01.22 14:57, Sven Roederer wrote:

Am Dienstag, 21. Dezember 2021, 08:45:59 CET schrieb Oskari Lemmela:

Make soft_config writable in all cases. Performing soft_config commit
will fail if mtd partition is not writable.

Signed-off-by: Oskari Lemmela 
---
  .../drivers/platform/mikrotik/rb_softconfig.c   | 17 +++--
  1 file changed, 3 insertions(+), 14 deletions(-)

diff --git
a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
index 070bd32d5a..31d06c423a 100644
--- a/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
+++ b/target/linux/generic/files/drivers/platform/mikrotik/rb_softconfig.c
@@ -59,20 +59,9 @@
  #define RB_SOFTCONFIG_VER  "0.03"
  #define RB_SC_PR_PFX   "[rb_softconfig] "

Oskari,

maybe also good to bump version to 0.04 .

Sven



I can do this when grabbing the patches.
I got the "reset key" series also in my staging which was also lacking 
the bump.


So i'll probably bump this one to 0.06 then.

Thanks!

Koen

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

Custom thread names not working in htop anymore

[Koen Vandeputte]

Hi,

I noticed that custom thread names don't seem to work anymore these days.
Htop got bumped recently but the issue still isn't fixed.

This feature was very useful to check which thread consumes a lot of cpu 
during debugging applications.


I think this got broken with the bump to a newer musl version as this is 
the only delta I haven't tested yet.


Someone any idea?

Regards,

Koen


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

Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD

[Koen Vandeputte]

On 10.12.21 16:14, Denis K wrote:

Mikrotik RB912UAG needs to be better supported in ath79, imho
and I'm working on it. Reset key, Gigabit Ethernet, mPCIe slot, UART
-- all need to be fixed. This patch adds support for reset key, next
one I'm working on will fix mPCIe slot. No ideas about how to fix
Gigabit, sigh.

Guys, please tell me what should I change in this patch to make
it useful for upstream?

Regards, Denis Kalashnikov



I'll check gigabit and pcie today.

I noticed yesterday on the latest master state that the board crashes 
with an oops (pcie driver) when a mini pcie wifi card is inserted.

This wasn't the case in the past.

I also gathered all board revisions here (on some of them, gigabit 
actually works) to check for a delta.



Checking ..

Koen


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

Re: [PATCH 21.02] mac80211: Update toversion 5.10.83

[Koen Vandeputte]

On 13.12.21 15:00, Hauke Mehrtens wrote:

On 12/13/21 2:16 PM, Koen Vandeputte wrote:


On 12.12.21 22:18, Hauke Mehrtens wrote:

The following patches were backported from upstream before and are not
needed any more:
package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch 

package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch 



Signed-off-by: Hauke Mehrtens 
---
  package/kernel/mac80211/Makefile  |  8 +--
  .../patches/ath/542-ath9k_debugfs_diag.patch  |  4 +-
  .../ath/551-ath9k_ubnt_uap_plus_hsr.patch |  4 +-
  .../ath/930-ath10k_add_tpt_led_trigger.patch  |  4 +-
  ...rolling-support-for-various-chipsets.patch | 14 +++---
  ...75-ath10k-use-tpt-trigger-by-default.patch |  2 +-
  ...980-ath10k-fix-max-antenna-gain-unit.patch | 49 
---

  ...-power-reduction-for-US-regulatory-d.patch |  8 +--
  .../100-remove-cryptoapi-dependencies.patch   | 10 ++--
  ...ort-immediate-reconnect-request-hint.patch |  2 +-
  ...-the-fwd_skb-dev-for-mesh-forwarding.patch |  2 +-
  ...t-access-the-IV-when-it-was-stripped.patch | 26 --
  ...-get_default_func-move-default-flow-.patch |  2 +-
  ...ot-maintain-a-backlog-sorted-list-of.patch |  2 +-
  ...add-rx-decapsulation-offload-support.patch | 18 +++
  ...le-QoS-support-for-nl80211-ctrl-port.patch |  6 +--
  ...pply-flow-control-on-management-fram.patch |  2 +-
  ...set-sk_pacing_shift-for-802.3-txpath.patch |  2 +-
  ...MPDU-session-check-from-minstrel_ht-.patch |  6 +--
  ...eee80211_tx_h_rate_ctrl-when-dequeue.patch |  8 +--
  ...te-control-support-for-encap-offload.patch |  2 +-
  ...rting-aggregation-sessions-on-mesh-i.patch |  2 +-
  ...introduce-aql_enable-node-in-debugfs.patch |  4 +-
  ...to-a-virtual-time-based-airtime-sche.patch |  6 +--
  ...eck-per-vif-offload_flags-in-Tx-path.patch |  2 +-
  ...nl80211-add-support-for-BSS-coloring.patch |  2 +-
  ...211-add-support-for-BSS-color-change.patch |  6 +--
  .../patches/subsys/400-allow-ibss-mixed.patch |  2 +-
  28 files changed, 65 insertions(+), 140 deletions(-)
  delete mode 100644 
package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch 

  delete mode 100644 
package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch 



Hi Hauke,

Something strange:
- This complete patch was based on 5.10.83 and upstreamed patches 
were removed
- it removes specifically this one:   delete mode 100644 
package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch 


- But this fix was only added in 5.10.84 ?


Hi Koen,

Sorry I forgot to update the patch subject line. This is based on 
kernel 5.10.84, I only saw this some minutes after sending the mail.


The patch for master is based on 5.15.7.

The tar.xz files are named correctly.

I anyway plan to release official backports tar.xz files and then use 
them in OpenWrt.


Hauke



No Worries :-)
Thanks for clearing this up and your hard work here!

Regards,

Koen


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

Re: [PATCH 21.02] mac80211: Update toversion 5.10.83

[Koen Vandeputte]

On 12.12.21 22:18, Hauke Mehrtens wrote:

The following patches were backported from upstream before and are not
needed any more:
   
package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch
   
package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch

Signed-off-by: Hauke Mehrtens 
---
  package/kernel/mac80211/Makefile  |  8 +--
  .../patches/ath/542-ath9k_debugfs_diag.patch  |  4 +-
  .../ath/551-ath9k_ubnt_uap_plus_hsr.patch |  4 +-
  .../ath/930-ath10k_add_tpt_led_trigger.patch  |  4 +-
  ...rolling-support-for-various-chipsets.patch | 14 +++---
  ...75-ath10k-use-tpt-trigger-by-default.patch |  2 +-
  ...980-ath10k-fix-max-antenna-gain-unit.patch | 49 ---
  ...-power-reduction-for-US-regulatory-d.patch |  8 +--
  .../100-remove-cryptoapi-dependencies.patch   | 10 ++--
  ...ort-immediate-reconnect-request-hint.patch |  2 +-
  ...-the-fwd_skb-dev-for-mesh-forwarding.patch |  2 +-
  ...t-access-the-IV-when-it-was-stripped.patch | 26 --
  ...-get_default_func-move-default-flow-.patch |  2 +-
  ...ot-maintain-a-backlog-sorted-list-of.patch |  2 +-
  ...add-rx-decapsulation-offload-support.patch | 18 +++
  ...le-QoS-support-for-nl80211-ctrl-port.patch |  6 +--
  ...pply-flow-control-on-management-fram.patch |  2 +-
  ...set-sk_pacing_shift-for-802.3-txpath.patch |  2 +-
  ...MPDU-session-check-from-minstrel_ht-.patch |  6 +--
  ...eee80211_tx_h_rate_ctrl-when-dequeue.patch |  8 +--
  ...te-control-support-for-encap-offload.patch |  2 +-
  ...rting-aggregation-sessions-on-mesh-i.patch |  2 +-
  ...introduce-aql_enable-node-in-debugfs.patch |  4 +-
  ...to-a-virtual-time-based-airtime-sche.patch |  6 +--
  ...eck-per-vif-offload_flags-in-Tx-path.patch |  2 +-
  ...nl80211-add-support-for-BSS-coloring.patch |  2 +-
  ...211-add-support-for-BSS-color-change.patch |  6 +--
  .../patches/subsys/400-allow-ibss-mixed.patch |  2 +-
  28 files changed, 65 insertions(+), 140 deletions(-)
  delete mode 100644 
package/kernel/mac80211/patches/ath/980-ath10k-fix-max-antenna-gain-unit.patch
  delete mode 100644 
package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch


Hi Hauke,

Something strange:
- This complete patch was based on 5.10.83 and upstreamed patches were 
removed
- it removes specifically this one:   delete mode 100644 
package/kernel/mac80211/patches/subsys/307-mac80211-do-not-access-the-IV-when-it-was-stripped.patch

- But this fix was only added in 5.10.84 ?

Regards,

Koen


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

Re: [PATCH v2 1/2] ath79: add support for reset key on MikroTik RB912UAG-2HPnD

[Koen Vandeputte]

On 10.12.21 16:14, Denis K wrote:

Mikrotik RB912UAG needs to be better supported in ath79, imho
and I'm working on it. Reset key, Gigabit Ethernet, mPCIe slot, UART
-- all need to be fixed. This patch adds support for reset key, next
one I'm working on will fix mPCIe slot. No ideas about how to fix
Gigabit, sigh.

Guys, please tell me what should I change in this patch to make
it useful for upstream?

Regards, Denis Kalashnikov



I missed these as I'm doing lots of stuff outside of OpenWRT the past 
few months.

Added to my staging tree.

Thanks,

Koen


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

Re: [PATCH 0/3] uqmi: sync libqmi and add more diagnostic commands;

[Koen Vandeputte]

On 08.11.21 09:36, Koen Vandeputte wrote:


On 24.10.21 17:05, Oskari Lemmela wrote:

First patch updates dynamic code generator to handle newer data from
libqmi project. After data is synced from libqmi project, more 
connection

diagnostic commands are added to uqmi.

Oskari Lemmela (3):
   uqmi: update code generator
   uqmi: sync data from libqmi project
   uqmi: add more diagnostics commands

  commands-nas.c    |  663 +++-
  commands-nas.h    |   10 +-
  commands-uim.c    |    8 +-
  commands-wda.c    |    3 +-
  commands-wds.c    |   16 +-
  commands-wds.h    |    2 +-
  data/gen-code.pl  |   11 +-
  data/gen-common.pm    |   10 +
  data/gen-error-list.pl    |    2 +-
  data/gen-header.pl    |    5 +-
  data/qmi-service-ctl.json |   40 +-
  data/qmi-service-dms.json |  533 +++---
  data/qmi-service-nas.json | 1703 +--
  data/qmi-service-oma.json |   52 +-
  data/qmi-service-pbm.json |   47 +-
  data/qmi-service-pds.json |  104 +-
  data/qmi-service-uim.json |  746 ++
  data/qmi-service-wda.json |  144 ++-
  data/qmi-service-wds.json | 2039 +
  data/qmi-service-wms.json |  218 ++--


I noticed the JSON files here seem edited compared to upstream to 
avoid following original compile issue:  (variables starting with a 
number)



/Tools/QMI/qmi-message-nas.h:820:19: error: invalid suffix 
"gpp_eons_plmn_name" on integer constant

  820 | } 3gpp_eons_plmn_name;
  |   ^~~

Maybe the perl scripts could be edited to simply prepend a "_" to 
these vars to avoid the problem.
This would allow to use unmodified upstream json files which is a lot 
less work to update it in the future.



Regards,

Koen



Patch proposal:


diff --git a/data/gen-common.pm b/data/gen-common.pm
index e951776..278afce 100644
--- a/data/gen-common.pm
+++ b/data/gen-common.pm
@@ -32,6 +32,7 @@ sub gen_cname($) {
 my $name = shift;

 $name =~ s/[^a-zA-Z0-9_]/_/g;
+    $name = "_${name}" if $name =~ /^\d/;
 return lc($name);
 }


Regards,

Koen


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

Re: [PATCH 0/3] uqmi: sync libqmi and add more diagnostic commands

[Koen Vandeputte]

On 24.10.21 17:05, Oskari Lemmela wrote:

First patch updates dynamic code generator to handle newer data from
libqmi project. After data is synced from libqmi project, more connection
diagnostic commands are added to uqmi.

Oskari Lemmela (3):
   uqmi: update code generator
   uqmi: sync data from libqmi project
   uqmi: add more diagnostics commands

  commands-nas.c|  663 +++-
  commands-nas.h|   10 +-
  commands-uim.c|8 +-
  commands-wda.c|3 +-
  commands-wds.c|   16 +-
  commands-wds.h|2 +-
  data/gen-code.pl  |   11 +-
  data/gen-common.pm|   10 +
  data/gen-error-list.pl|2 +-
  data/gen-header.pl|5 +-
  data/qmi-service-ctl.json |   40 +-
  data/qmi-service-dms.json |  533 +++---
  data/qmi-service-nas.json | 1703 +--
  data/qmi-service-oma.json |   52 +-
  data/qmi-service-pbm.json |   47 +-
  data/qmi-service-pds.json |  104 +-
  data/qmi-service-uim.json |  746 ++
  data/qmi-service-wda.json |  144 ++-
  data/qmi-service-wds.json | 2039 +
  data/qmi-service-wms.json |  218 ++--


I noticed the JSON files here seem edited compared to upstream to avoid 
following original compile issue:  (variables starting with a number)



/Tools/QMI/qmi-message-nas.h:820:19: error: invalid suffix 
"gpp_eons_plmn_name" on integer constant

  820 | } 3gpp_eons_plmn_name;
  |   ^~~

Maybe the perl scripts could be edited to simply prepend a "_" to these 
vars to avoid the problem.
This would allow to use unmodified upstream json files which is a lot 
less work to update it in the future.



Regards,

Koen


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

Re: OpenWrt imx split status?

[Koen Vandeputte]

On 05.10.21 17:42, Piotr Dymacz wrote:

Hi Tim,

On 04.10.2021 00:22, Tim Harvey wrote:

Piotr,

How is your progress regarding submitting patches to OpenWrt to split
the imx target into multiple arch related subtargets (like cortexa7,
cortexa9)?


I'm planning to clean it up and send patches this week.
I finally got final revision of the hardware I was working on that for.


Hi Piotr,

I've got this patch [1] lingering in my staging.
Is it still applicable after your patches?

Feel free to take it and include it in your series.

[1] 
https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=e678ae29e06b2feee81095da53a472652fba4f7c


Thanks,

Koen


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

Re: [PATCH] uqmi: Move to community packages repo

[Koen Vandeputte]

On 01.07.21 22:12, Arjun wrote:

On 02/07/21 1:36 am, David Bauer wrote:

[resend, as I've missed to keep the list CC'ed]

Hi Arjun

On 7/1/21 9:50 PM, Arjun AK wrote:

Signed-off-by: Arjun AK 




And just my personal opinion: While I think it makes sense to move 
optional packages to the packages feed, this is clearly a core 
functional dependency for multiple targets. We win absolutely nothing 
by moving it to packages, but lose the ability to build images 
providing seamless ootb internet connectivity without pulling in 
packages feed.


Just because a lot of packages were moved in the not-so-distant past 
means this has to be done to each and every packages in core.


Best
David


+1 for keeping it in the core




For now i would be happy with the patch titled "uim: add 
--uim-get-sim-state" be merged in.





I'm preparing a major update in the background (using libqmi 1.28.4 as 
source).

Hold on a little longer please.

Kind regards,

Koen


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

Re: imx6 - gateworks target broken

[Koen Vandeputte]

On 25.06.21 11:44, Piotr Dymacz wrote:

Hi Koen,

On 25.06.2021 11:04, Koen Vandeputte wrote:

Hi Piotr,

It seems imx6 Gateworks Ventana target got broken.

I suspect it's due to following commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8dba71dd33c8e35e7f363ffdb2ba42259ab43ce2 



After this commit, the bootfile generated is this one:

- 6x_bootscript-gateworks_ventana


While the bootloader looks for this:

Loading file '/6x_bootscript-ventana' to addr 0x1200...
** File not found /6x_bootscript-ventana **


Due to this, the fixup does not happen and wrong kernel params are
provided causing a panic as the rootfs is not found.

Any idea how to fix this one properly?
Revert the naming to plain "ventana" again?


Oh, I'm sorry for that!

I see that the 'script' var value is embedded in env [1] so probably 
the only correct way is to adjust it back on our side. Let me fix that 
as I also plan to send couple of patches with imx6 to imx split.


[1] 
https://source.denx.de/u-boot/u-boot/-/blob/master/include/configs/gw_ventana.h#L154



No worries :-)

Thanks for picking it up.

I'm currently using this patch to allow further testing:
https://git.openwrt.org/?p=openwrt/staging/xback.git;a=commit;h=e7b2714651ab8bbe3ff8518e18578a4e97cd

Regards,

Koen


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

imx6 - gateworks target broken

[Koen Vandeputte]

Hi Piotr,

It seems imx6 Gateworks Ventana target got broken.

I suspect it's due to following commit:
https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=8dba71dd33c8e35e7f363ffdb2ba42259ab43ce2

After this commit, the bootfile generated is this one:

- 6x_bootscript-gateworks_ventana


While the bootloader looks for this:

Loading file '/6x_bootscript-ventana' to addr 0x1200...
** File not found /6x_bootscript-ventana **


Due to this, the fixup does not happen and wrong kernel params are 
provided causing a panic as the rootfs is not found.


Any idea how to fix this one properly?
Revert the naming to plain "ventana" again?


Thanks,

Koen


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

Re: [PATCH 5/5] tegra: make target source-only

[Koen Vandeputte]

On 16.06.21 15:43, Tomasz Maciej Nowak wrote:

W dniu 15.06.2021 o 16:05, Koen Vandeputte pisze:

On 13.06.21 18:28, Tomasz Maciej Nowak wrote:

Looking at OpenWrt downloading statistics this target has non-existent
userbase apart from me. Mark it as source-only to skip the build by
buildbots and not waste further the resources.

Signed-off-by: Tomasz Maciej Nowak 
---

I'll keep this target in good condition in forseable future. If anyone
would suggest to drop the target, I'm not opposed.

I've been thinking for some time to try to support nvidia Jetson (and some 
carrier boards)

Great, finally someone interested in this niche target.


Yeah.

It pretty frustrating to see a lot of splats in different drivers which 
have already been solved long time ago ..
2nd reason is that the latest roadmap only mentions a kernel bump to 
5.10 in .. 2H 2022!  so it will stay on 4.9 for another year ..
Ubuntu 20.04 support is also scheduled for .. 04-2022 .. when the next 
LTS is released :sigh:
a 3rd reason is the size of the whole thing ..  It's pretty annoying to 
send an update of a few gigabytes over a 5mbps vsat link ..





as L4T is really .. really buggy and running way behind.

Looks like not much changed since Tegra 2 days.


Also some commonly used packages are also present in OpenWRT like gstreamer,  
opencv, ..

Hmm..., last time I checked NVIDIA usually only provided modified binaries for 
user-space.
In Tegra2&3 days they rarely published the sources of their changes, only 
compiled
libraries with headers, did it change since that time? Did they start to push 
their
implementations upstream?


No they don't, but I meant the framework is already present.
Due to this, adding hw accelerated will be very very difficult ... but 
it should be already possible to just get it working .. even if only CPU 
for now.


I'm looking at this as "another project" afterwards.




I was thinking to use this target as a guideline for trying to do that.

This would be similar split as in mvebu, where one subtarget would be armv7 and 
second one
a armv8. They probably won't share many drivers, but that's not much of a 
concern.
The boot procedure probably changed which means the SD card image structure 
also changed,
but that shouldn't be much of a problem.


Would you be interested?

Yes, I'll gladly help with it in any way I can.

cool!



Regards,

Koen


Regards.



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

Re: [PATCH 5/5] tegra: make target source-only

[Koen Vandeputte]

On 13.06.21 18:28, Tomasz Maciej Nowak wrote:

Looking at OpenWrt downloading statistics this target has non-existent
userbase apart from me. Mark it as source-only to skip the build by
buildbots and not waste further the resources.

Signed-off-by: Tomasz Maciej Nowak 
---

I'll keep this target in good condition in forseable future. If anyone
would suggest to drop the target, I'm not opposed.
I've been thinking for some time to try to support nvidia Jetson (and 
some carrier boards)

as L4T is really .. really buggy and running way behind.
Also some commonly used packages are also present in OpenWRT like 
gstreamer,  opencv, ..


I was thinking to use this target as a guideline for trying to do that.

Would you be interested?

Regards,

Koen


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

Re: [PATCH 3/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD

[Koen Vandeputte]

On 14.06.21 20:02, Adrian Schmutzler wrote:

Hi,

a few remaining comments below.


+   gpio-export {
+   compatible = "gpio-export";
+
+   usb_power {
+   label = "power:usb";

gpio-export nodes normally don't have a label property. We have 
gpio-export,name instead.

OK. Thanks



+   gpio-export,name = "power-usb";
+   gpio-export,output = <1>;
+   gpios = < 6 GPIO_ACTIVE_HIGH>;
+   };
+
+   pcie_power {
+   label = "power:pcie";
+   gpio-export,name = "power-pcie";
+   gpio-export,output = <0>;
+   gpios = < 7 GPIO_ACTIVE_HIGH>;
+   };
+   };
+};
+
+ {
+   status = "okay";
+
+   compatible = "qca,ar7100-spi";
+
+   cs-gpios = <0>, <_latch 0 GPIO_ACTIVE_LOW>;

I still don't think this belongs here. Why would it be the only device 
requiring this, while we removed it everywhere else?


+
+   flash@0 {
+   compatible = "jedec,spi-nor";
+   reg = <0>;
+   spi-max-frequency = <8000>;

Typically, speeds > 50 MHz require m25p,fast-read?
I checked datasheets for all revisions (carrying different NOR's) and 
80MHz was the lowest common for all.

This was also tested on all various boards.

But I do agree to play safe here and reduce to 50.
The performance impact is nearly 0 while avoiding issues on potential 
newer revisions later on.


Thanks for the insights.



Best

Adrian



@ Denis
I can adapt this right away in my staging tree if that's ok with you.



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

Re: [PATCH 0/3] ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD

[Koen Vandeputte]

On 27.05.21 10:16, Denis Kalashnikov wrote:

From: Denis Kalashnikov 

RB912 needs two ad hoc drivers: gpio-latch and rb91x_nand. So I've ported them
from ar71xx and added DTS.

In RFC v1 I added a MFD driver that provided API for manipulating shared gpio
lines to gpio-latch and nand drivers. In RFC v2 I just ported gpio-latch and
rb91x_nand drivers from ar71xx to ath79 by adding DTS support and usage of
a new gpio API (gpiod_*). This way is turned to be more clear and compact.
So, I've tried to fix what you guys advised me and here is my patches v1.

All seems to be working on my RB912UAG-2HPnD. Except a button and a beeper. The
beeper seems is not important thing, but the button is. The button shares gpio
15 with NAND ALE and NAND IO7, but this is not easily supported by the current
drivers. May be we need ad hoc driver for button. Or may be there is a more
general solution for this problem (like rb91x-gpio driver that arbitrates
all gpio lines instead of gpio-latch). This can be fixed in the next patches.

Denis Kalashnikov (3):
   ath79: add gpio-latch driver for MikroTik RouterBOARDs
   ath79: add NAND driver for MikroTik RB91xG series
   ath79: add support for MikroTik RouterBOARD 912UAG-2HPnD

  ...9342_mikrotik_routerboard-912uag-2hpnd.dts | 214 ++
  .../ath79/files/drivers/gpio/gpio-latch.c | 203 ++
  .../files/drivers/mtd/nand/raw/rb91x_nand.c   | 375 ++
  target/linux/ath79/image/mikrotik.mk  |   9 +
  .../base-files/etc/board.d/02_network |   2 +
  .../etc/hotplug.d/firmware/10-ath9k-eeprom|   1 +
  .../base-files/lib/upgrade/platform.sh|   1 +
  target/linux/ath79/mikrotik/config-default|   1 +
  .../patches-5.10/939-mikrotik-rb91x.patch |  49 +++
  .../patches-5.4/939-mikrotik-rb91x.patch  |  44 ++
  10 files changed, 899 insertions(+)
  create mode 100644 
target/linux/ath79/dts/ar9342_mikrotik_routerboard-912uag-2hpnd.dts
  create mode 100644 target/linux/ath79/files/drivers/gpio/gpio-latch.c
  create mode 100644 target/linux/ath79/files/drivers/mtd/nand/raw/rb91x_nand.c
  create mode 100644 target/linux/ath79/patches-5.10/939-mikrotik-rb91x.patch
  create mode 100644 target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch


Tested on the 5GHz flavor and works fine


Any other objections/remarks?
I will merge this otherwise tomorrow.

Thanks,

Koen




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

Re: [RFC v2 3/3] ath79: add support for Mikrotik RouterBoard 912G

[Koen Vandeputte]

On 23.05.21 11:01, Adrian Schmutzler wrote:

...

diff --git a/target/linux/ath79/image/mikrotik.mk
b/target/linux/ath79/image/mikrotik.mk
index 74f8603b5a..0072ec527d 100644
--- a/target/linux/ath79/image/mikrotik.mk
+++ b/target/linux/ath79/image/mikrotik.mk
@@ -9,6 +9,15 @@ define Device/mikrotik_routerboard-493g  endef
TARGET_DEVICES += mikrotik_routerboard-493g

+define Device/mikrotik_routerboard-912g
+  $(Device/mikrotik_nand)
+  SOC := ar9342
+  DEVICE_MODEL := RouterBOARD 912G
+  DEVICE_PACKAGES += kmod-usb-ehci kmod-usb2 kmod-gpio-beeper
+  SUPPORTED_DEVICES += rb-912uag-5hpnd rb-912uag-2hpnd endef

So, both have exactly the same setup as implemented here?

Best

Adrian


yes.

I personally use rb-912uag-5hpnd board.
The hardware is identical with the exception of the band used.

What's your 2 cents to get both supported using a single target?

Thanks,

Koen


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

Re: SquashFS mixed errors (decompression failed and others)

[Koen Vandeputte]

On 21.05.21 13:19, Ibrahim Tachijian wrote:

Hello,

We use approximately 10k IPQ40XX devices and we have noticed that
every time we run "sysupgrade -n" we lose approximately 1% of the
routers in the process.
After further investigation I'm almost confident that it is not the
sysupgrade process that is the culprit - so what I did was that I put
one test router into a reboot loop.

This is what I do;

Boot the router in a fresh state after a newly installed image.
The image contains a reboot loop that consists of a shell script that
runs every minute.

The shell script tries to run a php-script which simply echoes "Hello
World". If the php-script exists normally then we reboot the router.

However the php-script exists abnormally then the router stops and
does nothing other than informing me that there was a bus-error making
php not able to process the hello world script.

When this process runs the router reboots approximately 50 times
before it boots into a state which is faulty where I see bus-errors
when I try to run php scripts for example.


Looking into dmesg you can see some errors such as,

[10985.209438] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e
[11045.218685] SQUASHFS error: xz decompression failed, data probably corrupt
[11045.218731] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e
[11105.228157] SQUASHFS error: xz decompression failed, data probably corrupt
[11105.228203] SQUASHFS error: squashfs_read_data failed to read block 0x3a803e

or

[26218.687905] SQUASHFS error: Unable to read page, block 1b99a, size 10234
[26221.057472] SQUASHFS error: Unable to read data cache entry [1b99a]
[26221.057551] SQUASHFS error: Unable to read page, block 1b99a, size 10234
[26221.062926] SQUASHFS error: Unable to read data cache entry [1b99a]
[26221.069742] SQUASHFS error: Unable to read page, block 1b99a, size 10234
[26224.460239] SQUASHFS error: Unable to read data cache entry [1b99a]
[26224.460320] SQUASHFS error: Unable to read page, block 1b99a, size 10234

or

[62745.801178] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62773.347234] SQUASHFS error: xz decompression failed, data probably corrupt
[62773.347281] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62790.132661] SQUASHFS error: xz decompression failed, data probably corrupt
[62790.132706] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62790.216746] SQUASHFS error: xz decompression failed, data probably corrupt
[62790.216792] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62800.810525] SQUASHFS error: xz decompression failed, data probably corrupt
[62800.810570] SQUASHFS error: squashfs_read_data failed to read block 0x732ae2
[62828.336267] SQUASHFS error: xz decompression failed, data probably corrupt



Now, you would assume that the squashfs-partition is broken - but if
this was the case then a reboot should not help. It does.
Rebooting the router after it boots in this faulty state fixes the issue.

So approximately 1-2% of my reboots make the router go into this faulty state.

I am clueless on how to further investigate this issue. For now my
work around is restarting the router via a bash script should it
notice there are bus-errors or i/o errors.

Thanks


In the next kernel bump, following patch is also present:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v5.10.38=2ed1d90162a0c0683ecbe0c4802187fa22d641c3

I think it's worth a shot to retry the tests once it's bumped.

Koen


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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[Koen Vandeputte]

On 12.05.21 15:09, Bjørn Mork wrote:

Koen Vandeputte  writes:


Hi Bjørn

I can confirm the slot can also handle pcie signaling.
Got a rb912 board laying on my desk this very moment running an extra
ath9k pcie card :-)  (openwrt 19.07)

Thanks. Good to be wrong :-)


The slot is also advertised by MikroTik that it can do that.

Hmm, I could not find that.  But then again, that's probably just me
looking in the wrong places.


Bjørn



https://mikrotik.com/product/RB912UAG-5HPnD

"

The RB912UAG-5HPnD is a very versatile device.
It is a small wireless router with an integrated high power wireless 
card and an additional miniPCIe slot for 802.11 wireless, or 3G card.


"


Regards,

Koen


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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[Koen Vandeputte]

On 12.05.21 14:47, Bjørn Mork wrote:

Koen Vandeputte  writes:


I've fixed most of the open stuff, with the exception of using a PCIe
device in the slot. (checking currently what is wrong there)

Are you sure that's supported?  This is a slot intended only for LTE
modems, isn't it?

Looking at the picture at https://i.mt.lv/cdn/rb_images/884_hi_res.png I
can't see anything connecting to the PETn0/PETp0 pair.  There are
connections to the PERn0/PERp0 pair, but the traces do not look like
they're laid out for a PCIe differential pair. I suspect that's made for
some specific modem, using those pins for a debug UART. Like the Quectel
EC25:
https://forums.quectel.com/t/issue-in-interfacing-unilec-board-with-quectel-ec-25-e-mini-pcie-card/3057/5




Bjørn


Hi Bjørn

I can confirm the slot can also handle pcie signaling.
Got a rb912 board laying on my desk this very moment running an extra 
ath9k pcie card :-)  (openwrt 19.07)


The slot is also advertised by MikroTik that it can do that.

Here is a part of a rb912 bootlog, running in the field:


[   14.008974] ath: EEPROM regdomain: 0x0
[   14.008986] ath: EEPROM indicates default country code should be used
[   14.008990] ath: doing EEPROM country->regdmn map search
[   14.009008] ath: country maps to regdmn code: 0x3a
[   14.009014] ath: Country alpha2 being used: US
[   14.009018] ath: Regpair used: 0x3a
[   14.025334] ieee80211 phy0: Selected rate control algorithm 'minstrel_ht'
[   14.027550] ieee80211 phy0: Atheros AR9340 Rev:3 mem=0xb810, irq=47

[   14.034690] pci :00:00.0: using irq 40 for pin 1
[   14.039934] PCI: Enabling device :00:00.0 ( -> 0002)
[   14.054898] ath: EEPROM regdomain: 0x0
[   14.054906] ath: EEPROM indicates default country code should be used
[   14.054910] ath: doing EEPROM country->regdmn map search
[   14.054928] ath: country maps to regdmn code: 0x3a
[   14.054935] ath: Country alpha2 being used: US
[   14.054939] ath: Regpair used: 0x3a
[   14.068383] ieee80211 phy1: Selected rate control algorithm 'minstrel_ht'
[   14.070596] ieee80211 phy1: Atheros AR9300 Rev:4 mem=0xb000, irq=40


Regards,

Koen


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

Re: [PATCH 0/4] RFC: ath79: add support for Mikrotik RB91xG

[Koen Vandeputte]

Hi Denis,

I have high interest in this target device and wanted to provide some 
assistance if that's ok with you.
I've fixed most of the open stuff, with the exception of using a PCIe 
device in the slot. (checking currently what is wrong there)


Changes:
- dts cleanup
- Enabled USB
- Added required GPIO's for USB switching functionality (Type-A vs mini 
pcie slot)

- Added pcie device power gpio (default ON)
- Added kernel 5.10 support
- use maximum SPI speed compatible with any type/brand of EEPROM (Dual & 
Quad)

- use maximum SPI speed compatbile with any type/brand of SSR chip
- added beeper package

I also have different hw revisions of this board.
- Oldest revision: works as expected, also when booting from flash
- Newer revision: ethernet works when booting from ethernet, but not 
when booted from flash (interface is up, IP is set, but not able to ping 
it.)


I also have a board running latest RouterOS on it.
It seems it should be possible to also fetch Voltage and Temperature 
somewhere.


Do you have an update?

Thanks,
Kind regards,

Koen

On 06.05.21 18:35, John Crispin wrote:
interesting. I have a rb92xx on my desk and am wondering if this would 
also work ? after a brief glance at the code I think this might work. 
the rb92xx certainly has the same latch setup ...


    John

On 06.05.21 18:19, Denis Kalashnikov wrote:
When porting RB91xG ad hoc drivers (gpio-latch and rb91x-nand) from 
ar71xx
to ath79, I made a decision to rework this to more clear design in my 
opinion:

MFD driver that requests and controls the gpio lines, and separate NAND
driver and GPIO-latch driver that uses API of the MFD driver (like
how in rb4xx-clpd is done). ar71xx gpio-latch is very good, but 
somewhat hacky,
so I don't think that it can be general driver for gpio controller on 
a latch.
I could be wrong. Also it is my first attempt to port OpenWrt to a 
device, so
I need a review from the community. I've tested all these on my 
RB912UAG-2HPnD.
Gigabit Ethernet, 2.4GHz Wi-Fi, sysupgrade and LEDs:) are working for 
me.

Not working: beeper, button and USB port/mPCIe (has not tested yet).

Denis Kalashnikov (4):
   ath79: add MFD driver (NAND and GPIO) for Mikrotik RB91xG
   ath79: add GPIO-latch driver for Mikrotik RB91xG
   ath79: add NAND driver for Mikrotik RB91xG
   ath79: add support of Mikrotik RouterBoard 91xG series

  .../dts/ar9342_mikrotik_routerboard-912g.dts  | 314 +
  .../files/drivers/gpio/gpio-latch-rb91x.c | 127 +
  .../linux/ath79/files/drivers/mfd/rb91x-ngl.c | 331 ++
  .../files/drivers/mtd/nand/raw/nand_rb91x.c   | 432 ++
  .../linux/ath79/files/include/mfd/rb91x-ngl.h |  59 +++
  target/linux/ath79/image/mikrotik.mk  |   9 +
  .../base-files/etc/board.d/02_network |   2 +
  .../etc/hotplug.d/firmware/10-ath9k-eeprom    |   1 +
  .../base-files/lib/upgrade/platform.sh    |   1 +
  target/linux/ath79/mikrotik/config-default    |   3 +
  .../patches-5.4/939-mikrotik-rb91x.patch  |  65 +++
  11 files changed, 1344 insertions(+)
  create mode 100644 
target/linux/ath79/dts/ar9342_mikrotik_routerboard-912g.dts
  create mode 100644 
target/linux/ath79/files/drivers/gpio/gpio-latch-rb91x.c

  create mode 100644 target/linux/ath79/files/drivers/mfd/rb91x-ngl.c
  create mode 100644 
target/linux/ath79/files/drivers/mtd/nand/raw/nand_rb91x.c

  create mode 100644 target/linux/ath79/files/include/mfd/rb91x-ngl.h
  create mode 100644 
target/linux/ath79/patches-5.4/939-mikrotik-rb91x.patch




___
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

Re: [PATCH 4/4] ath79: add support of Mikrotik RouterBoard 91xG series

[Koen Vandeputte]

On 06.05.21 18:25, Denis Kalashnikov wrote:


What is not working:
  * USB port and mPCIe slot,
  * Beeper,

you will need to add kmod-gpio-beeper

+/*
+ * TODO list:
+ *   - Enable beeper/buzzer,
+ *   - Enable button/key,
+ *   - Enable usb EHCI and export GPIOs for
+ * turning on/off power for USB port and mPCIe slot,


fyi, The GPIO nr required for the USB target (USB type A or mini pcie 
slot) control is 61




+ *   - Test Wi-Fi working,
+ *   - Test Gigabit Ethernet working (see pll settings),
+ */
+
+/ {
+   compatible = "mikrotik,routerboard-912g";
+   model = "Mikrotik RB912G";
+};
+
+ {
+   /*
+* MFD: NAND plus GPIO-controller. They use/share SoC GPIO lines. Some 
of the
+* GPIO lines are multiplexed by a 8-bit latch (LVC573).
+* NAND is controlled by GPIO lines (bitbang), also some NAND control 
lines
+* (nCE, ALE, CLE, READ) and data lines are multiplexed by a latch. So 
driver
+* set control lines, enable latch ("latched them") and then transfer 
data.
+* Several lines of the latch (not used for NAND control lines) are used
+* as general-purpose GPIO. NAND ECC format is Mikrotik specific.
+*/
+   /*
+
+---+
+|  
 |
++-+ |  
 |
+| | |  
 |
+| | |  
 |
+| | |  
 |   3-4 lines
+| | |  
 +
+|   G |   8 lines   |  
 8-bit   |GPIO
+|   P +---+-+  
 |  (leds, SSR nCS)
+|   I |   | |  
 Latch   |
+|   O |   | |  
 |
+|   s |   | |  
 LVC573  |  4 lines
+| |   | |  
 +---+
+| |   | |  
 |   |
+| |   | |  
 |   |
+| |   | |  
 |   |
+| |   | |  
 |   |
+| |   | |  
 |   |
+| |   | 8   
+---+   |
+| |   |
 |
+| |   | l  
 |
+| |   | i  
 |
+|  SoC|   | n  
 |
+| |   | e  
 |
+| |   | s   
+--+|
+| |   | |  
||
+| |   | |   C  
||
+| |   | |  
| nCE, CLE, ALE, |
+| |   | |   O  
++
+| |   | | D
|   READ
+| |   | |   N  
|
+| |   | | A
|
+| |   | |  N  A  N  D   T  
|
+| |   +-+ T
|
+| | |   R  
| nRW, RDY
+| | | A
+--+
+| | |   O  
|  |
+| | |  
|  |
+| | |   L  
|  |
+| |  

Re: [PATCH 4/4] ath79: add support of Mikrotik RouterBoard 91xG series

[Koen Vandeputte]

On 06.05.21 18:25, Denis Kalashnikov wrote:


What is not working:
  * USB port and mPCIe slot,
  * Beeper,
  * Button,

+
+/* SoC Wi-Fi MAC managed by ath9k driver (RB912UAG-2HPnD) */
+ {
+   status = "okay";
+   /*
+* Wireless calibration data is in SPI NOR flash
+* hard_config partition. In OpenWrt you can also
+* read it from sysfs file
+* /sys/firmware/mikrotik/hard_config/wlan_data
+* from offset 0x1000
+* (/etc/hotplug.d/firmware/10-ath9k-eeprom script
+* does this).
+*/
+   qca,no-eeprom;
+};


Add the following here in the dts to enable USB controller (tested and 
working)



 {
    status = "okay";
};

_phy {
    status = "okay";
};



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

Re: ath79: mikrotik mac issue

[Koen Vandeputte]

Hi Roger,

I just confirmed that MAC's are properly set using master OpenWRT.
Will look into this.

I noticed you say this and OpenWRT master also shows it:

eth1: /sys/firmware/mikrotik/hard_config/mac_base
eth0: /sys/firmware/mikrotik/hard_config/mac_base+1
wlan0: /sys/firmware/mikrotik/hard_config/mac_base+2


I just checked on a fresh board using routerOS and it should be:

eth0: /sys/firmware/mikrotik/hard_config/mac_base
eth1: /sys/firmware/mikrotik/hard_config/mac_base+1 //SFP
wlan0: /sys/firmware/mikrotik/hard_config/mac_base+2


So the macs from Eth and SFP (eth1) need to be switched.

Regards,

Koen

On 18.04.21 19:00, Roger Pueyo Centelles wrote:

Hi,

Sorry, no clue. I am getting MAC addresses correctly assigned on a
MikroTik RB922UAGS-5HPacD running OpenWrt SNAPSHOT, r16574-f7e00d81bc.

As expected, random MAC addresses appear for both eth0 and eth1 on a
fresh boot after flashing with "sysupgrade -v -n. At around ~40 seconds
uptime, the network is activated with the correct MAC addresses enabled
(same as in /etc/config/network):

eth1: /sys/firmware/mikrotik/hard_config/mac_base
eth0: /sys/firmware/mikrotik/hard_config/mac_base+1
wlan0: /sys/firmware/mikrotik/hard_config/mac_base+2

The behaviour is correct on rebooting or reflashing.

Roger

El 16/4/21 a les 17:04, Koen Vandeputte ha escrit:

Hi all,

I found another interesting issue testing on a rb922
The board gets a random mac on each boot.

This is normal and should be automatically corrected by 02_network
afterwards when hard_config is available, but it seems it's not
getting applied correctly.
Debugging the 02_network script shows that the actual value is
properly fetched from hard_config, but it's not getting applied for
some reason ..
/etc/board.json shows the correct ones, but the interfaces still carry
the random MAC.

Judging by the flow in the script, I guess this issue will be present
on all ath79 Mikrotik targets.

Anyone got a clue?

Regards,

Koen



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

Re: ath79: mikrotik mac issue

[Koen Vandeputte]

Hi Roger,

An important detail:
I'm testing using kernel 5.10 :-)

Regards,

Koen

On 18.04.21 19:00, Roger Pueyo Centelles wrote:

Hi,

Sorry, no clue. I am getting MAC addresses correctly assigned on a
MikroTik RB922UAGS-5HPacD running OpenWrt SNAPSHOT, r16574-f7e00d81bc.

As expected, random MAC addresses appear for both eth0 and eth1 on a
fresh boot after flashing with "sysupgrade -v -n. At around ~40 seconds
uptime, the network is activated with the correct MAC addresses enabled
(same as in /etc/config/network):

eth1: /sys/firmware/mikrotik/hard_config/mac_base
eth0: /sys/firmware/mikrotik/hard_config/mac_base+1
wlan0: /sys/firmware/mikrotik/hard_config/mac_base+2

The behaviour is correct on rebooting or reflashing.

Roger

El 16/4/21 a les 17:04, Koen Vandeputte ha escrit:

Hi all,

I found another interesting issue testing on a rb922
The board gets a random mac on each boot.

This is normal and should be automatically corrected by 02_network
afterwards when hard_config is available, but it seems it's not
getting applied correctly.
Debugging the 02_network script shows that the actual value is
properly fetched from hard_config, but it's not getting applied for
some reason ..
/etc/board.json shows the correct ones, but the interfaces still carry
the random MAC.

Judging by the flow in the script, I guess this issue will be present
on all ath79 Mikrotik targets.

Anyone got a clue?

Regards,

Koen



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

ath79: mikrotik mac issue

[Koen Vandeputte]

Hi all,

I found another interesting issue testing on a rb922
The board gets a random mac on each boot.

This is normal and should be automatically corrected by 02_network 
afterwards when hard_config is available, but it seems it's not getting 
applied correctly.
Debugging the 02_network script shows that the actual value is properly 
fetched from hard_config, but it's not getting applied for some reason ..
/etc/board.json shows the correct ones, but the interfaces still carry 
the random MAC.


Judging by the flow in the script, I guess this issue will be present on 
all ath79 Mikrotik targets.


Anyone got a clue?

Regards,

Koen


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

Re: Regression: commit 2809d0000744 ("kernel: support FIT partition parser on mtdblock devices") breaks mtd-concat

[Koen Vandeputte]

On 12.04.21 17:31, Daniel Golle wrote:

On Mon, Apr 12, 2021 at 10:45:14PM +0800, DENG Qingfang wrote:

After the commit, devices with mtd-concat such as HC5962 no longer work.
Several "sysfs: cannot create duplicate filename '/devices/..." warnings
can be seen in kernel log.

I'm working on it, currently preparing to reproduce this be also
playing with mtd-concat.

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


Should it help :-)

https://pastebin.com/raw/d069j7wS

Koen


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

Upgrading Mikrotik RB922 (19.07 ar71xx -> 20.x ath79)

[Koen Vandeputte]

Hi all,

I'm playing around with Mikrotik stuff to test flashing from 19.07 
ar71xx towards master using sysupgrade.


Trying this natively using sysupgrade shows Invalid firmware image:


dd 
'if=/tmp/openwrt-ath79-mikrotik-mikrotik_routerboard-922uags-5hpacd-squashfs-sysupgrade.bin' 
'skip=0' 'bs=4' 'count=1'

+ identify_magic 73797375
+ local 'magic=73797375'
+ echo 'unknown 73797375'
+ local 'file_type=unknown 73797375'
+ '[' 0 '=' 0 -a 'unknown 73797375' '!=' ubi -a 'unknown 73797375' '!=' 
ubifs ]

+ echo 'Invalid sysupgrade file.'
Invalid sysupgrade file.

Looks like it trips over "file_type"

Anyone any idea how to fix this properly?

Thanks,

Koen


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

Re: [PATCH 19.07] kernel: Update kernel 4.14 to version 4.14.206

[Koen Vandeputte]

On 13.11.20 13:35, Adrian Schmutzler wrote:

-Original Message-
From: openwrt-devel [mailto:openwrt-devel-boun...@lists.openwrt.org]
On Behalf Of Josef Schlehofer
Sent: Freitag, 13. November 2020 09:33
To: openwrt-devel@lists.openwrt.org
Cc: Hauke Mehrtens 
Subject: [PATCH 19.07] kernel: Update kernel 4.14 to version 4.14.206

From: Hauke Mehrtens 

This is a security update as currently in OpenWrt 19.07, there is version
4.14.202 it means that it is vulnerable against vulnerability known as Sad DNS
(DNS cache poisoning). Since kernel 4.14.203, there is present mitigation to
this attack by randomizing ICMP global rate limit.

More details can be found here: https://www.saddns.net/

Compile and runtime tested on x86/64.
Also compile and run tested on all Turris devices (Turris 1.x - powerpc 8540,
Turris Omnia - mvebu/cortex-a9_vfpv3-d16, Turris MOX -
mvebu/aarch64_cortex-a53)

Signed-off-by: Hauke Mehrtens  (cherry picked from
commit 9cdc02be88d5c25791664b1baaf9a7c1a4382c95)
Signed-off-by: Josef Schlehofer  [added
commit message about run testing on Turris devices, added mention about
Sad DNS]


Did you just pick the patch or properly refresh patches again?

Best

Adrian



fwiw,

I took my .205 patch and bumped it again with .206
It's already in my staging tree and compile tests already executed.

Regards,

Koen


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

Re: Someone working on kernel 5.9?

[Koen Vandeputte]

On 29.10.20 13:20, Felix Fietkau wrote:

On 2020-10-29 13:11, Koen Vandeputte wrote:

On 29.10.20 11:37, Andrey Jr. Melnikov wrote:

Koen Vandeputte  wrote:


On 03.10.20 17:11, Vincent Wiemann wrote:

Hi folks,

is anybody working on 5.9, already?
I'd like to do some testing with io_uring on ath79 devices,
but the features needed require a version > 5.7.
Please let me know!

Not yet currently as I'm pretty occupied with AI stuff, but I might give
it a try within 1 .. 2 weeks.

before you start - in 5.8 kernel build process slightly changed, so openwrt
"build module first, kernel last" not working, vmlinux must be build before
modules now.
mtd subsystem partition code massive changed - mtdsplit drivers need rewrite.

Thanks,

I'll take a look at it.
I did encounter the mtdsplit stuff you mention.

Just swapped to 5.10-rc1 as it will be the next LTS.

I have 5.9 working on the mediatek target in my staging tree:
https://git.openwrt.org/?p=openwrt/staging/nbd.git;a=summary

- Felix


Even better!

I'll use it as a baseline towards 5.10.

Thanks Felix

Koen


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

Re: Someone working on kernel 5.9?

[Koen Vandeputte]

On 29.10.20 11:37, Andrey Jr. Melnikov wrote:

Koen Vandeputte  wrote:


On 03.10.20 17:11, Vincent Wiemann wrote:

Hi folks,

is anybody working on 5.9, already?
I'd like to do some testing with io_uring on ath79 devices,
but the features needed require a version > 5.7.
Please let me know!

Not yet currently as I'm pretty occupied with AI stuff, but I might give
it a try within 1 .. 2 weeks.

before you start - in 5.8 kernel build process slightly changed, so openwrt
"build module first, kernel last" not working, vmlinux must be build before
modules now.
mtd subsystem partition code massive changed - mtdsplit drivers need rewrite.


Thanks,

I'll take a look at it.
I did encounter the mtdsplit stuff you mention.

Just swapped to 5.10-rc1 as it will be the next LTS.

Regards,

Koen


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

Re: Someone working on kernel 5.9?

[Koen Vandeputte]

On 03.10.20 17:11, Vincent Wiemann wrote:

Hi folks,

is anybody working on 5.9, already?
I'd like to do some testing with io_uring on ath79 devices,
but the features needed require a version > 5.7.
Please let me know!

Best,

Vincent

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



Not yet currently as I'm pretty occupied with AI stuff, but I might give 
it a try within 1 .. 2 weeks.


Regards,

Koen


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

Re: [PATCH] iftop: fix compilation with GCC 10

[Koen Vandeputte]

On 17.07.20 11:56, Rosen Penev wrote:



On Jul 17, 2020, at 2:50 AM, Petr Štetiar  wrote:

Rosen Penev  [2020-07-13 22:43:51]:

Hi,


GCC 10 defaults to fno-common, which demains unique defenitions.

whats the exact error here? Wouldn't it make sense to move this into packages 
feed?

+1

No idea what this package is for or the reason for its presence here.


It's a ncurses based tool which shows how much bandwidth is going to a 
specific destination (shows the DNS name if there is one)


Pretty handy to check in realtime how much traffic is going to specific 
sites



What about upstream, looks like they might find this patch handy.

Seems relatively dead upstream. Last commit one year ago and second to last 
three years ago.

-- ynezz

___
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

Re: [OpenWrt-Devel] [PATCH] kernel: bump 5.4 to 5.4.47

[Koen Vandeputte]

On 18.06.20 10:52, Kevin 'ldir' Darbyshire-Bryant wrote:



On 18 Jun 2020, at 08:58, Koen Vandeputte  wrote:


On 18.06.20 08:50, Kevin Darbyshire-Bryant wrote:

Refreshed patches.

Run tested: x86/64 (apu2)

Signed-off-by: Kevin Darbyshire-Bryant 
---


I've got the bumps in my staging already sinds a day or 2 :-)


AFAIUI 5.4.47 was release 17 hours ago, a few hours after ynezz committed 
5.4.46 - I think.


ah right .. mine was .46

got to rebase again for the other bumps ..


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

Re: [OpenWrt-Devel] [PATCH] kernel: bump 5.4 to 5.4.47

[Koen Vandeputte]

On 18.06.20 08:50, Kevin Darbyshire-Bryant wrote:

Refreshed patches.

Run tested: x86/64 (apu2)

Signed-off-by: Kevin Darbyshire-Bryant 
---



I've got the bumps in my staging already sinds a day or 2 :-)


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

[OpenWrt-Devel] cns3xxx and kernel 5.4

[Koen Vandeputte]

Hi All,

I've tried to bump this target to kernel 5.4 but failed to do so twice.

This target is not DT aware at all and the amount of efforts required to 
do so are tremendous, which I cannot justify internally here.



Giving the facts that:

- The huge amount of effort required

- The SoC itself reached EoL at Cavium for some time now.

- Upstream removed some important parts as it's also slowly getting EoL 
over there


- Internally in the company here, the product that used this will fade 
out shortly


- The amount of download for this binary suggest that the target is not 
that popular



I have decided to not invest more time in this one myself.

I would like to propose to either remove it for the next release, or 
make it source-only for some time excluded from the builds


should someone else would like to invest more time in it.


Either way, this target is the last one without 5.4 support and it 
should not delay the process any further.


Regards,

Koen


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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750

[Koen Vandeputte]

On 28.05.20 04:42, luochong...@gl-inet.com wrote:

Hi Koen,

I'm really sorry that I missed your previous email.

Tried sysupgrade --> results in platform_check failure.
In the original device naming convention, E750 was named glinet,gl-e750
However, in today's openwrt, the name of the device is glinet_gl-e750, 
so platform_check failure is prompted.
You'd better use uboot to upgrade your firmware, follow the link below 
for the uboot upgrade steps

https://docs.gl-inet.com/en/3/troubleshooting/debrick/

this device also only has 1 ethernet port exposed on the board.
Yes, the E750 has only one ethernet port,
In E750, we only use GMAC0, but in ATH79 target, I had to initialize 
P4 via GMAC1 connected to the Ethernet switch, so you'll see eth0 and 
eth1 on your system.
I have tried to use GMAC0 to initialize P4 directly, but after 
initializing P4 in this way, the speed of P4 can only be 100M, not 
100M/10M.




*/Best Regards/*



Hi Chongjun,


Thanks for the details.


Could you send a V3 to ensure ethernet is working?

Currently, there seems to be a mismatch and I suspect the wrong eth is 
being assigned with an IP.



Basically, the device is totally unreachable with the current patchset.


Thanks for your efforts,


Koen


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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750

[Koen Vandeputte]

On 27.05.20 15:33, Koen Vandeputte wrote:


On 07.05.20 13:46, Luochongjun wrote:

The gl-e750 is a portable travel router that gives you safe access to
the internet while traveling.

Specifications:
- SoC: Qualcomm Atheros AR9531 (650MHz)
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND (GD5F1GQ4UFYIG)
- Ethernet: 10/100: 1xLAN
- Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac)
- USB: 1x USB 2.0 port
- Switch: 1x switch
- Button: 1x reset button
- OLED Screen: 128*64 px

Flash instruction:
Support for sysupgrade directive upgrades, as well as luci upgrades.


Hi,

I retested this patch just to be sure I didn't miss anything before.


Did you test this patch on actual hardware before sending this?

I've got 2x e750-Mudi devices which:

- I first flashed to the latest Gl.inet firmware (18.06 based) (works 
fine)


- Tried sysupgrade --> results in platform_check failure

- Tried forced sysupgrade --> does not boot afterwards

- Tried uboot recovery (both sysupgrade and factory images) --> does 
not boot



Using gl.inet official img, the uboot recovery mode works fine.

Thanks,

Koen



I just soldered UART to the board.

Ethernet is not coming up properly.

relevant prints:


[    0.551090] libphy: Fixed MDIO Bus: probed
[    0.872975] ag71xx 1900.eth: Could not connect to PHY device. 
Deferring probe.
[    0.881098] ag71xx 1a00.eth: invalid MAC address, using random 
address

[    1.139873] random: fast init done
[    1.520295] libphy: ag71xx_mdio: probed
[    1.525811] libphy: ar8xxx-mdio: probed
[    1.538905] switch0: Atheros AR8229 rev. 1 switch registered on mdio.0
[    1.587451] ag71xx 1a00.eth: connected to PHY at fixed-0:00 
[uid=, driver=Generic PHY]

[    1.597499] eth0: Atheros AG71xx at 0xba00, irq 5, mode: gmii
[    1.605610] NET: Registered protocol family 10
[    1.614929] Segment Routing with IPv6
[    1.618900] NET: Registered protocol family 17
[    1.623601] 8021q: 802.1Q VLAN Support v1.8
[    1.631247] PCI host bridge /ahb/pcie-controller@180c ranges:
[    1.637642]  MEM 0x1000..0x13ff
[    1.643057]   IO 0x..0x
[    1.648655] PCI host bridge to bus :00
[    1.652937] pci_bus :00: root bus resource [mem 
0x1000-0x13ff]

[    1.660051] pci_bus :00: root bus resource [io  0x]
[    1.665824] pci_bus :00: root bus resource [??? 0x flags 0x0]
[    1.672845] pci_bus :00: No busn resource found for root bus, 
will use [bus 00-ff]
[    1.682374] pci :00:00.0: BAR 0: assigned [mem 
0x1000-0x101f 64bit]
[    1.690010] pci :00:00.0: BAR 6: assigned [mem 
0x1020-0x1020 pref]
[    2.013961] ag71xx 1900.eth: connected to PHY at mdio.0:1f:04 
[uid=004dd042, driver=Generic PHY]

[    2.024473] eth1: Atheros AG71xx at 0xb900, irq 4, mode: mii

[   10.293731] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[   11.325088] eth0: link up (1000Mbps/Full duplex)

[   11.329934] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

[   17.716093] eth0: link down


this device also only has 1 ethernet port exposed on the board.

Regards,

Koen


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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750

[Koen Vandeputte]

On 07.05.20 13:46, Luochongjun wrote:

The gl-e750 is a portable travel router that gives you safe access to
the internet while traveling.

Specifications:
- SoC: Qualcomm Atheros AR9531 (650MHz)
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND (GD5F1GQ4UFYIG)
- Ethernet: 10/100: 1xLAN
- Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac)
- USB: 1x USB 2.0 port
- Switch: 1x switch
- Button: 1x reset button
- OLED Screen: 128*64 px

Flash instruction:
Support for sysupgrade directive upgrades, as well as luci upgrades.


Hi,

I retested this patch just to be sure I didn't miss anything before.


Did you test this patch on actual hardware before sending this?

I've got 2x e750-Mudi devices which:

- I first flashed to the latest Gl.inet firmware (18.06 based) (works fine)

- Tried sysupgrade --> results in platform_check failure

- Tried forced sysupgrade --> does not boot afterwards

- Tried uboot recovery (both sysupgrade and factory images) --> does not 
boot



Using gl.inet official img, the uboot recovery mode works fine.

Thanks,

Koen



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

Re: [OpenWrt-Devel] Targets without 5.4 support yet

[Koen Vandeputte]

On 25.05.20 13:11, Zoltan HERPAI wrote:

Hi,

On 5/25/2020 12:42, m...@adrianschmutzler.de wrote:

Hi all,

while there has been a lot of progress during the last months, there 
are still a few target that have not been updated to 5.4 (at least as 
testing kernel) yet:


4.19:
cns3xxx

4.14:
ar71xx (to be removed)
arc770 (RFT patch: 
https://patchwork.ozlabs.org/project/openwrt/patch/20200413103352.7429-1-freif...@adrianschmutzler.de/)

at91
ath25 (patchset crashing at Ethernet init: 
https://patchwork.ozlabs.org/project/openwrt/list/?series=169991)

pistachio
rb532
samsung
uml

This is meant as an invitation for those caring about/using these 
targets to consider updating them; in best case they should receive 
some testing before a 5.4 stable branch is made (whenever that might 
be).


At least for the 4.14 targets, I expect them to be archived if there 
is no update until after the next release (or at the latest after the 
one following it).


I'm working on bringing pistachio up to 5.4, apart from the spi-nand 
(which is quite a core item obviously, so I thought about reaching out 
to Boris for some guidance) it's looking good so far. If anyone's 
interested in helping, I'll share what I have. Also, if there is no 
one else interested in cns3xxx, I'm happy to take a look at that, I've 
got two devboards in the shed for that.


Regards,
Zoltan H

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


cns3xxx is scheduled later this week, but help is certainly welcome.

I managed to do most of the required changes, but was stuck currently on 
the new "GPIO descriptor" stuff. (for GPS PPS)


Regards,

Koen


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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750

[Koen Vandeputte]

On 07.05.20 13:46, Luochongjun wrote:

The gl-e750 is a portable travel router that gives you safe access to
the internet while traveling.

Specifications:
- SoC: Qualcomm Atheros AR9531 (650MHz)
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND (GD5F1GQ4UFYIG)
- Ethernet: 10/100: 1xLAN
- Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac)
- USB: 1x USB 2.0 port
- Switch: 1x switch
- Button: 1x reset button
- OLED Screen: 128*64 px

Flash instruction:
Support for sysupgrade directive upgrades, as well as luci upgrades.



Warning: Permanently added '192.168.8.1' (RSA) to the list of known hosts.


BusyBox v1.28.3 () built-in shell (ash)

  ___     __
 |   |.-.-.-.|  |  |  |..|  |_
 |   -   ||  _  |  -__| ||  |  |  ||   _||   _|
 |___||   __|_|__|__||||__|  ||
  |__| W I R E L E S S   F R E E D O M
 -
 OpenWrt 18.06.1, r7258-5eb055306f
 -
=== WARNING! =
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--
root@GL-E750:~# cd /tmp/
root@GL-E750:/tmp# sysupgrade -n 
/tmp/openwrt-ath79-nand-glinet_gl-e750-squashfs

-sysupgrade.bin
Device gl-e750 not supported by this image
Supported devices: glinet,gl-e750
Image check 'fwtool_check_image' failed.
root@GL-E750:/tmp#


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

Re: [OpenWrt-Devel] [PATCH] ath79: add support for gl-e750

[Koen Vandeputte]

On 07.05.20 13:46, Luochongjun wrote:

The gl-e750 is a portable travel router that gives you safe access to
the internet while traveling.

Specifications:
- SoC: Qualcomm Atheros AR9531 (650MHz)
- RAM: 128 MB DDR2
- Flash: 16 MB SPI NOR (W25Q128FVSG) + 128 MB SPI NAND (GD5F1GQ4UFYIG)
- Ethernet: 10/100: 1xLAN
- Wireless: QCA9531 2.4GHz (bgn) + QCA9887 5GHz (ac)
- USB: 1x USB 2.0 port
- Switch: 1x switch
- Button: 1x reset button
- OLED Screen: 128*64 px
- Serial: TX pin marked as UART-SOUT, located near the switch (115200 
8N1, 3V3 level)


- Mobile: Quectel EP06-E in mini pci-e slot, USB 2.0 connected


Correct?


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

Re: [OpenWrt-Devel] [PATCH 0/3] mac80211: Update to version 5.7-rc2

[Koen Vandeputte]

On 21.04.20 23:22, Hauke Mehrtens wrote:

This updates mac80211 in OpenWrt to version 5.7-rc2.
This update contains ath11k and many other ieee80211ax updates.
ath11k only works on the ipq807x devices.

I tried to start a discussion how we want to go forward with the
wireless subsystem we ship in the next OpenWrt release:
https://lists.infradead.org/pipermail/openwrt-devel/2020-March/022198.html

I would prefer if we apply this to master and then continuously update
to match more recent kernel versions till we are at an LTS kernel
version. I assume that the kernel 5.9 or 5.10 will be the next LTS
version. Using a normal kernel release as a base will make providing
(security) updates much harder.


Hi Hauke,

It seems I missed that one.

+1 for option 4
I'm also in favor of avoiding non-LTS stuff as it puts pressure on 
timely updates.
It allows bleeding edge stuff while being still (more easily) 
maintainable when a release moves to maintenance.


Regards,

Koen



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

Re: [OpenWrt-Devel] Quick question regarding Octeon-tx

[Koen Vandeputte]

On 09.03.20 20:18, Koen Vandeputte wrote:

Hi Tim,

I was compile-testing the 5.4 bump on OcteonTx and found a missing 
symbol for it:



kvdp@kvdp-BRIX:~/git/openwrt_staging/target$ grep -r "CGROUP_HUGETLB"
linux/generic/config-4.14:# CONFIG_CGROUP_HUGETLB is not set
linux/octeontx/config-4.14:CONFIG_CGROUP_HUGETLB=y

Looks like it was set enabled for OcteonTx in 4.14

Is it still a requirement for this target in 5.4?

Thanks,

Koen



Please ignore.

It seems it was caused due to lack of disk space during compile testing.

Full download & re-compile didn't trigger it again.


Koen


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

[OpenWrt-Devel] Quick question regarding Octeon-tx

[Koen Vandeputte]

Hi Tim,

I was compile-testing the 5.4 bump on OcteonTx and found a missing 
symbol for it:



kvdp@kvdp-BRIX:~/git/openwrt_staging/target$ grep -r "CGROUP_HUGETLB"
linux/generic/config-4.14:# CONFIG_CGROUP_HUGETLB is not set
linux/octeontx/config-4.14:CONFIG_CGROUP_HUGETLB=y

Looks like it was set enabled for OcteonTx in 4.14

Is it still a requirement for this target in 5.4?

Thanks,

Koen


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

Re: [OpenWrt-Devel] [PATCH] octeontx: add support for Linux 5.4

[Koen Vandeputte]

On 06.03.20 18:44, Koen Vandeputte wrote:


On 06.03.20 16:55, Tim Harvey wrote:
On Wed, Feb 26, 2020 at 12:40 PM Tim Harvey  
wrote:

Signed-off-by: Tim Harvey 
---
  target/linux/octeontx/config-5.4   | 634 
+

  ...nderx-use-proper-interface-type-for-RGMII.patch |  47 ++
  ...hunderx-workaround-BGX-TX-Underflow-issue.patch | 150 +
  ...03-can-mcp251x-convert-to-half-duplex-SPI.patch |  51 ++
  ...rk-for-Gateworks-PLX-PEX860x-switch-with-.patch |  64 +++
  5 files changed, 946 insertions(+)
  create mode 100644 target/linux/octeontx/config-5.4
  create mode 100644 
target/linux/octeontx/patches-5.4/0001-net-thunderx-use-proper-interface-type-for-RGMII.patch
  create mode 100644 
target/linux/octeontx/patches-5.4/0002-net-thunderx-workaround-BGX-TX-Underflow-issue.patch
  create mode 100644 
target/linux/octeontx/patches-5.4/0003-can-mcp251x-convert-to-half-duplex-SPI.patch
  create mode 100644 
target/linux/octeontx/patches-5.4/0004-PCI-add-quirk-for-Gateworks-PLX-PEX860x-switch-with-.patch


diff --git a/target/linux/octeontx/config-5.4 
b/target/linux/octeontx/config-5.4

new file mode 100644
index 000..524279f
--- /dev/null
+++ b/target/linux/octeontx/config-5.4
@@ -0,0 +1,634 @@
+CONFIG_64BIT=y
+CONFIG_64BIT_TIME=y
+# CONFIG_ARCH_AGILEX is not set
+# CONFIG_ARCH_BITMAIN is not set
+CONFIG_ARCH_CLOCKSOURCE_DATA=y
+CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
+CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
+CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
+CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y
+CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
+CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
+CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
+CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
+CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
+CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
+CONFIG_ARCH_HAS_KCOV=y
+CONFIG_ARCH_HAS_KEEPINITRD=y
+CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
+CONFIG_ARCH_HAS_PTE_DEVMAP=y
+CONFIG_ARCH_HAS_PTE_SPECIAL=y
+CONFIG_ARCH_HAS_SETUP_DMA_OPS=y
+CONFIG_ARCH_HAS_SET_DIRECT_MAP=y
+CONFIG_ARCH_HAS_SET_MEMORY=y
+CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
+CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
+CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y
+CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
+CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y
+CONFIG_ARCH_HAS_TICK_BROADCAST=y
+CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
+CONFIG_ARCH_HIBERNATION_HEADER=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_INLINE_READ_LOCK=y
+CONFIG_ARCH_INLINE_READ_LOCK_BH=y
+CONFIG_ARCH_INLINE_READ_LOCK_IRQ=y
+CONFIG_ARCH_INLINE_READ_LOCK_IRQSAVE=y
+CONFIG_ARCH_INLINE_READ_UNLOCK=y
+CONFIG_ARCH_INLINE_READ_UNLOCK_BH=y
+CONFIG_ARCH_INLINE_READ_UNLOCK_IRQ=y
+CONFIG_ARCH_INLINE_READ_UNLOCK_IRQRESTORE=y
+CONFIG_ARCH_INLINE_SPIN_LOCK=y
+CONFIG_ARCH_INLINE_SPIN_LOCK_BH=y
+CONFIG_ARCH_INLINE_SPIN_LOCK_IRQ=y
+CONFIG_ARCH_INLINE_SPIN_LOCK_IRQSAVE=y
+CONFIG_ARCH_INLINE_SPIN_TRYLOCK=y
+CONFIG_ARCH_INLINE_SPIN_TRYLOCK_BH=y
+CONFIG_ARCH_INLINE_SPIN_UNLOCK=y
+CONFIG_ARCH_INLINE_SPIN_UNLOCK_BH=y
+CONFIG_ARCH_INLINE_SPIN_UNLOCK_IRQ=y
+CONFIG_ARCH_INLINE_SPIN_UNLOCK_IRQRESTORE=y
+CONFIG_ARCH_INLINE_WRITE_LOCK=y
+CONFIG_ARCH_INLINE_WRITE_LOCK_BH=y
+CONFIG_ARCH_INLINE_WRITE_LOCK_IRQ=y
+CONFIG_ARCH_INLINE_WRITE_LOCK_IRQSAVE=y
+CONFIG_ARCH_INLINE_WRITE_UNLOCK=y
+CONFIG_ARCH_INLINE_WRITE_UNLOCK_BH=y
+CONFIG_ARCH_INLINE_WRITE_UNLOCK_IRQ=y
+CONFIG_ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE=y
+CONFIG_ARCH_KEEP_MEMBLOCK=y
+CONFIG_ARCH_MMAP_RND_BITS=18
+CONFIG_ARCH_MMAP_RND_BITS_MAX=33
+CONFIG_ARCH_MMAP_RND_BITS_MIN=18
+CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
+CONFIG_ARCH_PROC_KCORE_TEXT=y
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ARCH_SPARSEMEM_DEFAULT=y
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
+CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
+CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
+CONFIG_ARCH_SUPPORTS_INT128=y
+CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
+CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
+CONFIG_ARCH_SUPPORTS_UPROBES=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARCH_THUNDER=y
+CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
+CONFIG_ARCH_USE_MEMREMAP_PROT=y
+CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
+CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
+CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y
+CONFIG_ARCH_WANT_FRAME_POINTERS=y
+CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
+CONFIG_ARM64=y
+# CONFIG_ARM64_16K_PAGES is not set
+CONFIG_ARM64_4K_PAGES=y
+# CONFIG_ARM64_64K_PAGES is not set
+CONFIG_ARM64_CNP=y
+CONFIG_ARM64_CONT_SHIFT=4
+CONFIG_ARM64_CRYPTO=y
+CONFIG_ARM64_ERRATUM_1165522=y
+CONFIG_ARM64_ERRATUM_1286807=y
+CONFIG_ARM64_ERRATUM_819472=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_826319=y
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_843419=y
+CONFIG_ARM64_HW_AFDBM=y
+# CONFIG_ARM64_LSE_ATOMICS is not set
+CONFIG_ARM64_MODULE_PLTS=y
+CONFIG_ARM64_PAGE_SHIFT=12
+CONFIG_ARM64_PAN=y
+CONFIG_ARM64_PA_BITS=48
+CONFIG_ARM64_PA_BITS_48=y
+# CONFIG_ARM64_PMEM is not set
+# CONFIG_ARM64_PSEUDO_NMI is not set
+# CONFIG_ARM64_PTDUMP_DEBUGFS is not set
+CONFIG_ARM64_PTR_AUTH=y
+# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET

Re: [OpenWrt-Devel] [PATCH] octeontx: add support for Linux 5.4

[Koen Vandeputte]

On 06.03.20 16:55, Tim Harvey wrote:

On Wed, Feb 26, 2020 at 12:40 PM Tim Harvey  wrote:

Signed-off-by: Tim Harvey 
---
  target/linux/octeontx/config-5.4   | 634 +
  ...nderx-use-proper-interface-type-for-RGMII.patch |  47 ++
  ...hunderx-workaround-BGX-TX-Underflow-issue.patch | 150 +
  ...03-can-mcp251x-convert-to-half-duplex-SPI.patch |  51 ++
  ...rk-for-Gateworks-PLX-PEX860x-switch-with-.patch |  64 +++
  5 files changed, 946 insertions(+)
  create mode 100644 target/linux/octeontx/config-5.4
  create mode 100644 
target/linux/octeontx/patches-5.4/0001-net-thunderx-use-proper-interface-type-for-RGMII.patch
  create mode 100644 
target/linux/octeontx/patches-5.4/0002-net-thunderx-workaround-BGX-TX-Underflow-issue.patch
  create mode 100644 
target/linux/octeontx/patches-5.4/0003-can-mcp251x-convert-to-half-duplex-SPI.patch
  create mode 100644 
target/linux/octeontx/patches-5.4/0004-PCI-add-quirk-for-Gateworks-PLX-PEX860x-switch-with-.patch

diff --git a/target/linux/octeontx/config-5.4 b/target/linux/octeontx/config-5.4
new file mode 100644
index 000..524279f
--- /dev/null
+++ b/target/linux/octeontx/config-5.4
@@ -0,0 +1,634 @@
+CONFIG_64BIT=y
+CONFIG_64BIT_TIME=y
+# CONFIG_ARCH_AGILEX is not set
+# CONFIG_ARCH_BITMAIN is not set
+CONFIG_ARCH_CLOCKSOURCE_DATA=y
+CONFIG_ARCH_DMA_ADDR_T_64BIT=y
+CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
+CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
+CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
+CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
+CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
+CONFIG_ARCH_HAS_DMA_COHERENT_TO_PFN=y
+CONFIG_ARCH_HAS_DMA_PREP_COHERENT=y
+CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
+CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
+CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
+CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
+CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
+CONFIG_ARCH_HAS_KCOV=y
+CONFIG_ARCH_HAS_KEEPINITRD=y
+CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
+CONFIG_ARCH_HAS_PTE_DEVMAP=y
+CONFIG_ARCH_HAS_PTE_SPECIAL=y
+CONFIG_ARCH_HAS_SETUP_DMA_OPS=y
+CONFIG_ARCH_HAS_SET_DIRECT_MAP=y
+CONFIG_ARCH_HAS_SET_MEMORY=y
+CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
+CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
+CONFIG_ARCH_HAS_SYNC_DMA_FOR_CPU=y
+CONFIG_ARCH_HAS_SYNC_DMA_FOR_DEVICE=y
+CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y
+CONFIG_ARCH_HAS_TICK_BROADCAST=y
+CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
+CONFIG_ARCH_HIBERNATION_HEADER=y
+CONFIG_ARCH_HIBERNATION_POSSIBLE=y
+CONFIG_ARCH_INLINE_READ_LOCK=y
+CONFIG_ARCH_INLINE_READ_LOCK_BH=y
+CONFIG_ARCH_INLINE_READ_LOCK_IRQ=y
+CONFIG_ARCH_INLINE_READ_LOCK_IRQSAVE=y
+CONFIG_ARCH_INLINE_READ_UNLOCK=y
+CONFIG_ARCH_INLINE_READ_UNLOCK_BH=y
+CONFIG_ARCH_INLINE_READ_UNLOCK_IRQ=y
+CONFIG_ARCH_INLINE_READ_UNLOCK_IRQRESTORE=y
+CONFIG_ARCH_INLINE_SPIN_LOCK=y
+CONFIG_ARCH_INLINE_SPIN_LOCK_BH=y
+CONFIG_ARCH_INLINE_SPIN_LOCK_IRQ=y
+CONFIG_ARCH_INLINE_SPIN_LOCK_IRQSAVE=y
+CONFIG_ARCH_INLINE_SPIN_TRYLOCK=y
+CONFIG_ARCH_INLINE_SPIN_TRYLOCK_BH=y
+CONFIG_ARCH_INLINE_SPIN_UNLOCK=y
+CONFIG_ARCH_INLINE_SPIN_UNLOCK_BH=y
+CONFIG_ARCH_INLINE_SPIN_UNLOCK_IRQ=y
+CONFIG_ARCH_INLINE_SPIN_UNLOCK_IRQRESTORE=y
+CONFIG_ARCH_INLINE_WRITE_LOCK=y
+CONFIG_ARCH_INLINE_WRITE_LOCK_BH=y
+CONFIG_ARCH_INLINE_WRITE_LOCK_IRQ=y
+CONFIG_ARCH_INLINE_WRITE_LOCK_IRQSAVE=y
+CONFIG_ARCH_INLINE_WRITE_UNLOCK=y
+CONFIG_ARCH_INLINE_WRITE_UNLOCK_BH=y
+CONFIG_ARCH_INLINE_WRITE_UNLOCK_IRQ=y
+CONFIG_ARCH_INLINE_WRITE_UNLOCK_IRQRESTORE=y
+CONFIG_ARCH_KEEP_MEMBLOCK=y
+CONFIG_ARCH_MMAP_RND_BITS=18
+CONFIG_ARCH_MMAP_RND_BITS_MAX=33
+CONFIG_ARCH_MMAP_RND_BITS_MIN=18
+CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=11
+CONFIG_ARCH_PROC_KCORE_TEXT=y
+CONFIG_ARCH_SELECT_MEMORY_MODEL=y
+CONFIG_ARCH_SPARSEMEM_DEFAULT=y
+CONFIG_ARCH_SPARSEMEM_ENABLE=y
+CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
+CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
+CONFIG_ARCH_SUPPORTS_INT128=y
+CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
+CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
+CONFIG_ARCH_SUPPORTS_UPROBES=y
+CONFIG_ARCH_SUSPEND_POSSIBLE=y
+CONFIG_ARCH_THUNDER=y
+CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
+CONFIG_ARCH_USE_MEMREMAP_PROT=y
+CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
+CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
+CONFIG_ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT=y
+CONFIG_ARCH_WANT_FRAME_POINTERS=y
+CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
+CONFIG_ARM64=y
+# CONFIG_ARM64_16K_PAGES is not set
+CONFIG_ARM64_4K_PAGES=y
+# CONFIG_ARM64_64K_PAGES is not set
+CONFIG_ARM64_CNP=y
+CONFIG_ARM64_CONT_SHIFT=4
+CONFIG_ARM64_CRYPTO=y
+CONFIG_ARM64_ERRATUM_1165522=y
+CONFIG_ARM64_ERRATUM_1286807=y
+CONFIG_ARM64_ERRATUM_819472=y
+CONFIG_ARM64_ERRATUM_824069=y
+CONFIG_ARM64_ERRATUM_826319=y
+CONFIG_ARM64_ERRATUM_827319=y
+CONFIG_ARM64_ERRATUM_843419=y
+CONFIG_ARM64_HW_AFDBM=y
+# CONFIG_ARM64_LSE_ATOMICS is not set
+CONFIG_ARM64_MODULE_PLTS=y
+CONFIG_ARM64_PAGE_SHIFT=12
+CONFIG_ARM64_PAN=y
+CONFIG_ARM64_PA_BITS=48
+CONFIG_ARM64_PA_BITS_48=y
+# CONFIG_ARM64_PMEM is not set
+# CONFIG_ARM64_PSEUDO_NMI is not set
+# CONFIG_ARM64_PTDUMP_DEBUGFS is not set
+CONFIG_ARM64_PTR_AUTH=y
+# CONFIG_ARM64_RANDOMIZE_TEXT_OFFSET is not set
+CONFIG_ARM64_SSBD=y

Re: [OpenWrt-Devel] RFT: Add support for kernel 5.4

[Koen Vandeputte]

On 28.02.20 18:22, Ansuel Smith wrote:


Hi All,

After a lot of hard work from many people involved, I'm very
pleased to
announce
initial support for kernel 5.4 has been pushed to master with
already a
nice amount
of available targets.

If you are interested, feel free to test, send fixes or send
patches for
supporting 5.4 on other targets besides the ones mentioned below.

All supported targets have been provided with kernel 5.4 as the
"Testing
kernel".
This means you can enable 5.4 by selecting "Global --> use the
testing
kernel version" within menuconfig.


*Big fat warning*

While a ton of effort has been conducted, trying to prevent mayhem
and
fixing as many bugs as possible,
support for 5.4 is still considered to be experimental at this point
until extended testing has been conducted.

If you would like to try it, please make sure you are able to debrick
your device if required.
If you still try it without any way of debricking it, you are
doing so
*at your own risk*


Following targets are currently available and have been runtime
tested:

- apm821xx
- ath79
- bcm53xx
- imx6
- ipq40xx
- mediatek
- mpc85xx
- x86_64

Completely untested but provided as a baseline:

- ipq807x


Following targets are near completion and should be added
hopefully next
week:

- cns3xxx
- octeontx


Kind Regards,

Koen


___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org

https://lists.openwrt.org/mailman/listinfo/openwrt-devel


Ipq806x is pretty much done and I think can be pushed as a testing 
kernel, should I create a PR on GitHub?



Yes please.


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

[OpenWrt-Devel] RFT: Add support for kernel 5.4

[Koen Vandeputte]

Hi All,

After a lot of hard work from many people involved, I'm very pleased to 
announce
initial support for kernel 5.4 has been pushed to master with already a 
nice amount

of available targets.

If you are interested, feel free to test, send fixes or send patches for 
supporting 5.4 on other targets besides the ones mentioned below.


All supported targets have been provided with kernel 5.4 as the "Testing 
kernel".
This means you can enable 5.4 by selecting "Global --> use the testing 
kernel version" within menuconfig.



*Big fat warning*

While a ton of effort has been conducted, trying to prevent mayhem and 
fixing as many bugs as possible,
support for 5.4 is still considered to be experimental at this point 
until extended testing has been conducted.


If you would like to try it, please make sure you are able to debrick 
your device if required.
If you still try it without any way of debricking it, you are doing so 
*at your own risk*



Following targets are currently available and have been runtime tested:

- apm821xx
- ath79
- bcm53xx
- imx6
- ipq40xx
- mediatek
- mpc85xx
- x86_64

Completely untested but provided as a baseline:

- ipq807x


Following targets are near completion and should be added hopefully next 
week:


- cns3xxx
- octeontx


Kind Regards,

Koen


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

Re: [OpenWrt-Devel] ath79: NAND bad eraseblocks in MikroTik RouterBOARD 922UAGS-5HPacD

[Koen Vandeputte]

Hi Roger,

Can you send me full bootlogs please from both?

I have RB922-5HPnD, not the AC version over here, but I guess the issue 
will also be present over there.


Thanks again,

Koen

On 27.01.20 15:16, Roger Pueyo Centelles | Guifi.net via openwrt-devel 
wrote:

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.

___
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

Re: [OpenWrt-Devel] 19.07.0 boot hang on Mikrotik device

[Koen Vandeputte]

On 27.01.20 17:14, Joe Ayers wrote:

You should report this bug under "openwrt-19.07":
https://bugs.openwrt.org/

You are apparently using ar71xx, did you try an ath79 19.07 image?

the first mikrotik device in ath79 was merged to master last week, so ath79 is 
not an option here ATM.

Best

Adrian


Regards,
Baptiste


The devices with this issue aren't supported with Openwrt images yet
:) .   Thus, submitting a defect may be problematic.   I've added a
few definitions on top of the openwrt "Mikrotik LHG 5" to add support
(and hopefully I can find the time to submit an openwrt PR).  There
are 3 devices with exact same motherboard "LHG 2nD" and same behavior
going from 18.06.2 to 19.07.0:

LDF 2nD
LHG 2nD
LHG 2nD-XL

I have narrowed down the problem.  By removing "40_run_failsafe_hook",
procd completes as expected.   Something seems to be triggering
failsafe mode and blocking procd.   If anyone knows what might have
changed or where to fix the root cause, would appreciate any
information to save time.   I'll dig a little more...

Joe AE6XE


I'm also a bit worried when seeing this:

[0.133043] ar71xx: invalid MDIO id 1

Koen


On 25-01-20, Joe Ayers wrote:

At http:\\arednmesh.org, we've had several mikrotik devices working,
all with "LHG" motherboards.   One of the devices, RB LHG 2nD-XL no
longer boots with upgrade from 18.06.2 to 19.07.0.  Other devices with
same "LHG" mother board continue to work fine, e.g. RB LHG 5nD-XL, LHG
5nDHP.

I'm stuck on getting this working, if you have any pointers, please
let me know.Here's dmesg where it hangs:


___
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

Re: [OpenWrt-Devel] [PATCH 19.07] mac80211: update to version 4.19.85

[Koen Vandeputte]

Tested on ~10 devices. IBSS and AP/STA

Tested-by: Koen Vandeputte 


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

Re: [OpenWrt-Devel] v5.4 as next kernel

[Koen Vandeputte]

On 29.10.19 06:37, John Crispin wrote:

Hi,
should we use v5.4 as our next kernel ?
John



From my point of view: yes
I also really like the cadence of just following LTS release schedule 
which doesn't enforce a hard deadline to do major bumps or risking 
drying up of fixes from Stable



Lots of stuff gets backported when newer kernels arrive, so maybe avoid 
that effort and invest it in just bumping the whole thing
I often hear from people around me that OpenWrt looks like a "garbage 
bin of files" due to all custom patches

This would be one way to reduce the amount ..

Still a lot of targets are on 4.14, we might as well just bump then to 
5.4 iso of first to 4.19 to eventually get to 5.4


By the time 19.07 will be released, 5.4 will probably be on our doorstep 
and I don't see us make another major release within 1 .. 2 months after 
19.07


Using mac80211 from a newer kernel seems to work well, but judging by 
the amount of changes in Hauke's updates
seems to indicate it's a lot more work if the gap between kernel and 
mac80211 versions widens up.



It's OK to be mainstream, but it's a lot more motivating (and fun!) to 
be bleeding edge.


Koen


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

Re: [OpenWrt-Devel] Hang on setting $PROMPT in master

[Koen Vandeputte]

On 21.10.19 17:04, Martin Tippmann wrote:

We are using a shell-function to set the prompt based on return code -
it works fine in 17.01 / 18.06 / 19.07, however in current master when
the function is run the terminal/ssh session hangs.

how to reproduce:



<--- hang.sh:
#!/bin/sh


You could add following line here to check where it hangs:

set -x


prompt_set() {
face() {
 local rc=$?
 case "$rc" in
0) printf '%s' "$1" ;;
*) printf '%s' "$2" ; return $rc ;;
   esac
}

local e='\[\e' # start escape-sequence
local c='\]' # close escape-sequence

local user='\u'
local wdir='\w' # workdir
local host='\h' # short form

 local reset="${e}[0m${c}" # all attributes
 local white="${e}[37m${c}"
 local cyan="${e}[36m${c}"
 local yellow="${e}[33;1m${c}" # bold
 local green="${e}[32m${c}"
 local red="${e}[31m${c}"

 local ok="${green}:)"
 local bad="${red}8("

# e.g. user@hostname:~ :)
export PS1="${cyan}${user}$white@${green}$host:${yellow}$wdir \$(
face '$ok' '$bad' ) $reset"
}

prompt_set
-->

now source the file:

. ./hang.sh

shellcheck does not complain - I'm writing because I'm not sure wether
this invalid sh that happened to work anyway or is this a
bug/regression in ash?

regards
Martin

___
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

Re: [OpenWrt-Devel] [PATCH 1/2] imx6: bootscript: enable UBI fastmap support

[Koen Vandeputte]

On 04.10.19 14:30, Koen Vandeputte wrote:


On 03.10.19 00:21, Tim Harvey wrote:

UBI Fastmap support is stable in the 4.4 kernel so lets take
advantage of it to shave off 5-10 seconds of boot time.

Signed-off-by: Tim Harvey 
---
  target/linux/imx6/image/bootscript-ventana | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/linux/imx6/image/bootscript-ventana 
b/target/linux/imx6/image/bootscript-ventana

index 941afb5..8451caf 100644
--- a/target/linux/imx6/image/bootscript-ventana
+++ b/target/linux/imx6/image/bootscript-ventana
@@ -1,4 +1,4 @@
-echo "Gateworks Ventana OpenWrt Boot script v1.01"
+echo "Gateworks Ventana OpenWrt Boot script v1.02"
    # set some defaults
  # set some defaults
@@ -51,6 +51,8 @@ if itest.s "x${dtype}" == "xnand" ; then
  echo "mtdparts:${mtdparts}"
  setenv fsload ubifsload
  setenv root "ubi0:ubi ubi.mtd=2 rootfstype=squashfs,ubifs"
+    # enable UBI fastmap support
+    setenv bootargs "${bootargs} ubi.fm_autoconvert=1"
  else
  echo "Booting from block device ${bootdev}..."
  setenv fsload "${fs}load ${dtype} ${disk}:1"


Hi Tim,

Shouldn't this patch also enable the required kernel symbol? 
(MTD_UBI_FASTMAP)


Next to that, even in kernel 4.19 I'm reading following regarding this 
feature:


Important: this feature is experimental so far and the on-flash │
format for fastmap may change in the next kernel versions


Hi Richard,

Apologies for dragging you in here.

How stable is this fastmap format?

Will it leave Experimental state in the near future?


Thanks,

Koen



I'm also seeing this warning:


[    0.00] Kernel command line: console=ttymxc1,115200 ubi0:ubi 
ubi.mtd=2 rootfstype=squashfs,ubifs ubi.fm_autoconvert=1


[    2.356304] ubi0: default fastmap pool size: 95
[    2.360850] ubi0: default fastmap WL pool size: 47
[    2.365684] ubi0: attaching mtd2
[    2.551317] random: crng init done
[    2.786708] ubi0: scanning is finished

[    2.795380] ubi0 warning: ubi_eba_init: cannot reserve enough PEBs 
for bad PEB handling, reserved 38, need 40        <---


[    2.806651] ubi0: attached mtd2 (name "ubi", size 239 MiB)
[    2.812151] ubi0: PEB size: 131072 bytes (128 KiB), LEB size: 126976 
bytes

[    2.819051] ubi0: min./max. I/O unit sizes: 2048/2048, sub-page size 2048
[    2.825855] ubi0: VID header offset: 2048 (aligned 2048), data 
offset: 4096

[    2.832825] ubi0: good PEBs: 1912, bad PEBs: 0, corrupted PEBs: 0
[    2.838937] ubi0: user volume: 3, internal volumes: 1, max. volumes 
count: 128
[    2.846175] ubi0: max/mean erase counter: 4/1, WL threshold: 4096, 
image sequence number: 1659699605
[    2.855327] ubi0: available PEBs: 0, total reserved PEBs: 1912, PEBs 
reserved for bad PEB handling: 38

[    2.864657] ubi0: background thread "ubi_bgt0d" started, PID 826
[    2.871496] block ubiblock0_1: created from ubi0:1(rootfs)
[    2.877025] ubiblock: device ubiblock0_1 (rootfs) set to be root 
filesystem



It doesn't seem to be a coincidence that it's missing 2 PEB's while 
fastmap uses 2 of them



Koen


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

Re: [OpenWrt-Devel] [PATCH 1/2] imx6: bootscript: enable UBI fastmap support

[Koen Vandeputte]

On 03.10.19 00:21, Tim Harvey wrote:

UBI Fastmap support is stable in the 4.4 kernel so lets take
advantage of it to shave off 5-10 seconds of boot time.

Signed-off-by: Tim Harvey 
---
  target/linux/imx6/image/bootscript-ventana | 4 +++-
  1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/target/linux/imx6/image/bootscript-ventana 
b/target/linux/imx6/image/bootscript-ventana
index 941afb5..8451caf 100644
--- a/target/linux/imx6/image/bootscript-ventana
+++ b/target/linux/imx6/image/bootscript-ventana
@@ -1,4 +1,4 @@
-echo "Gateworks Ventana OpenWrt Boot script v1.01"
+echo "Gateworks Ventana OpenWrt Boot script v1.02"
  
  # set some defaults

  # set some defaults
@@ -51,6 +51,8 @@ if itest.s "x${dtype}" == "xnand" ; then
echo "mtdparts:${mtdparts}"
setenv fsload ubifsload
setenv root "ubi0:ubi ubi.mtd=2 rootfstype=squashfs,ubifs"
+   # enable UBI fastmap support
+   setenv bootargs "${bootargs} ubi.fm_autoconvert=1"
  else
echo "Booting from block device ${bootdev}..."
setenv fsload "${fs}load ${dtype} ${disk}:1"


Hi Tim,

Shouldn't this patch also enable the required kernel symbol? 
(MTD_UBI_FASTMAP)


Next to that, even in kernel 4.19 I'm reading following regarding this 
feature:


Important: this feature is experimental so far and the on-flash │
format for fastmap may change in the next kernel versions


Hi Richard,

Apologies for dragging you in here.

How stable is this fastmap format?

Will it leave Experimental state in the near future?


Thanks,

Koen


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

Re: [OpenWrt-Devel] QCA9994 outdoor 13km link

[Koen Vandeputte]

On 25.09.19 17:14, supp...@maxnet.al wrote:
This is long distance, 5km with 4 dishes on each side. They are all 
vertical and all chains have signal range -60 to -65.


I don't have omni antennas. Is there a problem that i am using dishes?



I run dozens of long-range devices, and I'm seeing 2 issues in your setup:

1)

- Ack-to issues kick in starting from roughly 1000m.  When you cannot 
alter ack_to (coverage class), you will notice severe performance issues 
above 1000m


2)

- Using identical polarization on all chains is an absolute performance 
killer.


I have 2 devices,  both 2x2 802.11n, HT40 SGI, which are only 150m 
apart, all chains V polarized.


When running speedtests, inspecting ath9k rate control shows it is stuck 
at the max speed for 1 chain (iso 2)


In my case it means the absolute link rate is 130Mbit iso 270 in this 
configuration.


I can imagine using 4 chains will even reduce performance a lot more.

You should really try to use use H + V+ (-45) + (+45).

Also, ensure radio's at both sides have the chains on identical 
polarization. (Chain0 - V,  Chain1 - H, ..)



Regards,

Koen



On Wed, Sep 25, 2019 at 5:11 PM +0200, "Ben Greear" 
mailto:gree...@candelatech.com>> wrote:


Is this short distance or long?

Please try short distance with omni antenna first to make sure you are not 
hitting the delayed-ack issue
or problems with your antenna.

Change your antenna orientation so that they point in different directions.

Thanks,
Ben

On 9/25/19 6:49 AM, supp...@maxnet.al wrote:
> Hello,
> 
> Today i managed to connect the station wds at 80MHz channel. Signal is -56 and i have very low datarates. I have attached a photo.
> 
>   When station was ddwrt and AP openwrt the datarates were 866/433. TX won't do more than VHT-NSS 1 although RX it's not good either because it's a 4 chain 
> radio and it should do VHT-NSS4.
> 
> Thank you,

> Klevis
> 
> 
> 
> 
> On Mon, Sep 23, 2019 at 6:36 PM +0200, "Ben Greear" > wrote: > > Weeks or months or whenever I have time, and maybe

sooner if someone > wants to sponsor it. Please understand I, and
probably everyone else working > on OpenWRT, am busy with lots of
other projects and community work often > gets pushed to the back
burner. > > Thanks, > Ben > > On 9/23/19 8:18 AM,
supp...@maxnet.al wrote: > > Hi Ben, > > > > When do you think you
might be able to make those changes to your driver? > > > >
Thanks, > > Klevis. > > > > > > > > On 2019-09-20 13:00, Ben
Greear wrote: > >> On 9/20/19 12:55 PM, Vincent Wiemann wrote: >
>>> Hi Klevis, > >>> > >>> have you tried it with a short
distance? > >>> If you did you should better ask Ben Greear
directly. > >> > >> I asked him to post publicly so that others
can help answer and that > >> my own answers might > >> help
someone else. > >> > >> I have some patches that should enable
coverage class settings for > >> wave-2, but I am too busy > >>
with other things right now to port them to my ath10k-ct
driver/firmware. > >> > >> Thanks, > >> Ben > >> > >>> > >>> By
the way ath10k gen 2 chipsets don't work very well with long
distance links without a > >>> special feature which
implementation is only available to companies like Ubiquiti and
very few > >>> people who have an own reverse-engineered
implementation. > >>> It works on IPQ401X, QCA9886 and QCA9888
based chips only. > >>> > >>> And it is not possible to set a
coverage class for gen 2 devices, yet as far as I know due to
missing > >>> documentation and implementation (correct me if that
information is outdated). > >>> Furthermore a high channel width
often results in problems > >>> due to lower receiver sensibility.
> >>> We have better experiences with lower channel widths and
sometimes get more throughput with that. > >>> > >>> Actually I
think this does not explain your connection issues as 13 km is not
that much. > >>> > >>> Regards, > >>> > >>> Vincent Wiemann > >>>
> >>> On 20.09.19 18:30, supp...@maxnet.al wrote: >  Hello
everyone, >  >  I am trying to setup a custom made outdoor
link with Apu2d2 board devices and QCA9994 cards from compex.
After i installed openwrt and ath10k ct driver, >  kmod ath10k
and board-2.bin the device can run a 80MHz channel in WDS AP. The
problem is that it won't run as station or station wds. It can
scan >  the SSIDs but won't connect them. >  >  Any
suggestion? >  >  Thank you! >  Klevis >  > >>> >
>>> ___ > >>>
openwrt-devel mailing list > >>> openwrt-devel@lists.openwrt.org >
>>> https://lists.openwrt.org/mailman/listinfo/openwrt-devel > >>>
> > > > > -- > Ben GreearCandela Technologies Inc
http://www.candelatech.com > -- Ben Greear Candela Technologies
Inc 

Re: [OpenWrt-Devel] kernel: bump 4.19 to 4.19.72 broke ath79

[Koen Vandeputte]

On 14-09-19 12:47, Magnus Kroken wrote:

Hi Andre

On 14.09.2019 10:49, Andre Valentin wrote:

It seems the kernel bump broke ath79 compilation. The problem lies in
target/linux/ath79/patches-4.19/0028-MIPS-ath79-drop-machfiles.patch

It cannot be applied anymore. I tried a quick fix, but there seems to 
be a bigger change.


The culprit isn't the kernel update, but this commit:
00d48bcac0 ar71xx: Fix potentially missed IRQ handling during dispatch

Koen (or anyone else), can you shed some light on this one? I mostly 
poke at kernel patches until something happens, I don't really 
understand hardware/kernel well. Some things jump out:



Hi,

Sorry about that.

ath79 contained a patch which removes the legacy irq code, which is 
being altered in the fix.


Hence the patch during build of ath79 didn't apply.

I didn't notice it, as this removal was only upstreamed in 5.0 and it's 
strictly not needed to remove it, as it's simply unused over there.


Fixes has been pushed for master and 19.07.

Regards,

Koen

1. The commit message is labeled ar71xx, but the patch is applied to 
the generic target. It patches kernel files that IIUC are used by both 
ath79 and ar71xx targets.
2. It modifies arch/mips/ath79/irq.c. The patch that fails on ath79, 
0027-MIPS-ath79-drop-legacy-IRQ-code, deletes this file completely 
(which now fails, as the file content is changed by 
343-MIPS-ath79-Fix-potentially-missed-IRQ-handling-durin.patch).



Kind regards,

André


Regards,
Magnus Kroken


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

Re: [OpenWrt-Devel] kernel: bump 4.19 to 4.19.72 broke ath79

[Koen Vandeputte]

On 14-09-19 10:49, Andre Valentin wrote:

Hi!

It seems the kernel bump broke ath79 compilation. The problem lies in
target/linux/ath79/patches-4.19/0028-MIPS-ath79-drop-machfiles.patch

It cannot be applied anymore. I tried a quick fix, but there seems to be a 
bigger change.

Kind regards,

André



should be fixed.

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

Re: [OpenWrt-Devel] ath79 on 19.07 doesn't build on 4.14.143 kernel

[Koen Vandeputte]

On 14-09-19 11:59, Dmitry Tunin wrote:

Patch target/linux/ath79/patches-4.14/0027-MIPS-ath79-drop-legacy-IRQ-code.patch
doesn't apply


Applying 
/home/pilot6/LEDE/openwrt/target/linux/ath79/patches-4.14/0027-MIPS-ath79-drop-legacy-IRQ-code.patch
using plaintext:
patching file arch/mips/ath79/Makefile
patching file arch/mips/ath79/irq.c
Hunk #1 FAILED at 1.
Not deleting file arch/mips/ath79/irq.c as content differs from patch
1 out of 1 hunk FAILED -- saving rejects to file arch/mips/ath79/irq.c.rej
patching file arch/mips/ath79/setup.c
patching file arch/mips/include/asm/mach-ath79/ath79.h
Patch failed!  Please fix
/home/pilot6/LEDE/openwrt/target/linux/ath79/patches-4.14/0027-MIPS-ath79-drop-legacy-IRQ-code.patch!
Makefile:19: recipe for target
'/home/pilot6/LEDE/openwrt/build_dir/target-mips_24kc_musl/linux-ath79_generic/linux-4.14.143/.prepared_bdda8d3146b44452afe9accda800aa5d'
failed

should be fixed.

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

Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode

[Koen Vandeputte]

On 28.08.19 19:34, Joe Ayers wrote:

initialized the ackto to max:

A) avoidance of late-ack state
B) not require wpa_supplicant  -- not in use by our community today
C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger
"late ack" (consistent, with observation of low SNR Neighbors sticking
at max ack_to with my changes )

flip the algo off/on when new neighbor joins:

Intended technique to reset ack_to to max.  If ack_to is set to 20km
and then a new adhoc neighbor joins at 30km, this would be a late ack
state, and unable to detect.My early testing results showed the
algo off/on would restart the ack_to to max and start the process over
with the new neighbor.   I trust I got it right?

There are 10s to 100s of users testing this bleeding edge change from
nightly builds, and so far, I've not found a failure case.
Although, the findings are showing the cases where static setting has
better throughput.

Joe AE6XE


Hi Joe,

Purely fyi

I just pushed dynack improvements to all openwrt branches.

I also noticed the issues you addressed above, and these patches fix
them for me.

Regards,

Koen


Thanks for update.   Updates on performance observations, I've been
recommending usage of auto settings to the AREDN community as follows:

* best performance gain on Point-to-Point longer distance links (back
bone links).  I saw ~30% iperf improvement results on a 60km 5GHz link
-- ack-to floats up under load.   This was about the difference I
measured on a similar 3GHz  60km link head-to-head comparison between
AirOS auto distance with TDMA and openwrt static distance with CSMA.
(3GHz because it takes wifi noise out of the picture.)  I want to do a
head-to-head comparison again to confirm, but it appears a P2P w/ auto
setting CSMA in openwrt will compare similar thoughput as AirOS auto
distance TDMA.



* good/poor performance for Point-to-Multipoint long distance
settings, up to 20km  range (cell coverage).   If weak SNR stations, a
static setting is optimal.  If quality signal, auto works good.

Will try to verify this one

* Poor performance for short distances, e.g. in the house.   auto
calculated ack_to settings are several km.  Performance is much poorer
than a static setting of <1km.

Ack on this one.
Tested on links ranging from ~500m up to 3.5km

static seems to win in terms of performance until the distance goes 
beyond ~6km here




There seems to be something going on with calculation when 'on the
bench' testing with short distances.   Maybe a bias needs to be
applied?


I notice that ack_to never drops below 64 on short distance links. 
(static sets it to 31 on selecting 500m)


I wonder if processing delay/time and thread context switching is coming 
into play here on the slower ar71xx socs


Will check it.

The main focus of this series was to have working links and avoid 
breaking existing ones.


I think the next round will be regarding these performance "issues" 
compared to static


Koen



Joe AE6XE


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

Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode

[Koen Vandeputte]

initialized the ackto to max:

A) avoidance of late-ack state
B) not require wpa_supplicant  -- not in use by our community today
C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger
"late ack" (consistent, with observation of low SNR Neighbors sticking
at max ack_to with my changes )

flip the algo off/on when new neighbor joins:

Intended technique to reset ack_to to max.  If ack_to is set to 20km
and then a new adhoc neighbor joins at 30km, this would be a late ack
state, and unable to detect.My early testing results showed the
algo off/on would restart the ack_to to max and start the process over
with the new neighbor.   I trust I got it right?

There are 10s to 100s of users testing this bleeding edge change from
nightly builds, and so far, I've not found a failure case.
Although, the findings are showing the cases where static setting has
better throughput.

Joe AE6XE




Hi Joe,

Purely fyi

I just pushed dynack improvements to all openwrt branches.

I also noticed the issues you addressed above, and these patches fix 
them for me.


Regards,

Koen


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

[OpenWrt-Devel] [PATCH] ar71xx: ag71xx: add missing register writes

[Koen Vandeputte]

These are added in ath79, but were not backported here

Signed-off-by: Koen Vandeputte 
---
 .../files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c  | 5 +
 1 file changed, 5 insertions(+)

diff --git 
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c 
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
index f0d8d46a18a1..e97317bd20ff 100644
--- 
a/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
+++ 
b/target/linux/ar71xx/files/drivers/net/ethernet/atheros/ag71xx/ag71xx_main.c
@@ -1274,6 +1274,9 @@ static int ag71xx_change_mtu(struct net_device *dev, int 
new_mtu)
return -EBUSY;
 
dev->mtu = new_mtu;
+   ag71xx_wr(ag, AG71XX_REG_MAC_MFL,
+ ag71xx_max_frame_len(dev->mtu));
+
return 0;
 }
 
@@ -1413,6 +1416,8 @@ static int ag71xx_probe(struct platform_device *pdev)
 
ag71xx_dump_regs(ag);
 
+   ag71xx_wr(ag, AG71XX_REG_MAC_CFG1, 0);
+
ag71xx_hw_init(ag);
 
ag71xx_dump_regs(ag);
-- 
2.17.1


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

Re: [OpenWrt-Devel] ath9k: fix dynack in IBSS mode

[Koen Vandeputte]

Hi Joe,


Lorenzo,  I deployed an ath9k auto distance solution in April that is
working for the AREDN community http://www.arednmesh.org .

https://github.com/aredn/aredn_ar71xx/blob/develop/patches/712-auto-distance-settings.patch

Summary of solution:

* no dependency on wpa_supplicant
* initial ack_to is set to max,  to not enter late ack conditions
* User level trigger to flip distance setting to static and back to
auto when new 802.11 adhoc neighbor joins. (we archive and chart SNR
values for neighbors and natural to hook in this trigger).

Have you initialized the ackto to the max value to remove wpa_supplicant
dependency or because the system is not able to trigger the 'late ack'?
I did not get why you need to flip the algo off/on when new 802.11 adhoc
neighbor joins

Regards,
Lorenzo


initialized the ackto to max:

A) avoidance of late-ack state
B) not require wpa_supplicant  -- not in use by our community today
C) Suspect some conditions, e.g. low SNR Neighbors, do not trigger
"late ack" (consistent, with observation of low SNR Neighbors sticking
at max ack_to with my changes )

flip the algo off/on when new neighbor joins:

Intended technique to reset ack_to to max.  If ack_to is set to 20km
and then a new adhoc neighbor joins at 30km, this would be a late ack
state, and unable to detect.My early testing results showed the
algo off/on would restart the ack_to to max and start the process over
with the new neighbor.   I trust I got it right?

There are 10s to 100s of users testing this bleeding edge change from
nightly builds, and so far, I've not found a failure case.
Although, the findings are showing the cases where static setting has
better throughput.

Joe AE6XE







Lorenzo,

It's been a while regarding the above.

I can confirm the issue that if the algorithm misses the late ack's due 
to low initial snr, the initial ack_to is too low to recover afterwards.


Do you think it would be useful to start at high ack_to and let it 
estimate/drop afterwards?


Ps.

I've got my 24km link back if required to do some additional testing.


Thanks,

Koen


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

Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS

[Koen Vandeputte]

On 09.08.19 15:31, Koen Vandeputte wrote:


On 09.08.19 14:48, Ben Greear wrote:

On 8/6/19 2:26 AM, Koen Vandeputte wrote:


Hi Ben,

I finally managed to get to some time to properly take a look 
using a simple setup.


Attached all required files to simulate the issue.

I compiled the latest OpenWrt master state, (included a full 
wpa_supplicant and iperf tools) and ran the 2 starts.


Attached also logs as seen from both boards simultaneously.


basically:

- If the boards finally do link after lots of tries, it will have 
a >200ms latency and max speed of about 3Mbit.


- The wpa_sup config file is the most basic RSN enabled config.

- I also tried the current Master state with/without all custom 
pathes, but the result is the same.


- wpa_supp also nags about some missing IE's


Hw used:

- 2x RB-922UAGS containing a on-board ar988x, capable of 30dBm.

- 2x standard 5GHz omni antennae

- board seperation distance ca 6ft


Can you reproduce without encryption enabled?  That makes it easier 
to debug

packet sniffs.

If you just run ping traffic (or very slow speed tcp/udp), do you 
still see the issues (like high

latency, packet loss, poor on-air encoding rates, etc)?


currently rebuilding the setup. will get back on this asap.
If I build you a debugging firmware, are you able and willing to 
reproduce the problem and

send me dmesg output as well as on-air packet sniff?

Very sure!


Preferably, with generated traffic with unique packet sizes (ie, ever 
increasing, random, or something like
that, so I can more easily match up on-air frames with the debugging 
output.



I believe that the beacon issues are probably a symptom of some other 
failure in the transmit and/or

receive path.

Thanks,
Ben


Lets get this fixed! :-)

Koen



Just tested with encryption disabled:

summary:

- speed is looking good. (~130Mbit/s) also link speed is 866Mbit (2x2 radio)

- iw wlan0 confirms 80MHz channel

- Only a single splat seen, no beacon errors

- non-htt firmware


dmesg:  https://pastebin.com/YLbJCDJc


configs:

network={
    ssid="ibsskoen"
    key_mgmt=NONE
    mode=1
    frequency=5745
}

iwinfo:

wlan0 ESSID: "ibsskoen"
  Access Point: B8:69:F4:CF:C6:05
  Mode: Ad-Hoc  Channel: 149 (5.745 GHz)
  Tx-Power: 30 dBm  Link Quality: 70/70
  Signal: -5 dBm  Noise: -102 dBm
  Bit Rate: 866.7 MBit/s
  Encryption: unknown
  Type: nl80211  HW Mode(s): 802.11nac
  Hardware: 168C:003C 19B6:D042 [Generic MAC80211]
  TX power offset: unknown
  Frequency offset: unknown
  Supports VAPs: yes  PHY name: phy0



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

Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS

[Koen Vandeputte]

On 09.08.19 14:48, Ben Greear wrote:

On 8/6/19 2:26 AM, Koen Vandeputte wrote:


Hi Ben,

I finally managed to get to some time to properly take a look using 
a simple setup.


Attached all required files to simulate the issue.

I compiled the latest OpenWrt master state, (included a full 
wpa_supplicant and iperf tools) and ran the 2 starts.


Attached also logs as seen from both boards simultaneously.


basically:

- If the boards finally do link after lots of tries, it will have a 
>200ms latency and max speed of about 3Mbit.


- The wpa_sup config file is the most basic RSN enabled config.

- I also tried the current Master state with/without all custom 
pathes, but the result is the same.


- wpa_supp also nags about some missing IE's


Hw used:

- 2x RB-922UAGS containing a on-board ar988x, capable of 30dBm.

- 2x standard 5GHz omni antennae

- board seperation distance ca 6ft


Can you reproduce without encryption enabled?  That makes it easier to 
debug

packet sniffs.

If you just run ping traffic (or very slow speed tcp/udp), do you 
still see the issues (like high

latency, packet loss, poor on-air encoding rates, etc)?


currently rebuilding the setup. will get back on this asap.
If I build you a debugging firmware, are you able and willing to 
reproduce the problem and

send me dmesg output as well as on-air packet sniff?

Very sure!


Preferably, with generated traffic with unique packet sizes (ie, ever 
increasing, random, or something like
that, so I can more easily match up on-air frames with the debugging 
output.



I believe that the beacon issues are probably a symptom of some other 
failure in the transmit and/or

receive path.

Thanks,
Ben


Lets get this fixed! :-)

Koen


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

Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS

[Koen Vandeputte]

On 05.08.19 18:17, Koen Vandeputte wrote:


On 05.08.19 17:47, Koen Vandeputte wrote:


On 27.06.19 16:24, Ben Greear wrote:

On 6/27/19 7:17 AM, Koen Vandeputte wrote:


On 26.06.19 18:39, Ben Greear wrote:

On 6/26/19 9:28 AM, Koen Vandeputte wrote:


On 26.06.19 18:16, Ben Greear wrote:

On 6/26/19 2:02 AM, Koen Vandeputte wrote:


On 25.06.19 15:54, Ben Greear wrote:



On 06/25/2019 02:53 AM, Koen Vandeputte wrote:


On 24.06.19 22:04, Ben Greear wrote:

On 6/24/19 8:32 AM, Koen Vandeputte wrote:

Hi Ben,
Hi All,

So I'm going to give this another try ..
As the IBSS functionality is heavily advertised as a delta 
to mainline, it would be very nice to get it working also :)


Testing the latest ath10k-ct driver and firmware seems to 
be a step back compared to roughly a month ago.


I'm currently seeing the firmware crashing, which was not 
the case before:



ath10k-ct + htt-fw:

https://pastebin.com/raw/7Sy9yx6s


Looks like firmware ran out of some WMI event buffers and 
crashed instead of handling

it more gracefully.

Please try the attached (untested) firmware and see if it 
behaves better.



Hi Ben,

1 step forward here.

I'm not seeing crashes anymore using the test-firmware.

https://pastebin.com/raw/4ZeXu7iw


I've linked up 2 IBSS devices (wave 1, VHT80)

OLSR traffic (UDP) works and packets here are nicely going 
back & forth.


Simply pinging (ICMP) between the 2 devices does not work.

When sending 100 pings, (64 byte large) sometimes 1 gets 
through .. but with a latency of > 500ms



I think if the splat and the beacon spam below could be fixed 
.. this would be a major step forward:


[   30.328423] [ cut here ]
[   30.333251] WARNING: CPU: 0 PID: 1578 at 
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]
[   30.355636] Modules linked in: mbt ath9k ath9k_common 
qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci 
ath10k_core ath usb_wwan sierra_net sierra rndis_host 
qmi_wwan pppox ppp_generic mac80211 iptable_nat 
iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE 
ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm 
cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport 
xt_mark xt_mac xt_limt
[   30.427331]  nls_utf8 nls_iso8859_1 nls_cp437 authenc 
ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug 
ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core 
mii aead crypto_null cryptomgr crc32c_generic crypto_hash
[   30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not 
tainted 4.14.129 #0


Please look in your code and let me know the source around the 
line in mac.c (6563) that is splatting.


Also, you might grab the latest ath10k-ct repo, it has a tweak 
that might fix the SWBA overrun

messages.

https://github.com/greearb/ath10k-ct

Thanks,
Ben


Hi Ben,

Here is the output based on the latest git HEAD of your ct 
tree, combined with the test firmware:


https://pastebin.com/raw/kwC6c18J


Hello,

The splat decode does not match the source code, so I'm not 
which is correct.



OpenWrt seems to add custom patches to your source.

Please find the complete source in subsequent mail as being build.


I did look in that code, and that is where I saw the mismatch. 
Please check your own local system
and see if the splat matches your code?  Maybe I made some mistake 
of course...


You can paste ~20 lines of code around the proper splat line and 
then I can find it in my

source...

Thanks,
Ben



Hi Ben,

Just retried again on a slightly older commit (2019-05-08) and the 
splat points to another location now.

When looking it up, it again points to the WARN_ON pointed below ..

Checking shows that all calls to ath10k_mac_vif_beacon_free() calls 
are way above this line (highest line nr is around line1970)

I currently can't explain where the mismatch comes from ..

Current build below is just the git HEAD of openwrt 19.07 branch, 
cloned, build and flashed without any modification.



[   31.956774] WARNING: CPU: 0 PID: 1725 at 
/mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 
ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core]




 ret = ath10k_config_ps(ar);
 if (ret)
 ath10k_warn(ar, "failed to setup ps on 
vdev %i: %d\n",

 arvif->vdev_id, ret);
 }

 if (changed & BSS_CHANGED_MCAST_RATE &&
--->      !WARN_ON(ath10k_mac_vif_chan(arvif->vif, ))) {
 band = def.chan->band;


I think this might not be to serious of a bug, and probably does not 
cause any real

trouble.

It is also probably a bug in mac80211 or similar, but not certain 
about that.


The general set of bugs related to IBSS

Re: [OpenWrt-Devel] atomic sleep bugs - 19.07 (and probably Master too)

[Koen Vandeputte]

On 01.08.19 17:27, Koen Vandeputte wrote:

Hi All,

I've been playing around the last few days stresstesting latest 19.07 
on different targets (ar71xx, cns3xxx, imx6, ...) with extra kernel 
debug features enabled.


I'll post some results here as maybe somebody has a clue. :)


Some interesting splats already showed up, actually also *breaking* 
some functionality while the board is running:


on Mikrotik RB2011 (ar71xx)


[   16.885207] eth0: link down
[   16.919752] BUG: sleeping function called from invalid context at 
net/core/dev.c:5563

[   17.013669] in_atomic(): 1, irqs_disabled(): 1, pid: 463, name: ip
[   17.087839] 2 locks held by ip/463:
[   17.129668]  #0:  (rtnl_mutex){}, at: [<80378814>] 
rtnetlink_rcv_msg+0x2d8/0x380
[   17.222617]  #1:  (&(>lock)->rlock){}, at: [<80331900>] 
ag71xx_hw_disable+0x24/0x94

[   17.322878] CPU: 0 PID: 463 Comm: ip Not tainted 4.14.134 #0
[   17.390782] Stack : 805e 8058aefc 80558ed0 876278ec 8061 
8061 87d1b2fc 805b7367
[   17.491032] 80552f04 01cf 8061386c 87627ccc 87d5b180 
0001 876278a0 6ae07578
[   17.591283]   80b0 8762779c 0a55a891 
 0007 
[   17.691535] 0099 8f9b5648 0098  8000 
87d6e58c 87d6e5b0 0001
[   17.791785] 8047095c 87627ccc 87d5b180 87d9ae10 0003 
802cfa54  8061

[   17.892036] ...
[   17.921352] Call Trace:
[   17.950676] [<8006cb0c>] show_stack+0x58/0x100
[   18.003996] [<800aadf4>] ___might_sleep+0x100/0x120
[   18.062512] [<8035d7f4>] napi_disable+0x30/0xd8
[   18.116854] [<80331940>] ag71xx_hw_disable+0x64/0x94
[   18.176421] [<80331994>] ag71xx_stop+0x24/0x38
[   18.229729] [<8035b1f0>] __dev_close_many+0xcc/0x104
[   18.289306] [<8036426c>] __dev_change_flags+0xc8/0x1ac
[   18.350950] [<80364378>] dev_change_flags+0x28/0x70
[   18.409473] [<80377c30>] do_setlink+0x31c/0x91c
[   18.463826] [<8037a700>] rtnl_newlink+0x3ec/0x7f8
[   18.520261] [<80378838>] rtnetlink_rcv_msg+0x2fc/0x380
[   18.581938] [<8039bac4>] netlink_rcv_skb+0xd4/0x178
[   18.640439] [<8039b0a0>] netlink_unicast+0x168/0x250
[   18.76] [<8039b664>] netlink_sendmsg+0x3d8/0x434
[   18.759580] [<803404a4>] ___sys_sendmsg+0x1dc/0x290
[   18.818098] [<80341500>] __sys_sendmsg+0x54/0x84
[   18.873504] [<8007212c>] syscall_common+0x34/0x58


on Mikrotik RB-912 (ar71xx), using ath9k combined with a USB modem 
together.  When disabling ath9k or unplugging the modem, these bugs 
don't appear

Here, the USB modem stops receiving data after a few seconds:


[   37.165493] wlan0: Trigger new scan to find an IBSS to join
[   37.171546] BUG: sleeping function called from invalid context at 
kernel/irq/manage.c:112
[   37.180006] in_atomic(): 1, irqs_disabled(): 1, pid: 9, name: 
kworker/u2:1

[   37.187110] 6 locks held by kworker/u2:1/9:
[   37.191434]  #0:  ("%s"wiphy_name(local->hw.wiphy)){}, at: 
[<8009f89c>] process_one_work+0x250/0x4c0
[   37.201298]  #1:  ((>work)){}, at: [<8009f89c>] 
process_one_work+0x250/0x4c0
[   37.209604]  #2:  (>mtx){}, at: [<82917130>] 
ieee80211_ibss_work+0x40/0x5a4 [mac80211]
[   37.219077]  #3:  (>mtx){}, at: [<8290d914>] 
ieee80211_request_ibss_scan+0x4c/0x2b8 [mac80211]
[   37.229246]  #4:  (>mutex){}, at: [<82ae4878>] 
ath9k_ps_restore+0xd54/0x11dc [ath9k]
[   37.238159]  #5:  (_desc_lock_class){}, at: [<800c29d8>] 
__irq_get_desc_lock+0x8c/0xb0

[   37.247113] CPU: 0 PID: 9 Comm: kworker/u2:1 Tainted: G W 4.14.134 #0
[   37.255282] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
[   37.261055] Stack : 82870080 82870158 82860d60 800c0fa0 8061 
 0001 805b
[   37.269743] 80552e7c 8384db24 0348 800c1e04 82860d60 
 8384db00 21bc325c
[   37.278434]   0006 8384d9d4 acbbbd0d 
 0007 
[   37.287125] 0132 805c 0131   
828626d8 828703c8 0348
[   37.295816] 82870080 82870158 82860d60 828703c8 0002 
802cfa54  8061

[   37.304508] ...
[   37.307055] Call Trace:
[   37.309601] [<8006cb0c>] show_stack+0x58/0x100
[   37.314219] [<800aadf4>] ___might_sleep+0x100/0x120
[   37.319280] [<800c3344>] synchronize_irq+0x3c/0xa0
[   37.324245] [<800c6594>] __irq_disable+0x64/0xb4
[   37.329024] [<800c35f4>] __disable_irq_nosync+0x3c/0x68
[   37.334434] [<800c363c>] disable_irq+0x14/0x38
[   37.339195] [<82ae5b48>] ath9k_calculate_summary_state+0x53c/0x6f4 
[ath9k]

[   37.357669] ttyS ttyS0: 1 input overrun(s)
[   38.170588] BUG: sleeping function called from invalid context at 
kernel/irq/manage.c:112
[   38.179059] in_atomic(): 1, irqs_disabled(): 1, pid: 9, name: 
kworker/u2:1

[   38.186167] 5 locks hel

[OpenWrt-Devel] atomic sleep bugs - 19.07 (and probably Master too)

[Koen Vandeputte]

Hi All,

I've been playing around the last few days stresstesting latest 19.07 on 
different targets (ar71xx, cns3xxx, imx6, ...) with extra kernel debug 
features enabled.


I'll post some results here as maybe somebody has a clue. :)


Some interesting splats already showed up, actually also *breaking* some 
functionality while the board is running:


on Mikrotik RB2011 (ar71xx)


[   16.885207] eth0: link down
[   16.919752] BUG: sleeping function called from invalid context at 
net/core/dev.c:5563

[   17.013669] in_atomic(): 1, irqs_disabled(): 1, pid: 463, name: ip
[   17.087839] 2 locks held by ip/463:
[   17.129668]  #0:  (rtnl_mutex){}, at: [<80378814>] 
rtnetlink_rcv_msg+0x2d8/0x380
[   17.222617]  #1:  (&(>lock)->rlock){}, at: [<80331900>] 
ag71xx_hw_disable+0x24/0x94

[   17.322878] CPU: 0 PID: 463 Comm: ip Not tainted 4.14.134 #0
[   17.390782] Stack : 805e 8058aefc 80558ed0 876278ec 8061 
8061 87d1b2fc 805b7367
[   17.491032] 80552f04 01cf 8061386c 87627ccc 87d5b180 
0001 876278a0 6ae07578
[   17.591283]   80b0 8762779c 0a55a891 
 0007 
[   17.691535] 0099 8f9b5648 0098  8000 
87d6e58c 87d6e5b0 0001
[   17.791785] 8047095c 87627ccc 87d5b180 87d9ae10 0003 
802cfa54  8061

[   17.892036] ...
[   17.921352] Call Trace:
[   17.950676] [<8006cb0c>] show_stack+0x58/0x100
[   18.003996] [<800aadf4>] ___might_sleep+0x100/0x120
[   18.062512] [<8035d7f4>] napi_disable+0x30/0xd8
[   18.116854] [<80331940>] ag71xx_hw_disable+0x64/0x94
[   18.176421] [<80331994>] ag71xx_stop+0x24/0x38
[   18.229729] [<8035b1f0>] __dev_close_many+0xcc/0x104
[   18.289306] [<8036426c>] __dev_change_flags+0xc8/0x1ac
[   18.350950] [<80364378>] dev_change_flags+0x28/0x70
[   18.409473] [<80377c30>] do_setlink+0x31c/0x91c
[   18.463826] [<8037a700>] rtnl_newlink+0x3ec/0x7f8
[   18.520261] [<80378838>] rtnetlink_rcv_msg+0x2fc/0x380
[   18.581938] [<8039bac4>] netlink_rcv_skb+0xd4/0x178
[   18.640439] [<8039b0a0>] netlink_unicast+0x168/0x250
[   18.76] [<8039b664>] netlink_sendmsg+0x3d8/0x434
[   18.759580] [<803404a4>] ___sys_sendmsg+0x1dc/0x290
[   18.818098] [<80341500>] __sys_sendmsg+0x54/0x84
[   18.873504] [<8007212c>] syscall_common+0x34/0x58


on Mikrotik RB-912 (ar71xx), using ath9k combined with a USB modem 
together.  When disabling ath9k or unplugging the modem, these bugs 
don't appear

Here, the USB modem stops receiving data after a few seconds:


[   37.165493] wlan0: Trigger new scan to find an IBSS to join
[   37.171546] BUG: sleeping function called from invalid context at 
kernel/irq/manage.c:112
[   37.180006] in_atomic(): 1, irqs_disabled(): 1, pid: 9, name: 
kworker/u2:1

[   37.187110] 6 locks held by kworker/u2:1/9:
[   37.191434]  #0:  ("%s"wiphy_name(local->hw.wiphy)){}, at: 
[<8009f89c>] process_one_work+0x250/0x4c0
[   37.201298]  #1:  ((>work)){}, at: [<8009f89c>] 
process_one_work+0x250/0x4c0
[   37.209604]  #2:  (>mtx){}, at: [<82917130>] 
ieee80211_ibss_work+0x40/0x5a4 [mac80211]
[   37.219077]  #3:  (>mtx){}, at: [<8290d914>] 
ieee80211_request_ibss_scan+0x4c/0x2b8 [mac80211]
[   37.229246]  #4:  (>mutex){}, at: [<82ae4878>] 
ath9k_ps_restore+0xd54/0x11dc [ath9k]
[   37.238159]  #5:  (_desc_lock_class){}, at: [<800c29d8>] 
__irq_get_desc_lock+0x8c/0xb0
[   37.247113] CPU: 0 PID: 9 Comm: kworker/u2:1 Tainted: G W   
4.14.134 #0

[   37.255282] Workqueue: phy0 ieee80211_ibss_leave [mac80211]
[   37.261055] Stack : 82870080 82870158 82860d60 800c0fa0 8061 
 0001 805b
[   37.269743] 80552e7c 8384db24 0348 800c1e04 82860d60 
 8384db00 21bc325c
[   37.278434]   0006 8384d9d4 acbbbd0d 
 0007 
[   37.287125] 0132 805c 0131   
828626d8 828703c8 0348
[   37.295816] 82870080 82870158 82860d60 828703c8 0002 
802cfa54  8061

[   37.304508] ...
[   37.307055] Call Trace:
[   37.309601] [<8006cb0c>] show_stack+0x58/0x100
[   37.314219] [<800aadf4>] ___might_sleep+0x100/0x120
[   37.319280] [<800c3344>] synchronize_irq+0x3c/0xa0
[   37.324245] [<800c6594>] __irq_disable+0x64/0xb4
[   37.329024] [<800c35f4>] __disable_irq_nosync+0x3c/0x68
[   37.334434] [<800c363c>] disable_irq+0x14/0x38
[   37.339195] [<82ae5b48>] ath9k_calculate_summary_state+0x53c/0x6f4 
[ath9k]

[   37.357669] ttyS ttyS0: 1 input overrun(s)
[   38.170588] BUG: sleeping function called from invalid context at 
kernel/irq/manage.c:112
[   38.179059] in_atomic(): 1, irqs_disabled(): 1, pid: 9, name: 
kworker/u2:1

[   38.186167] 5 locks held by kworker/u2:1/9:
[   38.190492]  #0:  ("%s"wiphy_name(local->hw.wiphy)){}, at: 
[<8009f89c>] process_one_work+0x250/0x4c0
[   38.200365]  #1: ((&(>scan_work)->work)){}, at: 
[<8009f89c>] process_one_work+0x250/0x4c0
[   38.209925]  #2:  (>mtx){}, at: 

Re: [OpenWrt-Devel] [PATCH 19.07] mac80211: Update to version 4.19.57

[Koen Vandeputte]

On 07.07.19 19:28, Hauke Mehrtens wrote:

This updates to backports-4.19.57-1 which contains the wireless
subsystem and driver from kernel 4.19.57.
The removed patches are applied upstream.


Tested-by: Koen Vandeputte 

- Quad radio 802.11n (ar9220) on cns3xxx

- Dual radio 802.11n (ar9582) on imx6

- Single radio 802.11n on ar71xx

All running in IBSS CCMP


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