[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.00.1605161452100.6794@tp.orcam.me.uk>
Date: Fri, 20 May 2016 14:21:34 +0100
From: "Maciej W. Rozycki" <macro@...tec.com>
To: Guenter Roeck <linux@...ck-us.net>
CC: stable <stable@...r.kernel.org>,
Linux MIPS Mailing List <linux-mips@...ux-mips.org>,
Ben Hutchings <ben@...adent.org.uk>,
Li Zefan <lizefan@...wei.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: Building older mips kernels with different versions of binutils;
possible patch for 3.2 and 3.4
Hi Guenter,
> building mips images with a consistent infrastructure is becoming more and
> more difficult.
As the current MIPS binutils maintainer I am sorry to hear about this,
and apologise for the state of affairs. Of course I can't help with any
sins of the past, but at least I can help straightening out the current
situation and making sure that the most recent binutils work as expected.
> Current state is as follows.
>
> Binutils/ 2.22 2.24 2.25
> Kernel
> 3.2 X - -
> 3.4 X - -
> 3.10 X X -
> 3.14 X X -
> 3.16 X X -
> 3.18 X X (X) [1]
> 4.1 X X (X)
> 4.4 X X (X)
> 4.5 X X (X)
> 4.6 X X (X)
> next - X (X)
>
> [1] (at least) allnoconfig fails to build with binutils 2.25 (2.25.1, more
> specifically).
>
> I used the following toolchains for the above tests:
> - Poky 1.3 (binutils 2.22)
> - Poky 2.0 (binutils 2.25.1)
> - gcc-4.6.3-nolibc from kernel.org (binutils 2.22)
> - gcc-4.9.0-nolibc from kernel.org (binutils 2.24)
>
> For 3.4 and 3.2 kernels to build with binutils v2.24, it would be necessary to
> apply patch c02263063362 ("MIPS: Refactor 'clear_page' and 'copy_page'
> functions").
Mind that this change is really only needed to build microMIPS kernels,
only required for pure microMIPS hardware, i.e. processors which do not
support regular (aka AD 1985 classic) MIPS execution at all -- have you
been building such configurations? For mixed-mode processors a regular
MIPS kernel will do as it'll handle microMIPS userland just fine.
Or is there a hidden catch in this change beyond what's been stated in
the commit description?
> It applies cleanly to 3.4, but has a Makefile conflict in 3.2. It might
> make sense to apply this patch to both releases. Would this be possible ?
> This way, we would have at least one toolchain which can build all 3.2+
> kernels.
If you send me messages from build errors you think may be caused by an
incompatibility between the most recent binutils and kernel code, along
with a kernel GIT commit ID, then I'll investigate and see if this is a
problem on the binutils or the kernel side. I may need to ask for .config
in the process. If you have problems with older binutils, then I just
*might* be able to provide advice or a workaround, but my capabilities
beyond that may be limited, I'm a limited resource after all.
Maciej
Powered by blists - more mailing lists