Subject: Re: Atheros - Status?
To: Greg Troxel <gdt@ir.bbn.com>
From: Sam Leffler <sam@errno.com>
List: current-users
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:anonymous@cvs.sourceforge.net:/cvsroot/madwifi login
> $ cvs -d:pserver:anonymous@cvs.sourceforge.net:/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
> mipsisa32-le-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 (!).

>
> netbsd:
>
> 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
> stripped
>
> sourceforge after cvs up -r 1.1.1.5 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.

	Sam