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

2014-07-01 Thread Xiongfei(Alex) GUO
hi, Roman,

simply try these commands in OpenWrt, then the ethernet will start to work.

uci set network.@switch_vlan[0].vid=1
uci set network.@switch_vlan[1].vid=2
uci commit
/etc/init.d/network restart

BTW, I'm not sure my test is right, that I can see the wireless driver
start, but I cannot find any WIFI with SSID==OpenWrt.



hi, John,

the problem here is,

in old driver for mt7530, vid is always equal to vlan number. but in
new driver vid must be set explicitly.

in most applications, user don't need to care about the difference
between vid and vlan.

my solution for mt7530 driver is, when swconfig apply, if vid == 0,
then let vid = vlan (so vid==0 is valid). if you think it is ok, i can
send a patch about this.



Regards!~

Xiongfei (Alex) Guo
Credo Semi.


On Tue, Jul 1, 2014 at 7:37 AM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 1 July 2014 01:54, xf...@credosemi.com xf...@credosemi.com wrote:
 can you just show the output of swconfig dev switch0 show ?


Also it appeared that ethernet is broken for mt7620n (didn't test
other ramips targets) on trunk. Apparently after this (not sure how
it's possible): https://dev.openwrt.org/changeset/41331
As `swconfig list' tells: Found: switch0 - mt7530


 I don't have the board in hands right now but the other thing I've
 noticed that VID for both 1 and 2 vlans was 0. And setting it to
 correct values didn't have any effect.

 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-07-01 Thread Kazuki Shimada

Hi, Roman.

Do your patches have any chance to make wireless on mt7620a device to work?
If so, I'll try it on my buffalo whr-300hp2.

Thanks in advance.

Kazuki Shimada


(2014/07/01 2:36), Roman Yeryomin wrote:

On 30 June 2014 20:30, John Crispin j...@phrozen.org wrote:



i think this is the same is inside the 5390 pci chip ? i have one
of those, will verify tomorrow.


Would be good!



we will figure it out, otherwise we ask the rt2x00 people for help



please tell me which patches to test/merge .. this is really
good news, thanks a lot to everyone involved.


Basically all I've attached, it's just they are not in the form to
git apply them. I can prepare those too if you want.


no worries i will ive it a shot in a sec and apply it manually


I've sent the series just now...

Regards,
Roman
___
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-07-01 Thread John Crispin
Hi,

i have the whr-300hp2 on my desk now and will fix the switch and merge
the wifi fixes now.

John

On 01/07/2014 09:41, Kazuki Shimada wrote:
 Hi, Roman.
 
 Do your patches have any chance to make wireless on mt7620a device
 to work? If so, I'll try it on my buffalo whr-300hp2.
 
 Thanks in advance.
 
 Kazuki Shimada
 
 
 (2014/07/01 2:36), Roman Yeryomin wrote:
 On 30 June 2014 20:30, John Crispin j...@phrozen.org wrote:
 
 i think this is the same is inside the 5390 pci chip ? i
 have one of those, will verify tomorrow.
 
 Would be good!
 
 
 we will figure it out, otherwise we ask the rt2x00 people for
 help
 
 
 please tell me which patches to test/merge .. this is
 really good news, thanks a lot to everyone involved.
 
 Basically all I've attached, it's just they are not in the
 form to git apply them. I can prepare those too if you want.
 
 no worries i will ive it a shot in a sec and apply it manually
 
 I've sent the series just now...
 
 Regards, Roman ___ 
 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 mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


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

2014-07-01 Thread John Crispin
Hi,

please make a patch that will default vid == vlan nr. this way we have
a sane default hat user can override with higher vid if needed.

Thanks
John


On 01/07/2014 08:57, Xiongfei(Alex) GUO wrote:
 hi, Roman,
 
 simply try these commands in OpenWrt, then the ethernet will start
 to work.
 
 uci set network.@switch_vlan[0].vid=1 uci set
 network.@switch_vlan[1].vid=2 uci commit /etc/init.d/network
 restart
 
 BTW, I'm not sure my test is right, that I can see the wireless
 driver start, but I cannot find any WIFI with SSID==OpenWrt.
 
 
 
 hi, John,
 
 the problem here is,
 
 in old driver for mt7530, vid is always equal to vlan number. but
 in new driver vid must be set explicitly.
 
 in most applications, user don't need to care about the difference 
 between vid and vlan.
 
 my solution for mt7530 driver is, when swconfig apply, if vid ==
 0, then let vid = vlan (so vid==0 is valid). if you think it is ok,
 i can send a patch about this.
 
 
 
 Regards!~
 
 Xiongfei (Alex) Guo Credo Semi.
 
 
 On Tue, Jul 1, 2014 at 7:37 AM, Roman Yeryomin
 leroi.li...@gmail.com wrote:
 On 1 July 2014 01:54, xf...@credosemi.com xf...@credosemi.com
 wrote:
 can you just show the output of swconfig dev switch0 show ?
 
 
 Also it appeared that ethernet is broken for mt7620n (didn't
 test other ramips targets) on trunk. Apparently after this
 (not sure how it's possible):
 https://dev.openwrt.org/changeset/41331 As `swconfig list'
 tells: Found: switch0 - mt7530
 
 
 I don't have the board in hands right now but the other thing
 I've noticed that VID for both 1 and 2 vlans was 0. And setting
 it to correct values didn't have any effect.
 
 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-07-01 Thread Roman Yeryomin
On 1 July 2014 09:57, Xiongfei(Alex) GUO xf...@credosemi.com wrote:
 hi, Roman,

 simply try these commands in OpenWrt, then the ethernet will start to work.

 uci set network.@switch_vlan[0].vid=1
 uci set network.@switch_vlan[1].vid=2
 uci commit
 /etc/init.d/network restart

That helped, indeed!
But how come changing the vid via swconfig directly doesn't have any effect?
For example:

root@OpenWrt:/# swconfig dev switch0 vlan 1 show
VLAN 1:
vid: 1
ports: 1 2 3 4 6t
root@OpenWrt:/# swconfig dev switch0 vlan 1 set vid 5
root@OpenWrt:/# swconfig dev switch0 vlan 1 show
VLAN 1:
vid: 1
ports: 1 2 3 4 6t

Because this is what I saw - the vid was 0 and I tried to set it via
swconfig which didn't help.
To me it still looks that something is broken if I cannot change vid
(pvid or other vlan configuration) via swconfig.

 BTW, I'm not sure my test is right, that I can see the wireless driver
 start, but I cannot find any WIFI with SSID==OpenWrt.


missing eeprom?
___
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-07-01 Thread Xiongfei(Alex) GUO
On Tue, Jul 1, 2014 at 9:51 PM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 1 July 2014 09:57, Xiongfei(Alex) GUO xf...@credosemi.com wrote:
 hi, Roman,

 simply try these commands in OpenWrt, then the ethernet will start to work.

 uci set network.@switch_vlan[0].vid=1
 uci set network.@switch_vlan[1].vid=2
 uci commit
 /etc/init.d/network restart

 That helped, indeed!
 But how come changing the vid via swconfig directly doesn't have any effect?
 For example:

 root@OpenWrt:/# swconfig dev switch0 vlan 1 show
 VLAN 1:
 vid: 1
 ports: 1 2 3 4 6t
 root@OpenWrt:/# swconfig dev switch0 vlan 1 set vid 5
 root@OpenWrt:/# swconfig dev switch0 vlan 1 show
 VLAN 1:
 vid: 1
 ports: 1 2 3 4 6t

 Because this is what I saw - the vid was 0 and I tried to set it via
 swconfig which didn't help.
 To me it still looks that something is broken if I cannot change vid
 (pvid or other vlan configuration) via swconfig.

one more step,

$ swconfig dev switch0 set apply 1

Xiongfei(Alex) Guo
Credo Semi.
___
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-07-01 Thread Roman Yeryomin
On 1 July 2014 17:49, Xiongfei(Alex) GUO xf...@credosemi.com wrote:
 On Tue, Jul 1, 2014 at 9:51 PM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 1 July 2014 09:57, Xiongfei(Alex) GUO xf...@credosemi.com wrote:
 hi, Roman,

 simply try these commands in OpenWrt, then the ethernet will start to work.

 uci set network.@switch_vlan[0].vid=1
 uci set network.@switch_vlan[1].vid=2
 uci commit
 /etc/init.d/network restart

 That helped, indeed!
 But how come changing the vid via swconfig directly doesn't have any effect?
 For example:

 root@OpenWrt:/# swconfig dev switch0 vlan 1 show
 VLAN 1:
 vid: 1
 ports: 1 2 3 4 6t
 root@OpenWrt:/# swconfig dev switch0 vlan 1 set vid 5
 root@OpenWrt:/# swconfig dev switch0 vlan 1 show
 VLAN 1:
 vid: 1
 ports: 1 2 3 4 6t

 Because this is what I saw - the vid was 0 and I tried to set it via
 swconfig which didn't help.
 To me it still looks that something is broken if I cannot change vid
 (pvid or other vlan configuration) via swconfig.

 one more step,

 $ swconfig dev switch0 set apply 1


yes, I already figured it out (it wasn't obvious at all) - see the
post in your patch thread.


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-06-30 Thread Сергей Василюгин
  29.06.2014, 20:34, "Сергей Василюгин" vasilu...@yandex.ru:  29.06.2014, 18:33, "Roman Yeryomin" leroi.li...@gmail.com:On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote: 26.06.2014, 06:03, "Daniel" dan...@makrotopia.org: Hi Roman, On 04/04/2014 04:39 PM, Roman Yeryomin wrote:  I worked on other things lately but plan to return to rt2x00 soon and  maybe try ralink driver on trunk again. I started looking into your patches and started to see things moving as far as you got. I suggest to define RT6352 and set chip.rt to that instead of checking for chip.rf == RF7620 in cases which were meant for RT5390. Is there any more recent version of your work on rt2x00 than the 630-rt2x00-add-mt7620-20140131.patch included in your first post? If so, please share it, I'd like to re-use what ever there is and try to botch things up a bit ;) Cheers Daniel After some attempts tonight I make working version of the patch. But my trunk revision really very old and I need time to rebase it. The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); instead of *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620); broke all rf reading.Honestly that sounds weird because unless you change all the othermasks for mt7620 you will have them overlapped.Also this is how that register is described in datasheet (the fieldsare in reverse order comparing to all other socs).If you say you got it working can you send at least binary image totest (while you are trying to rebase it)?Regards,Roman1. As my friends say - let me show :)Your recently sent patch: static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,  const unsigned int word, u8 *value) {@@ -182,15 +221,31 @@ * doesn't become available in time, reg will be 0x * which means we return 0xff to the caller. */-   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {-   reg = 0;-   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);-   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);-   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);+   switch (rt2x00dev-chip.rf) {+   case RF7620:+   if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) {+   reg = 0;+   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620, word);+   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620, 0);+   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1);++   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);++   WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg);+   }+   break;+   default:+   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {+   reg = 0;+   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);+   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);+   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1); -   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);+   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); -   WAIT_FOR_RFCSR(rt2x00dev, reg);+   WAIT_FOR_RFCSR(rt2x00dev, reg);+   }+   break;    } *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);@@ -198,6 +253,12 @@    mutex_unlock(rt2x00dev-csr_mutex); } use call*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);for both case - default and mt7620. I call*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);for mt7620 :) 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8gDlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto detect not working yet). AFAIK asus rt-n14u use the same. Updated. ---serge ___
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-06-30 Thread John Crispin


