from:"Mikko Hissa"

Re: [OpenWrt-Devel] [PATCH] Fix 'Dropping frame due to full tx queue' for Ralink wifi get stuck.

2015-09-11 Thread Mikko Hissa


> On 11 Sep 2015, at 15:43, N.Leiten  wrote:
> 
> In email dated Пятница - 11 сентября 2015 13:49:26 user Felix Fietkau wrote:
>> On 2015-09-11 13:33, N.Leiten wrote:
>>> Fix instability of Ralink WiFi general queue management on high load.
>>> rt2x00 driver logs in dmesg "Dropping frame due to full queue ..." several 
>>> times and at some point get stuck.
>>> 
>>> Solutions in patch:
>>> 1) Increasing number of frames in each TX queue helps with speed and
>>> decreases queue overflows. Actually 256 frames can be increased to
>>> 512 (this number of frames used in proprietary drivers for every
>>> queue).
>> 512 frames seems to be overly excessive. Ever heard of bufferbloat?
>> It seems to me that the driver should simply call ieee80211_stop_queue
>> earlier to ensure that mac80211 does not attempt to fill the queues as
>> much. The driver queue length should probably be around 64 or less.
>> 
> 
> I agree. The patch was made for internal use on own hardware reference design 
> in our company, so I had to look through proprietary and opensource drivers 
> to see the difference. The point was to use recent versions of OpenWRT with 
> mac80211 stack because proprietary still uses linux-2.6. And it makes porting 
> full of pain in nails and bloody eyes reading that piece of code. For now 
> mac80211 is preferrable.
> As to bufferbloat - yes I'm aware of it. Maybe I'm wrong in observations, but 
> simply increasing queue num to 128 frames make driver more stable but not 
> enough, so I started digging in ralink drivers for maximum value, tried it 
> and it increased stability even more, but still hang at some point. So I 
> decreased it to 256. Well, I'll try to remove this part and test again.

I think I solved the stuck tx-queue issue a few years ago by increasing the 
size of the txstatus fifo. Now looking at the code, I suggest you to try the 
following. 

in rt2800mmio.c:
static void rt2800mmio_txstatus_interrupt(struct rt2x00_dev *rt2x00dev…
I don’t know to what end was this added here but anyways remove 
the read limit, since it’s obvious that there might be more than just one 
tx-queue being used. Exiting the interrupt handler here with half full hw fifo 
(16 entries) will lead to lost txstatuses for sure:
if (++i >= rt2x00dev->tx->limit)
break;

in rt2x00dev.c
static int rt2x00lib_probe_hw(struct rt2x00_dev *rt2x00dev)…
I used a static value here, but it seems that the hw might 
generate excess txstatuses (who knows why). So bigger is better!
-int kfifo_size = roundup_pow_of_two(rt2x00dev->ops->tx_queues 
* rt2x00dev->tx->limit * sizeof(u32));
+int kfifo_size = roundup_pow_of_two(2048 * sizeof(u32));

With these you should no longer be experiencing stuck tx-queues!

> 
>>> 2) Setting number of frames in TX/RX queues to equal values
>>> resolves async speed behaviour with better RX on AP-side (uplink from
>>> STAs), where it needs to be at least equal or better on TX queue on
>>> AP (download to STA).
>> That also doesn't make much sense to me as queueing behavior is
>> completely different between rx and tx. Rx queue processing speed is
>> determined by CPU speed, Tx queue processing speed is determined by
>> shared medium speed.
>> 
> 
> I agree, that was another step in digging. As I can understand it's better 
> even use NAPI for RX queue. But I found only one mention of it in mac80211 
> sources, need to explore this.

The driver already uses tasklets and rx-interrupts stay disabled until the 
driver "catches up” with the rx-queue. So, there’s little to none performance 
gain here with napi. Although, I did see a noticeable performance increase by 
enabling delayed rx-interrupts from the hw. As if the hw is sending a BA every 
time when RX_CRX_IDX register is written? 

> I'll remove it, test again and make new patch. Can you direct me with this 
> kind of behaviour? On rt3092 (2T2R) we can get 30-40Mbit/s download and 
> 80-120Mbit/s upload speeds in separate tests, on 1T1R and 2T2R stations.
> 
>>> 3) In rt2x00mac.c additional check for queue
>>> full added and reassignment in this case, so interface will not drop
>>> frame.
>> Why? If the queues are full, it's better to just drop packets instead of
>> making the problem worse.
>> 
> 
> It was the simpliest solution at this point. I'll try to use 
> ieee80211_stop_queue instead, but don't know how much time it'll consume.
> Maybe there's problem in "kick/pause" queue mechanism? I managed to explore 
> behaviour after hang-point. It seems that only QID_AC_* queues stuck, station 
> assoc/auth goes fine but actual data not transmitted on AP-side, but it 
> receives DHCP-requests from station and it looks like no network access on 
> hanged AP.

When the queue is stuck, you can see that the queue is filled to it’s threshold 
and it’s paused. So, the kick&pause works as it should.

> 
>>> 4) Fixes in queue initialization. Default

Re: [OpenWrt-Devel] [PATCH] Fix 'Dropping frame due to full tx queue' for Ralink wifi get stuck.

2015-09-11 Thread Mikko Hissa


