Failed to download firmware to ACX100

Logged In: YES
user_id=132674

Oh no, not another DLink card with some memory issues.
This card works in Windows, right?
(we've had a similar case some months ago where there was
some slight memory corruption, but the card worked fine in
Windows).
Since you're the 2nd or 3rd (depending on who was faster - I
don't know) person to report firmware upload trouble with
520+ and 650+ cards and it actually seems to work on
Windows, we definitely ought to try some more to fix it.
I'm going to add some more firmware upload debugging in the
next version. Hopefully we'll be able to debug it further.

Thanks for the report!

Logged In: YES
user_id=673325

Yes, it's a D-Link :/. It works with Windows, currently I am
using driverloader trial because it works very well with the
DWL-650+. When you have a new working version e-mail me,
I don't wanna buy the driverloader.

Logged In: YES
user_id=780113

Can you increase your debug flags to at least debug=0x03 and post
the log again. Thanks.

Logged In: YES
user_id=673325

Ok, I removed the alias to driverloader and configured
modules.conf to acx100_pci.o with:
alias eth1 acx100_pci
options acx100_pci use_eth_name=1 debug=0x03
firmware_dir=/lib/modules/acx100_fmwe/

Now it doesn't tell me that it won't download the firmware,
but there's a bigger problem. It actually comunicates with
the adapter (the light flash while starting up) but it kinda
dies. It can't send data(at startup it had a 100% data
loss), it has a lot of trouble getting the IP. I think it
can recieve data though, I was able to ping (after startup,
where I retried to start the device) my laptop, which has
the DWL-650+, but it can't ping my desktop. Don't expect to
see any replies from me today, I have to learn 100 words for
an english test tomorrow (I am in high school) Anyways here
is the output from dmesg:

