linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: "Maciej W. Rozycki" <macro@imgtec.com>
Cc: stable <stable@vger.kernel.org>,
	Linux MIPS Mailing List <linux-mips@linux-mips.org>,
	Ben Hutchings <ben@decadent.org.uk>,
	Li Zefan <lizefan@huawei.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4
Date: Fri, 20 May 2016 10:31:39 -0700	[thread overview]
Message-ID: <20160520173139.GB12632@roeck-us.net> (raw)
In-Reply-To: <alpine.DEB.2.00.1605161452100.6794@tp.orcam.me.uk>

On Fri, May 20, 2016 at 02:21:34PM +0100, Maciej W. Rozycki wrote:
> 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.
> 

binutils 2.25, any kernel supporting it (3.18+), mips:allnoconfig:

  CC      arch/mips/mm/sc-ip22.o

{standard input}: Assembler messages:
{standard input}:131: Error: number (0x9000000080000000) larger than 32 bits
{standard input}:154: Error: number (0x9000000080000000) larger than 32 bits
{standard input}:191: Error: number (0x9000000080000000) larger than 32 bits

There is assembler code in arch/mips/mm/sc-ip22.c which first sets "mips3"
(which I think is 32 bit) and then issues "dli\t$1, 0x9000000080000000\n\t",
which apparently the assembler in binutils 2.25 doesn't like.

---

binutils 2.24, mips:defconfig or mips:allnoconfig; Kernel 3.2.y or 3.4.y

arch/mips/mm/page.c:88:6: error: 'clear_page' alias in between function and variable is not supported
void clear_page(void *page) __attribute__((alias("clear_page_array")));

[there are several of those messages]

I can not really comment on microMIPS or not. Maybe some configurations do work
with binutils 2.24 and kernel versions 3.2 or 3.4. If so, I have not been able
to find them.

Builds with binutils 2.22 on recent kernels fail on and off (there was a failure
in -next a few days ago which has since then be fixed). Overall using it as
"default" builder is by now too fragile, which is why I dropped it as baseline
version. I now only build defconfig and allnoconfig with it as basic sanity test.

For qemu tests, I ended up using a combination of binutils 2.22, 2.24, and 2.25
depending on the kernel version. Previously I only used 2.22, but again that
is by now too risky. I can not just use 2.25 since it isn't supported in older
kernels (plus mips-gcc in Poky 2.0 seems to be buggy for mipsel64, or maybe that
compiler and qemu don't like each other), I can not just use 2.24 because it
isn't supported in 3.2 and 3.4, and I don't want to use 2.22 for recent kernels
since all tests may end up failing because some feature only available in later
versions of binutils was added to the kernel. 

Guenter

  reply	other threads:[~2016-05-20 17:31 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-16  2:56 Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4 Guenter Roeck
2016-05-20 13:21 ` Maciej W. Rozycki
2016-05-20 17:31   ` Guenter Roeck [this message]
2016-05-20 18:29     ` Maciej W. Rozycki
2016-05-20 23:18     ` James Hogan
2017-10-08 18:12 ` Ben Hutchings
2017-10-08 18:49   ` Guenter Roeck
2017-10-08 19:01     ` Guenter Roeck
2017-10-08 19:54       ` Ben Hutchings

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=20160520173139.GB12632@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=ben@decadent.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mips@linux-mips.org \
    --cc=lizefan@huawei.com \
    --cc=macro@imgtec.com \
    --cc=stable@vger.kernel.org \
    /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;
as well as URLs for NNTP newsgroup(s).