> On 11 Sep 2015, at 21:32, N.Leiten  wrote:
> 
> Hi.
> 
> In email dated Пятница - 11 сентября 2015 17:16:35 user Mikko Hissa wrote:
>> 
>>> On 11 Sep 2015, at 15:43, N.Leiten  wrote:
>>> 
>>> In email dated Пятница - 11 сентября 2015 13:49:26 user Felix Fietkau wrote:
>>>> On 2015-09-11 13:33, N.Leiten wrote:
>>>>> Fix instability of Ralink WiFi general queue management on high load.
>>>>> rt2x00 driver logs in dmesg "Dropping frame due to full queue ..." 
>>>>> several times and at some point get stuck.
>>>>> 
>>>>> Solutions in patch:
>>>>> 1) Increasing number of frames in each TX queue helps with speed and
>>>>> decreases queue overflows. Actually 256 frames can be increased to
>>>>> 512 (this number of frames used in proprietary drivers for every
>>>>> queue).
>>>> 512 frames seems to be overly excessive. Ever heard of bufferbloat?
>>>> It seems to me that the driver should simply call ieee80211_stop_queue
>>>> earlier to ensure that mac80211 does not attempt to fill the queues as
>>>> much. The driver queue length should probably be around 64 or less.
>>>> 
>>> 
>>> I agree. The patch was made for internal use on own hardware reference 
>>> design in our company, so I had to look through proprietary and opensource 
>>> drivers to see the difference. The point was to use recent versions of 
>>> OpenWRT with mac80211 stack because proprietary still uses linux-2.6. And 
>>> it makes porting full of pain in nails and bloody eyes reading that piece 
>>> of code. For now mac80211 is preferrable.
>>> As to bufferbloat - yes I'm aware of it. Maybe I'm wrong in observations, 
>>> but simply increasing queue num to 128 frames make driver more stable but 
>>> not enough, so I started digging in ralink drivers for maximum value, tried 
>>> it and it increased stability even more, but still hang at some point. So I 
>>> decreased it to 256. Well, I'll try to remove this part and test again.
>> 
>> I think I solved the stuck tx-queue issue a few years ago by increasing the 
>> size of the txstatus fifo. Now looking at the code, I suggest you to try the 
>> following. 
>> 
>> in rt2800mmio.c:
>>  static void rt2800mmio_txstatus_interrupt(struct rt2x00_dev *rt2x00dev…
>>  I don’t know to what end was this added here but anyways remove 
>> the read limit, since it’s obvious that there might be more than just one 
>> tx-queue being used. Exiting the interrupt handler here with half full hw 
>> fifo (16 entries) will lead to lost txstatuses for sure:
>>  if (++i >= rt2x00dev->tx->limit)
>>break;
>> 
> Ok, I'll try that.
> 
>> in rt2x00dev.c
>>  static int rt2x00lib_probe_hw(struct rt2x00_dev *rt2x00dev)…
>>  I used a static value here, but it seems that the hw might 
>> generate excess txstatuses (who knows why). So bigger is better!
>>  -int kfifo_size = roundup_pow_of_two(rt2x00dev->ops->tx_queues 
>> * rt2x00dev->tx->limit * sizeof(u32));
>>  +int kfifo_size = roundup_pow_of_two(2048 * sizeof(u32));
>> 
>> With these you should no longer be experiencing stuck tx-queues!
>> 
> 
> Actually,
>   int kfifo_size = roundup_pow_of_two(2048 * sizeof(u32));
> is the same way I go, but I increase rt2x00dev->tx->limit to 512 at first 
> place and after tests decreased it to 256. So in math we got the same value  
> there (4 queues * 512 frames = 2048).

Exactly, 2048 is not enough if you are using that kind of queue size. That 2048 
fifo size was meant for the default queue sizes.

> 
>>> 
>>>>> 2) Setting number of frames in TX/RX queues to equal values
>>>>> resolves async speed behaviour with better RX on AP-side (uplink from
>>>>> STAs), where it needs to be at least equal or better on TX queue on
>>>>> AP (download to STA).
>>>> That also doesn't make much sense to me as queueing behavior is
>>>> completely different between rx and tx. Rx queue processing speed is
>>>> determined by CPU speed, Tx queue processing speed is determined by
>>>> shared medium speed.
>>>> 
>>> 
>>> I agree, that was another step in digging. As I can understand it's better 
>>> even use NAPI for RX queue. But I found only one mention of it in mac80211 
>>> sources, need to explore this.
>>

[OpenWrt-Devel] hostapd disconnects with Apple devices.

2015-01-12 Thread Mikko Hissa

Hi everyone,

If I recall correctly, since June/July 2014, Apple devices get constantly 
disconnected from AP.
A simple fix is to disable hostapd's disassoc_low_ack. I saw this behaviour on 
iPads, iPhones, MacBooks, iMacs etc.
Should the default setting be altered?

Best regards,
Mikko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] What should I do if I want to use the RGMII interface on Ralink RT3052?

2015-02-18 Thread Mikko Hissa

Hi!

> On 19 Feb 2015, at 04:14, 郭传鈜  wrote:
> 
> Hello,everyone!
> There is a kind of Huawei HG255D which has an RTL8211CL Gigabit PHY and We 
> are trying to add support for it.
> But I can't find anything about the RGMII and mdio-bus in any dts file of 
> rt305x-based devices:-(
> The only device I found which used the interface is WL-351 with an RTL8366 
> switch  but it doesn't use the MDIO interface to control it. I tried to copy 
> the fpa2 and fct2 value from WL-351.dts but ,of course, it doesn't work.
> Then I tried to do the following:
> https://github.com/981213/openwrt/commit/47fa84df4dcc9b8bfe49ed2211d463ed014e2df2
>  
> 

Yes, there's that and then you need to configure registers for gdma2 in the 
ethernet driver... Register a second netdev and map packets, to the 
corresponding netdev/gdma (in/out) interface, by dma descriptors.

OR

In the dst file under the esw, change the value of portmap to 3f.
XD


> but it doesn't work too.
> Could someone please tell me what should I do in the dts file and how can I 
> reset the PHY?
> 
> 
> Sorry for my bad English:-)
> 
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] What should I do if I want to use the RGMII interface on Ralink RT3052?

2015-02-19 Thread Mikko Hissa


