[PATCH] Remove ccache wrappers
These wrappers are not needed as CC doesn't need to be a single word.
a53b084e497a9f1629a2caada833ebe14a6838b7 which introduced the wrappers
doesn't explain why they were really needed and why only for the target
and not for the host.
Moreover, name of the wrappers breaks a ccache assumption: since
v4.0-3-g6a92b4cd3a67 it has special handling for "chained" invocation
such as "ccache ccache gcc" where it skips all the "ccache*" names in
the middle and proceeds to run as if it was started as "ccache
gcc"[1][2].
This becomes important when a build system sees ccache in the PATH and
automatically enables it by prepending to CC. An example of such a
system would be autosetup as used by jimtcl. With the wrappers it breaks
as the command line ends up being just "ccache -Os..." because
"ccache_cc" gets skipped as it starts with "ccache".
[1] https://github.com/ccache/ccache/blob/master/src/ccache.cpp#L2105
[2] https://github.com/ccache/ccache/blob/master/src/Util.cpp#L802
Reported-by: Karl Palsson
Signed-off-by: Paul Fertser
---
I tried CONFIG_ALL=y build and fixed bad packaging where I noticed:
https://github.com/openwrt/packages/pull/20353
Also sent a patch for Alpine (in private) and a patch/bug report to
libicu upstream: https://github.com/unicode-org/icu/pull/2290 .
My notion is that properly fixing affected software is better in the
long run. However just renaming the wrappers is an option too if it's
much less painful in the end. One potential downside would be that the
build systems wouldn't be able to detect e.g. GCC vs clang if used
with a wrapper and wouldn't apply custom build flags.
rules.mk | 4 ++--
tools/ccache/Makefile | 10 --
tools/ccache/files/ccache_cc | 2 --
tools/ccache/files/ccache_cxx | 2 --
4 files changed, 2 insertions(+), 16 deletions(-)
delete mode 100755 tools/ccache/files/ccache_cc
delete mode 100755 tools/ccache/files/ccache_cxx
diff --git a/rules.mk b/rules.mk
index 3d151338af11..a2f5bcca4b0d 100644
--- a/rules.mk
+++ b/rules.mk
@@ -283,8 +283,8 @@ export HOSTCC_NOCACHE
export HOSTCXX_NOCACHE
ifneq ($(CONFIG_CCACHE),)
- TARGET_CC:= ccache_cc
- TARGET_CXX:= ccache_cxx
+ TARGET_CC:= ccache $(TARGET_CC)
+ TARGET_CXX:= ccache $(TARGET_CXX)
HOSTCC:= ccache $(HOSTCC)
HOSTCXX:= ccache $(HOSTCXX)
export CCACHE_BASEDIR:=$(TOPDIR)
diff --git a/tools/ccache/Makefile b/tools/ccache/Makefile
index 25ab4a46eabe..6824dbddfd40 100644
--- a/tools/ccache/Makefile
+++ b/tools/ccache/Makefile
@@ -28,14 +28,4 @@ ifneq (docs-$(CONFIG_BUILD_DOCUMENTATION),docs-y)
CMAKE_HOST_OPTIONS += -DENABLE_DOCUMENTATION=OFF
endif
-define Host/Install/ccache
- $(INSTALL_DIR) $(STAGING_DIR_HOST)/bin/
- $(CP) ./files/* $(STAGING_DIR_HOST)/bin/
-endef
-
-define Host/Install
- $(call Host/Install/Default)
- $(call Host/Install/ccache)
-endef
-
$(eval $(call HostBuild))
diff --git a/tools/ccache/files/ccache_cc b/tools/ccache/files/ccache_cc
deleted file mode 100755
index 01c4ad42a21d..
--- a/tools/ccache/files/ccache_cc
+++ /dev/null
@@ -1,2 +0,0 @@
-#!/bin/sh
-exec ccache "${TARGET_CC_NOCACHE}" "$@"
diff --git a/tools/ccache/files/ccache_cxx b/tools/ccache/files/ccache_cxx
deleted file mode 100755
index cc60eb3a13c7..
--- a/tools/ccache/files/ccache_cxx
+++ /dev/null
@@ -1,2 +0,0 @@
-#!/bin/sh
-exec ccache "${TARGET_CXX_NOCACHE}" "$@"
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFT 0/5] realtek: support boards similar to DGS-1210-10
On Sat, Jul 16, 2022 at 11:32:52PM -0300, Luiz Angelo Daros de Luca wrote: > It uses SOC := rtl8380 while all existing dgs-1210 F1 variants use > rtl8382 (except for the pending -52 variant). The commit didn't > mention why that happened. It's just cosmetic AFAICT but the datasheet clearly states that the SoC used for <=18 ports switches is called RTL8380. > I'm not sure which one is correct here. However, if it is really a > different SoC and with what we currently know, we could create a > generic rtl83xx_d-link_dgs-1210.dtsi as the -52 variant uses even a > more different SoC (rtl8393). They share a lot of stuff like flash > layout and gpios (and the vendor firmware even uses the same image). I > could do some generic and family review but I only have -28 and -52 > variants. I only have access to non-PoE dgs-1210-10 R1 board. You say they share GPIO layout, does it mean you currently can't fully handle SFP ports on your hardware but my patches make it work? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] x86: geode: add kmod-crypto-ebc needed for hw acceleration
Module kmod-crypto-hw-geode provides accelerated cbc(aes) and ecb(aes) but the software implementation is also needed when AES key size isn't 128 so that the operation can fall back. Add the kmod so that it would all work as expected out of the box. Tested-by: timur_davletshin Signed-off-by: Paul Fertser --- target/linux/x86/image/geode.mk | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/target/linux/x86/image/geode.mk b/target/linux/x86/image/geode.mk index 6cea887926db..ce5e93a2c5bc 100644 --- a/target/linux/x86/image/geode.mk +++ b/target/linux/x86/image/geode.mk @@ -1,7 +1,8 @@ define Device/generic DEVICE_VENDOR := Generic DEVICE_MODEL := x86/Geode - DEVICE_PACKAGES += kmod-crypto-cbc kmod-crypto-hw-geode kmod-ledtrig-gpio + DEVICE_PACKAGES += kmod-crypto-cbc kmod-crypto-ebc kmod-crypto-hw-geode \ + kmod-ledtrig-gpio GRUB2_VARIANT := legacy endef TARGET_DEVICES += generic -- 2.32.0 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] x86: geode: use kernel [hwrng] to provide randomness
Following the idea from 7747b3fa36d3 ("generic: add bcm2835-rng quality
patch") and 9dc84018eeef ("bcm27xx: remove urngd package") this patch
allows kernel to directly use HW RNG and provide enough entropy from
/dev/random without urngd and/or rng-tools.
I am not sending this upstream as I have no idea how to estimate quality
properly.
Tested-by: timur_davletshin
Signed-off-by: Paul Fertser
---
target/linux/x86/geode/target.mk | 1 +
.../960-hwrng-geode-set-quality-to-1000.patch| 12
2 files changed, 13 insertions(+)
create mode 100644
target/linux/x86/patches-5.10/960-hwrng-geode-set-quality-to-1000.patch
diff --git a/target/linux/x86/geode/target.mk b/target/linux/x86/geode/target.mk
index a64d2baaeec2..1ca0de2fbe49 100644
--- a/target/linux/x86/geode/target.mk
+++ b/target/linux/x86/geode/target.mk
@@ -1,5 +1,6 @@
BOARDNAME:=AMD Geode based systems
FEATURES += pci usb gpio
+DEFAULT_PACKAGES := $(filter-out urngd,$(DEFAULT_PACKAGES))
define Target/Description
Build firmware images for AMD Geode GX/LX based systems (net5501, alix,
geos)
diff --git
a/target/linux/x86/patches-5.10/960-hwrng-geode-set-quality-to-1000.patch
b/target/linux/x86/patches-5.10/960-hwrng-geode-set-quality-to-1000.patch
new file mode 100644
index ..de1435b20bc9
--- /dev/null
+++ b/target/linux/x86/patches-5.10/960-hwrng-geode-set-quality-to-1000.patch
@@ -0,0 +1,12 @@
+Index: linux-5.10.92/drivers/char/hw_random/geode-rng.c
+===
+--- linux-5.10.92.orig/drivers/char/hw_random/geode-rng.c
linux-5.10.92/drivers/char/hw_random/geode-rng.c
+@@ -80,6 +80,7 @@ static struct hwrng geode_rng = {
+ .name = "geode",
+ .data_present = geode_rng_data_present,
+ .data_read = geode_rng_data_read,
++ .quality= 1000,
+ };
+
+
--
2.32.0
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [RFT 1/5] realtek: split DGS-1210-10P DTS
Hi Adrian, Thank you very much for the review of these patches, all comments make sense to me, and I would have fixed that all BUT Apparently finding even a single person to actually test this code on older revision or on similar Trendnet device is impossible so I guess the best I can do is to send a single patch adding support for the device I personally have access to, without touching anything else that's already there. Will post it soon. Thank you again for your continued work. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH v4 5/5] realtek: Remove _machine_restart and _machine_halt
Hello, On Sun, Nov 14, 2021 at 07:45:34PM +0100, Sander Vanheule wrote: > By dropping _machine_restart, users can provide more reliable or > device-specific restart modes. For the whole series Tested-by: Paul Fertser The tests were performed on D-Link DGS-1210-10P R1 (RTL8380), both normal restart and forced restart after stopping watchdog were tested, the board is booting normally every time. Thanks a lot! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFT 4/5] realtek: support D-Link DGS-1210-10P H/W:R1
This is an 8 port 1000BASE-T + 2 1000BASE-X SFP gigabit switch with PoE+
support, 65 W budget (using 54 V * 1.574 A = 85 W power supply).
In order to manipulate the PoE+ one needs the realtek-poe package [0].
Specifications
--
* SoC: Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash: Macronix MX25L25645GMI-08G 32 MiB
* RAM: Nanya NT5CC256M8JQ-EK 256 MiB DDR3(L) SDRAM
* Ethernet: 8x 10/100/1000 1000BASE-T
2x 1000BASE-X SFP
* PoE+: Broadcom BCM59121B0KMLG (IEEE 802.3at-2009 compliant)
Controlled by Nuvoton M0516LDE MCU talking undocumented
protocol to the Realtek's second UART
* Buttons: Mode ("lights_toggle") and Reset
* LEDs: Power, PoE Max, Link and PoE software-controlled; per-port
link indication LEDs hardware-controlled
* UART: 2.54 mm header with populated standard pin connector J8
Pin 1: Vcc (3.3 V)
Pin 2: Tx
Pin 3: Rx
Pin 4: GND
Baud and framing: 115200 8n1
Installation
* Configure your client with static 10.90.90.91/24 address.
* Set up a TFTP server on your client and make it serve the initramfs
image. Connect it to port 1 of the switch.
* Connect serial, power up the switch, interrupt U-boot by hitting
Escape after seeing "Power on self test" message
* Download the image onto the device and boot from it:
> tftpboot 0x8f00
10.90.90.91:openwrt-realtek-generic-d-link_dgs-1210-10p-r1-initramfs-kernel.bin
> bootm
* Once OpenWrt has booted reconfigure your client to use VID 100 and DHCP,
scp the sysupgrade image to /tmp and run sysupgrade.
[0]
https://patchwork.ozlabs.org/project/openwrt/patch/20210511152243.1167160-1-j...@phrozen.org/
Signed-off-by: Paul Fertser
---
.../realtek/base-files/etc/board.d/02_network | 7 ++
.../rtl8380_d-link_dgs-1210-10p-r1.dts| 67 +++
target/linux/realtek/image/Makefile | 11 +++
3 files changed, 85 insertions(+)
create mode 100644
target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-r1.dts
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
b/target/linux/realtek/base-files/etc/board.d/02_network
index 58461c9c995f..e7c45de92328 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -48,6 +48,13 @@ done
[ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
case $board in
+d-link,dgs-1210-10p-f1|\
+d-link,dgs-1210-10p-r1)
+ ucidef_set_poe 65 "$lan_list"
+ # once PoE board data is standardised it should also include
+ # max per-port power: 30 W
+ # PoE id numbers: inversed, e.g. lan2 is id 7
+ ;;
netgear,gs110tpp-v1)
ucidef_set_poe 130 "$lan_list"
;;
diff --git a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-r1.dts
b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-r1.dts
new file mode 100644
index ..379e0140bdf0
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-r1.dts
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl8380_d-link_dgs-1210-10.dtsi"
+
+/ {
+ compatible = "d-link,dgs-1210-10p-r1", "realtek,rtl838x-soc";
+ model = "D-Link DGS-1210-10P R1";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x1000>;
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x 0x008>;
+ read-only;
+ };
+
+ partition@8 {
+ label = "u-boot-env";
+ reg = <0x0008 0x004>;
+ read-only;
+ };
+
+ partition@c {
+ label = "u-boot-env2";
+ reg = <0x000c 0x004>;
+ };
+
+ partition@10 {
+ label = "firmware";
+ compatible = "denx,uimage";
+ reg = <0x0010 0x0e8>;
+ };
+
+
[RFT 5/5] realtek: support Trendnet TPE-082WS V1
According to photos and specs for Trendnet TPE-082WS V1.2R it should be
the same as D-Link DGS-1210-10P R1 but with more powerful PSU (90 W) so
the PoE budget is specified as 75 W.
Signed-off-by: Paul Fertser
---
.../realtek/base-files/etc/board.d/02_network | 3 +
.../rtl8380_trendnet_tpe-082ws-v1.dts | 67 +++
target/linux/realtek/image/Makefile | 11 +++
3 files changed, 81 insertions(+)
create mode 100644
target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-082ws-v1.dts
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
b/target/linux/realtek/base-files/etc/board.d/02_network
index e7c45de92328..f8e06aea3510 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -61,6 +61,9 @@ netgear,gs110tpp-v1)
netgear,gs310tp-v1)
ucidef_set_poe 55 "$lan_list"
;;
+trendnet,tpe-082ws-v1)
+ ucidef_set_poe 75 "$lan_list"
+ ;;
zyxel,gs1900-10hp)
ucidef_set_poe 77 "$lan_list"
;;
diff --git a/target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-082ws-v1.dts
b/target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-082ws-v1.dts
new file mode 100644
index ..9b61da7ffccf
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-082ws-v1.dts
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl8380_d-link_dgs-1210-10.dtsi"
+
+/ {
+ compatible = "trendnet,tpe-082ws-v1", "realtek,rtl838x-soc";
+ model = "Trendnet TPE-082WS V1";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x1000>;
+ };
+};
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <5000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x 0x008>;
+ read-only;
+ };
+
+ partition@8 {
+ label = "u-boot-env";
+ reg = <0x0008 0x004>;
+ read-only;
+ };
+
+ partition@c {
+ label = "u-boot-env2";
+ reg = <0x000c 0x004>;
+ };
+
+ partition@10 {
+ label = "firmware";
+ compatible = "denx,uimage";
+ reg = <0x0010 0x0e8>;
+ };
+
+ partition@f8 {
+ label = "kernel2";
+ reg = <0x00f8 0x018>;
+ };
+
+ partition@110 {
+ label = "rootfs2";
+ reg = <0x0110 0x0d0>;
+ };
+
+ partition@1e0 {
+ label = "jffs2";
+ reg = <0x01e0 0x020>;
+ };
+ };
+ };
+};
diff --git a/target/linux/realtek/image/Makefile
b/target/linux/realtek/image/Makefile
index c7238494606e..94f4d91a089a 100644
--- a/target/linux/realtek/image/Makefile
+++ b/target/linux/realtek/image/Makefile
@@ -80,6 +80,17 @@ define Device/d-link_dgs-1210-10p-r1
endef
TARGET_DEVICES += d-link_dgs-1210-10p-r1
+define Device/trendnet_tpe-082ws-v1
+ SOC := rtl8380
+ IMAGE_SIZE := 14848k
+ DEVICE_VENDOR := Trendnet
+ DEVICE_MODEL := TPE-082WS
+ DEVICE_VARIANT := V1
+ # TODO
+ # DEVICE_PACKAGES += realtek-poe
+endef
+TARGET_DEVICES += trendnet_tpe-082ws-v1
+
define Device/d-link_dgs-1210-16
$(Device/d-link_dgs-1210)
DEVICE_MODEL := DGS-1210-16
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFT 3/5] realtek: add non-PoE version of DGS-1210-10 F1
Signed-off-by: Paul Fertser
---
.../rtl8380_d-link_dgs-1210-10-f1.dts | 8 +++
.../rtl8380_d-link_dgs-1210-10-f1.dtsi| 61 +++
.../rtl8380_d-link_dgs-1210-10p-f1.dts| 60 +-
target/linux/realtek/image/Makefile | 10 ++-
4 files changed, 78 insertions(+), 61 deletions(-)
create mode 100644
target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dts
create mode 100644
target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dtsi
diff --git a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dts
b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dts
new file mode 100644
index ..39e76bf470ea
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dts
@@ -0,0 +1,8 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl8380_d-link_dgs-1210-10-f1.dtsi"
+
+/ {
+ compatible = "d-link,dgs-1210-10-f1", "realtek,rtl838x-soc";
+ model = "D-Link DGS-1210-10 F1";
+};
diff --git a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dtsi
b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dtsi
new file mode 100644
index ..c9dd5e77deb6
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dtsi
@@ -0,0 +1,61 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl8380_d-link_dgs-1210-10.dtsi"
+
+/ {
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x800>;
+ };
+};
+
+&spi0 {
+ status = "okay";
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <1000>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x 0x8>;
+ read-only;
+ };
+ partition@8 {
+ label = "u-boot-env";
+ reg = <0x0008 0x4>;
+ read-only;
+ };
+ partition@c {
+ label = "u-boot-env2";
+ reg = <0x000c 0x4>;
+ };
+ partition@28 {
+ label = "firmware";
+ compatible = "denx,uimage";
+ reg = <0x0010 0xd8>;
+ };
+ partition@be8 {
+ label = "kernel2";
+ reg = <0x00e8 0x18>;
+ };
+ partition@100 {
+ label = "sysinfo";
+ reg = <0x0100 0x4>;
+ };
+ partition@104 {
+ label = "rootfs2";
+ reg = <0x0104 0xc0>;
+ };
+ partition@1c4 {
+ label = "jffs2";
+ reg = <0x01c4 0x3c>;
+ };
+ };
+ };
+};
diff --git a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
index 9a301adb935c..a59dc6b60cc7 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
+++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
@@ -1,66 +1,8 @@
// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
-#include "rtl8380_d-link_dgs-1210-10.dtsi"
+#include "rtl8380_d-link_dgs-1210-10-f1.dtsi"
/ {
compatible = "d-link,dgs-1210-10p-f1", "realtek,rtl838x-soc";
model = "D-Link DGS-1210-10P F1";
-
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x800>;
- };
-};
-
-
-&spi0 {
- status = "okay";
-
- flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <1000>;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells
[RFT 2/5] realtek: add all LEDs, buttons and SFP signals to DGS-1210-10
These GPIO numbers were obtained by physically inspecting a DGS-1210-10P
R1 board but should be common for other devices based on same PCB
layout.
Signed-off-by: Paul Fertser
---
.../dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi | 88 +--
1 file changed, 83 insertions(+), 5 deletions(-)
diff --git a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
index c465e7354872..0e9aebda91a9 100644
--- a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
+++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
@@ -23,25 +23,90 @@
compatible = "gpio-leds";
led_power: power {
- // GPIO 0 seems to provide power to the leds
label = "green:power";
gpios = <&gpio0 0 GPIO_ACTIVE_LOW>;
};
+
+ poe_max {
+ label = "yellow:poe_max";
+ gpios = <&gpio1 27 GPIO_ACTIVE_LOW>;
+ };
+
+ link {
+ label = "green:link";
+ gpios = <&gpio1 28 GPIO_ACTIVE_LOW>;
+ };
+
+ poe {
+ label = "green:poe";
+ gpios = <&gpio1 29 GPIO_ACTIVE_LOW>;
+ };
};
keys {
compatible = "gpio-keys-polled";
poll-interval = <20>;
- /* is this pin 30 on the external RTL8231 (&gpio1)? */
- /*mode {
+ mode {
+ label = "mode";
+ gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ reset {
label = "reset";
- gpios = <&gpio0 94 GPIO_ACTIVE_LOW>;
+ gpios = <&gpio1 33 GPIO_ACTIVE_LOW>;
linux,code = ;
- };*/
+ };
+ };
+
+ gpio-restart {
+ compatible = "gpio-restart";
+ gpios = <&gpio1 34 GPIO_ACTIVE_LOW>;
+ open-source;
+ };
+
+ /* i2c of the left SFP cage: port 9 */
+ i2c0: i2c-gpio-0 {
+ compatible = "i2c-gpio";
+ sda-gpios = <&gpio1 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpio1 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ sfp0: sfp-p9 {
+ compatible = "sff,sfp";
+ i2c-bus = <&i2c0>;
+ los-gpio = <&gpio1 9 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpio = <&gpio1 8 GPIO_ACTIVE_LOW>;
+ tx-disable-gpio = <&gpio1 11 GPIO_ACTIVE_HIGH>;
+ };
+
+ /* i2c of the right SFP cage: port 10 */
+ i2c1: i2c-gpio-1 {
+ compatible = "i2c-gpio";
+ sda-gpios = <&gpio1 1 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpio1 2 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ sfp1: sfp-p10 {
+ compatible = "sff,sfp";
+ i2c-bus = <&i2c1>;
+ los-gpio = <&gpio1 4 GPIO_ACTIVE_HIGH>;
+ mod-def0-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
+ tx-disable-gpio = <&gpio1 12 GPIO_ACTIVE_HIGH>;
};
};
+&gpio1 {
+ status = "okay";
+};
+
&uart1 {
status = "okay";
};
@@ -86,6 +151,7 @@
ethernet = <ðernet0>;
reg = <28>;
phy-mode = "internal";
+
fixed-link {
speed = <1000>;
full-duplex;
@@ -93,3 +159,15 @@
};
};
};
+
+&switch0 {
+ ports {
+ port@24 {
+ sfp = <&sfp0>;
+ };
+
+ port@26 {
+ sfp = <&sfp1>;
+ };
+ };
+};
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[RFT 1/5] realtek: split DGS-1210-10P DTS
In preparations to add support for more similar boards the common part
is split into a DTSI.
The model that's currently supported is known to be revision F1 so mark
it accordingly and provide appropriate compatible string for sysupgrade
to work.
Signed-off-by: Paul Fertser
---
...0p.dts => rtl8380_d-link_dgs-1210-10.dtsi} | 60 -
.../rtl8380_d-link_dgs-1210-10p-f1.dts| 66 +++
target/linux/realtek/image/Makefile | 7 +-
3 files changed, 71 insertions(+), 62 deletions(-)
rename target/linux/realtek/dts-5.10/{rtl8382_d-link_dgs-1210-10p.dts =>
rtl8380_d-link_dgs-1210-10.dtsi} (60%)
create mode 100644
target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
diff --git a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
similarity index 60%
rename from target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
rename to target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
index 119eaadc16e6..c465e7354872 100644
--- a/target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts
+++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi
@@ -6,9 +6,6 @@
#include
/ {
- compatible = "d-link,dgs-1210-10p", "realtek,rtl838x-soc";
- model = "D-Link DGS-1210-10P";
-
aliases {
led-boot = &led_power;
led-failsafe = &led_power;
@@ -20,11 +17,6 @@
bootargs = "console=ttyS0,115200";
};
- memory@0 {
- device_type = "memory";
- reg = <0x0 0x800>;
- };
-
leds {
pinctrl-names = "default";
pinctrl-0 = <&pinmux_disable_sys_led>;
@@ -50,58 +42,6 @@
};
};
-
-&spi0 {
- status = "okay";
- flash@0 {
- compatible = "jedec,spi-nor";
- reg = <0>;
- spi-max-frequency = <1000>;
-
- partitions {
- compatible = "fixed-partitions";
- #address-cells = <1>;
- #size-cells = <1>;
-
- partition@0 {
- label = "u-boot";
- reg = <0x 0x8>;
- read-only;
- };
- partition@8 {
- label = "u-boot-env";
- reg = <0x0008 0x4>;
- read-only;
- };
- partition@c {
- label = "u-boot-env2";
- reg = <0x000c 0x4>;
- };
- partition@28 {
- label = "firmware";
- compatible = "denx,uimage";
- reg = <0x0010 0xd8>;
- };
- partition@be8 {
- label = "kernel2";
- reg = <0x00e8 0x18>;
- };
- partition@100 {
- label = "sysinfo";
- reg = <0x0100 0x4>;
- };
- partition@104 {
- label = "rootfs2";
- reg = <0x0104 0xc0>;
- };
- partition@1c4 {
- label = "jffs2";
- reg = <0x01c4 0x3c>;
- };
- };
- };
-};
-
&uart1 {
status = "okay";
};
diff --git a/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
new file mode 100644
index ..9a301adb935c
--- /dev/null
+++ b/target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts
@@ -0,0 +1,66 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl8380_d-link_dgs-1210-10.dtsi"
+
+/ {
+ compatible = "d-link,dgs-1210-10p-f1", "realtek,rtl838x-soc";
+ model = "D-Link DGS-1210-10P F1";
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x800>;
+ };
+};
+
+
+&spi0 {
+ status = "okay";
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+
[RFT 0/5] realtek: support boards similar to DGS-1210-10
I only have D-Link DGS-1210-10P R1 for testing but other devices should be very similar judging by the photos. Would be nice to share support for all the features available rather than get just R1 fully working. Paul Fertser (5): realtek: split DGS-1210-10P DTS realtek: add all LEDs, buttons and SFP signals to DGS-1210-10 realtek: add non-PoE version of DGS-1210-10 F1 realtek: support D-Link DGS-1210-10P H/W:R1 realtek: support Trendnet TPE-082WS V1 .../realtek/base-files/etc/board.d/02_network | 10 + .../rtl8380_d-link_dgs-1210-10-f1.dts | 8 + .../rtl8380_d-link_dgs-1210-10-f1.dtsi| 61 ++ .../dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi | 173 ++ .../rtl8380_d-link_dgs-1210-10p-f1.dts| 8 + .../rtl8380_d-link_dgs-1210-10p-r1.dts| 67 +++ .../rtl8380_trendnet_tpe-082ws-v1.dts | 67 +++ .../dts-5.10/rtl8382_d-link_dgs-1210-10p.dts | 155 target/linux/realtek/image/Makefile | 35 +++- 9 files changed, 427 insertions(+), 157 deletions(-) create mode 100644 target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dts create mode 100644 target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10-f1.dtsi create mode 100644 target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10.dtsi create mode 100644 target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-f1.dts create mode 100644 target/linux/realtek/dts-5.10/rtl8380_d-link_dgs-1210-10p-r1.dts create mode 100644 target/linux/realtek/dts-5.10/rtl8380_trendnet_tpe-082ws-v1.dts delete mode 100644 target/linux/realtek/dts-5.10/rtl8382_d-link_dgs-1210-10p.dts -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek: do not hardcode restart handler and enable gpio-restart
Most boards supported by this target have a dedicated GPIO line
connected to SoC's /RESET to allow full clean reliable reboot.
Use regular kernel notifier methods for default restart routines to
allow higher-priority handlers (such as gpio-restart) to override it.
Signed-off-by: Paul Fertser
---
target/linux/realtek/config-5.10 | 1 +
.../files-5.10/arch/mips/rtl838x/setup.c | 75 ---
2 files changed, 48 insertions(+), 28 deletions(-)
diff --git a/target/linux/realtek/config-5.10 b/target/linux/realtek/config-5.10
index 1b050fc08140..84281df316fd 100644
--- a/target/linux/realtek/config-5.10
+++ b/target/linux/realtek/config-5.10
@@ -156,6 +156,7 @@ CONFIG_PHYLIB=y
CONFIG_PHYLINK=y
CONFIG_PINCTRL=y
CONFIG_POWER_RESET=y
+CONFIG_POWER_RESET_GPIO_RESTART=y
CONFIG_POWER_RESET_SYSCON=y
CONFIG_RATIONAL=y
CONFIG_REALTEK_PHY=y
diff --git a/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
b/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
index 752a85643728..a2de760321de 100644
--- a/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
+++ b/target/linux/realtek/files-5.10/arch/mips/rtl838x/setup.c
@@ -9,6 +9,7 @@
*
*/
+#include
#include
#include
#include
@@ -29,12 +30,20 @@
extern struct rtl83xx_soc_info soc_info;
+static struct notifier_block realtek_restart_handler = {
+.priority = 128,
+};
+
u32 pll_reset_value;
-static void rtl838x_restart(char *command)
+static int rtl838x_restart_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
{
u32 pll = sw_r32(RTL838X_PLL_CML_CTRL);
+ if (mode != SYS_RESTART)
+ return NOTIFY_DONE;
+
pr_info("System restart.\n");
pr_info("PLL control register: %x, applying reset value %x\n",
pll, pll_reset_value);
@@ -45,35 +54,48 @@ static void rtl838x_restart(char *command)
/* Reset Global Control1 Register */
sw_w32(1, RTL838X_RST_GLB_CTRL_1);
+
+ return NOTIFY_DONE;
}
-static void rtl839x_restart(char *command)
+static int rtl839x_restart_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
{
/* SoC reset vector (in flash memory): on RTL839x platform preferred
way to reset */
void (*f)(void) = (void *) 0xbfc0;
+ if (mode != SYS_RESTART)
+ return NOTIFY_DONE;
+
pr_info("System restart.\n");
/* Reset SoC */
sw_w32(0x, RTL839X_RST_GLB_CTRL);
/* and call reset vector */
f();
- /* If this fails, halt the CPU */
- while
- (1);
+
+ return NOTIFY_DONE;
}
-static void rtl930x_restart(char *command)
+static int rtl930x_restart_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
{
+ if (mode != SYS_RESTART)
+ return NOTIFY_DONE;
+
pr_info("System restart.\n");
sw_w32(0x1, RTL930X_RST_GLB_CTRL_0);
- while
- (1);
+
+ return NOTIFY_DONE;
}
-static void rtl931x_restart(char *command)
+static int rtl931x_restart_notify(struct notifier_block *this,
+ unsigned long mode, void *cmd)
{
u32 v;
+ if (mode != SYS_RESTART)
+ return NOTIFY_DONE;
+
pr_info("System restart.\n");
sw_w32(1, RTL931X_RST_GLB_CTRL);
v = sw_r32(RTL931X_RST_GLB_CTRL);
@@ -82,20 +104,14 @@ static void rtl931x_restart(char *command)
sw_w32(v, RTL931X_RST_GLB_CTRL);
msleep(15);
sw_w32(0x101, RTL931X_RST_GLB_CTRL);
-}
-static void rtl838x_halt(void)
-{
- pr_info("System halted.\n");
- while
- (1);
+ return NOTIFY_DONE;
}
static void __init rtl838x_setup(void)
{
- pr_info("Registering _machine_restart\n");
- _machine_restart = rtl838x_restart;
- _machine_halt = rtl838x_halt;
+ pr_info("Registering rtl838x_restart_notify\n");
+ realtek_restart_handler.notifier_call = rtl838x_restart_notify;
/* This PLL value needs to be restored before a reset and will then be
* preserved over a SoC reset. A wrong value prevents the SoC from
@@ -109,9 +125,8 @@ static void __init rtl838x_setup(void)
static void __init rtl839x_setup(void)
{
- pr_info("Registering _machine_restart\n");
- _machine_restart = rtl839x_restart;
- _machine_halt = rtl838x_halt;
+ pr_info("Registering rtl839x_restart_notify\n");
+ realtek_restart_handler.notifier_call = rtl839x_restart_notify;
/* Setup System LED. Bit 14 of RTL839X_LED_GLB_CTRL then allows to
toggle it */
sw_w32_mask(0, 3 << 15, RTL839X_LED_GLB_CTRL);
@@ -119,9 +134,8 @@ static void __init rtl839x_setup(void)
static void __init rtl93
Re: [PATCH v3] realtek: ensure output drivers are enabled in RTL8231
Hello Adrian,
Thank you for taking care about this. One note below.
On Sat, Oct 02, 2021 at 06:37:22PM +0200, Adrian Schmutzler wrote:
> > The bootloader can leave the GPIO expander in a state which doesn't have
> > output drivers enabled so GPIOs will properly work for input but output
> > operations will have no effect.
...
> > Reviewed-by: Sander Vanheule
> > Signed-off-by: Paul Fertser
>
> I added
>
> Fixes: 16ae56b4f9ec ("realtek: fix RTL8231 gpio expander for high GPIOs")
Even though the patch changes the code that was introduced before with
the patch you mention it's not fixing it. Commit 16ae56b4f9ec was
fixing another bug (working with high GPIOs) and it was consistent
with the existing code (that wasn't changing input/output state on
init). However, that clearly leads to GPIOs not being able to work for
output at least on some of the supported targets so if anything it
should have
Fixes: 2b88563ee5aa ("realtek: update the tree to the latest refactored
version")
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v3] realtek: ensure output drivers are enabled in RTL8231
The bootloader can leave the GPIO expander in a state which doesn't have
output drivers enabled so GPIOs will properly work for input but output
operations will have no effect.
To avoid disrupting the boot in case the bootloader left direction and
data registers in an inconsistent state (e.g. pulling SoC's reset to 0)
reconfigure everything as input.
Reviewed-by: Sander Vanheule
Signed-off-by: Paul Fertser
---
Notes:
Changes from v2:
- Fix 5.10 as well
Changes from v1:
- Fix comment to mention we affect two extra GPIOs
- Remove unused "v" declaration.
.../realtek/files-5.10/drivers/gpio/gpio-rtl8231.c | 12 +++-
.../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c| 12 +++-
2 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
b/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
index a8ffcdc31368..f4f5621e0c1b 100644
--- a/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
+++ b/target/linux/realtek/files-5.10/drivers/gpio/gpio-rtl8231.c
@@ -239,8 +239,6 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned int
offset, int value)
int rtl8231_init(struct rtl8231_gpios *gpios)
{
- u32 v;
-
pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios->smi_bus_id);
gpios->reg_cached = 0;
@@ -254,11 +252,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
- /* Select GPIO functionality for pins 0-34 */
+ /* Select GPIO functionality and force input direction for pins 0-36 */
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
- v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
- rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
+
+ /* Set LED_Start to enable drivers for output mode */
+ rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);
return 0;
}
diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
index a8ffcdc31368..f4f5621e0c1b 100644
--- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
+++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
@@ -239,8 +239,6 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned int
offset, int value)
int rtl8231_init(struct rtl8231_gpios *gpios)
{
- u32 v;
-
pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios->smi_bus_id);
gpios->reg_cached = 0;
@@ -254,11 +252,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
- /* Select GPIO functionality for pins 0-34 */
+ /* Select GPIO functionality and force input direction for pins 0-36 */
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
- v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
- rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
+
+ /* Set LED_Start to enable drivers for output mode */
+ rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);
return 0;
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] realtek: ensure output drivers are enabled in RTL8231
The bootloader can leave the GPIO expander in a state which doesn't have
output drivers enabled so GPIOs will properly work for input but output
operations will have no effect.
To avoid disrupting the boot in case the bootloader left direction and
data registers in an inconsistent state (e.g. pulling SoC's reset to 0)
reconfigure everything as input.
Signed-off-by: Paul Fertser
---
Notes:
Changes from v1:
- Fix comment to mention we affect two extra GPIOs
- Remove unused "v" declaration.
.../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c| 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
index a8ffcdc31368..f4f5621e0c1b 100644
--- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
+++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
@@ -239,8 +239,6 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned int
offset, int value)
int rtl8231_init(struct rtl8231_gpios *gpios)
{
- u32 v;
-
pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios->smi_bus_id);
gpios->reg_cached = 0;
@@ -254,11 +252,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
- /* Select GPIO functionality for pins 0-34 */
+ /* Select GPIO functionality and force input direction for pins 0-36 */
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x);
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
- v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
- rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
+ rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff);
+
+ /* Set LED_Start to enable drivers for output mode */
+ rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1);
return 0;
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek: ensure output drivers are enabled in RTL8231
The bootloader can leave the GPIO expander in a state which doesn't have output drivers enabled so GPIOs will properly work for input but output operations will have no effect. To avoid disrupting the boot in case the bootloader left direction and data registers in an inconsistent state (e.g. pulling SoC's reset to 0) reconfigure everything as input. Thanks to Sander Vanheule for telling about LED_Start. Signed-off-by: Paul Fertser --- My previous patch to this part of the code is marked Accepted in the Patchwork so this one is on top of it. Feel free to squash them together. .../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c index a8ffcdc31368..405c2c151368 100644 --- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c +++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c @@ -254,11 +254,15 @@ int rtl8231_init(struct rtl8231_gpios *gpios) sw_w32_mask(3, 1, RTL838X_DMY_REG5); } - /* Select GPIO functionality for pins 0-34 */ + /* Select GPIO functionality and force input direction for pins 0-34 */ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x); + rtl8231_write(gpios, RTL8231_GPIO_DIR(0), 0x); rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x); - v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32)); - rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7); + rtl8231_write(gpios, RTL8231_GPIO_DIR(16), 0x); + rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x03ff); + + /* Set LED_Start to enable drivers for output mode */ + rtl8231_write(gpios, RTL8231_LED_FUNC0, 1 << 1); return 0; } -- 2.17.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] dnsmasq: add explicit "set:" for client-matching options
Bring the usage in line with the dnsmasq man page and the other options
where set: is mandatory.
No functional change.
Signed-off-by: Paul Fertser
---
package/network/services/dnsmasq/files/dnsmasq.init | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
index bea0bc02a2da..f000d5844bcb 100755
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -241,7 +241,7 @@ dhcp_subscrid_add() {
config_get subscriberid "$cfg" subscriberid
[ -n "$subscriberid" ] || return 0
- xappend "--dhcp-subscrid=$networkid,$subscriberid"
+ xappend "--dhcp-subscrid=set:$networkid,$subscriberid"
config_get_bool force "$cfg" force 0
@@ -257,7 +257,7 @@ dhcp_remoteid_add() {
config_get remoteid "$cfg" remoteid
[ -n "$remoteid" ] || return 0
- xappend "--dhcp-remoteid=$networkid,$remoteid"
+ xappend "--dhcp-remoteid=set:$networkid,$remoteid"
config_get_bool force "$cfg" force 0
@@ -274,7 +274,7 @@ dhcp_circuitid_add() {
config_get circuitid "$cfg" circuitid
[ -n "$circuitid" ] || return 0
- xappend "--dhcp-circuitid=$networkid,$circuitid"
+ xappend "--dhcp-circuitid=set:$networkid,$circuitid"
config_get_bool force "$cfg" force 0
@@ -290,7 +290,7 @@ dhcp_userclass_add() {
config_get userclass "$cfg" userclass
[ -n "$userclass" ] || return 0
- xappend "--dhcp-userclass=$networkid,$userclass"
+ xappend "--dhcp-userclass=set:$networkid,$userclass"
config_get_bool force "$cfg" force 0
@@ -307,7 +307,7 @@ dhcp_vendorclass_add() {
config_get vendorclass "$cfg" vendorclass
[ -n "$vendorclass" ] || return 0
- xappend "--dhcp-vendorclass=$networkid,$vendorclass"
+ xappend "--dhcp-vendorclass=set:$networkid,$vendorclass"
config_get_bool force "$cfg" force 0
@@ -323,7 +323,7 @@ dhcp_match_add() {
config_get match "$cfg" match
[ -n "$match" ] || return 0
- xappend "--dhcp-match=$networkid,$match"
+ xappend "--dhcp-match=set:$networkid,$match"
config_get_bool force "$cfg" force 0
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek: add support for D-Link DGS-1210-10P H/W:R1
Hi Adrian, On Fri, Sep 24, 2021 at 11:36:39PM +0200, Adrian Schmutzler wrote: > > Subject: [PATCH] realtek: add support for D-Link DGS-1210-10P H/W:R1 > > Some mostly nitpick comments below. ... Appreciated, all noted, will take everything into account when preparing v2. Chances are we'll have a common dtsi for this R1, the earlier F1 revision (I mostly copied its DTS, so it should eventually be fixed following your comments too) and also for Trendnet TPE-082WS. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] dnsmasq: add match_tag for --dhcp-host
A set of tags can be specified for --dhcp-host option to restrict the
assignment to the requests which match all the tags.
Example usage:
config vendorclass
option networkid 'udhcp'
option vendorclass 'udhcp'
config host
option mac '*:*:*:*:*:*'
list match_tag 'switch.10'
list match_tag 'udhcp'
option ip '192.168.25.10'
Signed-off-by: Paul Fertser
---
package/network/services/dnsmasq/files/dnsmasq.init | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
mode change 100644 => 100755
package/network/services/dnsmasq/files/dnsmasq.init
diff --git a/package/network/services/dnsmasq/files/dnsmasq.init
b/package/network/services/dnsmasq/files/dnsmasq.init
old mode 100644
new mode 100755
index 9748c09b8ee8..bea0bc02a2da
--- a/package/network/services/dnsmasq/files/dnsmasq.init
+++ b/package/network/services/dnsmasq/files/dnsmasq.init
@@ -332,7 +332,7 @@ dhcp_match_add() {
dhcp_host_add() {
local cfg="$1"
- local hosttag nametime addrs duids macs tags
+ local hosttag nametime addrs duids macs tags mtags
config_get_bool force "$cfg" force 0
@@ -357,6 +357,11 @@ dhcp_host_add() {
config_get duid "$cfg" duid
config_get tag "$cfg" tag
+ add_tag() {
+ mtags="${mtags}tag:$1,"
+ }
+ config_list_foreach "$cfg" match_tag add_tag
+
if [ -n "$mac" ]; then
# --dhcp-host=00:20:e0:3b:13:af,192.168.0.199,lap
# many MAC are possible to track a laptop ON/OFF dock
@@ -394,9 +399,9 @@ dhcp_host_add() {
if [ $DNSMASQ_DHCP_VER -eq 6 ]; then
addrs="${ip:+,$ip}${hostid:+,[::$hostid]}"
- xappend
"--dhcp-host=$macs${duids:+,$duids}$hosttag$addrs$nametime"
+ xappend
"--dhcp-host=$mtags$macs${duids:+,$duids}$hosttag$addrs$nametime"
else
- xappend "--dhcp-host=$macs$hosttag${ip:+,$ip}$nametime"
+ xappend "--dhcp-host=$mtags$macs$hosttag${ip:+,$ip}$nametime"
fi
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek-poe: add support for PoE on Realtek switches
Hello John,
Thank you for the rather useful tool. One comment below.
On Tue, May 11, 2021 at 05:22:43PM +0200, John Crispin wrote:
> +/* 0x17 - Set power management mode
> + * 0: None (No Power Management mode) (Default in Semi-Auto mode)
> + * 1: Static Power Management with Port Priority(Default in Automode)
> + * 2: Dynamic Power Management with Port Priority
> + * 3: Static Power Management without Port Priority
> + * 4: Dynamic Power Management without Port Priority
> + */
> +static int
> +poe_cmd_power_mgmt_mode(unsigned char mode)
> +{
> + unsigned char cmd[] = { 0x18, 0x00, mode };
Typo in command number here.
Because of it on D-Link DGS-1210-10P R1 with
"firmware": "v24.33",
"mcu": "Nuvoton M05xx LAN Microcontroller",
the power is never provided, the port status changes between "unknown"
(6):
RX -> 0x2a 0x63 0x00 0x11 0xb6 0x11 0x11 0x11 0x11 0x11 0x11 0xba
and "Searching" (1) when I plug and unplug the cable.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH] realtek: fix RTL8231 gpio expander for high GPIOs
Hi Sander, Thank you for review, it made me think about consistency. On Mon, Sep 20, 2021 at 05:45:06PM +0200, Sander Vanheule wrote: > On Fri, 2021-09-17 at 16:11 +0300, Paul Fertser wrote: > > rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x); > > rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x); > > + rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 7 | (7 << 5)); > > Pins 35-36 cannot serve as LED output, but their GPIO direction can still be > changed. > Since the select bit for pins 35-36 should always read '1' (the GPIO pin > function), this > should probably be: > > rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 0x1f | (0x1f << 5)); So we are not changing the direction for GPIOs 0-31 and it's probably a good thing since probably the bootloader has already configured them in some desired way. Guess the same idea should be applied to high GPIOs too, please see my v2. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] realtek: fix RTL8231 gpio expander for high GPIOs
GPIOs > 31 require special handling. This patch fixes both the
initialisation and direction get/set operations.
Signed-off-by: Paul Fertser
---
Notes:
Changes from v1:
- Do not modify high GPIOs direction bits on init
.../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
index 031f60f5307c..a8ffcdc31368 100644
--- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
+++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
@@ -106,12 +106,11 @@ static int rtl8231_pin_dir(struct rtl8231_gpios *gpios,
u32 gpio, u32 dir)
u32 v;
int pin_sel_addr = RTL8231_GPIO_PIN_SEL(gpio);
int pin_dir_addr = RTL8231_GPIO_DIR(gpio);
- int pin = gpio % 16;
- int dpin = pin;
+ int dpin = gpio % 16;
if (gpio > 31) {
pr_debug("WARNING: HIGH pin\n");
- dpin = pin << 5;
+ dpin += 5;
pin_dir_addr = pin_sel_addr;
}
@@ -140,7 +139,7 @@ static int rtl8231_pin_dir_get(struct rtl8231_gpios *gpios,
u32 gpio, u32 *dir)
if (gpio > 31) {
pin_dir_addr = RTL8231_GPIO_PIN_SEL(gpio);
- pin = pin << 5;
+ pin += 5;
}
v = rtl8231_read(gpios, pin_dir_addr);
@@ -240,6 +239,8 @@ void rtl8231_gpio_set(struct gpio_chip *gc, unsigned int
offset, int value)
int rtl8231_init(struct rtl8231_gpios *gpios)
{
+ u32 v;
+
pr_info("%s called, MDIO bus ID: %d\n", __func__, gpios->smi_bus_id);
gpios->reg_cached = 0;
@@ -253,9 +254,11 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
- /*Select GPIO functionality for pins 0-15, 16-31 and 32-37 */
+ /* Select GPIO functionality for pins 0-34 */
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
+ v = rtl8231_read(gpios, RTL8231_GPIO_PIN_SEL(32));
+ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), v | 0x7);
return 0;
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] realtek: add support for D-Link DGS-1210-10P H/W:R1
This is an 8 port 1000BASE-T + 2 1000BASE-X SFP gigabit switch with PoE+
support, 65 W budget.
In order to manipulate the PoE+ one needs the rtl83xx-poe package [0].
Specifications
--
* SoC: Realtek RTL8380M 500 MHz MIPS 4KEc
* Flash: Macronix MX25L25645GMI-08G 32 MiB
* RAM: Nanya NT5CC256M8JQ-EK 256 MiB DDR3(L) SDRAM
* Ethernet: 8x 10/100/1000 1000BASE-T
2x 1000BASE-X SFP
* PoE+: Broadcom BCM59121B0KMLG (IEEE 802.3at-2009 compliant)
Controlled by Nuvoton M0516LDE MCU talking undocumented
protocol to the Realtek's second UART
* Buttons: Mode ("lights_toggle") and Reset
* LEDs: Power and link indication LEDs are working, others
unsupported.
* UART: 2.54 mm header with populated standard pin connector J8
Pin 1: Vcc (3.3 V)
Pin 2: Tx
Pin 3: Rx
Pin 4: GND
Baud and framing: 115200 8n1
Installation
* Configure your client with static 10.90.90.91/24 address.
* Set up a TFTP server on your client and make it serve the initramfs
image. Connect it to port 1 of the switch.
* Connect serial, power up the switch, interrupt U-boot by hitting
Escape after seeing "Power on self test" message
* Download the image onto the device and boot from it:
> tftpboot 0x8f00
10.90.90.91:openwrt-realtek-generic-d-link_dgs-1210-10p-r1-initramfs-kernel.bin
> bootm
* Once OpenWrt has booted reconfigure your client to use VID 100 and DHCP,
scp the sysupgrade image to /tmp and run sysupgrade.
[0]
https://git.openwrt.org/?p=openwrt/staging/blogic.git;a=tree;f=package/rtl83xx-poe;hb=2540faec92abf8f5e52eae0e77bfbdb47457252d
Signed-off-by: Paul Fertser
---
.../realtek/base-files/etc/board.d/02_network | 3 +
.../dts/rtl8382_d-link_dgs-1210-10p-r1.dts| 205 ++
target/linux/realtek/image/Makefile | 8 +
3 files changed, 216 insertions(+)
create mode 100644 target/linux/realtek/dts/rtl8382_d-link_dgs-1210-10p-r1.dts
diff --git a/target/linux/realtek/base-files/etc/board.d/02_network
b/target/linux/realtek/base-files/etc/board.d/02_network
index 58461c9c995f..fe40f007d29e 100644
--- a/target/linux/realtek/base-files/etc/board.d/02_network
+++ b/target/linux/realtek/base-files/etc/board.d/02_network
@@ -48,6 +48,9 @@ done
[ -n "$label_mac" ] && ucidef_set_label_macaddr $label_mac
case $board in
+d-link,dgs-1210-10p-r1)
+ ucidef_set_poe 65 "$lan_list"
+ ;;
netgear,gs110tpp-v1)
ucidef_set_poe 130 "$lan_list"
;;
diff --git a/target/linux/realtek/dts/rtl8382_d-link_dgs-1210-10p-r1.dts
b/target/linux/realtek/dts/rtl8382_d-link_dgs-1210-10p-r1.dts
new file mode 100644
index ..ef6ad94bb06c
--- /dev/null
+++ b/target/linux/realtek/dts/rtl8382_d-link_dgs-1210-10p-r1.dts
@@ -0,0 +1,205 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include "rtl838x.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "d-link,dgs-1210-10p-r1", "realtek,rtl838x-soc";
+ model = "D-Link DGS-1210-10P-R1";
+
+ aliases {
+ led-boot = &led_power;
+ led-failsafe = &led_power;
+ led-running = &led_power;
+ led-upgrade = &led_power;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200";
+ };
+
+ memory@0 {
+ device_type = "memory";
+ reg = <0x0 0x1000>;
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_power: power {
+ // GPIO 24 seems to provide power to the leds
+ label = "green:power";
+ gpios = <&gpio0 47 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <20>;
+
+ mode {
+ label = "mode";
+ gpios = <&gpio1 30 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+
+ reset {
+ label = "reset";
+ gpios = <&gpio1 33 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+
+ /* i2c of the left SFP cage: port 9 */
+ i2c0: i2c-gpio-0 {
+ compatible = "i2c-gpio";
+ sda-gpios = <&gpio1 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ scl-gpios = <&gpio1 7 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
+ i2c-gpio,delay-us = <2>;
+ #address-cells = <1>;
+ #size-cells = <0>;
+ };
+
+ sfp0: sfp-p9 {
+ com
[PATCH] realtek: fix RTL8231 gpio expander for high GPIOs
GPIOs > 31 require special handling. This patch fixes both the
initialisation (defaulting to input) and direction get/set operations.
Runtime-tested on D-Link DGS-1210-10P-R1 which has "reset" button on
GPIO[33].
Signed-off-by: Paul Fertser
---
.../realtek/files-5.4/drivers/gpio/gpio-rtl8231.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
index 031f60f5307c..ddb8894663ec 100644
--- a/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
+++ b/target/linux/realtek/files-5.4/drivers/gpio/gpio-rtl8231.c
@@ -106,12 +106,11 @@ static int rtl8231_pin_dir(struct rtl8231_gpios *gpios,
u32 gpio, u32 dir)
u32 v;
int pin_sel_addr = RTL8231_GPIO_PIN_SEL(gpio);
int pin_dir_addr = RTL8231_GPIO_DIR(gpio);
- int pin = gpio % 16;
- int dpin = pin;
+ int dpin = gpio % 16;
if (gpio > 31) {
pr_debug("WARNING: HIGH pin\n");
- dpin = pin << 5;
+ dpin += 5;
pin_dir_addr = pin_sel_addr;
}
@@ -140,7 +139,7 @@ static int rtl8231_pin_dir_get(struct rtl8231_gpios *gpios,
u32 gpio, u32 *dir)
if (gpio > 31) {
pin_dir_addr = RTL8231_GPIO_PIN_SEL(gpio);
- pin = pin << 5;
+ pin += 5;
}
v = rtl8231_read(gpios, pin_dir_addr);
@@ -253,9 +252,10 @@ int rtl8231_init(struct rtl8231_gpios *gpios)
sw_w32_mask(3, 1, RTL838X_DMY_REG5);
}
- /*Select GPIO functionality for pins 0-15, 16-31 and 32-37 */
+ /*Select GPIO functionality for pins 0-15, 16-31 and 32-34 */
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(0), 0x);
rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(16), 0x);
+ rtl8231_write(gpios, RTL8231_GPIO_PIN_SEL(32), 7 | (7 << 5));
return 0;
}
--
2.17.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] config/Config-images: fix unit of partition sizes
The code interprets these config values as Mebibytes rather than Megabytes so modify the description accordingly. Signed-off-by: Paul Fertser --- config/Config-images.in | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config/Config-images.in b/config/Config-images.in index 26917267cf..715ba21284 100644 --- a/config/Config-images.in +++ b/config/Config-images.in @@ -280,14 +280,14 @@ menu "Target Images" source "target/linux/*/image/Config.in" config TARGET_KERNEL_PARTSIZE - int "Kernel partition size (in MB)" + int "Kernel partition size (in MiB)" depends on USES_BOOT_PART default 8 if TARGET_apm821xx_sata default 64 if TARGET_bcm27xx default 16 config TARGET_ROOTFS_PARTSIZE - int "Root filesystem partition size (in MB)" + int "Root filesystem partition size (in MiB)" depends on USES_ROOTFS_PART || TARGET_ROOTFS_EXT4FS || TARGET_omap || TARGET_sunxi || TARGET_uml default 104 help -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] ath79/nand: fix factory image generation for Netgear and Zyxel boards
The factory images need to embed specific IDs to pass verification with
the OEM firmware (including TFTP recovery), so they need to be
per-device variables.
Fixes: ab1584a797 ("ath79: netgear: trim down uImage customisations")
Reported-by: Marcin Juszkiewicz
Signed-off-by: Paul Fertser
---
v2: move device variables common to generic and NAND targets to
Makefile (Adrian Schmutzler)
target/linux/ath79/image/Makefile | 2 ++
target/linux/ath79/image/common-netgear.mk | 2 --
target/linux/ath79/image/nand.mk | 2 --
3 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/target/linux/ath79/image/Makefile
b/target/linux/ath79/image/Makefile
index 4a51cf1fbf..6583ae46d4 100644
--- a/target/linux/ath79/image/Makefile
+++ b/target/linux/ath79/image/Makefile
@@ -4,6 +4,8 @@ include $(INCLUDE_DIR)/image.mk
KERNEL_LOADADDR = 0x8006
DEVICE_VARS += LOADER_FLASH_OFFS LOADER_TYPE
+DEVICE_VARS += RAS_ROOTFS_SIZE RAS_BOARD RAS_VERSION
+DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_HW_ID
define Build/combined-image
sh $(TOPDIR)/scripts/combined-image.sh \
diff --git a/target/linux/ath79/image/common-netgear.mk
b/target/linux/ath79/image/common-netgear.mk
index d4f43bbaca..8a74fdc0c9 100644
--- a/target/linux/ath79/image/common-netgear.mk
+++ b/target/linux/ath79/image/common-netgear.mk
@@ -1,5 +1,3 @@
-DEVICE_VARS += NETGEAR_BOARD_ID NETGEAR_HW_ID
-
define Build/netgear-rootfs
mkimage \
-A mips -O linux -T filesystem -C none \
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 37fcb36937..abf269a8ce 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -1,5 +1,3 @@
-DEVICE_VARS += RAS_ROOTFS_SIZE RAS_BOARD RAS_VERSION
-
# attention: only zlib compression is allowed for the boot fs
define Build/zyxel-buildkerneljffs
rm -rf $(KDIR_TMP)/zyxelnbg6716
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79/nand: fix factory image generation for Netgear boards
The factory images need to embed specific IDs to pass verification with
the OEM firmware (including TFTP recovery), so they need to be
per-device variables.
Fixes: ab1584a797 ("ath79: netgear: trim down uImage customisations")
Acked-By: Marcin Juszkiewicz
Signed-off-by: Paul Fertser
---
target/linux/ath79/image/nand.mk | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/target/linux/ath79/image/nand.mk b/target/linux/ath79/image/nand.mk
index 37fcb36937..351239e2b3 100644
--- a/target/linux/ath79/image/nand.mk
+++ b/target/linux/ath79/image/nand.mk
@@ -1,4 +1,4 @@
-DEVICE_VARS += RAS_ROOTFS_SIZE RAS_BOARD RAS_VERSION
+DEVICE_VARS += RAS_ROOTFS_SIZE RAS_BOARD RAS_VERSION NETGEAR_BOARD_ID
NETGEAR_HW_ID
# attention: only zlib compression is allowed for the boot fs
define Build/zyxel-buildkerneljffs
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2 2/2] ipq806x: add support for TP-Link Talon AD7200
From: Gary Cooper Device hardware: https://deviwiki.com/wiki/TP-LINK_AD7200_(Talon) The Talon AD7200 is basically an Archer C2600 with a third PCIe lane and an 802.11ad radio. It looks like the Archers C2600/5400 but the housing is slightly larger. Specifications -- - IPQ8064 dual-core 1400MHz - QCA9988 2.4GHz WiFi - QCA9990 5GHz WiFi - QCA9500 60GHz WiFi - 32MB SPI Flash - 512MiB RAM - 5 GBit Ports (QCA8337) Installation Installation is possible from the OEM web interface. Sysupgrade is possible. TFTP recovery is possible. - Image: AD7200_1.0_tp_recovery.bin Notes - This will be the first 802.11ad device supported by mainline. Signed-off-by: Gary Cooper --- package/firmware/linux-firmware/qca.mk| 8 + package/kernel/mac80211/ath.mk| 13 +- .../ipq806x/base-files/etc/board.d/01_leds| 9 + .../ipq806x/base-files/etc/board.d/02_network | 1 + .../etc/hotplug.d/firmware/11-ath10k-caldata | 2 + .../base-files/lib/upgrade/platform.sh| 1 + .../arch/arm/boot/dts/qcom-ipq8064-ad7200.dts | 440 ++ target/linux/ipq806x/image/Makefile | 15 + tools/firmware-utils/src/tplink-safeloader.c | 44 ++ 9 files changed, 532 insertions(+), 1 deletion(-) create mode 100644 target/linux/ipq806x/files/arch/arm/boot/dts/qcom-ipq8064-ad7200.dts diff --git a/package/firmware/linux-firmware/qca.mk b/package/firmware/linux-firmware/qca.mk index 23fcc0905a..71b484d5c7 100644 --- a/package/firmware/linux-firmware/qca.mk +++ b/package/firmware/linux-firmware/qca.mk @@ -37,3 +37,11 @@ define Package/carl9170-firmware/install $(INSTALL_DATA) $(PKG_BUILD_DIR)/carl9170-1.fw $(1)/lib/firmware endef $(eval $(call BuildPackage,carl9170-firmware)) + +Package/wil6210-firmware = $(call Package/firmware-default,wil6210 firmware) +define Package/wil6210-firmware/install + $(INSTALL_DIR) $(1)/lib/firmware + $(INSTALL_DATA) $(PKG_BUILD_DIR)/wil6210.fw $(1)/lib/firmware + $(INSTALL_DATA) $(PKG_BUILD_DIR)/wil6210.brd $(1)/lib/firmware +endef +$(eval $(call BuildPackage,wil6210-firmware)) diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk index 957c9da939..f8245e24e1 100644 --- a/package/kernel/mac80211/ath.mk +++ b/package/kernel/mac80211/ath.mk @@ -1,6 +1,6 @@ PKG_DRIVERS += \ ath ath5k ath6kl ath6kl-sdio ath6kl-usb ath9k ath9k-common ath9k-htc ath10k \ - carl9170 owl-loader ar5523 + carl9170 wil6210 owl-loader ar5523 PKG_CONFIG_DEPENDS += \ CONFIG_PACKAGE_ATH_DEBUG \ @@ -20,6 +20,7 @@ ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS ATH9K_HTC_DEBUGFS \ ATH10K_DEBUGFS \ CARL9170_DEBUGFS \ + WIL6210_DEBUGFS \ ATH5K_DEBUG \ ATH6KL_DEBUG endif @@ -29,6 +30,7 @@ ifdef CONFIG_PACKAGE_MAC80211_TRACING ATH10K_TRACING \ ATH6KL_TRACING \ ATH_TRACEPOINTS \ + WIL6210_TRACING \ ATH5K_TRACER endif @@ -66,6 +68,7 @@ config-$(call config_package,ath6kl-sdio) += ATH6KL_SDIO config-$(call config_package,ath6kl-usb) += ATH6KL_USB config-$(call config_package,carl9170) += CARL9170 +config-$(call config_package,wil6210) += WIL6210 config-$(call config_package,ar5523) += AR5523 define KernelPackage/ath/config @@ -285,6 +288,14 @@ define KernelPackage/carl9170 AUTOLOAD:=$(call AutoProbe,carl9170) endef +define KernelPackage/wil6210 + $(call KernelPackage/mac80211/Default) + TITLE:=QCA/Wilocity 60g WiFi card wil6210 support + DEPENDS+= @PCI_SUPPORT +kmod-mac80211 +wil6210-firmware + FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/wil6210/wil6210.ko + AUTOLOAD:=$(call AutoProbe,wil6210) +endef + define KernelPackage/owl-loader $(call KernelPackage/mac80211/Default) TITLE:=Owl loader for initializing Atheros PCI(e) Wifi chips diff --git a/target/linux/ipq806x/base-files/etc/board.d/01_leds b/target/linux/ipq806x/base-files/etc/board.d/01_leds index fed821663a..a03a056d83 100755 --- a/target/linux/ipq806x/base-files/etc/board.d/01_leds +++ b/target/linux/ipq806x/base-files/etc/board.d/01_leds @@ -39,6 +39,15 @@ netgear,r7800) ucidef_set_led_switch "wan" "WAN" "white:wan" "switch0" "0x20" ucidef_set_led_ide "esata" "eSATA" "white:esata" ;; +tplink,ad7200) + ucidef_set_led_usbport "usb1" "USB 1" "blue:usb_1" "usb1-port1" "usb2-port1" + ucidef_set_led_usbport "usb2" "USB 2" "blue:usb_3" "usb3-port1" "usb4-port1" + ucidef_set_led_switch "wan" "wan" "blue:wan" "switch0" "0x02" + ucidef_set_led_switch "lan" "lan" "blue:lan" "switch0" "0x3c" + ucidef_set_led_wlan "wlan2g" "wlan2g" "blue:wlan2g" "phy2tpt" + ucidef_set_led_wlan "wlan5g" "wlan5g" "blue:wlan5g" "phy1tpt" + ucidef_set_led_netdev "wlan60g" "wlan60g" "blue:wlan60g" "wlan0" + ;; tplink,c2600) ucidef_set_led_usbport "usb1" "USB 1" "white:usb_2" "usb1-port1" "usb2-port1" ucidef_set_led_usbport "usb2" "USB 2" "whit
[PATCH v2 1/2] mac80211: add 802.11ad-support
From: Gary Cooper
This adds some logic to properly populate defaults in /etc/config/wireless
and support for WPA*-GCMP. TP-Link AD7200, Mikrotik WAP60g, LHGG-60ad, etc
Signed-off-by: Gary Cooper
---
package/base-files/files/sbin/wifi | 1 +
package/kernel/mac80211/files/lib/wifi/mac80211.sh | 6 ++
package/network/services/hostapd/files/hostapd.sh | 8
3 files changed, 15 insertions(+)
diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi
index a8b4451c60..75759b94f3 100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -79,6 +79,7 @@ wifi_fixup_hwmode() {
case "$hwmode" in
11bg) hwmode=bg;;
11a) hwmode=a;;
+ 11ad) hwmode=ad;;
11b) hwmode=b;;
11g) hwmode=g;;
11n*)
diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
index c0fbfbe5a8..3e99f06693 100644
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -88,6 +88,12 @@ detect_mac80211() {
iw phy "$dev" info | grep -q 'VHT Capabilities' &&
htmode="VHT80"
}
+ iw phy "$dev" info | grep -q '\* 5 MHz \[' && {
+ mode_band="ad"
+ channel=$(iw phy "$dev" info | grep '\* 5 MHz \[' |
grep '(disabled)' -v -m 1 | sed 's/[^[]*\[\|\|\].*//g')
+ iw phy "$dev" info | grep -q 'Capabilities:' &&
htmode="HT20"
+ }
+
[ -n "$htmode" ] && ht_capab="set
wireless.radio${devidx}.htmode=$htmode"
path="$(mac80211_phy_to_path "$dev")"
diff --git a/package/network/services/hostapd/files/hostapd.sh
b/package/network/services/hostapd/files/hostapd.sh
index 80e1f7cedf..883b7e0e05 100644
--- a/package/network/services/hostapd/files/hostapd.sh
+++ b/package/network/services/hostapd/files/hostapd.sh
@@ -1312,6 +1312,14 @@ wpa_supplicant_add_network() {
;;
esac
+ case "$wpa_cipher" in
+ GCMP)
+ append network_data "pairwise=GCMP" "$N$T"
+ append network_data "group=GCMP" "$N$T"
+ ;;
+ *) ;;
+ esac
+
[ "$mode" = mesh ] || {
case "$wpa" in
1)
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH v2] ath79: fix ath10k caldata extraction on some D-Link DIR-842 C3 devices
According to forum threads [0][1] and a report on IRC by Doc-Saintly some of those boards have calibration data in a different place. Only one alternative location is known. Without proper board calibration data (board.bin having all 0xff bytes) ath10k firmware still tries to load but crashes on startup with a confusing error message. If you're applying this patch manually on your device do not forget to remove /lib/firmware/ath10k/pre-cal-pci-:00:00.0.bin and reboot to force caldata re-extraction. [0] https://forum.openwrt.org/t/support-for-d-link-dir842-rev-c3/41654 [1] https://forum.openwrt.org/t/d-link-dir-842-cant-access-firmware-upload-form/65454 Signed-off-by: Paul Fertser --- Changes in v2: - Separate out nec,wg1200cr section as those boards do not even have a "reserved" partition (Adrian Schmutzler) .../base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index 25e864ba72..ca994a4e52 100644 --- a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -167,13 +167,18 @@ case "$FIRMWARE" in ;; dlink,dir-842-c1|\ dlink,dir-842-c2|\ - dlink,dir-842-c3|\ - nec,wg1200cr) + dlink,dir-842-c3) caldata_extract "art" 0x5000 0x2f20 + caldata_valid "202f" || caldata_extract "reserved" 0x15000 0x2f20 ath10k_patch_mac $(mtd_get_mac_ascii devdata wlan5mac) ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \ /lib/firmware/ath10k/QCA9888/hw2.0/board.bin ;; + nec,wg1200cr) + caldata_extract "art" 0x5000 0x2f20 + ath10k_patch_mac $(mtd_get_mac_ascii devdata wlan5mac) + ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \ + /lib/firmware/ath10k/QCA9888/hw2.0/board.bin netgear,ex6400|\ netgear,ex7300) caldata_extract "caldata" 0x5000 0x2f20 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] ath79: fix ath10k caldata extraction on some D-Link DIR-842 C3 devices
According to forum threads [0][1] and a report on IRC by Doc-Saintly some of those boards have calibration data in a different place. Only one alternative location is known. Without proper board calibration data (board.bin having all 0xff bytes) ath10k firmware still tries to load but crashes on startup with a confusing error message. If you're applying this patch manually on your device do not forget to remove /lib/firmware/ath10k/pre-cal-pci-:00:00.0.bin and reboot to force caldata re-extraction. [0] https://forum.openwrt.org/t/support-for-d-link-dir842-rev-c3/41654 [1] https://forum.openwrt.org/t/d-link-dir-842-cant-access-firmware-upload-form/65454 Signed-off-by: Paul Fertser --- .../generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata index 25e864ba72..79003929df 100644 --- a/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata +++ b/target/linux/ath79/generic/base-files/etc/hotplug.d/firmware/11-ath10k-caldata @@ -170,6 +170,7 @@ case "$FIRMWARE" in dlink,dir-842-c3|\ nec,wg1200cr) caldata_extract "art" 0x5000 0x2f20 + caldata_valid "202f" || caldata_extract "reserved" 0x15000 0x2f20 ath10k_patch_mac $(mtd_get_mac_ascii devdata wlan5mac) ln -sf /lib/firmware/ath10k/pre-cal-pci-\:00\:00.0.bin \ /lib/firmware/ath10k/QCA9888/hw2.0/board.bin -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[PATCH] mac80211: fix MAC address allocations when local bit set on base addr
Testing with hwsim reveals two problems:
1. phyX/addresses has two addresses and mac80211_get_addr keeps
returning the last one when asked for more;
2. The base address has the local bit set and the operation unsets it.
Fix both.
Fixes: 866790fd827cb0187353cdf484eb46a9b38fb6ba
Reported-by: Zero_Chaos
Signed-off-by: Paul Fertser
---
package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
index 823c68170a..3097a053b8 100644
--- a/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/netifd/wireless/mac80211.sh
@@ -383,7 +383,7 @@ mac80211_generate_mac() {
[ "$mask" = "00:00:00:00:00:00" ] && {
mask="ff:ff:ff:ff:ff:ff";
- [ "$(wc -l < /sys/class/ieee80211/${phy}/addresses)" -gt 1 ] &&
{
+ [ "$(wc -l < /sys/class/ieee80211/${phy}/addresses)" -gt $id ]
&& {
addr="$(mac80211_get_addr "$phy" "$id")"
[ -n "$addr" ] && {
echo "$addr"
@@ -403,7 +403,7 @@ mac80211_generate_mac() {
[ "$((0x$mask1))" -gt 0 ] && {
b1="0x$1"
[ "$id" -gt 0 ] && \
- b1=$(($b1 ^ ((($id - !($b1 & 2)) << 2) | 0x2)))
+ b1=$(($b1 ^ ((($id - !($b1 & 2)) << 2)) | 0x2))
printf "%02x:%s:%s:%s:%s:%s" $b1 $2 $3 $4 $5 $6
return
}
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: ipq806x: add support for TP-Link Talon AD7200
Hey Robert, On Mon, Oct 12, 2020 at 09:52:07AM +0200, Robert Marko wrote: > Paul, where did you get the 802.11ad support code for OpenWrt? I just forwarded Gary's commit to the mailing list as somehow the subscription confirmation mail doesn't get through to him. That said, the commit doesn't feature much 802.11ad specific code, all of the essential parts are available from the upstream projects (kernel driver, hostapd/wpa_supplicant support), Gary just added a bit of glue to enable it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
ipq806x: add support for TP-Link Talon AD7200
From: Gary Cooper
Device hardware: https://deviwiki.com/wiki/TP-LINK_AD7200_(Talon)
The Talon AD7200 is basically an Archer C2600 with larger flash, a third PCIe
lane and an 802.11ad radio. It comes in a different housing reminiscent of the
Archers C3200 and C5400.
Specifications
--
- IPQ8064 dual-core 1400MHz
- QCA9988 2.4GHz WiFi
- QCA9888 5GHz WiFi
- QCA9500 60GHz WiFi
- 256MiB SPI Flash
- 512MiB RAM
- 5 GBit Ports (QCA8337)
Installation
Installation is possible from the OEM web interface.
Sysupgrade is possible.
TFTP recovery is possible.
- Image: AD7200_1.0_tp_recovery.bin
Notes
- This will be the first 802.11ad device supported by mainline.
Signed-off-by: Gary Cooper
---
package/base-files/files/sbin/wifi| 1 +
package/firmware/linux-firmware/qca.mk| 8 +
package/kernel/mac80211/ath.mk| 13 +-
.../mac80211/files/lib/wifi/mac80211.sh | 6 +
.../network/services/hostapd/files/hostapd.sh | 8 +
.../ipq806x/base-files/etc/board.d/01_leds| 9 +
.../ipq806x/base-files/etc/board.d/02_network | 4 +
.../etc/hotplug.d/firmware/11-ath10k-caldata | 2 +
.../base-files/lib/upgrade/platform.sh| 1 +
.../arch/arm/boot/dts/qcom-ipq8064-ad7200.dts | 440 ++
target/linux/ipq806x/image/Makefile | 15 +
tools/firmware-utils/src/tplink-safeloader.c | 44 ++
12 files changed, 550 insertions(+), 1 deletion(-)
create mode 100644
target/linux/ipq806x/files-5.4/arch/arm/boot/dts/qcom-ipq8064-ad7200.dts
diff --git a/package/base-files/files/sbin/wifi
b/package/base-files/files/sbin/wifi
index a8b4451c60..75759b94f3 100755
--- a/package/base-files/files/sbin/wifi
+++ b/package/base-files/files/sbin/wifi
@@ -79,6 +79,7 @@ wifi_fixup_hwmode() {
case "$hwmode" in
11bg) hwmode=bg;;
11a) hwmode=a;;
+ 11ad) hwmode=ad;;
11b) hwmode=b;;
11g) hwmode=g;;
11n*)
diff --git a/package/firmware/linux-firmware/qca.mk
b/package/firmware/linux-firmware/qca.mk
index 23fcc0905a..71b484d5c7 100644
--- a/package/firmware/linux-firmware/qca.mk
+++ b/package/firmware/linux-firmware/qca.mk
@@ -37,3 +37,11 @@ define Package/carl9170-firmware/install
$(INSTALL_DATA) $(PKG_BUILD_DIR)/carl9170-1.fw $(1)/lib/firmware
endef
$(eval $(call BuildPackage,carl9170-firmware))
+
+Package/wil6210-firmware = $(call Package/firmware-default,wil6210 firmware)
+define Package/wil6210-firmware/install
+ $(INSTALL_DIR) $(1)/lib/firmware
+ $(INSTALL_DATA) $(PKG_BUILD_DIR)/wil6210.fw $(1)/lib/firmware
+ $(INSTALL_DATA) $(PKG_BUILD_DIR)/wil6210.brd $(1)/lib/firmware
+endef
+$(eval $(call BuildPackage,wil6210-firmware))
diff --git a/package/kernel/mac80211/ath.mk b/package/kernel/mac80211/ath.mk
index 5db4be8daa..e563fb71fc 100644
--- a/package/kernel/mac80211/ath.mk
+++ b/package/kernel/mac80211/ath.mk
@@ -1,6 +1,6 @@
PKG_DRIVERS += \
ath ath5k ath6kl ath6kl-sdio ath6kl-usb ath9k ath9k-common ath9k-htc
ath10k \
- carl9170 owl-loader ar5523
+ carl9170 wil6210 owl-loader ar5523
PKG_CONFIG_DEPENDS += \
CONFIG_PACKAGE_ATH_DEBUG \
@@ -20,6 +20,7 @@ ifdef CONFIG_PACKAGE_MAC80211_DEBUGFS
ATH9K_HTC_DEBUGFS \
ATH10K_DEBUGFS \
CARL9170_DEBUGFS \
+ WIL6210_DEBUGFS \
ATH5K_DEBUG \
ATH6KL_DEBUG
endif
@@ -29,6 +30,7 @@ ifdef CONFIG_PACKAGE_MAC80211_TRACING
ATH10K_TRACING \
ATH6KL_TRACING \
ATH_TRACEPOINTS \
+ WIL6210_TRACING
ATH5K_TRACER
endif
@@ -66,6 +68,7 @@ config-$(call config_package,ath6kl-sdio) += ATH6KL_SDIO
config-$(call config_package,ath6kl-usb) += ATH6KL_USB
config-$(call config_package,carl9170) += CARL9170
+config-$(call config_package,wil6210) += WIL6210
config-$(call config_package,ar5523) += AR5523
define KernelPackage/ath/config
@@ -284,6 +287,14 @@ define KernelPackage/carl9170
AUTOLOAD:=$(call AutoProbe,carl9170)
endef
+define KernelPackage/wil6210
+ $(call KernelPackage/mac80211/Default)
+ TITLE:=QCA/Wilocity 60g WiFi card wil6210 support
+ DEPENDS+= @PCI_SUPPORT +kmod-mac80211 +wil6210-firmware
+ FILES:=$(PKG_BUILD_DIR)/drivers/net/wireless/ath/wil6210/wil6210.ko
+ AUTOLOAD:=$(call AutoProbe,wil6210)
+endef
+
define KernelPackage/owl-loader
$(call KernelPackage/mac80211/Default)
TITLE:=Owl loader for initializing Atheros PCI(e) Wifi chips
diff --git a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
index c0fbfbe5a8..3e99f06693 100644
--- a/package/kernel/mac80211/files/lib/wifi/mac80211.sh
+++ b/package/kernel/mac80211/files/lib/wifi/mac80211.sh
@@ -88,6 +88,12 @@ detect_mac80211() {
iw phy "$dev" info | grep -q 'VHT Capabilities' &&
htmode="VHT80"
}
+ iw phy "$dev" info | grep -q '\* 5 MHz \[' && {
+
Re: [OpenWrt-Devel] Build error on latest trunk: meson, python, zstd
Hello, On Tue, Jun 09, 2020 at 11:11:06AM +0200, Reiner Karlsberg wrote: > ['/etc/openwrt/WE826/staging_dir/host/bin/python']> is not a valid python or > it is missing setuptools OpenWrt build system checks for Python3 presence in the prereq stage but it doesn't check if it has setuptools installed or not. In other words, your host Python is missing setuptools needed by meson needed by zstd from packages feed. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: add list-enabled/disabled to service function in /etc/profile
On Thu, Jun 04, 2020 at 06:31:36AM -0700, Stan Grishin wrote: > Thanks. Should I replace list-enabled and list-disabled with list, doing this: I'm not sure it's anywhere close to the optimal solution with ubus and jsonfilter, but I'm not well-versed in the area enough to suggest a proper one, sorry. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] base-files: add list-enabled/disabled to service function in /etc/profile
On Thu, Jun 04, 2020 at 02:56:31AM -0700, Stan Grishin wrote:
> If there's a one/two liner to figure out if a service is running or
> not,
ubus call service list '{ "verbose": true, "name": "openvpn" }' | \
jsonfilter -e '@.openvpn.instances["foo"].running
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] wireguard-tools: fix version indicator
On Mon, May 11, 2020 at 05:43:56PM +0300, Paul Fertser wrote: > Probably the right way to solve this would be to have means to > override the default git describe behaviour (and force specific > version string instead) by a configure (or similar) flag. Another (probably sick) idea: after cloning from git OpenWrt can remove original .git/ and add to the archive a fake one with just a single object and tag. I've just checked and it seems to have "git describe --tags" working it's enough to add just three files: refs/tags/ HEAD objects/xx/xx First two files with identical content, the last should be a valid object of type "commit" (no need to store a tree object even though it's referenced from it). To make "git rev-parse --verify --short HEAD" work as expected too one can preserve just the HEAD commit object (not a tree). This way the space requirements to store additional data inside the source archives will be really small. This would require moving and unpacking the pack that's usually created by git fetch --depth=1 and then removing all the objects but one. Does this sound like a plan? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] wireguard-tools: fix version indicator
Hello, I'm not talking about this specific patch but rather about the general problem I'm aware of, in this specific case it might be not applicable. On Mon, May 11, 2020 at 04:25:42PM +0200, Petr Štetiar wrote: > > If we execute `wg --version` we get a diffrent version string that does > > not match with the version string in the openwrt makefile. > > > > Current version string: > > `wireguard-tools vreboot-13159-gac5caa2718 > > -https://git.zx2c4.com/wireguard-tools/` This is clearly the git tag from OpenWrt tree itself. > ok, but I fail to see why this patch should be maintained by OpenWrt, this > looks like it should be fixed upstream. Thanks. Many projects when cloned from a git tree use some variation of "git describe" to embed a meaningful version in the compiled binary. OpenWrt kind of breaks the assumptions because it first does a git clone but then packs an archive with all the sources but not the .git directory. Of course it makes sense to save space on servers and buildbots and whereever the downloads are stored. However, without .git directory the command run by a particular build system will often traverse to the upper directories until it finds the OpenWrt tree .git. Probably the right way to solve this would be to have means to override the default git describe behaviour (and force specific version string instead) by a configure (or similar) flag. That would require collaboration with upstream but will also need some additional tweaks to the OpenWrt package Makefile. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Booting boards with UART attached (was: Re: [PATCH] ramips: mt7621: use lzma-loader for D-Link DIR-860L B1)
Hello, On Mon, Apr 20, 2020 at 11:01:46AM +0200, Szabolcs Hubai wrote: > I have a CP2102 USB to TTL module, and used with "minicom -D /dev/ttyUSB0". > > > Intereestingly, when I connected with serial to the router it was > sometime unstable: > * refuse to start > * freeze at boot soon after: "Error applying setting, reverse things > back" messge I can't tell if it's exactly the problem there but when working with UARTs it's good to keep in mind that Tx idles high and so when you disconnect power from your target you'll have your UART module feeding some current to the SoC's Rx from the module's Tx and that often confuses the hardware. Proper way to fix this would be to feed USB UART module's output buffers from target's Vcc (that's why most UART headers have that pin); the next best option would be to not have target's Rx connected at all (and hotplugging it just before you actually need it); yet another possible way might be to add a 1k (or more) resistor in series to limit this current. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi, On Fri, Apr 10, 2020 at 07:23:44PM +0800, guilin.wang wrote: > now the external single-chip cannot detect the level change of GPIO How often do you really need to feed the watchdog? Why do you have an additional MCU taking care of capturing the level change, what else is it doing? Can this MCU firmware be upgraded without external hardware? > I now suspect that the wdt-gpio delay is too short and the > microcontroller part has not detected a falling edge change. I tried > both toggle and level, With gpio_wdt driver when you're using LEVEL mode the GPIO will be pulsed (high level for 1 us (microsecond!)) each time the watchdog is pinged. With TOGGLE mode the GPIO will be toggled each ping. Default watchdog ping frequency in procd is 5 seconds. You can see more info on [0]. > but unfortunately both failed, and I will continue to test. It's not a matter of testing, it's a matter of understanding what's really going on. HTH [0] https://openwrt.org/docs/guide-user/hardware/watchdog -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] om-watchdog: Add support for GL-X1200 (GL.iNet)
Hi, On Fri, Apr 10, 2020 at 06:55:59PM +0800, guilin.wang wrote: > but found that the dog could not be fed successfully. Why exactly? > Our external microcontroller feeds the dog. The cpu just gives the > microcontroller a trigger signal, but I tested that the > microcontroller cannot detect the level change using this method How is it able to detect the level change using another method then, what exactly makes them different? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] generic: spi-nor: rework broken-flash-reset
Hello, On Mon, Apr 06, 2020 at 07:44:28PM +0800, Chuanhong Guo wrote: > Instead of resetting flash to 3B address on remove hook, this > implementation only enters 4B mode when needed, which prevents more > unexpected reboot stuck. Probably a naive question, but does this have any measurable performance impact? In any case making reboots more reliable is worth it. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Openwrt TpLink Archer D2
Hello, On Mon, Apr 06, 2020 at 07:05:44PM +0200, Martin Heck via openwrt-devel wrote: > i have a Tp Link Archer D2 Router This page https://openwrt.org/toh/tp-link/archer_d2_ac750 tells me it has 64 MiB RAM. > DDR size from 0xa000 - 0xa3ff This confirms the size. > DRAM: 64 MiB And this. > [ 0.00] MIPS: machine is TP-LINK Archer VR200v > [ 0.00] Determined physical RAM map: > [ 0.00] memory: 07f0 @ (usable) But this is from a 128 MiB device. So you get this: > [ 0.00] Data bus error, epc == 806352b0, ra == 80635278 -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v1] umdns: suppress address-of-packed-member warning
Hello,
On Sat, Apr 04, 2020 at 09:27:34AM +0100, Kevin Darbyshire-Bryant wrote:
> dns.c:261:2: error: converting a packed ‘struct dns_question’ pointer
> (alignment 1) to a ‘uint16_t’ {aka ‘short unsigned int’} pointer
> (alignment 2) may result in an unaligned pointer value
> [-Werror=address-of-packed-member]
>
> 261 | uint16_t *swap = (uint16_t *) q;
>
> Work around what I think is a false positive by turning the warning off.
It seems that packed structures have no alignment guarantees at all
(beyond the size they're packed for), so even the first member can't
be used like that. So the warning looks legit?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How can I include strace into the firmware?
On Tue, Mar 24, 2020 at 08:08:08PM +0900, Jeonghum Joh wrote: > Do you have some suggestion for me? opkg update before trying to install -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] How can I include strace into the firmware?
Hello, On Tue, Mar 24, 2020 at 07:39:05PM +0900, Jeonghum Joh wrote: > I'd like to use "strace" in openwrt firmware. Just install "strace" package, it's in base. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: move lzma-loader to the end of available RAM
Hi, On Tue, Jan 21, 2020 at 10:48:28PM +0100, m...@adrianschmutzler.de wrote: > I can't tell you why overwrite works this direction without further > research though. "If a variable has been set with a command argument (*note Overriding Variables: Overriding.), then ordinary assignments in the makefile are ignored." info make 6.7 The 'override' Directive -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Replying to old mails (Was: Re: [OpenWrt-Devel, v5, 2/2] Allow sysupgrade restore on ER)
Hi, Somewhat related, On Fri, Jan 03, 2020 at 01:34:43PM +0100, m...@adrianschmutzler.de wrote: > I do not have the old e-mails for those changes, thus I cannot respond > correctly. One can do wget http://lists.infradead.org/mailman/private/openwrt-devel.mbox/openwrt-devel.mbox?username=\&password= to retrieve full mailing list archive in mailbox format and use his/her favourite MUA to comfortably reply to any given mail. Also, the patchwork shows Message ID clearly, so if your MUA allows setting of In-Reply-To header you can do that even without using the mailing list archive (I demonstrate this in this very mail, using Mutt and :set edit_headers option). > Still, both (very old) patches miss commit message and, more importantly, > Signed-off, so I will mark them as "Changes Requested". -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Preserving configs over sysupgrade on ath79/tiny broken for some boards (on 19.07 and master), possible solutions
Hello David, On Tue, Dec 31, 2019 at 04:20:29PM +0100, David Bauer wrote: > > If no users speak up probably it's better to remove all the support > > code altogether to avoid wasting maintainers' time on it? > > The code is not really an issue, as there's not much code dedicated for 4M > devices. It's mostly their device-tree, which is maintainable compared to the > previous > ar71xx boardfiles. It's still an effort. People spend time writing patches, reviewers spend time reviewing, maintainers spend time merging and we're now spending time discussing. > As many people still use these 4M devices Judging by the amount of replies from active users to my mail (apparently zero), not many. Probably those who're using do not plan to upgrade firmware so can't care less. Probably they're perfectly fine with sysupgrade not keeping configs on those odd inconsistent tplink boards. If they are not speaking up, I'd say keeping the target is actually harmful. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Preserving configs over sysupgrade on ath79/tiny broken for some boards (on 19.07 and master), possible solutions
Hello gents, On Mon, Dec 30, 2019 at 02:41:12PM +0100, Piotr Dymacz wrote: > > On 12/30/19 12:42 PM, Jo-Philipp Wich wrote: > > > Hi, > > > > > > given that (binary release) support for 4MB devices will end with 19.07, > > > I'd vote for reverting the 4K sector change in ath79 and stick with 64K > > > ones as common denominator across the entire target. That will be the > > > least invasive and most robust fix. > > > > +1 > > > > IMHO this change is way to crucial to have it introduced this short before > > the release is built. People who built images for their devices can > > introduce > > 4K sectors to their own images. This way, we do't risk breaking boards. > > +1 Are any of you using the affected TP-Link boards or ath79/tiny or 4 MiB devices in general? What features do you actually pack in them? Do you plan to continue doing so past 19.XX release? If no users speak up probably it's better to remove all the support code altogether to avoid wasting maintainers' time on it? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Preserving configs over sysupgrade on ath79/tiny broken for some boards (on 19.07 and master), possible solutions
Hi, Status quo summary: Many ath79/tiny devices will lose configs (almost) each time sysupgrading. This is easy to fix for most of the boards that consistently have compatible flash memory ICs (some TP-Links are not elements of this set). The only easy fix for all the boards is to revert the 4K sectors patch. Rationale for using 4K erase sectors: OpenWrt uses jffs2 filesystem for storing ssh host key, config files and other auxilary information across reboots. For that to work at least 5 erase blocks are needed. With regular 64 KiB sectors that means your rootfs_data partition needs to be at least 320 KiB big. This is clearly much more than enough, and you'll have to sacrifice some of the features when packing your rootfs. Some flash memory chips allow using 4 KiB erase sectors so the minimal rootfs_data partition size becomes 20 KiB (in theory). An example of why I think that is useful: I built a regular image (sans PPP and LuCI) for my 4 MiB ath79 device with dnsmasq DNSSEC, SQM, 6in4 and udpxy. The whole firmware partition is 3776 KiB, of which 1442350 bytes go to kernel, 2424274 to rootfs and 116 KiB to rootfs_data. With regular configuration 40 KiB of it are used, and 76 are free. And the system still has opkg so that I can easily install tcpdump-mini or other diagnostic utilities to /tmp. This wouldn't be possible (at least not with SQM) if I was using 64 KiB erase blocks on this device. Sysupgrade problem description: During the upgrade process the saved configuration files are written to the flash starting from the erase marker added to the sysupgrade image during the pad-rootfs build image stage. If there is a mismatch between BLOCKSIZE specified in the Makefile for the specific board and erase block size as determined by the kernel by reading the flash memory JEDEC ID and checking its capabilities from a table in spi-nor driver then the erase marker will likely be misaligned. I've compiled the list of all the ath79/tiny devices so that proper BLOCKSIZE could be specified but faced an issue with some TP-Link boards that according to certain sources can have factory memory with different capabilities. The full list is at the end of this mail. Possible solutions that come to mind: 1. Revert to using 64 KiB erase sectors on all ath79/tiny devices; 2. Fix BLOCKSIZE for those boards that are consistent, document possible config loss for the others; 3. Change sysupgrade in a way to either: 3.1. When seeing the erase marker automatically align it to the nearest erase sector boundary and act accordingly; 3.2. Ignore erase markers not placed at the runtime-detected erase sector boundaries; make build system emit those at both 4K and 64K locations; 3.3. Port kernel squashfs splitter logic to sysupgrade to make it find the right place for the erase marker (or jffs2 with configs) fully on its own. That's how I see it, please fix me where I am wrong. List of the ath79/tiny boards with references: Buffalo WHR-G301N http://openwrtwlan.blogspot.com/2012/11/wzr-g301ntftp.html mx25l3205d SECT_4K DIR-615 E4 https://forum.archive.openwrt.org/viewtopic.php?id=52823 mx25l3205d SECT_4K PQI Air-Pen http://www.srchack.org/article.php?story=20180924234149309 s25fl064k 8 MiB (not important since 4K sectors not used on 8 MiB) Netgear WNR612 v2 https://openwrt.org/toh/netgear/wnr612v2 mx25l3205d SECT_4K On Networks N150R (rebranded Netgear WNR612v2) https://git.openwrt.org/?p=openwrt/openwrt.git;a=commit;h=b6e1cbd8dd5b8fe3833547480abdbd57edb3238c mx25l3205d SECT_4K Netgear WNR1000 v2 https://gist.github.com/SaltwaterC/ef49c8a4df81c8896153 w25q32 SECT_4K Netgear WNR2000 v3 https://oldwiki.archive.openwrt.org/toh/netgear/wnr2000 mx25l3206e (same JEDEC ID as mx25l3205d) SECT_4K TP-Link TL-MR10U https://openwrt.org/toh/tp-link/tl-mr10u Spansion FL032PIF 32Mbit or Eon EN25Q32B 64 KiB sectors TP-Link TL-MR3020 v1 https://openwrt.org/toh/tp-link/tl-mr3020 S25FL032P 64 KiB sectors TP-Link TL-MR3040 v2 https://openwrt.org/toh/tp-link/tl-mr3040 S25FL032P 64 KiB sectors TP-Link TL-MR3220 v1 https://www.kaskus.co.id/show_post/58181950d9d77097618b4569/791/- s25sl032p 64 KiB sectors TP-Link TL-MR3420 v1 https://openwrt.org/toh/tp-link/tl-mr3420 v1: MX25L3206E; v1.1: F32-100HIP; v1.2: W25Q32BV/FL032PIF v1: SECT_4K; v1.1: SECT_4K; v1.1: SECT_4/64 KiB TP-Link TL-MR3420 v2 https://openwrt.org/toh/tp-link/tl-mr3420 v2.3 winbond or spansion? ??? TP-Link TL-WA901ND v2 https://openwrt.org/toh/tp-link/tl-wa901nd s25sl032a 64 KiB sectors TP-Link TL-WR703N https://openwrt.org/toh/tp-link/tl-wr703n s25sl032a 64 KiB sectors TP-Link TL-WR740N v1/v2 https://openwrt.org/toh/tp-link/tl-wr740n en25q32b 64 KiB sectors TP-Link TL-WR740N v3 ? https://eko.one.pl/forum/viewtopic.php?id=14257 ? en25f32 4k? ??? ??? TP-Link TL-WR740N v4 http://bkil.blogspot.com/2014/12/tftp-secret-of-tl-wr740n-uncovered.html s25sl032p 64 KiB sectors TP-Link TL-WR741N/ND v1/v2 v1: ??? v2.4: https://openwrt.org/_media/media/tplink/tp-link-v2.4
[OpenWrt-Devel] [PATCH v2] ath79: tp-link: use ath10k-ct-smallbuffers for 64 MiB devices
Signed-off-by: Paul Fertser --- target/linux/ath79/image/generic-tp-link.mk | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 8a030492c5..97c4bb9441 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -195,8 +195,8 @@ define Device/tplink_archer-d50-v1 DEVICE_VENDOR := TP-Link DEVICE_MODEL := Archer D50 DEVICE_VARIANT := v1 - DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct \ - ath10k-firmware-qca988x-ct + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport \ + kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct BOARDNAME := ARCHER-D50-V1 IMAGE_SIZE := 7808k TPLINK_HWID := 0xC121 @@ -366,7 +366,7 @@ define Device/tplink_re450-v2 IMAGE_SIZE := 6016k DEVICE_MODEL := RE450 DEVICE_VARIANT := v2 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct TPLINK_HWID := 0x0 TPLINK_HWREV := 0 TPLINK_BOARD_ID := RE450-V2 @@ -576,8 +576,9 @@ define Device/tplink_tl-wr902ac-v1 SOC := qca9531 DEVICE_MODEL := TL-WR902AC DEVICE_VARIANT := v1 - DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct \ - ath10k-firmware-qca9887-ct -swconfig -uboot-envtools + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport \ + kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9887-ct \ + -swconfig -uboot-envtools TPLINK_BOARD_ID := TL-WR902AC-V1 IMAGE_SIZE := 7360k TPLINK_HWID := 0x0 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: tp-link: use ath10k-ct-smallbuffers for 64 MiB devices
On Tue, Dec 24, 2019 at 09:27:21PM +0100, Lech Perczak wrote: > > On Tue, Dec 24, 2019 at 08:26:09PM +0100, Lech Perczak wrote: > > > I think that TL-WR902AC v1 should be included as well, as it is 64M device > > > and I also experienced issues with ath10k-ct on it while porting. > > Device like that requires the tweak, no doubt. But I'm not feeling > > like going through the whole ar71xx target since it's deprecated > > anyway and whoever cares should port the needed boards to ath79 AFAIK. > > > This device was just ported to ath79 recently. Indeed, it got right in-between. I'll send an amendment to this tp-link patch, thanks for noticing! > I think grepping by device trees could be used to determine devices which > need the changes. I have an impression that RAM amount is autodetected, so grepping through DTSes can't help here. In any case, I think it's all covered by now. Thank you! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] use strncpy instead of strcpy
Hi, On Tue, Dec 24, 2019 at 10:02:13AM -0800, Khem Raj wrote: > + hdr->name[strlen((char*)hdr->name)] = '\0'; > + strncpy((char *) hdr->name, (const char *)name, > strlen((char*)hdr->name)); strlen((char*)hdr->name) doesn't seem to be meaningful in this context, are you sure you were not meaning to do something like this instead? + strncpy((char *) hdr->name, (const char *)name, sizeof(hdr->name)); + hdr->name[sizeof(hdr->name) - 1] = '\0'; -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ipq40xx: use ath10k-ct-smallbuffers for 128 MiB devices
Signed-off-by: Paul Fertser --- target/linux/ipq40xx/image/Makefile | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/target/linux/ipq40xx/image/Makefile b/target/linux/ipq40xx/image/Makefile index fada35a49d..1fe563c7a5 100644 --- a/target/linux/ipq40xx/image/Makefile +++ b/target/linux/ipq40xx/image/Makefile @@ -128,7 +128,8 @@ define Device/asus_rt-ac58u # string and call it a day Yeah, we do the latter! UIMAGE_NAME:=$(shell echo -e '\03\01\01\01RT-AC58U') IMAGES := sysupgrade.bin - DEVICE_PACKAGES := kmod-usb-ledtrig-usbport + DEVICE_PACKAGES := -kmod-ath10k-ct kmod-ath10k-ct-smallbuffers \ + kmod-usb-ledtrig-usbport endef TARGET_DEVICES += asus_rt-ac58u @@ -494,6 +495,7 @@ define Device/zyxel_wre6606 DEVICE_DTS := qcom-ipq4018-wre6606 IMAGES := sysupgrade.bin IMAGE/sysupgrade.bin := append-kernel | append-rootfs | pad-rootfs | append-metadata + DEVICE_PACKAGES := -kmod-ath10k-ct kmod-ath10k-ct-smallbuffers endef TARGET_DEVICES += zyxel_wre6606 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: tp-link: use ath10k-ct-smallbuffers for 64 MiB devices
Signed-off-by: Paul Fertser --- target/linux/ath79/image/generic-tp-link.mk | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 8a030492c5..f4e16e6e43 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -195,8 +195,8 @@ define Device/tplink_archer-d50-v1 DEVICE_VENDOR := TP-Link DEVICE_MODEL := Archer D50 DEVICE_VARIANT := v1 - DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct \ - ath10k-firmware-qca988x-ct + DEVICE_PACKAGES := kmod-usb2 kmod-usb-ledtrig-usbport \ + kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct BOARDNAME := ARCHER-D50-V1 IMAGE_SIZE := 7808k TPLINK_HWID := 0xC121 @@ -366,7 +366,7 @@ define Device/tplink_re450-v2 IMAGE_SIZE := 6016k DEVICE_MODEL := RE450 DEVICE_VARIANT := v2 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct TPLINK_HWID := 0x0 TPLINK_HWREV := 0 TPLINK_BOARD_ID := RE450-V2 -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH for-19.07] ath79: use ath10k-ct-smallbuffers for 64 MiB devices
Signed-off-by: Paul Fertser --- target/linux/ath79/image/generic-tp-link.mk | 14 +++--- target/linux/ath79/image/generic-ubnt.mk| 8 target/linux/ath79/image/generic.mk | 6 +++--- 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index 468117aad4..304304799d 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -17,7 +17,7 @@ define Device/tplink_archer-c2-v3 ATH_SOC := qca9563 IMAGE_SIZE := 7808k DEVICE_TITLE := TP-Link Archer C2 v3 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9887-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9887-ct TPLINK_BOARD_ID := ARCHER-C2-V3 endef TARGET_DEVICES += tplink_archer-c2-v3 @@ -28,7 +28,7 @@ define Device/tplink_archer-c25-v1 IMAGE_SIZE := 7808k DEVICE_TITLE := TP-Link Archer C25 v1 TPLINK_BOARD_ID := ARCHER-C25-V1 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9887-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9887-ct SUPPORTED_DEVICES += archer-c25-v1 endef TARGET_DEVICES += tplink_archer-c25-v1 @@ -39,7 +39,7 @@ define Device/tplink_archer-c58-v1 IMAGE_SIZE := 7936k DEVICE_TITLE := TP-Link Archer C58 v1 TPLINK_BOARD_ID := ARCHER-C58-V1 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9888-ct SUPPORTED_DEVICES += archer-c58-v1 endef TARGET_DEVICES += tplink_archer-c58-v1 @@ -61,7 +61,7 @@ define Device/tplink_archer-c60-v1 IMAGE_SIZE := 7936k DEVICE_TITLE := TP-Link Archer C60 v1 TPLINK_BOARD_ID := ARCHER-C60-V1 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9888-ct SUPPORTED_DEVICES += archer-c60-v1 endef TARGET_DEVICES += tplink_archer-c60-v1 @@ -72,7 +72,7 @@ define Device/tplink_archer-c60-v2 IMAGE_SIZE := 7808k DEVICE_TITLE := TP-Link Archer C60 v2 TPLINK_BOARD_ID := ARCHER-C60-V2 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9888-ct SUPPORTED_DEVICES += archer-c60-v2 endef TARGET_DEVICES += tplink_archer-c60-v2 @@ -171,7 +171,7 @@ TARGET_DEVICES += tplink_cpe210-v3 define Device/tplink_archer-d50-v1 ATH_SOC := qca9531 DEVICE_TITLE := TP-Link Archer D50 v1 - DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct BOARDNAME := ARCHER-D50-V1 IMAGE_SIZE := 7808k TPLINK_HWID := 0xC121 @@ -206,7 +206,7 @@ define Device/tplink_re450-v2 ATH_SOC := qca9563 IMAGE_SIZE := 6016k DEVICE_TITLE := TP-Link RE450 v2 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct TPLINK_HWID := 0x0 TPLINK_HWREV := 0 TPLINK_BOARD_ID := RE450-V2 diff --git a/target/linux/ath79/image/generic-ubnt.mk b/target/linux/ath79/image/generic-ubnt.mk index 6601986e08..8bc4523f46 100644 --- a/target/linux/ath79/image/generic-ubnt.mk +++ b/target/linux/ath79/image/generic-ubnt.mk @@ -128,7 +128,7 @@ TARGET_DEVICES += ubnt_nanostation-m-xw define Device/ubnt_lap-120 $(Device/ubnt-wa) DEVICE_TITLE := Ubiquiti LiteAP ac (LAP-120) - DEVICE_PACKAGES += kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES += kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct IMAGE_SIZE := 15744k IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | mkubntimage-split endef @@ -137,7 +137,7 @@ TARGET_DEVICES += ubnt_lap-120 define Device/ubnt_nanobeam-ac $(Device/ubnt-wa) DEVICE_TITLE := Ubiquiti NanoBeam AC - DEVICE_PACKAGES += kmod-ath10k-ct ath10k-firmware-qca988x-ct rssileds + DEVICE_PACKAGES += kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct rssileds IMAGE_SIZE := 15744k IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | mkubntimage-split endef @@ -146,7 +146,7 @@ TARGET_DEVICES += ubnt_nanobeam-ac define Device/ubnt_nanostation-ac $(Device/ubnt-wa) DEVICE_TITLE := Ubiquiti Nanostation AC - DEVICE_PACKAGES += kmod-ath10k-ct ath10k-firmware-qca988x-ct rssileds + DEVICE_PACKAGES += kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct rssileds IMAGE_SIZE := 15744k IMAGE/factory.bin := $$(IMAGE/sysupgrade.bin) | mkubntimage-split endef @@ -155,7 +155,7 @@ TARGET_DEVICES += ubnt_nanostation-ac define Device/ubnt_nanostation-ac-loco $(Device/ubnt-wa) DEVICE_TITLE := Ubiquiti Nanostation AC loco - DEVICE_PACKAGES += kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES += kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct IMAGE_SIZE := 15744k IMAGE
Re: [OpenWrt-Devel] [PATCH v3] kernel: ath10k-ct: provide a build variant for small RAM devices
Hi Bjørn, On Mon, Dec 23, 2019 at 10:17:11AM +0100, Bjørn Mork wrote: > Paul Fertser writes: > > --- /dev/null > > +++ > > b/package/kernel/ath10k-ct/patches/960-0011-ath10k-limit-pci-buffer-size.patch > > @@ -0,0 +1,100 @@ > > +--- a/ath10k-4.19/pci.c > > b/ath10k-4.19/pci.c > > +@@ -142,7 +142,11 @@ static struct ce_attr host_ce_config_wla > > + .flags = CE_ATTR_FLAGS, > > + .src_nentries = 0, > > + .src_sz_max = 2048, > > ++#ifndef CONFIG_ATH10K_SMALLBUFFERS > > + .dest_nentries = 512, > > ++#else > > ++ .dest_nentries = 128, > > ++#endif > > + .recv_cb = ath10k_pci_htt_htc_rx_cb, > > + }, > > + > > Why not replace the magic numbers with a macro? Then you could get away > with *one* "if configx then this else that"? And preferably put it in a > header file. There're different values for different buffers so there can't be a single number to fit them all. And I do not see how adding 4 different defines just for the sake of it would make sense there. > Or maybe these things even could be made runtime configurable? Buffers > of this size really should be IMHO, as there is no way to make one size > fit all. As demonstrated... This was already discussed, please see [0]. I think adding a kernel module parameter would make sense for this but it's also much more complicated than just adding two patches that were already used in OpenWrt for many years. So far nobody volunteered to do that, and I wanted to provide at least some semi-sane solution for the upcoming release. [0] https://patchwork.ozlabs.org/comment/2322701/ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: use ath10k-ct-smallbuffers for 64 MiB devices
Signed-off-by: Paul Fertser --- These should be all the affected ath79 devices. There're also some in ipq40xx and ipq806x. And, of course, plenty in ar71xx, not sure if it's worth caring about those. target/linux/ath79/image/generic-tp-link.mk | 10 +- target/linux/ath79/image/generic-ubnt.mk| 10 +- target/linux/ath79/image/generic.mk | 8 3 files changed, 14 insertions(+), 14 deletions(-) diff --git a/target/linux/ath79/image/generic-tp-link.mk b/target/linux/ath79/image/generic-tp-link.mk index cc5c13b919..8a030492c5 100644 --- a/target/linux/ath79/image/generic-tp-link.mk +++ b/target/linux/ath79/image/generic-tp-link.mk @@ -20,7 +20,7 @@ define Device/tplink_archer-c2-v3 IMAGE_SIZE := 7808k DEVICE_MODEL := Archer C2 DEVICE_VARIANT := v3 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9887-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9887-ct TPLINK_BOARD_ID := ARCHER-C2-V3 endef TARGET_DEVICES += tplink_archer-c2-v3 @@ -32,7 +32,7 @@ define Device/tplink_archer-c25-v1 DEVICE_MODEL := Archer C25 DEVICE_VARIANT := v1 TPLINK_BOARD_ID := ARCHER-C25-V1 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9887-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9887-ct SUPPORTED_DEVICES += archer-c25-v1 endef TARGET_DEVICES += tplink_archer-c25-v1 @@ -56,7 +56,7 @@ define Device/tplink_archer-c58-v1 DEVICE_MODEL := Archer C58 DEVICE_VARIANT := v1 TPLINK_BOARD_ID := ARCHER-C58-V1 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9888-ct SUPPORTED_DEVICES += archer-c58-v1 endef TARGET_DEVICES += tplink_archer-c58-v1 @@ -119,7 +119,7 @@ define Device/tplink_archer-c60-v1 DEVICE_MODEL := Archer C60 DEVICE_VARIANT := v1 TPLINK_BOARD_ID := ARCHER-C60-V1 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9888-ct SUPPORTED_DEVICES += archer-c60-v1 endef TARGET_DEVICES += tplink_archer-c60-v1 @@ -131,7 +131,7 @@ define Device/tplink_archer-c60-v2 DEVICE_MODEL := Archer C60 DEVICE_VARIANT := v2 TPLINK_BOARD_ID := ARCHER-C60-V2 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca9888-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca9888-ct SUPPORTED_DEVICES += archer-c60-v2 endef TARGET_DEVICES += tplink_archer-c60-v2 diff --git a/target/linux/ath79/image/generic-ubnt.mk b/target/linux/ath79/image/generic-ubnt.mk index 760d5be196..8a45fb09d1 100644 --- a/target/linux/ath79/image/generic-ubnt.mk +++ b/target/linux/ath79/image/generic-ubnt.mk @@ -122,7 +122,7 @@ define Device/ubnt_lap-120 $(Device/ubnt-wa) DEVICE_MODEL := LiteAP ac DEVICE_VARIANT := LAP-120 - DEVICE_PACKAGES += kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES += kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct endef TARGET_DEVICES += ubnt_lap-120 @@ -130,28 +130,28 @@ define Device/ubnt_litebeam-ac-gen2 $(Device/ubnt-wa) DEVICE_MODEL := LiteBeam AC DEVICE_VARIANT := Gen2 - DEVICE_PACKAGES := kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES := kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct endef TARGET_DEVICES += ubnt_litebeam-ac-gen2 define Device/ubnt_nanobeam-ac $(Device/ubnt-wa) DEVICE_MODEL := NanoBeam AC - DEVICE_PACKAGES += kmod-ath10k-ct ath10k-firmware-qca988x-ct rssileds + DEVICE_PACKAGES += kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct rssileds endef TARGET_DEVICES += ubnt_nanobeam-ac define Device/ubnt_nanostation-ac $(Device/ubnt-wa) DEVICE_MODEL := Nanostation AC - DEVICE_PACKAGES += kmod-ath10k-ct ath10k-firmware-qca988x-ct rssileds + DEVICE_PACKAGES += kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct rssileds endef TARGET_DEVICES += ubnt_nanostation-ac define Device/ubnt_nanostation-ac-loco $(Device/ubnt-wa) DEVICE_MODEL := Nanostation AC loco - DEVICE_PACKAGES += kmod-ath10k-ct ath10k-firmware-qca988x-ct + DEVICE_PACKAGES += kmod-ath10k-ct-smallbuffers ath10k-firmware-qca988x-ct endef TARGET_DEVICES += ubnt_nanostation-ac-loco diff --git a/target/linux/ath79/image/generic.mk b/target/linux/ath79/image/generic.mk index 10bd40abc1..18dad80d5d 100644 --- a/target/linux/ath79/image/generic.mk +++ b/target/linux/ath79/image/generic.mk @@ -273,7 +273,7 @@ define Device/comfast_cf-e313ac SOC := qca9531 DEVICE_VENDOR := COMFAST DEVICE_MODEL := CF-E313AC - DEVICE_PACKAGES := rssileds kmod-leds-gpio kmod-ath10k-ct \ + DEVICE_PACKAGES := rssileds kmod-leds-gpio kmod-ath10k-ct-smallbuffers \ ath10k-firmware-qca9888-ct -swconfig -uboot-envtools IMAGE_SIZE := 7936k endef @@ -473,7 +473,7 @@ define Device/dlink_dir-859-a1 DEVICE_MODEL := DIR-859 DEVICE_VARIANT := A1 IMAGE_SIZE := 15872k - DEVICE_PACKAGES := kmod-usb2 kmod-ath10k
[OpenWrt-Devel] [PATCH v3] kernel: ath10k-ct: provide a build variant for small RAM devices
According to many bugreports [0][1][2] the default ath10k-ct kernel
module is unusable on devices with just 64 MiB RAM or with 128 MiB and
dual ath10k cards. The target boards boot but eventually oom-killer
starts to interfere with normal operation, so the current state is
effectively broken.
Since the two patches in question have a performance impact (and
possibly some other unexpected side-effects) a dedicated build variant
is added so that users of the low RAM devices can still benefit from all
the ath10k-ct advantages.
According to testing [3] results, the issue can be experienced even with
"a 256MB device with three radios". Measured performance impact of
implementing small buffers was lowering "the maximum 5 GHz throughput on
an IPQ40xx device without RPS/XPS optimizations from 494/432 Mbit/s for
TCP transfers (download/upload) to 438/343 Mbit/s"
The patches were apparently inspired by QSDK tweaks used by ODMs for the
affected devices.
[0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html
[1] https://github.com/openwrt/openwrt/pull/1077
[2] https://bugs.openwrt.org/index.php?do=details&task_id=2664
[3] https://github.com/freifunk-gluon/gluon/pull/1440#issue-195607701
Signed-off-by: Paul Fertser
---
This is compile-tested only!
Changes for v3:
- Apply all patches to both build variants, select by a preprocessor
symbol
Changes for v2:
- Added performance impact details to the commit message
- Fixed QUILT=1 operation
- Refreshed the new patches
package/kernel/ath10k-ct/Makefile | 18 +++-
...0-0010-ath10k-limit-htt-rx-ring-size.patch | 28 +
...60-0011-ath10k-limit-pci-buffer-size.patch | 100 ++
3 files changed, 145 insertions(+), 1 deletion(-)
create mode 100644
package/kernel/ath10k-ct/patches/960-0010-ath10k-limit-htt-rx-ring-size.patch
create mode 100644
package/kernel/ath10k-ct/patches/960-0011-ath10k-limit-pci-buffer-size.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index dbf75fe174..e38380547a 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -35,6 +35,7 @@ define KernelPackage/ath10k-ct
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
AUTOLOAD:=$(call AutoProbe,ath10k_pci)
PROVIDES:=kmod-ath10k
+ VARIANT:=regular
endef
define KernelPackage/ath10k-ct/config
@@ -42,7 +43,17 @@ define KernelPackage/ath10k-ct/config
config ATH10K-CT_LEDS
bool "Enable LED support"
default y
- depends on PACKAGE_kmod-ath10k-ct
+ depends on PACKAGE_kmod-ath10k-ct ||
PACKAGE_kmod-ath10k-ct-smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers
+$(call KernelPackage/ath10k-ct)
+ TITLE+= (small buffers for low-RAM devices)
+ VARIANT:=smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers/config
+$(call KernelPackage/ath10k-ct/config)
endef
NOSTDINC_FLAGS = \
@@ -90,6 +101,10 @@ ifeq ($(CONFIG_ATH10K-CT_LEDS),y)
NOSTDINC_FLAGS += -DCONFIG_ATH10K_LEDS
endif
+ifeq ($(BUILD_VARIANT),smallbuffers)
+ NOSTDINC_FLAGS += -DCONFIG_ATH10K_SMALLBUFFERS
+endif
+
define Build/Configure
cp $(STAGING_DIR)/usr/include/mac80211/ath/*.h $(PKG_BUILD_DIR)
endef
@@ -107,3 +122,4 @@ define Build/Compile
endef
$(eval $(call KernelPackage,ath10k-ct))
+$(eval $(call KernelPackage,ath10k-ct-smallbuffers))
diff --git
a/package/kernel/ath10k-ct/patches/960-0010-ath10k-limit-htt-rx-ring-size.patch
b/package/kernel/ath10k-ct/patches/960-0010-ath10k-limit-htt-rx-ring-size.patch
new file mode 100644
index 00..a3a939440a
--- /dev/null
+++
b/package/kernel/ath10k-ct/patches/960-0010-ath10k-limit-htt-rx-ring-size.patch
@@ -0,0 +1,28 @@
+--- a/ath10k-4.19/htt.h
b/ath10k-4.19/htt.h
+@@ -237,7 +237,11 @@ enum htt_rx_ring_flags {
+ };
+
+ #define HTT_RX_RING_SIZE_MIN 128
++#ifndef CONFIG_ATH10K_SMALLBUFFERS
+ #define HTT_RX_RING_SIZE_MAX 2048
++#else
++#define HTT_RX_RING_SIZE_MAX 512
++#endif
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
+--- a/ath10k-5.2/htt.h
b/ath10k-5.2/htt.h
+@@ -225,7 +225,11 @@ enum htt_rx_ring_flags {
+ };
+
+ #define HTT_RX_RING_SIZE_MIN 128
++#ifndef CONFIG_ATH10K_SMALLBUFFERS
+ #define HTT_RX_RING_SIZE_MAX 2048
++#else
++#define HTT_RX_RING_SIZE_MAX 512
++#endif
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
diff --git
a/package/kernel/ath10k-ct/patches/960-0011-ath10k-limit-pci-buffer-size.patch
b/package/kernel/ath10k-ct/patches/960-0011-ath10k-limit-pci-buffer-size.patch
new file mode 100644
index 00..517be89dab
--- /dev/null
+++
b/package/kernel/ath10k-ct/patches/960-0011-ath10k-l
[OpenWrt-Devel] [PATCH] ubox: print an error when no kernel module dir can be found
Do not just silently fail when kernel modules are nowhere to be
found. This is essential for diagnosing mismatched kernel version
failures.
Signed-off-by: Paul Fertser
---
kmodloader.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/kmodloader.c b/kmodloader.c
index 07b6700..b4facb4 100644
--- a/kmodloader.c
+++ b/kmodloader.c
@@ -108,8 +108,10 @@ static int init_module_folders(void)
s = p + 1;
}
- if (!module_folders)
+ if (!module_folders) {
+ ULOG_ERR("no module folders for kernel version %s found\n",
ver.release);
return -1;
+ }
module_folders[n] = NULL;
return 0;
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] kernel: ath10k-ct: provide a build variant for small RAM devices
According to many bugreports [0][1][2] the default ath10k-ct kernel
module is unusable on devices with just 64 MiB RAM or with 128 MiB and
dual ath10k cards. The target boards boot but eventually oom-killer
starts to interfere with normal operation, so the current state is
effectively broken.
Since the two patches in question have a performance impact (and
possibly some other unexpected side-effects) a dedicated build variant
is added so that users of the low RAM devices can still benefit from all
the ath10k-ct advantages.
According to testing [3] results, the issue can be experienced even with
"a 256MB device with three radios". Measured performance impact of
implementing small buffers was lowering "the maximum 5 GHz throughput on
an IPQ40xx device without RPS/XPS optimizations from 494/432 Mbit/s for
TCP transfers (download/upload) to 438/343 Mbit/s"
The patches were apparently inspired by QSDK tweaks used by ODMs for the
affected devices.
[0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html
[1] https://github.com/openwrt/openwrt/pull/1077
[2] https://bugs.openwrt.org/index.php?do=details&task_id=2664
[3] https://github.com/freifunk-gluon/gluon/pull/1440#issue-195607701
Signed-off-by: Paul Fertser
---
Changes for v2:
- Added performance impact details to the commit message
- Fixed QUILT=1 operation
- Refreshed the new patches
package/kernel/ath10k-ct/Makefile | 30 +++-
...0-0010-ath10k-limit-htt-rx-ring-size.patch | 22 ++
...60-0011-ath10k-limit-pci-buffer-size.patch | 76 +++
3 files changed, 127 insertions(+), 1 deletion(-)
create mode 100644
package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
create mode 100644
package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index dbf75fe174..99ec225570 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -35,6 +35,7 @@ define KernelPackage/ath10k-ct
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
AUTOLOAD:=$(call AutoProbe,ath10k_pci)
PROVIDES:=kmod-ath10k
+ VARIANT:=regular
endef
define KernelPackage/ath10k-ct/config
@@ -42,7 +43,17 @@ define KernelPackage/ath10k-ct/config
config ATH10K-CT_LEDS
bool "Enable LED support"
default y
- depends on PACKAGE_kmod-ath10k-ct
+ depends on PACKAGE_kmod-ath10k-ct ||
PACKAGE_kmod-ath10k-ct-smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers
+$(call KernelPackage/ath10k-ct)
+ TITLE+= (small buffers for low-RAM devices)
+ VARIANT:=smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers/config
+$(call KernelPackage/ath10k-ct/config)
endef
NOSTDINC_FLAGS = \
@@ -90,6 +101,22 @@ ifeq ($(CONFIG_ATH10K-CT_LEDS),y)
NOSTDINC_FLAGS += -DCONFIG_ATH10K_LEDS
endif
+define Build/Patch
+ $(if $(QUILT),rm -rf $(PKG_BUILD_DIR)/patches; mkdir -p
$(PKG_BUILD_DIR)/patches)
+ $(call PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR),regular/)
+ifeq ($(BUILD_VARIANT),smallbuffers)
+ $(call
PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-$(BUILD_VARIANT),$(BUILD_VARIANT)/)
+endif
+ $(if $(QUILT),touch $(PKG_BUILD_DIR)/.quilt_used)
+endef
+
+define Quilt/Refresh/Package
+ $(call Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR),regular/)
+ifeq ($(BUILD_VARIANT),smallbuffers)
+ $(call
Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-$(BUILD_VARIANT),$(BUILD_VARIANT)/)
+endif
+endef
+
define Build/Configure
cp $(STAGING_DIR)/usr/include/mac80211/ath/*.h $(PKG_BUILD_DIR)
endef
@@ -107,3 +134,4 @@ define Build/Compile
endef
$(eval $(call KernelPackage,ath10k-ct))
+$(eval $(call KernelPackage,ath10k-ct-smallbuffers))
diff --git
a/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
new file mode 100644
index 00..fcc5927759
--- /dev/null
+++
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
@@ -0,0 +1,22 @@
+--- a/ath10k-4.19/htt.h
b/ath10k-4.19/htt.h
+@@ -237,7 +237,7 @@ enum htt_rx_ring_flags {
+ };
+
+ #define HTT_RX_RING_SIZE_MIN 128
+-#define HTT_RX_RING_SIZE_MAX 2048
++#define HTT_RX_RING_SIZE_MAX 512
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
+--- a/ath10k-5.2/htt.h
b/ath10k-5.2/htt.h
+@@ -225,7 +225,7 @@ enum htt_rx_ring_flags {
+ };
+
+ #define HTT_RX_RING_SIZE_MIN 128
+-#define HTT_RX_RING_SIZE_MAX 2048
++#define HTT_RX_RING_SIZE_MAX 512
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT
Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote: > From what I remember Sven Eckelmann also measured the impact from the > patches on the performance and posted his results to the OpenWrt ML > (google will find them). https://github.com/freifunk-gluon/gluon/pull/1440 is what contains all the relevant data. So Ben is well aware of the performance implications. "Even a 256MB device with three radios can go OOM" It looks like having a version of kmod-ath10k-ct with reduced buffers would be beneficial to the OpenWrt users. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
Thank you for the answer Christian, On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote: > I think for this to have any chance of moving forward you'll need to > pressure your ODMs and if that doesn't work: Go with a different WIFI > chip vendor that supports low memory devices, or add more RAM. > From what I can tell, Qualcomm nowadays gets what they want "for free" > and for the past four-five years, they certainly didn't feel pressured > to add "low memory" support to ath10k. FWIW, OpenWrt's ath10k vendor is CT now, not QCA, so it's not much relevant what do ODMs and (whatever is left from) QCA say, I guess. It would be kind of weird to force OpenWrt users of certain devices to downgrade to upstream ath10k (or to abandon hardware that is working fine for them with previous OpenWrt release) just because Atheros no longer exist and Qualcomm can't care less about free software community, don't you think so? I'll try to find the mailing list posts you're talking about to help Ben decide if he is still OK with those patches getting used on low-RAM devices in OpenWrt or not. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] LEDs in system UCI config (was: Re: [PATCH 19.07] ath79: add support for gl-ar750)
On Sat, Dec 14, 2019 at 02:12:55PM +0300, Paul Fertser wrote:
> Should a uci-defaults script be added to base-files that would
> populate the system config with all the LEDs present in the DT but not
> added by board config?
cd /sys/class/leds
for i in *; do
uci show system | grep -q sysfs=\'$i\' || {
l=${i#*:}
f=${l#*:}
c=${l%:*}
echo ucidef_set_led_default \"$f-$c\" \"$f \($c\)\" \"$i\" \"0\"
}
done
On my DIR-615-E4 this gives:
ucidef_set_led_default "power-amber" "power (amber)" "d-link:amber:power" "0"
ucidef_set_led_default "wan-amber" "wan (amber)" "d-link:amber:wan" "0"
ucidef_set_led_default "wps-blue" "wps (blue)" "d-link:blue:wps" "0"
ucidef_set_led_default "power-green" "power (green)" "d-link:green:power" "0"
ucidef_set_led_default "wlan-green" "wlan (green)" "d-link:green:wlan" "0"
Does this make sense?
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] LEDs in system UCI config (was: Re: [PATCH 19.07] ath79: add support for gl-ar750)
Hello, Some follow-up thoughts, could someone clarify please? On Sat, Dec 14, 2019 at 02:10:28AM +0300, Paul Fertser wrote: > On Fri, Dec 13, 2019 at 11:51:14PM +0100, Sven Roederer wrote: > > good point. But also on master seems to be no entry for this board in > > "01_leds". So I assume the default case fits for it. > > I looked several times through the config and was unable to see the > default case. Apparently, you count on trigger being set in DTS, and > that's ok for wlan and power, I see. It's just that I checked ar71xx > and it had those entries in uci-defaults but since triggers can be set > from DTS now that's not needed, got it. So if default trigger can be set in DTS, then it should be set there, I can see the rationale. But in this case it's not added to the system config and so repurpusing it for other tasks (or just disabling the LED) is not straight-forward anymore, as one would need to add it manually. Should a uci-defaults script be added to base-files that would populate the system config with all the LEDs present in the DT but not added by board config? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 19.07] ath79: add support for gl-ar750
Hey Sven, On Fri, Dec 13, 2019 at 11:51:14PM +0100, Sven Roederer wrote: > good point. But also on master seems to be no entry for this board in > "01_leds". So I assume the default case fits for it. I looked several times through the config and was unable to see the default case. Apparently, you count on trigger being set in DTS, and that's ok for wlan and power, I see. It's just that I checked ar71xx and it had those entries in uci-defaults but since triggers can be set from DTS now that's not needed, got it. Also, if you're going to improve the patch, I've noticed you have no DTS designations for how the LEDs are to be used (aliases for led-boot etc) and no label_mac assignment. Not sure if that's important. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 19.07] ath79: add support for gl-ar750
Hello, On Fri, Dec 13, 2019 at 08:50:46PM +0100, Sven Roederer wrote: > .../ath79/base-files/etc/board.d/02_network | 5 + > .../etc/hotplug.d/firmware/11-ath10k-caldata | 1 + > .../ath79/dts/qca9531_glinet_gl-ar750.dts | 142 ++ > target/linux/ath79/image/generic.mk | 9 ++ Is this not missing the additions to board.d/01_leds ? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
Hey Ben, On Wed, Dec 11, 2019 at 10:06:26AM -0800, Ben Greear wrote: > On 12/11/19 6:44 AM, Paul Fertser wrote: > > According to many bugreports [0][1][2] the default ath10k-ct kernel ... > And also if you want to just have the makefile pass a -DBUILD_ATH10K_SMALL or > something > like that and #ifdef code in the ath10k-ct driver, then I'd apply that patch > to ath10k-ct > so that you don't need the patches. I am offering my patch to the OpenWrt maintainers as kind of a stop-gap measure to get ath10k-ct working for the release (or in any way they think is appropriate). Another approach they can choose is to select the upstream ath10k for those devices. Otherwise some previously supported boards will require manual intervention to get WiFi working after an upgrade. Regarding your fwcfg idea, I am not sure it will work as it seems the PCI initialisation is happening before fwcfg is parsed and applied. Adding a Kconfig option is another possibility. But what do you think about an additional module parameter, wouldn't it be the cleanest solution in the long run? BTW, according to the git logs the patches were initially added by Christian Lamparter, so I hope he can clarify the situation a bit. Probably there were some performance tests executed back than to measure the impact. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
On Wed, Dec 11, 2019 at 05:44:59PM +0300, Paul Fertser wrote: > +define Build/Patch > + $(if $(QUILT),rm -rf $(PKG_BUILD_DIR)/patches; mkdir -p > $(PKG_BUILD_DIR)/patches) > + $(call PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR),) > +ifeq ($(BUILD_VARIANT),smallbuffers) > + $(call > PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-smallbuffers,patches-smallbuffers) > +endif > + $(if $(QUILT),touch $(PKG_BUILD_DIR)/.quilt_used) > +endef This is not correctly creating the patches-smallbuffers directory, I'll fix it for v2 along with other review points (if this approach is considered worthy at all). -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] kernel: ath10k-ct: provide a build variant for small RAM devices
According to many bugreports [0][1][2] the default ath10k-ct kernel
module is unusable on devices with just 64 MiB RAM or with 128 MiB and
dual ath10k cards. The target boards boot but eventually oom-killer
starts to interfere with normal operation, so the current state is
effectively broken.
Since the two patches in question might have a performance impact (and
possibly some other unexpected side-effects) a dedicated build variant
is added so that users of the low RAM devices can still benefit from all
the ath10k-ct advantages.
[0] http://lists.infradead.org/pipermail/openwrt-devel/2019-December/020573.html
[1] https://github.com/openwrt/openwrt/pull/1077
[2] https://bugs.openwrt.org/index.php?do=details&task_id=2664
Signed-off-by: Paul Fertser
---
package/kernel/ath10k-ct/Makefile | 30 +++-
...0-0010-ath10k-limit-htt-rx-ring-size.patch | 22 ++
...60-0011-ath10k-limit-pci-buffer-size.patch | 76 +++
3 files changed, 127 insertions(+), 1 deletion(-)
create mode 100644
package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
create mode 100644
package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
diff --git a/package/kernel/ath10k-ct/Makefile
b/package/kernel/ath10k-ct/Makefile
index dbf75fe174..d5726a1c88 100644
--- a/package/kernel/ath10k-ct/Makefile
+++ b/package/kernel/ath10k-ct/Makefile
@@ -35,6 +35,7 @@ define KernelPackage/ath10k-ct
$(PKG_BUILD_DIR)/ath10k$(CT_KVER)/ath10k_core.ko
AUTOLOAD:=$(call AutoProbe,ath10k_pci)
PROVIDES:=kmod-ath10k
+ VARIANT:=regular
endef
define KernelPackage/ath10k-ct/config
@@ -42,7 +43,17 @@ define KernelPackage/ath10k-ct/config
config ATH10K-CT_LEDS
bool "Enable LED support"
default y
- depends on PACKAGE_kmod-ath10k-ct
+ depends on PACKAGE_kmod-ath10k-ct ||
PACKAGE_kmod-ath10k-ct-smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers
+$(call KernelPackage/ath10k-ct)
+ TITLE+= (small buffers to work on low-RAM devices)
+ VARIANT:=smallbuffers
+endef
+
+define KernelPackage/ath10k-ct-smallbuffers/config
+$(call KernelPackage/ath10k-ct/config)
endef
NOSTDINC_FLAGS = \
@@ -90,6 +101,22 @@ ifeq ($(CONFIG_ATH10K-CT_LEDS),y)
NOSTDINC_FLAGS += -DCONFIG_ATH10K_LEDS
endif
+define Build/Patch
+ $(if $(QUILT),rm -rf $(PKG_BUILD_DIR)/patches; mkdir -p
$(PKG_BUILD_DIR)/patches)
+ $(call PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR),)
+ifeq ($(BUILD_VARIANT),smallbuffers)
+ $(call
PatchDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-smallbuffers,patches-smallbuffers)
+endif
+ $(if $(QUILT),touch $(PKG_BUILD_DIR)/.quilt_used)
+endef
+
+define Quilt/Refresh/Package
+ $(call Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR),)
+ifeq ($(BUILD_VARIANT),smallbuffers)
+ $(call
Quilt/RefreshDir,$(PKG_BUILD_DIR),$(PATCH_DIR)-smallbuffers,patches-smallbuffers)
+endif
+endef
+
define Build/Configure
cp $(STAGING_DIR)/usr/include/mac80211/ath/*.h $(PKG_BUILD_DIR)
endef
@@ -107,3 +134,4 @@ define Build/Compile
endef
$(eval $(call KernelPackage,ath10k-ct))
+$(eval $(call KernelPackage,ath10k-ct-smallbuffers))
diff --git
a/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
new file mode 100644
index 00..f73b02e5ef
--- /dev/null
+++
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0010-ath10k-limit-htt-rx-ring-size.patch
@@ -0,0 +1,22 @@
+--- a/ath10k-4.19/htt.h
b/ath10k-4.19/htt.h
+@@ -226,7 +226,7 @@ enum htt_rx_ring_flags {
+ };
+
+ #define HTT_RX_RING_SIZE_MIN 128
+-#define HTT_RX_RING_SIZE_MAX 2048
++#define HTT_RX_RING_SIZE_MAX 512
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
+--- a/ath10k-5.2/htt.h
b/ath10k-5.2/htt.h
+@@ -226,7 +226,7 @@ enum htt_rx_ring_flags {
+ };
+
+ #define HTT_RX_RING_SIZE_MIN 128
+-#define HTT_RX_RING_SIZE_MAX 2048
++#define HTT_RX_RING_SIZE_MAX 512
+ #define HTT_RX_RING_SIZE HTT_RX_RING_SIZE_MAX
+ #define HTT_RX_RING_FILL_LEVEL (((HTT_RX_RING_SIZE) / 2) - 1)
+ #define HTT_RX_RING_FILL_LEVEL_DUAL_MAC (HTT_RX_RING_SIZE - 1)
diff --git
a/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
new file mode 100644
index 00..27c0032bfb
--- /dev/null
+++
b/package/kernel/ath10k-ct/patches-smallbuffers/960-0011-ath10k-limit-pci-buffer-size.patch
@@ -0,0 +1,76 @@
+--- a/ath10k-4.19/pci.c
b/ath10k-4.19/pci.c
+@@ -131,7 +131,7 @@ static struct ce_attr host_ce_config_wla
+ .flags = CE_ATTR_FLAGS,
+ .src_nentries = 0,
+ .src
Re: [OpenWrt-Devel] [RFC][PATCH] base-files: send informational UDP message each second waiting
On Wed, Dec 11, 2019 at 12:47:22PM +0100, Petr Štetiar wrote: > Paul Fertser [2019-12-11 14:03:53]: > > Waiting with a timeout poses a question of what that timeout should be set > > to; and if that's reasonable to extend current 2 seconds with any > > significant amount. > > As you've witnessed this default value doesn't work well in some cases. The problem I faced was because the message is sent only once _before_ timeout starts ticking, so no matter what it's set to, the message wouldn't be there. > > Current documentation says a message should be sent. > > So now, this would need to be rephrased from current 0 or 1, to 0 to N, where > N depends on config settings (timeout value). Documentation [0] says "Wait (with a packet sniffer) for a special broadcast packet and press a button". So I think with this patch documentation changes are not strictly necessary, it still works the same way, you wait for the packet and press a button. > > Do you have any other possible solution in mind? > > (nope, just thinking aloud) > > If the fixed value doesn't work for all use cases, then its not fixed variable > anymore and should be variable, thus config option, probably finetuned per > target/device. Currently all devices wait for 2 seconds during normal bootup no matter what. Without my patch any value for that timeout wouldn't help with the UDP message. [0] https://openwrt.org/docs/guide-user/troubleshooting/failsafe_and_factory_reset -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
Hello Lars, On Fri, Nov 08, 2019 at 03:12:02PM +0700, Lars Melin wrote: > On 11/8/2019 14:50, Paul Fertser wrote: > > From working with uIP before on an embedded target I know that it > > doesn't support delayed ACKs in any form, for any packet it sends it > > waits for an ACK before sending the next, and I would guess that for > > any packet it receives it's better to wait for its ACK before sending > > the next (as I see plenty of duplicated ACKs from this backup server > > all confirming just the first packet received, and then long wait > > before retransmission). The problem is in the number of packets sent, > > not the size (so changing MTU/MSS doesn't help much). > > > > I haven't been able to find a way to trick it into behaving, sorry. > > > > Don't complicate simple things, all D-Link routers have a recovery web page > and you access it with your browser, not with curl. You quoted my message and it doesn't contradict "having a recovery web page" idea. However, it clearly says that I can't meaningfully use it _anyhow_, neither with curl nor with my browser. Please reread the quote and you'll see it is not simple. Do you want me to send you a PCAP file as a proof? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC][PATCH] base-files: send informational UDP message each second waiting
Hi, On Tue, Dec 10, 2019 at 03:42:13PM +0100, Petr Štetiar wrote: > Paul Fertser [2019-12-10 17:24:20]: > > in cases when the interface is brought up faster it leads to two messages > > in cases when the interface is brought up slower it leads to no message. > > To me it just seems like a workaround to fix your use case, not a proper fix. You're right, I mentioned "inherently racy" in the commit message exactly because of that. Waiting for LOWER_UP there without a timeout is not a solution because in the normal bootup case there might be nothing attached to the LAN so the boot will be effectively halted forever. Waiting with a timeout poses a question of what that timeout should be set to; and if that's reasonable to extend current 2 seconds with any significant amount. Current documentation says a message should be sent. Current code works for some devices and fails for other devices. My patch improves the situation without adding any code complexity (indeed, it's even removing one line) or wasting boot time. Do you have any other possible solution in mind? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC][PATCH] base-files: send informational UDP message each second waiting
The preinit network initialisation and failsafe informational message
are inherently racy as the interface takes some time to become
functional after "ip link set $pi_ifname up" command.
Consider this timing:
[ 12.002713] IPv6: ADDRCONF(NETDEV_UP): eth1: link is not ready
[ 12.008819] IPv6: ADDRCONF(NETDEV_UP): eth1.1: link is not ready
[ 12.118877] random: procd: uninitialized urandom read (4 bytes read)
[ 13.068614] eth1: link up (1000Mbps/Full duplex)
[ 13.073309] IPv6: ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
[ 13.080445] IPv6: ADDRCONF(NETDEV_CHANGE): eth1.1: link becomes ready
Since the UDP message was sent prior to link becoming ready, it was
never seen on the wire.
The default failsafe timeout is set to 2 seconds, so with this patch
there are two attempts to send the message, one spent in vain, and the
other visible in tcpdump on an attached host. Of course, in cases when
the interface is brought up faster it leads to two messages, however it
should be harmless. This patch (almost) doesn't affect normal boot time
while still allowing to enter failsafe reliably with a single button
press, matching the official "generic failsafe" documentation.
Signed-off-by: Paul Fertser
---
package/base-files/files/lib/preinit/30_failsafe_wait | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/package/base-files/files/lib/preinit/30_failsafe_wait
b/package/base-files/files/lib/preinit/30_failsafe_wait
index dd9c7e2b59..85dca398fa 100644
--- a/package/base-files/files/lib/preinit/30_failsafe_wait
+++ b/package/base-files/files/lib/preinit/30_failsafe_wait
@@ -31,6 +31,8 @@ fs_wait_for_key () {
lock $keypress_wait
{
while [ $timer -gt 0 ]; do
+ pi_failsafe_net_message=true \
+ preinit_net_echo "Please press button now to
enter failsafe"
echo "$timer" >$keypress_sec
timer=$(($timer - 1))
sleep 1
@@ -88,9 +90,6 @@ failsafe_wait() {
}
grep -q 'failsafe=' /proc/cmdline && FAILSAFE=true && export FAILSAFE
if [ "$FAILSAFE" != "true" ]; then
- pi_failsafe_net_message=true
- preinit_net_echo "Please press button now to enter failsafe"
- pi_failsafe_net_message=false
fs_wait_for_key f 'to enter failsafe mode'
$fs_failsafe_wait_timeout && FAILSAFE=true
[ -f "/tmp/failsafe_button" ] && FAILSAFE=true && echo "-
failsafe button "`cat /tmp/failsafe_button`" was pressed -"
[ "$FAILSAFE" = "true" ] && export FAILSAFE && touch
/tmp/failsafe
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v3] ath79: add D-Link DIR-615 E4
Specifications:
- FCC ID: KA2IR615E3
- SoC: MIPS32 24K 400 MHz Atheros AR7240
- RAM: 32 MiB DDR SDRAM ESMT M13S2561616A-5T
- Flash: 4 MiB NOR SPI Macronix MX25L3208E
- Wireless: AR9287 2.4 GHz 802.11n 2T2R, 2x RP-SMA connectors
- Ethernet: 5x 100BASE-TX Fast Ethernet
- LEDs: 9x GPIO, 1x ath9k
- Buttons: 2x tactile switches
- UART: 3.3 V, 115200 8n1
- USB: simple hardware modification required, 1x USB 1.1 Full Speed
Partitioning notes:
Vendor firmware (based on CameoAP99) defines two additional partitions:
"mac" @0x3b, size 0x1 and "lp" @0x3c, size 0x3.
The "mac" partition stores LAN MAC address and hardware board name.
However, the vendor firmware uses addresses from "nvram" partition, and
the board name is used only for informational purposes in the Web
interface (included in the pages' header), not affecting the firmware
image check.
The "lp" partition is supposed to contain a "language pack" (which can
be used to add an additional language support to the Web interface) and
is flashed separately, using the vendor firmware upgrade page.
Since these partitions are absolutely useless for OpenWrt and
overwriting them doesn't prevent downgrading to obsolete vendor
firmware, this patch appends the valueable space to "firmware".
Installation instructions:
- Upgrade from OpenWrt ar71xx with "sysupgrade -f -n"
or
- Upload as a firmware update via the vendor Web-interface
or
- Connect UART and use "loady" to upload and run OpenWrt initramfs
image, then sysupgrade from it (TFTP client doesn't work)
or
- Before powering up hold "reset" button and keep it pressed for about
15 seconds after, then access fail safe Web server on 192.168.0.1 (the
old uIP TCP/IP protocol stack is not compatible with modern Linux, the
kernel, so you'll need to use some other OS to do this). Can be
performed without a Web-browser too:
curl http://192.168.0.1/cgi/index \
-F Send=@openwrt-ath79-tiny-dlink_dir-615-e4-squashfs-factory.bin
Signed-off-by: Paul Fertser
---
Changes for v3:
- Add specifications and installation instructions to commit message
- Remove useless comments from DTS, other minor changes
- Change LEDs back to using "d-link" name
- Move ath9k LED to a dedicated section
Changes for v2:
- Remove "rev." from board name
- Use a single DTS file; whoever has hardware to port this to the other
similar devices can easily unsplit it later
- Fix label_mac handling (as it's not available in DT)
- Rename gpio_leds to leds DTS section
- Use boardname for LEDs and merge the setup code with buffalo,whr-g301n
- Use 33 MHz for SPI clock (max frequency for READ command acconding to the
chip datasheet)
- Make "firmware" partition 0x3b (3776 kiB) long, covering "mac" and
"lp"
.../ath79/dts/ar7240_dlink_dir-615-e4.dts | 170 ++
target/linux/ath79/image/tiny.mk | 16 ++
.../ath79/tiny/base-files/etc/board.d/01_leds | 7 +
.../tiny/base-files/etc/board.d/02_network| 6 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 4 +
5 files changed, 203 insertions(+)
create mode 100644 target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
diff --git a/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
new file mode 100644
index 00..537a99b8db
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
@@ -0,0 +1,170 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar7240.dtsi"
+
+/ {
+ model = "D-Link DIR-615 E4";
+ compatible = "dlink,dir-615-e4", "qca,ar7240";
+
+ aliases {
+ led-boot = &led_power_amber;
+ led-failsafe = &led_power_amber;
+ led-running = &led_power_green;
+ led-upgrade = &led_power_amber;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&switch_led_pins>;
+
+ led_power_green: power_green {
+ label = "d-link:green
Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
On Sat, Dec 07, 2019 at 11:11:27PM +0100, m...@adrianschmutzler.de wrote: > Well, address the issues we have agreed on in a v3. Sure, will do tomorrow, thanks! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
On Sat, Dec 07, 2019 at 09:58:26PM +0100, Petr Štetiar wrote: > > I'll be happy to change the patch in any way that will get it accepted. > > Then just do the requested changes in v3, solved. I got an impression Adrian is not sure anymore he's requesting all the changes we talked about, as I provided some reasonable counter-arguments and that he is waiting for someone else to chime in. If you tell me I should just do whatever Adrian says, ok, np. Do I get it right? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
Hi Petr, On Sat, Dec 07, 2019 at 04:04:13PM +0100, Petr Štetiar wrote: > > You changed the status of the patch to "Changes requested" but you > > I've marked it as such, because of that discussion[1], but I admit, that I > didn't read it thoroughly. One thing I find a bit annoying about Patchwork is that state changes are anonymous and so a committer might get an odd feeling when something like that happens. Regarding this specific patch, I'd really like to hear the opinion of a maintainer (it seems like ath79 doesn't have an official maintainer yet) as there're some issues raised in the discussion for which there's still no clear answer. I'll be happy to change the patch in any way that will get it accepted. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
Hello dear maintainer, You changed the status of the patch to "Changes requested" but you haven't expressed your opinion on the topics raised during the discussion. Please do so that I can make the changes to your liking. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [RFC][PATCH] ath79-tiny: enable 4k sectors
This enables using 4kiB sectors as erase blocks for 4MiB NOR flash ICs that support it. Writeable jffs2 overlay used to store settings requires a partition with at least 5 erase blocks, so using small sectors is essential for devices with 4MiB flash. Sysupgrading a device running firmware without this feature will likely not allow to preserve configs automatically but since ath79 is considered to be in a "technology preview" state it shouldn't be a problem. Signed-off-by: Paul Fertser --- target/linux/ath79/tiny/config-default | 1 + 1 file changed, 1 insertion(+) diff --git a/target/linux/ath79/tiny/config-default b/target/linux/ath79/tiny/config-default index 90cd5534c7..9b845abbff 100644 --- a/target/linux/ath79/tiny/config-default +++ b/target/linux/ath79/tiny/config-default @@ -1,4 +1,5 @@ CONFIG_LEDS_RESET=y +CONFIG_MTD_SPI_NOR_USE_4K_SECTORS=y CONFIG_NET_DSA=y CONFIG_NET_DSA_MV88E6060=y CONFIG_NET_DSA_TAG_TRAILER=y -- 2.20.1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
On Mon, Nov 11, 2019 at 01:53:10PM +0100, Adrian Schmutzler wrote: > > I've made specific effort to flash vendor firmware and confirmed by > > testing on hardware that the vendor firmware doesn't need those > > partitions. Isn't that enough? What important aspects did I not check? > > I haven't been able to extract that precise information from your > previous comments (I don't want to blame you for that, maybe I just > overlooked it ...). > > If stock firmware works without those partitions, removing them is > fine for me. Please explicitly state in your commit message (after > telling about the removal) that you tested successfully on vendor > firmware. :-) Funny thing but it's exactly the commit message for my v2 where I tried to express it. For the next version I'll try to make it more clear. The vendor firmware was split out of a full flash dump I found on the net (I copied the whole original "firmware" partition with "mtd write"). -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
Hello Adrian,
Thank you very much for the review.
On Mon, Nov 11, 2019 at 12:12:47PM +0100, Adrian Schmutzler wrote:
> > + power_green: power_green {
>
> As stated above, change the _label_ to include a "led_" prefix, so
> this becomes "led_power_green: power_green {". Same for power_amber
> below.
Noted.
> > + label = "dir-615-e4:green:power";
>
> Sorry for causing confusion here. I have had a look into ar71xx mach
> files and they consistent use "d-link" as vendor for the led
> labels. Thus, I think it makes more sense to revert that to the
> previous version "d-link:green:power".
Why do you think so? If board name is a good idea and allows sharing
led arrangements (and sharing is desired) then why should we stick to
the old way of doing it?
> > + wlan {
> > + label = "dir-615-e4:green:wlan";
> > + gpios = <&ath9k 1 GPIO_ACTIVE_LOW>;
> > + linux,default-trigger = "phy0tpt";
> > + };
>
> At some point, we started to put ath9k leds into a node of their own:
Noted.
> > +&spi {
> > + status = "okay";
> > + num-cs = <1>;
>
> Please add empty line after status.
Yep.
> > + nvram: partition@3 {
> > + reg = <0x3 0x1>;
> > + label = "nvram";
> > + read-only;
> > + };
>
> Remove the node labels for the two partitions above, as they are not used
> anyway (but not the label properties).
Noted.
> > + /*
> > + These two partitions are defined by CameoAP99 layout
> > + but not needed for vendor firmware: MAC address is
> > taken
> > + from "nvram", language pack can be flashed separately.
> > +
> > + mac: partition@3b {
> > + reg = <0x3b 0x1>;
> > + label = "mac";
> > + read-only;
> > + };
> > +
> > + lp: partition@3c {
> > + reg = <0x3c 0x3>;
> > + label = "lp";
> > + read-only;
> > + };
> > + */
>
> Well, we still do not know whether they are present in vendor
> firmware. I'm still skeptical about removing them. Nevertheless, I
> won't prevent you from doing that, but please remove this comment
> from the DTS then and put an extensive description into the commit
> message instead.
I've made specific effort to flash vendor firmware and confirmed by
testing on hardware that the vendor firmware doesn't need those
partitions. Isn't that enough? What important aspects did I not check?
Regarding removing comments in DTS, this I am not yet sure is the
right way to go, please consider this rationale: DTS files are not
only OpenWrt-specific, they're supposed to specify hardware
arrangements for the upstream Linux, and for all the other low-level
software that can be booted on hardware too (such as barebox and
u-boot bootloaders). This said, whatever can't be expressed as a set
of properties should still be mentioned in the comments so that
whoever is dealing with this hardware has extensive information.
> > +ð0 {
> > + status = "okay";
> > +
> > + /* ethernet MAC is stored in nvram */
>
> Remove those comments. You are setting up stuff in 02_network, which
> are relatively standard, so I think extra comments are not
> necessary.
E.g. when (if at all ever) the kernel gains support for parsing nvram
partition, this comment will be changed to a proper DT property. But
it doesn't mean that a person looking at this file before that happens
should need to consult OpenWrt sources to understand how to deal with
this board properly.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] 4K sectors on ath79-tiny
Hello, What is the reason for not enabling 4K erase sectors for the 4M devices in ath79 target? jffs2 needs minimum 5 erase blocks so for those space-constrained devices this option seems to be really useful (to be able to keep configs when the space gets tight). However please note that if this option is enabled then sysupgrade will fail to properly keep configs on upgrade, that might be a nasty surprise for those already using the supported boards. So what would be the way towards enabling this feature now? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v2] ath79: add D-Link DIR-615 E4
Support ported from ar71xx.
Tested on hardware: flashing OpenWrt, then downgrading to vendor
firmware, then using regular vendor web interface to upgrade to OpenWrt
(using -factory.bin image). All MACs in vendor firmware were correct,
the only visible quirk was meaningless "Hardware Version:" field in the
web interface page header (one can append "mac" partition contents to
the vendor firmware dump prior to flashing if that's too worrying).
Signed-off-by: Paul Fertser
---
Changes for v2:
- Remove "rev." from board name
- Use a single DTS file; whoever has hardware to port this to the other
similar devices can easily unsplit it later
- Fix label_mac handling (as it's not available in DT)
- Rename gpio_leds to leds DTS section
- Use boardname for LEDs and merge the setup code with buffalo,whr-g301n
- Use 33 MHz for SPI clock (max frequency for READ command acconding to the
chip datasheet)
- Make "firmware" partition 0x3b (3776 kiB) long, covering "mac" and
"lp"
.../ath79/dts/ar7240_dlink_dir-615-e4.dts | 188 ++
target/linux/ath79/image/tiny.mk | 16 ++
.../ath79/tiny/base-files/etc/board.d/01_leds | 3 +-
.../tiny/base-files/etc/board.d/02_network| 6 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 4 +
5 files changed, 216 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
diff --git a/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
new file mode 100644
index 00..64ee2eb938
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
@@ -0,0 +1,188 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "ar7240.dtsi"
+
+/ {
+ model = "D-Link DIR-615 E4";
+ compatible = "dlink,dir-615-e4", "qca,ar7240";
+
+ aliases {
+ led-boot = &power_amber;
+ led-failsafe = &power_amber;
+ led-running = &power_green;
+ led-upgrade = &power_amber;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&switch_led_pins>;
+
+ power_green: power_green {
+ label = "dir-615-e4:green:power";
+ gpios = <&gpio 6 GPIO_ACTIVE_HIGH>;
+ };
+
+ power_amber: power_amber {
+ label = "dir-615-e4:amber:power";
+ gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ wps {
+ label = "dir-615-e4:blue:wps";
+ gpios = <&gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ lan1 {
+ label = "dir-615-e4:green:lan1";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ lan2 {
+ label = "dir-615-e4:green:lan2";
+ gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ lan3 {
+ label = "dir-615-e4:green:lan3";
+ gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ lan4 {
+ label = "dir-615-e4:green:lan4";
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+ };
+
+ wan_amber {
+ label = "dir-615-e4:amber:wan";
+ gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan_green {
+ label = "dir-615-e4:green:wan";
+ gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+ };
+
+ wlan {
+ label = "dir-615-e4:green:wlan";
+ gpios = <&ath9k 1 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "phy0tpt";
+ };
+ };
+};
+
+&spi {
+ status = "
Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
On Fri, Nov 08, 2019 at 07:41:33PM +0300, Paul Fertser wrote: > "lp" might be a "language pack" which is to be downloaded and > flashed separately when using vendor firmware. One forum post[1] says that the only language pack the person was able to ever find for this device was for "taiwanese language" :D [1] http://4pda.ru/forum/lofiversion/index.php?t446257-1580.html -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
Hi Adrian, On Fri, Nov 08, 2019 at 03:53:59PM +0100, Adrian Schmutzler wrote: > > With that I have 6 eraseblocks left for the rootfs_data partition (5 > > is the absolute minimum jffs2 allows). > > > > > Be aware that you might not find someone willing to merge this. > > > > I do not think this device is any worse than the other 4M devices > > supported by ath79. [...] > > Well, TP-Link devices have 0x3d, Netgear has 0x3a, ... With the useless partitions concatenated with firmware it'll be 0x3b, more than Netgear, same as many 4M ramips devices. My current guess is that "mac" partition initially contains MAC (but it is not used as D-Link specifies their own in nvram) and "lp" might be a "language pack" which is to be downloaded and flashed separately when using vendor firmware. But even with 0x37 I showed a sensible set of software that still allows to have 6 eraseblocks for rootfs_data. I think the only possibly essential part missing is DNSSEC but that would assume one is using such an old and limited device as his or her border gateway which is unlikely; yet this old 2x2 router can still serve nicely as a "wireless extender" or just a "dumb AP". > Well, on the other hand the question is whether we want to deviate > from the principle of keeping vendor partitions to add support for a > 4/32 device, especially since the partition size will be still small > in comparison afterwards. If it might stop building anyway soon, we > could also keep the partitions in official repo and whoever wants to > use it will have to mess with the code. For my own use I'm certainly planning to self-build and to have firmware partition span till the beginning of "art". With regard to the official tree, I guess that's up to the target maintainer (and possibly the end-users?) to decide. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
On Thu, Nov 07, 2019 at 08:19:27AM +0300, Paul Fertser wrote: > I see there's some http server mentioned in the wiki article, haven't > tried it yet (and I can't understand what "simple" web browser it > talks about, probably there should be a curl command instead?), So I gave it a try but the results are not fruitful. This command should work: curl http://192.168.0.1/cgi/index -F Send=@built/targets/ath79/tiny/openwrt-ath79-tiny-dlink_dir-615-e4-squashfs-factory.bin BUT the recovery HTTP server is using a very old uIP implementation that seems to be unable to play well along with the current TCP stack in Linux. The result is a very slow upload (left it overnight and it's still not finished). >From working with uIP before on an embedded target I know that it doesn't support delayed ACKs in any form, for any packet it sends it waits for an ACK before sending the next, and I would guess that for any packet it receives it's better to wait for its ACK before sending the next (as I see plenty of duplicated ACKs from this backup server all confirming just the first packet received, and then long wait before retransmission). The problem is in the number of packets sent, not the size (so changing MTU/MSS doesn't help much). I haven't been able to find a way to trick it into behaving, sorry. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
Hello Thomas, On Wed, Nov 06, 2019 at 11:31:23PM +0100, tm...@gmx.de wrote: > > Support ported from ar71xx. > > > > Signed-off-by: Paul Fertser > > [...] > > Can you please add installation instructions? Please notice that this patch is WiP and some additional changes are to be introduced in v2. I would expect -factory.bin to be flashable by vendor firmware. Closely looking at hexdump -C doesn't reveal any differences between generated images by existing support in ar71xx target and this ath79 port. Upgrading from OpenWrt is possible with sysupgrade. TFTP to uboot doesn't work for me (I receive ARP request and send replies back but they're apparently never heard) but with "loady" I'm able to bootm an initramfs image and then sysupgrade from it. I see there's some http server mentioned in the wiki article, haven't tried it yet (and I can't understand what "simple" web browser it talks about, probably there should be a curl command instead?), and in my opinion it's ok to wait for a few minutes for slow serial upload as it's to be performed only once anyway but if you can figure a reliable http method it would be a nice alternative. Where would you like to have the additional installation instructions, on the wiki or in the commit message itself? BTW, as a device user, what's your opinion regarding mac and lp partitions, do you consider keeping them wasteful or not? Thank you! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
On Mon, Nov 04, 2019 at 05:16:15PM +0100, Adrian Schmutzler wrote:
> > + power_green: power_green {
> > + label = "d-link:green:power";
>
> It's policy to use boardname instead of "d-link" here, except for tplink as
> far as I know.
But in this case there're three other boards that can be supported by
almost the same code (they lack "wlan" led but they also get a bigger
firmware partition becase they have no "lp" partition). I am not sure
how to properly add support for all of them, especially given I have
no way to test on real hardware (except for the E4).
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
Hello,
Thank you for the review indeed!
On Mon, Nov 04, 2019 at 05:16:15PM +0100, Adrian Schmutzler wrote:
> > + power_green: power_green {
> > + label = "d-link:green:power";
>
> It's policy to use boardname instead of "d-link" here, except for tplink as
> far as I know.
My bad, I was using tp-link 741 code for inspiration.
> > + firmware: partition@4 {
> > + compatible = "denx,uimage";
> > + reg = <0x4 0x37>;
>
> 3520k? Does this even build with standard buildbot settings?
I did not know I need to check with standard buildbot settings, I
haven't noticed anything like that in the patch guide.
That said, I find these settings meaningful for a home AP+router:
CONFIG_TARGET_ath79=y
CONFIG_TARGET_ath79_tiny=y
CONFIG_TARGET_ath79_tiny_DEVICE_dlink_dir-615-e4=y
CONFIG_PACKAGE_6in4=y
# CONFIG_PACKAGE_iwinfo is not set
CONFIG_PACKAGE_kmod-iptunnel=y
CONFIG_PACKAGE_kmod-iptunnel4=y
# CONFIG_PACKAGE_kmod-ppp is not set
CONFIG_PACKAGE_kmod-sit=y
# CONFIG_PACKAGE_libiwinfo is not set
# CONFIG_PACKAGE_openwrt-keyring is not set
# CONFIG_PACKAGE_ppp is not set
# CONFIG_PACKAGE_uboot-envtools is not set
# CONFIG_PACKAGE_usign is not set
# CONFIG_SIGNATURE_CHECK is not set
# CONFIG_SIGNED_PACKAGES is not set
With that I have 6 eraseblocks left for the rootfs_data partition (5
is the absolute minimum jffs2 allows).
> Be aware that you might not find someone willing to merge this.
I do not think this device is any worse than the other 4M devices
supported by ath79. Moreover, it can easily (two usb pulldown
resistors and two series) be modded to add a USB port (much easier
than TL-WR741ND).
Regarding the firmware partition size, it can be made 4 eraseblocks
more if the next two useless partitions are merged into it.
> > + mac: partition@3b {
> > + reg = <0x3b 0x1>;
> > + label = "mac";
>
> Why is there a partition labelled mac that is not used for MAC
> addresses? Have you checked the partition for MAC addresses?
I have, and it certainly doesn't have the address printed on device
label. I would guess the partition is a rudiment of Cameo99 reference
design or something like that, and D-Link in their wisdom decided to
store MACs elsewhere.
> > + lp: partition@3c {
> > + reg = <0x3c 0x3>;
> > + label = "lp";
> > + read-only;
> > + };
This I have no idea what can be used for. hexdumping it reveals some
filenames and "whiteout" strings which might hint at using it as some
kind of a writeable overlay. I can't be sure I still have the factory
data in it though, but I do not remember specifically overwriting or
anyhow abusing it either, probably it was done before me.
Anyway, I do not see any good reason to care much about running
factory (old, buggy and flawed) vendor firmware on this ancient device
(it came with an old-school 50Hz transformer PSU, you can imagine how
old it is!)
> > case "$board" in
> > + dlink,dir-615-e4)
> > + lan_mac=$(mtd_get_mac_ascii "nvram" "lan_mac")
> > + wan_mac=$(mtd_get_mac_ascii "nvram" "wan_mac")
> > + ;;
>
> I didn't find a reference to "wan_mac" in nvram in ar71xx. Did you deduce
> that by yourself?
Yes, that's where I deviate from code in ar71xx. I grepped strings in
nvram partition and noticed lan_mac and wan_mac, both made perfect
sense. Regarding wlan mac in vendor firmware, I do not think I've ever
seen vendor firmware running on this board so I can't tell. Guess
whoever added support for it (and the other 3 almost identical boards)
in ar71xx have checked all the options.
All your other points noted, thanks a lot!
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
Hello dear reviewers,
On Sun, Nov 03, 2019 at 02:32:47PM +0300, Paul Fertser wrote:
> + mac: partition@3b {
> + reg = <0x3b 0x1>;
> + label = "mac";
> + read-only;
> + };
> +
> + lp: partition@3c {
> + reg = <0x3c 0x3>;
> + label = "lp";
> + read-only;
> + };
These two I'm not sure about. They do not seem to contain anything
useful but I haven't checked running vendor firmware. They waste 256
KiB of precious flash space.
> + ath9k: wifi@0,0 {
> + compatible = "pci168c,002b";
This is a weird node. It doesn't match (actual PID is 0x002e) and yet
the driver loads and works. Probably it shouldn't be used at all?
> + dlink,dir-615-e4)
> + caldata_extract "art" 0x1000 0x1000
> + ath9k_patch_mac_crc $(mtd_get_mac_ascii "nvram" "lan_mac") 0x10c
lan mac seems to be used for wlan as is (without +1/-1) by ar71xx
code.
--
Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software!
mailto:fercer...@gmail.com
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: add D-Link DIR-615 rev. E4
Support ported from ar71xx.
Signed-off-by: Paul Fertser
---
.../ath79/dts/ar7240_dlink_dir-600-a1.dtsi| 173 ++
.../ath79/dts/ar7240_dlink_dir-615-e4.dts | 19 ++
target/linux/ath79/image/tiny.mk | 16 ++
.../ath79/tiny/base-files/etc/board.d/01_leds | 7 +
.../tiny/base-files/etc/board.d/02_network| 5 +
.../etc/hotplug.d/firmware/10-ath9k-eeprom| 4 +
6 files changed, 224 insertions(+)
create mode 100644 target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi
create mode 100644 target/linux/ath79/dts/ar7240_dlink_dir-615-e4.dts
diff --git a/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi
b/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi
new file mode 100644
index 00..e6206f6f42
--- /dev/null
+++ b/target/linux/ath79/dts/ar7240_dlink_dir-600-a1.dtsi
@@ -0,0 +1,173 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+#include
+#include
+
+#include "ar7240.dtsi"
+
+/ {
+ aliases {
+ led-boot = &power_amber;
+ led-failsafe = &power_amber;
+ led-running = &power_green;
+ led-upgrade = &power_amber;
+ label-mac-device = ð0;
+ };
+
+ keys {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = <&gpio 8 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+
+ wps {
+ label = "wps";
+ linux,code = ;
+ gpios = <&gpio 12 GPIO_ACTIVE_LOW>;
+ debounce-interval = <60>;
+ };
+ };
+
+ gpio-leds {
+ compatible = "gpio-leds";
+ pinctrl-names = "default";
+ pinctrl-0 = <&switch_led_pins>;
+
+ power_green: power_green {
+ label = "d-link:green:power";
+ gpios = <&gpio 6 GPIO_ACTIVE_HIGH>;
+ };
+
+ power_amber: power_amber {
+ label = "d-link:amber:power";
+ gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
+ };
+
+ wps {
+ label = "d-link:blue:wps";
+ gpios = <&gpio 0 GPIO_ACTIVE_LOW>;
+ };
+
+ lan1 {
+ label = "d-link:green:lan1";
+ gpios = <&gpio 13 GPIO_ACTIVE_LOW>;
+ };
+
+ lan2 {
+ label = "d-link:green:lan2";
+ gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+ };
+
+ lan3 {
+ label = "d-link:green:lan3";
+ gpios = <&gpio 15 GPIO_ACTIVE_LOW>;
+ };
+
+ lan4 {
+ label = "d-link:green:lan4";
+ gpios = <&gpio 16 GPIO_ACTIVE_LOW>;
+ };
+
+ wan_amber {
+ label = "d-link:amber:wan";
+ gpios = <&gpio 7 GPIO_ACTIVE_HIGH>;
+ };
+
+ wan_green {
+ label = "d-link:green:wan";
+ gpios = <&gpio 17 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&spi {
+ status = "okay";
+ num-cs = <1>;
+
+ flash@0 {
+ compatible = "jedec,spi-nor";
+ reg = <0>;
+ spi-max-frequency = <2500>;
+
+ partitions {
+ compatible = "fixed-partitions";
+ #address-cells = <1>;
+ #size-cells = <1>;
+
+ uboot: partition@0 {
+ reg = <0x0 0x3>;
+ label = "u-boot";
+ read-only;
+ };
+
+ nvram: partition@3 {
+ reg = <0x3 0x1>;
+ label = "nvram";
+ read-only;
+ };
+
+ firmware: partition@4 {
+ compatible = "denx,uimage";
+ reg = <0x4 0x37>;
+ label = "firmware";
+ };
+
+ mac: partition@3b {
+ reg = <0x3b 0x1>;
+
Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2
Hi Roger, Thank you for the review! On Fri, Oct 11, 2019 at 07:14:25PM +0200, Roger Pueyo Centelles | Guifi.net wrote: > + xiaomi,mir3g-v2) > + wan_mac=$(mtd_get_mac_binary factory 0xe006) > + ;; > > You may want to add "label_mac=$wan_mac" there, if the MAC address on the back > label matches the WAN interface (on the R4G it does). Indeed, done. > Also, it looks like a newline should be added at the end of the .dts file. I've checked and I see there's already a newline present at the end of the file. > Since there are two Xiaomi Router 4A variants, the 100m and the Gigabit > Edition, > you may want to use: > > + DEVICE_ALT0_VENDOR := Xiaomi > + DEVICE_ALT0_MODEL := Mi Router 4A > + DEVICE_ALT0_VARIANT := Gigabit Edition Done. > Last, I added the device to uboot-envtools. Feel free to copy it: > [2]https://github.com/openwrt/openwrt/pull/2486/commits/2625499ca554449e7a19bb5f6f61acdefb5a69e1 Since the uboot partition is not writeable by default, and there's no way to install OpenWrt without changing it first by some other means (such as an external SPI flash programmer) I have a feeling adding it to uboot-envtools wouldn't be useful. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2
Hi, On Sat, Aug 31, 2019 at 11:32:33PM +0200, m...@adrianschmutzler.de wrote: > > + xiaomi,mir3g-v2) > > + ucidef_add_switch "switch0" \ > > + "2:lan:2" "3:lan:1" "4:wan" "6t@eth0" > > + ;; > > "6t@eth0" and "6@eth0" should be the same, so this can be merged with > cudy,wr1000. Done. > > + xiaomi,mir3g-v2) > > + wan_mac=$(mtd_get_mac_binary factory 0xe006) > > + ;; > > This can be merged with elecom,wrc-1167ghbk2-s|\ etc. I rebased to current master and added label_mac (as per Roger's suggestion), and since I can not be sure about all the other devices, I left the dedicated section for this model. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH v4] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2
- CMIIT ID: 2019AP2581
- SoC: MediaTek MT7621
- Flash:16MiB NOR SPI (GigaDevice GD25Q128B)
- RAM: 128MiB DDR3 (ESMT M15T1G1664A)
- Serial: As marked on PCB, 3V3 logic, baudrate is 115200, 8n1
- Ethernet: 3x 10/100/1000 Mbps (switched, 2xLAN + WAN)
- WIFI0:MT7603E 2.4GHz 802.11b/g/n
- WIFI1:MT7612E 5GHz 802.11ac
- Antennas: 4x external (2 per radio), non-detachable
- LEDs: Programmable "power" LED (two-coloured, yellow/blue)
Non-programmable "internet" LED (shows WAN activity)
- Buttons: Reset
INSTALLATION:
Bootloader won't accept any serial input unless "boot_wait" u-boot
environment variable is changed to "on". Vendor firmware (looks like
an illegal OpenWrt fork) won't accept any serial input unless
"uart_en" is set to "1". Tricks to force u-boot to use default
environment do not help as it's restricted in the same way.
With bootloader unlocked the easiest way would be to TFTP the
sysupgrade image or to sysupgrade after loading an initramfs one.
For porting the flash contents were changed externally with an SPI
programmer (after lifting Vcc flash IC pin away from the PCB).
Forum thread [0] indicates that this device is identical to "Xiaomi Mi
Router 4A Gigabit Edition".
[0]
https://forum.openwrt.org/t/xiaomi-mi-router-4a-gigabit-edition-r4ag-r4a-gigabit-fully-supported-but-requires-overwriting-spi-flash-with-programmer/36685
Signed-off-by: Paul Fertser
---
Changes for v2:
- Addressed all Adrian Schmutzl's comments
Changes for v3:
- Add SPDX license header
- Use new ALT variables to support R4AG model name
Changes for v4:
- Merge switch config with cudy,wr1000 (Adrian Schmutzler)
- Add label_mac (Roger Pueyo Centelles)
- Use DEVICE_ALT0_MODEL for R4A GE (Roger Pueyo Centelles)
.../ramips/base-files/etc/board.d/02_network | 7 +-
.../ramips/dts/mt7621_xiaomi_mir3g-v2.dts | 147 ++
target/linux/ramips/image/mt7621.mk | 13 ++
3 files changed, 166 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
diff --git a/target/linux/ramips/base-files/etc/board.d/02_network
b/target/linux/ramips/base-files/etc/board.d/02_network
index 3c73a63aae..480726a870 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -297,7 +297,8 @@ ramips_setup_interfaces()
ucidef_add_switch "switch0" \
"4:lan" "6@eth0"
;;
- cudy,wr1000)
+ cudy,wr1000|\
+ xiaomi,mir3g-v2)
ucidef_add_switch "switch0" \
"2:lan:2" "3:lan:1" "4:wan" "6@eth0"
;;
@@ -720,6 +721,10 @@ ramips_setup_macs()
xiaomi,mir3g)
lan_mac=$(mtd_get_mac_binary factory 0xe006)
;;
+ xiaomi,mir3g-v2)
+ wan_mac=$(mtd_get_mac_binary factory 0xe006)
+ label_mac=$wan_mac
+ ;;
xiaomi,mir3p)
lan_mac=$(mtd_get_mac_binary factory 0xe006)
label_mac=$lan_mac
diff --git a/target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
b/target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
new file mode 100644
index 00..58da88a862
--- /dev/null
+++ b/target/linux/ramips/dts/mt7621_xiaomi_mir3g-v2.dts
@@ -0,0 +1,147 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include "mt7621.dtsi"
+
+#include
+#include
+
+/ {
+ compatible = "xiaomi,mir3g-v2", "mediatek,mt7621-soc";
+ model = "Xiaomi Mi Router 3G v2";
+
+ aliases {
+ led-boot = &led_status_yellow;
+ led-failsafe = &led_status_yellow;
+ led-running = &led_status_blue;
+ led-upgrade = &led_status_yellow;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_status_blue: status_blue {
+ label = "mir3gv2:blue:status";
+ gpios = <&gpio0 8 GPIO_ACTIVE_LOW>;
+ };
+
+ led_status_yellow: status_yellow {
+ label = "mir3gv2:yellow:status";
+ gpios = <&gpio0 10 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ button {
+ compatible = "gpio-keys";
+
+ reset {
+ label = "reset";
+ gpios = <&gpio0 18 GPIO_ACTIVE_LOW>;
+ linux,code = ;
+ };
+ };
+};
+
+&spi0 {
+ status = &quo
Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2
Dear maintainers, Do you request me to make all of the changes proposed by Roger (including adding u-boot data? But the env partition is marked read-only and most other targets do not do that)? Or the merging proposed by Adrian? Please clarify! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v3] ramips: add support for Xiaomi Mi Wi-Fi Router 3G v2
Hi, Thank you for the reviewing. On Sat, Aug 31, 2019 at 11:32:33PM +0200, m...@adrianschmutzler.de wrote: > > + xiaomi,mir3g-v2) > > + ucidef_add_switch "switch0" \ > > + "2:lan:2" "3:lan:1" "4:wan" "6t@eth0" > > + ;; > > "6t@eth0" and "6@eth0" should be the same, so this can be merged with > cudy,wr1000. > > > + xiaomi,mir3g-v2) > > + wan_mac=$(mtd_get_mac_binary factory 0xe006) > > + ;; > > This can be merged with elecom,wrc-1167ghbk2-s|\ etc. The question is whether it should be merged. I can see both positives (less places to change if/when scripts are refactored) and negatives (not easy to compare with other probably related devices from the same manufacturer). If the current practice is to merge everything mergeable, sure, I can send a v4 with that. I'm rather worried by the lack of feedback from R4AG developers/users though! -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercer...@gmail.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
