On Wed, 9 Mar 2016 21:30:55 +0200 Andy Shevchenko <andy.shevche...@gmail.com> wrote:
> On Tue, Feb 9, 2016 at 6:02 AM, Guenter Roeck <li...@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 <m...@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
