From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id 5BE15B6EE7 for ; Mon, 2 Apr 2012 12:02:13 +1000 (EST) Message-ID: <1333332115.30734.27.camel@pasglop> Subject: Re: kilauea compilation breaks with v3.3 kernel and ELDK 4.2 From: Benjamin Herrenschmidt To: "Frank E." =?ISO-8859-1?Q?Svendsb=F8e?= Date: Mon, 02 Apr 2012 12:01:55 +1000 In-Reply-To: <20120401221359.GA31730@gnubox> References: <4F69C553.6070409@gmail.com> <20120321162549.8C1D0202A4D@gemini.denx.de> <1332633218.2882.16.camel@pasglop> <1333152184.30734.3.camel@pasglop> <20120401221359.GA31730@gnubox> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Cc: linuxppc-dev@ozlabs.org, Wolfgang Denk , robert.karl.berger@gmail.com List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Mon, 2012-04-02 at 00:14 +0200, Frank E. Svendsbøe wrote: > On Sat, Mar 31, 2012 at 11:03:04AM +1100, Benjamin Herrenschmidt wrote: > > On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote: > > > > > Hi Josh Boyer, > > > > > > just wanted to add that I'm experiencing the same problem that Robert > > > reported, but on 8xx instead of 4xx. The mpc8xx does not support the > > > mfdcrx instruction, so maybe it's more to it than just a binutils bug? > > > > The kernel shouldn't have tried to build that instruction on 8xx, though > > I suppose if it's in arch/powerpc/boot, we are a bit too eager at > > building everything including what's not relevant, we might to be a bit > > more careful at excluding 4xx stuff on a 8xx kernel. > > > > Yes. I agree on Wolfgangs statement regarding not building code we > don't want/need. Please explain to me why src-wlib/src-plat in > arch/powerpc/boot/Makefile includes every ppc target... Ok, I've asked Tony to have a look at splitting the build decision in arch/powerpc/boot along the same lines as the CPU families... ie only wrappers for platforms potentially supported by the built kernel. That should fix it. Cheers, Ben.