[OpenWrt-Devel] [PATCHv2] ralink: add support for ap699ge8c2
Signed-off-by: Cristian Morales Vega crist...@samknows.com
---
.../linux/ramips/base-files/etc/board.d/02_network | 5 +
target/linux/ramips/base-files/lib/ramips.sh | 3 +
.../ramips/base-files/lib/upgrade/platform.sh | 1 +
target/linux/ramips/dts/AP699GE8C2.dts | 112 +
target/linux/ramips/image/Makefile | 6 +-
target/linux/ramips/mt7621/profiles/ap699ge8c2.mk | 18
6 files changed, 144 insertions(+), 1 deletion(-)
create mode 100644 target/linux/ramips/dts/AP699GE8C2.dts
create mode 100644 target/linux/ramips/mt7621/profiles/ap699ge8c2.mk
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 24e1ba8..ee6aab0 100755
--- a/target/linux/ramips/base-files/etc/board.d/02_network
+++ b/target/linux/ramips/base-files/etc/board.d/02_network
@@ -116,6 +116,7 @@ ramips_setup_interfaces()
;;
3g-6200n | \
+ ap699ge8c2 | \
ai-br100 | \
dir-610-a1 | \
dir-300-b7 | \
@@ -268,6 +269,10 @@ ramips_setup_macs()
local wan_mac=
case $board in
+ ap699ge8c2)
+ wan_mac=$(mtd_get_mac_binary factory 57350)
+ ;;
+
br-6475nd)
lan_mac=$(cat /sys/class/net/eth0/address)
wan_mac=$(mtd_get_mac_binary devdata 7)
diff --git a/target/linux/ramips/base-files/lib/ramips.sh
b/target/linux/ramips/base-files/lib/ramips.sh
index 616f4a1..c1b7898 100755
--- a/target/linux/ramips/base-files/lib/ramips.sh
+++ b/target/linux/ramips/base-files/lib/ramips.sh
@@ -397,6 +397,9 @@ ramips_board_detect() {
*Mediatek MT7628AN evaluation board)
name=mt7628
;;
+ *TWSZ AP699GE8C2)
+ name=ap699ge8c2
+ ;;
*)
name=generic
;;
diff --git a/target/linux/ramips/base-files/lib/upgrade/platform.sh
b/target/linux/ramips/base-files/lib/upgrade/platform.sh
index 17b456b..b79cca8 100755
--- a/target/linux/ramips/base-files/lib/upgrade/platform.sh
+++ b/target/linux/ramips/base-files/lib/upgrade/platform.sh
@@ -25,6 +25,7 @@ platform_check_image() {
all0256n | \
all5002 | \
all5003 | \
+ ap699ge8c2 | \
ar725w | \
asl26555 | \
awapn2403 | \
diff --git a/target/linux/ramips/dts/AP699GE8C2.dts
b/target/linux/ramips/dts/AP699GE8C2.dts
new file mode 100644
index 000..7157962
--- /dev/null
+++ b/target/linux/ramips/dts/AP699GE8C2.dts
@@ -0,0 +1,112 @@
+/dts-v1/;
+
+/include/ mt7621.dtsi
+
+/ {
+ compatible = mediatek,mt7621-eval-board, mediatek,mt7621-soc;
+ model = TWSZ AP699GE8C2;
+
+ memory@0 {
+ device_type = memory;
+ reg = 0x0 0x400;
+ };
+
+ chosen {
+ bootargs = console=ttyS0,57600;
+ };
+
+ palmbus@1E00 {
+ spi@b00 {
+ status = okay;
+
+ m25p80@0 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = mx25l6405d;
+ reg = 0 0;
+ linux,modalias = m25p80;
+ spi-max-frequency = 1000;
+
+ partition@0 {
+ label = u-boot;
+ reg = 0x0 0x3;
+ read-only;
+ };
+
+ partition@3 {
+ label = u-boot-env;
+ reg = 0x3 0x1;
+ read-only;
+ };
+
+ factory: partition@4 {
+ label = factory;
+ reg = 0x4 0x1;
+ read-only;
+ };
+
+ partition@5 {
+ label = firmware;
+ reg = 0x5 0x7b;
+ };
+
+ };
+ };
+ };
+
+ pcie@1e14 {
+ status = okay;
+
+ pcie0 {
+ mt76@0,0 {
+ reg = 0x 0 0 0 0;
+ device_type = pci;
+ mediatek,mtd-eeprom = factory 0x8000;
+ mediatek,2ghz = 0;
+ };
+ };
+
+ pcie1 {
+ mt76@1,0 {
+ reg = 0x 0 0 0 0;
+ device_type = pci;
+
[OpenWrt-Devel] DVB tuners
Hi, I am looking into set-top-box applications and wondered if you guys were aware of any devices with DVB functionality. I'm particularly interested in whether there are any Linux SoC devices with interfaces capable of handling multiple DVB tuners. I would guess this could be handles using USB interfaces, but hoped there might be exampled of better ways to achieve it. Thanks in advance, Charlie ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] External (public) IP forwarded to internal LAN
Hi, I'll try to explain better my concern. I would like to show the source ip when I read the log of my web browser; this is the scenario: user A (IP) ---//- (extern iface)MODEM/ROUTER(internal iface) -- (WWW iface) WWW the IP is 1.2.3.4 the extern iface is 5.6.7.8 the internal iface is 192.168.100.100 the WWW iface is 192.168.100.200 when I look the ip packets on extern iface I can see the packet from 1.2.3.4 and directed to 5.6.7.8, BUT on internal iface every packet comes from 192.168.100.100, not from 1.2.3.4. in the log of the web server the address recorded is 192.168.100.100. the dump on the modem's extern iface 15:07:09.216062 IP 1-2-3-4.foo.com.15716 adsl-5-6-7-8.foo.it.10080 the dump on the modem's internal iface 15:07:03.135591 IP 192.168.100.100.15716 192.168.100.200.www on the www side 192.168.100.100 - - [14/May/2015:15:07:03 +0200] GET / HTTP/1.1 200 2735 - Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 you can find the output of the two commands on pastebin in the next 2 weeks. iptables -L -vn at http://pastebin.com/2b0ewSyu iptables -t nat -L -vn at http://pastebin.com/i7qPXEMJ Hope this helps. Cheers Angelo Hi all, first of all, I'm sorry for my poor english and if I placed my question in a wrong place. I'm facing an issue with,I think, iptables. This is the scenario: I'm using a ddns service to point my external ip to access my server; and it works fine, but the original address is always the internal iface of my modem. This is my actual port-forwarding conf in /etc/config/firewall option src 'wan' option dest 'lan' option proto 'tcp udp' option dest_ip '192.168.x.x' option dest_port 'x' option name 'Photo' option src_dport 'x' option reflection '1' surfing on web and in the wiki of openwrt I cannot find any solution. If I'm not wrong, in the previous release of openwrt the origin's IP was forwarded to the internal lan. Tcpdumping the wan iface I can see both public ip (original and my own ip) Is there any solution (conf, recompile the packet,patch etc) to reflect the previous behaviour ? Cheers Angelo ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] [PATCH] ralink: add support for mt7621 switch counters
Signed-off-by: Cristian Morales Vega crist...@samknows.com
---
.../drivers/net/ethernet/ralink/gsw_mt7620a.c | 8 +-
.../files/drivers/net/ethernet/ralink/mt7530.c | 197 -
.../files/drivers/net/ethernet/ralink/mt7530.h | 3 +-
3 files changed, 199 insertions(+), 9 deletions(-)
diff --git
a/target/linux/ramips/files/drivers/net/ethernet/ralink/gsw_mt7620a.c
b/target/linux/ramips/files/drivers/net/ethernet/ralink/gsw_mt7620a.c
index 8039704..257a9c5 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/gsw_mt7620a.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/gsw_mt7620a.c
@@ -728,10 +728,10 @@ int mt7620_gsw_config(struct fe_priv *priv)
/* is the mt7530 internal or external */
if (priv-mii_bus priv-mii_bus-phy_map[0x1f]) {
- mt7530_probe(priv-device, gsw-base, NULL, 0);
- mt7530_probe(priv-device, NULL, priv-mii_bus, 1);
+ mt7530_probe(priv-device, gsw-base, NULL, 0, 0);
+ mt7530_probe(priv-device, NULL, priv-mii_bus, 1, 0);
} else {
- mt7530_probe(priv-device, gsw-base, NULL, 1);
+ mt7530_probe(priv-device, gsw-base, NULL, 1, 0);
}
return 0;
@@ -740,7 +740,7 @@ int mt7620_gsw_config(struct fe_priv *priv)
int mt7621_gsw_config(struct fe_priv *priv)
{
if (priv-mii_bus priv-mii_bus-phy_map[0x1f])
- mt7530_probe(priv-device, NULL, priv-mii_bus, 1);
+ mt7530_probe(priv-device, NULL, priv-mii_bus, 1, 1);
return 0;
}
diff --git a/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
b/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
index 1352b25..cacf19e 100644
--- a/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
+++ b/target/linux/ramips/files/drivers/net/ethernet/ralink/mt7530.c
@@ -63,6 +63,107 @@ enum {
#define REG_HWTRAP 0x7804
+#define MIB_DESC(_s , _o, _n) \
+ { \
+ .size = (_s), \
+ .offset = (_o), \
+ .name = (_n), \
+ }
+
+struct mt7xxx_mib_desc {
+ unsigned int size;
+ unsigned int offset;
+ const char *name;
+};
+
+#define MT7621_MIB_COUNTER_BASE0x4000
+#define MT7621_MIB_COUNTER_PORT_OFFSET 0x100
+#define MT7621_STATS_TDPC 0x00
+#define MT7621_STATS_TCRC 0x04
+#define MT7621_STATS_TUPC 0x08
+#define MT7621_STATS_TMPC 0x0C
+#define MT7621_STATS_TBPC 0x10
+#define MT7621_STATS_TCEC 0x14
+#define MT7621_STATS_TSCEC 0x18
+#define MT7621_STATS_TMCEC 0x1C
+#define MT7621_STATS_TDEC 0x20
+#define MT7621_STATS_TLCEC 0x24
+#define MT7621_STATS_TXCEC 0x28
+#define MT7621_STATS_TPPC 0x2C
+#define MT7621_STATS_TL64PC0x30
+#define MT7621_STATS_TL65PC0x34
+#define MT7621_STATS_TL128PC 0x38
+#define MT7621_STATS_TL256PC 0x3C
+#define MT7621_STATS_TL512PC 0x40
+#define MT7621_STATS_TL1024PC 0x44
+#define MT7621_STATS_TOC 0x48
+#define MT7621_STATS_RDPC 0x60
+#define MT7621_STATS_RFPC 0x64
+#define MT7621_STATS_RUPC 0x68
+#define MT7621_STATS_RMPC 0x6C
+#define MT7621_STATS_RBPC 0x70
+#define MT7621_STATS_RAEPC 0x74
+#define MT7621_STATS_RCEPC 0x78
+#define MT7621_STATS_RUSPC 0x7C
+#define MT7621_STATS_RFEPC 0x80
+#define MT7621_STATS_ROSPC 0x84
+#define MT7621_STATS_RJEPC 0x88
+#define MT7621_STATS_RPPC 0x8C
+#define MT7621_STATS_RL64PC0x90
+#define MT7621_STATS_RL65PC0x94
+#define MT7621_STATS_RL128PC 0x98
+#define MT7621_STATS_RL256PC 0x9C
+#define MT7621_STATS_RL512PC 0xA0
+#define MT7621_STATS_RL1024PC 0xA4
+#define MT7621_STATS_ROC 0xA8
+#define MT7621_STATS_RDPC_CTRL 0xB0
+#define MT7621_STATS_RDPC_ING 0xB4
+#define MT7621_STATS_RDPC_ARL 0xB8
+
+static const struct mt7xxx_mib_desc mt7621_mibs[] = {
+ MIB_DESC(1, MT7621_STATS_TDPC, TxDrop),
+ MIB_DESC(1, MT7621_STATS_TCRC, TxCRC),
+ MIB_DESC(1, MT7621_STATS_TUPC, TxUni),
+ MIB_DESC(1, MT7621_STATS_TMPC, TxMulti),
+ MIB_DESC(1, MT7621_STATS_TBPC, TxBroad),
+ MIB_DESC(1, MT7621_STATS_TCEC, TxCollision),
+ MIB_DESC(1, MT7621_STATS_TSCEC, TxSingleCol),
+ MIB_DESC(1, MT7621_STATS_TMCEC, TxMultiCol),
+ MIB_DESC(1, MT7621_STATS_TDEC, TxDefer),
+ MIB_DESC(1, MT7621_STATS_TLCEC, TxLateCol),
+ MIB_DESC(1, MT7621_STATS_TXCEC, TxExcCol),
+ MIB_DESC(1, MT7621_STATS_TPPC, TxPause),
+ MIB_DESC(1, MT7621_STATS_TL64PC, Tx64Byte),
+ MIB_DESC(1, MT7621_STATS_TL65PC, Tx65Byte),
+ MIB_DESC(1, MT7621_STATS_TL128PC, Tx128Byte),
+ MIB_DESC(1, MT7621_STATS_TL256PC, Tx256Byte),
+ MIB_DESC(1, MT7621_STATS_TL512PC, Tx512Byte),
+ MIB_DESC(1, MT7621_STATS_TL1024PC, Tx1024Byte),
+ MIB_DESC(2, MT7621_STATS_TOC, TxByte),
+ MIB_DESC(1, MT7621_STATS_RDPC, RxDrop),
+ MIB_DESC(1, MT7621_STATS_RFPC, RxFiltered),
+
Re: [OpenWrt-Devel] WAN dhcp client doesnt recognize unplugged cable and doesnt request new IP on replugged
Thank you for explanation. Why does openwrt use force_link on WAN, when it can break internet connection and remote access? Or what are advantages of force_link? Thanks. -- S pozdravom Jakub Janco 2015-05-14 17:32 GMT+02:00 Hans Dedecker dedec...@gmail.com: On Wed, May 13, 2015 at 12:35 PM, Conor O'Gorman i...@conorogorman.net wrote: On 12/05/15 17:57, Jakub Jančo wrote: Hello, I have tplink 1043nd with BB Problem is that I have dhcp client on WAN and if I unplug cable from WAN, it doesnt change status, give up dhcp address. Even worse is that if I plug cable with another end point with another network, WAN dhcp client doesnt pull new IP, I must click on Connect to refresh dhcp client, then new ip is assigned and internet works. Or restart device. Have a look at ifpugd. But maybe netifd should/could/might do something for this scenario? Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel netifd has support for link state changes; the network interface will be brought up/down if the link is active/inactive. However if the force_link parameter is enabled for a network interface netifd will ignore link state changes. Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WAN dhcp client doesnt recognize unplugged cable and doesnt request new IP on replugged
On Wed, May 13, 2015 at 12:35 PM, Conor O'Gorman i...@conorogorman.net wrote: On 12/05/15 17:57, Jakub Jančo wrote: Hello, I have tplink 1043nd with BB Problem is that I have dhcp client on WAN and if I unplug cable from WAN, it doesnt change status, give up dhcp address. Even worse is that if I plug cable with another end point with another network, WAN dhcp client doesnt pull new IP, I must click on Connect to refresh dhcp client, then new ip is assigned and internet works. Or restart device. Have a look at ifpugd. But maybe netifd should/could/might do something for this scenario? Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel netifd has support for link state changes; the network interface will be brought up/down if the link is active/inactive. However if the force_link parameter is enabled for a network interface netifd will ignore link state changes. Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WAN dhcp client doesnt recognize unplugged cable and doesnt request new IP on replugged
On Thu, May 14, 2015 at 8:23 PM, Jakub Jančo kub...@gmail.com wrote: Thank you for explanation. Why does openwrt use force_link on WAN, when it can break internet connection and remote access? Or what are advantages of force_link? I don't see any added value of using force_link on a WAN interface unless you would use a static IP address. You verified force_link is enabled on the WAN interface for your board ? Hans Thanks. -- S pozdravom Jakub Janco 2015-05-14 17:32 GMT+02:00 Hans Dedecker dedec...@gmail.com: On Wed, May 13, 2015 at 12:35 PM, Conor O'Gorman i...@conorogorman.net wrote: On 12/05/15 17:57, Jakub Jančo wrote: Hello, I have tplink 1043nd with BB Problem is that I have dhcp client on WAN and if I unplug cable from WAN, it doesnt change status, give up dhcp address. Even worse is that if I plug cable with another end point with another network, WAN dhcp client doesnt pull new IP, I must click on Connect to refresh dhcp client, then new ip is assigned and internet works. Or restart device. Have a look at ifpugd. But maybe netifd should/could/might do something for this scenario? Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel netifd has support for link state changes; the network interface will be brought up/down if the link is active/inactive. However if the force_link parameter is enabled for a network interface netifd will ignore link state changes. Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] WAN dhcp client doesnt recognize unplugged cable and doesnt request new IP on replugged
No I havent, I thought it is Bring on boot but it is another option. So my problem persist. config interface 'wan' option ifname 'eth0' option proto 'dhcp' option metric '1' config interface 'wan6' option ifname '@wan' option proto 'dhcpv6' This is my wan config, and after turn off and on lan port on remote site, no logs entries. -- S pozdravom Jakub Janco 2015-05-14 22:29 GMT+02:00 Hans Dedecker dedec...@gmail.com: On Thu, May 14, 2015 at 8:23 PM, Jakub Jančo kub...@gmail.com wrote: Thank you for explanation. Why does openwrt use force_link on WAN, when it can break internet connection and remote access? Or what are advantages of force_link? I don't see any added value of using force_link on a WAN interface unless you would use a static IP address. You verified force_link is enabled on the WAN interface for your board ? Hans Thanks. -- S pozdravom Jakub Janco 2015-05-14 17:32 GMT+02:00 Hans Dedecker dedec...@gmail.com: On Wed, May 13, 2015 at 12:35 PM, Conor O'Gorman i...@conorogorman.net wrote: On 12/05/15 17:57, Jakub Jančo wrote: Hello, I have tplink 1043nd with BB Problem is that I have dhcp client on WAN and if I unplug cable from WAN, it doesnt change status, give up dhcp address. Even worse is that if I plug cable with another end point with another network, WAN dhcp client doesnt pull new IP, I must click on Connect to refresh dhcp client, then new ip is assigned and internet works. Or restart device. Have a look at ifpugd. But maybe netifd should/could/might do something for this scenario? Conor ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel netifd has support for link state changes; the network interface will be brought up/down if the link is active/inactive. However if the force_link parameter is enabled for a network interface netifd will ignore link state changes. Hans ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] DVB tuners
On 14.05.2015 16:22, Charlie Smurthwaite wrote: Hi, I am looking into set-top-box applications and wondered if you guys were aware of any devices with DVB functionality. I'm particularly interested in whether there are any Linux SoC devices with interfaces capable of handling multiple DVB tuners. I would guess this could be handles using USB interfaces, but hoped there might be exampled of better ways to achieve it. Thanks in advance, Charlie ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel There are a ton of DVB capable SoC devices - ARM, MIPS or x86 that could potentially run OpenWrt or that might be capable of running vanilla/upstream Kernel so porting to *almost* upstream OpenWrt is less painful. (if you want tu run OpenWrt - you might run normal Linux or you have to stick with ancient vendor Linux) Afaik black box DVB-IPTV boxes are also available targetting private (Inverto SatIP LNB, Cable IP from AVM) users (up to normal broadcast use-case/multi-residential use-case). just to keep in mind as alternative However dealing or developing in that area can get really painful because many hardware vendors willingly break their products to disable normal consumer features. (Hollywood Studio guidelines or consumer features) This is from some research + experiments running Linux DVB receivers. classic Linux DVB SoC solutions from - MIPS platform: VU+ (VU Plus), Dreambox Hardware having up to 4x integrated tuners - ARM platform: Coolstream up to 4 integrated tuners - SH4 platform (dont know) have at least some Open Source projects developers attached (Neutrino, Enigma, tuxbox projects) but sometimes horribly old vendor Kernels. DVB Set-Top boxes became outdated for some ppl in place of integrated TV (silently removing features due to DRM) OR new streaming / Set-Top Box + USB solutions like: - (SigmaDesign) Popcornhour boxes (some SDK were available because there were some community packages but I remember this as very closed from vendor barely providing any useful info on public sites) Maker hardware like: - (broadcom) Raspberry PI with kodi,OpenElec or OpenEmbedded/Yocto - (Amlogic) S805 (Odroid-C1) S812 (several chinese vendors) (4x USB 2.0) Experimenting/Flashing might be easier and faster because SD-Card boots. Some modern distros like Archlinux for aarch64 can run on these too. Main potential problems are: - poor Network/IO performance (USB attached Ethernet, 10/100Mbit only) of classic DVB SoC - reason for poor IO is hardware acceleration default bit rate limits (CDROM,DVD speed, BluRay bitrate) or common broadcast practise (3Mbit/s SD, 10Mbit/s HD for example) - slow general purpose CPU (Hardware codecs on most devices) (classic DVB) - USB attached tuners have issues like potential dropouts and electrical bus / ESD problems - design compromise: RF frequency chip design affects sound I/O (different but similar problem is the 2.4GHz and USB3 interference) Notice that DigitialDevices offers miniPCIe DVB with multiple tuners and there were IEEE1394 DVB tuners (FireDTV) that were chainable on market. APU 1D4 or next gen Soekris 68xx Atom SoC might be interesting. PS: Most facts are from public info / reviews / Prosumer perspective only Since testing gets really expensive when looking at multi tuner/DVB solutions or embedded boards that might be capable or good solutions for embedded / small HTPC. http://www.cnx-software.com/ seems to list/post about every obscure embedded china hardware and often does multimedia hardware too. ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
[OpenWrt-Devel] Firefly FireWrt - interesting AC1200 beast
Hi, has anyone got their hands on Firefly FireWrt [1] with Mediatek MT7621A dual core MIPS 1004Kc processor? Specs look really interesting, but my concern is wifi driver maturity and general reliability. Any comments on reliability of Mediatek platform? I haven't had experience with and device using Mediatek SoC so any insights are appreciated. Also there is currently a Beta program open so you can get demo board for 69$ [2], I'm sure they will gladly send these boards to OpenWrt devs. [1] http://www.cnx-software.com/2015/05/14/firewrt-is-an-openwrt-802-11ac-board-powered-by-mediatek-mt7621a-processor/ [2] http://bbs.t-firefly.com/forum.php?mod=viewthreadtid=543 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
