avr32 build failures in linux-next
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
Quoted 3 lines · Guenter Roeck
Hi,
I am getting persistent build failures with av32 in linux-next.
me too.
Quoted 7 lines
Example for avr32:defconfig:
fs/built-in.o: In function `anon_inode_getfile':
(.text+0x2ae90): relocation truncated to fit:R_AVR32_21Sagainst `.text'+296c0
Quoted 6 lines
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.
Quoted 3 lines
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
Quoted 6 lines · Sudip Mukherjee
Quoted 3 lines · Guenter Roeck
Hi,
I am getting persistent build failures with av32 in linux-next.
me too.
linux-next is Torvalds master branch?
Quoted 7 lines
Quoted 7 lines
Example for avr32:defconfig:
fs/built-in.o: In function `anon_inode_getfile':
(.text+0x2ae90): relocation truncated to fit:R_AVR32_21Sagainst `.text'+296c0All 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.
Quoted 7 lines
Quoted 4 lines
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.
Quoted 4 lines
Quoted 2 lines
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.
Signature · 2 lines
Best regards, Hans-Christian Egtvedt
Quoted 6 lines · Hans-Christian Noren Egtvedt
Quoted 6 lines
Quoted 6 lines
Example for avr32:defconfig:
fs/built-in.o: In function `anon_inode_getfile':
(.text+0x2ae90): relocation truncated to fit:R_AVR32_21Sagainst `.text'+296c0
Quoted 6 lines
Quoted 1 line
Quoted 1 line
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 withCONFIG_CC_OPTIMIZE_FOR_SIZE=yfor actual usage.
4.5-rc1 builds and runs with CONFIG_CC_OPTIMIZE_FOR_SIZE=n here. It's a fairly minimal config though.
Quoted 11 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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.
Signature · 1 line
Måns Rullgård
Quoted 10 lines · Måns Rullgård
Quoted 8 lines · Hans-Christian Noren Egtvedt
Quoted 7 lines
Quoted 7 lines
Example for avr32:defconfig:
fs/built-in.o: In function `anon_inode_getfile':
(.text+0x2ae90): relocation truncated to fit:R_AVR32_21Sagainst `.text'+296c0All builds but avr32:allnoconfig fail with such truncated relocations.
Quoted 8 lines
Quoted 4 lines
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 withCONFIG_CC_OPTIMIZE_FOR_SIZE=yfor actual usage.4.5-rc1 builds and runs with
CONFIG_CC_OPTIMIZE_FOR_SIZE=nhere. 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.
Quoted 10 lines
Quoted 10 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
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.
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 13 lines · Guenter Roeck
Quoted 12 lines · Måns Rullgård
Quoted 10 lines · Hans-Christian Noren Egtvedt
Quoted 7 lines
Quoted 7 lines
Example for avr32:defconfig:
fs/built-in.o: In function `anon_inode_getfile':
(.text+0x2ae90): relocation truncated to fit:R_AVR32_21Sagainst `.text'+296c0All builds but avr32:allnoconfig fail with such truncated relocations.
Weirdly I do not get this when I build torvalds/master with allnoconfig.
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
The avr32 kernel was never very fond of
CONFIG_CC_OPTIMIZE_FOR_SIZE=n, it was always built withCONFIG_CC_OPTIMIZE_FOR_SIZE=yfor actual usage.4.5-rc1 builds and runs with
CONFIG_CC_OPTIMIZE_FOR_SIZE=nhere. 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.
Quoted 28 lines
Disabling
CONFIG_CC_OPTIMIZE_FOR_SIZEdoes not make a difference. Same problem.Quoted 11 lines
Quoted 11 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 8 lines
Quoted 1 line
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 ;-).
Quoted 4 lines
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 regionCPUSRAM' not declared
That looks like you're trying to use a toolchain configured for bare metal uC environment.
Quoted 4 lines
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.
Quoted 11 lines
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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.
Signature · 1 line
Måns Rullgård
Quoted 3 lines · Måns Rullgård
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.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 10 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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
Quoted 9 lines · Guenter Roeck
Quoted 8 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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.
Quoted 6 lines
Quoted 4 lines
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.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 14 lines · Andy Shevchenko
Quoted 13 lines · Guenter Roeck
Quoted 12 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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.
Quoted 7 lines
Quoted 2 lines
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.
Signature · 1 line
Måns Rullgård
Quoted 19 lines · Måns Rullgård
Quoted 17 lines · Andy Shevchenko
Quoted 15 lines · Guenter Roeck
Quoted 12 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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.
Quoted 9 lines
Quoted 4 lines
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
Quoted 14 lines · Andy Shevchenko
Quoted 13 lines · Guenter Roeck
Quoted 12 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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.
Quoted 7 lines
Quoted 2 lines
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.
Signature · 1 line
Måns Rullgård
Quoted 19 lines · Måns Rullgård
Quoted 17 lines · Andy Shevchenko
Quoted 15 lines · Guenter Roeck
Quoted 12 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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.
Quoted 6 lines
Quoted 4 lines
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_THREADis 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.
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 20 lines · Andy Shevchenko
Quoted 19 lines · Måns Rullgård
Quoted 17 lines · Andy Shevchenko
Quoted 15 lines · Guenter Roeck
Quoted 12 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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.
Quoted 8 lines
Quoted 6 lines
Quoted 4 lines
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_THREADis 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.
Signature · 1 line
Måns Rullgård
Quoted 14 lines · On Wed, 9 Mar 2016 21:30:55 +0200 Andy Shevchenko <[email protected]>…
Quoted 13 lines · Guenter Roeck
Quoted 12 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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.
Quoted 7 lines
Quoted 2 lines
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
Quoted 25 lines · One Thousand Gnomes
Quoted 14 lines · On Wed, 9 Mar 2016 21:30:55 +0200 Andy Shevchenko <[email protected]>…
Quoted 13 lines · Guenter Roeck
Quoted 12 lines · Andy Shevchenko
Quoted 3 lines · Måns Rullgård
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.
Quoted 7 lines
Quoted 2 lines
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.
Quoted 7 lines
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.
Signature · 1 line
Måns Rullgård
Quoted 2 lines · Måns Rullgård
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
Signature · 2 lines
With Best Regards, Andy Shevchenko
Quoted 10 lines · Hans-Christian Noren Egtvedt
Quoted 6 lines · Sudip Mukherjee
Quoted 3 lines · Guenter Roeck
Hi,
I am getting persistent build failures with av32 in linux-next.
me too.
linux-next is Torvalds master branch?
No. We are talking aboutgit://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Quoted 25 lines
Quoted 7 lines
Quoted 7 lines
Example for avr32:defconfig:
fs/built-in.o: In function `anon_inode_getfile':
(.text+0x2ae90): relocation truncated to fit:R_AVR32_21Sagainst `.text'+296c0All 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 withCONFIG_CC_OPTIMIZE_FOR_SIZE=yfor actual usage.Quoted 7 lines
Quoted 4 lines
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.
Quoted 9 lines
Quoted 4 lines
Quoted 2 lines
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