kilauea compilation breaks with v3.3 kernel and ELDK 4.2
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
Quoted 11 lines · Robert Berger
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.
Quoted 3 lines
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.
Quoted 5 lines
What puzzles me is that also stuff for boards is being compiled which is not really needed like
treeboot-currituck.ceven 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.
Quoted 1 line
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
Dear Josh,
Quoted 5 lines · In message <CA+5PVA7+vPZmLBzkXOFwTM+kLMYHPDgVW4Jcm91XSxW=Ng-Y6g@mail.gmail.com>…
Quoted 3 lines
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.
Quoted 4 lines
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 6 lines
Quoted 1 line
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.hand use the asm long trick. Ew. I can look at that next week.
Thanks a lot in advance!
Best regards,
Wolfgang Denk
Signature · 6 lines
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: [email protected] It is wrong always, everywhere and for everyone to believe anything upon insufficient evidence. - W. K. Clifford, British philosopher, circa 1876
Quoted 9 lines · Wolfgang Denk
Quoted 1 line
Quoted 1 line
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes
with the
Quoted 1 line
Quoted 1 line
ELDK 4.2) this assembly instruction is not known and the build
breaks.
Quoted 2 lines
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.
Isn't this a binutils rather than gcc issue ?
Cheers,
Ben.
Quoted 4 lines · Benjamin Herrenschmidt
Quoted 3 lines · Wolfgang Denk
Quoted 1 line
Quoted 1 line
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes
with the
Quoted 1 line
Quoted 1 line
ELDK 4.2) this assembly instruction is not known and the build
Quoted 8 lines
Quoted 6 lines
breaks.
Quoted 2 lines
Sigh. =A0GCC 4.2 is pretty old at this point.
But still rock-solid ... =A0We use it a lot, especially as reference for more recent (and sometimes more broken) versions of GCC.
Isn't this a binutils rather than gcc issue ?
Pretty much.
josh
Quoted 11 lines · Josh Boyer
Quoted 9 lines · Benjamin Herrenschmidt
Quoted 8 lines · Wolfgang Denk
Quoted 1 line
Quoted 1 line
The problem is that for ppc-linux-gcc (GCC) 4.2.2 (which comes
with the
Quoted 1 line
Quoted 1 line
ELDK 4.2) this assembly instruction is not known and the build
breaks.
Quoted 2 lines
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 6 lines
Quoted 3 lines
Quoted 1 line
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
Quoted 5 lines · Frank Svendsbøe
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.
Quoted 4 lines · Benjamin Herrenschmidt
Quoted 2 lines · Frank Svendsbøe
Hi Josh Boyer,
Quoted 9 lines
Quoted 3 lines
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...
Quoted 2 lines
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);
Signature · 2 lines
Best regards, Frank
Quoted 15 lines · Frank E. Svendsbøe
Quoted 4 lines · Benjamin Herrenschmidt
Quoted 2 lines · Frank Svendsbøe
Hi Josh Boyer,
Quoted 9 lines
Quoted 3 lines
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.
Quoted 3 lines
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/Makefileincludes 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.
Quoted 4 lines · Benjamin Herrenschmidt
Ok, I've asked Tony to have a look at splitting the build decision in
arch/powerpc/bootalong 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 <[email protected]>
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.
--- arch/powerpc/boot/Makefile | 56 +++++++++++++++++++++++++++++++++---------- 1 files changed, 43 insertions(+), 13 deletions(-)
arch/powerpc/boot/Makefile +43 -13
@@ -69,19 +69,49 @@ src-wlib := string.S crt0.S crtsavres.S stdio.c main.c \ 4xx.c ebony.c mv64x60.c mpsc.c mv64x60_i2c.c cuboot.c bamboo.c \ cpm-serial.c stdlib.c mpc52xx-psc.c planetcore.c uartlite.c \ fsl-soc.c mpc8xx.c pq2.c ugecon.c -src-plat := of.c cuboot-52xx.c cuboot-824x.c cuboot-83xx.c cuboot-85xx.c holly.c \ - cuboot-ebony.c cuboot-hotfoot.c epapr.c treeboot-ebony.c \ - prpmc2800.c \ - ps3-head.S ps3-hvcall.S ps3.c treeboot-bamboo.c cuboot-8xx.c \ - cuboot-pq2.c cuboot-sequoia.c treeboot-walnut.c \ - cuboot-bamboo.c cuboot-mpc7448hpc2.c cuboot-taishan.c \ - fixed-head.S ep88xc.c ep405.c cuboot-c2k.c \ - cuboot-katmai.c cuboot-rainier.c redboot-8xx.c ep8248e.c \ - cuboot-warp.c cuboot-85xx-cpm2.c cuboot-yosemite.c simpleboot.c \ - virtex405-head.S virtex.c redboot-83xx.c cuboot-sam440ep.c \ - cuboot-acadia.c cuboot-amigaone.c cuboot-kilauea.c \ - gamecube-head.S gamecube.c wii-head.S wii.c treeboot-iss4xx.c \ - treeboot-currituck.c +src-plat := of.c +ifeq ($(CONFIG_40x),y) +src-plat += fixed-head.S ep405.c cuboot-hotfoot.c treeboot-walnut.c \ + cuboot-acadia.c cuboot-kilauea.c \ + simpleboot.c virtex405-head.S virtex.c +endif +ifeq ($(CONFIG_44x),y) +src-plat += treeboot-ebony cuboot-ebony treeboot-bamboo cuboot-bamboo \ + cuboot-sam440ep.c cuboot-sequoia.c cuboot-rainier.c \ + cuboot-taishan.c cuboot-katmai.c cuboot-warp.c \ + cuboot-yosemite.c treeboot-iss4xx.c treeboot-currituck.c \ + simpleboot.c fixed-head.S virtex.c +endif +ifeq ($(CONFIG_8xx),y) +src-plat += cuboot-8xx.c fixed-head.S ep88xc.c redboot-8xx.c +endif +ifeq ($(CONFIG_PPC_MPC52xx),y) +src-plat += cuboot-52xx.c +endif +ifeq ($(CONFIG_PPC_82xx),y) +src-plat += cuboot-pq2.c fixed-head.S ep8248e.c cuboot-824x.c +endif +ifeq ($(CONFIG_PPC_82xx),y) +src-plat += cuboot-83xx.c fixed-head.S redboot-83xx.c +endif +ifeq ($(CONFIG_FSL_SOC_BOOKE),y) +src-plat += cuboot-85xx.c cuboot-85xx-cpm2.c +endif +ifeq ($(CONFIG_EMBEDDED6xx),y) +src-plat += cuboot-pq2.c cuboot-mpc7448hpc2.c cuboot-c2k.c \ + gamecube-head.S gamecube.c wii-head.S wii.c holly.c \ + prpmc2800.c +endif +ifeq ($(CONFIG_AMIGAONE),y) +src-plat += cuboot-amigaone.c +endif +ifeq ($(CONFIG_PPC_PS3),y) +src-plat += ps3-head.S ps3-hvcall.S ps3.c +endif +ifeq ($(CONFIG_EPAPR_BOOT),y) +src-plat += epapr.c +endif +src-plat := $(sort $(src-plat)) src-boot := $(src-wlib) $(src-plat) empty.c src-boot := $(addprefix $(obj)/, $(src-boot))
Signature · 3 lines
1.7.7.6 Yours Tony
Quoted 10 lines · Tony Breeds
Quoted 4 lines · Benjamin Herrenschmidt
Ok, I've asked Tony to have a look at splitting the build decision in
arch/powerpc/bootalong 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 :)
Signature · 2 lines
Best regards, Frank
Quoted 9 lines · Tony Breeds
Quoted 4 lines · Benjamin Herrenschmidt
Ok, I've asked Tony to have a look at splitting the build decision in
arch/powerpc/bootalong 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
Quoted 5 lines · Robert Berger
Quoted 4 lines · Tony Breeds
Quoted 2 lines · Benjamin Herrenschmidt
Ok, I've asked Tony to have a look at splitting the build decision in
arch/powerpc/bootalong the same lines as the CPU families... ie onl=
y
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
wrappers for platforms potentially supported by the built kernel. That should fix it.
Please try this patch. =A0Only lightly tested here. =A0I haven't "split =
up"
Quoted 5 lines
Quoted 1 line
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?
I can confirm this too (applied to 3.4-rc7). Tony?
Best regards,
Frank
Quoted 4 lines · Benjamin Herrenschmidt
Quoted 2 lines · On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsb=F8e wrote:
Hi Josh Boyer,
Quoted 8 lines
Quoted 3 lines
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
Quoted 15 lines · Josh Boyer
Quoted 4 lines · Benjamin Herrenschmidt
Quoted 2 lines · Frank Svendsbøe
Hi Josh Boyer,
Quoted 8 lines
Quoted 3 lines
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.
Quoted 4 lines
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.
Quoted 10 lines · Benjamin Herrenschmidt
Quoted 9 lines · Josh Boyer
Quoted 7 lines · Benjamin Herrenschmidt
Quoted 5 lines · On Sat, 2012-03-31 at 00:53 +0200, Frank Svendsb=F8e 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=
?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
The kernel shouldn't have tried to build that instruction on 8xx, thou=
gh
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
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 9 lines
Quoted 6 lines
Quoted 1 line
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
Dear Josh,
Quoted 10 lines · In message <CA+5PVA6jQgme0sS=i8yYX6b_R5179+BtWPh7QXCGNfoLTCt46A@mail.gmail.com>…
Quoted 5 lines
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
Signature · 5 lines
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: [email protected] I have made mistakes, but have never made the mistake of claiming I never made one. - James G. Bennet
Quoted 10 lines · On Wed, 04 Apr 2012 21:21:01 +0200 Wolfgang Denk <[email protected]> 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. ;-)
Signature · 2 lines
Cheers, Stephen Rothwell [email protected]
Dear Stephen Rothwell,
Quoted 9 lines · In message <[email protected]> you wrote:
Quoted 5 lines
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/Changeswhere 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
Signature · 5 lines
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: [email protected] "Consistency requires you to be as ignorant today as you were a year ago." - Bernard Berenson
Quoted 11 lines · Robert Berger
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.
Quoted 3 lines
What puzzles me is that also stuff for boards is being compiled which is not really needed like
treeboot-currituck.ceven 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
Dear Tony,
Quoted 7 lines · In message <[email protected]> you wrote:
Quoted 4 lines
What puzzles me is that also stuff for boards is being compiled which is not really needed like
treeboot-currituck.ceven 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
Signature · 4 lines
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: [email protected] I must follow the people. Am I not their leader? - Benjamin Disraeli