avr32 build failures in linux-next

avr32 build failures in linux-next

[Guenter Roeck]

Hi,

I am getting persistent build failures with av32 in linux-next.

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.

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 ?

Another question is if the avr32 kernel still supported, or if I should
just stop trying to build test it. Any thoughts ?

Thanks,
Guenter

Re: avr32 build failures in linux-next

[Sudip Mukherjee]

On Friday 05 February 2016 09:32 PM, Guenter Roeck wrote:
> Hi,
>
> I am getting persistent build failures with av32 in linux-next.

me too.

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

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

Regards
Sudip

Re: avr32 build failures in linux-next

[Hans-Christian Noren Egtvedt]

Around Fri 05 Feb 2016 22:02:12 +0530 or thereabout, Sudip Mukherjee wrote:
> On Friday 05 February 2016 09:32 PM, Guenter Roeck wrote:
>>Hi,
>>
>>I am getting persistent build failures with av32 in linux-next.
> 
> me too.

linux-next is Torvalds master branch?

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

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

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

If it is too unstable for you in the test bench, feel free to remove it.

-- 
Best regards,
Hans-Christian Egtvedt

Re: avr32 build failures in linux-next

[Måns Rullgård]

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.

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

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

-- 
Måns Rullgård

Re: avr32 build failures in linux-next

[Guenter Roeck]

On 02/06/2016 03:57 AM, Hans-Christian Noren Egtvedt wrote:
> Around Fri 05 Feb 2016 22:02:12 +0530 or thereabout, Sudip Mukherjee wrote:
>> On Friday 05 February 2016 09:32 PM, Guenter Roeck wrote:
>>> Hi,
>>>
>>> I am getting persistent build failures with av32 in linux-next.
>>
>> me too.
>
> linux-next is Torvalds master branch?
>

No. We are talking about
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git

>>> 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.
>
>>> 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.
>
>>> 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.
>
> If it is too unstable for you in the test bench, feel free to remove it.
>

I'll keep building it for now, until it fails to build in mainline.

Guenter

Re: avr32 build failures in linux-next

[Guenter Roeck]

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.

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

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.

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

I'll stop building it after avr32:defconfig fails to build in mainline.

Guenter

Re: avr32 build failures in linux-next

[Måns Rullgård]

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

Re: avr32 build failures in linux-next

[Andy Shevchenko]

On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:

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

Once I tried up the topic about removal avr32 for good, but looks like
it wasn't a good time. Maybe now is better? It would really reduce a
burden on many drivers.

-- 
With Best Regards,
Andy Shevchenko

Re: avr32 build failures in linux-next

[Guenter Roeck]

On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
>
>> 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.
>
> Once I tried up the topic about removal avr32 for good, but looks like
> it wasn't a good time. Maybe now is better? It would really reduce a
> burden on many drivers.
>
I would agree, as long as the maintainers agree. We don't want to repeat
the h8300 experience.

Thanks,
Guenter

Re: avr32 build failures in linux-next

[Andy Shevchenko]

On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>
>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
>>
>>> 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.
>>
>>
>> Once I tried up the topic about removal avr32 for good, but looks like
>> it wasn't a good time. Maybe now is better? It would really reduce a
>> burden on many drivers.
>>
> I would agree, as long as the maintainers agree. We don't want to repeat
> the h8300 experience.

So, are we going to agree that avr32 must be retired from next cycle?

P.S. I have no idea how to fix this "…relocation truncated to fit:
R_AVR32_21S…", though I can test anything anyone propose.

-- 
With Best Regards,
Andy Shevchenko

Re: avr32 build failures in linux-next

[Måns Rullgård]

Andy Shevchenko <andy.shevchenko@gmail.com> writes:

> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>
>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
>>>
>>>> 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.
>>>
>>>
>>> Once I tried up the topic about removal avr32 for good, but looks like
>>> it wasn't a good time. Maybe now is better? It would really reduce a
>>> burden on many drivers.
>>>
>> I would agree, as long as the maintainers agree. We don't want to repeat
>> the h8300 experience.
>
> So, are we going to agree that avr32 must be retired from next cycle?
>
> P.S. I have no idea how to fix this "…relocation truncated to fit:
> R_AVR32_21S…", though I can test anything anyone propose.

