Subject: Re: Atheros - Status?
To: Greg Troxel <email@example.com>
From: Sam Leffler <firstname.lastname@example.org>
Date: 02/22/2004 12:33:01
On Friday 20 February 2004 07:05 am, Greg Troxel wrote:
> There's actually support for many non-x86 architectures; look on
> sourceforge (the madwifi project).
> I didn't realize that (none of the other archs are in the netbsd tree
> under src/contrib/sys/arch/*/dev).
> The version in netbsd is labeled '12-dec-2003', and I suppose that
> should get updated to the 2004-01-12 version.
> For anyone who is inclined to try the sourceforge versions, here's the
> cheat sheet for getting the bits quickly:
> $ cvs -d:pserver:email@example.com:/cvsroot/madwifi login
> $ cvs -d:pserver:firstname.lastname@example.org:/cvsroot/madwifi co madwifi
> $ cd madwifi/hal/linux && ls *.uu
> arm9-le-thumb-elf.hal.o.uu powerpc-be-eabi.hal.o.uu
> i386-elf.hal.o.uu powerpc-le-eabi.hal.o.uu
> mipsisa32-be-elf.hal.o.uu xscale-be-elf.hal.o.uu
There are actually two others (MIPS2 in particular) hidden on the vendor
branch (ATHEROS) but orphaned from HEAD (don't get me started about
sourceforge and how impossible it is get CVS repo help).
> It would be nice if 'ident' or something on the .o got a revision
> number and date. I tried strings and ident and wasn't able to get the
> build date. From dyoung's commit comments I think that netbsd
> currently has the 11-dec-03 version which is labelled 0.9.6.11.
> But, it seems the linux hals and the freebsd hal that is used in
> netbsd are different:
I'll see what I can do about the ident string. The version string shows up
many places elsewhere.
As to differences, the Linux versions are compiled separately but they have
identical ABI's (at least they worked in my testing). I'm not sure if there
are actual differences or why the two binaries aren't identical bit for bit.
If netbsd has 0.9.6.11 then that's the latest. FreeBSD is lagging (!).
> athhal-elf.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD),
> not stripped text data bss dec hex filename
> 131435 4260 432 136127 213bf athhal-elf.o
> sourceforge after uudecode:
> hal.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (SYSV), not
> sourceforge after cvs up -r 220.127.116.11 i386-elf.hal.o.uu and uudecode
> hal.o: ELF 32-bit LSB relocatable, Intel 80386, version 1 (FreeBSD), not
> stripped text data bss dec hex filename
> 102210 4280 432 106922 1a1aa hal.o
> Sorry if I'm being a pain, but I'm obviously missing something about
> how the hal binaries work. I think they are os indedepent (depending
> only on processor/endian and exec format), so I'm guessing the ELF
> system name is just where they were compiled. But I was not able to
> tie the bits in NetBSD cvs back to what I think is the corresponding
> version in madwifi cvs.
They are supposed to be OS independent. All the OS-specific glop is in the
ah_osdep.c file that is supplied in source form. The naming convention
reflects the gcc tag used to build the hal.o binary. If you can't just grab
a hal.o from sourceforge and use it I want to know and will fix that.