On 30/06/2014 18:50, Roman Yeryomin wrote:
 So... I've tried the old tree with suggested fix and ended up
 rebasing my patches to trunk, adding all the fixes and cleaning
 them up. Attaching the patches for now. John, Helmut, what do you
 think, can we apply them to the trunk (I will send them properly
 then)? Unfortunately I don't have any other socs which identify
 themselves as RT5390 to test if this patch brakes anything for it.
 

i think this is the same is inside the 5390 pci chip ? i have one of
those, will verify tomorrow.

please tell me which patches to test/merge .. this is really good
news, thanks a lot to everyone involved.



 Also it appeared that ethernet is broken for mt7620n (didn't test 
 other ramips targets) on trunk. Apparently after this (not sure
 how it's possible): https://dev.openwrt.org/changeset/41331 As
 `swconfig list' tells: Found: switch0 - mt7530
 
huh ... i tested it on 2 boards before the merge, will verify ... what
board are you testing on ?

John

 
 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-06-30 Thread Roman Yeryomin
On 30 June 2014 19:50, Roman Yeryomin leroi.li...@gmail.com wrote:
 So... I've tried the old tree with suggested fix and ended up rebasing
 my patches to trunk, adding all the fixes and cleaning them up.
 Attaching the patches for now. John, Helmut, what do you think, can we
 apply them to the trunk (I will send them properly then)?
 Unfortunately I don't have any other socs which identify themselves as
 RT5390 to test if this patch brakes anything for it.

 Also it appeared that ethernet is broken for mt7620n (didn't test
 other ramips targets) on trunk. Apparently after this (not sure how
 it's possible): https://dev.openwrt.org/changeset/41331
 As `swconfig list' tells: Found: switch0 - mt7530

Images for test:
https://box.advem.lv/public.php?service=filest=82ea8ca6d74bdc1538f110546e77d584

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-06-30 Thread Roman Yeryomin
On 30 June 2014 19:52, John Crispin j...@phrozen.org wrote:


 On 30/06/2014 18:50, Roman Yeryomin wrote:
 So... I've tried the old tree with suggested fix and ended up
 rebasing my patches to trunk, adding all the fixes and cleaning
 them up. Attaching the patches for now. John, Helmut, what do you
 think, can we apply them to the trunk (I will send them properly
 then)? Unfortunately I don't have any other socs which identify
 themselves as RT5390 to test if this patch brakes anything for it.


 i think this is the same is inside the 5390 pci chip ? i have one of
 those, will verify tomorrow.

Would be good!

 please tell me which patches to test/merge .. this is really good
 news, thanks a lot to everyone involved.

Basically all I've attached, it's just they are not in the form to git
apply them.
I can prepare those too if you want.

 Also it appeared that ethernet is broken for mt7620n (didn't test
 other ramips targets) on trunk. Apparently after this (not sure
 how it's possible): https://dev.openwrt.org/changeset/41331 As
 `swconfig list' tells: Found: switch0 - mt7530

 huh ... i tested it on 2 boards before the merge, will verify ... what
 board are you testing on ?

Asus RT-N14U


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-06-30 Thread John Crispin

 i think this is the same is inside the 5390 pci chip ? i have one
 of those, will verify tomorrow.
 
 Would be good!
 

we will figure it out, otherwise we ask the rt2x00 people for help


 please tell me which patches to test/merge .. this is really
 good news, thanks a lot to everyone involved.
 
 Basically all I've attached, it's just they are not in the form to
 git apply them. I can prepare those too if you want.
 
no worries i will ive it a shot in a sec and apply it manually


thanks,
John
___
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-06-30 Thread Roman Yeryomin
On 30 June 2014 20:30, John Crispin j...@phrozen.org wrote:

 i think this is the same is inside the 5390 pci chip ? i have one
 of those, will verify tomorrow.

 Would be good!


 we will figure it out, otherwise we ask the rt2x00 people for help


 please tell me which patches to test/merge .. this is really
 good news, thanks a lot to everyone involved.

 Basically all I've attached, it's just they are not in the form to
 git apply them. I can prepare those too if you want.

 no worries i will ive it a shot in a sec and apply it manually

I've sent the series just now...

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-06-30 Thread xf...@credosemi.com
can you just show the output of swconfig dev switch0 show ?

Alex

Roman Yeryomin leroi.li...@gmail.com编写:

On 29 June 2014 20:11, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 29 June 2014 16:33, Сергей Василюгин vasilu...@yandex.ru wrote:


 29.06.2014, 18:33, Roman Yeryomin leroi.li...@gmail.com:

 On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote:

  26.06.2014, 06:03, Daniel dan...@makrotopia.org:

  Hi Roman,

  On 04/04/2014 04:39 PM, Roman Yeryomin wrote:

   I worked on other things lately but plan to return to rt2x00 soon and
   maybe try ralink driver on trunk again.

  I started looking into your patches and started to see things moving as far
  as
  you got.
  I suggest to define RT6352 and set chip.rt to that instead of checking for
  chip.rf == RF7620 in cases which were meant for RT5390.
  Is there any more recent version of your work on rt2x00 than the
  630-rt2x00-add-mt7620-20140131.patch included in your first post? If so,
  please
  share it, I'd like to re-use what ever there is and try to botch things up
 a
  bit ;)

  Cheers


  Daniel

  After some attempts tonight I make working version of the patch. But my
  trunk revision really very old and I need time to rebase it.
  The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So
  *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
  instead of
  *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
  broke all rf reading.

 Honestly that sounds weird because unless you change all the other
 masks for mt7620 you will have them overlapped.
 Also this is how that register is described in datasheet (the fields
 are in reverse order comparing to all other socs).
 If you say you got it working can you send at least binary image to
 test (while you are trying to rebase it)?

 Regards,
 Roman

 1. As my friends say - let me show :)
 Your recently sent patch:

 static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
   const unsigned int word, u8 *value)
  {
 @@ -182,15 +221,31 @@
  * doesn't become available in time, reg will be 0x
  * which means we return 0xff to the caller.
  */
 -   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
 -   reg = 0;
 -   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
 -   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
 -   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);
 +   switch (rt2x00dev-chip.rf) {
 +   case RF7620:
 +   if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) {
 +   reg = 0;
 +   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620,
 word);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620,
 0);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1);
 +
 +   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
 reg);
 +
 +   WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg);
 +   }
 +   break;
 +   default:
 +   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
 +   reg = 0;
 +   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);

 -   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
 +   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
 reg);

 -   WAIT_FOR_RFCSR(rt2x00dev, reg);
 +   WAIT_FOR_RFCSR(rt2x00dev, reg);
 +   }
 +   break;
 }

 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
 @@ -198,6 +253,12 @@
 mutex_unlock(rt2x00dev-csr_mutex);
  }

 use call
 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
 for both case - default and mt7620. I call
 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
 for mt7620 :)

 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8g
 Dlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto
 detect not working yet). AFAIK asus rt-n14u use the same.


 Sorry, I've read your previous email wrong.
 By looking at the code seems you are right! I can't believe I've
 missed that line before! I will look - maybe I kept the old tree I was
 experimenting with.
 BTW, I don't know why but your image for rt-n14u didn't work for me -
 even ethernet is not working.

So... I've tried the old tree with suggested fix and ended up rebasing
my patches to trunk, adding all the fixes and cleaning them up.
Attaching the patches for now. John, Helmut, what do you think, can we
apply them to the trunk (I will send them properly then)?
Unfortunately I don't have any other socs which identify themselves as
RT5390 to test if this patch brakes anything for it.

Also it appeared that ethernet is broken for mt7620n (didn't test
other ramips targets) on trunk. Apparently after this (not 

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

2014-06-30 Thread Roman Yeryomin
On 1 July 2014 01:54, xf...@credosemi.com xf...@credosemi.com wrote:
 can you just show the output of swconfig dev switch0 show ?


Also it appeared that ethernet is broken for mt7620n (didn't test
other ramips targets) on trunk. Apparently after this (not sure how
it's possible): https://dev.openwrt.org/changeset/41331
As `swconfig list' tells: Found: switch0 - mt7530


I don't have the board in hands right now but the other thing I've
noticed that VID for both 1 and 2 vlans was 0. And setting it to
correct values didn't have any effect.

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-06-29 Thread Roman Yeryomin
On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote:


 26.06.2014, 06:03, Daniel dan...@makrotopia.org:

 Hi Roman,

 On 04/04/2014 04:39 PM, Roman Yeryomin wrote:

  I worked on other things lately but plan to return to rt2x00 soon and
  maybe try ralink driver on trunk again.

 I started looking into your patches and started to see things moving as far
 as
 you got.
 I suggest to define RT6352 and set chip.rt to that instead of checking for
 chip.rf == RF7620 in cases which were meant for RT5390.
 Is there any more recent version of your work on rt2x00 than the
 630-rt2x00-add-mt7620-20140131.patch included in your first post? If so,
 please
 share it, I'd like to re-use what ever there is and try to botch things up a
 bit ;)

 Cheers


 Daniel

 After some attempts tonight I make working version of the patch. But my
 trunk revision really very old and I need time to rebase it.
 The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So
 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
 instead of
 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
 broke all rf reading.

Honestly that sounds weird because unless you change all the other
masks for mt7620 you will have them overlapped.
Also this is how that register is described in datasheet (the fields
are in reverse order comparing to all other socs).
If you say you got it working can you send at least binary image to
test (while you are trying to rebase it)?

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-06-29 Thread Сергей Василюгин
  29.06.2014, 18:33, "Roman Yeryomin" leroi.li...@gmail.com:On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote: 26.06.2014, 06:03, "Daniel" dan...@makrotopia.org: Hi Roman, On 04/04/2014 04:39 PM, Roman Yeryomin wrote:  I worked on other things lately but plan to return to rt2x00 soon and  maybe try ralink driver on trunk again. I started looking into your patches and started to see things moving as far as you got. I suggest to define RT6352 and set chip.rt to that instead of checking for chip.rf == RF7620 in cases which were meant for RT5390. Is there any more recent version of your work on rt2x00 than the 630-rt2x00-add-mt7620-20140131.patch included in your first post? If so, please share it, I'd like to re-use what ever there is and try to botch things up a bit ;) Cheers Daniel After some attempts tonight I make working version of the patch. But my trunk revision really very old and I need time to rebase it. The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); instead of *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620); broke all rf reading.Honestly that sounds weird because unless you change all the othermasks for mt7620 you will have them overlapped.Also this is how that register is described in datasheet (the fieldsare in reverse order comparing to all other socs).If you say you got it working can you send at least binary image totest (while you are trying to rebase it)?Regards,Roman1. As my friends say - let me show :)Your recently sent patch: static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,  const unsigned int word, u8 *value) {@@ -182,15 +221,31 @@ * doesn't become available in time, reg will be 0x * which means we return 0xff to the caller. */-   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {-   reg = 0;-   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);-   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);-   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);+   switch (rt2x00dev-chip.rf) {+   case RF7620:+   if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) {+   reg = 0;+   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620, word);+   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620, 0);+   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1);++   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);++   WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg);+   }+   break;+   default:+   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {+   reg = 0;+   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);+   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);+   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1); -   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);+   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); -   WAIT_FOR_RFCSR(rt2x00dev, reg);+   WAIT_FOR_RFCSR(rt2x00dev, reg);+   }+   break;    } *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);@@ -198,6 +253,12 @@    mutex_unlock(rt2x00dev-csr_mutex); } use call*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);for both case - default and mt7620. I call*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);for mt7620 :) 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8gDlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto detect not working yet). AFAIK asus rt-n14u use the same. ---serge ___
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-06-29 Thread Roman Yeryomin
On 29 June 2014 16:33, Сергей Василюгин vasilu...@yandex.ru wrote:


 29.06.2014, 18:33, Roman Yeryomin leroi.li...@gmail.com:

 On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote:

  26.06.2014, 06:03, Daniel dan...@makrotopia.org:

  Hi Roman,

  On 04/04/2014 04:39 PM, Roman Yeryomin wrote:

   I worked on other things lately but plan to return to rt2x00 soon and
   maybe try ralink driver on trunk again.

  I started looking into your patches and started to see things moving as far
  as
  you got.
  I suggest to define RT6352 and set chip.rt to that instead of checking for
  chip.rf == RF7620 in cases which were meant for RT5390.
  Is there any more recent version of your work on rt2x00 than the
  630-rt2x00-add-mt7620-20140131.patch included in your first post? If so,
  please
  share it, I'd like to re-use what ever there is and try to botch things up
 a
  bit ;)

  Cheers


  Daniel

  After some attempts tonight I make working version of the patch. But my
  trunk revision really very old and I need time to rebase it.
  The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So
  *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
  instead of
  *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
  broke all rf reading.

 Honestly that sounds weird because unless you change all the other
 masks for mt7620 you will have them overlapped.
 Also this is how that register is described in datasheet (the fields
 are in reverse order comparing to all other socs).
 If you say you got it working can you send at least binary image to
 test (while you are trying to rebase it)?

 Regards,
 Roman

 1. As my friends say - let me show :)
 Your recently sent patch:

 static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
   const unsigned int word, u8 *value)
  {
 @@ -182,15 +221,31 @@
  * doesn't become available in time, reg will be 0x
  * which means we return 0xff to the caller.
  */
 -   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
 -   reg = 0;
 -   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
 -   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
 -   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);
 +   switch (rt2x00dev-chip.rf) {
 +   case RF7620:
 +   if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) {
 +   reg = 0;
 +   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620,
 word);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620,
 0);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1);
 +
 +   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
 reg);
 +
 +   WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg);
 +   }
 +   break;
 +   default:
 +   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
 +   reg = 0;
 +   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);

 -   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
 +   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
 reg);

 -   WAIT_FOR_RFCSR(rt2x00dev, reg);
 +   WAIT_FOR_RFCSR(rt2x00dev, reg);
 +   }
 +   break;
 }

 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
 @@ -198,6 +253,12 @@
 mutex_unlock(rt2x00dev-csr_mutex);
  }

 use call
 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
 for both case - default and mt7620. I call
 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
 for mt7620 :)

 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8g
 Dlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto
 detect not working yet). AFAIK asus rt-n14u use the same.