acx100: It looks like you were coaxed into buying a wireless
network card
acx100: that uses the mysterious ACX100 chip from Texas
Instruments.
acx100: You should better have bought e.g. a PRISM(R)
chipset based card,
acx100: since that would mean REAL vendor Linux support.
acx100: Given this info, it's plain evident that this driver
is EXPERIMENTAL,
acx100: thus your mileage may vary. Visit
http://acx100.sf.net for support.
acx100_init_module: TI acx100_pci.o: Ver 0.2.0pre6 Loaded
PCI: Setting latency timer of device 03:00.0 to 64
Found ACX100-based wireless network card,
phymem1:0x40800000, phymem2:0x40810000 , irq:11,
mem1:0xf9c0b000, mem2:0xf9c0d000
Allocating 6592, 19C0h bytes for wlandevice_t
hw_unavailable = 1
reset hw_unavailable++
Allocated 40636 bytes for firmware module loading.
acx100_write_fw (firmware): 1, acx100_validate_fw: 1
reset hw_unavailable--
************ acx100_initmac_1 ************
Allocated 964 bytes for firmware module loading.
WriteACXImage (radio): 1, ValidateACXImage: 1
get_mask 0x00002004, set_mask 0x00000000
Got antenna value 0x8f.
get_mask 0x00000000, set_mask 0x00000000 - after update
Regulatory domain ID as read from EEPROM: 0x10
hw_unavailable--
acx100: form factor 0x00 (standard?), radio type 0x11
(RFMD), EEPROM version 0x0 004. Uploaded firmware 'Rev
1.9.8.b' (0x01020505).
divert: allocating divert_blk for eth0
Warning: WEP support might not be supported in Ad-Hoc mode yet!
firmware version >= 1.9.3.e --> using software timer
initial settings update on iface activation.
get_mask 0x00000000, set_mask 0x0000dfff
Updating WEP key settings
Updating transmit power: 20 dBm
changing radio power level to 20 dBm (0x3f)
Updating antenna value: 0x8F
Updating energy detect threshold: 112
Updating Channel Clear Assessment value: 0x0D
Updating: enable Tx
Updating: enable Rx
Updating short retry limit: 5, long retry limit: 3
Updating xmt MSDU lifetime: 2048
Updating regulatory domain: 0x10
Updating channel: 1
get_mask 0x00000000, set_mask 0x00000000 - after update
acx100_process_probe_response: found and registered station
0: ESSID "family" on channel 11, BSSID 00 0D 88 8D 90 A9
(Access Point, 22Mbps), SIR 87, SNR 59.
acx100_process_probe_response: found and registered station
1: ESSID "family" on channel 11, BSSID 00 40 05 26 B9 36
(Access Point, 22Mbps), SIR 128, SNR 59.
d11CompleteScan: matching station FOUND (idx 1), JOINING (00
40 05 26 B9 36).
Sending authentication1 request, awaiting response!
Sending authentication1 request, awaiting response!
<sta_list_add> sta = 00:40:05:26:B9:36
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
Sending association request, awaiting response! NOT
ASSOCIATED YET.
parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE]
parport0: irq 7 detected
lp0: using parport0 (polling).
lp0: console ready
Intel 810 + AC97 Audio, version 0.24, 15:50:18 Oct 29 2003
PCI: Found IRQ 11 for device 00:1f.5
PCI: Sharing IRQ 11 with 00:1f.6
PCI: Setting latency timer of device 00:1f.5 to 64
i810: Intel ICH4 found at IO 0xbc40 and 0xb800, MEM
0xf4fff800 and 0xf4fff400, I RQ 11
i810: Intel ICH4 mmio at 0xf9c4c800 and 0xf9c4e400
i810_audio: Primary codec has ID 0
i810_audio: Audio Controller supports 6 channels.
i810_audio: Defaulting to base 2 channel mode.
i810_audio: Resetting connection 0
i810_audio: Connection 0 with codec id 0
ac97_codec: AC97 Audio codec, id: 0x8384:0x7650 (Unknown)
i810_audio: AC'97 codec 0 supports AMAP, total channels = 2
b44.c:v0.9 (Jul 14, 2003)
PCI: Found IRQ 11 for device 02:00.0
PCI: Sharing IRQ 11 with 00:1d.2
PCI: Sharing IRQ 11 with 00:1f.1
divert: allocating divert_blk for eth0
eth0: Broadcom 4400 10/100BaseT Ethernet 00:0b:db:95:56:22
divert: freeing divert_blk for eth0
b44.c:v0.9 (Jul 14, 2003)
PCI: Found IRQ 11 for device 02:00.0
PCI: Sharing IRQ 11 with 00:1d.2
PCI: Sharing IRQ 11 with 00:1f.1
divert: allocating divert_blk for eth0
eth0: Broadcom 4400 10/100BaseT Ethernet 00:0b:db:95:56:22
b44: eth0: Link is down.
usb-uhci.c: interrupt, status 2, frame# 1366
usb_control/bulk_msg: timeout
firmware version >= 1.9.3.e --> using software timer
initial settings update on iface activation.
get_mask 0x00000000, set_mask 0x00000f7f
Updating WEP key settings
Updating transmit power: 20 dBm
changing radio power level to 20 dBm (0x3f)
Updating antenna value: 0x8F
Updating energy detect threshold: 112
Updating Channel Clear Assessment value: 0x0D
Updating: enable Tx
Updating: enable Rx
Updating regulatory domain: 0x10
Updating channel: 11
get_mask 0x00000000, set_mask 0x00000000 - after update
get_mask 0x00000000, set_mask 0x00000801
Updating WEP key settings
get_mask 0x00000000, set_mask 0x00000000 - after update
acx100_process_probe_response: found and registered station
0: ESSID "family" on channel 11, BSSID 00 0D 88 8D 90 A9
(Access Point, 22Mbps), SIR 104, SNR 0.
get_mask 0x00000000, set_mask 0x00000400
get_mask 0x00000000, set_mask 0x00000000 - after update
acx100_process_probe_response: found and registered station
0: ESSID "family" on channel 11, BSSID 00 40 05 26 B9 36
(Access Point, 22Mbps), SIR 160, SNR 0.
acx100_process_probe_response: found and registered station
1: ESSID "family" on channel 11, BSSID 00 0D 88 8D 90 A9
(Access Point, 22Mbps), SIR 90, SNR 0.
firmware version >= 1.9.3.e --> using software timer
initial settings update on iface activation.
get_mask 0x00000000, set_mask 0x0000037f
Updating WEP key settings
Updating transmit power: 20 dBm
changing radio power level to 20 dBm (0x3f)
Updating antenna value: 0x8F
Updating energy detect threshold: 112
Updating Channel Clear Assessment value: 0x0D
Updating: enable Tx
Updating: enable Rx
Updating regulatory domain: 0x10
Updating channel: 11
get_mask 0x00000000, set_mask 0x00000000 - after update
firmware version >= 1.9.3.e --> using software timer
initial settings update on iface activation.
get_mask 0x00000000, set_mask 0x0000077f
Updating WEP key settings
Updating transmit power: 20 dBm
changing radio power level to 20 dBm (0x3f)
Updating antenna value: 0x8F
Updating energy detect threshold: 112
Updating Channel Clear Assessment value: 0x0D
Updating: enable Tx
Updating: enable Rx
Updating regulatory domain: 0x10
Updating channel: 11
get_mask 0x00000000, set_mask 0x00000000 - after update
firmware version >= 1.9.3.e --> using software timer
initial settings update on iface activation.
get_mask 0x00000000, set_mask 0x0000077f
Updating WEP key settings
Updating transmit power: 20 dBm
changing radio power level to 20 dBm (0x3f)
Updating antenna value: 0x8F
Updating energy detect threshold: 112
Updating Channel Clear Assessment value: 0x0D
Updating: enable Tx
Updating: enable Rx
Updating regulatory domain: 0x10
Updating channel: 11
get_mask 0x00000000, set_mask 0x00000000 - after update
firmware version >= 1.9.3.e --> using software timer
initial settings update on iface activation.
get_mask 0x00000000, set_mask 0x00000f7f
Updating WEP key settings
Updating transmit power: 20 dBm
changing radio power level to 20 dBm (0x3f)
Updating antenna value: 0x8F
Updating energy detect threshold: 112
Updating Channel Clear Assessment value: 0x0D
Updating: enable Tx
Updating: enable Rx
Updating regulatory domain: 0x10
Updating channel: 11
get_mask 0x00000000, set_mask 0x00000000 - after update

