libertas sdio on bf548 w/ uclinux

Tue May 6 11:10:39 EDT 2008

Nick Moszer wrote:
> Pierre Ossman wrote:
>   
>> On Tue, 22 Apr 2008 14:28:36 -0400
>> Dan Williams <dcbw at redhat.com> wrote:
>>
>>   
>>     
>>> On Tue, 2008-04-22 at 13:04 -0500, Nick Moszer wrote:
>>>     
>>>       
>>>> As a follow up to this, here is the libertas debug info right before it 
>>>> bombs.
>>>>       
>>>>         
>>> Probably need to get Pierre's input here...  I'm not sure how the SDIO
>>> stack is supposed to interact with controllers that have certain
>>> padding/alignment constraints.
>>>
>>> Pierre?
>>>     
>>>       
>> What a delightful mess of top posting...
>>
>> As for controllers with certain padding/alignment constraints, the
>> answer is simply tough luck, get some other hardware that isn't broken.
>> The MMC/SD/SDIO specs have mandated varying transfer sizes since day
>> one, so hardware that cannot support that doesn't deserve to be called
>> a MMC/SD/SDIO controller.
>>
>> The controller shouldn't BUG though as such requests are perfectly
>> valid. It should fail them with -EINVAL, indicating that the hardware
>> is unable to satisfy the request.
>>
>> And yes, the behaviour of the libertas card is consistent with what
>> I've been seeing. My guess is that it transfers one chunk that tells it
>> how much data that follows.
>>
>> Rgds
>> Pierre
>>   
>>     
> Wondering if I could ask one more question of you gentlemen.
>
> This is VERY close to working now.  I added a workaround for this 
> blackfin board where all the data passed it bumped up to the nearest
> power of 2. I'm able to load the libertas and libertas_sdio modules just 
> fine.  I get a ethX device and am able to associate with an AP.
> I can throw iwconfig a hundred times and it works, so basic 
> communication with the chip appears to be working.
>
> Sometimes it will get an IP through DHCP, when it does once I try to 
> send data through the wifi (ping, ssh) it will sometimes make it one or
> two pings in, sometimes 5 or 6 and then die.
>
> Output from libertas debug when it fails to get an IP:
> libertas enter: handle_cmd_response():547
> libertas leave: handle_cmd_response():712
> libertas enter: cleanup_cmdnode():1585
> libertas leave: cleanup_cmdnode():1599
> libertas leave: libertas_process_rx_command():865, ret 0
> libertas host: EXEC_NEXT_CMD: sending command 0x0028
> libertas enter: DownloadcommandToStation():981
> libertas host: DNLD_CMD: command 0x0028, size 12, jiffies 42721
> libertas enter: if_sdio_host_to_card(type 1, bytes 12):726
> libertas leave: if_sdio_host_to_card():800, ret 0
> libertas cmd: DNLD_CMD: sent command 0x0028, jiffies 42721
> libertas leave: DownloadcommandToStation():1037, ret 0
> libertas enter: if_sdio_host_to_card_worker():379
> libertas leave: if_sdio_host_to_card_worker():419
> libertas enter: if_sdio_interrupt():846
> libertas thread: interrupt: 0x2
> libertas leave: if_sdio_interrupt():880, ret 0
> libertas enter (INT): if_sdio_host_to_card(type 0, bytes 614):726
> libertas leave (INT): if_sdio_host_to_card():800, ret 0
> libertas enter: if_sdio_host_to_card_worker():379
> libertas leave: if_sdio_host_to_card_worker():419
> libertas enter: if_sdio_interrupt():846
> libertas thread: interrupt: 0x1
> libertas enter: if_sdio_card_to_host():273
> libertas fw (INT): command_timer_fn fired, cmd 28
> libertas fw (INT): re-sending same command because of timeout
> libertas enter (INT): libertas_queue_cmd():924
> libertas host (INT): QUEUE_CMD: inserted command 0x0028 into cmdpendingq
> libertas leave (INT): libertas_queue_cmd():961
> NETDEV WATCHDOG: eth1: transmit timed out
> libertas: tx watch dog timeout
> libertas enter (INT): if_sdio_host_to_card(type 0, bytes 614):726
> libertas leave (INT): if_sdio_host_to_card():800, ret 0
> libertas enter: if_sdio_host_to_card_worker():379
> NETDEV WATCHDOG: eth1: transmit timed out
> libertas: tx watch dog timeout
> libertas enter (INT): if_sdio_host_to_card(type 0, bytes 614):726
> libertas leave (INT): if_sdio_host_to_card():800, ret 0
> NETDEV WATCHDOG: eth1: transmit timed out
> libertas: tx watch dog timeout
> libertas enter (INT): if_sdio_host_to_card(type 0, bytes 614):726
> libertas leave (INT): if_sdio_host_to_card():800, ret 0
> NETDEV WATCHDOG: eth1: transmit timed out
> libertas: tx watch dog timeout
> libertas enter (INT): if_sdio_host_to_card(type 0, bytes 614):726
> libertas leave (INT): if_sdio_host_to_card():800, ret 0
> NETDEV WATCHDOG: eth1: transmit timed out
> libertas: tx watch dog timeout
>
>
> In this instance it seems like it failed on a CMD_MAC_CONTROL but I've
> also seen it fail on a CMD_MAC_MULTICAST_ADR and a CMD_802_11_GET_LOG so
> I don't think it's that particular command.
>
>
> Looking at scope output it APPEARS the SDIO_D1 pin is being held low by 
> the Marvell chip, when I reset the SDH controller on the blackfin the
> pin is still low. It won't go back high until the card is reset.  
> Turning on mmc debugging it appears the controller is still trying to 
> send commands.
>
>
> Another thing of interest is in the status register of the blackfin SDH 
> controller I get a "missing start bit" flag set when this fails.
>
>
> So, my thought is that the firmware on the Marvell chip is going dumb 
> and dies.  Which kind of makes this not easy to fix.  Does anyone else
> have an opinion?  I'm hoping it's something I'm overlooking and not the 
> firmware.
>
> Thanks!
>
>
>
>
>
>
>
>
>
> _______________________________________________
> libertas-dev mailing list
> libertas-dev at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/libertas-dev
>   
"Bump".... no takers on this one?  The help is greatly appreciated.