> On 19 Feb 2015, at 09:45, 郭传鈜  wrote:
> 
> Portmap?This value is only for the default VLAN config of the switch right? 
> But the problem I'm facing is that the link status of port 5 is always "link 
> down" even if I plugged in the network cable:-(

Actually no, the switch has like two logical switches and it doesn't forward 
packets between those two (LAN/WAN).
Does swconfig show the port as disabled?

> 
> 2015-02-19 15:24 GMT+08:00 Mikko Hissa  <mailto:mikko.hi...@werzek.com>>:
> Hi!
> 
>> On 19 Feb 2015, at 04:14, 郭传鈜 > <mailto:gch981...@gmail.com>> wrote:
>> 
>> Hello,everyone!
>> There is a kind of Huawei HG255D which has an RTL8211CL Gigabit PHY and We 
>> are trying to add support for it.
>> But I can't find anything about the RGMII and mdio-bus in any dts file of 
>> rt305x-based devices:-(
>> The only device I found which used the interface is WL-351 with an RTL8366 
>> switch  but it doesn't use the MDIO interface to control it. I tried to copy 
>> the fpa2 and fct2 value from WL-351.dts but ,of course, it doesn't work.
>> Then I tried to do the following:
>> https://github.com/981213/openwrt/commit/47fa84df4dcc9b8bfe49ed2211d463ed014e2df2
>>  
>> <https://github.com/981213/openwrt/commit/47fa84df4dcc9b8bfe49ed2211d463ed014e2df2>
> 
> Yes, there's that and then you need to configure registers for gdma2 in the 
> ethernet driver... Register a second netdev and map packets, to the 
> corresponding netdev/gdma (in/out) interface, by dma descriptors.
> 
> OR
> 
> In the dst file under the esw, change the value of portmap to 3f.
> XD
> 
> 
>> but it doesn't work too.
>> Could someone please tell me what should I do in the dts file and how can I 
>> reset the PHY?
>> 
>> 
>> Sorry for my bad English:-)
>> 
>> ___
>> openwrt-devel mailing list
>> openwrt-devel@lists.openwrt.org <mailto:openwrt-devel@lists.openwrt.org>
>> https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel 
>> <https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel>
> 
> 



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

[OpenWrt-Devel] [PATCH] ramips: add support for D-Link DIR-615 H1

2012-08-09 Thread Mikko Hissa

rt2x00 still needs some patching as the radio doesn't come to life.
Installation via webflash.

Signed-off-by: Mikko Hissa 

Index: trunk/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-615-h1.c
===
--- trunk/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-615-h1.c   
(revision 0)
+++ trunk/target/linux/ramips/files/arch/mips/ralink/rt305x/mach-dir-615-h1.c   
(revision 0)
@@ -0,0 +1,113 @@
+/*
+ *  D-Link DIR-615 H1
+ *
+ *  Copyright (C) 2012 Mikko Hissa 
+ *
+ *  This program is free software; you can redistribute it and/or modify it
+ *  under the terms of the GNU General Public License version 2 as published
+ *  by the Free Software Foundation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "devices.h"
+
+#define DIR_615_H1_GPIO_LED_WAN_AMBER 12   /* active low */
+#define DIR_615_H1_GPIO_LED_WAN_GREEN 13   /* active low */
+#define DIR_615_H1_GPIO_LED_WPS_BLUE 14/* active low */
+
+#define DIR_615_H1_GPIO_LED_STATUS_AMBER 7
+#define DIR_615_H1_GPIO_LED_STATUS_GREEN 9
+
+#define DIR_615_H1_GPIO_BUTTON_RESET 10/* active low */
+#define DIR_615_H1_GPIO_BUTTON_WPS 0   /* active low */
+
+#define DIR_615_H1_KEYS_POLL_INTERVAL 20
+#define DIR_615_H1_KEYS_DEBOUNCE_INTERVAL (3 * DIR_615_H1_KEYS_POLL_INTERVAL)
+
+static struct gpio_led dir_615_h1_leds_gpio[] __initdata = {
+   {
+   .name   = "d-link:amber:status",
+   .gpio   = DIR_615_H1_GPIO_LED_STATUS_AMBER,
+   }, {
+   .name   = "d-link:green:status",
+   .gpio   = DIR_615_H1_GPIO_LED_STATUS_GREEN,
+   }, {
+   .name   = "d-link:amber:wan",
+   .gpio   = DIR_615_H1_GPIO_LED_WAN_AMBER,
+   .active_low = 1,
+   }, {
+   .name   = "d-link:green:wan",
+   .gpio   = DIR_615_H1_GPIO_LED_WAN_GREEN,
+   .active_low = 1,
+   }, {
+   .name   = "d-link:blue:wps",
+   .gpio   = DIR_615_H1_GPIO_LED_WPS_BLUE,
+   .active_low = 1,
+   }
+};
+
+static struct gpio_keys_button dir_615_h1_gpio_buttons[] __initdata = {
+   {
+   .desc   = "reset",
+   .type   = EV_KEY,
+   .code   = KEY_RESTART,
+   .debounce_interval = DIR_615_H1_KEYS_DEBOUNCE_INTERVAL,
+   .gpio   = DIR_615_H1_GPIO_BUTTON_RESET,
+   .active_low = 1,
+   }, {
+   .desc   = "wps",
+   .type   = EV_KEY,
+   .code   = KEY_WPS_BUTTON,
+   .debounce_interval = DIR_615_H1_KEYS_DEBOUNCE_INTERVAL,
+   .gpio   = DIR_615_H1_GPIO_BUTTON_WPS,
+   .active_low = 1,
+   }
+};
+
+const struct flash_platform_data dir615h1_flash = {
+   .type   = "mx25l3205d",
+};
+
+struct spi_board_info dir615h1_spi_slave_info[] __initdata = {
+   {
+   .modalias   = "m25p80",
+   .platform_data  = &dir615h1_flash,
+   .irq= -1,
+   .max_speed_hz   = 1000,
+   .bus_num= 0,
+   .chip_select= 0,
+   },
+};
+
+static void __init dir615h1_init(void)
+{
+   rt305x_gpio_init(RT305X_GPIO_MODE_GPIO << RT305X_GPIO_MODE_UART0_SHIFT);
+   rt305x_register_spi(dir615h1_spi_slave_info,
+   ARRAY_SIZE(dir615h1_spi_slave_info));
+   rt305x_esw_data.vlan_config = RT305X_ESW_VLAN_CONFIG_W;
+   rt305x_register_ethernet();
+   ramips_register_gpio_leds(-1, ARRAY_SIZE(dir_615_h1_leds_gpio), 
+ dir_615_h1_leds_gpio);
+   ramips_register_gpio_buttons(-1, DIR_615_H1_KEYS_POLL_INTERVAL, 
+ARRAY_SIZE(dir_615_h1_gpio_buttons), 
+dir_615_h1_gpio_buttons);
+   rt305x_register_wifi();
+   rt305x_register_wdt();
+   rt305x_register_usb();
+}
+
+MIPS_MACHINE(RAMIPS_MACH_DIR_615_H1, "DIR-615-H1", "D-Link DIR-615 H1",
+dir615h1_init);
Index: trunk/target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
===
--- trunk/target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
(revision 33076)
+++ trunk/target/linux/ramips/files/arch/mips/ralink/rt305x/Makefile
(working copy)
@@ -17,6 +17,7 @@
 obj-$(CONFIG_RT305X

Re: [OpenWrt-Devel] [PATCH] ramips: add support for D-Link DIR-615 H1

2012-08-10 Thread Mikko Hissa


lukasz  kirjoitti 10.8.2012 kello 11.42:

> W dniu 10.08.2012 01:36, Mikko Hissa pisze:
>> rt2x00 still needs some patching as the radio doesn't come to life.
>> Installation via webflash.
>> 
> Hi
> Can you post factory partition, somwhere to download ?

Here you go:
http://wikisend.com/download/330884/factory.bin
> ___
> 
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] Problem with Ralink rt3352 wireless driver

