Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 15 Nov 2006 01:01:59 -1000
From:      Jim Thompson <jim@netgate.com>
To:        John Hay <jhay@meraka.org.za>
Cc:        freebsd-arm@freebsd.org
Subject:   Re: Gateworks 2348 any experience with it?
Message-ID:  <FBD13236-9CC9-436C-9CE6-D474C583ADE9@netgate.com>
In-Reply-To: <20061115091005.GA72236@zibbi.meraka.csir.co.za>
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>

next in thread | previous in thread | raw e-mail | index | archive | help

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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?FBD13236-9CC9-436C-9CE6-D474C583ADE9>