Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 6/26/19 9:28 AM, Koen Vandeputte wrote: On 26.06.19 18:16, Ben Greear wrote: On 6/26/19 2:02 AM, Koen Vandeputte wrote: On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Hello, The splat decode does not match the source code, so I'm not which is correct. OpenWrt seems to add custom patches to your source. Please find the complete source in subsequent mail as being build. I did look in that code, and that is where I saw the mismatch. Please check your own local system and see if the splat matches your code? Maybe I made some mistake of course... You can paste ~20 lines of code around the proper splat line and then I can find it in my source... Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 26.06.19 18:16, Ben Greear wrote: On 6/26/19 2:02 AM, Koen Vandeputte wrote: On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Hello, The splat decode does not match the source code, so I'm not which is correct. OpenWrt seems to add custom patches to your source. Please find the complete source in subsequent mail as being build. Regards, Koen [ 32.341077] [ cut here ] [ 32.345898] WARNING: CPU: 0 PID: 1470 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-06-13-f0aa8130/ath10k-4.19/mac.c:6581 ath10k_mac_vif_beacon_free+0xc54/0x112c [ath10k_core] (line 6581 is not in the mac_vif_beacon_free method). Also, please enable the firmware DBGLOG logging per instructions here: http://www.candelatech.com/ath10k-bugs.php This is the suggested level to debug at: 0xc032 Will do and will get back on this. Thanks Thanks, Ben ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem with "base" release repositories
+1 Thanks for all Jo. Fernando On 26/06/2019 05:50, Bjørn Mork wrote: Jo-Philipp Wich writes: the base repositories have been fully restored and should be safe to use again. Thank you for both fast resolution and the continous info updates. That's pretty impressive, and I just have to wonder how much sleep you got last night :-) IMHO, this was a demonstration of professional issue handling with very limited resources. OpenWrt is obviously in good hands these days. A big thanks to you all! Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem with "base" release repositories
> Op 26 jun. 2019, om 10:50 heeft Bjørn Mork het volgende > geschreven: > > Jo-Philipp Wich writes: > >> the base repositories have been fully restored and should be safe to use >> again. > > Thank you for both fast resolution and the continous info updates. > That's pretty impressive, and I just have to wonder how much sleep you > got last night :-) > > IMHO, this was a demonstration of professional issue handling with very > limited resources. OpenWrt is obviously in good hands these days. > > A big thanks to you all! > > > > > Bjørn > > ___ > openwrt-devel mailing list > openwrt-devel@lists.openwrt.org > https://lists.openwrt.org/mailman/listinfo/openwrt-devel Absolutely true. So, deepest respect from me as well. Paul ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ath79: add support for gl-ar750
This patch supports gl-ar750, which was previously supported by ar71xx.
Specification:
- SOC: QCA9531 (650MHz)
- Flash: 16 MiB (W25Q128FVSG)
- RAM: 128 MiB DDR2
- Ethernet: 10/100: 2xLAN + 10/100: 1xWAN
- Wireless: 2.4GHz (bgn) and 5GHz (ac)
- USB: 1x USB 2.0 port
- Switch: 1x switch
- Button: 1x reset button
- LED: 3x LEDS (white)
Flash instruction:
Support for sysupgrade directive upgrades, as well as luci upgrades.
Signed-off-by: luochongjun
---
.../etc/hotplug.d/firmware/11-ath10k-caldata | 1 +
target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts | 151 +
target/linux/ath79/image/generic.mk| 8 ++
3 files changed, 160 insertions(+)
create mode 100644 target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
diff --git
a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
index 8f0ea1d..6a9cb1c 100644
--- a/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
+++ b/target/linux/ath79/base-files/etc/hotplug.d/firmware/11-ath10k-caldata
@@ -116,6 +116,7 @@ case "$FIRMWARE" in
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(cat
/sys/class/net/eth0/address) +1)
;;
+ glinet,gl-ar750|\
glinet,gl-ar750s)
ath10kcal_extract "art" 20480 2116
ath10kcal_patch_mac $(macaddr_add $(mtd_get_mac_binary art 0)
+1)
diff --git a/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
new file mode 100644
index 000..c20cdf5
--- /dev/null
+++ b/target/linux/ath79/dts/qca9531_glinet_gl-ar750.dts
@@ -0,0 +1,151 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+/dts-v1/;
+
+#include
+#include
+
+#include "qca953x.dtsi"
+
+/ {
+ compatible = "glinet,gl-ar750", "qca,qca9531";
+ model = "GL.iNet GL-AR750";
+
+ keys {
+ compatible = "gpio-keys";
+
+ poll-interval = <20>;
+ pinctrl-names = "default";
+ pinctrl-0 = <_disable_pins>;
+
+ reset {
+ label = "reset";
+ linux,code = ;
+ gpios = < 3 GPIO_ACTIVE_LOW>;
+ };
+
+ mode {
+ label = "mode";
+ linux,code = ;
+ gpios = < 0 GPIO_ACTIVE_LOW>;
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ power {
+ label = "gl-ar750:white:power";
+ gpios = < 12 GPIO_ACTIVE_LOW>;
+ default-state = "on";
+ };
+
+ wlan2g {
+ label = "gl-ar750:white:wlan2g";
+ gpios = < 14 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "phy1tpt";
+ };
+
+ wlan5g {
+ label = "gl-ar750:white:wlan5g";
+ gpios = < 13 GPIO_ACTIVE_LOW>;
+ linux,default-trigger = "phy0tpt";
+ };
+
+ };
+
+ i2c {
+ compatible = "i2c-gpio";
+
+ sda-gpios = < 17 GPIO_ACTIVE_LOW>;
+ scl-gpios = < 16 GPIO_ACTIVE_LOW>;
+ };
+
+
+};
+
+ {
+ status = "okay";
+
+ wifi@0,0 {
+ compatible = "qcom,ath10k";
+ reg = <0 0 0 0 0>;
+ device_type = "pci";
+ };
+};
+
+ {
+ status = "okay";
+};
+
+ {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ status = "okay";
+
+ hub_port: port@1 {
+ reg = <1>;
+ #trigger-source-cells = <0>;
+ };
+};
+
+_phy {
+ status = "okay";
+};
+
+ {
+ status = "okay";
+ num-cs = <0>;
+
+ 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 0x04>;
+ read-only;
+ };
+
+ partition@4 {
+ label = "u-boot-env";
+ reg = <0x04 0x01>;
+ read-only;
+ };
+
+ art: partition@5 {
+ label = "art";
+ reg = <0x05 0x01>;
+ read-only;
+ };
+
+ partition@6 {
+ compatible =
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 26.06.19 11:02, Koen Vandeputte wrote: On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Regards, Koen Here is the source as compiled in openwrt: http://www.xback.be/ath10k-419.tar.xz Koen ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] ath10k-ct 4.19 and IBSS
On 25.06.19 15:54, Ben Greear wrote: On 06/25/2019 02:53 AM, Koen Vandeputte wrote: On 24.06.19 22:04, Ben Greear wrote: On 6/24/19 8:32 AM, Koen Vandeputte wrote: Hi Ben, Hi All, So I'm going to give this another try .. As the IBSS functionality is heavily advertised as a delta to mainline, it would be very nice to get it working also :) Testing the latest ath10k-ct driver and firmware seems to be a step back compared to roughly a month ago. I'm currently seeing the firmware crashing, which was not the case before: ath10k-ct + htt-fw: https://pastebin.com/raw/7Sy9yx6s Looks like firmware ran out of some WMI event buffers and crashed instead of handling it more gracefully. Please try the attached (untested) firmware and see if it behaves better. Hi Ben, 1 step forward here. I'm not seeing crashes anymore using the test-firmware. https://pastebin.com/raw/4ZeXu7iw I've linked up 2 IBSS devices (wave 1, VHT80) OLSR traffic (UDP) works and packets here are nicely going back & forth. Simply pinging (ICMP) between the 2 devices does not work. When sending 100 pings, (64 byte large) sometimes 1 gets through .. but with a latency of > 500ms I think if the splat and the beacon spam below could be fixed .. this would be a major step forward: [ 30.328423] [ cut here ] [ 30.333251] WARNING: CPU: 0 PID: 1578 at /mnt/ramdisk/koen/firmware/builds/generic_rb922/build_dir/target-mips_24kc_musl/linux-ar71xx_mikrotik/ath10k-ct-2019-05-08-f98b6dc4/ath10k-4.19/mac.c:6563 ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.355636] Modules linked in: mbt ath9k ath9k_common qcserial pppoe ppp_async option cdc_mbim ath9k_hw ath10k_pci ath10k_core ath usb_wwan sierra_net sierra rndis_host qmi_wwan pppox ppp_generic mac80211 iptable_nat iptable_mangle iptable_filter ipt_REJECT ipt_MASQUERADE ip_tables huawei_cdc_ncm ftdi_sio cfg80211 cdc_subset cdc_ncm cdc_ether xt_time xt_tcpudp xt_state xt_nat xt_multiport xt_mark xt_mac xt_limt [ 30.427331] nls_utf8 nls_iso8859_1 nls_cp437 authenc ehci_platform sd_mod scsi_mod ehci_hcd gpio_button_hotplug ext4 mbcache jbd2 usbcore nls_base usb_common ptp pps_core mii aead crypto_null cryptomgr crc32c_generic crypto_hash [ 30.448017] CPU: 0 PID: 1578 Comm: wpa_supplicant Not tainted 4.14.129 #0 Please look in your code and let me know the source around the line in mac.c (6563) that is splatting. Also, you might grab the latest ath10k-ct repo, it has a tweak that might fix the SWBA overrun messages. https://github.com/greearb/ath10k-ct Thanks, Ben Hi Ben, Here is the output based on the latest git HEAD of your ct tree, combined with the test firmware: https://pastebin.com/raw/kwC6c18J Regards, Koen [ 30.454906] Stack : 8050 804c0870 80495404 86fc5a24 8606485c 804e7307 [ 30.463402] 804915c8 062a 805437d0 19a3 87d1ed28 0001 86fc59d8 ebb059e8 [ 30.471880] 8054 68e8 0007 [ 30.480373] 0123 f55b2536 0122 8000 87152504 8710ccc4 [ 30.488863] 0009 19a3 87d1ed28 876fd000 802a3964 8054 [ 30.497355] ... [ 30.499839] Call Trace: [ 30.502320] [<8006c7ac>] show_stack+0x58/0x100 [ 30.506838] [<80086de0>] __warn+0xe4/0x118 [ 30.510994] [<80086ea4>] warn_slowpath_null+0x1c/0x28 [ 30.516158] [<8710ccc4>] ath10k_mac_vif_beacon_free+0xc7c/0x115c [ath10k_core] [ 30.523505] ---[ end trace 83fd3571e310245a ]--- [ 33.172852] wlan0: Trigger new scan to find an IBSS to join [ 33.237416] wlan0: Trigger new scan to find an IBSS to join [ 33.243317] wlan0: Trigger new scan to find an IBSS to join [ 33.249205] wlan0: Trigger new scan to find an IBSS to join [ 33.305210] wlan0: Trigger new scan to find an IBSS to join [ 34.049614] wlan0: Trigger new scan to find an IBSS to join [ 34.115369] wlan0: Trigger new scan to find an IBSS to join [ 34.189823] wlan0: Selected IBSS BSSID fa:77:78:55:af:7b based on configured SSID [ 34.280540] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.288002] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.295924] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.303406] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.310839] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.318280] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.325714] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.333148] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.340567] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon [ 34.348003] ath10k_pci :01:00.0: SWBA overrun on vdev 0, skipped old beacon ... ... Thanks for your swift
[OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-NV1
SoC:Mediatek MT7621A
CPU:4x 880Mhz
Cache: 32 KB I-Cache and 32 KB D-Cach
256 KB L2 Cache (shared by Dual-Core)
RAM:DDR3 512MB 16bits BUS
FLASH: 16MB
Switch: Mediatek Gigabit Switch (2 x LAN, 1 x WAN)
POE:(1x PD, 2x PSE)
USB:1x 3.0
PCI:3x Mini PCIe (3 USB2.0 + 2 x UIM interface)
GPS:Quectel L70B
SIM:2 Slots
BTN:Reset
LED:- Power
- Ethernet
- Wifi
- USB
UART: UART is present as Pads with throughholes on the PCB.
They are located on left side.
3.3V - RX - GND - TX / 57600-8N1
3.3V is the square pad
Installation
The stock image is a modified openwrt and can be overflashed via sysupgrade
-F
Signed-off-by: Daniel Danzberger
---
target/linux/ramips/base-files/etc/board.d/02_network | 3 +++
target/linux/ramips/dts/AP7621-NV1.dts| 9 +
target/linux/ramips/image/mt7621.mk | 9 +
3 files changed, 21 insertions(+)
create mode 100644 target/linux/ramips/dts/AP7621-NV1.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 02ef30cade..a276adb32c 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -42,6 +42,9 @@ ramips_setup_interfaces()
asiarf,ap7621-001)
ucidef_add_switch "switch0" "0:lan" "4:wan" "6@eth0"
;;
+ asiarf,ap7621-nv1)
+ ucidef_add_switch "switch0" "0:wan" "2:lan" "3:lan" "6@eth0"
+ ;;
3g150b|\
3g300m|\
a5-v11|\
diff --git a/target/linux/ramips/dts/AP7621-NV1.dts
b/target/linux/ramips/dts/AP7621-NV1.dts
new file mode 100644
index 00..aad222f155
--- /dev/null
+++ b/target/linux/ramips/dts/AP7621-NV1.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/dts-v1/;
+#include "AP7621-001.dts"
+
+/ {
+ compatible = "asiarf,ap7621-nv1", "mediatek,mt7621-soc";
+ model = "AsiaRF AP7621-NV1";
+};
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index dce24308b8..b32cdf4100 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -659,3 +659,12 @@ define Device/asiarf_ap7621-001
endef
TARGET_DEVICES += asiarf_ap7621-001
+define Device/asiarf_ap7621-nv1
+ DTS := AP7621-NV1
+ IMAGE_SIZE := $(ralink_default_fw_size_16M)
+ DEVICE_TITLE := AsiaRF AP7621-NV1
+ DEVICE_PACKAGES := \
+ kmod-sdhci-mt7620 kmod-mt76x2 kmod-usb3
+endef
+TARGET_DEVICES += asiarf_ap7621-nv1
+
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] Problem with "base" release repositories
Jo-Philipp Wich writes: > the base repositories have been fully restored and should be safe to use > again. Thank you for both fast resolution and the continous info updates. That's pretty impressive, and I just have to wonder how much sleep you got last night :-) IMHO, this was a demonstration of professional issue handling with very limited resources. OpenWrt is obviously in good hands these days. A big thanks to you all! Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-NV1
Daniel Danzberger writes: > The AP7621-NV1 is basically an AP7621-001 with additional peripherals: > > - +1 Ethernet Port (POE: 1x PD, 2x PSE) > - 2 SIM slots > - 3 PICe USB2.0 + 2 x UIM interface > > Installation: > Same as on the AP7621-001. Overflash with sysupgrade -F. Please write the full description and instructions. You don't have to save any space here. References like this is hard to look up, and completely unnecessary. And s/PICe/PCIe/ Bjørn ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ramips: mt7621: Add new device AsiaRF AP7621-NV1
The AP7621-NV1 is basically an AP7621-001 with additional peripherals:
- +1 Ethernet Port (POE: 1x PD, 2x PSE)
- 2 SIM slots
- 3 PICe USB2.0 + 2 x UIM interface
Installation:
Same as on the AP7621-001. Overflash with sysupgrade -F.
Signed-off-by: Daniel Danzberger
---
target/linux/ramips/base-files/etc/board.d/02_network | 3 +++
target/linux/ramips/dts/AP7621-NV1.dts| 9 +
target/linux/ramips/image/mt7621.mk | 9 +
3 files changed, 21 insertions(+)
create mode 100644 target/linux/ramips/dts/AP7621-NV1.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 02ef30cade..a276adb32c 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -42,6 +42,9 @@ ramips_setup_interfaces()
asiarf,ap7621-001)
ucidef_add_switch "switch0" "0:lan" "4:wan" "6@eth0"
;;
+ asiarf,ap7621-nv1)
+ ucidef_add_switch "switch0" "0:wan" "2:lan" "3:lan" "6@eth0"
+ ;;
3g150b|\
3g300m|\
a5-v11|\
diff --git a/target/linux/ramips/dts/AP7621-NV1.dts
b/target/linux/ramips/dts/AP7621-NV1.dts
new file mode 100644
index 00..aad222f155
--- /dev/null
+++ b/target/linux/ramips/dts/AP7621-NV1.dts
@@ -0,0 +1,9 @@
+// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
+
+/dts-v1/;
+#include "AP7621-001.dts"
+
+/ {
+ compatible = "asiarf,ap7621-nv1", "mediatek,mt7621-soc";
+ model = "AsiaRF AP7621-NV1";
+};
diff --git a/target/linux/ramips/image/mt7621.mk
b/target/linux/ramips/image/mt7621.mk
index dce24308b8..b32cdf4100 100644
--- a/target/linux/ramips/image/mt7621.mk
+++ b/target/linux/ramips/image/mt7621.mk
@@ -659,3 +659,12 @@ define Device/asiarf_ap7621-001
endef
TARGET_DEVICES += asiarf_ap7621-001
+define Device/asiarf_ap7621-nv1
+ DTS := AP7621-NV1
+ IMAGE_SIZE := $(ralink_default_fw_size_16M)
+ DEVICE_TITLE := AsiaRF AP7621-NV1
+ DEVICE_PACKAGES := \
+ kmod-sdhci-mt7620 kmod-mt76x2 kmod-usb3
+endef
+TARGET_DEVICES += asiarf_ap7621-nv1
+
--
2.20.1
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
