Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753080AbcCGQoM (ORCPT ); Mon, 7 Mar 2016 11:44:12 -0500 Received: from muru.com ([72.249.23.125]:48101 "EHLO muru.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752516AbcCGQoB (ORCPT ); Mon, 7 Mar 2016 11:44:01 -0500 Date: Mon, 7 Mar 2016 08:43:57 -0800 From: Tony Lindgren To: Arnd Bergmann Cc: Brian Norris , David Woodhouse , linux-arm-kernel@lists.infradead.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org Subject: Re: [PATCH] mtd: only use __xipram annotation when XIP_KERNEL is set Message-ID: <20160307164356.GB9329@atomide.com> References: <1453736525-1959191-2-git-send-email-arnd@arndb.de> <5158260.vK2YuWzYIn@wuerfel> <20160305002203.GF55664@google.com> <3185882.WT2d08mtAT@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3185882.WT2d08mtAT@wuerfel> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3085 Lines: 62 * Arnd Bergmann [160304 16:34]: > On Friday 04 March 2016 16:22:03 Brian Norris wrote: > > Hi Arnd, > > > > On Sat, Mar 05, 2016 at 01:19:21AM +0100, Arnd Bergmann wrote: > > > On Friday 04 March 2016 16:02:25 Brian Norris wrote: > > > > On Mon, Jan 25, 2016 at 04:41:50PM +0100, Arnd Bergmann wrote: > > > > > When XIP_KERNEL is enabled, some functions are defined in the .data > > > > > ELF section because we require them to be in RAM whenever we communicate > > > > > with the flash chip. However this causes problems when FTRACE is > > > > > enabled and gcc emits calls to __gnu_mcount_nc in the function > > > > > prolog: > > > > > > > > > > drivers/built-in.o: In function `cfi_chip_setup': > > > > > :(.data+0x272fc): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o > > > > > drivers/built-in.o: In function `cfi_probe_chip': > > > > > :(.data+0x27de8): relocation truncated to fit: R_ARM_CALL against symbol `__gnu_mcount_nc' defined in .text section in arch/arm/kernel/built-in.o > > > > > /tmp/ccY172rP.s: Assembler messages: > > > > > /tmp/ccY172rP.s:70: Warning: ignoring changed section attributes for .data > > > > > /tmp/ccY172rP.s: Error: 1 warning, treating warnings as errors > > > > > make[5]: *** [drivers/mtd/chips/cfi_probe.o] Error 1 > > > > > /tmp/ccK4rjeO.s: Assembler messages: > > > > > /tmp/ccK4rjeO.s:421: Warning: ignoring changed section attributes for .data > > > > > /tmp/ccK4rjeO.s: Error: 1 warning, treating warnings as errors > > > > > make[5]: *** [drivers/mtd/chips/cfi_util.o] Error 1 > > > > > /tmp/ccUvhCYR.s: Assembler messages: > > > > > /tmp/ccUvhCYR.s:1895: Warning: ignoring changed section attributes for .data > > > > > /tmp/ccUvhCYR.s: Error: 1 warning, treating warnings as errors > > > > > > > > Can you provide a sample .config that DOES build correctly with > > > > XIP_KERNEL enabled + this patch? My first attempt yields some other > > > > failures I don't care to fixup right now... > > > > > > > > Anyway, I don't doubt you have a good fix here, so I can probably take > > > > it. Any review from others would be welcome though. > > > > > > I found the config in the attachment in my logs. > > > > Thanks... > > > > > To get this config working, I also needed this hunk from my set of > > > old unsubmitted patches: > > > > ...but, does anyone care about XIP / MTD_XIP then, if the first two > > examples we have both have long-standing build issues? > > > > Probably not. I just checked the third user (omap1), and it seems that one > has been broken since 2009 with 941132606c76 ("OMAP: Remove OMAP_IO_ADDRESS, > use OMAP1_IO_ADDRESS and OMAP2_IO_ADDRESS instead"), when Tony replaced > the inline omap_readl() with an extern function, thus breaking the > implementation of xip_irqpending() that must be inlined. > > The other two have apparently been broken since 2011, by other patches > that also broke compilation. For omaps, I don't recall anybody working on xip for probably close to 10 years. Regards, Tony