[OpenWrt-Devel] [PATCH v2] ramips: various Netgear R6120 fixes
The R6120 has no 5GHz WLAN LED, the assigned GPIO in fact controls
the WAN LED.
Renames the LED accordingly in the device-tree.
Removes the 5GHz WLAN LED trigger.
Adds the correct WAN port LED trigger.
Currently, the MAC address for the Netgear R6120 is read from the NVRAM
partition. The offset for the MAC address however is not consistent
across devices or firmware versions.
Switch to using the factory partition like all other Netgear devices do.
The LAN ports of the R6120 are labled in reverse on the casing.
Adjust LuCI switchport numbering accordingly.
The WiFi eeprom offsets for the R6120 are currently wrong (5GHz offset
is bigger than the partition itself).
Fixes poor performance on 2.4 and 5 GHz.
Signed-off-by: David Bauer
---
v2:
- Squash commits into one
- Fix incorrect WiFi eeprom offsets
.../ramips/base-files/etc/board.d/01_leds | 2 +-
.../ramips/base-files/etc/board.d/02_network | 5 -
target/linux/ramips/dts/R6120.dts | 20 +--
3 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/target/linux/ramips/base-files/etc/board.d/01_leds
b/target/linux/ramips/base-files/etc/board.d/01_leds
index e36f125126..056443c49d 100755
--- a/target/linux/ramips/base-files/etc/board.d/01_leds
+++ b/target/linux/ramips/base-files/etc/board.d/01_leds
@@ -248,8 +248,8 @@ mzk-ex750np)
;;
netgear,r6120)
ucidef_set_led_switch "lan" "lan" "$boardname:green:lan" "switch0"
"0x0f"
+ ucidef_set_led_switch "wan" "wan" "$boardname:green:wan" "switch0"
"0x10"
ucidef_set_led_wlan "wlan2g" "WiFi 2.4GHz" "$boardname:green:wlan2g"
"phy0tpt"
- ucidef_set_led_wlan "wlan5g" "WiFi 5GHz" "$boardname:green:wlan5g"
"phy1tpt"
;;
oy-0001)
set_wifi_led "$boardname:green:wifi"
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 74938121a8..7496926c37 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -107,7 +107,6 @@ ramips_setup_interfaces()
mtc,wr1201|\
mzk-750dhp|\
mzk-w300nh2|\
- netgear,r6120|\
nixcore-x1-8M|\
nixcore-x1-16M|\
oy-0001|\
@@ -336,6 +335,10 @@ ramips_setup_interfaces()
"0:lan" "1:lan" "2:lan" "3:lan" "6t@eth0"
ucidef_set_interface_wan "usb0"
;;
+ netgear,r6120)
+ ucidef_add_switch "switch0" \
+ "0:lan:4" "1:lan:3" "2:lan:2" "3:lan:1" "4:wan" "6@eth0"
+ ;;
hc5761)
ucidef_add_switch "switch0" \
"1:lan" "4:lan" "0:wan" "6@eth0"
diff --git a/target/linux/ramips/dts/R6120.dts
b/target/linux/ramips/dts/R6120.dts
index 375e400299..d37dde2145 100644
--- a/target/linux/ramips/dts/R6120.dts
+++ b/target/linux/ramips/dts/R6120.dts
@@ -55,13 +55,13 @@
gpios = <&gpio1 9 GPIO_ACTIVE_LOW>;
};
- wlan5 {
- label = "r6120:green:wlan5g";
+ wan {
+ label = "r6120:green:wan";
gpios = <&gpio1 8 GPIO_ACTIVE_LOW>;
};
- wlan5_orange {
- label = "r6120:orange:wlan5g";
+ wan_orange {
+ label = "r6120:orange:wan";
gpios = <&gpio1 7 GPIO_ACTIVE_LOW>;
};
};
@@ -103,7 +103,7 @@
read-only;
};
- nvram: partition@6 {
+ partition@6 {
label = "nvram";
reg = <0x6 0x3>;
read-only;
@@ -126,12 +126,12 @@
&wmac {
status = "okay";
- mtd-mac-address = <&nvram 0x100b0>;
- mediatek,mtd-eeprom = <&factory 0x2>;
+ mtd-mac-address = <&factory 0x4>;
+ mediatek,mtd-eeprom = <&factory 0x0>;
};
ðernet {
- mtd-mac-address = <&nvram 0x100b0>;
+ mtd-mac-address = <&factory 0x4>;
};
&pcie {
@@ -141,9 +141,9 @@
&pcie0 {
wifi@0,0 {
reg = <0x 0 0 0 0>;
- mediatek,mtd-eeprom = <&factory 0x28000>;
+ mediatek,mtd-eeprom = <&factory 0x8000>;
ieee80211-freq-limit = <500 600>;
- mtd-mac-address = <&nvram 0x100b0>;
+ mtd-mac-address = <&factory 0x4>;
mtd-mac-address-increment = <(2)>;
};
};
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ath79: fix qca955x pcie0 memory size
On 2/1/19 5:32 PM, Philippe Mathieu-Daudé wrote: > On 2/1/19 4:01 PM, Chuanhong Guo wrote: >> Hi! >> >> On Fri, Feb 1, 2019 at 9:53 PM Philippe Mathieu-Daudé >> wrote: >>> [...] >>> Now that you pointed this line, I am not sure it is correct... >>> It maps I/O (0x0100) region of 1B (0 0x01) from PCI 0x >>> (0 0x) at 0x000 (0x000) into cpu space. >>> But the DDR is already mapped at 0x000 in cpu address space... >>> Am I missing something? >> The atheros PCIE controller doesn't have an IO space at all. (at least >> the documentation doesn't mention it.) >> I'm not sure if it's possible to write a PCIE driver without IO space. > > Yes we can. I checked with someone from upstream Linux PCI before going with that statement; however Santiago told me via side chat this tree is based on a 4.14 kernel, where ath79 uses the pci-legacy driver. The legacy mips driver (and the sh4) fails if no IO space is provided. I see in the tree the similar pattern used by other boards ath79 based, so this is effectively a kludge for the legacy PCI driver. Since this is about a downstream distribution, I'd go with a patch to fix pci-legacy.c rather than mapping in DDR. If someone disagree, then I'd rather map those phantom IO spaces out of the DDR space. >> I guess the existing code just uses 1 byte of system memory as a >> placeholder. > > OK, so we can clearly get ride of that space then :) > > Cc'ing John who introduced the QCA in 53c474abbd. > > SAn: Can you test this snippet on your board and resend a patch? > > -- >8 -- > --- a/target/linux/ath79/dts/qca9557.dtsi > +++ b/target/linux/ath79/dts/qca9557.dtsi > @@ -187,6 +187,5 @@ > <0x1400 0x1000>; /* CFG */ > reg-names = "crp_base", "ctrl_base", > "cfg_base"; > - ranges = <0x200 0 0x1000 > 0x1000 0 0x0400/* pci memory */ > - 0x100 0 0x > 0x000 0 0x01>; /* io space */ > + ranges = <0x0200 0 0x1000 > 0x1000 0 0x0200>; > interrupt-parent = <&intc2>; > interrupts = <1>; > @@ -209,6 +208,5 @@ > <0x1600 0x1000>; /* CFG */ > reg-names = "crp_base", "ctrl_base", > "cfg_base"; > - ranges = <0x200 0 0x1200 > 0x1200 0 0x0200/* pci memory */ > - 0x100 0 0x > 0x000 0 0x01>; /* io space */ > + ranges = <0x0200 0 0x1200 > 0x1200 0 0x0200>; > interrupt-parent = <&intc3>; > interrupts = <0>; > > --- > > Regards, > > Phil. > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: add support for Xiaomi Mi Router 4Q
Hardware
CPU: Qualcomm Atheros QCA9561
RAM: 64M DDR2
FLASH: 16M SPI-NOR
ETH: 1x WAN - 2x LAN
WiFi: QCA9561 3T3R
BTN: 1x Reset - 1x WPS
LED: 1x Blue - 1x Red - 1x Yellow
UART: TX - GND - RX - VCC (From ethernet port)
115200n8 - 3.3V
Installation
1. Connect to the device via UART.
2. Interrupt the U-Boot on power-on by pressing enter when prompted.
3. Connect you computer to one of the routers LAN ports.
Assign yourself the IP 192.168.31.10/24.
Copy the OpenWRT initramfs image to a tftp server root directory.
Rename the image to 'x4q.bin'.
4. Load the initramfs image to the router by executing following command
in U-Boot. The image will boot afterwards.
> tftpboot 0x8100 x4q.bin; bootm
5. SCP the sysupgrade-image into '/tmp'.
Remember to assign yourself an IP in 192.168.1.0/24 for this step!
6. Install OpenWRT permanently by executing
> sysupgrade -n /tmp/
Signed-off-by: David Bauer
---
.../ath79/base-files/etc/board.d/02_network | 5 +
.../ath79/dts/qca9561_xiaomi_mi-router-4q.dts | 153 ++
target/linux/ath79/image/generic.mk | 7 +
3 files changed, 165 insertions(+)
create mode 100644 target/linux/ath79/dts/qca9561_xiaomi_mi-router-4q.dts
diff --git a/target/linux/ath79/base-files/etc/board.d/02_network
b/target/linux/ath79/base-files/etc/board.d/02_network
index 6f3ef614db..08f69e5a48 100755
--- a/target/linux/ath79/base-files/etc/board.d/02_network
+++ b/target/linux/ath79/base-files/etc/board.d/02_network
@@ -215,6 +215,11 @@ ath79_setup_interfaces()
ucidef_add_switch "switch0" \
"0@eth0" "2:lan" "3:wan"
;;
+ xiaomi,mi-router-4q)
+ ucidef_set_interface_wan "eth0"
+ ucidef_add_switch "switch0" \
+ "0@eth1" "3:lan:1" "4:lan:2"
+ ;;
*)
ucidef_set_interfaces_lan_wan "eth0" "eth1"
;;
diff --git a/target/linux/ath79/dts/qca9561_xiaomi_mi-router-4q.dts
b/target/linux/ath79/dts/qca9561_xiaomi_mi-router-4q.dts
new file mode 100644
index 00..8b8818c82f
--- /dev/null
+++ b/target/linux/ath79/dts/qca9561_xiaomi_mi-router-4q.dts
@@ -0,0 +1,153 @@
+// SPDX-License-Identifier: GPL-2.0+ OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "qca956x.dtsi"
+
+/ {
+ compatible = "xiaomi,mi-router-4q", "qca,qca9560";
+ model = "Xiaomi Mi Router 4Q";
+
+ aliases {
+ led-boot = &led_yellow;
+ led-failsafe = &led_red;
+ led-running = &led_blue;
+ led-upgrade = &led_red;
+ };
+
+ chosen {
+ bootargs = "console=ttyS0,115200n8";
+ };
+
+ keys {
+ compatible = "gpio-keys-polled";
+ poll-interval = <100>;
+
+ reset {
+ label = "Reset button";
+ linux,code = ;
+ gpios = <&gpio 21 GPIO_ACTIVE_LOW>;
+ };
+
+ wps {
+ label = "WPS/MI button";
+ linux,code = ;
+ gpios = <&gpio 19 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led_red: led_red {
+ label = "mi-router-4q:red:led";
+ gpios = <&gpio 1 GPIO_ACTIVE_LOW>;
+ };
+
+ led_yellow: led_yellow {
+ label = "mi-router-4q:yellow:led";
+ gpios = <&gpio 22 GPIO_ACTIVE_LOW>;
+ };
+
+ led_blue: led_blue {
+ label = "mi-router-4q:blue:led";
+ gpios = <&gpio 14 GPIO_ACTIVE_LOW>;
+ };
+ };
+};
+
+&uart {
+ status = "okay";
+};
+
+&gpio {
+ status = "okay";
+};
+
+&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>;
+
+ partition@0 {
+ label = "u-boot";
+ reg = <0x00 0x3>;
+ read-only;
+ };
+
+ partition@3 {
+ label = "nvram";
+ reg = <0x03 0x1>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "boarddata";
+ reg = <0x4 0x1>;
+ read-only;
+ };
+
+ partition
[OpenWrt-Devel] ath79: ar71xx: Upgrade: tl-wr842n-v1 has Wrong BOARDNAME in ar71xx Builds
As reported in https://forum.openwrt.org/t/ath79-image-builder-problem-for-wr842n-v1/30197/4?u=jeff the board configuration for the ar71xx tl-wr842n-v1 improperly sets BOARDNAME to TL-MR3420 (confirmed on master and on openwrt-18.06) As a result, users upgrading that device to ath79 will not have a seamless experience, requiring manual intervention. I'm hesitant to suggest that the TL-MR3420 be added to SUPPORTED_DEVICES for tl-wr842n-v2 under ath79, as I believe the MR3420 is a 4/32 device and the WR842N v1 is a 8/32 device. Some idiot uninformed user might suggest that TL-MR3420 users try to flash the 8 MB image. Jeff target/linux/ar71xx/image/generic-tp-link.mk: define Device/tl-wr842n-v1 $(Device/tplink-8m) DEVICE_TITLE := TP-LINK TL-WR842N/ND v1 DEVICE_PACKAGES := kmod-usb-core kmod-usb2 kmod-usb-ledtrig-usbport BOARDNAME := TL-MR3420 DEVICE_PROFILE := TLWR842 TPLINK_HWID := 0x08420001 endef TARGET_DEVICES += tl-wr842n-v1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ath79: fix qca955x pcie0 memory size
On 2/1/19 4:01 PM, Chuanhong Guo wrote: > Hi! > > On Fri, Feb 1, 2019 at 9:53 PM Philippe Mathieu-Daudé wrote: >> [...] >> Now that you pointed this line, I am not sure it is correct... >> It maps I/O (0x0100) region of 1B (0 0x01) from PCI 0x >> (0 0x) at 0x000 (0x000) into cpu space. >> But the DDR is already mapped at 0x000 in cpu address space... >> Am I missing something? > The atheros PCIE controller doesn't have an IO space at all. (at least > the documentation doesn't mention it.) > I'm not sure if it's possible to write a PCIE driver without IO space. Yes we can. > I guess the existing code just uses 1 byte of system memory as a > placeholder. OK, so we can clearly get ride of that space then :) Cc'ing John who introduced the QCA in 53c474abbd. SAn: Can you test this snippet on your board and resend a patch? -- >8 -- --- a/target/linux/ath79/dts/qca9557.dtsi +++ b/target/linux/ath79/dts/qca9557.dtsi @@ -187,6 +187,5 @@ <0x1400 0x1000>; /* CFG */ reg-names = "crp_base", "ctrl_base", "cfg_base"; - ranges = <0x200 0 0x1000 0x1000 0 0x0400/* pci memory */ - 0x100 0 0x 0x000 0 0x01>; /* io space */ + ranges = <0x0200 0 0x1000 0x1000 0 0x0200>; interrupt-parent = <&intc2>; interrupts = <1>; @@ -209,6 +208,5 @@ <0x1600 0x1000>; /* CFG */ reg-names = "crp_base", "ctrl_base", "cfg_base"; - ranges = <0x200 0 0x1200 0x1200 0 0x0200/* pci memory */ - 0x100 0 0x 0x000 0 0x01>; /* io space */ + ranges = <0x0200 0 0x1200 0x1200 0 0x0200>; interrupt-parent = <&intc3>; interrupts = <0>; --- Regards, Phil. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt 18.06.2 service release
The OpenWrt Community is proud to announce the second service release of the stable OpenWrt 18.06 series. OpenWrt 18.06.2 incorporates a fair number of bug fixes in the network userland and the build system, as well as updates to the kernel and base packages. --- Some selected highlights of the service release are: * Linux kernel updated to versions 4.9.152/4.14.95 (from 4.9.120/4.14.63 in v18.06.1) * Security fixes for the Linux kernel, GNU patch, Glibc, BZip2, Grub, OpenSSL and MbedTLS * Build system bug fixes * IPv6 and network service fixes For a detailed list of changes since 18.06.1 refer to https://openwrt.org/releases/18.06/changelog-18.06.2 --- For latest information about the 18.06 series, refer to the wiki at: https://openwrt.org/releases/18.06/ To download the v18.06.2 images, navigate to: https://downloads.openwrt.org/releases/18.06.2/ Have fun! The OpenWrt Community signature.asc Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ath79: fix qca955x pcie0 memory size
Hi! On Fri, Feb 1, 2019 at 9:53 PM Philippe Mathieu-Daudé wrote: > [...] > Now that you pointed this line, I am not sure it is correct... > It maps I/O (0x0100) region of 1B (0 0x01) from PCI 0x > (0 0x) at 0x000 (0x000) into cpu space. > But the DDR is already mapped at 0x000 in cpu address space... > Am I missing something? The atheros PCIE controller doesn't have an IO space at all. (at least the documentation doesn't mention it.) I'm not sure if it's possible to write a PCIE driver without IO space. I guess the existing code just uses 1 byte of system memory as a placeholder. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 2/2] ath79: fix qca955x dual pci resource allocation
On 1/29/19 5:12 AM, Santiago Piccinini wrote: > Tested with a dual pci QCA9558 board (LibreRouter v1) in three > configurations: enabling pcie0 only, pcie1 only and both enabled. > > Signed-off-by: Santiago Piccinini > --- > target/linux/ath79/dts/qca9557.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/ath79/dts/qca9557.dtsi > b/target/linux/ath79/dts/qca9557.dtsi > index 541aa6916e..77e5a316dd 100644 > --- a/target/linux/ath79/dts/qca9557.dtsi > +++ b/target/linux/ath79/dts/qca9557.dtsi > @@ -209,7 +209,7 @@ > <0x1600 0x1000>; /* CFG */ > reg-names = "crp_base", "ctrl_base", "cfg_base"; > ranges = <0x200 0 0x1200 0x1200 0 > 0x0200/* pci memory */ > - 0x100 0 0x 0x000 0 > 0x01>; /* io space */ > + 0x100 0 0x 0x001 0 > 0x01>; /* io space */ This host range is indeed already registered for pcie0. However I wonder if registering this I/O range make sense at all. (Also, see my question on patch 1/2 of this series remapping this into the DDR addr space). > interrupt-parent = <&intc3>; > interrupts = <0>; > > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH 1/2] ath79: fix qca955x pcie0 memory size
Hi Santiago, On 1/29/19 5:12 AM, Santiago Piccinini wrote: > Datasheet states that both PCI ranges are of 0x200 size: > 0x1000_-0x11FF_FFF and 0x1200_-0x13FF_. > > Signed-off-by: Santiago Piccinini Each PCIe root complex region is 32MB wide indeed. > --- > target/linux/ath79/dts/qca9557.dtsi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/target/linux/ath79/dts/qca9557.dtsi > b/target/linux/ath79/dts/qca9557.dtsi > index bfc2545b27..541aa6916e 100644 > --- a/target/linux/ath79/dts/qca9557.dtsi > +++ b/target/linux/ath79/dts/qca9557.dtsi > @@ -186,7 +186,7 @@ > reg = <0x180c 0x1000>, /* CRP */ > <0x180f 0x100>, /* CTRL */ > <0x1400 0x1000>; /* CFG */ > reg-names = "crp_base", "ctrl_base", "cfg_base"; > - ranges = <0x200 0 0x1000 0x1000 0 > 0x0400/* pci memory */ > + ranges = <0x200 0 0x1000 0x1000 0 > 0x0200/* pci memory */ "Map 32-bit non-prefetchable (0x0200) region of 32MB (0 0x0400) from PCI 0x1000 (0 0x1000) at 0x1000 (0x1000) into cpu space". OK, your change is correct, thus: Reviewed-by: Philippe Mathieu-Daudé > 0x100 0 0x 0x000 0 > 0x01>; /* io space */ Now that you pointed this line, I am not sure it is correct... It maps I/O (0x0100) region of 1B (0 0x01) from PCI 0x (0 0x) at 0x000 (0x000) into cpu space. But the DDR is already mapped at 0x000 in cpu address space... Am I missing something? I'm cc'ing Johann who initially wrote that. Regards, Phil. > interrupt-parent = <&intc2>; > interrupts = <1>; > ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] ar71xx: OM2P ImageBuilder no firmware when BIN_DIR used
Hi all, thanks to this[0] bug report I found that the ar71xx/generic ImageBuilder doesn't create any firmware images for profile OM2P when used with BIN_DIR. My first guess is that it's somewhat related to a hard coded destination which doesn't handle BIN_DIR. At the very end of an "successful" build log: > if [ -e > "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-factory.bin" > ]; then cp > "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-factory.bin" > > "/home/aparcar/worker/imagebuilder/openwrt/18.06.2/ar71xx/generic/bin/targets/ar71xx/generic/openwrt-18.06.2-c9d037b0992cca4-ar71xx-generic-om2p-squashfs-sysupgrade.bin"; > fi Running the following commands $ make image PROFILE="OM2P" $ ls openwrt-18.06.2-ar71xx-generic-device-om2p.manifest openwrt-18.06.2-ar71xx-generic-vmlinux.bin openwrt-18.06.2-ar71xx-generic-om2p-squashfs-factory.bin openwrt-18.06.2-ar71xx-generic-vmlinux.elf openwrt-18.06.2-ar71xx-generic-om2p-squashfs-sysupgrade.bin openwrt-18.06.2-ar71xx-generic-vmlinux.lzma openwrt-18.06.2-ar71xx-generic-root.squashfs openwrt-18.06.2-ar71xx-generic-vmlinux-lzma.elf openwrt-18.06.2-ar71xx-generic-uImage-lzma.bin sha256sums $ make image PROFILE="OM2P" BIN_DIR="/tmp/test/" $ ls /tmp/test/ openwrt-18.06.2-ar71xx-generic-device-om2p.manifest openwrt-18.06.2-ar71xx-generic-vmlinux.elf openwrt-18.06.2-ar71xx-generic-root.squashfs openwrt-18.06.2-ar71xx-generic-vmlinux.lzma openwrt-18.06.2-ar71xx-generic-uImage-lzma.bin openwrt-18.06.2-ar71xx-generic-vmlinux-lzma.elf openwrt-18.06.2-ar71xx-generic-vmlinux.bin sha256sums Hopefully someone could fix this! Best regards, Paul [0]: https://github.com/libremesh/chef/issues/79 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] lantiq: SMP interrupts and ethernet driver backport from vanilla v5
Dne 01. 02. 19 v 10:51 Hauke Mehrtens napsal(a):> On 1/31/19 9:30 PM, Mathias Kresin wrote: >> 30/01/2019 11:38, Petr Cvek: >>> Hi, thank you both for the answer and sorry for "./" in the patches I usually do only git patching :-D. The patches are really RFC only. For example I would like to know if a separate node is the best way for SMP irq controller (ICU). The second set of the registers could be just appended at the end of icu0 registers. Origin of patches: well I was able to find second ICU just by dumping iomem space and looking for patterns (which is enough to make a clean implementation), but I was lazy to write it (again, done it once for some FPGA) myself so I've copied part of the code from this repo: https://github.com/paldier/K3C-merlin/blob/master/release/src-lantiq/linux/linux-3.10.104/arch/mips/lantiq/irq.c The probable address of second ICU was confirmed by grepping the GPL source codes from my modem's vendor (tplink td-W9980) https://static.tp-link.com/resources/gpl/GPL_TD-W9980.tar.gz The burst flag is basically the same value as in "etop" code path. The warning about 8 word burst size is again from tplink source blob (btw I think the DMA_2W_BURST flag in 4.14.9x is actually 4 word burst, but I didn't confirmed it yet). > I am also interested in benchmarks with only one of the patches to know > which patch gives us which improvement. The IRQ controller patch needs > some improvements to get into mainline Linux kernel and I would look > into it if it creates some improvement. Thats gonna be a bit of a problem. My TD-W9980 has sadly a wave300 5G wifi driver, so I cannot test on it as it is broken and crashing the system (I've managed only make a few scans). For 2.4G wifi, I have only 150Mbps usb dongles, which are slow even without local interferences. My VDSL has only 22:2 which is OK even with vendor's firmware. My only option for a benchmarking is the ethernet which is (with the vanilla openwrt driver) extremely slow. My backport increased the TX speed of the modem from about 4.5 MiByte/s to about 7.5 MiByte/s (TCP netcat pipe, ACKs on RX FIFO). Gonna try iperf tomorrow. The driver works even with NFS rootfs over it. Sometimes a kernel warning about timeout is printed, but the system works afterwards and this is only a RFC stage. Probably some spinlock is missing or irq gets acked at the wrong place. It _will_ be fixed. What is interesting is my observation of long frames (4000-6000) which are sometimes coming from lantiq (observed in wireshark). My server is sending only classic ~1500 frames and I know the lantiq driver is limited to them too (+ tested in ip link set eth0 mtu 3000 -> error). > Are the IRQs on the 2. VPE used automatically or do you use it with irq > balanced? > Could you please provide the output of "cat /proc/interrupts" > The interupts are used automatically, but the distribution is quite random. I don't have irqbalance package compiled. # cat /proc/interrupts CPU0 CPU1 7: 31309 31096 MIPS 7 timer 8:586607 MIPS 0 IPI call 9: 5991 10371 MIPS 1 IPI resched 22: 14762 1 icu 22 spi_rx 23: 2496 1 icu 23 spi_tx 24: 0 0 icu 24 spi_err 62: 0 0 icu 62 1e101000.usb, dwc2_hsotg:usb1 63: 0192 icu 63 mei_cpe 72: 11133 0 icu 72 vrx200_rx 73: 0 13833 icu 73 vrx200_tx 91: 0 81 icu 91 1e106000.usb, dwc2_hsotg:usb2 112:745 0 icu 112 asc_tx 113: 0222 icu 113 asc_rx 114: 0 0 icu 114 asc_err 126: 0 0 icu 126 gptu 127: 0 0 icu 127 gptu 128: 0 0 icu 128 gptu 129: 0 0 icu 129 gptu 130: 0 0 icu 130 gptu 131: 0 0 icu 131 gptu 161: 0 0 icu 161 ifx_pcie_rc0 ERR: 1 (using napi polling decreases interrupt generation, so 11133 and 13833 values are not real number of packets transmitted, the vanilla driver has more then twice as much as backported driver) The affinity can be set in /proc/irq/$NUM, this can be used for testing the improvements cause by patch (the burst width can be written on the fly too). > We should probably make use for scattered DMA in > the driver too. I would like to try, but I don't have any vrx200 SoC TRM datasheets and even with different kernel versions (from vendors) the picture is not complete. Petr ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [RFC] lantiq: SMP interrupts and ethernet driver backport from vanilla v5
On 1/31/19 9:30 PM, Mathias Kresin wrote: > 30/01/2019 11:38, Petr Cvek: >> Hello, >> >> I discovered the lantiq xrx200 lacks support for interrupts on secondary >> VPE, and I've managed to add this functionality to the kernel, the >> second icu controller lives on base address 0x1f880300 and works in the >> same way as first. Tested with 4.14.93 kernel, untested patches in the >> attachment or on openwrt forum: >> >> https://forum.openwrt.org/t/xrx200-irq-balancing-between-vpes/29732/11 >> >> My second submission is a backported xrx200 ethernet driver from vanilla >> kernel v5 patched with switch and phy functions. Using kernel napi >> polling seems to highly increase the throughput of the network. >> >> Trying to initially increase the throughput of the network I've found >> there is an inefficiently setting of DMA burst size. My patch sets this >> value to a higher value. >> >> These two patches were tested with 4.14.93 kernel too, there is forum >> thread: >> >> https://forum.openwrt.org/t/how-can-we-make-the-lantiq-xrx200-devices-faster/9724/30 >> >> >> RFC for any parallel development info (next version of ethernet driver >> will be based on vanilla kernel version?), ideas, testing ... >> >> best regards, >> Petr Cvek > > Hey Petr, > > first of all, the patches don't apply as they are: > > is: ./a/arch/mips/lantiq/irq.c > expected: a/arch/mips/lantiq/irq.c > > For an official submission, a commit message is a must have. But even > for testing it would be nice to have a commit message explaining what a > patch is proposed to do. Otherwise it is kind of hard to provide any > comments. > > Furthermore, it would be very helpful if the source of the changes is > mentioned. At least parts of the code seem to be from intel/lantiq UGW 7.x. > > The backport of the vanilla eth driver breaks Ethernet completely on my > board. I dropped it during my testing. > > Since we're all busy, providing some numbers about the seen improvement > would might raise more interest. Ideally, you provide the numbers per > patch, to see if a specific patch really changes something. > > I gave the patches a quick try in conjunction with the irqbalance > package (to not move driver irqs from one core/vpe to another by hand). > I saw an improvement in throughput on my BT HomeHub 5a while doing iperf > from 5Ghz wireless to a lan client. > > The bandwidth was UP: 195 Mbits/s, DOWN: 137 Mbit/s with the patches > applied, while it was UP: 152 Mbit/s, DOWN: 95,5 MBit/s without. It's > more than the all time max of 180MBit, I measured a long time ago in a > test setup I can't remember. > > But I only consider wireless benchmarks in a shielded/isolated > environment as reliable anyway. It's good to know, but benchmarking the > ethernet (nat/routing) should be more reliable. As we speak of > benchmarking the ethernet, it would be interesting to see if enabling > flow offloading improves the situation even further. > > Of course, the 5GHz wireless bandwidth is still less than the 385 > Mbits/s I benchmarked with the BT firmware in the tests setup I can't > remember. Nevertheless, it's promising. > > Mathias Hi Petr, I am also interested in benchmarks with only one of the patches to know which patch gives us which improvement. The IRQ controller patch needs some improvements to get into mainline Linux kernel and I would look into it if it creates some improvement. Are the IRQs on the 2. VPE used automatically or do you use it with irq balanced? Could you please provide the output of "cat /proc/interrupts" I used vanilla upstream kernel without the OpenWrt patches and only got about 60MBit/s NAT performance, but I think about 300MBit/s software forwarding performance. We should probably make use for scattered DMA in the driver too. I plan to use this new driver + a DSA switch driver in OpenWrt, but we still need a good configuration migration script. Hauke ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
