Date: Wed, 15 Nov 2006 07:51:14 -0800 From: Sam Leffler <sam@errno.com> To: John Hay <jhay@meraka.org.za> Cc: freebsd-arm@freebsd.org Subject: Re: Gateworks 2348 any experience with it? Message-ID: <455B3772.2020403@errno.com> In-Reply-To: <20061115121521.GA38995@ci0.org> 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> <20061115121521.GA38995@ci0.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Olivier Houchard wrote:
> 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.
Correct. Newer versions of the hal will come ready for use but for now
you need to patch the ELF header. I'll work on getting a newer hal
together than can be dropped in in-place.
The rest of the avila support code should appear in HEAD this week. I'm
trying to cleanup some stuff beforehand to avoid churning the repo once
it hits CVS.
Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?455B3772.2020403>