Sorry, I've read your previous email wrong.
By looking at the code seems you are right! I can't believe I've
missed that line before! I will look - maybe I kept the old tree I was
experimenting with.
BTW, I don't know why but your image for rt-n14u didn't work for me -
even ethernet is not working.

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-06-29 Thread xf...@credosemi.com
hi,

as I know, wrt get MAC address from some mtd partition, if it got all 0xff,the 
ethernet will not boot up. for more details just check the dts file for rt-n14u.

Alex Guo 

Roman Yeryomin leroi.li...@gmail.com编写:

On 29 June 2014 16:33, Сергей Василюгин vasilu...@yandex.ru wrote:


 29.06.2014, 18:33, Roman Yeryomin leroi.li...@gmail.com:

 On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote:

  26.06.2014, 06:03, Daniel dan...@makrotopia.org:

  Hi Roman,

  On 04/04/2014 04:39 PM, Roman Yeryomin wrote:

   I worked on other things lately but plan to return to rt2x00 soon and
   maybe try ralink driver on trunk again.

  I started looking into your patches and started to see things moving as far
  as
  you got.
  I suggest to define RT6352 and set chip.rt to that instead of checking for
  chip.rf == RF7620 in cases which were meant for RT5390.
  Is there any more recent version of your work on rt2x00 than the
  630-rt2x00-add-mt7620-20140131.patch included in your first post? If so,
  please
  share it, I'd like to re-use what ever there is and try to botch things up
 a
  bit ;)

  Cheers


  Daniel

  After some attempts tonight I make working version of the patch. But my
  trunk revision really very old and I need time to rebase it.
  The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So
  *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
  instead of
  *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
  broke all rf reading.

 Honestly that sounds weird because unless you change all the other
 masks for mt7620 you will have them overlapped.
 Also this is how that register is described in datasheet (the fields
 are in reverse order comparing to all other socs).
 If you say you got it working can you send at least binary image to
 test (while you are trying to rebase it)?

 Regards,
 Roman

 1. As my friends say - let me show :)
 Your recently sent patch:

 static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,
   const unsigned int word, u8 *value)
  {
 @@ -182,15 +221,31 @@
  * doesn't become available in time, reg will be 0x
  * which means we return 0xff to the caller.
  */
 -   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
 -   reg = 0;
 -   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
 -   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
 -   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);
 +   switch (rt2x00dev-chip.rf) {
 +   case RF7620:
 +   if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) {
 +   reg = 0;
 +   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620,
 word);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620,
 0);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1);
 +
 +   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
 reg);
 +
 +   WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg);
 +   }
 +   break;
 +   default:
 +   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) {
 +   reg = 0;
 +   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0);
 +   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1);

 -   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg);
 +   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG,
 reg);

 -   WAIT_FOR_RFCSR(rt2x00dev, reg);
 +   WAIT_FOR_RFCSR(rt2x00dev, reg);
 +   }
 +   break;
 }

 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
 @@ -198,6 +253,12 @@
 mutex_unlock(rt2x00dev-csr_mutex);
  }

 use call
 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);
 for both case - default and mt7620. I call
 *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);
 for mt7620 :)

 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8g
 Dlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto
 detect not working yet). AFAIK asus rt-n14u use the same.


