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
