rt73 on ARM

nerochiaro · **Joined:** Tue Apr 03, 2007 4:07 pm **Posts:** 18

Hi,
i'm trying to setup an ARM9-based device to use an Asus WL-167G dongle (based on rt73).

To run it on the ARM I cross-compiled the r73 legacy driver from the "rt73 USB nightly CVS tarball" from the downloads page.
If this is the wrong driver, please let me know (however the dongle works fine with this driver on a PC running ubuntu edgy, so i guess it's the right one).

The cross compile seems to go ok, I get the rt73.ko module and use insmod to load it on the ARM. I get this:

Code:

~ # insmod rt73
Loading Module /lib/modules/2.6.15/extra/rt73.ko
rtusb init ====>
idVendor = 0xb05, idProduct = 0x1723 
usbcore: registered new driver rt73

So it seems to load just fine. And iwconfig seems to see it too:

Code:

~ # /usr/local/bin/iwconfig
rausb0    RT73 WLAN  
Link Quality:0  Signal level:0  Noise level:113
Rx invalid nwid:0  invalid crypt:0  invalid misc:0

However when I try to do actually use it i get the following error:

Code:

~ # /usr/local/bin/iwconfig rausb0 essid something
Error for wireless request "Set ESSID" (8B1A) :
SET failed on device rausb0 ; Network is down.

The same thing happens if I "ifconfig rausb0 up" before trying that (I mention this because someone suggested that i should up the interface before using iwconfig, i'm not sure it makes sense).

So, anyone can see what I am doing wrong or has suggestions ?
Am I missing something obvious ?

Thanks,
--
nero

mykhal · **Joined:** Tue Mar 06, 2007 12:43 am **Posts:** 4

did you try e.g. "ifconfig rausb0 inet 10.10.10.69 netmask 255.255.255.0 up" ?

nerochiaro · **Joined:** Tue Apr 03, 2007 4:07 pm **Posts:** 18

mykhal wrote:

did you try e.g. "ifconfig rausb0 inet 10.10.10.69 netmask 255.255.255.0 up" ?

Yes, and no luck. I still get the same error message when using iwconfig.

I also noticed that if i try to bring down the interface with ifconfig, the kernel module crashes.
You can see the log of such a session with final crash in the attached file.

serialmonkey · **Posted:** Tue Apr 03, 2007 11:30 pm

What version of the wireless extensions are you using ?

iwconfig -version

nerochiaro · **Joined:** Tue Apr 03, 2007 4:07 pm **Posts:** 18

serialmonkey wrote:

What version of the wireless extensions are you using ? iwconfig -version

Code:

~ # /usr/local/bin/iwconfig --version 
iwconfig  Wireless-Tools version 28
Compatible with Wireless Extension v11 to v20.
Kernel Currently compiled with Wireless Extension v19.

~ # uname -a
Linux neuros 2.6.15 #2 PREEMPT Tue Apr 3 16:34:50 CEST 2007 armv5tejl unknown

I added kernel version in case you need it too.

serialmonkey · **Posted:** Thu Apr 05, 2007 1:26 am

Afraid it just doesn't appear the device is getting initialised properly. Can you compile with debug enabled and show us the output ?

idamlaj · **Posted:** Mon Apr 09, 2007 2:00 pm

Or just load the driver with the debug parameter set to 2:

Code:

modprobe rt73 debug=2

nerochiaro · **Joined:** Tue Apr 03, 2007 4:07 pm **Posts:** 18

idamlaj wrote:

Or just load the driver with the debug parameter set to 2:

Code:

modprobe rt73 debug=2

I both compiled the module with debug and loaded it with debug=2. Here's what happens.

Code:

~ # insmod rt73 debug=2
Loading Module /lib/modules/2.6.15/extra/rt73.ko
rtusb init ====>
idVendor = 0xb05, idProduct = 0x1723 
**RT2573**<7>usb device name rausb0
**RT2573**<7>BulkOutMaxPacketSize  64
**RT2573**<7>rt73_get_ether_stats --->
usbcore: registered new driver rt73
~ # ifconfig rausb0 inet 192.168.1.77 netmask 255.0.0.0  up
rt73 driver version - 1.0.3.6 CVS
**RT2573**<7>--> PortCfgInit
**RT2573**<7><-- PortCfgInit
**RT2573**<7>--> RTMPInitAdapterBlock
**RT2573**<7><-- RTMPInitAdapterBlock
**RT2573**<7>--> NICInitTransmit
**RT2573**<7>--> NICInitRecv
**RT2573**<7>Not enough memory
**RT2573**<7><-- NICInitRecv
**RT2573**<7>---> ReleaseAdapter
**RT2573**<7><--- ReleaseAdapter
**RT2573**<7>rt73_get_ether_stats --->
**RT2573**<7>rt73_get_ether_stats --->

So it seems it runs out of memory while allocating pRxContext->TransferBuffer in NICInitRecv in rtmp_init.c.
I tried to lower the amount of memory of that specific call to kmalloc to ridiculously small levels, but it always fails.

Just for experiment I tried to comment out altogether the allocation of the various transmit buffers in NICInitTransmit (which is called before NICInitRecv). I thought that since the kmallocs in NICInitTransmit didn't error skipping them would've left usable memory for the one in NICInitRecv.

But no, instead it still fails.

This seems a bit strange to me. Am I missing something ?
Thanks
--
nero

serialmonkey · **Posted:** Wed Apr 11, 2007 3:28 pm

Afraid I can't reproduce this on my ARM setup. I agree, it's very odd you are getting memory errors on that call.

nerochiaro · **Joined:** Tue Apr 03, 2007 4:07 pm **Posts:** 18

serialmonkey wrote:

Afraid I can't reproduce this on my ARM setup. I agree, it's very odd you are getting memory errors on that call.

I think I found out how to at least bypass the problem. It looks like the only kmalloc calls that fail are those that have MEM_ALLOC_FLAG as second argument to kmalloc. That is, they require GFP_DMA | GFP_ATOMIC memory.

Taking away the GFP_DMA requirement allows the memory to be allocated and kmalloc to return successfuly and the driver sort of works.

Why only the receive buffers use GFP_DMA | GFP_ATOMIC and the transmit buffers use just GFP_KERNEL ?
Is DMA really required for these receive buffers ?
I'm not really an expert here, so i'm actually curious.

Also it might be that this is not the right fix, since the drivers seems to be having continuous failures in lots calls to RTUSB_VendorRequest (they all return -110 on calls to usb_control_msg).
Any ideas why this might happen or it's related to the memory allocation issue above ?

serialmonkey · **Posted:** Tue Apr 17, 2007 10:36 am

Afraid I can't really comment, that memory design was done by Ralink and we have never fully been able to understand it - hence why we rewrote it from scratch in rt2x00

nerochiaro · **Joined:** Tue Apr 03, 2007 4:07 pm **Posts:** 18

serialmonkey wrote:

Afraid I can't really comment, that memory design was done by Ralink and we have never fully been able to understand it - hence why we rewrote it from scratch in rt2x00

Speaking of rt2x00, I would surely prefer to use it, since being you the authors, the support will be surely better.

But we can't move to a 2.6.17 for now. is there any way to make it work on a 2.6.15 kernel ?

IvD · **Posted:** Tue Apr 17, 2007 11:45 am

nerochiaro wrote:

is there any way to make it work on a 2.6.15 kernel ?

Not really, unless you want to spend a lot of time porting it.
Note that at the moment we already have serious problems bringing the latest mac80211 stack available for vanilla kernels...

chernwu · **Joined:** Thu Apr 19, 2007 2:50 pm **Posts:** 6

nerochiaro wrote:

To run it on the ARM I cross-compiled the r73 legacy driver from the "rt73 USB nightly CVS tarball" from the downloads page.

nero

can you tell me how did you cross-compiled it? i can't cross-compile it scesefully. can you give your code here? thanks very much.

nerochiaro · **Joined:** Tue Apr 03, 2007 4:07 pm **Posts:** 18

chernwu wrote:

nerochiaro wrote:

To run it on the ARM I cross-compiled the r73 legacy driver from the "rt73 USB nightly CVS tarball" from the downloads page.

nero

can you tell me how did you cross-compiled it? i can't cross-compile it scesefully. can you give your code here? thanks very much.

Ok, this is what I remember:

I put the contents of the Module directory into my arm 2.6.15 kernel tree under drivers/usb/net/rt73, then did the following to make it part of the kernel build:
- I added to the /drivers/usb/net/Kconfig to add an option to enable the rt73 module,
- Then edited the Makefile in /drivers/usb/net to have it build the subdir rt73 when the option above is active.
Then I ran the kernel menuconfig to actually enable that option.

Finally I edited the Makefile for the rt73 driver itself:
- put the right paths in KERNEL_SOURCE and MODULE_ROOT
- removed the calls to /sbin/depmod since we're not on the target system
- deleted the module and debug rules
- renamed arm rule to module and armdebug rule to debug

At this point doing make modules && make modules_install from the kernel root did the trick.
I'm not sure if this will be enough on your system. It worked for me.
Good luck !

rt2x00.serialmonkey.com

Forum rules

rt73 on ARM

Who is online