The tx/rx delay bits in the ETH_XMII_CONTROL register have to be unset when the
enable_rgmii_rx_delay/enable_rgmii_tx_delay will be set in the AT803x PHY.
Othwise the throughput in gigabit mode is heavily reduced.
Signed-off-by: Sven Eckelmann <sven@open-mesh.org>
SVN-Revision: 45521
The OM5P-AN boards are suffering from ethernet packet loss when booting with
some active POE setups or when switching to Fast Ethernet when previously
booted with Gigabit ethernet attached.
The cause of the problem is that the AR8035 PHYs requires special register
settings to work reliably on these boards. Enable the RGMII TX, RX delays and
disable SmartEE functionality of the AR8035 PHYs. Also enable the RXD and RDV
delay in the ETH_CFG register to fix the issue.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45438
On newer Mikrotik boards, the radio calibration data
is stored differently and uses LZO compression instead
of RLE.
Update the RouterBOOT helper code to support the new
format.
Signed-off-by: Gabor Juhos <juhosg@openwrt.org>
SVN-Revision: 45297
While the switch positions aren't explicitly labeled as on and off, we've heard
complaints about them being wrong. This patch changes the handling to match the
stock firmware.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 44795
My previous patch regarding the Hornet-UB board
(commit: beed4d82d6a0154b0cd5f7b84e2180215ace6718) actually
causes the WPS led state to be inverted. Practically this meant
that value 0 in /sys/class/led/alfa:blue:wps/brightness would
turn the LED on and any positive value (1-255) would turn it off.
The above of course is confusing and hence reverting this value
back to the way it was before beed4d82d6a0154b0cd5f7b84e2180215ace6718.
Signed-off-by: Janne Cederberg <janne.cederberg@gmail.com>
SVN-Revision: 44791
This problem has existed at least since Attitude Adjustment and
is also present in trunk. Basically on the Hornet-UB board the
functionality of RESET and WPS have "switched places".
There are two tickets about the issue at dev.openwrt.org,
The solution suggested on them both is incomplete though
and introduces the following proglem:
Patching as suggested on #14136/#15282 will result in a situation
where simply pressing the RESET button on the bottom will cause
FACTORY RESET to be run. This is due to GPIO high/low state being
incorrect as a result of the above change and virtually the RESET
button is in the pressed-down state the entire time. When it is
then physically pressed, that causes the opposite, release, to be
triggered and since to the board it seemed that the button was
pressed long before it was released, the FACTORY RESET results.
The attached patch works as expected. I have verified both the
incorrect functionality as well as after fixing the issue as
described in the patch and flashing the resulting firmware to a
Hornet-UB board.
Signed-off-by: Janne Cederberg <janne.cederberg@gmail.com>
SVN-Revision: 44692
Previously, the generated images for the My Net Wi-fi Range Extender
wouldn't always work (and panic) due to the fixed mtd offsets and
sizes for the kernel and rootfs. This patch fixes the problem by
utilizing the shared Cybertan's partition parser to recalculate
the mtd partitions for every image dynamically everytime.
Reported-by: Pascal Paradis <peparadis@yahoo.com>
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
SVN-Revision: 44665
This patch renames the partition parser from
wrt160nl to more generic cybertan.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
SVN-Revision: 44663
Please also backport to Barrier Breaker (this same patch applies there too).
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
SVN-Revision: 44647
OpenWrt can be flashed with following uboot commands:
tftpboot 0x80500000 openwrt-ar71xx-generic-wpj558-16M-squashfs-sysupgrade.bin
erase 0x9f030000 +$filesize
cp.b $fileaddr 0x9f030000 $filesize
Signed-off-by: Luka Perkov <luka@openwrt.org>
SVN-Revision: 44620
This patch adds support for MERCURY MAC1200R, a dual band 802.11bgn + 802.11ac
router based on the AR9344, with QCA988x ath10k radio and 5 Fast Ethernet ports
Signed-off-by: Roger Pueyo Centelles <roger.pueyo@guifi.net>
SVN-Revision: 44359
This device is very similar to the TL-WR841N v8, only two LED GPIOs are
different.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 44255
The board is already supported by OpenWrt. WNR1000v2/WNR1000v2-VC are
pretty much the same as WNR2000v3/WNR612v2, therefore the same
initialization code and flash layout is used.
Signed-off-by: Ștefan Rusu <saltwaterc@gmail.com>
Tested-by: Douglas Fraser <1dsfraser@gmail.com>
SVN-Revision: 44221
Fix the WLAN MAC address to match the one printed on the label by using the
correct address from the ART instead of the address of the LAN interface.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 44183
This adds support for the TP-LINK CPE210/220/510/520 (Pharos series). These
devices are very similar to the Ubiquiti NanoStations, but with better specs:
faster CPU, more RAM, 2x2 MIMO.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 43385
This patch changes the code of the Wi-Fi On/Off button on the TP-Link WR1043ND v2
from KEY_WLAN to KEY_RFKILL (and renames a few constants to match). The reason
for this change is, that the KEY_WIFI button code is not recognized by the
hotplug subsystem. This means that the userspace is not notified about the
button being pressed which effectively renders it useless.
Signed-off-by: Josef Gajdusek <atx@atx.name>
SVN-Revision: 42922
This patch fixes LED definitions for the DRAGINO2 board.
1. It renames the Router/USB led to System, as it is now marked "SYS" on the board.
2. It gives control of the LAN and WAN leds and some other GPIOs to Linux.
3. It fixes the active_low property for the LAN and WAN leds.
4. It sets up WLAN, LAN and WAN leds in the UCI defaults.
5. It allows usage of the System led by the diag.sh script, so it will be used to indicate boot and failsafe status.
Signed-off-by: Vittorio Gambaletta <openwrt@vittgam.net>
SVN-Revision: 42897
A typo in the definition for the OM2P reset button disabled its functionality
in OpenWrt. The actual button for these two devices is "1" and not "11".
Signed-off-by: Oren Poleg <oren@poleg.org>
[sven@open-mesh.org: added a commit subject+message]
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 42782
Qihoo 360 C301 is a dual band wireless router supports 802.11n and 802.11ac.
Its chipset is AR9344 + AR9882 with two 16MB flashes.
This patch adds its initial support.
v2:
* use mtd_get_mac_ascii to fetch MAC address for ath10k.
* use ath79_register_pci to initialize AR9882.
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
SVN-Revision: 42552
While the AR9331 has a gigabit MAC towards the internal switch, the
integrated PHYs however are only 100-base-tx capable. The existing code
however advertieses gigabit capability in the link status word. If you
attach such a PHY to a gigabit capable switch on the remote end, with
some probability it attempts to negotiate gigabit and fails, falling
baco to the AR9331 assuming a 10mbit half-duplex link. This has been
observed quite frequently with the Carambola2 and gigabit capable
switches.
In ath79_register_eth(), "pdata->has_gbit = 1;" is set unconditionally
for both AR9331 ethernet ports. This is most likely wrong. Despite the
two MAC IP cores being gigabit MACs, the MAC for eth1 is connected to a
100base-T PHY via MII. The has_gbit attribute is used in the ethernet
driver to determine the supported link modes.
So either pdata->has_gbit is not set to 1 anymore, or the ethernet
driver needs to be modified to determine the advertised link code word
on another criteria than pdata->has_gbit. This patch implements the
former solution.
Signed-off-by: Harald Welte <laforge@gnumonks.org>
SVN-Revision: 42432
This sets the MAC address of the WLAN interface to the "official" primary MAC
address (the one on the label under the devices, and the one used with the stock
firmware). The MAC address used so far (primary-1) isn't even used at all with
the stock firmware, which sets (primary) on LAN and WLAN and (primary+1) on the
WAN interface (like OpenWrt does with this patch).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 42193
The OpenMesh MR600(v1) can only enable the 2.4G WiFi PHY LED through the
mini-PCIe device. Not configuring the LED pin inside the platform data
makes it impossible to configure it through any standard OpenWrt tool.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 42184