I'd like to try fixing it before we delete anything.  At the very least,
it's always a good idea to figure out exactly why it broke, just to be
sure it isn't a broader issue that has yet to manifest itself elsewhere.

-- 
Måns Rullgård

Re: avr32 build failures in linux-next

[Sudip Mukherjee]

On Thursday 10 March 2016 01:20 AM, Måns Rullgård wrote:
> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>
>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>>
>>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
>>>>
>>>>> 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.
>>>>
>>>>
>>>> Once I tried up the topic about removal avr32 for good, but looks like
>>>> it wasn't a good time. Maybe now is better? It would really reduce a
>>>> burden on many drivers.
>>>>
>>> I would agree, as long as the maintainers agree. We don't want to repeat
>>> the h8300 experience.
>>
>> So, are we going to agree that avr32 must be retired from next cycle?
>>
>> P.S. I have no idea how to fix this "…relocation truncated to fit:
>> R_AVR32_21S…", though I can test anything anyone propose.
>
> I'd like to try fixing it before we delete anything.  At the very least,
> it's always a good idea to figure out exactly why it broke, just to be
> sure it isn't a broader issue that has yet to manifest itself elsewhere.
>

I will suggest keeping it for one more cycle and see if it can be fixed.

regards
sudip

Re: avr32 build failures in linux-next

[Måns Rullgård]

Andy Shevchenko <andy.shevchenko@gmail.com> writes:

> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>
>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
>>>
>>>> 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.
>>>
>>>
>>> Once I tried up the topic about removal avr32 for good, but looks like
>>> it wasn't a good time. Maybe now is better? It would really reduce a
>>> burden on many drivers.
>>>
>> I would agree, as long as the maintainers agree. We don't want to repeat
>> the h8300 experience.
>
> So, are we going to agree that avr32 must be retired from next cycle?
>
> P.S. I have no idea how to fix this "…relocation truncated to fit:
> R_AVR32_21S…", though I can test anything anyone propose.

The error goes away if CONFIG_AIO_THREAD is disabled.  Still don't know why.

-- 
Måns Rullgård

Re: avr32 build failures in linux-next

[Andy Shevchenko]

On Thu, Mar 10, 2016 at 3:38 PM, Måns Rullgård <mans@mansr.com> wrote:
> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>
>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>>
>>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
>>>>
>>>>> 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.
>>>>
>>>>
>>>> Once I tried up the topic about removal avr32 for good, but looks like
>>>> it wasn't a good time. Maybe now is better? It would really reduce a
>>>> burden on many drivers.
>>>>
>>> I would agree, as long as the maintainers agree. We don't want to repeat
>>> the h8300 experience.
>>
>> So, are we going to agree that avr32 must be retired from next cycle?
>>
>> P.S. I have no idea how to fix this "…relocation truncated to fit:
>> R_AVR32_21S…", though I can test anything anyone propose.
>
> The error goes away if CONFIG_AIO_THREAD is disabled.  Still don't know why.

A straight guess: it has reduced enough room to fit the relocation window?
Anyway confirm that after disabling that kernel builds as usual.

-- 
With Best Regards,
Andy Shevchenko

Re: avr32 build failures in linux-next

[Måns Rullgård]

Andy Shevchenko <andy.shevchenko@gmail.com> writes:

> On Thu, Mar 10, 2016 at 3:38 PM, Måns Rullgård <mans@mansr.com> wrote:
>> Andy Shevchenko <andy.shevchenko@gmail.com> writes:
>>
>>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>>>> On 02/08/2016 08:06 AM, Andy Shevchenko wrote:
>>>>>
>>>>> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
>>>>>
>>>>>> 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.
>>>>>
>>>>>
>>>>> Once I tried up the topic about removal avr32 for good, but looks like
>>>>> it wasn't a good time. Maybe now is better? It would really reduce a
>>>>> burden on many drivers.
>>>>>
>>>> I would agree, as long as the maintainers agree. We don't want to repeat
>>>> the h8300 experience.
>>>
>>> So, are we going to agree that avr32 must be retired from next cycle?
>>>
>>> P.S. I have no idea how to fix this "…relocation truncated to fit:
>>> R_AVR32_21S…", though I can test anything anyone propose.
>>
>> The error goes away if CONFIG_AIO_THREAD is disabled.  Still don't know why.
>
> A straight guess: it has reduced enough room to fit the relocation window?

