mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Måns Rullgård" <mans@mansr.com>
To: Guenter Roeck <linux@roeck-us.net>
Cc: Hans-Christian Noren Egtvedt <egtvedt@samfundet.no>,
	Sudip Mukherjee <sudipm.mukherjee@gmail.com>,
	Haavard Skinnemoen <hskinnemoen@gmail.com>,
	"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: avr32 build failures in linux-next
Date: Sat, 06 Feb 2016 17:28:37 +0000	[thread overview]
Message-ID: <yw1xoabtg33u.fsf@unicorn.mansr.com> (raw)
In-Reply-To: <56B61D21.2010407@roeck-us.net> (Guenter Roeck's message of "Sat, 6 Feb 2016 08:19:45 -0800")

Guenter Roeck <linux@roeck-us.net> writes:

> On 02/06/2016 06:01 AM, Måns Rullgård wrote:
>> Hans-Christian Noren Egtvedt <egtvedt@samfundet.no> writes:
>>
>>>>> Example for avr32:defconfig:
>>>>>
>>>>> fs/built-in.o: In function `anon_inode_getfile':
>>>>> (.text+0x2ae90): relocation truncated to fit: R_AVR32_21S against
>>>>> `.text'+296c0
>>>>>
>>>>> All builds but avr32:allnoconfig fail with such truncated relocations.
>>>
>>> Weirdly I do not get this when I build torvalds/master with allnoconfig.
>>>
>>> The avr32 kernel was never very fond of CONFIG_CC_OPTIMIZE_FOR_SIZE=n, it
>>> was always built with CONFIG_CC_OPTIMIZE_FOR_SIZE=y for actual usage.
>>
>> 4.5-rc1 builds and runs with CONFIG_CC_OPTIMIZE_FOR_SIZE=n here.  It's a
>> fairly minimal config though.
>>
>
> 4.5-rcX is not the problem. I was talking about linux-next.

I know, I was merely providing another data point.

> Disabling CONFIG_CC_OPTIMIZE_FOR_SIZE does not make a difference. Same
> problem.
>
>>>>> Toolchain used is the old gcc 4.2.4 toolchain from kernel.org. I have been
>>>>> unable to find or build newer versions of gcc for avr32.
>>>>>
>>>>> Does anyone know if a more recent toolchain for avr32 is available ?
>>>>
>>>> https://sourceware.org/ml/crossgcc/2015-10/msg00050.html
>>>> says avr32 has been depreciated.
>>>
>>> Last release of avr32-linux GCC was the 4.2.4 patches in Buildroot
>>> for AVR32.
>>>
>>> Atmel never upstreamed the AVR32 patches for GCC.
>>
>> There are patches for gcc 4.4.3 at
>> http://distribute.atmel.no/tools/opensource/avr32-gcc/
>> The patches apply with only trivial fixes to 4.4.7 as well.  I tried
>> forward-porting to something newer, but my knowledge gcc internal voodoo
>> wasn't sufficient.
>>
> I managed to build avr32 gcc 4.4.7 from
> http://distribute.atmel.no/tools/opensource/Atmel-AVR32-GNU-Toolchain/3.4.3/
> after making a couple of changes in the gcc source to make its first
> stage build with a recent version of gcc (looks like one can not build
> gcc 4.4.7 with gcc 5.2 without fixing it up first ;-).
>
> No difference. If anything, the situation is worse, since it produces lots of
>
> avr32-ld:built in linker script:15: warning: memory region `FLASH' not declared
> avr32-ld:built in linker script:140: warning: memory region `CPUSRAM' not declared

That looks like you're trying to use a toolchain configured for bare
metal uC environment.

> in addition to the final 'relocation truncated to fit' error.
>
> Since the message is produced by the linker, maybe this isn't even a compiler
> problem but a problem with binutils.

"Relocation truncated to fit" usually means the compiler used a relative
addressing mode to access something that ended up being too far away in
the final link.  Sometimes this is caused by using compiler flags for a
"small" memory model (text+data less than some limit) when a "large"
setting should have been used due to the size of the thing being built.
That's not the case here, however, since there are no such flags for
AVR32.  This means it's most likely either a compiler bug or a bug in
hand-written assembly code.

>>>>> Another question is if the avr32 kernel still supported, or if I should
>>>>> just stop trying to build test it. Any thoughts ?
>>>>
>>>> I have already stopped building it.
>>>
>>> I build the kernel and try to fix small issues here and there.
>>
>> Even when it builds, it often doesn't work since non-DT support has
>> bitrotted in many drivers.
>>
> Not very encouraging.

Not very surprising either.  The number of people using Linux on avr32
is probably approximately zero, and if anyone is, they're likely still
running 2.6.32 or thereabouts.

-- 
Måns Rullgård

  reply	other threads:[~2016-02-06 17:28 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-05 16:02 Guenter Roeck
2016-02-05 16:32 ` Sudip Mukherjee
2016-02-06 11:57   ` Hans-Christian Noren Egtvedt
2016-02-06 14:01     ` Måns Rullgård
2016-02-06 16:19       ` Guenter Roeck
2016-02-06 17:28         ` Måns Rullgård [this message]
2016-02-08 16:06           ` Andy Shevchenko
2016-02-09  4:02             ` Guenter Roeck
2016-03-09 19:30               ` Andy Shevchenko
2016-03-09 19:50                 ` Måns Rullgård
2016-03-10  4:55                   ` Sudip Mukherjee
2016-03-10 13:38                 ` Måns Rullgård
2016-03-10 13:53                   ` Andy Shevchenko
2016-03-10 14:24                     ` Måns Rullgård
2016-03-10 14:29                 ` One Thousand Gnomes
2016-03-10 14:31                   ` Måns Rullgård
2016-03-10 15:10                     ` Andy Shevchenko
2016-02-06 15:50     ` Guenter Roeck

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=yw1xoabtg33u.fsf@unicorn.mansr.com \
    --to=mans@mansr.com \
    --cc=egtvedt@samfundet.no \
    --cc=hskinnemoen@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=sudipm.mukherjee@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®