Re: Building older mips kernels with different versions of binutils; possible patch for 3.2 and 3.4

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux MIPS Home]     [LKML Archive]     [Linux ARM Kernel]     [Linux ARM]     [Linux]     [Git]     [Yosemite News]     [Linux SCSI]     [Linux Hams]

  Powered by Linux