Without this patch, an extra entry appears for AR9287 GPIO
that duplicates WLAN LED but in fact drives nothing:
gpiochip1: GPIOs 502-511, ath9k-phy0:
gpio-502 ( |netgear:blue:wlan ) out hi
gpio-503 ( |netgear:amber:test ) out hi
gpio-504 ( |netgear:green:power ) out lo
gpio-505 ( |rfkill ) in hi
gpio-507 ( |wps ) in hi
gpio-508 ( |reset ) in hi
gpio-510 ( |ath9k-phy0 ) out hi <===!
The pin pointed above is default LED GPIO (8) for AR9287.
For WNR2200 it is not connected anywhere - pin 0 drives blue WLAN
LED instead - but initialization code is missing that information.
This fix calls ap9x_pci_setup_wmac_led_pin() function at device
setup, forcing WLAN LED pin to be 0 and removing redundant entry.
Signed-off-by: Michal Cieslakiewicz <michal.cieslakiewicz@wp.pl>
tx_size was just declared above and set to BIT(tx->order)
Use the declaration instead, which could avoid a pointer deref
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
(cherry picked from commit 6852eab58236e3991f5d73f211018dfef01f2a64)
Backport of a4eef43a12 ("ath79: ag71xx: replace alloc_etherdev with devm_alloc_etherdev")
combined with the initial changes from John Crispin.
Simplifies the code a lot by using the Managed dev API.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Backport of 4eaa3626a8 ("ath79: ag71xx: pass correct device pointer to dma functions")
While 4.14 does not contain the warnings,
it still makes sense to use the proper pointers here.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
All other instances of this identical declaration fetch the
value directly from the ring_order.
Also do it here.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
ar71xx got lost during final rebase ..
Fixes: c8a6ce71e4 ("ar71xx/ath79: ag71xx: init rings with GFP_KERNEL")
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
The Aerohive HiveAP 121 has the wrong PLL value set for Gigabit speeds,
leading to packet-loss. 10M and 100M work fine.
This commit sets the Gigabit Ethernet PLL value to the correct value,
fixing packet loss.
Confirmed with iperf and floodping.
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit cb49e46a8a4526d86270ced3ba3aa90225ca82d7)
commit e09da0169a08 ("ar71xx: fix Mikrotik board detection")
was generated based on testing a rb-912 board, on which detection failed.
Testing on more hardware shows something fun:
machine : MikroTik RouterBOARD 922UAGS-5HPacD
machine : Mikrotik RouterBOARD 912UAG-5HPnD
Both lowercase and uppercase are used.
So ensure we support both now ..
Fixes: e09da0169a08 ("ar71xx: fix Mikrotik board detection")
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
(cherry picked from commit 845b2a1cfe307394f3f2144cce085bbb5e171ecc)
Fix a typo in the machine type being extracted from /proc/cpuinfo
which causes all Mikrotik board to be undetected properly.
This lead to sysupgrade issues and probably some others too.
Fixes: 76c963bb01 ("ar71xx: base-files: fix board detect on new MikroTik devices")
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Update WLAN LED colour identifier for both interfaces on Archer C7
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
(cherry picked from commit 65762cdd2223d759f5836214143888e32ce5766b)
Move system LED board definitions of Archer C5/C7 to reflect
actual system LED colour used
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
(cherry picked from commit a73934fc9ad05207e79a3e58abc3d14eee28b6f2)
All leds on these boards are green. v1 has RFKILL GPIO 23 for production
units (it had GPIO 13 only for test phase units, and these are rather
very rare to find). As for the previous attempt to fix this and revert
due to WDR boards have blue leds, it was wrong: WDR board does not use
common setup (false).
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
(cherry picked from commit c79c001b593bd826d51722f2c83ad8770255f3b3)
Base address for USB0 has changed from 0x18116c94 on AR934X
to 0x18116d94 on QCA9558. CP Typo remained for years here...
Signed-off-by: Tomislav Požega <pozega.tomislav@gmail.com>
(cherry picked from commit fd5aa19480b92045db224a2d2450680e9fe66385)
fixes intermittent loss of connectivity on 1Gbit port, with log message:
> 803x_aneg_done: SGMII link is not ok
Thanks to David Bauer for pointing me in the right direction.
I just had to figure out the right bus_id, which you find in this log:
> ag71xx ag71xx.1: connected to PHY at gpio-1:00 [uid=004dd074,
driver=Atheros 8031 ethernet]
Fixes FS#2236
Signed-off-by: Etienne Champetier <champetier.etienne@gmail.com>
[Wrapped commit message - Fixed whitespace erors]
Signed-off-by: David Bauer <mail@david-bauer.net>
(cherry picked from commit 2a7519e29d6cbbe1eb73623ef35add0ef596fb5f)
While flashing lots of RB2011 devices, I noticed that
some of them refused to boot properly, failing over the NAND parameters.
Checking in detail shows that some device seem to use another NAND flash
which only support standard 2048-byte pages, without 512-byte subpage support.
This commit disables usage of these small subpage completely.
Advantages:
- Both NAND's with(out) subpage support are working now
- The nand speed increases a bit (measured roughly 1%) in typical usecases
Disadvantages:
- The maximum storage capacity decreases by ~0.2%
as small changes can consume a full page (2048 bytes) now.
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Apply the same approach as in commit 3b53d6fdbc ("ar71xx: fix pci irq
init on kernel 4.14") to fix IRQ initialization for ath79-based chipsets
on rb4xx.
Ref: PR#2182
Acked-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Signed-off-by: W. Michael Petullo <mike@flyn.org>
[commit ref fix]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
(cherry picked from commit 8c7d6c47a7893db689e50e1917479ad07a96547a)
Move all MikroTik devices to new function to increase script execution
speed.
Machine name in new version of MikroTik RouterBOARD devices add "RB"
before model name:
Old machine name: MikroTik RouterBOARD 951Ui-2nD
New: MikroTik RouterBOARD RB951Ui-2nD
So this patch should fix it for all currently supported MikroTik boards.
Tested-by: Cezary Jackiewicz <cezary@eko.one.pl> [wAP R-2nD]
Signed-off-by: Henryk Heisig <hyniu@o2.pl>
[rebased,commit message facelift,script fixes]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
[spotted missing 922UAGS-5HPacD]
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Refreshed all patches.
This bump contains upstream commits which seem to avoid (not properly fix)
the errors as seen in FS#2305 and FS#2297
Altered patches:
- 403-net-mvneta-convert-to-phylink.patch
- 410-sfp-hack-allow-marvell-10G-phy-support-to-use-SFP.patch
Compile-tested on: ar71xx, cns3xxx, imx6, mvebu, x86_64
Runtime-tested on: ar71xx, cns3xxx, imx6, x86_64
Signed-off-by: Koen Vandeputte <koen.vandeputte@ncentric.com>
Remove references to broken and mostly deprecated phy_ethtool_ioctl, use
new {s,g}et_link_ksettings and add nway_reset which was previously
handled in phy_ethtool_ioctl.
Cc: John Crispin <john@phrozen.org>
Ref: https://bugs.openwrt.org/index.php?do=details&task_id=1982
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This ioctl is currently routed through generic interface code:
dev_ioctl
dev_ethtool
__ethtool_get_link_ksettings
phy_ethtool_ioctl
Cc: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The vendor firmware only uses two mac addresses, the mac address on the
label and the label + 1. While checking multiple devices, all labels have
even mac addresses. Concluding only 2 address are assigned to a device.
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Commit "generic: ar8216: add mib_poll_interval switch attribute" sets
mib-poll-interval as disabled by default (was set to 2s), so it makes
switch LEDs trigger disfunctional on devices which don't have
mib-poll-interval set.
So this patch sets mib-poll-interval to 500ms on devices which are using
ar8xxx switch LEDs trigger, as the same value was set for built in
switches in 443fc9ac35 ("ath79: use ar8216 for builtin switch").
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Signed-off-by: Chuanhong Guo <gch981213@gmail.com>
Network for the Archer C25 v1 is set up without switch for no
obvious reason. The LED setup is even done switch-based.
This patch changes network setup so a switch is created.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Switches failsafe mode interface from WAN to LAN ports.
Tested on TL-WR940Nv6.0 and TL-WR940Nv6.1
Signed-off-by: Joachim Fünfer <joachim.fuenfer@stusta.net>
This commit fixes following script error in syslog:
cat: can't open '/sys/devices/platform/ehci-platform/usb1/1-1/1-1.2/1-1.2:1.4/ieee80211/phy*/name': No such file or directory
sh: add: unknown operand
sh: add: unknown operand
Signed-off-by: Rosy Song <rosysong@rosinson.com>
Signed-off-by: Petr Štetiar <ynezz@true.cz>
[commit subject and message tweaks]
This device shares the network config with v4, thus the WAN MAC
also needs to be fixed the same way. However, the partition
where the MAC address resides has been changed.
Based on: https://github.com/openwrt/openwrt/pull/1726
Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
It was reported, that latest ar71xx builds have broken networking on
TP-Link TL-WPA8630 and Nanostation M5 XW devices and that by reverting
the offending commit, everything is back to normal.
Fixes: d3506d1 ("ar71xx: ag71xx: fix compile error when enabling debug")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
CPU: AR9342 SoC
RAM: 64 MB DDR2
Flash: 8 MB NOR SPI
Ports: 100 MBit (24V PoE in)
WLAN: 2.4/5 GHz
UART: 1 UART on PCB marked as J1 with 115200 8N1 config
LEDs: Power, Ethernet, 4x RSSI LEDs (orange, red, 2x green)
Buttons: Reset
UART connection details
.---------------------------------.
| |
[ETH] J1 [ANT]
| o VCC o RX o TX o GND |
`---------------------------------'
Flashing instructions using recovery method over TFTP
1. Unplug the ethernet cable from the router.
2. Using paper clip press and hold the router's reset button. Make sure
you can feel it depressed by the paper clip. Do not release the button
until step 4.
3. While keeping the reset button pressed in, plug the ethernet cable
back into the AP. Keep the reset button depressed until you see the
device's LEDs flashing in upgrade mode (alternating LED1/LED3 and
LED2/LED4), this may take up to 25 seconds.
4. You may release the reset button, now the device should be in TFTP
transfer mode.
5. Set a static IP on your Computer's NIC. A static IP of 192.168.1.25/24
should work.
6. Plug the PoE injector's LAN cable directly to your computer.
7. Start tftp client and issue following commands:
tftp> binary
tftp> connect 192.168.1.20
tftp> put openwrt-ar71xx-generic-ubnt-bullet-m-xw-squashfs-factory.bin
Tested only on Bullet M2HP.
Signed-off-by: Petr Štetiar <ynezz@true.cz>
This is backport of the same functionality in ath79, from commit
d42a7c469 ("ath79: ubnt-m-xw: Fix factory image flashing using TFTP
recovery method")
Ubiquity allows flashing of unsigned factory images via TFTP recovery
method[1]. They claim in airOS v6.0.7 release changelog[2] following:
All future airOS versions will be signed in this way and not allow
unsigned firmware to be loaded except via TFTP.
U-boot bootloader on M-XW devices expects factory image revision
version in specific format. On airOS v6.1.7 with `U-Boot 1.1.4-s1039
(May 24 2017 - 15:58:18)` bootloader checks if the revision major(?)
number is actually a number, but in currently generated images there's
OpenWrt text and so the check fails:
Hit any key to stop autoboot: 0
Setting default IP 192.168.1.20
Starting TFTP server...
Receiving file from 192.168.1.25:38438
Received 4981148 bytes
Firmware check failed! (1)
By placing arbitrary correct number first in major version, we make the
bootloader happy and we can flash factory images over TFTP again:
Received 3801500 bytes
Firmware Version: XW.ar934x.v6.0.4-42.OpenWrt-r9766+2-be42e44
Setting U-Boot environment variables
Un-Protected 1 sectors
Erasing Flash.... done
Patch provided by AREDN[3] project, tested on Bullet M2 XW.
1. https://help.ubnt.com/hc/en-us/articles/204910124-UniFi-TFTP-Recovery-for-Bricked-Access-Points
2. https://dl.ubnt.com/firmwares/XW-fw/v6.0.7/changelog.txt
3. https://github.com/aredn
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Looks identical to the v2.
This PR adds support for a popular low-cost 2.4GHz N based AP
Specifications:
- SoC: Qualcomm Atheros QCA9533 (650MHz)
- RAM: 64MB
- Storage: 8 MB SPI NOR
- Wireless: 2.4GHz N based built into SoC 2x2
- Ethernet: 1x 100/10 Mbps, integrated into SoC, 24V POE IN
Installation:
Flash factory image through stock firmware WEB UI
or through TFTP
To get to TFTP recovery just hold reset button while powering on for
around 4-5 seconds and release.
Rename factory image to recovery.bin
Stock TFTP server IP:192.168.0.100
Stock device TFTP adress:192.168.0.254
Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Signed-off-by: Robert Marko <robimarko@gmail.com>
[Rebased, adjusted for separate tplink-safeloader entry, dynamic partitioning]
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
This is also helpful to add support in ath79.
Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
Tested-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
I've missed leading whitespace issues in the original patch, so fixing
it in this commit. Thanks to pepe2k for letting me know.
Fixes: d260813d ("ar71xx: ens202ext: Fix VLAN switch")
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The target ENS202EXT was just recently added right before the stable
release of Openwrt 18.
It flashes fine, but the physical switch is almost impossible to use
until you have a VLAN set up. Tested on two devices.
The actual problem is that eth0 represents nothing for whatever reason.
In other words, both WAN and LAN are running from eth1. There may be an
underlying problem in the build, but for now, I assume that this is
correct and that a VLAN switch is an appropriate fix.
Also, it's virtually impossible to get the switch running right through
LuCI. It is one thing to get a switch to appear, but attempting to
configure it breaks the whole thing. The VLAN has to be set up
perfectly, otherwise, interfaces will not start up, and one is forced to
reset settings, OR, the new LuCI feature kicks in and reverses any
steps. It is extremely difficult to determine which virtual ports
correspond to which physical ethernet ports without being able to set up
the switch in LuCI.
Temporary Workaround: followed directions here
[openwrt/luci#867](https://github.com/openwrt/luci/issues/867)
Reviewed-by: Marty Plummer <hanetzer@startmail.com>
Signed-off-by: Michael Pratt <mpratt51@gmail.com>
[commit author fix, subject fix, message text wrap]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
The Mikrotik RouterBOARD SXT 2nD r3 is an outdoor WiFi AP / CPE
with a single 2.4 GHz radio and a 100 Mbps Ethernet port.
The device similar to the SXT 2nD r2, but it has SPI NOR flash instead
of NAND flash.
Hardware
--------
CPU: Atheros AR9344 (600 MHz)
RAM: 64 MiB
FLASH: 16 MiB SPI NOR W25Q128
ETH: 1x 100 Mbps Atheros AG71xx
WiFi: 2T2R 802.11b/g/n (ath9k)
Power: Passive PoE 8-30 V
Installation instructions:
1. Boot openwrt-ar71xx-mikrotik-vmlinux-initramfs.elf using a
DHCP+TFTP server.
2. Erase the "firmware" partition using the mtd command. This should
no longer be required once this patch is merged.
3. Use sysupgrade to install to flash. The file
openwrt-ar71xx-mikrotik-rb-nor-flash-16M-squashfs-sysupgrade.bin
should be used.
Signed-off-by: Xavier Douville <github@douville.org>
ath10k_pci driver crashes once loaded and causes boot loops on this
device as 5GHz radio QCA9880-AR1A shipped with this router is broken.
It's not possible to fix this problem in software, miniPCIe radio has to
be replaced.
We could've probably fixed crashing of the ath10k driver by reverting
following upstream commit:
commit 1a7fecb766c83dace747f42b25bbb544b00a0163
Author: Michal Kazior <michal.kazior@tieto.com>
Date: Sat Jan 24 12:14:48 2015 +0200
ath10k: reset chip before reading chip_id in probe
but it's not worth the effort as it wouldn't make that 5GHz radio usable
anyway. So it seems more convenient to just remove the crashing driver
and provide bootable images, as I believe, that a router that is working
but degraded is better than a router that will not work.
For details please see discussions in PR[1] and in FS#1743[2].
1. https://github.com/openwrt/openwrt/pull/1349
2. https://bugs.openwrt.org/index.php?do=details&task_id=1743
Signed-off-by: Aubrey McIntosh, PhD <aubrey.mcintosh@utexas.edu>
[subject and commit message tweaks]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
Michal Cieslakiewicz