Date: Wed, 15 Nov 2006 13:15:21 +0100 From: Olivier Houchard <mlfbsd@ci0.org> To: Jim Thompson <jim@netgate.com> Cc: freebsd-arm@freebsd.org, Sam Leffler <sam@freebsd.org> Subject: Re: Gateworks 2348 any experience with it? Message-ID: <20061115121521.GA38995@ci0.org> In-Reply-To: <FBD13236-9CC9-436C-9CE6-D474C583ADE9@netgate.com> References: <20061023163650.GA30024@zibbi.meraka.csir.co.za> <20061023211342.GA75533@ci0.org> <20061113140111.GA63047@zibbi.meraka.csir.co.za> <20061113143853.GA22089@ci0.org> <20061115091005.GA72236@zibbi.meraka.csir.co.za> <FBD13236-9CC9-436C-9CE6-D474C583ADE9@netgate.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Nov 15, 2006 at 01:01:59AM -1000, Jim Thompson wrote:
>
> On Nov 14, 2006, at 11:10 PM, John Hay wrote:
>
> >ERROR: hal.o uses FPA instructions, whereas kernel.debug does not
> >/home/jhay/cross/usr/bin/ld: failed to merge target specific data
> >of file hal.o
>
> You can't mix the two FP models. See these lines in contrib-arm.diff:
>
> +#undef TARGET_DEFAULT
> +#define TARGET_DEFAULT \
> + (ARM_FLAG_APCS_32 \
> + | ARM_FLAG_SOFT_FLOAT \
> + | ARM_FLAG_APCS_FRAME \
> + | ARM_FLAG_ATPCS \
> + | ARM_FLAG_VFP \
> + | ARM_FLAG_MMU_TRAPS \
> + | TARGET_ENDIAN_DEFAULT)
> +
> [...]
>
> + /* Default floating point model is soft-VFP.
> + * FIXME: -mhard-float currently implies FPA. */
> +#undef SUBTARGET_ASM_FLOAT_SPEC
> +#define SUBTARGET_ASM_FLOAT_SPEC \
> + "%{mhard-float:-mfpu=fpa} \
> + %{msoft-float:-mfpu=softvfp} \
> + %{!mhard-float: \
> + %{!msoft-float:-mfpu=softvfp}}"
>
> [...]
> + tdep->fp_model = ARM_FLOAT_SOFT_VFP;
>
>
> If you want the gory details, then I think they are as follows:
>
> - With no CPU specified the assembler assumes -msoft-fpa as a
> default, but it incorrectly marks the objects as being hard-fpa
> - With -mcpu=xscale the assembler defaults to -msoft-vfp and
> correctly marks the objects as such.
> - There's then no way to switch back to 'soft-fpa, but with the hard-
> fpa marking used by the default configuration.
>
> Did you add "--with-cpu=xscale" when you configured the (cross)
> compiler? If you do, you can drop the -mcpu=xscale
> when compiling.
>
> Its likely that Sam compiled the (uuencoded) xscale-be-elf.hal.o with
> the cross-compiler setup differently.
>
> Damn, I wish I had perforce access...
>
> Jim
>
Hi,
This is not John's fault, unfortunately right now the ath hal modules in
the src directory are compiled using FPA, while FreeBSD is compiled using
VFP.
You can use the small application at
http://people.freebsd.org/~sam/wackelf.c
to hack the ELF headers to make the hal binary VFP (it doesn't matter, because
it doesn't actually use FP).
Sam should update the hal modules soon.
Cheers,
Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061115121521.GA38995>