From: Robert Berger <hidden> Date: 2012-03-21 12:11:08
Hi,
Up to 3.2.x I was able to compile a mainline kernel for the kilauea
board, but...
http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
shows, that mfdcrx was introduced in the v3.3 kernel.
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
ELDK 4.2) this assembly instruction is not known and the build breaks.
There are some obvious workarounds, like using a more recent toolchain
(e.g ELDK 5.x) or use make -k to keep on compiling even when there is an
error as much as possible;)
What puzzles me is that also stuff for boards is being compiled which is
not really needed like treeboot-currituck.c even when I configure the
kernel for a kilauea board.
Is this on purpose and if so why?
Please advise.
Regards,
Robert
..."But I have a slowly coagulating theory that the size of a project is
directly proportional to the possibility that significant bugs will crop
up. Exponentiate for each additional programmer involved." - Steven K.
Halliburton
My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
On Wed, Mar 21, 2012 at 8:10 AM, Robert Berger
[off-list ref] wrote:
Hi,
Up to 3.2.x I was able to compile a mainline kernel for the kilauea
board, but...
http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
shows, that mfdcrx was introduced in the v3.3 kernel.
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
ELDK 4.2) this assembly instruction is not known and the build breaks.
Sigh. GCC 4.2 is pretty old at this point.
There are some obvious workarounds, like using a more recent toolchain
(e.g ELDK 5.x) or use make -k to keep on compiling even when there is an
error as much as possible;)
That would be the most expedient option, yes.
What puzzles me is that also stuff for boards is being compiled which is
not really needed like treeboot-currituck.c even when I configure the
kernel for a kilauea board.
Is this on purpose and if so why?
All of the stuff in arch/powerpc/boot/ is built regardless of the
configured board and stuffed into a wrapper.a archive. Then the
individual board targets are built and the necessary pieces are pulled
from the wrapper.a file.
Please advise.
If upgrading ELDK is an option for you, it will get you the quickest
solution. Otherwise we'll need to figure out how to stub out the
instruction in boot/dcr.h and use the asm long trick. Ew. I can look
at that next week.
josh
From: Wolfgang Denk <hidden> Date: 2012-03-21 16:25:56
Dear Josh,
In message [off-list ref] you wrote:
quoted
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
ELDK 4.2) this assembly instruction is not known and the build breaks.
Sigh. GCC 4.2 is pretty old at this point.
But still rock-solid ... We use it a lot, especially as reference for
more recent (and sometimes more broken) versions of GCC.
All of the stuff in arch/powerpc/boot/ is built regardless of the
configured board and stuffed into a wrapper.a archive. Then the
individual board targets are built and the necessary pieces are pulled
from the wrapper.a file.
This appears to be a pretty inefficient approach. Why don't we build
only the files we actually need? That would save a bit of build time.
quoted
Please advise.
If upgrading ELDK is an option for you, it will get you the quickest
solution. Otherwise we'll need to figure out how to stub out the
instruction in boot/dcr.h and use the asm long trick. Ew. I can look
at that next week.
Thanks a lot in advance!
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It is wrong always, everywhere and for everyone to believe anything
upon insufficient evidence. - W. K. Clifford, British philosopher,
circa 1876
From: Tony Breeds <hidden> Date: 2012-03-21 22:14:03
On Wed, Mar 21, 2012 at 02:10:59PM +0200, Robert Berger wrote:
Hi,
Up to 3.2.x I was able to compile a mainline kernel for the kilauea
board, but...
http://git.denx.de/?p=linux-denx.git;a=commitdiff;h=075bcf5879225d0c2a119c23d8046b890e051e81
shows, that mfdcrx was introduced in the v3.3 kernel.
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes with the
ELDK 4.2) this assembly instruction is not known and the build breaks.
If the instruction is available on your platform but not in your
toolchain we can do something ugly (as we hav in the past) and replace
"mfdrcx" with ".long xxxx". That will bypass the compiler breakage.
What puzzles me is that also stuff for boards is being compiled which is
not really needed like treeboot-currituck.c even when I configure the
kernel for a kilauea board.
Can you either propvide the config file or the name of the config target
so I look into why it's enabling the currituck platform.
Yours Tony
From: Wolfgang Denk <hidden> Date: 2012-03-21 22:34:38
Dear Tony,
In message [off-list ref] you wrote:
quoted
What puzzles me is that also stuff for boards is being compiled which is
not really needed like treeboot-currituck.c even when I configure the
kernel for a kilauea board.
Can you either propvide the config file or the name of the config target
so I look into why it's enabling the currituck platform.
Robert mentioned it in the Subjct: he was building for the Kilauea
board, i. e. 40x/kilauea_defconfig
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I must follow the people. Am I not their leader? - Benjamin Disraeli
From: Frank Svendsbøe <hidden> Date: 2012-03-30 22:53:35
On Mon, Mar 26, 2012 at 3:36 PM, Josh Boyer [off-list ref] wrote:
On Sat, Mar 24, 2012 at 7:53 PM, Benjamin Herrenschmidt
[off-list ref] wrote:
quoted
On Wed, 2012-03-21 at 17:25 +0100, Wolfgang Denk wrote:
quoted
quoted
quoted
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes
with the
quoted
quoted
ELDK 4.2) this assembly instruction is not known and the build
breaks.
quoted
Sigh. =A0GCC 4.2 is pretty old at this point.
But still rock-solid ... =A0We use it a lot, especially as reference fo=
r
quoted
quoted
more recent (and sometimes more broken) versions of GCC.
Isn't this a binutils rather than gcc issue ?
Pretty much.
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug?
Best regards,
Frank
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-03-31 00:03:17
On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote:
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug?
The kernel shouldn't have tried to build that instruction on 8xx, though
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bit
more careful at excluding 4xx stuff on a 8xx kernel.
Can you give us the exact error ?
Cheers,
Ben.
From: Frank E. Svendsbøe <hidden> Date: 2012-04-01 22:14:09
On Sat, Mar 31, 2012 at 11:03:04AM +1100, Benjamin Herrenschmidt wrote:
On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote:
quoted
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug?
The kernel shouldn't have tried to build that instruction on 8xx, though
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bit
more careful at excluding 4xx stuff on a 8xx kernel.
Yes. I agree on Wolfgangs statement regarding not building code we
don't want/need. Please explain to me why src-wlib/src-plat in
arch/powerpc/boot/Makefile includes every ppc target...
Can you give us the exact error ?
Yes. The problem is caused by commit 228d550 by Tony Breeds
arch/powerpc/boot/treeboot-currituck.c:50
reg = mfdcrx(DDR3_MR0CF + i);
--
Best regards,
Frank
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-04-02 02:02:13
On Mon, 2012-04-02 at 00:14 +0200, Frank E. Svendsbøe wrote:
On Sat, Mar 31, 2012 at 11:03:04AM +1100, Benjamin Herrenschmidt wrote:
quoted
On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote:
quoted
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug?
The kernel shouldn't have tried to build that instruction on 8xx, though
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bit
more careful at excluding 4xx stuff on a 8xx kernel.
Yes. I agree on Wolfgangs statement regarding not building code we
don't want/need. Please explain to me why src-wlib/src-plat in
arch/powerpc/boot/Makefile includes every ppc target...
Ok, I've asked Tony to have a look at splitting the build decision
in arch/powerpc/boot along the same lines as the CPU families... ie only
wrappers for platforms potentially supported by the built kernel. That
should fix it.
Cheers,
Ben.
From: Tony Breeds <hidden> Date: 2012-04-02 06:28:29
On Mon, Apr 02, 2012 at 12:01:55PM +1000, Benjamin Herrenschmidt wrote:
Ok, I've asked Tony to have a look at splitting the build decision
in arch/powerpc/boot along the same lines as the CPU families... ie only
wrappers for platforms potentially supported by the built kernel. That
should fix it.
Please try this patch. Only lightly tested here. I haven't "split up"
src-wlib yet as I wanted to verify I'm on the right track.
From e0b1ac84bfd539482bc88b943724e577e6b8dfb3 Mon Sep 17 00:00:00 2001
From: Tony Breeds <redacted>
Date: Mon, 2 Apr 2012 16:20:35 +1000
Subject: [PATCH] powerpc/boot: Only build board support files when required.
Currently we build all board files regardless of the final zImage
target. This is sub-optimal (in terms on compilation) and leads to
problems in one platform needlessly causing failures for other
platforms.
Use the Kconfig variables to selectively construct this board files to
build.
Signed-off-by: Tony Breeds <redacted>
---
arch/powerpc/boot/Makefile | 56 +++++++++++++++++++++++++++++++++----------
1 files changed, 43 insertions(+), 13 deletions(-)
From: Frank E. Svendsbøe <hidden> Date: 2012-04-02 08:37:20
On Mon, Apr 02, 2012 at 04:28:29PM +1000, Tony Breeds wrote:
On Mon, Apr 02, 2012 at 12:01:55PM +1000, Benjamin Herrenschmidt wrote:
quoted
Ok, I've asked Tony to have a look at splitting the build decision
in arch/powerpc/boot along the same lines as the CPU families... ie only
wrappers for platforms potentially supported by the built kernel. That
should fix it.
Please try this patch. Only lightly tested here. I haven't "split up"
src-wlib yet as I wanted to verify I'm on the right track.
Thanks. It compiles now (for 8xx), but I still need to resolve a
vmalloc failure during boot that occurred sometime after 3.2, so I
haven't been able to test it yet.
You're on the right track. Now continue splitting up src-wlib :)
--
Best regards,
Frank
On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt
[off-list ref] wrote:
On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsb=F8e wrote:
quoted
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug?
The kernel shouldn't have tried to build that instruction on 8xx, though
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bit
more careful at excluding 4xx stuff on a 8xx kernel.
It's still a binutils issue. Sounds like the toolchain being used to
build the 8xx kernel is specifically built for 8xx. A generally built
binutils should have worked fine (assuming it was new enough), since
we pass -mcpu=3D405.
josh
From: Benjamin Herrenschmidt <benh@kernel.crashing.org> Date: 2012-04-02 21:08:43
On Mon, 2012-04-02 at 08:10 -0400, Josh Boyer wrote:
On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt
[off-list ref] wrote:
quoted
On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsbøe wrote:
quoted
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug?
The kernel shouldn't have tried to build that instruction on 8xx, though
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bit
more careful at excluding 4xx stuff on a 8xx kernel.
It's still a binutils issue. Sounds like the toolchain being used to
build the 8xx kernel is specifically built for 8xx. A generally built
binutils should have worked fine (assuming it was new enough), since
we pass -mcpu=405.
Still, it makes sense to limit the building of the wrappers to the CPU
family of the kernel...
Cheers,
Ben.
On Mon, Apr 2, 2012 at 5:08 PM, Benjamin Herrenschmidt
[off-list ref] wrote:
On Mon, 2012-04-02 at 08:10 -0400, Josh Boyer wrote:
quoted
On Fri, Mar 30, 2012 at 8:03 PM, Benjamin Herrenschmidt
[off-list ref] wrote:
quoted
On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsb=F8e wrote:
quoted
Hi Josh Boyer,
just wanted to add that I'm experiencing the same problem that Robert
reported, but on 8xx instead of 4xx. The mpc8xx does not support the
mfdcrx instruction, so maybe it's more to it than just a binutils bug=
?
quoted
quoted
The kernel shouldn't have tried to build that instruction on 8xx, thou=
gh
quoted
quoted
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bi=
t
quoted
quoted
more careful at excluding 4xx stuff on a 8xx kernel.
It's still a binutils issue. =A0Sounds like the toolchain being used to
build the 8xx kernel is specifically built for 8xx. =A0A generally built
binutils should have worked fine (assuming it was new enough), since
we pass -mcpu=3D405.
Still, it makes sense to limit the building of the wrappers to the CPU
family of the kernel...
Oh, I'm not really disagreeing with that. I think I said as much about
4 years ago, but at the time the prevailing opinion was what we
currently have. I never really understood why.
Out with the old, in with the sane.
josh
From: Wolfgang Denk <hidden> Date: 2012-04-04 19:21:14
Dear Josh,
In message [off-list ref] you wrote:
quoted
The kernel shouldn't have tried to build that instruction on 8xx, though
I suppose if it's in arch/powerpc/boot, we are a bit too eager at
building everything including what's not relevant, we might to be a bit
more careful at excluding 4xx stuff on a 8xx kernel.
It's still a binutils issue. Sounds like the toolchain being used to
build the 8xx kernel is specifically built for 8xx. A generally built
binutils should have worked fine (assuming it was new enough), since
we pass -mcpu=405.
The problem is the "assuming it was new enough" part.
The kernel README says nothing about binutils requirements, the only
tool related statement is "Make sure you have at least gcc 3.2
available." Actually I doubt if gcc 3.2 wouldbuild a working kernel
image.
ELDK 4.2 is based on gcc version 4.2.2 / binutils version 2.17.50.0.12
20070128. This is obviously to old for this code. I do not see an
actual problem with that - nobody can expect that we support old tol
chain versions forever.
But then, I think if we make assumptions about tool versions, we
should add appropriate tests and issue helpful error messages. Here,
we should issue an error "binutils versions x.y.z or later needed" or
similar.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
I have made mistakes, but have never made the mistake of claiming I
never made one. - James G. Bennet
From: Stephen Rothwell <hidden> Date: 2012-04-05 00:02:41
On Wed, 04 Apr 2012 21:21:01 +0200 Wolfgang Denk [off-list ref] wrote:
The kernel README says nothing about binutils requirements, the only
tool related statement is "Make sure you have at least gcc 3.2
available." Actually I doubt if gcc 3.2 wouldbuild a working kernel
image.
ELDK 4.2 is based on gcc version 4.2.2 / binutils version 2.17.50.0.12
20070128. This is obviously to old for this code. I do not see an
actual problem with that - nobody can expect that we support old tol
chain versions forever.
The requirements are documented in Documentation/Changes where we say we
need gcc 3.2 and binutils 2.12. Not that that is very relevant to this
discussion. ;-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
From: Wolfgang Denk <hidden> Date: 2012-04-05 17:44:13
Dear Stephen Rothwell,
In message [off-list ref] you wrote:
quoted
ELDK 4.2 is based on gcc version 4.2.2 / binutils version 2.17.50.0.12
20070128. This is obviously to old for this code. I do not see an
actual problem with that - nobody can expect that we support old tol
chain versions forever.
The requirements are documented in Documentation/Changes where we say we
need gcc 3.2 and binutils 2.12. Not that that is very relevant to this
discussion. ;-)
Indeed. I doubt you can build any working PPC kernel with these old
tools.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"Consistency requires you to be as ignorant today as you were a year
ago." - Bernard Berenson
From: Robert Berger <hidden> Date: 2012-05-06 14:37:20
On 04/02/2012 09:28 AM, Tony Breeds wrote:
On Mon, Apr 02, 2012 at 12:01:55PM +1000, Benjamin Herrenschmidt wrote:
quoted
Ok, I've asked Tony to have a look at splitting the build decision
in arch/powerpc/boot along the same lines as the CPU families... ie only
wrappers for platforms potentially supported by the built kernel. That
should fix it.
Please try this patch. Only lightly tested here. I haven't "split up"
src-wlib yet as I wanted to verify I'm on the right track.
I can confirm that it fixes the kilauea problem. Builds and runs so far.
Are you going to push this upstream?
Regards,
Robert
..."Software is like sex, it's better when it's free"
My public pgp key is available at:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1