rt2870 cannot find firmware

Live forum: http://rt2x00.serialmonkey.com/viewtopic.php?t=6055

Yonaz

17-03-2010 19:00:29

Hi everyone,

I am having a problem with my Hama WLAN USB stick (with rt2870 chipset). I successfully downloaded and built the latest compat-wireless-2.6.33.tar.bz2 release. I put the rt2870.bin (version 8 ) that I got from the ralink page in the /lib/firmware directory, but when I restart the network, I get

SIOCSIFFLAGS No such file or directory

Further analyizing this with dmesg I get
[code295dtbuc]
udev: renamed network interface wlan0 to wlan1
rt2800usb 1-1:1.0: firmware requesting rt2870.bin
phy0 -> rt2x00lib_request_firmware: Error - Failed to request Firmware.
[/code295dtbuc]

I don't know, why it cannot find the firmware! Don't hesitate to post "stupid" suggestions. wink I am using gentoo with a self-built realtime kernel with version number 2.6.30.9, if that changes anything. Thanks in advance!

Cheers
Jonas

ChuckV

15-07-2010 00:29:43

We are using uClinux on an embedded system. I set my kernel config options to include the firmware in the kernel binary.

Device drivers -> Generic driver options
* Include in-kernel firmware blobs in kernel binary
(rt73.bin) External firmware blobs to build into the kernel binary

Replace rt73.bin with your firmware file.

IvD

15-07-2010 05:36:41

Or you could fix your udev configuration to read your /lib/firmware folder for the firmware.

steev

10-11-2010 23:17:55

I'm having the same problem here. It used to work, but now it does not. Not sure what changed or where, but when using rt2870sta from staging, and the v22 firmware named as rt3070.bin it works, although if i go out of range of wifi, I get a kernel panic. If I try any recent compat-wireless (started around september) it just tells me it cannot load the firmware, and I've tried copying it to rt2870.bin, rt2870, rt3070, and of course, the original is rt3070.bin. I've also tried building it in to the kernel, and I'm not sure what you mean about telling udev where /lib/firmware is. Could you expand on that? I've also tried the rt* files from the linux-firmware tree, but none of those load either. The one from Ralink's site is 8K, the one from the linux-firmware is 4k. The card itself is an rt2800usb device

lsusb reports
Bus 002 Device 004 ID 13d33273 IMC Networks
iManufacturer Ralink
iProduct 802.11 n WLAN
iSerial 1.0

Also, would it be possible to have it print out what the name is of the firmware it is looking for? That would definitely help. It prints out what one it loads, but not what it attempts to load. Thanks!

kcmon

11-11-2010 17:47:55

From what I have seen, the kernel uses udev to find and load the firmware. If you don't have udev, then whatever is handling your hotplug events is responsible for loading firmware. I have been using an ARM based embedded Linux system, and when I started playing around with wireless adapters, I needed to alter my hotplug script (since I don't have udev, we use a script for hotplug events) to load firmware. Documentation on doing this was found in kernel source tree at Documentation/firmware_class.

In summary, hotplug gets called with the command line argument "firmware" and a few environment variables set. I altered my hotplug script to trap that command line argument and load the firmware. However, recently I loaded compat-wireless on this board and found that I could no longer load firmware. After troubleshooting, I found that the compat-wireless drivers load firmware by sending "compat_firmware" as the command line argument to hotplug instead of "firmware". I altered hotplug to check for both "firmware" and "compat_firmware" and that corrected the problem.

The above may not apply to your problem as udev is supposed to take care of all of this for you, but I figured it was worth posting on the off chance that it may give you ideas to what the problem may be.

steev

12-11-2010 15:32:26

Thanks for the pointers kcmon, it definitely gave me something to look into. We are also using an ARM device, but we are also using almost a full Ubuntu Maverick install. I'm really at a loss at this point, but the whole compat_firmware supposed to be called instead of firmware might be the cause, I just haven't had time to look into it recently. I'll pass it on to someone else who is working on it though, and see if they have any luck.