Logged In: YES
user_id=673325

Ok, I more info on the subjetc, when I tried to run ifup
eth1 I got this:
Cannot get driver information: Operation not supported

Determining IP information for eth1...

Logged In: YES
user_id=673325

Ok, I GOT IT WORKING!!! The problem of not downloading the
firmware to the device its a bug of 2.0pre6, I now remember,
after installing and seeing that 2.0pre6 didn't work, I
grabed a working copy from CVS. I compiled it, but I never
tested it. Today I placed it at /lib/modules/whatever/net/
and it fixed the problem of downloading the firmware, I
don't know if the debug=0x03 helped. The next problem I
encountered is that I was using the latest D-Link driver,
the 3.06, I just tried 3.03 which doesn't contains
radio15.bin and it WORKS!!! :)))) I don't have to buy
driverloader!! I will soon write a tutorial to beginners on
the D-Link DWL-650+ based on my experience.

Logged In: YES
user_id=923839

Hi, as there are more debug information for the insmod issue,
here is the result of my dlink-520+.
insmod failure with pre6_plus_fixes_7
acx100: It looks like you were coaxed into buying a wireless
network card
acx100: that uses the mysterious ACX100 chip from Texas
Instruments.
acx100: You should better have bought e.g. a PRISM(R)
chipset based card,
acx100: since that would mean REAL vendor Linux support.
acx100: Given this info, it's plain evident that this driver is
EXPERIMENTAL,
acx100: thus your mileage may vary. Visit http://acx100.sf.net
for support.
acx100_init_module: TI acx100_pci.o: Ver 0.2.0pre6 Loaded
Found ACX100-based wireless network card,
phymem1:0xd6800000, phymem2:0xd6000000, irq:9,
mem1:0xe5825000, mem2:0xe5892000, compiled with wireless
extensions v16
Allocating 3560, DE8h bytes for wlandevice_t
hw_unavailable = 1
reset hw_unavailable++
Allocated 33392 bytes for firmware module loading.
FATAL: firmware upload: data parts at offset 15004 don't
match!! (0x57521cc9 vs. 0x5752f002). Memory defective or
timing issues, with DWL-xx0+?? Please report!
firmware upload attempt #0 FAILED, retrying...
FATAL: firmware upload: data parts at offset 15004 don't
match!! (0x57521cc9 vs. 0x5752f002). Memory defective or
timing issues, with DWL-xx0+?? Please report!
firmware upload attempt #1 FAILED, retrying...
FATAL: firmware upload: data parts at offset 660 don't match!!
(0x1afffff7 vs. 0x1affc000). Memory defective or timing issues,
with DWL-xx0+?? Please report!
firmware upload attempt #2 FAILED, retrying...
FATAL: firmware upload: data parts at offset 15004 don't
match!! (0x57521cc9 vs. 0x5752f002). Memory defective or
timing issues, with DWL-xx0+?? Please report!
firmware upload attempt #3 FAILED, retrying...
FATAL: firmware upload: data parts at offset 15004 don't
match!! (0x57521cc9 vs. 0x5752f002). Memory defective or
timing issues, with DWL-xx0+?? Please report!
firmware upload attempt #4 FAILED, retrying...
acx100_write_fw (firmware): 1, acx100_validate_fw: 0
Failed to upload firmware to the ACX100
acx100_probe_pci: TI acx100_pci: MAC initialize failure!

