On 04/16/2012 04:26 PM, odindba wrote:
>
> I have a dlink dwl-520+ wireless card (an acx 100 card) in a DEll 8250
> which can also boot to XP. The card works fine in XP.
>
> as I entered the below commands, the machine was not connected to the
> internet.
>
> Yast Hardware Information shows the card as a Network Card.
>
> lspci shows the Texas Instruments ACX 100 22Mbps Wireless Interface
>
> lspci -n shows 104c:8400 for this device
>
> find /lib/modules/uname -r -name “acx” results in nothing
>
> iwconfig shows:
> lo no wireless extensions
> eth0 no wireless extensions
>
> I see a single line referencing 104c:8400 in dmesg but nothing seems to
> be there about why the card does not work.
>
> route -n shows only a single line for loopback:
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo
>
> I had hoped the opensuse 12.1 would make my life easier setting this
> card up, but that seems not to have happened.
>
> The eth0 and lo devices show up in the Devices - Network Tolls screen,
> but not this card.
There are no Linux drivers for this device built into the kernel. There is an
out-of-kernel driver that can be downloaded from
Create drivers/net/wireless/acx subdirectory inside
your kernel tree.
BTW, if your kernel has drivers/net/wireless/tiacx directory,
you already may have acx driver (some different version).
Decide which one do you want.
Unpack tarball into drivers/net/wireless/acx directory.
Add a line to drivers/net/wireless/Makefile:
obj-m += acx/
Build your modules as usual (perhaps “make modules modules_install”).
Now what I’ve done so far is:
used zypper to install packages: make, gcc, kernel-source, kernel-syms. It could not find kernel-headers.
(note: I tried to get kernel-headers too, but it said " ‘linux-glibc-devel’ providing ‘kernel-headers’ is already installed."
root:/usr/src/linux: >zypper install kernel-headers
created acx directory in /usr/src/linux/drivers/net/wireless
copied acx-20080210/* to this new acx directory.
added obj-m += acx/ in new line to end of /usr/src/linux/drivers/net/wireless/Makefile
MY QUESTIONS:
for OpenSuse 12.1 (kernel 3.1.0.1.2-default), do I run “make modules modules_install”???
after building the kernel do I have to do anything else to make this new kernel active, change Grub, etc.???
anything else you guys think of that I should do???
Thanks.
Just a short remark - there are more experienced people around than me …
I guess it would make sense to update your system before you compile a new kernel module (driver)
especially your kernel(s).
For example zypper info (and uname -a)
tells me I have now
Now, would someone please tell me how to use “make” to rebuild my kernel (or whatever I need to rebuild) and compile/link/incorporate the new header and c files included with my acx wireless driver.
Please see my post above about what I have done so far. Basically , I placed new header files and c files into an “acx” subdirectory of /usr/src/linux/drivers/net/wireless, and added the line: obj-m += acx/ to end of /usr/src/linux/drivers/net/wireless/Makefile
Which Makefile should I “make”, and what arguments should I use?
Do I have to run make from a specific directory?
Must I do anything after the make to finish this process?
So what eventually worked for me was the following process:
used zypper to install packages: make, gcc, kernel-source, kernel-syms, patterns-openSUSE-devel_kernel. It could not find kernel-headers.
(note:
root:/usr/src/linux: >zypper install kernel-headers
Loading repository data…
Reading installed packages…
‘kernel-headers’ not found in package names. Trying capabilities.
‘linux-glibc-devel’ providing ‘kernel-headers’ is already installed.
Resolving package dependencies…
Nothing to do.)
Below started with:
creating an acx directory to store it in, cd’ing to it, and then:
note 1: I made 192.168.1.254 (my wireless router address)
a default IPv4 gateway for wlan0 on the Routing Tab screen.
note 2: Though it looked like the DWL-520+ card was connected to my wireless network (iwconfig),
I could get to no websites (even ping to ip addresses), until I selected
"User Controlled with Network Manager" in Global Options tab, at which point
I was prompted for my wireless network password (though I had entered it in
Yast-Network Config. After this prompt for password everything worked.
On 04/23/2012 01:06 PM, odindba wrote:
>
> to whom it may concern in the future:
>
> I wasted a lot of time because I had not originally noticed that the
> “newer” development source code for this driver was in the git tree of
> ‘acx100 - Wireless chipset Linux driver | Free software downloads at
> SourceForge.net’ (http://sourceforge.net/projects/acx100/) (I was
> trying to fix compile errors, etc.)
>
> So what eventually worked for me was the following process:
>
> 1. used zypper to install packages: make, gcc, kernel-source,
> kernel-syms, patterns-openSUSE-devel_kernel. It could not find
> kernel-headers.
> (note:
> root:/usr/src/linux:>zypper install kernel-headers
> Loading repository data…
> Reading installed packages…
> ‘kernel-headers’ not found in package names. Trying
> capabilities.
> ‘linux-glibc-devel’ providing ‘kernel-headers’ is
> already installed.
> Resolving package dependencies…
>
> Nothing to do.)
>
> 2. Below started with:
>
> creating an acx directory to store it in, cd’ing to it, and then:
>
> git clone git://acx100.git.sourceforge.net/gitroot/acx100/acx-mac80211
>
>
> 3. cd’d to acx-mac80211 direcory created by above, and ran “make”.
> this created acx-mac80211.ko
>
> 4. ran:
> make install
> depmod
> modprobe acx-mac80211
> rmmod acx-mac80211
> modprobe acx-mac80211
>
> 5. run:
> dmesg> my_dmesg to see startup messages, and look for acx
>
> and saw that I was missing the firmware…
>
> 6. created a firmware subdirectory:
> /granger/dwl_520_plus_linux_driver/firmware
>
> 7. went to http://web.archive.org/web/200605272...EN.BIN_1.9.8.b to
> download
> WLANGEN.BIN_1.9.8.b into firmware subdirectory
> 8. went to http://web.archive.org/web/200605272...w1/RADIO11.BIN to
> download
> RADIO11.bin
> 9. mv WLANGEN.BIN_1.9.8.b tiacx100
> mv RADIO11.BIN tiacx100r11
> mv tiacx* /lib/firmware/.
>
> 10. configured with Yast->Network Settings
>
> note 1: I made 192.168.1.254 (my wireless router address)
> a default IPv4 gateway for wlan0 on the Routing Tab
> screen.
>
> note 2: Though it looked like the DWL-520+ card was connected
> to my wireless network (iwconfig),
> I could get to no websites (even ping to ip addresses),
> until I selected
> “User Controlled with Network Manager” in Global
> Options tab, at which point
> I was prompted for my wireless network password (though
> I had entered it in
> Yast-Network Config. After this prompt for password
> everything worked.
I am glad you figured this out. I just purchased one of these devices on E-bay
and I am planning on keeping this driver up to date.
It cannot be made a part of the kernel source because there were some problems
with the reverse engineering between the TI binary-only code, and this driver.
To avoid contamination of the resulting source, a clean-romm RE process requires
that no one who participates in the decompilation of the binary can contribute
to the code in the new driver. With the b43 driver, this process was carefully
followed. On the other hand, the acx team could not certify that this was true,
thus it was cannot be part of the official kernel. This way, legal action by TI
is avoided.
Are you running this driver on a 32- or 64-bit system? There are many warnings
that result when compiling on x86_64 that make me think it might not work for a
64-bit system.
I am running it on a 32 bit system (old Dell 8250 with 2 gig memory).
It is a real shame that it is not part of the kernel.
Interesting, I did know about this RE (clean room) requirement. Even if those who decompile the binary code write no new source code themselves, the decompilers, I assume, write procedural specifications to give to the code writers. I wonder why TI would not give legal sanction to the acx team to do whatever to make their chip work, what could they lose?
On 04/24/2012 09:06 AM, odindba wrote:
>
> I am running it on a 32 bit system (old Dell 8250 with 2 gig memory).
>
> It is a real shame that it is not part of the kernel.
>
> Interesting, I did know about this RE (clean room) requirement. Even if
> those who decompile the binary code write no new source code themselves,
> the decompilers, I assume, write procedural specifications to give to
> the code writers. I wonder why TI would not give legal sanction to the
> acx team to do whatever to make their chip work, what could they lose?
I do not know what interaction there was between any Linux developers and TI.
This decision to remove tiacx (the old name for the driver) came at a point when
there was quite a bit of legal uncertainty between Linux and several
corporations. Perhaps they just wanted to avoid any further problems.
In any case, I plan to ensure that the driver works on 64-bit systems, and add
any resulting patches to the git repository.