2012-08-15 Thread Mikko Hissa


Peter.K  kirjoitti 15.8.2012 kello 9.30:

> I using openwrt-trunk lastest version in Ralink rt3352 EVB.
> Wireless driver seems doesn't work.
> 
> Does anyone know rt3352 wireless worked or not in current trunk?
> 

On D-Link DIR-615 H1, the driver loads without any errors. Yet no packets are 
received nor sent via radio.

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

2014-02-11 Thread Mikko Hissa

Hello!

On 01 Feb 2014, at 02:08, Roman Yeryomin  wrote:

> Hello everybody!
> I'm trying to get mt7620 (ramips target, rt-n14u board) wifi working
> but no luck. I have ported init functions and channel setup from the
> original (known to be working) driver. The original driver (and
> datasheet) is available in the web.
> Unfortunately I have no experience in wifi drivers and this is my
> first one. Even worse I don't know what those register (rfcsr and bbp)
> writes _should_ do because they are not in datasheet (I suppose the
> earlier chips rf registers are not documented also).
> Attaching the patches hoping somebody with more experience could help
> or at least give an advise. The patches are not very clean and
> probably some things can be done in a different way but that's not the
> point right now.
> 

I took a quick look at your patches and one thing caught my eye...
In rt2800.h you have:
+#define RF_CSR_CFG_REGNUM_MT7620   FIELD32(0x00ff)
8bit mask for register number AND bank id? I think it should be 2ff (10bits) 
because
in rfcsr_write you are doing:
+   rt2x00_set_field32(®, RF_CSR_CFG_REGNUM_MT7620, 
word);
where the word contains up to 6bits of register number AND 4bits of bank id.
So those writes above bank no. 3 are not happening.

> Currently wifi interface appears in the system and can be enabled but
> `iw dev wlan0 scan' gives no result and wlan0 transmits one packet
> roughly in 10 minutes as per ifconfig (ssid doesn't appear in the
> air).
> `iw phy' output looks like this:
> 

Best Regards,
Mikko
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

2014-02-11 Thread Mikko Hissa

Hello again!

On 11 Feb 2014, at 19:12, Mikko Hissa  wrote:

> Hello!
> 
> On 01 Feb 2014, at 02:08, Roman Yeryomin  wrote:
> 
>> Hello everybody!
>> I'm trying to get mt7620 (ramips target, rt-n14u board) wifi working
>> but no luck. I have ported init functions and channel setup from the
>> original (known to be working) driver. The original driver (and
>> datasheet) is available in the web.
>> Unfortunately I have no experience in wifi drivers and this is my
>> first one. Even worse I don't know what those register (rfcsr and bbp)
>> writes _should_ do because they are not in datasheet (I suppose the
>> earlier chips rf registers are not documented also).
>> Attaching the patches hoping somebody with more experience could help
>> or at least give an advise. The patches are not very clean and
>> probably some things can be done in a different way but that's not the
>> point right now.
>> 
> 
> I took a quick look at your patches and one thing caught my eye...
> In rt2800.h you have:
> +#define RF_CSR_CFG_REGNUM_MT7620 FIELD32(0x00ff)
> 8bit mask for register number AND bank id? I think it should be 2ff (10bits) 
> because

That 2ff should, of course, be 3ff. 

> in rfcsr_write you are doing:
> + rt2x00_set_field32(®, RF_CSR_CFG_REGNUM_MT7620, 
> word);
> where the word contains up to 6bits of register number AND 4bits of bank id.
> So those writes above bank no. 3 are not happening.
> 
>> Currently wifi interface appears in the system and can be enabled but
>> `iw dev wlan0 scan' gives no result and wlan0 transmits one packet
>> roughly in 10 minutes as per ifconfig (ssid doesn't appear in the
>> air).
>> `iw phy' output looks like this:
>> 
> 
> Best Regards,
> Mikko
> 
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

