From owner-freebsd-arm@FreeBSD.ORG Thu May 22 15:52:14 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8DC09D3C; Thu, 22 May 2014 15:52:14 +0000 (UTC) Received: from zibbi.meraka.csir.co.za (zibbi.meraka.csir.co.za [IPv6:2001:4200:7000:2::1]) by mx1.freebsd.org (Postfix) with ESMTP id CB3F82010; Thu, 22 May 2014 15:52:13 +0000 (UTC) Received: by zibbi.meraka.csir.co.za (Postfix, from userid 3973) id CB86AB828; Thu, 22 May 2014 17:52:10 +0200 (SAST) Date: Thu, 22 May 2014 17:52:10 +0200 From: John Hay To: Warner Losh Subject: Re: MK_ARM_EABI to retire in current Message-ID: <20140522155210.GA57720@zibbi.meraka.csir.co.za> References: <20140521192807.GA48338@zibbi.meraka.csir.co.za> <95AD97BA-AA48-4BBF-845C-D0CB585ACAA3@bsdimp.com> <20140522090504.GA22488@zibbi.meraka.csir.co.za> <5D4F0BD5-89DA-421F-B095-A5F2C49F3DF9@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5D4F0BD5-89DA-421F-B095-A5F2C49F3DF9@bsdimp.com> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 May 2014 15:52:14 -0000 On Thu, May 22, 2014 at 08:07:34AM -0600, Warner Losh wrote: > > On May 22, 2014, at 3:05 AM, John Hay wrote: > > > On Wed, May 21, 2014 at 02:01:42PM -0600, Warner Losh wrote: > >> > >> On May 21, 2014, at 1:28 PM, John Hay wrote: > >> > >>> On Mon, May 19, 2014 at 09:50:21AM -0700, Adrian Chadd wrote: > >>>> isn't eabi on the xscale still broken? > >>> > >>> It might still be broken. But there are more brokenness than that. :-( > >>> By defining WITHOUT_ARM_EABI=yes in src.conf, I can get an AVILA kernel > >>> built that boots with src from head at around mid December. Latest 10 > >>> and head just give no output, with or without WITHOUT_ARM_EABI defined. > >> > >> Does the same thing happen with make.conf instead of src.conf? > > > > Yes, I have tried both 10 and head with WITHOUT_ARM_EABI=yes and no > > output after go in redboot. My compile lines look like this: > > > > make TARGET_ARCH=armeb TARGET_CPUTYPE=xscale toolchain > > make TARGET=arm TARGET_ARCH=armeb buildkernel KERNCONF=AVILA DESTDIR=/arm/ > > > > And then in redboot "load -b 0x200000 kernel" to load it with tftp. And > > then "go". > > > > The "no output" happened somewhere between mid December and beginning > > of Feb. I determined that before getting side tracked. I'll see in the > > next day or two if I can narrow that down. > > > > If someone have patches so that WITHOUT_ARM_EABI=yes is not needed > > anymore, I'll test that too. > > This is with gcc, not clang, right? The default that the tree will do for the above commands. I did not force it one way or the other. The kernels that did boot, reported gcc 4.2.1 John > > Warner > > > > John > > > >> > >> Warner > >> > >>> John > >>> > >>>> > >>>> > >>>> -a > >>>> > >>>> > >>>> On 19 May 2014 08:40, Warner Losh wrote: > >>>>> Greetings, > >>>>> > >>>>> MK_ARM_EABI is going to die in current. It is the default for all platforms currently. I???m eliminating it as a build option. It must die because it invisibly (to uname) effects the ABI. > >>>>> > >>>>> So, to that end, I see two options: > >>>>> > >>>>> (1) Retire and remove oabi support. > >>>>> (2) Retain oabi support, but change its name to armo and armoeb. > >>>>> > >>>>> The rough consensus of arm developers I???ve polled now, and in the past, is that we just let oabi support die now that EABI support is working for everybody. > >>>>> > >>>>> Before I pull the trigger on this, however, I must ask if anybody has a problem with my doing option (1), and if so, what keeps you using oabi. > >>>>> > >>>>> Comments? > >>>>> > >>>>> Warner > >>>>> > >>>>> _______________________________________________ > >>>>> freebsd-arm@freebsd.org mailing list > >>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > >>>> _______________________________________________ > >>>> freebsd-arm@freebsd.org mailing list > >>>> http://lists.freebsd.org/mailman/listinfo/freebsd-arm > >>>> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"