compile quirk linux-2.6.24 (with workaround)

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

44 more lines

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

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

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

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

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

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

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>

diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 63d07cc..e3993a6 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile

@@ -35,10 +35,10 @@ endif
 
 BOOTCFLAGS     += -I$(obj) -I$(srctree)/$(obj) -I$(srctree)/$(src)/libfdt
 
-$(obj)/4xx.o: BOOTCFLAGS += -mcpu=440
-$(obj)/ebony.o: BOOTCFLAGS += -mcpu=440
-$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=440
-$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
+$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405
+$(obj)/ebony.o: BOOTCFLAGS += -mcpu=405
+$(obj)/cuboot-taishan.o: BOOTCFLAGS += -mcpu=405
+$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=405
 $(obj)/treeboot-walnut.o: BOOTCFLAGS += -mcpu=405

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$

-$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
+$(obj)/4xx.o: BOOTCFLAGS += -mcpu=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

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$

quoted

-$(obj)/cuboot-katmai.o: BOOTCFLAGS += -mcpu=440
+$(obj)/4xx.o: BOOTCFLAGS += -mcpu=405

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

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