From owner-freebsd-arm@FreeBSD.ORG Wed Nov 15 12:01:08 2006 Return-Path: X-Original-To: freebsd-arm@freebsd.org Delivered-To: freebsd-arm@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 7F38216A416; Wed, 15 Nov 2006 12:01:08 +0000 (UTC) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (cognet.ci0.org [80.65.224.102]) by mx1.FreeBSD.org (Postfix) with ESMTP id 4A7A543D4C; Wed, 15 Nov 2006 12:01:06 +0000 (GMT) (envelope-from mlfbsd@dong.ci0.org) Received: from dong.ci0.org (localhost.ci0.org [127.0.0.1]) by dong.ci0.org (8.13.7/8.13.4) with ESMTP id kAFCFMUS039066; Wed, 15 Nov 2006 13:15:22 +0100 (CET) (envelope-from mlfbsd@dong.ci0.org) Received: (from mlfbsd@localhost) by dong.ci0.org (8.13.7/8.13.4/Submit) id kAFCFLpi039065; Wed, 15 Nov 2006 13:15:21 +0100 (CET) (envelope-from mlfbsd) Date: Wed, 15 Nov 2006 13:15:21 +0100 From: Olivier Houchard To: Jim Thompson Message-ID: <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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Cc: freebsd-arm@freebsd.org, Sam Leffler Subject: Re: Gateworks 2348 any experience with it? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Nov 2006 12:01:08 -0000 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