Re: SMC2662W V.4

I'm very sorry to add another e-mail to everyone's inbox, but one more 
thing. I just noticed Jorg saying in one newsgroup archive (hummm, I 
never could find this one in the past):

<http://ftp.cs.indiana.edu/pub/faces/picons/>     From: Joerg Albert 
<joerg.albert <at> gmx.de>

    Subject: Re: Atmel 505a firmware loading
    <http://news.gmane.org/find-root.php?message_id=%3cPine.LNX.4.58.0403192059260.795%40ebxr.ubzr.qr%3e>
    Newsgroups: gmane.linux.drivers.at76c503a.user
    <http://news.gmane.org/gmane.linux.drivers.at76c503a.user>
    Date: Fri, 19 Mar 2004 21:03:31 +0100

Hi,

On Fri, 19 Mar 2004, JoDaY wrote:

> I know this is not the right mailing-list but you're my last hope...
> I'm trying to use an atmel at76c5054 ,

guess it is a at76c505a

> I don't know how it append and how to "redo" it, so I would ask you if I
> could find the good firmware (from win$ ?) and use your driver to make
> it loading ?
> If someone can redirect me to a (relatif) simple doc I would be very
> grateful.

I'm sorry (as for owners of a SMC 2662W v4): currently the Berlios driver
does not support these devices. Atmel, who makes the binary-only firmware,
provides a WPA-enabled firmware for these two devices only, while all
other devices have some older versions, too. WPA-enabled implies a
different interface between driver and device, which the Berlios driver
does not support yet. It will do so in the end, but I cannot give any
timeframe, just started to look into the latest changes of the Sourceforge
driver.

/Jörg

But I looked in the BSD driver and it seems do nothing treating the 
normal rfmd2958 (which appears to be supported by this driver) and the 
SMC variant differently other the the quirks mentioned in the first 
message. I could very easily be wrong, but could'nt the WPA just be 
ignored (which seems to be the case in the BSD driver, as I find no 
mention of WPA in it).

       Al

Alex Schultz wrote:

> Hi,
>
> I now might be able to mod it myself. I took a look at the at76c503.c 
> file and found that the remap and where to put the delay is probably 
> in that file too. The firmware changes could easily be done with a 
> modded version of at76c505-rfmd2958.c and fw-505rfmd2958-1.101.0-86.h 
> however, I don't know how to make at76c503.c behave differently when 
> dealing with a SMC2662W V.4 rather than with other things. I could 
> make it always behave as if it had the SMC2662W V.4, but I want to 
> make a nice clean mod that could possibly be added to the main tree if 
> it proves to be stable and the code is clean. So my main question now 
> is, how would one make at76c503.c behave differently when using 
> different models of at76c503 based network adapters?
>
>    Al
>
> Alex Schultz wrote:
>
>> Hi,
>>
>> My friend is having troubles getting this driver to work with the SMC 
>> 2662W V.4 . I did some research and found a BSD driver that works 
>> with it (http://vitsch.net/bsd/atuwi/) . There seems to be some funny 
>> quirks that it works around. Relevant parts of the code seem to be:
>>
>>    #ifndef ATUWI_NO_RFMD2958_SMC
>>        /* SMC2662 V.4 */
>>        { USB_VENDOR_ATMEL,    USB_PRODUCT_ATMEL_AT76C505A,
>>          RadioRFMD2958_SMC,    ATUWI_QUIRK_NO_REMAP |
>>    ATUWI_QUIRK_FW_DELAY },
>>    #endif
>>
>>
>> Just the general info about it
>>
>>    /*
>>     * The SMC2662w V.4 seems to require some time to do it's thing with
>>     * the external firmware... 20 ms isn't enough, but 21 ms works 100
>>     * times out of 100 tries. We'll wait a bit longer just to be sure
>>     */
>>    if (sc->atuwi_quirk & ATUWI_QUIRK_FW_DELAY) {
>>        atuwi_msleep(sc, 21 + 100);
>>    }
>>
>>
>> Seems that it has a funny quirk (explained well in the comment)
>>
>>    err = atuwi_usb_request(sc, DFU_REMAP, 0, 0, 0, NULL);
>>    if ((err) && (! sc->atuwi_quirk & ATUWI_QUIRK_NO_REMAP)) {
>>        ERROR(("atuwi%d: remap failed!\n", sc->atuwi_unit));
>>        return err;
>>    }
>>
>>
>> Another quirk, something to do with remaps, seems to ignore what 
>> would otherwise be a problem for other cards
>>
>>    #ifndef ATUWI_NO_RFMD2958_SMC
>>        case RadioRFMD2958_SMC:
>>            ptr=atuwi_fw_rfmd2958_smc_int;
>>            bytes_left=sizeof(atuwi_fw_rfmd2958_smc_int);
>>            DEBUG(FLAG_FW,("atuwi%d: loading RFMD2958-smc firmware...\n",
>>                sc->atuwi_unit));
>>            break;
>>    #endif
>>
>>
>> Apparently it needs it's own firmware
>>
>>    #ifndef ATUWI_NO_RFMD2958_SMC
>>    #include <dev/usb/atuwi_rfmd2958-smc_fw.h>
>>
>>
>> Again the new firmware
>>
>>    #ifndef ATUWI_NO_RFMD2958_SMC
>>        case RadioRFMD2958_SMC:
>>            ptr = atuwi_fw_rfmd2958_smc_ext;
>>            bytes_left = sizeof(atuwi_fw_rfmd2958_smc_ext);
>>            DEBUG(FLAG_FW,("atuwi%d: loading external RFMD2958-smc "
>>                "firmware\n", sc->atuwi_unit));
>>            break;
>>    #endif
>>
>>
>> and more about the new firmware.
>> I don't have the programming experience to make a version of the 
>> driver with support for these quirks, and I don't know if Jorg has 
>> the time to impliment such things. I just though I'd mention what 
>> I've found about this.
>>
>>
>>          Al
>>
>> _______________________________________________
>> at76c503a-user mailing list
>> [email protected]
>> http://lists.berlios.de/mailman/listinfo/at76c503a-user
>>
>
>
> _______________________________________________
> at76c503a-user mailing list
> [email protected]
> http://lists.berlios.de/mailman/listinfo/at76c503a-user
>