Firmware upload fails on Soekris board with ZCOM XG-600

Vanja Hrustic <[email protected]>
Newsgroups gmane.linux.drivers.prism54.user
Message-ID <[email protected]>
I am trying to make Mini-PCI card (Zcom XG-601, recognized as XG-601 by
prism54 driver) work on embedded system.

System is Soekris 4511, with Mini-PCI slot. Linux is booting (and running)
from Compact Flash card, and is put together by me; basucally, just kernel
(2.4.26 + hostap/preemptive patches), busybox, uclibc (plus wireless-tools
and some additional stuff, nothing system related).

Prism54 driver is from prism54-cvs-latest.tar.bz2 (downloaded on
21-Apr-2004).

Output of lspci -vvv shows:

00:10.0 Network controller: Intersil Corporation Intersil ISL3890 [Prism
GT/Prism Duette] (rev 01)
        Subsystem: Unknown device 17cf:0014
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B-
        Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at a0002000 (32-bit, non-prefetchable) [size=8K]
        Capabilities: [dc] Power Management version 1
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

I have /etc/hotplug directory, with firmware.agent in it. /sbin/hotplug is
taken from RedHat 9 system (I've installed quite few PrismGT based cards
on it, so hotplug script is okay). Firmware is 1.0.4.3, and saved as
/usr/lib/hotplug/firmware/isl3890

Kernel is compiled with neccesary support for hotplug, etc.

"modprobe firmware_class" loads the module fine.

"modprobe prism54" displays:

Loaded prism54 driver, version 1.1

But when I try to assign an IP address to the eth2 interface (prism54
card, in this case), I see the following:

remove_proc_entry: 00:10.0/loading busy, count=1
remove_proc_entry: firmware/00:10.0 busy, count=1
de_put: deferred delete of loading
de_put: deferred delete of 00:10.0

From what I could find, seems like "de_put:" lines are generated from
linux/fs/proc/inode.c, while "remove_proc_entry:" lines come from
linux/fs/proc/generic.c - I have no idea why/how they showed up, but I
presume developers will know :)

"iwconfig eth2" shows:

/sbin # iwconfig eth2
eth2: timeout waiting for mgmt response
eth2      no wireless extensions.

Just for fun of it, I did "cat /proc/net/wireless", and got:

/proc/net # cat /proc/net/wireless
Inter-| sta-|   Quality        |   Discarded packets               |
Missed | WE
 face | tus | link level noise |  nwid  crypt   frag  retry   misc |
beacon | 16
  eth2: 0000    0     0     0        0      0      0      0      0       
0
/proc/net # eth2: timeout waiting for mgmt response
eth2: timeout waiting for mgmt response
eth2: mgmt tx queue is still full
eth2: mgmt tx queue is still full
eth2: mgmt tx queue is still full

So, I am not sure if firmware was uploaded or not.

The relevant part from dmesg output:

Loaded prism54 driver, version 1.1
eth2: prism54 driver detected card model: XG-600
eth2: islpci_open()
eth2: resetting device...
eth2: uploading firmware...
remove_proc_entry: 00:10.0/loading busy, count=1
remove_proc_entry: firmware/00:10.0 busy, count=1
de_put: deferred delete of loading
de_put: deferred delete of 00:10.0
eth2: firmware uploaded done, now triggering reset...
eth2: timeout waiting for mgmt response 100, triggering device
eth2: timeout waiting for mgmt response
eth2: timeout waiting for mgmt response 100, triggering device
eth2: timeout waiting for mgmt response
eth2: timeout waiting for mgmt response 100, triggering device
eth2: timeout waiting for mgmt response
eth2: timeout waiting for mgmt response 100, triggering device
eth2: timeout waiting for mgmt response
eth2: mgmt tx queue is still full
eth2: mgmt tx queue is still full
eth2: mgmt tx queue is still full
/proc/net # 

Any pointers on how to solve/investigate this, or how to get more
'sensible debugging' output is much appreciated :)

Vanja
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.