Antminers using the stock bootloader will not hash without this GPIO set.
Applies to DD and CC
Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
SVN-Revision: 47261
This patch fixes ticket #15267 by enabling power on the
WNR2200's USB port. At present, the USB port on the WNR2200
is non-functional due to it not receiving power.
This patch defines an additional GPIO pin, but none of the
current GPIO definitions have been modified.
Signed-off-by: Riley Baird <BM-2cVqnDuYbAU5do2DfJTrN7ZbAJ246S4XiX@bitmessage.ch>
SVN-Revision: 47236
This patch supersedes the v1 from September 17th.
Bumping the patch version - the MiniBox profile showed up under M, but
since it's called 'Gainstrong MiniBox v1.0' now it looks out of place.
Renamed the profile to gs-minibox-v1.mk to fix that.
The following patch adds support for the Gainstrong MiniBox into trunk
(or 'Designated Driver' :D ).
Fixed items:
- Inverted LED polarity (OOLITE seems to suffer from the same problem).
- Changed uppercase MINIBOX_V1_ prefix as requested.
- Prefixes are now gs_minibox_ similar to gs_oolite_ (same vendor).
- Mention the vendor (Gainstrong) in code headers.
Compiles fine, has been confirmed working by owners on 15.05.
Question: I've seen some boards use tools/firmware-utils/src/mktplinkfw.c,
the MiniBox images build fine without, so I'm wondering: do I need to add
it in there as well? Any added benefit?
Thank you
Signed-off by: Stijn Segers <francesco.borromini@inventati.org>
SVN-Revision: 47234
Sets the LEDs to boardname:color:led-name
Sets the LAN to eth0
Other corrections such as the Machine Name and HWIDs
v2 corrects the profile names in the Makefile and changes tabs to spaces
in the Makefile 'define Device/' like the other devices.
Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
SVN-Revision: 47221
Add support for WeIO board (http://we-io.net).
This board is based on Carambola2 board form 8Devices.
Signed-off-by: Drasko DRASKOVIC <drasko.draskovic@gmail.com>
Signed-off-by: Felix Fietkau <nbd@openwrt.org> [some cleanups]
SVN-Revision: 47036
QCA9563 and QCA9561 are two series of Qualcomm SoC Dragonfly. The only different
is QCA9563 w/o internal switch. It has one GMAC with SGMII interface. But they
have the same device ID(0x1150). So they share the same codes.
Signed-off-by: Miaoqing Pan <miaoqing@codeaurora.org>
SVN-Revision: 46971
This patch adds support for TP-LINK TL-WDR3320 v2.
This router uses a chinese version 2 firmware header,.
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
SVN-Revision: 46934
This adds full support (sans sysupgrading from vendor firmware) for the COMFAST
CF-E316N v2 (aka CF-E316V2, CF-E316N-V2 and CF-E316Nv2.0, no FCC ID) by
Shenzhen Four Seas Global Link Network Technology Co., Ltd (this company is
actively refusing to provide GPL'd sources for the OpenWrt version they ship
with the device, damn them).
Signed-off-by: Paul Fertser <fercerpav@gmail.com>
SVN-Revision: 46852
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
This patch adds support for TP-Link TL-WDR6500 v2.
The firmware has a U-Boot header for kernel, and a TP-LINK v2 header for
the whole firmware, so I have to create a new firmware creation method.
SVN-Revision: 46663
Signed-off-by: Weijie Gao <hackpascal@gmail.com>
This patch adds flash layout parser for TP-Link firmwares which have a 64kb
bootloader.
This is used for TP-Link TL-WDR6500 v2.
SVN-Revision: 46662
This patch adds support for the Onion Omega.
https://onion.io/omega
Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
Acked-by: Boken Lin <bl@onion.io>
Tested-by: Jacky Huang <huangfangcheng@163.com>
SVN-Revision: 46458
In fb6f62e97733312053ab593fcf68eea47a21169e several settings
are set on the ethernet device, but they are not working.
Fix Ethernet by setting the right values.
Signed-off-by: Christian Mehlis <christian@m3hlis.de>
SVN-Revision: 46281
no-op since 2.6.35
removed in Kernel 4.1
see https://lwn.net/Articles/380931/
Signed-off-by: Dirk Neukirchen <dirkneukirchen@web.de>
SVN-Revision: 46280
This patch adds support for the Cisco WAP4410N, an access point that uses the
AR9132 SoC. Web upgrades from stock are not yet possible, UART access required
for the initial flash.
Signed-off-by: Ryan A Young <rayoung@utexas.edu>
SVN-Revision: 46250
This patch adds support for the Bitmain Antminer S3 Cryptocurrency Miner
http://wiki.openwrt.org/toh/bitmain/s3
Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
SVN-Revision: 46236
The initialization routines for these boards were relying on some (wrong)
defaults for the QCA953x ethernet. Make these defaults explicit to prevent
breaking them when the QCA953x defaults are fixed.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
SVN-Revision: 46206
The hardware should be almost the same as TL-WR720N-v3. WiFi and LAN networks
were tested by "Lo Yuk Fai <loyukfai@gmail.com>". Failsafe and slider switch
were tested by "Wong min <alpha080@gmail.com>".
Signed-off-by: Yousong Zhou <yszhou4tech@gmail.com>
SVN-Revision: 46046
This patch adds support for the Bitmain Antminer S1 Cryptocurrency Miner
http://wiki.openwrt.org/toh/bitmain/s1
Signed-off-by: L. D. Pinney <ldpinney@gmail.com>
Acked-by: James Hilliard <james.hilliard1@gmail.com>
SVN-Revision: 46044
Some devices ship with NAND images that use BCH ECC. Let the driver know
about that ECC mode so that it can be selected by machine files.
Signed-off-by: Thomas Hebb <tommyhebb@gmail.com>
SVN-Revision: 46022
AR8337 supports a configuration bit to swap MAC0 and MAC6.
Currently this is set in general if an AR8337 is detected and causes
issues with devices using an AR8334 (internally an AR8337, just
less chip pins).
And it might even cause issues with AR8337-based devices with
different board designs.
Swapping the MAC's however isn't needed for AR8337 in general.
It's just needed in case of certain board designs (affected devices
seem to be based on Atheros reference board AP135/136-010).
Therefore this configuration bit should be moved to platform data.
The patch includes the needed changes to the device initialization
code of affected devices. Hopefully I didn't miss any ..
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
SVN-Revision: 45970
The mynet range extender hardware is suffering from ethernet
link loss when booting with a recent openwrt image. This only
happens on 100mbps links, with 1Gbps speed the link was fine.
The cause of the problem is that the AR8035 PHY (aka F1E)
requires turning on and off the special TX delay setting
depending on the speed of the link.
The 10mbps mode only needed the proper pll value, which was
extracted from the vendor code.
Reported-by: Pascal Paradis
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
SVN-Revision: 45954
This patch is to add support for the Meraki MR12 and MR16 Access Points.
Currently everything is working, minus the 2nd NIC interface on the MR12
which is built into the SoC.
Signed-off-by: Chris R Blake <chrisrblake93 at gmail.com>
SVN-Revision: 45726
Users will now be provided with the inherent wifi toggle functionality
of /etc/rc.button/rfkill
Signed-off-by: Michael J. Bazzinotti <mbazzinotti@gmail.com>
SVN-Revision: 45635
Originally pressing a button would trigger a release state and vice-versa,
as observed from hotplug.d.
Signed-off-by: Michael J. Bazzinotti <mbazzinotti@gmail.com>
SVN-Revision: 45634
Most people report broken ethernet with upstream. Last year, user "franz.flasch"
authored a working mach-file. His patch is outdated so I modernized it. Original
patch and user commentary on page 1:
https://forum.openwrt.org/viewtopic.php?pid=260861#p260861
I have figured out what the critical differences are between the two that caused
upstream ethernet to break.
1) Both ath79_init_mac() functions calls must be invocated before any GMAC init
2) must init GMAC0 before GMAC1
That was enough to get upstream to function, but I wanted to enjoy my confidence
having tested franz's patch for a week sucessfully, so I put his whole
function in, which only features more differences in order of function calls.
An expert should consider these changes, which could pose potential bugs/issues:
1) No longer using the flag AR934X_ETH_CFG_SW_PHY_SWAP in the
ath79_setup_ar934x_eth_cfg() call.
2) Possible consequence of no longer explicitly setting ethernet duplex/speed.
Review: With this patch, my ethernet and wireless works.
Signed-off-by: Michael J. Bazzinotti <mbazzinotti@gmail.com>
SVN-Revision: 45633
It is common that the router provider be used rather than product name.
One can see this in target/linux/ar71xx/base-files/etc/uci-defaults/01_leds
Signed-off-by: Michael J. Bazzinotti <mbazzinotti@gmail.com>
SVN-Revision: 45630
It was reported that OM5P-AN needs not only a delay setting of 1 for RXD/RDV
but 2. These was found when testing with a NetGear GS752TP POE switch with a
cable length of 50ft and 250ft.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45524
The ETH_RXDV_DELAY (17:16) and ETH_RXD_DELAY (15:14) are currently not cleared
by the function ath79_setup_ar934x_eth_cfg. Clearing these in the
ath79_setup_ar934x_eth_cfg may cause problems on some hardware because they
rely on the preset value by the bootloader.
Instead another function is introduced which also works on ETH_CFG on AR934x.
It can be used to safely clear and set ETH_RXDV_DELAY and ETH_RXD_DELAY on
machines which require special settings.
Signed-off-by: Sven Eckelmann <sven@open-mesh.com>
SVN-Revision: 45523
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
By removing the NL16 signature check, the parser can be
utilized by other devices like the WD My Net Wi-fi Range
Extender.
Signed-off-by: Christian Lamparter <chunkeey@googlemail.com>
SVN-Revision: 44664
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
I don't see that we're in an atomic context so there's no need to
busy-wait. Therefore replace the delay with sleep calls.
See also Documentation/timers/timers-howto.txt. It states:
"In general, use of mdelay is discouraged and code should
be refactored to allow for the use of msleep."
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
SVN-Revision: 43539
Replace the fixed wait time of 1s with polling for BMCR_RESET
to be cleared on all PHYs.
Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
SVN-Revision: 43538
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
