Gateworks 2348 any experience with it?

Jim Thompson jim at netgate.com
Wed Nov 15 11:02:22 UTC 2006


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



More information about the freebsd-arm mailing list