Sorry, I've read your previous email wrong.
By looking at the code seems you are right! I can't believe I've
missed that line before! I will look - maybe I kept the old tree I was
experimenting with.
BTW, I don't know why but your image for rt-n14u didn't work for me -
even ethernet is not working.

Regards,
Roman
___
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-06-29 Thread Сергей Василюгин
  30.06.2014, 08:28, "xf...@credosemi.com" xf...@credosemi.com:hi,as I know, wrt get MAC address from some mtd partition, if it got all 0xff,the ethernet will not boot up. for more details just check the dts file for rt-n14u.Alex Guo Roman Yeryomin leroi.li...@gmail.com编写:On 29 June 2014 16:33, Сергей Василюгин vasilu...@yandex.ru wrote: 29.06.2014, 18:33, "Roman Yeryomin" leroi.li...@gmail.com: On 28 June 2014 19:17, Сергей Василюгин vasilu...@yandex.ru wrote:  26.06.2014, 06:03, "Daniel" dan...@makrotopia.org:  Hi Roman,  On 04/04/2014 04:39 PM, Roman Yeryomin wrote:   I worked on other things lately but plan to return to rt2x00 soon and   maybe try ralink driver on trunk again.  I started looking into your patches and started to see things moving as far  as  you got.  I suggest to define RT6352 and set chip.rt to that instead of checking for  chip.rf == RF7620 in cases which were meant for RT5390.  Is there any more recent version of your work on rt2x00 than the  630-rt2x00-add-mt7620-20140131.patch included in your first post? If so,  please  share it, I'd like to re-use what ever there is and try to botch things up a  bit ;)  Cheers  Daniel  After some attempts tonight I make working version of the patch. But my  trunk revision really very old and I need time to rebase it.  The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So  *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);  instead of  *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);  broke all rf reading. Honestly that sounds weird because unless you change all the other masks for mt7620 you will have them overlapped. Also this is how that register is described in datasheet (the fields are in reverse order comparing to all other socs). If you say you got it working can you send at least binary image to test (while you are trying to rebase it)? Regards, Roman 1. As my friends say - let me show :) Your recently sent patch: static void rt2800_rfcsr_read(struct rt2x00_dev *rt2x00dev,   const unsigned int word, u8 *value)  { @@ -182,15 +221,31 @@  * doesn't become available in time, reg will be 0x  * which means we return 0xff to the caller.  */ -   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) { -   reg = 0; -   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word); -   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0); -   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1); +   switch (rt2x00dev-chip.rf) { +   case RF7620: +   if (WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg)) { +   reg = 0; +   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM_MT7620, word); +   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE_MT7620, 0); +   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY_MT7620, 1); + +   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); + +   WAIT_FOR_RFCSR_MT7620(rt2x00dev, reg); +   } +   break; +   default: +   if (WAIT_FOR_RFCSR(rt2x00dev, reg)) { +   reg = 0; +   rt2x00_set_field32(reg, RF_CSR_CFG_REGNUM, word); +   rt2x00_set_field32(reg, RF_CSR_CFG_WRITE, 0); +   rt2x00_set_field32(reg, RF_CSR_CFG_BUSY, 1); -   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); +   rt2800_register_write_lock(rt2x00dev, RF_CSR_CFG, reg); -   WAIT_FOR_RFCSR(rt2x00dev, reg); +   WAIT_FOR_RFCSR(rt2x00dev, reg); +   } +   break; } *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); @@ -198,6 +253,12 @@ mutex_unlock(rt2x00dev-csr_mutex);  } use call *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA); for both case - default and mt7620. I call *value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620); for mt7620 :) 2. Binary images: https://yadi.sk/d/OeTxrigZVMg8g Dlink dir620f1 is my test board (pkg_id=0, chip_ver=2, eco_num=3 - auto detect not working yet). AFAIK asus rt-n14u use the same.Sorry, I've read your previous email wrong.By looking at the code seems you are right! I can't believe I'vemissed that line before! I will look - maybe I kept the old tree I wasexperimenting with.BTW, I don't know why but your image for rt-n14u didn't work for me -even ethernet is not working.Regards,Roman___openwrt-devel mailing listopenwrt-devel@lists.openwrt.orghttps://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel It's a possible solution. My board haveethernet@1010 {        mtd-mac-address = factory 0x4;        ralink,port-map = "w";    };I'll rebuild images tonight for test. ---serge ___
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-06-28 Thread Сергей Василюгин
  26.06.2014, 06:03, "Daniel" dan...@makrotopia.org:Hi Roman,On 04/04/2014 04:39 PM, Roman Yeryomin wrote: I worked on other things lately but plan to return to rt2x00 soon and maybe try ralink driver on trunk again.I started looking into your patches and started to see things moving as far asyou got.I suggest to define RT6352 and set chip.rt to that instead of checking forchip.rf == RF7620 in cases which were meant for RT5390.Is there any more recent version of your work on rt2x00 than the630-rt2x00-add-mt7620-20140131.patch included in your first post? If so, pleaseshare it, I'd like to re-use what ever there is and try to botch things up a bit ;)CheersDanielAfter some attempts tonight I make working version of the patch. But my trunk revision really very old and I need time to rebase it.The key error was in rt2800_rfcsr_read for RF7620 (wrong bitmask). So*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA);instead of*value = rt2x00_get_field32(reg, RF_CSR_CFG_DATA_MT7620);broke all rf reading.  Good luck! ---serge ___
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-06-25 Thread Daniel
Hi Roman,