insmod failure with pre4
################## log starts - failure pre4
#################################
acx100: It looks like you were coaxed into buying a wireless
network card
acx100: that uses the mysterious ACX100 chip from Texas
Instruments.
acx100: You should better have bought e.g. a PRISM(R)
chipset based card,
acx100: since that would mean REAL vendor Linux support.
acx100: Given this info, it's plain evident that this driver is
EXPERIMENTAL,
acx100: thus your mileage may vary. Visit http://acx100.sf.net
for support.
Found ACX100-based wireless network card,
phymem1:0xd6800000, phymem2:0xd6000000, irq:9,
mem1:0xe5825000, mem2:0xe588d000
Allocating 6604, 19CCh bytes for wlandevice_t
Allocated 33708 bytes for firmware module loading.
acx100_write_fw (firmware): 1, acx100_validate_fw: 0
Failed to download firmware to the ACX100
acx100_probe_pci: TI acx100_pci: MAC initialize failure!
################## log ends - failure pre4
###################################

insmod success with pre4 (always after 1 or 2 failure after a
fresh restart of the computer)
################## log starts - success pre4
#################################
acx100: It looks like you were coaxed into buying a wireless
network card
acx100: that uses the mysterious ACX100 chip from Texas
Instruments.
acx100: You should better have bought e.g. a PRISM(R)
chipset based card,
acx100: since that would mean REAL vendor Linux support.
acx100: Given this info, it's plain evident that this driver is
EXPERIMENTAL,
acx100: thus your mileage may vary. Visit http://acx100.sf.net
for support.
Found ACX100-based wireless network card,
phymem1:0xd6800000, phymem2:0xd6000000, irq:9,
mem1:0xe5825000, mem2:0xe588d000
Allocating 6604, 19CCh bytes for wlandevice_t
Allocated 33708 bytes for firmware module loading.
acx100_write_fw (firmware): 1, acx100_validate_fw: 1
************ acx100_initmac_1 ************
Allocated 920 bytes for firmware module loading.
WriteACXImage (radio): 1, ValidateACXImage: 1
writing WEP options.
################## log ends - success pre4
##################################

Logged In: YES
user_id=132674

Hmm, very interesting.

Both the fact that it semi-worked in pre4 (where we didn't
remove busy-loops yet) and the fact that it mostly happens
at offset 15004, which is the position after offset 15000
after which we schedule away to avoid more busy-looping show
that it seems to be a timing or register configuration issue.

Maybe we should abandon auto-increment during firmware
writing and instead always program the current offset prior
to writing the data. That might help...

I will send a modified version this evening.

Thanks for the very helpful report!

Logged In: YES
user_id=132674

Please try pre6_plus_fixes_8 tar file, this might fix the
problems (don't do auto increment of firmware write pointer,
since we might lose some state).
Would be great if that actually managed to fix it...
Otherwise we'll have to face removing the scheduling and to
somehow improve the loop or so.

Logged In: YES
user_id=923839

First thanks for all the hard work :)

I got the firmware loaded, but same problem as in pre4
The loading fails the first time(10 tests with 10 reboots), after
that it just loads fine. I can unload it, reload it, unload it...
without problem.
(I'm using the same debug level as the previous report, but I
don't have the logs I got with pre6_plus_fixes_7 when the
loading fails)