That was my first guess as well, but it was wrong.  See the patch I just
sent for an explanation.

-- 
Måns Rullgård

Re: avr32 build failures in linux-next

[One Thousand Gnomes]

On Wed, 9 Mar 2016 21:30:55 +0200
Andy Shevchenko <andy.shevchenko@gmail.com> wrote:

> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@roeck-us.net> wrote:
> > On 02/08/2016 08:06 AM, Andy Shevchenko wrote:  
> >>
> >> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
> >>  
> >>> 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.  
> >>
> >>
> >> Once I tried up the topic about removal avr32 for good, but looks like
> >> it wasn't a good time. Maybe now is better? It would really reduce a
> >> burden on many drivers.
> >>  
> > I would agree, as long as the maintainers agree. We don't want to repeat
> > the h8300 experience.  
> 
> So, are we going to agree that avr32 must be retired from next cycle?
> 
> P.S. I have no idea how to fix this "…relocation truncated to fit:
> R_AVR32_21S…", though I can test anything anyone propose.

It means the AVR32 tool chain generated a 21bit signed code relocation
then couldn't fix it up at link time. This probably simply means that
something called through anon_inode_getfile() is now more than 1MB away
from the call location, in which case you'll just need to debloat the
kernel until it fits again or re-order the link to cure it (if I had to
guess it'll be some kind of support function call and the compiler
support tends to end up one end of the binary not in the middle).

Could also be a linker bug (AVR32 has a few) or the toolchain writing
crap (check the .S file)

Unfortunately I don't believe the AVR32 binutils is bright enough to fix
up such relocations with a more locally inserted branch to set up a
branch to a 32bit target (which is not pretty). Reordering the link might
help if it happens to move the problem routines nearer each other but
it's not a real fix.

Alan

Re: avr32 build failures in linux-next

[Måns Rullgård]

One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> writes:

> On Wed, 9 Mar 2016 21:30:55 +0200
> Andy Shevchenko <andy.shevchenko@gmail.com> wrote:
>
>> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <linux@roeck-us.net> wrote:
>> > On 02/08/2016 08:06 AM, Andy Shevchenko wrote:  
>> >>
>> >> On Sat, Feb 6, 2016 at 7:28 PM, Måns Rullgård <mans@mansr.com> wrote:
>> >>  
>> >>> 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.  
>> >>
>> >>
>> >> Once I tried up the topic about removal avr32 for good, but looks like
>> >> it wasn't a good time. Maybe now is better? It would really reduce a
>> >> burden on many drivers.
>> >>  
>> > I would agree, as long as the maintainers agree. We don't want to repeat
>> > the h8300 experience.  
>> 
>> So, are we going to agree that avr32 must be retired from next cycle?
>> 
>> P.S. I have no idea how to fix this "…relocation truncated to fit:
>> R_AVR32_21S…", though I can test anything anyone propose.
>
> It means the AVR32 tool chain generated a 21bit signed code relocation
> then couldn't fix it up at link time. This probably simply means that
> something called through anon_inode_getfile() is now more than 1MB away
> from the call location, in which case you'll just need to debloat the
> kernel until it fits again or re-order the link to cure it (if I had to
> guess it'll be some kind of support function call and the compiler
> support tends to end up one end of the binary not in the middle).

It turned out to be a wrong asm operand constraint in cmpxchg().  Patch
already sent.

-- 
Måns Rullgård

Re: avr32 build failures in linux-next

[Andy Shevchenko]

On Thu, Mar 10, 2016 at 4:31 PM, Måns Rullgård <mans@mansr.com> wrote:
> It turned out to be a wrong asm operand constraint in cmpxchg().  Patch
> already sent.

I will temporary apply it to my tree  [1] as well.
By the way, I have updated (were one bug in my newly introduced fix)
and tested the series on Intel with UART, PPC with SATA, and AVR32
with plain dmatest. So far so good.

[1] https://bitbucket.org/andy-shev/linux/branch/topic%2Fdw%2Fsata

-- 
With Best Regards,
Andy Shevchenko