From: Bernhard Reiter <hidden> Date: 2008-02-03 16:59:33
Dear linux powerpc Maintainers and Users,
recently I have tried to compile a new kernel on a Debian sarge ppc
system (PowerBook5,6 MacRISC3 Power Macintosh).
The build system bailed out with
BOOTCC arch/powerpc/boot/4xx.o
cc1: error: bad value (440) for -mcpu= switch
make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
I have tracked this a few steps and the attached patch made the compile for me
as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
cannot produce code for 4xx it seems.
The "ARCH=ppc64" I have came about also looked wrong, but I do not know
if this part of the patch is really necessary.
It is just a workaround, as I have no insight of what is really going wrong.
I hope my report is useful,
Bernhard
Details:
I have used "make oldconfig" with a 2.6.17 kernel and answered some questions.
Here is the first section of the .config I've ended up with:
# CONFIG_PPC64 is not set
#
# Processor support
#
CONFIG_6xx=y
# CONFIG_PPC_85xx is not set
# CONFIG_PPC_8xx is not set
# CONFIG_40x is not set
# CONFIG_44x is not set
# CONFIG_E200 is not set
CONFIG_PPC_FPU=y
CONFIG_ALTIVEC=y
CONFIG_PPC_STD_MMU=y
CONFIG_PPC_STD_MMU_32=y
# CONFIG_PPC_MM_SLICES is not set
# CONFIG_SMP is not set
CONFIG_PPC32=y
CONFIG_WORD_SIZE=32
CONFIG_PPC_MERGE=y
CONFIG_MMU=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_IRQ_PER_CPU=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_ARCH_HAS_ILOG2_U32=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_GENERIC_FIND_NEXT_BIT=y
# CONFIG_ARCH_NO_VIRT_TO_BUS is not set
CONFIG_PPC=y
CONFIG_EARLY_PRINTK=y
CONFIG_GENERIC_NVRAM=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_PPC_OF=y
CONFIG_OF=y
CONFIG_PPC_UDBG_16550=y
# CONFIG_GENERIC_TBSYNC is not set
CONFIG_AUDIT_ARCH=y
CONFIG_GENERIC_BUG=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
# CONFIG_DEFAULT_UIMAGE is not set
# CONFIG_PPC_DCR_NATIVE is not set
# CONFIG_PPC_DCR_MMIO is not set
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
From: Sven Luther <hidden> Date: 2008-02-04 09:51:25
On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
Dear linux powerpc Maintainers and Users,
recently I have tried to compile a new kernel on a Debian sarge ppc
system (PowerBook5,6 MacRISC3 Power Macintosh).
This is a G4 based system.
The build system bailed out with
BOOTCC arch/powerpc/boot/4xx.o
cc1: error: bad value (440) for -mcpu= switch
make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
I have tracked this a few steps and the attached patch made the compile for me
as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
cannot produce code for 4xx it seems.
You should normally not need to build the 4xx bootloader part. Make sure
that, i don't know why this happens. Can you look into
arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
and make sure it is disabled in the main config ?
Please bounce this message to debian-powerpc, as debian believes in
censorship instead of trying to solve inimity by discussion.
Friendly,
Sven Luther
From: Bernhard Reiter <hidden> Date: 2008-02-04 10:26:26
On Monday 04 February 2008 10:51, Sven Luther wrote:
On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
quoted
Dear linux powerpc Maintainers and Users,
recently I have tried to compile a new kernel on a Debian sarge ppc
system (PowerBook5,6 MacRISC3 Power Macintosh).
This is a G4 based system.
Yes.
quoted
The build system bailed out with
BOOTCC arch/powerpc/boot/4xx.o
cc1: error: bad value (440) for -mcpu= switch
make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
I have tracked this a few steps and the attached patch made the compile
for me as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
cannot produce code for 4xx it seems.
You should normally not need to build the 4xx bootloader part. Make sure
that, i don't know why this happens. Can you look into
arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
and make sure it is disabled in the main config ?
I have tried to do this, but it looks like it is just hardcoded into the
Makefile as you can see from the patch. There is probably more that I do not
understand - thus my report with on the workaround.
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
From: Grant Likely <hidden> Date: 2008-02-04 17:34:27
On 2/4/08, Bernhard Reiter [off-list ref] wrote:
On Monday 04 February 2008 10:51, Sven Luther wrote:
quoted
You should normally not need to build the 4xx bootloader part. Make sure
that, i don't know why this happens. Can you look into
arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
and make sure it is disabled in the main config ?
I have tried to do this, but it looks like it is just hardcoded into the
Makefile as you can see from the patch. There is probably more that I do not
understand - thus my report with on the workaround.
The policy decision was made early on to build all of the bootwrapper
bits regardless of whether they are needed by the configured platform
or not. AFAIK the reason for this is to increase the variety of
platforms and compilers for with the bootwrapper bits are tested on.
Unfortunately, there are bits of 4xx bootwrappers which require
processor specific instructions for manipulating the cache and DCR.
If we're supporting compilers which don't have 440 support, then we'll
need to disable the build of those bits when they aren't needed, but I
don't know the best way to go about this. David, thoughts?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Sun, 3 Feb 2008 17:29:05 +0100
Bernhard Reiter [off-list ref] wrote:
Dear linux powerpc Maintainers and Users,
recently I have tried to compile a new kernel on a Debian sarge ppc
system (PowerBook5,6 MacRISC3 Power Macintosh).
The build system bailed out with
BOOTCC arch/powerpc/boot/4xx.o
cc1: error: bad value (440) for -mcpu= switch
make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
I have tracked this a few steps and the attached patch made the compile for me
as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
cannot produce code for 4xx it seems.
The "ARCH=ppc64" I have came about also looked wrong, but I do not know
if this part of the patch is really necessary.
It is just a workaround, as I have no insight of what is really going wrong.
That patch really won't fly. I'll try go come up with something a bit
more robust when I can.
josh
On Mon, 4 Feb 2008 10:51:21 +0100
Sven Luther [off-list ref] wrote:
On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
quoted
Dear linux powerpc Maintainers and Users,
recently I have tried to compile a new kernel on a Debian sarge ppc
system (PowerBook5,6 MacRISC3 Power Macintosh).
This is a G4 based system.
quoted
The build system bailed out with
BOOTCC arch/powerpc/boot/4xx.o
cc1: error: bad value (440) for -mcpu= switch
make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
I have tracked this a few steps and the attached patch made the compile for me
as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
cannot produce code for 4xx it seems.
You should normally not need to build the 4xx bootloader part. Make sure
that, i don't know why this happens. Can you look into
arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
and make sure it is disabled in the main config ?
That's not true. All the wrapper bits are built for every board always.
josh
From: Sven Luther <hidden> Date: 2008-02-05 14:39:29
On Tue, Feb 05, 2008 at 07:08:33AM -0600, Josh Boyer wrote:
On Mon, 4 Feb 2008 10:51:21 +0100
Sven Luther [off-list ref] wrote:
quoted
On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
quoted
Dear linux powerpc Maintainers and Users,
recently I have tried to compile a new kernel on a Debian sarge ppc
system (PowerBook5,6 MacRISC3 Power Macintosh).
This is a G4 based system.
quoted
The build system bailed out with
BOOTCC arch/powerpc/boot/4xx.o
cc1: error: bad value (440) for -mcpu= switch
make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
I have tracked this a few steps and the attached patch made the compile for me
as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
cannot produce code for 4xx it seems.
You should normally not need to build the 4xx bootloader part. Make sure
that, i don't know why this happens. Can you look into
arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
and make sure it is disabled in the main config ?
That's not true. All the wrapper bits are built for every board always.
Yes, which is why it fails. But Should they not be conditionally built
upon including support or not for the actual board ?
I mean, if you have not included 4xx support in the kernel, as is the
case here, it does not make sense to add the 4xx bootwrapper code, no ?
Friendly,
Sven Luther
On Tue, 5 Feb 2008 15:39:26 +0100
Sven Luther [off-list ref] wrote:
On Tue, Feb 05, 2008 at 07:08:33AM -0600, Josh Boyer wrote:
quoted
On Mon, 4 Feb 2008 10:51:21 +0100
Sven Luther [off-list ref] wrote:
quoted
On Sun, Feb 03, 2008 at 05:29:05PM +0100, Bernhard Reiter wrote:
quoted
Dear linux powerpc Maintainers and Users,
recently I have tried to compile a new kernel on a Debian sarge ppc
system (PowerBook5,6 MacRISC3 Power Macintosh).
This is a G4 based system.
quoted
The build system bailed out with
BOOTCC arch/powerpc/boot/4xx.o
cc1: error: bad value (440) for -mcpu= switch
make[1]: *** [arch/powerpc/boot/4xx.o] Fehler 1
I have tracked this a few steps and the attached patch made the compile for me
as my compiler gcc-Version 3.3.5 (Debian 1:3.3.5-13)
cannot produce code for 4xx it seems.
You should normally not need to build the 4xx bootloader part. Make sure
that, i don't know why this happens. Can you look into
arch/powerpc/boot/Makefile, to see what option enables the 4xx build,
and make sure it is disabled in the main config ?
That's not true. All the wrapper bits are built for every board always.
Yes, which is why it fails. But Should they not be conditionally built
upon including support or not for the actual board ?
One would think so.
I mean, if you have not included 4xx support in the kernel, as is the
case here, it does not make sense to add the 4xx bootwrapper code, no ?
It does, in a manner. There are both generic and platform specific
pieces to the bootwrapper. Having everything always built helps keep
the generic bits from breaking, which is important as they're often
tightly coupled. That's at least the reason I can think of.
The powerpc maintainers have been over this quite a bit and I don't see
it changing anytime soon.
josh
From: Grant Likely <hidden> Date: 2008-02-05 15:24:39
On 2/5/08, Josh Boyer [off-list ref] wrote:
quoted
I mean, if you have not included 4xx support in the kernel, as is the
case here, it does not make sense to add the 4xx bootwrapper code, no ?
It does, in a manner. There are both generic and platform specific
pieces to the bootwrapper. Having everything always built helps keep
the generic bits from breaking, which is important as they're often
tightly coupled. That's at least the reason I can think of.
The powerpc maintainers have been over this quite a bit and I don't see
it changing anytime soon.
That would mean we're dropping support for compilers which can't build
405/440 specific wrapper bits (or other core specific quirks that need
to go in the wrapper) That doesn't sound appropriate to me.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
On Tue, 5 Feb 2008 08:24:38 -0700
"Grant Likely" [off-list ref] wrote:
On 2/5/08, Josh Boyer [off-list ref] wrote:
quoted
quoted
I mean, if you have not included 4xx support in the kernel, as is the
case here, it does not make sense to add the 4xx bootwrapper code, no ?
It does, in a manner. There are both generic and platform specific
pieces to the bootwrapper. Having everything always built helps keep
the generic bits from breaking, which is important as they're often
tightly coupled. That's at least the reason I can think of.
The powerpc maintainers have been over this quite a bit and I don't see
it changing anytime soon.
That would mean we're dropping support for compilers which can't build
405/440 specific wrapper bits (or other core specific quirks that need
to go in the wrapper) That doesn't sound appropriate to me.
No it doesn't. At least not yet. I said I'd try to come up with a
patch soon-ish. We haven't failed!(yet) Also, this isn't a
core-specific quirk. It's an architected instruction of Book III-E in
the PowerPC ISA. I can't help it if other chips don't implement this
wonderful control mechanism ;)
Taking a step back though, there will always be odd cases like this as
we move forward. Toolchain XXX will eventually not support instruction
YYYY which will eventually be used, etc. I'll try to make this
specific case work because it's scope is quite limited. But this
problem as a whole will still remain.
josh
From: Olof Johansson <hidden> Date: 2008-02-05 16:09:42
On Tue, Feb 05, 2008 at 09:38:20AM -0600, Josh Boyer wrote:
Taking a step back though, there will always be odd cases like this as
we move forward. Toolchain XXX will eventually not support instruction
YYYY which will eventually be used, etc. I'll try to make this
specific case work because it's scope is quite limited. But this
problem as a whole will still remain.
Worst case, if it's only a couple of instructions, they could be covered
the way we usually handle new instructions in the ISA: make a macro for
them and hand-encode them.
See real_205_{read,write}b() in arch/powerpc/kernel/misc_64.S for
example.
-Olof
From: Bernhard Reiter <hidden> Date: 2008-02-06 10:07:52
On Tuesday 05 February 2008 16:38, Josh Boyer wrote:
quoted
That would mean we're dropping support for compilers which can't build
405/440 specific wrapper bits (or other core specific quirks that need
to go in the wrapper) That doesn't sound appropriate to me.
I agree.
Note that dropping support for these compilers will raise the hurdle to
compile kernels, which might lead to less testing of the whole kernel. This
effect would probably eat up the advantages of better testing by always
building the whole source. So I do not recommend it. :)
No it doesn't. At least not yet. I said I'd try to come up with a
patch soon-ish.
Thanks in advance!
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
On Tue, 5 Feb 2008 09:38:20 -0600
Josh Boyer [off-list ref] wrote:
On Tue, 5 Feb 2008 08:24:38 -0700
"Grant Likely" [off-list ref] wrote:
quoted
On 2/5/08, Josh Boyer [off-list ref] wrote:
quoted
quoted
I mean, if you have not included 4xx support in the kernel, as is the
case here, it does not make sense to add the 4xx bootwrapper code, no ?
It does, in a manner. There are both generic and platform specific
pieces to the bootwrapper. Having everything always built helps keep
the generic bits from breaking, which is important as they're often
tightly coupled. That's at least the reason I can think of.
The powerpc maintainers have been over this quite a bit and I don't see
it changing anytime soon.
That would mean we're dropping support for compilers which can't build
405/440 specific wrapper bits (or other core specific quirks that need
to go in the wrapper) That doesn't sound appropriate to me.
No it doesn't. At least not yet. I said I'd try to come up with a
patch soon-ish. We haven't failed!(yet) Also, this isn't a
core-specific quirk. It's an architected instruction of Book III-E in
the PowerPC ISA. I can't help it if other chips don't implement this
wonderful control mechanism ;)
Taking a step back though, there will always be odd cases like this as
we move forward. Toolchain XXX will eventually not support instruction
YYYY which will eventually be used, etc. I'll try to make this
specific case work because it's scope is quite limited. But this
problem as a whole will still remain.
My apologies for taking so long on this. Digging through gcc history
isn't exactly fun :)
Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
has been around since 2001. Seeing as how there really isn't anything
440 specific in the files effected, we should be able to pass -mcpu=405
for everything and have it still work.
Bernhard, can you try the patch below? I've compile test it, and
booted it on an Ebony board (PowerPC 440GP). If anyone else cares to
test that would also be welcome.
josh
[POWERPC] Fix bootwrapper builds with older gcc versions
GCC versions before 3.4 did not support the -mcpu=440 option. Use
-mcpu=405 for the 4xx specific bootwrapper files, as that has been
around for much longer.
Signed-off-by: Josh Boyer <redacted>
From: Bernhard Reiter <hidden> Date: 2008-02-22 14:50:35
On Tuesday 19 February 2008 03:52, Josh Boyer wrote:
My apologies for taking so long on this. Digging through gcc history
isn't exactly fun :)
No problem. Thanks for tackling the issue.
Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
has been around since 2001. Seeing as how there really isn't anything
440 specific in the files effected, we should be able to pass -mcpu=405
for everything and have it still work.
Bernhard, can you try the patch below?
I will test it in the next days.
The short test for my sarge compiler makes me optimistic:
dpkg -l gcc | grep gcc
ii gcc 3.3.5-3 The GNU C compiler
bernhard@burn:~/tmp$ gcc -mcpu=440 x.c
cc1: error: bad value (440) for -mcpu= switch
bernhard@burn:~/tmp$ gcc -mcpu=405 x.c
bernhard@burn:~/tmp$
From: Bernhard Reiter <hidden> Date: 2008-02-25 11:56:41
On Friday 22 February 2008 15:50, Bernhard Reiter wrote:
quoted
Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
has been around since 2001. Seeing as how there really isn't anything
440 specific in the files effected, we should be able to pass -mcpu=405
for everything and have it still work.
Bernhard, can you try the patch below?
I will test it in the next days.
Done. Looks good.
(I did _not_ do a full rebuild and installation, only a build test.
I will do a full blown test with 2.6.24.3.)
The short test for my sarge compiler makes me optimistic:
dpkg -l gcc | grep gcc
ii gcc 3.3.5-3 The GNU C compiler
bernhard@burn:~/tmp$ gcc -mcpu=440 x.c
cc1: error: bad value (440) for -mcpu= switch
bernhard@burn:~/tmp$ gcc -mcpu=405 x.c
bernhard@burn:~/tmp$
Note: Your original did not fully apply, I think it had lines like
-$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
-$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
which I did not have in my 2.6.24.
Probably because you've used a git version of linux.
What I did was to change the similiar occurances from 440 to 405.
Bernhard
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
From: Bernhard Reiter <hidden> Date: 2008-03-03 17:27:18
On Monday 25 February 2008 12:56, Bernhard Reiter wrote:
On Friday 22 February 2008 15:50, Bernhard Reiter wrote:
quoted
quoted
Ok, so it seems -mcpu=440 was added in gcc 3.4. The -mcpu=405 option
has been around since 2001. Seeing as how there really isn't anything
440 specific in the files effected, we should be able to pass -mcpu=405
for everything and have it still work.
Bernhard, can you try the patch below?
I will test it in the next days.
Done. Looks good.
(I did _not_ do a full rebuild and installation, only a build test.
I will do a full blown test with 2.6.24.3.)
Worked fine for me with the attached patch.
Thanks again.
Note: Your original did not fully apply, I think it had lines like
-$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
-$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
which I did not have in my 2.6.24.
Probably because you've used a git version of linux.
What I did was to change the similiar occurances from 440 to 405.
--
Managing Director - Owner: www.intevation.net (Free Software Company)
Germany Coordinator: fsfeurope.org. Coordinator: www.Kolab-Konsortium.com.
Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998
Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner