[Madwifi-users] madwifi-users@lists.sourceforge.net

[Anthony T. <atz...@ra...>]

I also using SnapGear Linux version 3.1.1 with the Intel XScale IXP425 
processor with the Atheros 5212 mini-PCI A/B/G card 0168:0013.  Is there 
more information available in making this work?

I have tried CVS 06-23-2004, 04-23-2004, 05-15-2004 module checkouts and 
all have the same problem described below when I 'insmod ath_pci.o'.  I 
was working on building the 01-12-2004 release too but am in mid-process 
of setting up the environment variables since the older build has some 
different environment variable names.  Going backward in time to make 
this work may not be the correct solution to my issue.

After seeing this mailing list post below, it seems as if there already 
is some work being performed on this driver for the same processor 
target platform, distribution, and toolchain.  There appears to be some 
offline interchange going on.  Any information would be greatly 
appreciated.  Thanks.

Anthony Tzouris


From: Sam Leffler <sam@er...>
Re: ath_hal_attach segfaults on IXDP425 
2004-05-05 14:51

 On Wednesday 05 May 2004 07:05 am, Dale Whitfield wrote:
 > >On Wednesday 05 May 2004 04:39 am, Lie, Martin wrote:
 > >> Hello,
 > >>
 > >> I am experiencing some troubles when insmod"ing ath_pci on my Intel
 > >> IXDP425 board. I am running Snapgear 3.1.1 and Atheros 5212 
running on a
 > >> miniPCI board and loading segfaults like this:
 > >
 > >    <...stuff snipped...>
 > >
 > >> It seems that a call to ath_hal_attach() in if_ath.c is the 
showstopper.
 > >> I have tried all available versions of the xscale-be-elf with the same
 > >> result. I have also tried a different miniPCI-card with the same
 > >> chipset, but with no luck.
 > >>
 > >> Does anyone have some suggestions on how I could resolve this?
 > >
 > >Many of the hal builds are not "maintained" because we don"t have the
 > >resources.  That is to say, these builds were known to work on at least
 > > one platform at one time but since that time they are just mechanically
 > > built with each new release.  Those builds that are/were known to work
 > > should have the specific processor model and/or board identified in the
 > > .inc file in the hal/linux directory.  The xscale-be build was 
tested on
 > > this exact board I believe (I note however that info is not in the .inc
 > > file).
 > >
 > >In general getting things working on embedded platforms can be painful.
 > > You often must use precisely the same toolchain and compilation options
 > > when building the hal and kernel/driver to get things to work.  This is
 > > why the hal .inc files have complete info about how the hal binary was
 > > built.
 > >
 > >Embedded platforms sometimes require special glue code to access 
registers
 > > in the hardware and the distributed code in linux/ah_osdep.? is
 > > insufficient (that code assumes a strict memory-mapped i/o model).
 > >
 > >If I had to guess I"d say you have a toolchain compatibility problem.
 >
 > Not a toolchain problem. The PCI window at that address (4bffxxxx) is not
 > accessible directly as memory-mapped. The memory is Non-Prefetch and 
should
 > be accessed via the processor using PCI read/write transactions.
 >
 > The hal needs to be compiled with REGOPS and those reg ops must use 
ixp425
 > pci_read and pci_write, ie. readl/writel (which must also be exported 
from
 > the kernel).
 >
 > Since the processor handles byte-lane swapping by (correctly) 
assuming that
 > pci is always little-endian, there"s a potential endian issue when doing
 > this which I have yet to resolve. Sam, perhaps you could offer some 
offline
 > advice, since its a hal issue.
 
 Ok.  Building xscale-be-elf with the REGOPS (so the register operations 
are
 all function calls to routines that can be defined in ah_osdep.c) is
 something I can do for the next hal release.  The inconsistent byte 
swapping
 semantics of readl/writel is why the hal currently avoids them 
entirely.  The
 intent, in a situation like this, is that you replace memory refs w/ the
 equivalent non-byte-swapped work and leave the byte swapping to the hal
 (which uses the h/w byte swapping).  We can talk about this more offline.
 
     Sam