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:

quoted

On Friday 04 March 2016 16:02:25 Brian Norris wrote:

quoted

On Mon, Jan 25, 2016 at 04:41:50PM +0100, Arnd Bergmann wrote:

quoted

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...

quoted

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.

	Arnd