2014-02-13 Thread Mikko Hissa

Hi!

On 13 Feb 2014, at 18:56, Roman Yeryomin  wrote:

> On 13 February 2014 16:37, Roman Yeryomin  wrote:
>> On 11 February 2014 20:32, Mikko Hissa  wrote:
>>> Hello again!
>>> 
>>> On 11 Feb 2014, at 19:12, Mikko Hissa  wrote:
>>> 
>>>> Hello!
>>>> 
>>>> On 01 Feb 2014, at 02:08, Roman Yeryomin  wrote:
>>>> 
>>>>> Hello everybody!
>>>>> I'm trying to get mt7620 (ramips target, rt-n14u board) wifi working
>>>>> but no luck. I have ported init functions and channel setup from the
>>>>> original (known to be working) driver. The original driver (and
>>>>> datasheet) is available in the web.
>>>>> Unfortunately I have no experience in wifi drivers and this is my
>>>>> first one. Even worse I don't know what those register (rfcsr and bbp)
>>>>> writes _should_ do because they are not in datasheet (I suppose the
>>>>> earlier chips rf registers are not documented also).
>>>>> Attaching the patches hoping somebody with more experience could help
>>>>> or at least give an advise. The patches are not very clean and
>>>>> probably some things can be done in a different way but that's not the
>>>>> point right now.
>>>>> 
>>>> 
>>>> I took a quick look at your patches and one thing caught my eye...
>>>> In rt2800.h you have:
>>>> +#define RF_CSR_CFG_REGNUM_MT7620 FIELD32(0x00ff)
>>>> 8bit mask for register number AND bank id? I think it should be 2ff 
>>>> (10bits) because
>>> 
>>> That 2ff should, of course, be 3ff.
>>> 
>>>> in rfcsr_write you are doing:
>>>> + rt2x00_set_field32(®, RF_CSR_CFG_REGNUM_MT7620, 
>>>> word);
>>>> where the word contains up to 6bits of register number AND 4bits of bank 
>>>> id.
>>>> So those writes above bank no. 3 are not happening.
>>>> 
>> 
>> Wow, indeed it should be 3ff (10 bits like you said). Thanks for the
>> find! I will try it today...
> 
> So it made it a bit better - tx and interrupt counter increments much
> faster but still nothing in the air and rx counter stays zero.
> Also nothing in monitor mode. :(
> Any other ideas?
> 

A wild guess here is that the PLL is way off. I see that you use 
spec->clk_is_20mhz in config_channel.
I think, that this was added for RT3352 which has the bit 20 set in the 
register SYSCTL_BASE+0x10 if 20Mhz clock source is used. MT7620 uses bit 6 for 
the same thing. If you look at arch/mips/ralink/mt7620.c wmac_clk is not 
defined at all. Try forcing spec->clk_is_20mhz to true and see if it helps!

> 
> Regards,
> Roman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

2014-02-13 Thread Mikko Hissa


On 13 Feb 2014, at 21:03, Mikko Hissa  wrote:

> Hi!
> 
> On 13 Feb 2014, at 18:56, Roman Yeryomin  wrote:
> 
>> On 13 February 2014 16:37, Roman Yeryomin  wrote:
>>> On 11 February 2014 20:32, Mikko Hissa  wrote:
>>>> Hello again!
>>>> 
>>>> On 11 Feb 2014, at 19:12, Mikko Hissa  wrote:
>>>> 
>>>>> Hello!
>>>>> 
>>>>> On 01 Feb 2014, at 02:08, Roman Yeryomin  wrote:
>>>>> 
>>>>>> Hello everybody!
>>>>>> I'm trying to get mt7620 (ramips target, rt-n14u board) wifi working
>>>>>> but no luck. I have ported init functions and channel setup from the
>>>>>> original (known to be working) driver. The original driver (and
>>>>>> datasheet) is available in the web.
>>>>>> Unfortunately I have no experience in wifi drivers and this is my
>>>>>> first one. Even worse I don't know what those register (rfcsr and bbp)
>>>>>> writes _should_ do because they are not in datasheet (I suppose the
>>>>>> earlier chips rf registers are not documented also).
>>>>>> Attaching the patches hoping somebody with more experience could help
>>>>>> or at least give an advise. The patches are not very clean and
>>>>>> probably some things can be done in a different way but that's not the
>>>>>> point right now.
>>>>>> 
>>>>> 
>>>>> I took a quick look at your patches and one thing caught my eye...
>>>>> In rt2800.h you have:
>>>>> +#define RF_CSR_CFG_REGNUM_MT7620 FIELD32(0x00ff)
>>>>> 8bit mask for register number AND bank id? I think it should be 2ff 
>>>>> (10bits) because
>>>> 
>>>> That 2ff should, of course, be 3ff.
>>>> 
>>>>> in rfcsr_write you are doing:
>>>>> + rt2x00_set_field32(®, RF_CSR_CFG_REGNUM_MT7620, 
>>>>> word);
>>>>> where the word contains up to 6bits of register number AND 4bits of bank 
>>>>> id.
>>>>> So those writes above bank no. 3 are not happening.
>>>>> 
>>> 
>>> Wow, indeed it should be 3ff (10 bits like you said). Thanks for the
>>> find! I will try it today...
>> 
>> So it made it a bit better - tx and interrupt counter increments much
>> faster but still nothing in the air and rx counter stays zero.
>> Also nothing in monitor mode. :(
>> Any other ideas?
>> 
> 
> A wild guess here is that the PLL is way off. I see that you use 
> spec->clk_is_20mhz in config_channel.
> I think, that this was added for RT3352 which has the bit 20 set in the 
> register SYSCTL_BASE+0x10 if 20Mhz clock source is used. MT7620 uses bit 6 
> for the same thing. If you look at arch/mips/ralink/mt7620.c wmac_clk is not 
> defined at all. Try forcing spec->clk_is_20mhz to true and see if it helps!
> 

I missed that you did set the wmac clock to 40Mhz in mt7620.c, which isn’t 
correct. It should be set according to the SYSC_REG_SYSTEM_CONFIG0 register bit 
6!

>> 
>> Regards,
>> Roman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

2014-02-13 Thread Mikko Hissa


On 13 Feb 2014, at 23:44, Roman Yeryomin  wrote:

> On 13 February 2014 22:45, Roman Yeryomin  wrote:
>> On 13 February 2014 21:32, Mikko Hissa  wrote:
>>> On 01 Feb 2014, at 02:08, Roman Yeryomin  wrote:
>>> 
>>> Hello everybody!
>>> I'm trying to get mt7620 (ramips target, rt-n14u board) wifi working
>>> but no luck. I have ported init functions and channel setup from the
>>> original (known to be working) driver. The original driver (and
>>> datasheet) is available in the web.
>>> Unfortunately I have no experience in wifi drivers and this is my
>>> first one. Even worse I don't know what those register (rfcsr and bbp)
>>> writes _should_ do because they are not in datasheet (I suppose the
>>> earlier chips rf registers are not documented also).
>>> Attaching the patches hoping somebody with more experience could help
>>> or at least give an advise. The patches are not very clean and
>>> probably some things can be done in a different way but that's not the
>>> point right now.
>>> 
>>> 
>>> I took a quick look at your patches and one thing caught my eye...
>>> In rt2800.h you have:
>>> +#define RF_CSR_CFG_REGNUM_MT7620 FIELD32(0x00ff)
>>> 8bit mask for register number AND bank id? I think it should be 2ff (10bits)
>>> because
>>> 
>>> 
>>> That 2ff should, of course, be 3ff.
>>> 
>>> in rfcsr_write you are doing:
>>> + rt2x00_set_field32(®, RF_CSR_CFG_REGNUM_MT7620,
>>> word);
>>> where the word contains up to 6bits of register number AND 4bits of bank id.
>>> So those writes above bank no. 3 are not happening.
>>> 
>>> 
>>> Wow, indeed it should be 3ff (10 bits like you said). Thanks for the
>>> find! I will try it today...
>>> 
>>> 
>>> So it made it a bit better - tx and interrupt counter increments much
>>> faster but still nothing in the air and rx counter stays zero.
>>> Also nothing in monitor mode. :(
>>> Any other ideas?
>>> 
>>> 
>>> A wild guess here is that the PLL is way off. I see that you use
>>> spec->clk_is_20mhz in config_channel.
>>> I think, that this was added for RT3352 which has the bit 20 set in the
>>> register SYSCTL_BASE+0x10 if 20Mhz clock source is used. MT7620 uses bit 6
>>> for the same thing. If you look at arch/mips/ralink/mt7620.c wmac_clk is not
>>> defined at all. Try forcing spec->clk_is_20mhz to true and see if it helps!
>>> 
>>> 
>>> I missed that you did set the wmac clock to 40Mhz in mt7620.c, which isn’t
>>> correct. It should be set according to the SYSC_REG_SYSTEM_CONFIG0 register
>>> bit 6!
>> 
>> Yea.. I tried both 20 and 40 but that was before you found the incorrect 
>> mask.
>> Let me try 20MHz...
> 
> Seems setting it to 20MHz didn't change anything.
> But you are right, I will make it read the setting from the register
> to get rid of uncertainty in further tests.
> 

Do you know if the device has external LNA and/or PA or does the eeprom 
indicate such thing?
I see that you have commented out all external LNA specific code. You could try 
‘iw wlan0 survey dump’ to see if the radio is alive?

> Regards,
> Roman

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

2014-02-13 Thread Mikko Hissa


On 04 Feb 2014, at 17:56, Helmut Schaa  wrote:

> On Tue, Feb 4, 2014 at 4:40 PM, Roman Yeryomin  wrote:
>> Thanks for answer, Helmut!
>> 
>> On 3 February 2014 18:01, Helmut Schaa  wrote:
>>> On Sat, Feb 1, 2014 at 1:08 AM, Roman Yeryomin  
>>> wrote:
 Unfortunately I have no experience in wifi drivers and this is my
 first one. Even worse I don't know what those register (rfcsr and bbp)
 writes _should_ do because they are not in datasheet (I suppose the
 earlier chips rf registers are not documented also).
>>> 
>>> Yep, there are no documents out there as far as I know :/
>> 
>> So it's mostly just magic and assumptions...
>> 
 Attaching the patches hoping somebody with more experience could help
 or at least give an advise. The patches are not very clean and
 probably some things can be done in a different way but that's not the
 point right now.
 
 Currently wifi interface appears in the system and can be enabled but
 `iw dev wlan0 scan' gives no result and wlan0 transmits one packet
 roughly in 10 minutes as per ifconfig (ssid doesn't appear in the
 air).
 `iw phy' output looks like this:
>>> 
>>> Maybe you should start with a simple monitor interface to get the RX
>>> path working (iw phy phy0 interface add mon0 type monitor).
>>> Just run a tcpdump on mon0 and see if you can receive something (with
>>> your patches applied).
>> 
>> Unfortunately it doesn't give any results.
>> Also rx counter was always zero - I forgot to mention that.
>> What I thought was suspicious is "Available Antennas: TX 0 RX 0" in iw
>> phy output, but I've checked other chips which do work and they all
>> have the same record.
> 
> Yeah, rt2x00 does not initialize these AFAIK.
> 
> So, you ported the code from the ralink rt2860 driver, right?
> I haven't looked into newer ralink chips at all. Did you check if any MAC
> layer changes regarding RX and TX rings exist?
> 

In rt2800lib.c function rt2800_get_txwi_rxwi_size()
Add case MT7620 with RT5592.

*txwi_size = TXWI_DESC_SIZE_5WORDS;
*rxwi_size = RXWI_DESC_SIZE_6WORDS;
break;


> helmut
> ___
> 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] [RFC] mt7620 wifi

2014-02-13 Thread Mikko Hissa


On 14 Feb 2014, at 01:04, Roman Yeryomin  wrote:

> On 14 February 2014 00:34, Mikko Hissa  wrote:
>> In rt2800lib.c function rt2800_get_txwi_rxwi_size()
>> Add case MT7620 with RT5592.
>> 
>>*txwi_size = TXWI_DESC_SIZE_5WORDS;
>>*rxwi_size = RXWI_DESC_SIZE_6WORDS;
>>break;
>> 
> 
> I suppose you mean RT5390 because:
> ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected
> 
> Also as far as I understand (from datasheet) it's not the same as
> RT5592. Correct me if I'm wrong.
> So I added:
> 
>case RT5390:
>*txwi_size = TXWI_DESC_SIZE_5WORDS;
>*rxwi_size = RXWI_DESC_SIZE_4WORDS;
>break;
> 
> But seems it didn't change anything.

Could you attach the file /lib/firmware/soc_wmac.eeprom from the router, 
there’s something weird there.

> 
> Regards,
> Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

2014-02-14 Thread Mikko Hissa


On 14 Feb 2014, at 01:04, Roman Yeryomin  wrote:

> On 14 February 2014 00:34, Mikko Hissa  wrote:
>> In rt2800lib.c function rt2800_get_txwi_rxwi_size()
>> Add case MT7620 with RT5592.
>> 
>>*txwi_size = TXWI_DESC_SIZE_5WORDS;
>>*rxwi_size = RXWI_DESC_SIZE_6WORDS;
>>break;
>> 
> 
> I suppose you mean RT5390 because:
> ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 5390, rev 0500 detected
> 
> Also as far as I understand (from datasheet) it's not the same as
> RT5592. Correct me if I'm wrong.
> So I added:
> 
>case RT5390:
>*txwi_size = TXWI_DESC_SIZE_5WORDS;
>*rxwi_size = RXWI_DESC_SIZE_4WORDS;
>break;

They should be 5 and 6 words not 5 and 4!

*txwi_size = TXWI_DESC_SIZE_5WORDS;
*rxwi_size = RXWI_DESC_SIZE_6WORDS;
break;

The original driver detects MT7620 by chip id 0x5390 and bus type. The driver 
in rt2x00 for RT5390 is for a another chip. So you might not want to run the 
bits of code meant for RT5390 but create some dummy definition for MT7620 and 
set it in rt2800_probe_rt().

Best Regards,
Mikko

> But seems it didn't change anything.
> 
> Regards,
> Roman
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] d-link dir-615 h1 without wifi on trunk !

2014-05-16 Thread Mikko Hissa


On 16 May 2014, at 14:18, Daniel Petre  wrote:

> Hello,

Hi!

> anyone has any idea about the fix for the wireless of d-link dir-615 h1 ?
> 

In rt2800lib.c, remove line 7812:  
  if (rt2x00_rt(rt2x00dev, RT3290) ||
-rt2x00_rt(rt2x00dev, RT3352) ||
 rt2x00_rt(rt2x00dev, RT5390) ||
 rt2x00_rt(rt2x00dev, RT5392))

(You’ll find it in 
build_dir/target-mipsel_24kec+dsp_uClibc-0.9.33.2/linux-ramips_rt305x/compat-wireless-2014-03-31/drivers/net/wireless/rt2x00)

Just do make without a clean and it’ll work.

There still are some problems with rt2x00 not limited to rt3352 (slow rx etc.)…

> https://dev.openwrt.org/ticket/16406
> 
> I just tried r40772 after a make clean and still no wireless:
> 
> rt2800_wmac 1018.wmac: failed to load eeprom property
> ieee80211 phy0: rt2x00lib_request_eeprom_file: Info - Loading EEPROM data 
> from 'soc_wmac.eeprom'.
> ieee80211 phy0: rt2x00_set_rt: Info - RT chipset 3352, rev 0200 detected
> ieee80211 phy0: rt2800_init_eeprom: Error - Invalid RF chipset 0x3352 detected
> ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device
> 
> thanks!
> ___
> 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

[OpenWrt-Devel] [PATCH] ramips: RT-N56U support fixes and factory image creation

2014-06-11 Thread Mikko Hissa

Signed-off-by: Mikko Hissa 
---
 .../preinit/04_disable_wnce2001_flash_checksumming |  43 ---
 .../base-files/lib/preinit/04_handle_checksumming  |  56 
 target/linux/ramips/dts/RTN56U.dts |   8 +
 target/linux/ramips/image/Makefile |   8 +-
 .../patches-3.10/0135-mtd-add-rtn56u-support.patch |  28 ++
 tools/firmware-utils/Makefile  |   1 +
 tools/firmware-utils/src/mkrtn56uimg.c | 294 +
 7 files changed, 394 insertions(+), 44 deletions(-)
 delete mode 100644 
target/linux/ramips/base-files/lib/preinit/04_disable_wnce2001_flash_checksumming
 create mode 100644 
target/linux/ramips/base-files/lib/preinit/04_handle_checksumming
 create mode 100644 
target/linux/ramips/patches-3.10/0135-mtd-add-rtn56u-support.patch
 create mode 100644 tools/firmware-utils/src/mkrtn56uimg.c

diff --git 
a/target/linux/ramips/base-files/lib/preinit/04_disable_wnce2001_flash_checksumming
 
b/target/linux/ramips/base-files/lib/preinit/04_disable_wnce2001_flash_checksumming
deleted file mode 100644
index 67a1746..000
--- 
a/target/linux/ramips/base-files/lib/preinit/04_disable_wnce2001_flash_checksumming
+++ /dev/null
@@ -1,43 +0,0 @@
-#!/bin/sh
-
-# Netgear WNCE2001 has does a checksum check on boot and goes into recovery
-# tftp mode when the check fails.  Initializing the JFFS2 partition triggers
-# this, so we make sure to zero checksum and size to be checksummed before
-# that happens, so this needs to run very early during boot.
-
-do_wnce2001_checksumming_disable() {
-   . /lib/ramips.sh
-
-   local board=$(ramips_board_name)
-
-   case "$board" in
-   wnce2001)
-   echo "Board is WNCE2001, updating checksum partition..."
-   local zeroes=/dev/zero
-   local tmpfile=/tmp/wnce2001_checksum
-   local partname=checksum
-   local mtd=$(find_mtd_part $partname)
-   dd if=$mtd of=$tmpfile bs=80 count=1 2>/dev/null
-   signature=$(dd if=$tmpfile bs=1 skip=24 count=20 2>/dev/null)
-   checksum=$(dd if=$tmpfile bs=1 count=4 2>/dev/null | hexdump -v 
-n 4 -e '1/1 "%02x"')
-   if [ "$signature" != "RT3052-AP-WNCE2001-3" ]; then
-   echo "Signature of checksum partition is wrong, 
bailing."
-   return 0
-   fi
-   if [ "$checksum" != "" ]; then
-   echo "Checksum is set, zeroing."
-   # zero out checksum
-   dd if=$zeroes of=$tmpfile conv=notrunc bs=1 seek=0 
count=4 2>/dev/null
-   # zero out bytecount to be checksummed
-   dd if=$zeroes of=$tmpfile conv=notrunc bs=1 seek=60 
count=4 2>/dev/null
-   mtd write $tmpfile $partname
-   else
-   echo "Checksum is already zero, nothing to do."
-   fi
-   ;;
-   esac
-
-   return 0
-}
-
-boot_hook_add preinit_main do_wnce2001_checksumming_disable
diff --git a/target/linux/ramips/base-files/lib/preinit/04_handle_checksumming 
b/target/linux/ramips/base-files/lib/preinit/04_handle_checksumming
new file mode 100644
index 000..fd06d20
--- /dev/null
+++ b/target/linux/ramips/base-files/lib/preinit/04_handle_checksumming
@@ -0,0 +1,56 @@
+#!/bin/sh
+
+# Netgear WNCE2001 has does a checksum check on boot and goes into recovery
+# tftp mode when the check fails.  Initializing the JFFS2 partition triggers
+# this, so we make sure to zero checksum and size to be checksummed before
+# that happens, so this needs to run very early during boot.
+
+do_checksumming_disable() {
+   . /lib/ramips.sh
+
+   local board=$(ramips_board_name)
+
+   case "$board" in
+   wnce2001)
+   echo "Board is WNCE2001, updating checksum partition..."
+   local zeroes=/dev/zero
+   local tmpfile=/tmp/wnce2001_checksum
+   local partname=checksum
+   local mtd=$(find_mtd_part $partname)
+   dd if=$mtd of=$tmpfile bs=80 count=1 2>/dev/null
+   signature=$(dd if=$tmpfile bs=1 skip=24 count=20 2>/dev/null)
+   checksum=$(dd if=$tmpfile bs=1 count=4 2>/dev/null | hexdump -v 
-n 4 -e '1/1 "%02x"')
+   if [ "$signature" != "RT3052-AP-WNCE2001-3" ]; then
+   echo "Signature of checksum partition is wrong, 
bailing."
+   return 0
+   fi
+   if [ "$checksum" != "" ]; then
+   echo "Checksum is set, zeroing."
+   # zero out checksum
+   dd if=$zeroes of=$tmpfile conv=notrunc bs=1 seek=0

