SV: [Madwifi-users] ath_hal_attach segfaults on IXDP425

[Lie, M. <mar...@wr...>]

I noticed my arm-elf- toolchain was too old, and I have upgraded it to the
correct versions as mentioned in the *.inc-file.

My next problem is that the driver is not compilable with the arm-elf-
toolchain, only arm-linux- toolchain. As it complained about kernel include
files, I tried to recompile the kernel with arm-elf, but that did'nt last
long until compilation failed. Seems like my distro needs arm-linux for
compilation. As far as I could see, the arm-elf-gcc was compiled with glibc
available (although --enable-languages=c is set when running configure for
gcc).

The arm-linux toolchain is of correct version, and I am able to compile and
link the driver, but it segfaults as mentioned earlier.

Questions:
* what are the implications of compiling/linking with the arm-linux
toolchain?
* would a "xscale-be-linux" binary help me?


- Martin


-----Opprinnelig melding-----
Fra: Sam Leffler [mailto:sa...@er...] 
Sendt: 5. mai 2004 15:30
Til: mad...@li...
Kopi: Lie, Martin
Emne: Re: [Madwifi-users] ath_hal_attach segfaults on IXDP425


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.

	Sam