On 04/04/2014 04:39 PM, Roman Yeryomin wrote:
 I worked on other things lately but plan to return to rt2x00 soon and
 maybe try ralink driver on trunk again.

I started looking into your patches and started to see things moving as far as
you got.
I suggest to define RT6352 and set chip.rt to that instead of checking for
chip.rf == RF7620 in cases which were meant for RT5390.
Is there any more recent version of your work on rt2x00 than the
630-rt2x00-add-mt7620-20140131.patch included in your first post? If so, please
share it, I'd like to re-use what ever there is and try to botch things up a 
bit ;)

Cheers


Daniel
___
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-04-04 Thread Roman Yeryomin
On 4 April 2014 00:06, Michel Stempin michel.stem...@wanadoo.fr wrote:


 Le 03/04/2014 22:52, John Crispin a écrit :


 On 03/04/2014 22:04, Michel Stempin wrote:
 Does anybody can explain what is the official mt7620 support status
 in OpenWrt?

 working fully apart of wifi and i2s

   John
 Ok, thanks John for this clarification!

 But where does this Chinese OpenWrt PandoraBox version comes from?


That one uses original ralink driver and is based on AA. I've tried
using ralink driver with latest trunk few weeks ago but stuck with
interrupts not enabled for wifi.
I worked on other things lately but plan to return to rt2x00 soon and
maybe try ralink driver on trunk again.

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-04-03 Thread Michel Stempin


