From owner-freebsd-arm@FreeBSD.ORG Thu Apr 17 12:49:26 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 132D690F for ; Thu, 17 Apr 2014 12:49:26 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D914217A4 for ; Thu, 17 Apr 2014 12:49:25 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1Walkq-000Gg9-UG; Thu, 17 Apr 2014 12:49:25 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s3HCnLqf003242; Thu, 17 Apr 2014 06:49:21 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+cmEjErxZHRWWDSPF1Jj2t Subject: Re: Building an ARM/RPI-B release (hacked) on CURRENT/AMD64. From: Ian Lepore To: ticso@cicely.de In-Reply-To: <20140417103117.GE44138@cicely7.cicely.de> References: <9FDD6F0E-B2A9-48D9-A3E4-181868995FDA@grondar.org> <20140417103117.GE44138@cicely7.cicely.de> Content-Type: text/plain; charset="us-ascii" Date: Thu, 17 Apr 2014 06:49:21 -0600 Message-ID: <1397738961.1124.157.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: Tim Kientzle , freebsd-arm , Mark R V Murray X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Apr 2014 12:49:26 -0000 On Thu, 2014-04-17 at 12:31 +0200, Bernd Walter wrote: > On Wed, Apr 16, 2014 at 06:25:39PM -0700, Tim Kientzle wrote: > > > > On Apr 15, 2014, at 12:23 PM, Mark R V Murray wrote: > > > > > Hi Tim > > > > > > I?ve been doing some local hacks to cross-build ARM/RPI releases on CURRENT/AMD64. > > > > > > What I?m doing aren?t clean releases in that I want to use the state of /usr/src and /usr/ports ?as-is? and not a clean check out. This allows me to experimentally break stuff without having to check it in first. It also give me a way to build bootable images for when (not ?if?!) I mess things up properly on the RPI. It has the advantage also of being quicker than the usual release build. > > > > > > (The hacks, as they stand now, are attached. I null-mount /usr/src and /usr/ports instead of checking them out, and I have local checkouts of crochet and u-boot to copy as checking them out during a release build fails too often.) > > > > > > The problem is that sometime in the last month or so, things stopped working, and its taken me until now to have the time to have a look at it. > > > > > > The problem is that during the u-boot build, a CLANG-based xdev build is used, and this has no *-gcc, only a *-cc. If I fix that with a symlink, clang then objects to the -ffixed-r8 option. Clang has an equivalent -ffixed-r9, but the u-boot that is mandated for FreeBSD/Arm/RPI use doesn?t have the R9 fix. > > > > > > Questions: > > > > > > 1) Are you aware of any of this? > > > > Yes. > > > > > > > > 2) Do you have a quick fix idea (preferably not involving GCC)? > > > > No. > > > > Right now, the ?get it working? answer is to install GCC XDEV tools. > > > > Though I tried that on a clean system last weekend and it > > still failed to build. Haven?t tracked down why. > > > > > > > > I?m rather short of time right now, but may be able to get to this over Easter. > > > > Long-term, we?d all like to see U-Boot build with clang. > > > > No idea yet whether that?s hard or not. No idea if > > I?ll have time to work on it in the near future. > > What are the symptoms with clang U-Boot? > U-boot requires that a global register be set aside by the compiler and it's used to access all global vars. As I vaguely understand it, u-boot used to want r8 for this, and clang didn't used to support the concept at all. Now clang supports it, but only for r9, and apparently more recent u-boot expects r9 rather than r8. So the fix is probably to use more recent u-boot sources (I've been using 2014.01 for imx6 stuff), and probably to add the new -ffixed-r9 flag for a clang build. -- Ian