[rt2x00-users] Ralink RT3060F (RT352/RF3020) radio issues
Gertjan van Wingerde
gwingerde at gmail.com
Tue Jul 24 06:14:42 AEST 2012
On 23 jul. 2012, at 20:45, Lucio Albornoz <l.illanes at gmx.de> wrote:
> On Mon, Jul 23, 2012 at 07:52:38PM +0200, Gertjan van Wingerde wrote:
>> To me it looks like an EEPROM problem, in the identification of the RF chipset.
> I rebuilt the Ralink and rt2x00 driver(s) each w/ every single possible RFIC combination hard-wired, as I've suspected this myself, unfortunately with negligible results:
> 1) The `rt3090_ap' driver has the Ralink chipset interrupt the CPU (PreTBTTInt, TBTTInt, and `INT_MGMT_DLY' during site surveys,) and report >0 `Tx success,' whereas
> 2) the latest Ralink driver doesn't seem to ever receive any Ralink chipset interrupts at all, likewise report >0 `Tx success', yet additionally report >0 `Rx with CRC' (but no `Rx success,') and
I cannot speak for the Ralink drivers, but given that they don't work either may mean there's something wrong with your hardware.
> 3) the `rt2x00' driver from `compat-wireless-2012-06-14' (with and without the patch supplied by Stanislaw Gruszka) simply and plainly doesn't work at all, for which I had to dd (1) my EEPROM image down to 272 bytes:
> [ 232.060000] phy1 -> rt2x00lib_request_eeprom_file: Info - Loading EEPROM data from 'RT2860.eeprom'.
> [ 232.120000] phy1 -> rt2x00lib_request_eeprom_file: Error - EEPROM file size is invalid, it should be 272 bytes
> [ 232.128000] rt2800pci: probe of 0000:00:0e.0 failed with error -22
> All of the mentioned drivers (and then some, for that matter) invariably failed to ever receive and/or transmit anything, whether acting as a station or an AP. Furthermore, the EEPROM (as taken from my IAD's original OS image, along with the firmware) had to be byte-swapped for the latter two drivers.
Excuse my ignorance, but do you apply any patches to the rt2x00 driver?
I do not recall any support for reading the eeprom from a file, as the above logs seem to indicate.
Also, forget about Stanislaw's patch, as that isn't the correct way forward.
>> If I recall correctly, your chipset identifies itself as RT35x2 chipset (the PCI ID indicates that is a PCIe interface, MAC_CSR0 indicates the generic chipset code 3572). However, the EEPROM indicates an RF3020 (ID 0x0005), which is a strange combination, as we have seen that RF chipset only in combination with RT30x0 chips.
> Going by the etching on the physical chipset it *does* identify itself as an RT3060F (e.g. RT30x0.) As the logging messages from the IAD's OS and Ralink driver match those produced by the former two Ralink drivers above completely, I'm inclined to believe that this chipset does indeed use the RFIC it claims to. The IAD in question, if it helps, uses the `Danube' platform and was made by Arcadyan.
OK. With identifying I meant the way the chip identifies itself via the registers and it's PCI ID. These don't match up with etching on the chip. Very strange.
Could you post the logging messages from Ralink driver to show what exactly it identifies?
Apart from that, I'm afraid I am running out of ideas, I've never seen or heard from such a situation before.
>> Unfortunately I don't have access to a code tree until Thursday, so I cannot cook up a patch for you to test what happens if we force the RF chipset to be RF3052 (ID 0x0009). Maybe you can test that yourself.
> I did just now, with the second and third of the above mentioned drivers, yet again, unsuccessfully; the `rt3090_ap' driver does apparently not contain code for this RFIC at all.
Can you post the full logs of the attempt with the rt2x00 driver?
>  Danube - LinuxMIPS <http://www.linux-mips.org/wiki/Danube>
More information about the users