Le 19/03/2014 23:22, Michel Stempin a écrit :
 
 
 Le 15/02/2014 12:02, Roman Yeryomin a écrit :
 On 14 February 2014 20:43, Mikko Hissa mikko.hi...@werzek.com wrote:

 On 14 Feb 2014, at 01:04, Roman Yeryomin leroi.li...@gmail.com wrote:

 On 14 February 2014 00:34, Mikko Hissa mikko.hi...@werzek.com 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;

 You are right, it's 5 and 6 words - I misread the datasheet. Also
 seems there is a typo first stating txwi is 4 words but describing 5
 below.
 Anyway I tried txwi 5 and rxwi 6 and results are the same.

 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().


 Ook.. I'll try to separate and clean that.
 
 Any news regarding the MT7620 WiFi?
 
 Regards,
 Michel

There is nowadays a lot of OpenWrt-based code featuring MT7620 WiFi flourishing 
on the Web:

http://downloads.openwrt.org.cn/PandoraBox/ralink/mt7620/packages/
https://github.com/qdk0901/openwrt-mt7620
https://app.box.com/s/fqmmhqyykyw63350cpg1

Especially regarding the first link which looks like it is coming directly from 
the Chinese OpenWrt developers, what is the exact status of these files?

Digging into the sources, you find some blobs and/or prominent copyright 
notices that make me dubious about their legality...

Does anybody can explain what is the official mt7620 support status in OpenWrt?

Regards,
Michel

 ___
 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-04-03 Thread John Crispin


On 03/04/2014 22:04, Michel Stempin wrote:
 Does anybody can explain what is the official mt7620 support status
 in OpenWrt?

working fully apart of wifi and i2s

John
___
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-04-03 Thread Michel Stempin


Le 03/04/2014 22:52, John Crispin a écrit :
 
 
 On 03/04/2014 22:04, Michel Stempin wrote:
 Does anybody can explain what is the official mt7620 support status
 in OpenWrt?
 
 working fully apart of wifi and i2s
 
   John
Ok, thanks John for this clarification!

But where does this Chinese OpenWrt PandoraBox version comes from?

Michel
___
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-03-19 Thread Michel Stempin


Le 15/02/2014 12:02, Roman Yeryomin a écrit :
 On 14 February 2014 20:43, Mikko Hissa mikko.hi...@werzek.com wrote:

 On 14 Feb 2014, at 01:04, Roman Yeryomin leroi.li...@gmail.com wrote:

 On 14 February 2014 00:34, Mikko Hissa mikko.hi...@werzek.com 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;
 
 You are right, it's 5 and 6 words - I misread the datasheet. Also
 seems there is a typo first stating txwi is 4 words but describing 5
 below.
 Anyway I tried txwi 5 and rxwi 6 and results are the same.
 
 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().

 
 Ook.. I'll try to separate and clean that.

Any news regarding the MT7620 WiFi?

Regards,
Michel
___
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-15 Thread Roman Yeryomin
On 14 February 2014 20:43, Mikko Hissa mikko.hi...@werzek.com wrote:

 On 14 Feb 2014, at 01:04, Roman Yeryomin leroi.li...@gmail.com wrote:

 On 14 February 2014 00:34, Mikko Hissa mikko.hi...@werzek.com 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;

You are right, it's 5 and 6 words - I misread the datasheet. Also
seems there is a typo first stating txwi is 4 words but describing 5
below.
Anyway I tried txwi 5 and rxwi 6 and results are the same.

 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().


Ook.. I'll try to separate and clean that.


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 Roman Yeryomin
On 14 February 2014 01:30, Mikko Hissa mikko.hi...@werzek.com wrote:

 On 14 Feb 2014, at 01:04, Roman Yeryomin leroi.li...@gmail.com wrote:

 On 14 February 2014 00:34, Mikko Hissa mikko.hi...@werzek.com 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.

I used the one from SDK (which is known to be working) and just placed
it in /lib/firmware/.
But RT comes from ASIC_REG_ID register, not eeprom.

Regards,
Roman


soc_wmac.eeprom
Description: Binary data
___
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 leroi.li...@gmail.com wrote:

 On 14 February 2014 00:34, Mikko Hissa mikko.hi...@werzek.com 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] [RFC] mt7620 wifi