####### log starts - failure pre6_plus_fixes_8
###########################
acx100: It looks like you were coaxed into buying a wireless
network card
acx100: that uses the mysterious ACX100 chip from Texas
Instruments.
acx100: You should better have bought e.g. a PRISM(R)
chipset based card,
acx100: since that would mean REAL vendor Linux support.
acx100: Given this info, it's plain evident that this driver is
EXPERIMENTAL,
acx100: thus your mileage may vary. Visit http://acx100.sf.net
for support.
PCI: Enabling device 00:09.0 (0004 -> 0007)
Found ACX100-based wireless network card,
phymem1:0xd6800000, phymem2:0xd6000000, irq:9,
mem1:0xe5818000, mem2:0xe581a000
Allocating 6604, 19CCh bytes for wlandevice_t
Allocated 33708 bytes for firmware module loading.
acx100_write_fw (firmware): 1, acx100_validate_fw: 0
Failed to download firmware to the ACX100
acx100_probe_pci: TI acx100_pci: MAC initialize failure!
####### log ends - failure pre6__plus_fixes_8
###########################

####### log starts - success pre6__plus_fixes_8
########################
acx100: It looks like you were coaxed into buying a wireless
network card
acx100: that uses the mysterious ACX100 chip from Texas
Instruments.
acx100: You should better have bought e.g. a PRISM(R)
chipset based card,
acx100: since that would mean REAL vendor Linux support.
acx100: Given this info, it's plain evident that this driver is
EXPERIMENTAL,
acx100: thus your mileage may vary. Visit http://acx100.sf.net
for support.
Found ACX100-based wireless network card,
phymem1:0xd6800000, phymem2:0xd6000000, irq:9,
mem1:0xe5816000, mem2:0xe5818000
Allocating 6604, 19CCh bytes for wlandevice_t
Allocated 33708 bytes for firmware module loading.
acx100_write_fw (firmware): 1, acx100_validate_fw: 1
************ acx100_initmac_1 ************
Allocated 920 bytes for firmware module loading.
WriteACXImage (radio): 1, ValidateACXImage: 1
writing WEP options.
Regulatory domain ID as read from EEPROM: 0x30
####### log starts - success pre6__plus_fixes_8
######################

Logged In: YES
user_id=132674

While this is showing some beautiful success and failure
logs, the logs don't bear the slightest resemblance to
0.2.0pre6_plus_fixes_8 with its changed log messages and
additional firmware logging.
Please fix.

Thanks!

Logged In: YES
user_id=923839

[FIXED]
I'm feeling so stupid about the previous misleading report :o)
The loading script was automatically changing to the previous
location of the old driver. I should have noticed that the
logging was not like the pre6 pattern. Next time I'll avoid
debugging at 2AM ;)
Anyway. I'm currently using pre6_plus_fixes_8 to write this
message :)
It loads fine and at the first time (5 tries with reboots)
here is a nice logging
----------------------------------------------------
It looks like you were coaxed into buying a wireless network
card
that uses the mysterious ACX100 chip from Texas
Instruments.
You should better have bought e.g. a PRISM(R) chipset based
card,
since that would mean REAL vendor Linux support.
Given this info, it's plain evident that this driver is
EXPERIMENTAL,
thus your mileage may vary. Visit http://acx100.sf.net for
support.
acx100_init_module: TI acx100_pci.o: Ver 0.2.0pre6 Loaded
Found ACX100-based wireless network card,
phymem1:0xd6800000, phymem2:0xd6000000, irq:9,
mem1:0xe581b000, mem2:0xe581d000, compiled with wireless
extensions v16
Allocating 3564, DECh bytes for wlandevice_t
hw_unavailable = 1
reset hw_unavailable++
Allocated 33708 bytes for firmware module loading.
not using auto increment for firmware loading.
acx100_write_fw (firmware): 1, acx100_validate_fw: 1
reset hw_unavailable--
************ acx100_initmac_1 ************
Allocated 920 bytes for firmware module loading.
not using auto increment for firmware loading.
WriteACXImage (radio): 1, ValidateACXImage: 1
writing WEP options.
-----------------------------------------------------------

Thank you so much :)

Logged In: YES
user_id=132674

Hmm, crap, so this means that we do have to use the slower
variant of always programming the new offset before writing...
But anyway, I'm very glad that this slightly inferiour
solution managed to fix things, and I think that we'll keep
it as default,
since there have been several reports of this problem, so
they should hopefully all be fine now.