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