Re: [OpenWrt-Devel] dlink dir-615 h1 serial pinout

2012-03-12 Thread Mikko Hissa

No, the first one is VCC and the second one is GND. 

d...@ip6.ro kirjoitti 12.3.2012 kello 15.37:

> hello,
> apologies for the slightly offtopic,
> im trying to solder a serial to dlink dir615 h1 revision
> and i was wondering if anyone got it right?
> 
> attached is the pic, i guess the left most is the GND and the two on the 
> right are RX and TX ?
> 
> thanks!
> ___
> openwrt-devel mailing list
> openwrt-devel@lists.openwrt.org
> https://lists.openwrt.org/mailman/listinfo/openwrt-devel

___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Re: [OpenWrt-Devel] [PATCH] Fix 'Dropping frame due to full tx queue' for Ralink wifi get stuck.

Re: [OpenWrt-Devel] [PATCH] Fix 'Dropping frame due to full tx queue' for Ralink wifi get stuck.

[OpenWrt-Devel] hostapd disconnects with Apple devices.

Re: [OpenWrt-Devel] What should I do if I want to use the RGMII interface on Ralink RT3052?

Re: [OpenWrt-Devel] What should I do if I want to use the RGMII interface on Ralink RT3052?

[OpenWrt-Devel] [PATCH] ramips: add support for D-Link DIR-615 H1

Re: [OpenWrt-Devel] [PATCH] ramips: add support for D-Link DIR-615 H1

Re: [OpenWrt-Devel] Problem with Ralink rt3352 wireless driver

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

Re: [OpenWrt-Devel] [RFC] mt7620 wifi

Re: [OpenWrt-Devel] d-link dir-615 h1 without wifi on trunk !

[OpenWrt-Devel] [PATCH] ramips: RT-N56U support fixes and factory image creation

Re: [OpenWrt-Devel] dlink dir-615 h1 serial pinout

19 matches

Site Navigation

Mail list logo

Footer information