2014-02-13 Thread Roman Yeryomin
On 13 February 2014 16:37, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 11 February 2014 20:32, Mikko Hissa mikko.hi...@werzek.com wrote:
 Hello again!

 On 11 Feb 2014, at 19:12, Mikko Hissa mikko.hi...@werzek.com wrote:

 Hello!

 On 01 Feb 2014, at 02:08, Roman Yeryomin leroi.li...@gmail.com 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(reg, 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?


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
Hi!

On 13 Feb 2014, at 18:56, Roman Yeryomin leroi.li...@gmail.com wrote:

 On 13 February 2014 16:37, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 11 February 2014 20:32, Mikko Hissa mikko.hi...@werzek.com wrote:
 Hello again!
 
 On 11 Feb 2014, at 19:12, Mikko Hissa mikko.hi...@werzek.com wrote:
 
 Hello!
 
 On 01 Feb 2014, at 02:08, Roman Yeryomin leroi.li...@gmail.com 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(reg, 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 Roman Yeryomin
On 13 February 2014 21:32, Mikko Hissa mikko.hi...@werzek.com wrote:
 On 01 Feb 2014, at 02:08, Roman Yeryomin leroi.li...@gmail.com 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(reg, 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...

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 Roman Yeryomin
On 13 February 2014 22:45, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 13 February 2014 21:32, Mikko Hissa mikko.hi...@werzek.com wrote:
 On 01 Feb 2014, at 02:08, Roman Yeryomin leroi.li...@gmail.com 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(reg, 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.

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 leroi.li...@gmail.com wrote:

 On 13 February 2014 22:45, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 13 February 2014 21:32, Mikko Hissa mikko.hi...@werzek.com wrote:
 On 01 Feb 2014, at 02:08, Roman Yeryomin leroi.li...@gmail.com 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(reg, 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 Roman Yeryomin
On 14 February 2014 00:14, Mikko Hissa mikko.hi...@werzek.com wrote:
 On 13 Feb 2014, at 23:44, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 13 February 2014 22:45, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 13 February 2014 21:32, Mikko Hissa mikko.hi...@werzek.com wrote:
 On 01 Feb 2014, at 02:08, Roman Yeryomin leroi.li...@gmail.com 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(reg, 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?

The board doesn't have PA/LNAs (at least I don't seem them). And yes,
eeprom indicates their presence as far as I know.
Radio seems to be alive (also interrupts and tx counter are telling that):

root@OpenWrt:/# iw wlan0 survey dump
Survey data from wlan0
frequency:  2462 MHz [in use]
channel active time:3673 ms
channel busy time:  267 ms
extension channel busy time:0 ms


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 helmut.sc...@googlemail.com wrote:

 On Tue, Feb 4, 2014 at 4:40 PM, Roman Yeryomin leroi.li...@gmail.com wrote:
 Thanks for answer, Helmut!
 
 On 3 February 2014 18:01, Helmut Schaa helmut.sc...@googlemail.com wrote:
 On Sat, Feb 1, 2014 at 1:08 AM, Roman Yeryomin leroi.li...@gmail.com 
 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 Roman Yeryomin
On 14 February 2014 00:34, Mikko Hissa mikko.hi...@werzek.com 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.

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 14 Feb 2014, at 01:04, Roman Yeryomin leroi.li...@gmail.com wrote:

 On 14 February 2014 00:34, Mikko Hissa mikko.hi...@werzek.com 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-11 Thread Mikko Hissa
Hello!

On 01 Feb 2014, at 02:08, Roman Yeryomin leroi.li...@gmail.com 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(reg, 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 mikko.hi...@werzek.com wrote:

 Hello!
 
 On 01 Feb 2014, at 02:08, Roman Yeryomin leroi.li...@gmail.com 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(reg, 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-06 Thread Roman Yeryomin
On 5 February 2014 09:21, Helmut Schaa helmut.sc...@googlemail.com wrote:
 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?

 Yes, from rt2860v2 2.7.1.6 to be precise.
 Yes I did the mac registers init too. There are several new registers
 they initialize. I tried to integrate mac init to the existing
 function. Do you think I should try to do it separately?

 No, should be fine that way (for testing) I guess.

 Did you check if the interrupt handler is called after setting the
 device up (/proc/interrupts)?
 Just as a first evidence of life?

 Hmm..
 If I configure it as ap, yes:
CPU0
   5: 28  MIPS  1010.ethernet
   6:  38912  MIPS  rt2800_wmac
   7: 204558  MIPS  timer
   9:  0  INTC  1100.timer
  20:521  INTC  serial
  25:  2  INTC  gsw
 ERR:  0

 Good, so at least something happens :D
 Might make sense to add some code to the interrupt handler to see
 which interrupts get fired.

Do you mean plat_irq_dispatch() from arch/mips/ralink/irq.c ?

 But if I put it in monitor mode (either via config or iw command)
 interrupt counter remains zero. What does it mean?

 So, it seems as if the RX path is not working at all. But that can have
 several reasons ...

 Did you check with a second wifi device if the card transmits any
 frames in AP mode?
 Beacons?

Only with android tablet with wifi scanner. Do you think I should try
a better scanner (kismet?) ?

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-06 Thread Helmut Schaa
On Thu, Feb 6, 2014 at 11:40 AM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 5 February 2014 09:21, Helmut Schaa helmut.sc...@googlemail.com wrote:
 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?

 Yes, from rt2860v2 2.7.1.6 to be precise.
 Yes I did the mac registers init too. There are several new registers
 they initialize. I tried to integrate mac init to the existing
 function. Do you think I should try to do it separately?

 No, should be fine that way (for testing) I guess.

 Did you check if the interrupt handler is called after setting the
 device up (/proc/interrupts)?
 Just as a first evidence of life?

 Hmm..
 If I configure it as ap, yes:
CPU0
   5: 28  MIPS  1010.ethernet
   6:  38912  MIPS  rt2800_wmac
   7: 204558  MIPS  timer
   9:  0  INTC  1100.timer
  20:521  INTC  serial
  25:  2  INTC  gsw
 ERR:  0

 Good, so at least something happens :D
 Might make sense to add some code to the interrupt handler to see
 which interrupts get fired.

 Do you mean plat_irq_dispatch() from arch/mips/ralink/irq.c ?

I thought about rt2800mmio_interrupt.

 But if I put it in monitor mode (either via config or iw command)
 interrupt counter remains zero. What does it mean?

 So, it seems as if the RX path is not working at all. But that can have
 several reasons ...

 Did you check with a second wifi device if the card transmits any
 frames in AP mode?
 Beacons?

 Only with android tablet with wifi scanner. Do you think I should try
 a better scanner (kismet?) ?

Just use a second linux machine with a reasonable wifi card (ath9k
will do for example),
put it into monitor mode and run tcpdump/wireshark on it ...

Helmut
___
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-06 Thread Roman Yeryomin
On 6 February 2014 13:01, Helmut Schaa helmut.sc...@googlemail.com wrote:
 On Thu, Feb 6, 2014 at 11:40 AM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 5 February 2014 09:21, Helmut Schaa helmut.sc...@googlemail.com wrote:
 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?

 Yes, from rt2860v2 2.7.1.6 to be precise.
 Yes I did the mac registers init too. There are several new registers
 they initialize. I tried to integrate mac init to the existing
 function. Do you think I should try to do it separately?

 No, should be fine that way (for testing) I guess.

 Did you check if the interrupt handler is called after setting the
 device up (/proc/interrupts)?
 Just as a first evidence of life?

 Hmm..
 If I configure it as ap, yes:
CPU0
   5: 28  MIPS  1010.ethernet
   6:  38912  MIPS  rt2800_wmac
   7: 204558  MIPS  timer
   9:  0  INTC  1100.timer
  20:521  INTC  serial
  25:  2  INTC  gsw
 ERR:  0

 Good, so at least something happens :D
 Might make sense to add some code to the interrupt handler to see
 which interrupts get fired.

 Do you mean plat_irq_dispatch() from arch/mips/ralink/irq.c ?

 I thought about rt2800mmio_interrupt.

then it's these two:
INT_SOURCE_CSR_TBTT
INT_SOURCE_CSR_PRE_TBTT

 But if I put it in monitor mode (either via config or iw command)
 interrupt counter remains zero. What does it mean?

 So, it seems as if the RX path is not working at all. But that can have
 several reasons ...

 Did you check with a second wifi device if the card transmits any
 frames in AP mode?
 Beacons?

 Only with android tablet with wifi scanner. Do you think I should try
 a better scanner (kismet?) ?

 Just use a second linux machine with a reasonable wifi card (ath9k
 will do for example),
 put it into monitor mode and run tcpdump/wireshark on it ...

I will check it little bit later today.

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-06 Thread Roman Yeryomin
On 6 February 2014 13:27, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 6 February 2014 13:01, Helmut Schaa helmut.sc...@googlemail.com wrote:
 On Thu, Feb 6, 2014 at 11:40 AM, Roman Yeryomin leroi.li...@gmail.com 
 wrote:
 On 5 February 2014 09:21, Helmut Schaa helmut.sc...@googlemail.com wrote:
 Did you check with a second wifi device if the card transmits any
 frames in AP mode?
 Beacons?

 Only with android tablet with wifi scanner. Do you think I should try
 a better scanner (kismet?) ?

 Just use a second linux machine with a reasonable wifi card (ath9k
 will do for example),
 put it into monitor mode and run tcpdump/wireshark on it ...

 I will check it little bit later today.

So, no, I couldn't catch any frames in the air with this (in monitor mode):
tcpdump -i wlan0 -X ether src mt7620 mac

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-04 Thread Roman Yeryomin
Thanks for answer, Helmut!

On 3 February 2014 18:01, Helmut Schaa helmut.sc...@googlemail.com wrote:
 On Sat, Feb 1, 2014 at 1:08 AM, Roman Yeryomin leroi.li...@gmail.com 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.

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-04 Thread Helmut Schaa
On Tue, Feb 4, 2014 at 4:40 PM, Roman Yeryomin leroi.li...@gmail.com wrote:
 Thanks for answer, Helmut!

 On 3 February 2014 18:01, Helmut Schaa helmut.sc...@googlemail.com wrote:
 On Sat, Feb 1, 2014 at 1:08 AM, Roman Yeryomin leroi.li...@gmail.com 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?

helmut
___
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-04 Thread Roman Yeryomin
On 4 February 2014 17:56, Helmut Schaa helmut.sc...@googlemail.com wrote:
 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?

Yes, from rt2860v2 2.7.1.6 to be precise.
Yes I did the mac registers init too. There are several new registers
they initialize. I tried to integrate mac init to the existing
function. Do you think I should try to do it separately?

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-04 Thread Helmut Schaa
On Tue, Feb 4, 2014 at 5:19 PM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 4 February 2014 17:56, Helmut Schaa helmut.sc...@googlemail.com wrote:
 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?

 Yes, from rt2860v2 2.7.1.6 to be precise.
 Yes I did the mac registers init too. There are several new registers
 they initialize. I tried to integrate mac init to the existing
 function. Do you think I should try to do it separately?

No, should be fine that way (for testing) I guess.

Did you check if the interrupt handler is called after setting the
device up (/proc/interrupts)?
Just as a first evidence of life?
___
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-04 Thread Roman Yeryomin
On 4 February 2014 19:58, Helmut Schaa helmut.sc...@googlemail.com wrote:
 On Tue, Feb 4, 2014 at 5:19 PM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 4 February 2014 17:56, Helmut Schaa helmut.sc...@googlemail.com wrote:
 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?

 Yes, from rt2860v2 2.7.1.6 to be precise.
 Yes I did the mac registers init too. There are several new registers
 they initialize. I tried to integrate mac init to the existing
 function. Do you think I should try to do it separately?

 No, should be fine that way (for testing) I guess.

 Did you check if the interrupt handler is called after setting the
 device up (/proc/interrupts)?
 Just as a first evidence of life?

Hmm..
If I configure it as ap, yes:
   CPU0
  5: 28  MIPS  1010.ethernet
  6:  38912  MIPS  rt2800_wmac
  7: 204558  MIPS  timer
  9:  0  INTC  1100.timer
 20:521  INTC  serial
 25:  2  INTC  gsw
ERR:  0

But if I put it in monitor mode (either via config or iw command)
interrupt counter remains zero. What does it mean?
All done with reboots to reset the counter.

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-04 Thread Helmut Schaa
On Tue, Feb 4, 2014 at 8:24 PM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 4 February 2014 19:58, Helmut Schaa helmut.sc...@googlemail.com wrote:
 On Tue, Feb 4, 2014 at 5:19 PM, Roman Yeryomin leroi.li...@gmail.com wrote:
 On 4 February 2014 17:56, Helmut Schaa helmut.sc...@googlemail.com wrote:
 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?

 Yes, from rt2860v2 2.7.1.6 to be precise.
 Yes I did the mac registers init too. There are several new registers
 they initialize. I tried to integrate mac init to the existing
 function. Do you think I should try to do it separately?

 No, should be fine that way (for testing) I guess.

 Did you check if the interrupt handler is called after setting the
 device up (/proc/interrupts)?
 Just as a first evidence of life?

 Hmm..
 If I configure it as ap, yes:
CPU0
   5: 28  MIPS  1010.ethernet
   6:  38912  MIPS  rt2800_wmac
   7: 204558  MIPS  timer
   9:  0  INTC  1100.timer
  20:521  INTC  serial
  25:  2  INTC  gsw
 ERR:  0

Good, so at least something happens :D
Might make sense to add some code to the interrupt handler to see
which interrupts get fired.

 But if I put it in monitor mode (either via config or iw command)
 interrupt counter remains zero. What does it mean?

So, it seems as if the RX path is not working at all. But that can have
several reasons ...

Did you check with a second wifi device if the card transmits any
frames in AP mode?
Beacons?

Helmut
___
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-03 Thread Helmut Schaa
Hi,

On Sat, Feb 1, 2014 at 1:08 AM, Roman Yeryomin leroi.li...@gmail.com 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).

Yep, there are no documents out there as far as I know :/

 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).
Helmut
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel