[OpenWrt-Devel] [PATCH v3 1/2] ar71xx: Add support for PCIe on QCA953x
Signed-off-by: Sven Eckelmann
---
I got the chance to test the AP147-010 but got no software/SDK or documentation.
Still wanted to post my results because the device worked well enough for me.
I am not sure if it originally comes with a PCIe card (I've used at QCA9880
based one for my tests).
Most of the SoC relevant code is based on the QCA955x implementation.
v3:
- rebased on top of current trunk r46441 to fix conflict
v2:
- split into two patches
- rebased to fix conflict with r46207
.../740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch | 44 ++
.../740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch | 44 ++
2 files changed, 88 insertions(+)
create mode 100644
target/linux/ar71xx/patches-3.18/740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch
create mode 100644
target/linux/ar71xx/patches-4.1/740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch
diff --git
a/target/linux/ar71xx/patches-3.18/740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch
b/target/linux/ar71xx/patches-3.18/740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch
new file mode 100644
index 000..a57351e
--- /dev/null
+++
b/target/linux/ar71xx/patches-3.18/740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch
@@ -0,0 +1,44 @@
+--- a/arch/mips/ath79/pci.c
b/arch/mips/ath79/pci.c
+@@ -53,6 +53,15 @@ static const struct ath79_pci_irq ar724x
+ }
+ };
+
++static const struct ath79_pci_irq qca953x_pci_irq_map[] __initconst = {
++ {
++ .bus= 0,
++ .slot = 0,
++ .pin= 1,
++ .irq= ATH79_PCI_IRQ(0),
++ },
++};
++
+ static const struct ath79_pci_irq qca955x_pci_irq_map[] __initconst = {
+ {
+ .bus= 0,
+@@ -98,6 +107,9 @@ int __init pcibios_map_irq(const struct
+ soc_is_ar9344()) {
+ ath79_pci_irq_map = ar724x_pci_irq_map;
+ ath79_pci_nr_irqs = ARRAY_SIZE(ar724x_pci_irq_map);
++ } else if (soc_is_qca953x()) {
++ ath79_pci_irq_map = qca953x_pci_irq_map;
++ ath79_pci_nr_irqs = ARRAY_SIZE(qca953x_pci_irq_map);
+ } else if (soc_is_qca955x()) {
+ ath79_pci_irq_map = qca955x_pci_irq_map;
+ ath79_pci_nr_irqs = ARRAY_SIZE(qca955x_pci_irq_map);
+@@ -303,6 +315,15 @@ int __init ath79_register_pci(void)
+AR724X_PCI_MEM_SIZE,
+0,
+ATH79_IP2_IRQ(0));
++ } else if (soc_is_qca9533()) {
++ pdev = ath79_register_pci_ar724x(0,
++ QCA953X_PCI_CFG_BASE0,
++ QCA953X_PCI_CTRL_BASE0,
++ QCA953X_PCI_CRP_BASE0,
++ QCA953X_PCI_MEM_BASE0,
++ QCA953X_PCI_MEM_SIZE,
++ 0,
++ ATH79_IP2_IRQ(0));
+ } else if (soc_is_qca9558()) {
+ pdev = ath79_register_pci_ar724x(0,
+QCA955X_PCI_CFG_BASE0,
diff --git
a/target/linux/ar71xx/patches-4.1/740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch
b/target/linux/ar71xx/patches-4.1/740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch
new file mode 100644
index 000..a57351e
--- /dev/null
+++
b/target/linux/ar71xx/patches-4.1/740-MIPS-ath79-add-PCI-for-QCA953x-SoC.patch
@@ -0,0 +1,44 @@
+--- a/arch/mips/ath79/pci.c
b/arch/mips/ath79/pci.c
+@@ -53,6 +53,15 @@ static const struct ath79_pci_irq ar724x
+ }
+ };
+
++static const struct ath79_pci_irq qca953x_pci_irq_map[] __initconst = {
++ {
++ .bus= 0,
++ .slot = 0,
++ .pin= 1,
++ .irq= ATH79_PCI_IRQ(0),
++ },
++};
++
+ static const struct ath79_pci_irq qca955x_pci_irq_map[] __initconst = {
+ {
+ .bus= 0,
+@@ -98,6 +107,9 @@ int __init pcibios_map_irq(const struct
+ soc_is_ar9344()) {
+ ath79_pci_irq_map = ar724x_pci_irq_map;
+ ath79_pci_nr_irqs = ARRAY_SIZE(ar724x_pci_irq_map);
++ } else if (soc_is_qca953x()) {
++ ath79_pci_irq_map = qca953x_pci_irq_map;
++ ath79_pci_nr_irqs = ARRAY_SIZE(qca953x_pci_irq_map);
+ } else if (soc_is_qca955x()) {
+ ath79_pci_irq_map = qca955x_pci_irq_map;
+ ath79_pci_nr_irqs = ARRAY_SIZE(qca955x_pci_irq_map);
+@@ -303,6 +315,15 @@ int __init ath79_register_pci(void)
+AR724X_PCI_MEM_SIZE,
+0,
+ATH79_IP2_IRQ(0))
[OpenWrt-Devel] [PATCH v3 2/2] ar71xx: Add support for AP147-010 reference board
Signed-off-by: Sven Eckelmann
---
I got the chance to test the AP147-010 but got no software/SDK or documentation.
Still wanted to post my results because the device worked well enough for me.
I am not sure if it originally comes with a PCIe card (I've used at QCA9880
based one for my tests).
Most of the SoC relevant code is based on the QCA955x implementation.
v3:
- rebased on top of current trunk r46441 to fix conflict
v2:
- split into two patches
- rebased to fix conflict with r46207
target/linux/ar71xx/base-files/etc/diag.sh | 3 +
.../ar71xx/base-files/etc/uci-defaults/01_leds | 9 ++
.../ar71xx/base-files/etc/uci-defaults/02_network | 7 ++
target/linux/ar71xx/base-files/lib/ar71xx.sh | 3 +
.../lib/preinit/05_set_preinit_iface_ar71xx| 1 +
.../ar71xx/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ar71xx/config-3.18| 1 +
target/linux/ar71xx/config-4.1 | 1 +
.../ar71xx/files/arch/mips/ath79/mach-ap147.c | 125 +
target/linux/ar71xx/generic/profiles/atheros.mk| 10 ++
target/linux/ar71xx/image/Makefile | 3 +
target/linux/ar71xx/mikrotik/config-default| 1 +
target/linux/ar71xx/nand/config-default| 1 +
.../813-MIPS-ath79-add-ap147-support.patch | 42 +++
.../813-MIPS-ath79-add-ap147-support.patch | 42 +++
15 files changed, 250 insertions(+)
create mode 100644 target/linux/ar71xx/files/arch/mips/ath79/mach-ap147.c
create mode 100644
target/linux/ar71xx/patches-3.18/813-MIPS-ath79-add-ap147-support.patch
create mode 100644
target/linux/ar71xx/patches-4.1/813-MIPS-ath79-add-ap147-support.patch
diff --git a/target/linux/ar71xx/base-files/etc/diag.sh
b/target/linux/ar71xx/base-files/etc/diag.sh
index 12c31c4..916ed97 100644
--- a/target/linux/ar71xx/base-files/etc/diag.sh
+++ b/target/linux/ar71xx/base-files/etc/diag.sh
@@ -23,6 +23,9 @@ get_status_led() {
ap136-020)
status_led="ap136:green:status"
;;
+ ap147-010)
+ status_led="ap147:green:status"
+ ;;
ap135-020)
status_led="ap135:green:status"
;;
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
index d6f7d1a..2aced37 100644
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
@@ -46,6 +46,15 @@ ap113)
ucidef_set_led_usbdev "usb" "USB" "ap113:green:usb" "1-1"
;;
+ap147-010)
+ ucidef_set_led_netdev "wan" "WAN" "ap147:green:wan" "eth1"
+ ucidef_set_led_switch "lan1" "LAN1" "ap147:green:lan1" "switch0" "0x10"
+ ucidef_set_led_switch "lan2" "LAN2" "ap147:green:lan2" "switch0" "0x08"
+ ucidef_set_led_switch "lan3" "LAN3" "ap147:green:lan3" "switch0" "0x04"
+ ucidef_set_led_switch "lan4" "LAN4" "ap147:green:lan4" "switch0" "0x02"
+ ucidef_set_led_wlan "wlan2g" "WLAN 2.4 GHz" "ap147:green:wlan-2g"
"phy0tpt"
+ ;;
+
bullet-m | \
nanostation-m | \
rocket-m | \
diff --git a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
index e7dc538..53b3a7f 100755
--- a/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
+++ b/target/linux/ar71xx/base-files/etc/uci-defaults/02_network
@@ -46,6 +46,13 @@ ap136-010)
ucidef_add_switch_vlan "switch0" "2" "5 6"
;;
+ap147-010)
+ ucidef_set_interfaces_lan_wan "eth0" "eth1"
+ ucidef_add_switch "switch0" "1" "1"
+ ucidef_add_switch_vlan "switch0" "1" "0 1 2 3 4"
+ ucidef_add_switch_vlan "switch0" "2" "5 6"
+ ;;
+
ap136-020 |\
ap135-020 |\
tl-wr1043nd-v2 |\
diff --git a/target/linux/ar71xx/base-files/lib/ar71xx.sh
b/target/linux/ar71xx/base-files/lib/ar71xx.sh
index 9edd0cd..cc62b38 100755
--- a/target/linux/ar71xx/base-files/lib/ar71xx.sh
+++ b/target/linux/ar71xx/base-files/lib/ar71xx.sh
@@ -365,6 +365,9 @@ ar71xx_board_detect() {
*"AP143 reference board")
name="ap143"
;;
+ *"AP147-010 reference board")
+ name="ap147-010"
+ ;;
*AP81)
name="ap81"
;;
diff --git
a/target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx
b/target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx
index f11ea8c..d214e9b 100644
--- a/target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx
+++ b/target/linux/ar71xx/base-files/lib/preinit/05_set_preinit_iface_ar71xx
@@ -12,6 +12,7 @@ set_preinit_iface() {
alfa-nx |\
ap135-020 |\
ap136-020 |\
+ ap147-010 |\
ap83 |\
archer-c5 |\
archer-c7 |\
diff --git a/target/linux/ar71xx/base-files/lib/upgrade/platform.sh
b/target/linux/ar71xx/base-files/lib/up
[OpenWrt-Devel] ar71xx: spi difference between internal chip select and gpios as chip select
Hi, I would like to integrate the upstream devicetree ath79-spi patches into the ar71xx tree. But there are some improvements upstream which conflicts to use, they dropped the spi_controller_data, which is used by some boards to define the type of chip select. The type is internal or gpio. The internal chip selects are routed to gpios in the end. Is there a notable difference between the internal chip select and the direct accessed gpio variant? Did someone any performance tests on this? Best, lynxis -- Alexander Couzens mail: lyn...@fe80.eu jabber: lyn...@jabber.ccc.de mobile: +4915123277221 pgpcDGUH9dgV7.pgp Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
Hi Martin, On Sun, Jul 12, 2015 at 3:44 PM, Martin Blumenstingl wrote: > Since my latest patches were merged into the OpenWrt repository the > patch which updates the lantiq DSL drivers/application did not apply > anymore. > Here is the updated patch which applies against today's trunk: [0] > > Regards, > Martin > > > [0] https://gist.github.com/xdarklight/3452b26620b28f3bc577 over the course of this thread you mentioned having a similar setup as I do, so maybe you can help me out as I didn't yet get this working (neither did I without this patch and a couple of firmware versions): * I got a TDW8970 (non B version). If I understood correctly this is annex a as far as the official firmware is concerned, but with openwrt and the correct dsl firmware I can use this with annex b, right? * I got a german adsl annex b line * I'm using yesterday's trunk (b8bbdc62, which already has 703c4da0 'lantiq: Make the MEI address available for kernel drivers') with your patch quoted above on top * I'm using firmware 186b5406e6511c97d997b48f5e0ec5ad3f62600d The dsl line never syncs, and letting 'vdsl_cpe_control --c' just sit there spits out repeatedly: 'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used! Please change one of it.'. This sounds like an annex incompability? Was I wrong and there is a hardware difference and I cannot use the non B model with annex b? Thanks in advance, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
Hi Andre, On Thu, Jul 23, 2015 at 11:32 PM, Andre Heider wrote: > The dsl line never syncs, and letting 'vdsl_cpe_control --c' just sit > there spits out repeatedly: > 'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used! > Please change one of it.'. At some point during my tests I got a second device (an Arcadyan VGV7510KW22 - which came as "Annex B" device from the factory). Using the very same config made this device sync fine. > This sounds like an annex incompability? Was I wrong and there is a > hardware difference and I cannot use the non B model with annex b? Indeed, I have read multiple times that the DSL modem should support all annexes - but as our tests have shown: it doesn't (at least for ADSL). My guess is that the modem physically supports it but there's a bootstrap pin (to which a resistor is soldered... or not) which configures it to be Annex A *or* B only. The interesting part: VDSL is not affected by this (all ISPs in all countries seem to use VDSL over ISDN). I am using an Annex A device on a German VDSL line and this is working fine. bottom line: it seems that the modems are bound to a specific annex for ADSL operation. Regards, Martin ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Thu, 23 Jul 2015 23:51:33 +0200 Martin Blumenstingl wrote: > Hi Andre, > > On Thu, Jul 23, 2015 at 11:32 PM, Andre Heider wrote: > > The dsl line never syncs, and letting 'vdsl_cpe_control --c' just sit > > there spits out repeatedly: > > 'DSL_CPE: Wrong combination of DSL PHY Firmware and hybrid type used! > > Please change one of it.'. > At some point during my tests I got a second device (an Arcadyan > VGV7510KW22 - which came as "Annex B" device from the factory). Using > the very same config made this device sync fine. > > > This sounds like an annex incompability? Was I wrong and there is a > > hardware difference and I cannot use the non B model with annex b? > Indeed, I have read multiple times that the DSL modem should support > all annexes - but as our tests have shown: it doesn't (at least for > ADSL). My guess is that the modem physically supports it but there's a > bootstrap pin (to which a resistor is soldered... or not) which > configures it to be Annex A *or* B only. > The interesting part: VDSL is not affected by this (all ISPs in all > countries seem to use VDSL over ISDN). I am using an Annex A device on > a German VDSL line and this is working fine. > > bottom line: it seems that the modems are bound to a specific annex > for ADSL operation. I've seen the same. With annex b device, same firmware, the modem syncs to adsl, with annex a not. vdsl is working unrelated to the annex (B on A and vice versa is working). If someone would like to search for differences on the pcb, I can make photos of both pcbs. best, lynxis -- Alexander Couzens mail: lyn...@fe80.eu jabber: lyn...@jabber.ccc.de mobile: +4915123277221 pgpZF9K5gPTCo.pgp Description: OpenPGP digital signature ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
Hi Martin, On Thu, Jul 23, 2015 at 11:51 PM, Martin Blumenstingl wrote: >> This sounds like an annex incompability? Was I wrong and there is a >> hardware difference and I cannot use the non B model with annex b? > Indeed, I have read multiple times that the DSL modem should support > all annexes - but as our tests have shown: it doesn't (at least for > ADSL). My guess is that the modem physically supports it but there's a > bootstrap pin (to which a resistor is soldered... or not) which > configures it to be Annex A *or* B only. thanks for the confirmation, I feared as much :\ Regards, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
Hi Alexander, On Fri, Jul 24, 2015 at 12:03 AM, Alexander Couzens wrote: > If someone would like to search for differences on the pcb, I can make photos > of both pcbs. soldering rx, tx and gnd on a pcb for a serial connection is as far as my hardware skills go, but maybe we can figure out the differences together ;) If you find the time, could you attach photos to the wiki page? If we figure anything out I'm willing to attempt an annex change on my router. Regards, Andre ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
> If someone would like to search for differences on the pcb, I can make photos > of both pcbs. Please do, it might be interesting. Also, if they are not identical (except for ADSL annex) it might be very difficult to find relevant differences. It sort of does not make sense to me that the only difference hardware-wise would be pcb jumper. You would think that company like TP-Link is trying very hard to save money where they can. They already have different firmware for "B" versions (W8970B W8980B) so why not use some spare GPIO to pull front-end configuration pin to state in which it has to be (if this is really whats happening). You might say that it's protection against cross flashing firmware from the other model but it is already possible to crossflash W8980 to W9980 without any hardware changes. Why not protect against that? Another theory is that Lantiq might be enforcing such implementation on manufacturers but it is also unlikely for me. All the other settings seem to be changed only by firmware updates. Why not this one? https://en.wikipedia.org/wiki/Asymmetric_digital_subscriber_line#/media/File:ADSL_annex_overview.svg Looking at this graph it seems plausible that there is some kind of additional high-pass filter before front-end or entirely different chip adapted to upstream transmission on slightly higher frequency for Annex B. However, w8970 in my country is advertised as supporting ALL BUT Annex B in this graph and thus needs to cover full bandwidth. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Fri, Jul 24, 2015 at 12:55 AM, Aleksander Wałęski wrote: > so why not > use some spare GPIO to pull front-end configuration pin to state in > which it has to be Actually, it just dawned on me that they can be doing just that. In the bootloader. This is the only part of firmware we are not changing. If PCBs turn out to be identical we might want to check this. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] lantiq DSL drivers / firmware info
On Fri, Jul 24, 2015 at 1:00 AM, Aleksander Wałęski wrote: > Actually, it just dawned on me that they can be doing just that. In > the bootloader. This is the only part of firmware we are not changing. > If PCBs turn out to be identical we might want to check this. That was my first guess, but I am using the open source u-boot version on the BT Home Hub 5A (= Annex A device) and it still refuses to connect to Annex B (at least back when I tried last, I switched to VDSL like two months ago). If you can figure out where the boot_sel pins are (similar to [0] or [1]) to get it into CFG04 mode (= boot via UART) then I can add a patch for Daniel Schwierzeck's open source lantiq u-boot. But be aware: you need to pull some of them HIGH (= 3.3V, *NOT* 5V) - you could damage your device by pulling the wrong pin HIGH. Regards, Martin [0] http://wiki.openwrt.org/toh/arcadyan/vgv7510kw22 [1] http://wiki.openwrt.org/toh/bt/homehub_v5a ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] OpenWrt Summit RFP - Deadline August 21
To help encourage the growth and strength of OpenWrt, prpl Foundation is organizing the OpenWrt Summit. Co-located with ELCE in Dublin, Ireland on October 8, the OpenWrt Summit will be the first community conference focusing exclusively on OpenWrt. Free for all to attend, OpenWrt Summit does not require an ELCE ticket. As a community centered conference, I invite users, developers, business leaders, and anyone who is hoping to make a difference in OpenWrt to submit a speaking/session proposal for the OpenWrt Summit. Suggested topics include: * OpenWrt introductory topics (What is OpenWrt? How to build? How to install? How to build packages?) * Hardware (Adding new OpenWrt support for hardware you created or bought, contributing back to the core) * Forks of OpenWrt (Best practices, staying close to core) * OpenWrt usage (Unique and complex scenarios) * Security (Containers, jails, etc) * Culture (Encouraging new contributors, documentation, advocacy) * Internet of Things/Internet of Everything * Future of OpenWrt We also welcome any other session topic related to OpenWrt. Again, I encourage everyone interested to submit a session proposal for the OpenWrt Summit. Proposals should be submitted by August 21. To learn more and to submit your proposal, please visit: http://wiki.prplfoundation.org/wiki/OpenWrt_Summit_2015 Also, if you're interested in learning more about the conference, including lodging information, please visit this URL as well. I look forward to the session proposals! If you have any questions, don't hesitate to ask.. Thanks, Eric Schultz -- Eric Schultz, Community Manager, prpl Foundation http://www.prplfoundation.org eschu...@prplfoundation.org cell: 920-539-0404 skype: ericschultzwi @EricPrpl ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH V3] cdc_ncm: Add support for moving NDP to end of NCM frame
On 15/07/2015 19:57, John Crispin wrote: > > > On 15/07/2015 19:41, Matti Laakso wrote: >>> Hi, >>> >>> how is the testing going ? i would like to also pull this intot he CC >>> which means there is not that much time left. >>> >>> also the patch sent was missing proper subject and SoB. >>> >>> John >> >> Hi John, >> >> Sorry about the delay, it seems I've managed to kill the second USB-port >> in my main router, and the first was for extroot. Now I was able to test >> this on another router, and E3372s is working perfectly on current 15.05 >> with this patch. Pure plug-and-play, at least for IPv4 connectivity. I >> can send a properly formatted and signed-off patch shortly, hope it >> still makes it to 15.05. >> >> Matti > > > goodie, i'll pull it into CC done, do we also need this for 4.1 ? John ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
