[PATCH] ppc: force target CPU

[Laurent Vivier]

With gcc-5.2 default target is power7.
As openbios targets PowerMacs G3/G4/G5, force
gcc target to be G3 (32bit) or G5 (64bit).

Signed-off-by: Laurent Vivier <[e-mail]>
---
 config/scripts/switch-arch | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch
index 38d263d..bcf807a 100755
--- a/config/scripts/switch-arch
+++ b/config/scripts/switch-arch
@@ -265,7 +265,7 @@ for ARCH in $arch_list; do
         ppc)
         select_prefix powerpc powerpc64
         if [ "$unix" = "no" ]; then
-            CFLAGS="-m32 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
+            CFLAGS="-m32 -mcpu=G3 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
             AS_FLAGS="-m32"
         else
             CFLAGS="-fno-builtin"
@@ -275,7 +275,7 @@ for ARCH in $arch_list; do
 
         ppc64)
         select_prefix powerpc64
-        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
+        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
         AS_FLAGS="-Wa,-a64"
         ;;
 
-- 
2.5.0

[Cole Robinson]

On 11/21/2015 11:00 AM, Laurent Vivier wrote:
> With gcc-5.2 default target is power7.
> As openbios targets PowerMacs G3/G4/G5, force
> gcc target to be G3 (32bit) or G5 (64bit).
>
> Signed-off-by: Laurent Vivier <[e-mail]>
> ---
>  config/scripts/switch-arch | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch
> index 38d263d..bcf807a 100755
> --- a/config/scripts/switch-arch
> +++ b/config/scripts/switch-arch
> @@ -265,7 +265,7 @@ for ARCH in $arch_list; do
>          ppc)
>          select_prefix powerpc powerpc64
>          if [ "$unix" = "no" ]; then
> -            CFLAGS="-m32 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
> +            CFLAGS="-m32 -mcpu=G3 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
>              AS_FLAGS="-m32"
>          else
>              CFLAGS="-fno-builtin"
> @@ -275,7 +275,7 @@ for ARCH in $arch_list; do
>
> ppc64)
>          select_prefix powerpc64
> -        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
> +        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
>          AS_FLAGS="-Wa,-a64"
>          ;;

Fixes things for me, thanks!

Tested-by: Cole Robinson <[e-mail]>

[Mark Cave-Ayland]

On 21/11/15 16:00, Laurent Vivier wrote:
> With gcc-5.2 default target is power7.
> As openbios targets PowerMacs G3/G4/G5, force
> gcc target to be G3 (32bit) or G5 (64bit).
>
> Signed-off-by: Laurent Vivier <[e-mail]>
> ---
>  config/scripts/switch-arch | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch
> index 38d263d..bcf807a 100755
> --- a/config/scripts/switch-arch
> +++ b/config/scripts/switch-arch
> @@ -265,7 +265,7 @@ for ARCH in $arch_list; do
>          ppc)
>          select_prefix powerpc powerpc64
>          if [ "$unix" = "no" ]; then
> -            CFLAGS="-m32 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
> +            CFLAGS="-m32 -mcpu=G3 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
>              AS_FLAGS="-m32"
>          else
>              CFLAGS="-fno-builtin"
> @@ -275,7 +275,7 @@ for ARCH in $arch_list; do
>
> ppc64)
>          select_prefix powerpc64
> -        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
> +        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
>          AS_FLAGS="-Wa,-a64"
>          ;;

Great work! Andreas, I'd be much happier if you could review/commit this
(or at least give a Reviewed-by) as this is a little bit out of my area
of knowledge...


Many thanks,

Mark.

[Mark Cave-Ayland]

On 22/11/15 11:54, Mark Cave-Ayland wrote:

(Add Hervé to CC)
> On 21/11/15 16:00, Laurent Vivier wrote:
> > With gcc-5.2 default target is power7.
> > As openbios targets PowerMacs G3/G4/G5, force
> > gcc target to be G3 (32bit) or G5 (64bit).
> >
> > Signed-off-by: Laurent Vivier <[e-mail]>
> > ---
> >  config/scripts/switch-arch | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch
> > index 38d263d..bcf807a 100755
> > --- a/config/scripts/switch-arch
> > +++ b/config/scripts/switch-arch
> > @@ -265,7 +265,7 @@ for ARCH in $arch_list; do
> >          ppc)
> >          select_prefix powerpc powerpc64
> >          if [ "$unix" = "no" ]; then
> > -            CFLAGS="-m32 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
> > +            CFLAGS="-m32 -mcpu=G3 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
> >              AS_FLAGS="-m32"
> >          else
> >              CFLAGS="-fno-builtin"
> > @@ -275,7 +275,7 @@ for ARCH in $arch_list; do
> >
> > ppc64)
> >          select_prefix powerpc64
> > -        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
> > +        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
> >          AS_FLAGS="-Wa,-a64"
> >          ;;
>
> Great work! Andreas, I'd be much happier if you could review/commit this
> (or at least give a Reviewed-by) as this is a little bit out of my area
> of knowledge...

After some further research, there are currently 2 reasons that make me
feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
builds: firstly there are some people trying to emulate PPC 604 CPUs
with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
instead.

To that end the minimum supported CPU for PPC needs to be 602 and so
with this in mind, I've lightly tested the attached patch which seems to
work here - Cole, does this work on your compiler setup? If so, I think
this is the option I would like to apply upstream.

Hervé, do you have a rebased version of your patchset to switch the QEMU
PReP machine over to OpenBIOS to OHW? And does it work with an OpenBIOS
compiled with these options? If so, it would be good to push for a
switch from OHW to OpenBIOS for PReP during the next QEMU dev cycle.


ATB,

Mark.

[Cole Robinson]

On 12/29/2015 11:43 AM, Mark Cave-Ayland wrote:
> On 22/11/15 11:54, Mark Cave-Ayland wrote:
>
> (Add Hervé to CC)
> > On 21/11/15 16:00, Laurent Vivier wrote:
> > > With gcc-5.2 default target is power7.
> > > As openbios targets PowerMacs G3/G4/G5, force
> > > gcc target to be G3 (32bit) or G5 (64bit).
> > >
> > > Signed-off-by: Laurent Vivier <[e-mail]>
> > > ---
> > >  config/scripts/switch-arch | 4 ++--
> > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch
> > > index 38d263d..bcf807a 100755
> > > --- a/config/scripts/switch-arch
> > > +++ b/config/scripts/switch-arch
> > > @@ -265,7 +265,7 @@ for ARCH in $arch_list; do
> > >          ppc)
> > >          select_prefix powerpc powerpc64
> > >          if [ "$unix" = "no" ]; then
> > > -            CFLAGS="-m32 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
> > > +            CFLAGS="-m32 -mcpu=G3 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
> > >              AS_FLAGS="-m32"
> > >          else
> > >              CFLAGS="-fno-builtin"
> > > @@ -275,7 +275,7 @@ for ARCH in $arch_list; do
> > >
> > > ppc64)
> > >          select_prefix powerpc64
> > > -        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
> > > +        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
> > >          AS_FLAGS="-Wa,-a64"
> > >          ;;
> >
> > Great work! Andreas, I'd be much happier if you could review/commit this
> > (or at least give a Reviewed-by) as this is a little bit out of my area
> > of knowledge...
>
> After some further research, there are currently 2 reasons that make me
> feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
> builds: firstly there are some people trying to emulate PPC 604 CPUs
> with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
> been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
> instead.
>
> To that end the minimum supported CPU for PPC needs to be 602 and so
> with this in mind, I've lightly tested the attached patch which seems to
> work here - Cole, does this work on your compiler setup? If so, I think
> this is the option I would like to apply upstream.

That patch also fixes the build on fedora 23.

Thanks,
Cole

[Mark Cave-Ayland]

On 29/12/15 17:01, Cole Robinson wrote:
> On 12/29/2015 11:43 AM, Mark Cave-Ayland wrote:
> > On 22/11/15 11:54, Mark Cave-Ayland wrote:
> >
> > (Add Hervé to CC)
> > > On 21/11/15 16:00, Laurent Vivier wrote:
> > > > With gcc-5.2 default target is power7.
> > > > As openbios targets PowerMacs G3/G4/G5, force
> > > > gcc target to be G3 (32bit) or G5 (64bit).
> > > >
> > > > Signed-off-by: Laurent Vivier <[e-mail]>
> > > > ---
> > > >  config/scripts/switch-arch | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/config/scripts/switch-arch b/config/scripts/switch-arch
> > > > index 38d263d..bcf807a 100755
> > > > --- a/config/scripts/switch-arch
> > > > +++ b/config/scripts/switch-arch
> > > > @@ -265,7 +265,7 @@ for ARCH in $arch_list; do
> > > >          ppc)
> > > >          select_prefix powerpc powerpc64
> > > >          if [ "$unix" = "no" ]; then
> > > > -            CFLAGS="-m32 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
> > > > +            CFLAGS="-m32 -mcpu=G3 -msoft-float -fno-builtin-bcopy -fno-builtin-log2"
> > > >              AS_FLAGS="-m32"
> > > >          else
> > > >              CFLAGS="-fno-builtin"
> > > > @@ -275,7 +275,7 @@ for ARCH in $arch_list; do
> > > >
> > > > ppc64)
> > > >          select_prefix powerpc64
> > > > -        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
> > > > +        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
> > > >          AS_FLAGS="-Wa,-a64"
> > > >          ;;
> > >
> > > Great work! Andreas, I'd be much happier if you could review/commit this
> > > (or at least give a Reviewed-by) as this is a little bit out of my area
> > > of knowledge...
> >
> > After some further research, there are currently 2 reasons that make me
> > feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
> > builds: firstly there are some people trying to emulate PPC 604 CPUs
> > with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
> > been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
> > instead.
> >
> > To that end the minimum supported CPU for PPC needs to be 602 and so
> > with this in mind, I've lightly tested the attached patch which seems to
> > work here - Cole, does this work on your compiler setup? If so, I think
> > this is the option I would like to apply upstream.
>
> That patch also fixes the build on fedora 23.

Great, thanks for testing Cole!


ATB,

Mark.

[Segher Boessenkool]

On Tue, Dec 29, 2015 at 04:43:09PM +0000, Mark Cave-Ayland wrote:
> After some further research, there are currently 2 reasons that make me
> feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
> builds: firstly there are some people trying to emulate PPC 604 CPUs
> with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
> been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
> instead.
>
> To that end the minimum supported CPU for PPC needs to be 602 and so
> with this in mind, I've lightly tested the attached patch which seems to
> work here - Cole, does this work on your compiler setup? If so, I think
> this is the option I would like to apply upstream.

I seriously doubt you have a 602 anywhere, or an emulator for it even.
You want 603/604, which were both called "G2".

It is probably best if you make code that runs on 603 but is tuned
for (say) 750, as in -mcpu=603 -mtune=750.
> ppc64)
>          select_prefix powerpc64
> -        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
> +        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
>          AS_FLAGS="-Wa,-a64"
>          ;;

G5 is 970.  It includes VMX (AltiVec) vector support; you may want to
aim lower here too, say, power4.

While I'm at it...  You probably want -ffreestanding (and then you don't
need to disable builtins separately).  You should not need -Wa,-a64
in CFLAGS unless your toolchain install is broken; and for AS_FLAGS
you want to include all of CFLAGS.

Cheers,


Segher

[Andreas Färber]

Am 18.01.2016 um 07:40 schrieb Segher Boessenkool:
> On Tue, Dec 29, 2015 at 04:43:09PM +0000, Mark Cave-Ayland wrote:
> > After some further research, there are currently 2 reasons that make me
> > feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
> > builds: firstly there are some people trying to emulate PPC 604 CPUs
> > with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
> > been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
> > instead.
> >
> > To that end the minimum supported CPU for PPC needs to be 602 and so
> > with this in mind, I've lightly tested the attached patch which seems to
> > work here - Cole, does this work on your compiler setup? If so, I think
> > this is the option I would like to apply upstream.
>
> I seriously doubt you have a 602 anywhere, or an emulator for it even.
> You want 603/604, which were both called "G2".

For reasons unknown to me as current maintainer, QEMU's PReP machine
uses a "602" CPU model by default. We are aware of issues with that
default and have overridden it from the command line occasionally in our
testing, but did not reach broader agreement on why and what to change
it to... so if you have more input on that...?

http://git.qemu-project.org/?p=qemu.git;a=blob;f=hw/ppc/prep.c;h=0e102fcfbe0...
> It is probably best if you make code that runs on 603 but is tuned
> for (say) 750, as in -mcpu=603 -mtune=750.
> > ppc64)
> >          select_prefix powerpc64
> > -        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
> > +        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
> >          AS_FLAGS="-Wa,-a64"
> >          ;;
>
> G5 is 970.  It includes VMX (AltiVec) vector support; you may want to
> aim lower here too, say, power4.

Why? QEMU's pseries emulation uses SLOF instead of OpenBIOS, and ppc64
mac99 uses a 970fx by default.

http://git.qemu-project.org/?p=qemu.git;a=blob;f=hw/ppc/mac_newworld.c;h=ca3...

Cheers,
Andreas
> While I'm at it...  You probably want -ffreestanding (and then you don't
> need to disable builtins separately).  You should not need -Wa,-a64
> in CFLAGS unless your toolchain install is broken; and for AS_FLAGS
> you want to include all of CFLAGS.
>
> Cheers,
>
> Segher

[Mark Cave-Ayland]

On 18/01/16 18:29, Andreas Färber wrote:
> Am 18.01.2016 um 07:40 schrieb Segher Boessenkool:
> > On Tue, Dec 29, 2015 at 04:43:09PM +0000, Mark Cave-Ayland wrote:
> > > After some further research, there are currently 2 reasons that make me
> > > feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
> > > builds: firstly there are some people trying to emulate PPC 604 CPUs
> > > with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
> > > been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
> > > instead.
> > >
> > > To that end the minimum supported CPU for PPC needs to be 602 and so
> > > with this in mind, I've lightly tested the attached patch which seems to
> > > work here - Cole, does this work on your compiler setup? If so, I think
> > > this is the option I would like to apply upstream.
> >
> > I seriously doubt you have a 602 anywhere, or an emulator for it even.
> > You want 603/604, which were both called "G2".
>
> For reasons unknown to me as current maintainer, QEMU's PReP machine
> uses a "602" CPU model by default. We are aware of issues with that
> default and have overridden it from the command line occasionally in our
> testing, but did not reach broader agreement on why and what to change
> it to... so if you have more input on that...?
>
> http://git.qemu-project.org/?p=qemu.git;a=blob;f=hw/ppc/prep.c;h=0e102fcfbe0...

You can see this if you go further back in history before the files were
moved; it seems like Jocelyn Mayer switched to a 604 in order to fix OS/2:

http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=da9b266bb8491fd41badf...

and the commit where the switch appears is here, apparently in an
attempt to find a CPU that worked at that time:

http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=b37fc148bb81b5b022846...
> > It is probably best if you make code that runs on 603 but is tuned
> > for (say) 750, as in -mcpu=603 -mtune=750.

Given that 603 was used in a real BeBox then this would seem to be a
reasonable default. And perhaps the QEMU PReP CPU should be updated
similarly?
> > > ppc64)
> > >          select_prefix powerpc64
> > > -        CFLAGS="-Wa,-a64 -m64 -msoft-float -fno-builtin"
> > > +        CFLAGS="-Wa,-a64 -m64 -mcpu=G5 -msoft-float -fno-builtin"
> > >          AS_FLAGS="-Wa,-a64"
> > >          ;;
> >
> > G5 is 970.  It includes VMX (AltiVec) vector support; you may want to
> > aim lower here too, say, power4.
>
> Why? QEMU's pseries emulation uses SLOF instead of OpenBIOS, and ppc64
> mac99 uses a 970fx by default.
>
> http://git.qemu-project.org/?p=qemu.git;a=blob;f=hw/ppc/mac_newworld.c;h=ca3...

ATB,

Mark.

[Andreas Färber]

Am 18.01.2016 um 20:14 schrieb Mark Cave-Ayland:
> On 18/01/16 18:29, Andreas Färber wrote:
> > Am 18.01.2016 um 07:40 schrieb Segher Boessenkool:
> > > On Tue, Dec 29, 2015 at 04:43:09PM +0000, Mark Cave-Ayland wrote:
> > > > After some further research, there are currently 2 reasons that make me
> > > > feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
> > > > builds: firstly there are some people trying to emulate PPC 604 CPUs
> > > > with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
> > > > been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
> > > > instead.
> > > >
> > > > To that end the minimum supported CPU for PPC needs to be 602 and so
> > > > with this in mind, I've lightly tested the attached patch which seems to
> > > > work here - Cole, does this work on your compiler setup? If so, I think
> > > > this is the option I would like to apply upstream.
> > >
> > > I seriously doubt you have a 602 anywhere, or an emulator for it even.
> > > You want 603/604, which were both called "G2".
> >
> > For reasons unknown to me as current maintainer, QEMU's PReP machine
> > uses a "602" CPU model by default. We are aware of issues with that
> > default and have overridden it from the command line occasionally in our
> > testing, but did not reach broader agreement on why and what to change
> > it to... so if you have more input on that...?
> >
> > http://git.qemu-project.org/?p=qemu.git;a=blob;f=hw/ppc/prep.c;h=0e102fcfbe0...
>
> You can see this if you go further back in history before the files were
> moved; it seems like Jocelyn Mayer switched to a 604 in order to fix OS/2:
>
> http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=da9b266bb8491fd41badf...
>
> and the commit where the switch appears is here, apparently in an
> attempt to find a CPU that worked at that time:
>
> http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=b37fc148bb81b5b022846...

I don't really care what Jocelyn played around with. Either there was a
real 602 based PReP machine or there wasn't. If there was, we should
take the earliest -mcpu setting like you suggested; if there was no such
machine, then we can fix QEMU and take up Segher's suggestion.

Regards,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

[Laurent Vivier]

Le 19/01/2016 00:44, Andreas Färber a écrit :
> Am 18.01.2016 um 20:14 schrieb Mark Cave-Ayland:
> > On 18/01/16 18:29, Andreas Färber wrote:
> > > Am 18.01.2016 um 07:40 schrieb Segher Boessenkool:
> > > > On Tue, Dec 29, 2015 at 04:43:09PM +0000, Mark Cave-Ayland wrote:
> > > > > After some further research, there are currently 2 reasons that make me
> > > > > feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
> > > > > builds: firstly there are some people trying to emulate PPC 604 CPUs
> > > > > with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
> > > > > been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
> > > > > instead.
> > > > >
> > > > > To that end the minimum supported CPU for PPC needs to be 602 and so
> > > > > with this in mind, I've lightly tested the attached patch which seems to
> > > > > work here - Cole, does this work on your compiler setup? If so, I think
> > > > > this is the option I would like to apply upstream.
> > > >
> > > > I seriously doubt you have a 602 anywhere, or an emulator for it even.
> > > > You want 603/604, which were both called "G2".
> > >
> > > For reasons unknown to me as current maintainer, QEMU's PReP machine
> > > uses a "602" CPU model by default. We are aware of issues with that
> > > default and have overridden it from the command line occasionally in our
> > > testing, but did not reach broader agreement on why and what to change
> > > it to... so if you have more input on that...?
> > >
> > > http://git.qemu-project.org/?p=qemu.git;a=blob;f=hw/ppc/prep.c;h=0e102fcfbe0...
> >
> > You can see this if you go further back in history before the files were
> > moved; it seems like Jocelyn Mayer switched to a 604 in order to fix OS/2:
> >
> > http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=da9b266bb8491fd41badf...
> >
> > and the commit where the switch appears is here, apparently in an
> > attempt to find a CPU that worked at that time:
> >
> > http://git.qemu-project.org/?p=qemu.git;a=commitdiff;h=b37fc148bb81b5b022846...
>
> I don't really care what Jocelyn played around with. Either there was a
> real 602 based PReP machine or there wasn't. If there was, we should
> take the earliest -mcpu setting like you suggested; if there was no such
> machine, then we can fix QEMU and take up Segher's suggestion.

According to this series (from Hervé):

    https://lists.gnu.org/archive/html/qemu-ppc/2015-06/msg00110.html

RS/6000 7020/40p is a PReP machine.

And according to this page:

   https://en.wikipedia.org/wiki/RS/6000#Type_7020

RS/6000 7020/40p is PowerPC 601 based.

Laurent

[Segher Boessenkool]

On Mon, Jan 18, 2016 at 07:29:33PM +0100, Andreas Färber wrote:
> Am 18.01.2016 um 07:40 schrieb Segher Boessenkool:
> > On Tue, Dec 29, 2015 at 04:43:09PM +0000, Mark Cave-Ayland wrote:
> > > After some further research, there are currently 2 reasons that make me
> > > feel we should be targeting earlier CPUs than the G3 for 32-bit OpenBIOS
> > > builds: firstly there are some people trying to emulate PPC 604 CPUs
> > > with QEMU/KVM which currently hangs in OpenBIOS, and secondly there has
> > > been talk of switching over QEMU's PReP machine from OHW to OpenBIOS
> > > instead.
> > >
> > > To that end the minimum supported CPU for PPC needs to be 602 and so
> > > with this in mind, I've lightly tested the attached patch which seems to
> > > work here - Cole, does this work on your compiler setup? If so, I think
> > > this is the option I would like to apply upstream.
> >
> > I seriously doubt you have a 602 anywhere, or an emulator for it even.
> > You want 603/604, which were both called "G2".
>
> For reasons unknown to me as current maintainer, QEMU's PReP machine
> uses a "602" CPU model by default. We are aware of issues with that
> default and have overridden it from the command line occasionally in our
> testing, but did not reach broader agreement on why and what to change
> it to... so if you have more input on that...?

I would use 603.  601 is problematic (it is not fully PowerPC).  602 for
all intents and purposes does not exist; also is problematic for a few
things (no DP float insns, no available manual, etc.)
> > G5 is 970.  It includes VMX (AltiVec) vector support; you may want to
> > aim lower here too, say, power4.
>
> Why? QEMU's pseries emulation uses SLOF instead of OpenBIOS, and ppc64
> mac99 uses a 970fx by default.

970 is the only 64-bit CPU ever used in Macs, sure.  There are later CPUs
that do not have VMX (e.g. power5).  -mcpu=970 -mno-altivec is essentially
the same as -mcpu=power4.


Segher

[Segher Boessenkool]

On Tue, Jan 19, 2016 at 01:50:13AM +0100, Laurent Vivier wrote:
> According to this series (from Hervé):
>
> https://lists.gnu.org/archive/html/qemu-ppc/2015-06/msg00110.html
>
> RS/6000 7020/40p is a PReP machine.
>
> And according to this page:
>
> https://en.wikipedia.org/wiki/RS/6000#Type_7020
>
> RS/6000 7020/40p is PowerPC 601 based.

601 doesn't have much to do with 602.  601 is not fully PowerPC; you do
not want to deal with it.


Segher

[Andreas Färber]

Am 19.01.2016 um 18:42 schrieb Segher Boessenkool:
> On Tue, Jan 19, 2016 at 01:50:13AM +0100, Laurent Vivier wrote:
> > According to this series (from Hervé):
> >
> > https://lists.gnu.org/archive/html/qemu-ppc/2015-06/msg00110.html
> >
> > RS/6000 7020/40p is a PReP machine.
> >
> > And according to this page:
> >
> > https://en.wikipedia.org/wiki/RS/6000#Type_7020
> >
> > RS/6000 7020/40p is PowerPC 601 based.
>
> 601 doesn't have much to do with 602.  601 is not fully PowerPC; you do
> not want to deal with it.

I believe Hervé was using a real firmware from IBM FTP for that one, not
OpenBIOS.

Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

[Hervé Poussineau]

Le 19/01/2016 19:05, Andreas Färber a écrit :
> Am 19.01.2016 um 18:42 schrieb Segher Boessenkool:
> > On Tue, Jan 19, 2016 at 01:50:13AM +0100, Laurent Vivier wrote:
> > > According to this series (from Hervé):
> > >
> > > https://lists.gnu.org/archive/html/qemu-ppc/2015-06/msg00110.html
> > >
> > > RS/6000 7020/40p is a PReP machine.
> > >
> > > And according to this page:
> > >
> > > https://en.wikipedia.org/wiki/RS/6000#Type_7020
> > >
> > > RS/6000 7020/40p is PowerPC 601 based.
> >
> > 601 doesn't have much to do with 602.  601 is not fully PowerPC; you do
> > not want to deal with it.
>
> I believe Hervé was using a real firmware from IBM FTP for that one, not
> OpenBIOS.
>
> Andreas

Yes, I was using the real IBM firmware for my tests.
As IBM 7020 was upgradable to 604, real firmware works with 601 and 604 types.
Let's say that QEMU emulates an upgraded 7020, by using a 604 cpu by default.
As a consequence, I see no problem compiling OpenBIOS for a 604 CPU.

Hervé

[Mark Cave-Ayland]

On 19/01/16 18:34, Hervé Poussineau wrote:
> Le 19/01/2016 19:05, Andreas Färber a écrit :
> > Am 19.01.2016 um 18:42 schrieb Segher Boessenkool:
> > > On Tue, Jan 19, 2016 at 01:50:13AM +0100, Laurent Vivier wrote:
> > > > According to this series (from Hervé):
> > > >
> > > > https://lists.gnu.org/archive/html/qemu-ppc/2015-06/msg00110.html
> > > >
> > > > RS/6000 7020/40p is a PReP machine.
> > > >
> > > > And according to this page:
> > > >
> > > > https://en.wikipedia.org/wiki/RS/6000#Type_7020
> > > >
> > > > RS/6000 7020/40p is PowerPC 601 based.
> > >
> > > 601 doesn't have much to do with 602.  601 is not fully PowerPC; you do
> > > not want to deal with it.
> >
> > I believe Hervé was using a real firmware from IBM FTP for that one, not
> > OpenBIOS.
> >
> > Andreas
>
> Yes, I was using the real IBM firmware for my tests.
> As IBM 7020 was upgradable to 604, real firmware works with 601 and 604
> types.
> Let's say that QEMU emulates an upgraded 7020, by using a 604 cpu by
> default.
> As a consequence, I see no problem compiling OpenBIOS for a 604 CPU.

Great! If we go with Segher's suggestion for 64-bit then we end up with
this:

32-bit: -mcpu=604
64-bit: -mcpu=970 -mno-altivec

Andreas, does this look reasonable to you?


ATB,

Mark.

[Laurent Vivier]

Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> On 19/01/16 18:34, Hervé Poussineau wrote:
> > Le 19/01/2016 19:05, Andreas Färber a écrit :
> > > Am 19.01.2016 um 18:42 schrieb Segher Boessenkool:
> > > > On Tue, Jan 19, 2016 at 01:50:13AM +0100, Laurent Vivier wrote:
> > > > > According to this series (from Hervé):
> > > > >
> > > > > https://lists.gnu.org/archive/html/qemu-ppc/2015-06/msg00110.html
> > > > >
> > > > > RS/6000 7020/40p is a PReP machine.
> > > > >
> > > > > And according to this page:
> > > > >
> > > > > https://en.wikipedia.org/wiki/RS/6000#Type_7020
> > > > >
> > > > > RS/6000 7020/40p is PowerPC 601 based.
> > > >
> > > > 601 doesn't have much to do with 602.  601 is not fully PowerPC; you do
> > > > not want to deal with it.
> > >
> > > I believe Hervé was using a real firmware from IBM FTP for that one, not
> > > OpenBIOS.
> > >
> > > Andreas
> >
> > Yes, I was using the real IBM firmware for my tests.
> > As IBM 7020 was upgradable to 604, real firmware works with 601 and 604
> > types.
> > Let's say that QEMU emulates an upgraded 7020, by using a 604 cpu by
> > default.
> > As a consequence, I see no problem compiling OpenBIOS for a 604 CPU.
>
> Great! If we go with Segher's suggestion for 64-bit then we end up with
> this:
>
> 32-bit: -mcpu=604
> 64-bit: -mcpu=970 -mno-altivec

I think you can use "-mcpu=power4" here, this is the old default value
for gcc.
> Andreas, does this look reasonable to you?
>
> ATB,
>
> Mark.

[Mark Cave-Ayland]

On 20/01/16 08:33, Laurent Vivier wrote:
> Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > On 19/01/16 18:34, Hervé Poussineau wrote:
> > > Le 19/01/2016 19:05, Andreas Färber a écrit :
> > > > Am 19.01.2016 um 18:42 schrieb Segher Boessenkool:
> > > > > On Tue, Jan 19, 2016 at 01:50:13AM +0100, Laurent Vivier wrote:
> > > > > > According to this series (from Hervé):
> > > > > >
> > > > > > https://lists.gnu.org/archive/html/qemu-ppc/2015-06/msg00110.html
> > > > > >
> > > > > > RS/6000 7020/40p is a PReP machine.
> > > > > >
> > > > > > And according to this page:
> > > > > >
> > > > > > https://en.wikipedia.org/wiki/RS/6000#Type_7020
> > > > > >
> > > > > > RS/6000 7020/40p is PowerPC 601 based.
> > > > >
> > > > > 601 doesn't have much to do with 602.  601 is not fully PowerPC; you do
> > > > > not want to deal with it.
> > > >
> > > > I believe Hervé was using a real firmware from IBM FTP for that one, not
> > > > OpenBIOS.
> > > >
> > > > Andreas
> > >
> > > Yes, I was using the real IBM firmware for my tests.
> > > As IBM 7020 was upgradable to 604, real firmware works with 601 and 604
> > > types.
> > > Let's say that QEMU emulates an upgraded 7020, by using a 604 cpu by
> > > default.
> > > As a consequence, I see no problem compiling OpenBIOS for a 604 CPU.
> >
> > Great! If we go with Segher's suggestion for 64-bit then we end up with
> > this:
> >
> > 32-bit: -mcpu=604
> > 64-bit: -mcpu=970 -mno-altivec
>
> I think you can use "-mcpu=power4" here, this is the old default value
> for gcc.

It seems they are effectively the same, so I don't have any strong
preference either way.

Laurent, would you like to resubmit a revised patch with the above
changes to the list? As soon as Andreas ACKs it then I'll apply it to
SVN trunk.


ATB,

Mark.

[Andreas Färber]

Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> On 20/01/16 08:33, Laurent Vivier wrote:
> > Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > this:
> > >
> > > 32-bit: -mcpu=604
> > > 64-bit: -mcpu=970 -mno-altivec
> >
> > I think you can use "-mcpu=power4" here, this is the old default value
> > for gcc.
>
> It seems they are effectively the same, so I don't have any strong
> preference either way.

I prefer Mark's explicit variant, ideally with some explanatory comment.

Cheers,
Andreas

-- 
SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
GF: Felix Imendörffer, Jane Smithard, Graham Norton; HRB 21284 (AG Nürnberg)

[Mark Cave-Ayland]

On 22/01/16 15:05, Andreas Färber wrote:
> Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> > On 20/01/16 08:33, Laurent Vivier wrote:
> > > Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > > Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > > this:
> > > >
> > > > 32-bit: -mcpu=604
> > > > 64-bit: -mcpu=970 -mno-altivec
> > >
> > > I think you can use "-mcpu=power4" here, this is the old default value
> > > for gcc.
> >
> > It seems they are effectively the same, so I don't have any strong
> > preference either way.
>
> I prefer Mark's explicit variant, ideally with some explanatory comment.

Thanks Andreas! Laurent, can you resubmit accordingly with a brief
comment for each summarising why these flags have been chosen?


Many thanks,

Mark.

[Laurent Vivier]

Le 22/01/2016 16:26, Mark Cave-Ayland a écrit :
> On 22/01/16 15:05, Andreas Färber wrote:
> > Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> > > On 20/01/16 08:33, Laurent Vivier wrote:
> > > > Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > > > Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > > > this:
> > > > >
> > > > > 32-bit: -mcpu=604
> > > > > 64-bit: -mcpu=970 -mno-altivec
> > > >
> > > > I think you can use "-mcpu=power4" here, this is the old default value
> > > > for gcc.
> > >
> > > It seems they are effectively the same, so I don't have any strong
> > > preference either way.
> >
> > I prefer Mark's explicit variant, ideally with some explanatory comment.
>
> Thanks Andreas! Laurent, can you resubmit accordingly with a brief
> comment for each summarising why these flags have been chosen?

I can, but I'm not able to build openbios for target ppc64 on ppc64 host.

Is this normal ?

$ ./config/scripts/switch-arch ppc64
Configuring OpenBIOS on ppc64 for ppc64
Initializing build tree /home/laurent/Projects/openbios/obj-ppc64...ok.
Creating target config.mak...ok.
Creating target rules.mak...ok.
Creating config files...ok.
[laurent@pmacg5-1 openbios]$ make
Building OpenBIOS for ppc64
Building...
error:
 HOSTCC host/kernel/dict.o
 HOSTCC host/kernel/bootstrap.o
 HOSTCC host/kernel/forth.o
 HOSTCC host/kernel/stack.o
 HOSTCC forthstrap
  GEN   bootstrap.dict
panic: segmentation violation at 0x87a1062c
dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628) pc=0x0(dict+0x785efff0)
dstackcnt=0 rstackcnt=0 instruction=deadbeef
dstack: 0x0
rstack: 0x0
Writing dictionary core file
rules.mak:69: recipe for target 'bootstrap.dict' failed
make[1]: *** [bootstrap.dict] Error 1
make[1]: Leaving directory '/home/laurent/Projects/openbios/obj-ppc64'
Makefile:19: recipe for target 'build' failed
make: *** [build] Error 1

Laurent

[Programmingkid]

On Jan 25, 2016, at 9:31 AM, Laurent Vivier wrote:
> Le 22/01/2016 16:26, Mark Cave-Ayland a écrit :
> > On 22/01/16 15:05, Andreas Färber wrote:
> > > Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> > > > On 20/01/16 08:33, Laurent Vivier wrote:
> > > > > Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > > > > Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > > > > this:
> > > > > >
> > > > > > 32-bit: -mcpu=604
> > > > > > 64-bit: -mcpu=970 -mno-altivec
> > > > >
> > > > > I think you can use "-mcpu=power4" here, this is the old default value
> > > > > for gcc.
> > > >
> > > > It seems they are effectively the same, so I don't have any strong
> > > > preference either way.
> > >
> > > I prefer Mark's explicit variant, ideally with some explanatory comment.
> >
> > Thanks Andreas! Laurent, can you resubmit accordingly with a brief
> > comment for each summarising why these flags have been chosen?
>
> I can, but I'm not able to build openbios for target ppc64 on ppc64 host.
>
> Is this normal ?

It definitely shouldn't be.
> $ ./config/scripts/switch-arch ppc64
> Configuring OpenBIOS on ppc64 for ppc64
> Initializing build tree /home/laurent/Projects/openbios/obj-ppc64...ok.
> Creating target config.mak...ok.
> Creating target rules.mak...ok.
> Creating config files...ok.
> [laurent@pmacg5-1 openbios]$ make
> Building OpenBIOS for ppc64
> Building...
> error:
> HOSTCC host/kernel/dict.o
> HOSTCC host/kernel/bootstrap.o
> HOSTCC host/kernel/forth.o
> HOSTCC host/kernel/stack.o
> HOSTCC forthstrap
>  GEN   bootstrap.dict
> panic: segmentation violation at 0x87a1062c
> dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628) pc=0x0(dict+0x785efff0)
> dstackcnt=0 rstackcnt=0 instruction=deadbeef
> dstack: 0x0
> rstack: 0x0
> Writing dictionary core file
> rules.mak:69: recipe for target 'bootstrap.dict' failed
> make[1]: *** [bootstrap.dict] Error 1
> make[1]: Leaving directory '/home/laurent/Projects/openbios/obj-ppc64'
> Makefile:19: recipe for target 'build' failed
> make: *** [build] Error 1

What operating system are you using to build OpenBIOS on? 
Is your operating system 32 bit or 64 bit?
What version of GCC are you using?

[Laurent Vivier]

Le 25/01/2016 15:48, Programmingkid a écrit :
> On Jan 25, 2016, at 9:31 AM, Laurent Vivier wrote:
> > Le 22/01/2016 16:26, Mark Cave-Ayland a écrit :
> > > On 22/01/16 15:05, Andreas Färber wrote:
> > > > Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> > > > > On 20/01/16 08:33, Laurent Vivier wrote:
> > > > > > Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > > > > > Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > > > > > this:
> > > > > > >
> > > > > > > 32-bit: -mcpu=604
> > > > > > > 64-bit: -mcpu=970 -mno-altivec
> > > > > >
> > > > > > I think you can use "-mcpu=power4" here, this is the old default value
> > > > > > for gcc.
> > > > >
> > > > > It seems they are effectively the same, so I don't have any strong
> > > > > preference either way.
> > > >
> > > > I prefer Mark's explicit variant, ideally with some explanatory comment.
> > >
> > > Thanks Andreas! Laurent, can you resubmit accordingly with a brief
> > > comment for each summarising why these flags have been chosen?
> >
> > I can, but I'm not able to build openbios for target ppc64 on ppc64 host.
> >
> > Is this normal ?
>
> It definitely shouldn't be.
> > $ ./config/scripts/switch-arch ppc64
> > Configuring OpenBIOS on ppc64 for ppc64
> > Initializing build tree /home/laurent/Projects/openbios/obj-ppc64...ok.
> > Creating target config.mak...ok.
> > Creating target rules.mak...ok.
> > Creating config files...ok.
> > [laurent@pmacg5-1 openbios]$ make
> > Building OpenBIOS for ppc64
> > Building...
> > error:
> > HOSTCC host/kernel/dict.o
> > HOSTCC host/kernel/bootstrap.o
> > HOSTCC host/kernel/forth.o
> > HOSTCC host/kernel/stack.o
> > HOSTCC forthstrap
> >  GEN   bootstrap.dict
> > panic: segmentation violation at 0x87a1062c
> > dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628) pc=0x0(dict+0x785efff0)
> > dstackcnt=0 rstackcnt=0 instruction=deadbeef
> > dstack: 0x0
> > rstack: 0x0
> > Writing dictionary core file
> > rules.mak:69: recipe for target 'bootstrap.dict' failed
> > make[1]: *** [bootstrap.dict] Error 1
> > make[1]: Leaving directory '/home/laurent/Projects/openbios/obj-ppc64'
> > Makefile:19: recipe for target 'build' failed
> > make: *** [build] Error 1
>
> What operating system are you using to build OpenBIOS on?

Fedora23/ppc64
> Is your operating system 32 bit or 64 bit?

64bit. but I've tested on debian ppc 32bit and it fails for another reason:

  CC    target/arch/ppc/qemu/init.o
/home/laurent/Projects/openbios/arch/ppc/qemu/init.c: In function ‘adler32’:
/home/laurent/Projects/openbios/arch/ppc/qemu/init.c:705:17: error: cast
to pointer from integer of different size [-Werror=int-to-pointer-cast]
     char *buf = (char *)POP();
                 ^
cc1: all warnings being treated as errors
> What version of GCC are you using?

64bit host: gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
32bit host: gcc (Debian 4.9.2-10) 4.9.2

Laurent

[Programmingkid]

On Jan 25, 2016, at 10:23 AM, Laurent Vivier wrote:
> Le 25/01/2016 15:48, Programmingkid a écrit :
> > On Jan 25, 2016, at 9:31 AM, Laurent Vivier wrote:
> > > Le 22/01/2016 16:26, Mark Cave-Ayland a écrit :
> > > > On 22/01/16 15:05, Andreas Färber wrote:
> > > > > Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> > > > > > On 20/01/16 08:33, Laurent Vivier wrote:
> > > > > > > Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > > > > >> Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > > > > >> this:
> > > > > > >> 
> > > > > > >> 32-bit: -mcpu=604
> > > > > > >> 64-bit: -mcpu=970 -mno-altivec
> > > > > > > 
> > > > > > > I think you can use "-mcpu=power4" here, this is the old default value
> > > > > > > for gcc.
> > > > > >
> > > > > > It seems they are effectively the same, so I don't have any strong
> > > > > > preference either way.
> > > > >
> > > > > I prefer Mark's explicit variant, ideally with some explanatory comment.
> > > >
> > > > Thanks Andreas! Laurent, can you resubmit accordingly with a brief
> > > > comment for each summarising why these flags have been chosen?
> > >
> > > I can, but I'm not able to build openbios for target ppc64 on ppc64 host.
> > >
> > > Is this normal ?
> >
> > It definitely shouldn't be.
> > > $ ./config/scripts/switch-arch ppc64
> > > Configuring OpenBIOS on ppc64 for ppc64
> > > Initializing build tree /home/laurent/Projects/openbios/obj-ppc64...ok.
> > > Creating target config.mak...ok.
> > > Creating target rules.mak...ok.
> > > Creating config files...ok.
> > > [laurent@pmacg5-1 openbios]$ make
> > > Building OpenBIOS for ppc64
> > > Building...
> > > error:
> > > HOSTCC host/kernel/dict.o
> > > HOSTCC host/kernel/bootstrap.o
> > > HOSTCC host/kernel/forth.o
> > > HOSTCC host/kernel/stack.o
> > > HOSTCC forthstrap
> > > GEN   bootstrap.dict
> > > panic: segmentation violation at 0x87a1062c
> > > dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628) pc=0x0(dict+0x785efff0)
> > > dstackcnt=0 rstackcnt=0 instruction=deadbeef
> > > dstack: 0x0
> > > rstack: 0x0
> > > Writing dictionary core file
> > > rules.mak:69: recipe for target 'bootstrap.dict' failed
> > > make[1]: *** [bootstrap.dict] Error 1
> > > make[1]: Leaving directory '/home/laurent/Projects/openbios/obj-ppc64'
> > > Makefile:19: recipe for target 'build' failed
> > > make: *** [build] Error 1
> >
> > What operating system are you using to build OpenBIOS on?
>
> Fedora23/ppc64
> > Is your operating system 32 bit or 64 bit?
>
> 64bit. but I've tested on debian ppc 32bit and it fails for another reason:
>
> CC    target/arch/ppc/qemu/init.o
> /home/laurent/Projects/openbios/arch/ppc/qemu/init.c: In function ‘adler32’:
> /home/laurent/Projects/openbios/arch/ppc/qemu/init.c:705:17: error: cast
> to pointer from integer of different size [-Werror=int-to-pointer-cast]
>     char *buf = (char *)POP();
>                 ^
> cc1: all warnings being treated as errors
> > What version of GCC are you using?
>
> 64bit host: gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
> 32bit host: gcc (Debian 4.9.2-10) 4.9.2
>
> Laurent

I use to have segmentation violations when I would compile OpenBIOS. The fix
for me was to do this: 

HOSTARCH=amd64 ./switch-arch ppc

But you should try this:

HOSTARCH=ppc64 ./switch-arch ppc

Lets see what happens when you try it.

Also what is the output of your "uname -a" command on the 64 bit operating system?

[Laurent Vivier]

Le 25/01/2016 16:38, Programmingkid a écrit :
> On Jan 25, 2016, at 10:23 AM, Laurent Vivier wrote:
> > Le 25/01/2016 15:48, Programmingkid a écrit :
> > > On Jan 25, 2016, at 9:31 AM, Laurent Vivier wrote:
> > > > Le 22/01/2016 16:26, Mark Cave-Ayland a écrit :
> > > > > On 22/01/16 15:05, Andreas Färber wrote:
> > > > > > Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> > > > > > > On 20/01/16 08:33, Laurent Vivier wrote:
> > > > > > >> Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > > > > >>> Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > > > > >>> this:
> > > > > > >>>
> > > > > > >>> 32-bit: -mcpu=604
> > > > > > >>> 64-bit: -mcpu=970 -mno-altivec
> > > > > > >>
> > > > > > >> I think you can use "-mcpu=power4" here, this is the old default value
> > > > > > >> for gcc.
> > > > > > >
> > > > > > > It seems they are effectively the same, so I don't have any strong
> > > > > > > preference either way.
> > > > > >
> > > > > > I prefer Mark's explicit variant, ideally with some explanatory comment.
> > > > >
> > > > > Thanks Andreas! Laurent, can you resubmit accordingly with a brief
> > > > > comment for each summarising why these flags have been chosen?
> > > >
> > > > I can, but I'm not able to build openbios for target ppc64 on ppc64 host.
> > > >
> > > > Is this normal ?
> > >
> > > It definitely shouldn't be.
> > > > $ ./config/scripts/switch-arch ppc64
> > > > Configuring OpenBIOS on ppc64 for ppc64
> > > > Initializing build tree /home/laurent/Projects/openbios/obj-ppc64...ok.
> > > > Creating target config.mak...ok.
> > > > Creating target rules.mak...ok.
> > > > Creating config files...ok.
> > > > [laurent@pmacg5-1 openbios]$ make
> > > > Building OpenBIOS for ppc64
> > > > Building...
> > > > error:
> > > > HOSTCC host/kernel/dict.o
> > > > HOSTCC host/kernel/bootstrap.o
> > > > HOSTCC host/kernel/forth.o
> > > > HOSTCC host/kernel/stack.o
> > > > HOSTCC forthstrap
> > > > GEN   bootstrap.dict
> > > > panic: segmentation violation at 0x87a1062c
> > > > dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628) pc=0x0(dict+0x785efff0)
> > > > dstackcnt=0 rstackcnt=0 instruction=deadbeef
> > > > dstack: 0x0
> > > > rstack: 0x0
> > > > Writing dictionary core file
> > > > rules.mak:69: recipe for target 'bootstrap.dict' failed
> > > > make[1]: *** [bootstrap.dict] Error 1
> > > > make[1]: Leaving directory '/home/laurent/Projects/openbios/obj-ppc64'
> > > > Makefile:19: recipe for target 'build' failed
> > > > make: *** [build] Error 1
> > >
> > > What operating system are you using to build OpenBIOS on?
> >
> > Fedora23/ppc64
> > > Is your operating system 32 bit or 64 bit?
> >
> > 64bit. but I've tested on debian ppc 32bit and it fails for another reason:
> >
> > CC    target/arch/ppc/qemu/init.o
> > /home/laurent/Projects/openbios/arch/ppc/qemu/init.c: In function ‘adler32’:
> > /home/laurent/Projects/openbios/arch/ppc/qemu/init.c:705:17: error: cast
> > to pointer from integer of different size [-Werror=int-to-pointer-cast]
> >     char *buf = (char *)POP();
> >                 ^
> > cc1: all warnings being treated as errors
> > > What version of GCC are you using?
> >
> > 64bit host: gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
> > 32bit host: gcc (Debian 4.9.2-10) 4.9.2
> >
> > Laurent
>
> I use to have segmentation violations when I would compile OpenBIOS. The fix
> for me was to do this:
>
> HOSTARCH=amd64 ./switch-arch ppc
>
> But you should try this:
>
> HOSTARCH=ppc64 ./switch-arch ppc

The problem is not with "switch-arch ppc" but with "switch-arch ppc64"

and the result is the same.
> Lets see what happens when you try it.
>
> Also what is the output of your "uname -a" command on the 64 bit operating system?

Linux pmacg5-1 4.4.0+ #10 SMP Mon Jan 11 15:30:32 CET 2016 ppc64 ppc64
ppc64 GNU/Linux

Laurent

[BALATON Zoltan]

On Mon, 25 Jan 2016, Laurent Vivier wrote:
> > > > > $ ./config/scripts/switch-arch ppc64
> > > > > Configuring OpenBIOS on ppc64 for ppc64
> > > > > Initializing build tree /home/laurent/Projects/openbios/obj-ppc64...ok.
> > > > > Creating target config.mak...ok.
> > > > > Creating target rules.mak...ok.
> > > > > Creating config files...ok.
> > > > > [laurent@pmacg5-1 openbios]$ make
> > > > > Building OpenBIOS for ppc64
> > > > > Building...
> > > > > error:
> > > > > HOSTCC host/kernel/dict.o
> > > > > HOSTCC host/kernel/bootstrap.o
> > > > > HOSTCC host/kernel/forth.o
> > > > > HOSTCC host/kernel/stack.o
> > > > > HOSTCC forthstrap
> > > > > GEN   bootstrap.dict
> > > > > panic: segmentation violation at 0x87a1062c
> > > > > dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628) pc=0x0(dict+0x785efff0)
> > > > > dstackcnt=0 rstackcnt=0 instruction=deadbeef
> > > > > dstack: 0x0
> > > > > rstack: 0x0
> > > > > Writing dictionary core file
> > > > > rules.mak:69: recipe for target 'bootstrap.dict' failed
> > > > > make[1]: *** [bootstrap.dict] Error 1
> > > > > make[1]: Leaving directory '/home/laurent/Projects/openbios/obj-ppc64'
> > > > > Makefile:19: recipe for target 'build' failed
> > > > > make: *** [build] Error 1

Does running 'make V=1' reveal more errors? Or maybe you could check 
bootstrap.dict-console.log or some other console.log files if they are 
created for some more clues whay it fails.
> > > 64bit host: gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)

Can you try with gcc 4.x? 5.x could be stricter that might cause problems 
but of course best would be if that could be fixed.

Regards,
BALATON Zoltan

[Programmingkid]

On Jan 25, 2016, at 11:23 AM, Laurent Vivier wrote:
> Le 25/01/2016 16:38, Programmingkid a écrit :
> > On Jan 25, 2016, at 10:23 AM, Laurent Vivier wrote:
> > > Le 25/01/2016 15:48, Programmingkid a écrit :
> > > > On Jan 25, 2016, at 9:31 AM, Laurent Vivier wrote:
> > > > > Le 22/01/2016 16:26, Mark Cave-Ayland a écrit :
> > > > > > On 22/01/16 15:05, Andreas Färber wrote:
> > > > > >
> > > > > > > Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> > > > > > >> On 20/01/16 08:33, Laurent Vivier wrote:
> > > > > > >>> Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > > > > >>>> Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > > > > >>>> this:
> > > > > > >>>> 
> > > > > > >>>> 32-bit: -mcpu=604
> > > > > > >>>> 64-bit: -mcpu=970 -mno-altivec
> > > > > > >>> 
> > > > > > >>> I think you can use "-mcpu=power4" here, this is the old default value
> > > > > > >>> for gcc.
> > > > > > >> 
> > > > > > >> It seems they are effectively the same, so I don't have any strong
> > > > > > >> preference either way.
> > > > > > > 
> > > > > > > I prefer Mark's explicit variant, ideally with some explanatory comment.
> > > > > >
> > > > > > Thanks Andreas! Laurent, can you resubmit accordingly with a brief
> > > > > > comment for each summarising why these flags have been chosen?
> > > > >
> > > > > I can, but I'm not able to build openbios for target ppc64 on ppc64 host.
> > > > >
> > > > > Is this normal ?
> > > >
> > > > It definitely shouldn't be.
> > > > > $ ./config/scripts/switch-arch ppc64
> > > > > Configuring OpenBIOS on ppc64 for ppc64
> > > > > Initializing build tree /home/laurent/Projects/openbios/obj-ppc64...ok.
> > > > > Creating target config.mak...ok.
> > > > > Creating target rules.mak...ok.
> > > > > Creating config files...ok.
> > > > > [laurent@pmacg5-1 openbios]$ make
> > > > > Building OpenBIOS for ppc64
> > > > > Building...
> > > > > error:
> > > > > HOSTCC host/kernel/dict.o
> > > > > HOSTCC host/kernel/bootstrap.o
> > > > > HOSTCC host/kernel/forth.o
> > > > > HOSTCC host/kernel/stack.o
> > > > > HOSTCC forthstrap
> > > > > GEN   bootstrap.dict
> > > > > panic: segmentation violation at 0x87a1062c
> > > > > dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628) pc=0x0(dict+0x785efff0)
> > > > > dstackcnt=0 rstackcnt=0 instruction=deadbeef
> > > > > dstack: 0x0
> > > > > rstack: 0x0
> > > > > Writing dictionary core file
> > > > > rules.mak:69: recipe for target 'bootstrap.dict' failed
> > > > > make[1]: *** [bootstrap.dict] Error 1
> > > > > make[1]: Leaving directory '/home/laurent/Projects/openbios/obj-ppc64'
> > > > > Makefile:19: recipe for target 'build' failed
> > > > > make: *** [build] Error 1
> > > >
> > > > What operating system are you using to build OpenBIOS on?
> > >
> > > Fedora23/ppc64
> > > > Is your operating system 32 bit or 64 bit?
> > >
> > > 64bit. but I've tested on debian ppc 32bit and it fails for another reason:
> > >
> > > CC    target/arch/ppc/qemu/init.o
> > > /home/laurent/Projects/openbios/arch/ppc/qemu/init.c: In function ‘adler32’:
> > > /home/laurent/Projects/openbios/arch/ppc/qemu/init.c:705:17: error: cast
> > > to pointer from integer of different size [-Werror=int-to-pointer-cast]
> > >    char *buf = (char *)POP();
> > >                ^
> > > cc1: all warnings being treated as errors
> > > > What version of GCC are you using?
> > >
> > > 64bit host: gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
> > > 32bit host: gcc (Debian 4.9.2-10) 4.9.2
> > >
> > > Laurent
> >
> > I use to have segmentation violations when I would compile OpenBIOS. The fix
> > for me was to do this:
> >
> > HOSTARCH=amd64 ./switch-arch ppc
> >
> > But you should try this:
> >
> > HOSTARCH=ppc64 ./switch-arch ppc
>
> The problem is not with "switch-arch ppc" but with "switch-arch ppc64"
>
> and the result is the same.

It was worth a try. So you are saying the 'ppc' option does successfully 'make' on your
PowerPC G5 system?

The forthstrap command is what is producing the error message. I assume it is 64 bit, but that assumption could be wrong. Could you report the output of this command: file ./config/scripts/obj-ppc/forthstrap
> > Lets see what happens when you try it.
> >
> > Also what is the output of your "uname -a" command on the 64 bit operating system?
>
> Linux pmacg5-1 4.4.0+ #10 SMP Mon Jan 11 15:30:32 CET 2016 ppc64 ppc64
> ppc64 GNU/Linux
>
> Laurent

The good news is that your uname command is reporting the correct values.

[Laurent Vivier]

Le 25/01/2016 18:08, BALATON Zoltan a écrit :
> On Mon, 25 Jan 2016, Laurent Vivier wrote:
> > > > > > $ ./config/scripts/switch-arch ppc64
> > > > > > Configuring OpenBIOS on ppc64 for ppc64
> > > > > > Initializing build tree
> > > > > > /home/laurent/Projects/openbios/obj-ppc64...ok.
> > > > > > Creating target config.mak...ok.
> > > > > > Creating target rules.mak...ok.
> > > > > > Creating config files...ok.
> > > > > > [laurent@pmacg5-1 openbios]$ make
> > > > > > Building OpenBIOS for ppc64
> > > > > > Building...
> > > > > > error:
> > > > > > HOSTCC host/kernel/dict.o
> > > > > > HOSTCC host/kernel/bootstrap.o
> > > > > > HOSTCC host/kernel/forth.o
> > > > > > HOSTCC host/kernel/stack.o
> > > > > > HOSTCC forthstrap
> > > > > > GEN   bootstrap.dict
> > > > > > panic: segmentation violation at 0x87a1062c
> > > > > > dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628)
> > > > > > pc=0x0(dict+0x785efff0)
> > > > > > dstackcnt=0 rstackcnt=0 instruction=deadbeef
> > > > > > dstack: 0x0
> > > > > > rstack: 0x0
> > > > > > Writing dictionary core file
> > > > > > rules.mak:69: recipe for target 'bootstrap.dict' failed
> > > > > > make[1]: *** [bootstrap.dict] Error 1
> > > > > > make[1]: Leaving directory
> > > > > > '/home/laurent/Projects/openbios/obj-ppc64'
> > > > > > Makefile:19: recipe for target 'build' failed
> > > > > > make: *** [build] Error 1
>
> Does running 'make V=1' reveal more errors? Or maybe you could check
> bootstrap.dict-console.log or some other console.log files if they are
> created for some more clues whay it fails.

There isn't more detail with V=1

With gdb:
Program received signal SIGSEGV, Segmentation fault.
findword (s1=0x10007b80 "(semis)")
    at /home/laurent/Projects/openbios/kernel/dict.c:118
118			tmplfa = read_ucell(cell2pointer(tmplfa));

(gdb) whatis tmplfa
type = ucell
(gdb) whatis ucell
type = uint32_t

and in include/kernel/stack.h:

#ifdef NATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH

static inline ucell pointer2cell(const void* x)
{
    return (ucell)(uintptr_t)x;
}

static inline void* cell2pointer(ucell x)
{
    return (void*)(uintptr_t)x;
}

#endif

So I guess using an uint32_t to store a pointer on a 64bit machine can
cause some troubles.

I have no "include/arch/ppc64/types.h", is that normal ?
> > > > 64bit host: gcc (GCC) 5.1.1 20150618 (Red Hat 5.1.1-4)
>
> Can you try with gcc 4.x? 5.x could be stricter that might cause
> problems but of course best would be if that could be fixed.
>
> Regards,
> BALATON Zoltan

[BALATON Zoltan]

On Mon, 25 Jan 2016, Laurent Vivier wrote:
> There isn't more detail with V=1
>
> With gdb:
> Program received signal SIGSEGV, Segmentation fault.
> findword (s1=0x10007b80 "(semis)")
>    at /home/laurent/Projects/openbios/kernel/dict.c:118
> 118			tmplfa = read_ucell(cell2pointer(tmplfa));
>
> (gdb) whatis tmplfa
> type = ucell
> (gdb) whatis ucell
> type = uint32_t
>
> and in include/kernel/stack.h:
>
> #ifdef NATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH
>
> static inline ucell pointer2cell(const void* x)
> {
>    return (ucell)(uintptr_t)x;
> }
>
> static inline void* cell2pointer(ucell x)
> {
>    return (void*)(uintptr_t)x;
> }
>
> #endif
>
> So I guess using an uint32_t to store a pointer on a 64bit machine can
> cause some troubles.
>
> I have no "include/arch/ppc64/types.h", is that normal ?

Sorry, no idea. I don't seem to have include/arch/ppc64 in my tree from 
svn either but I don't know if that's normal or not. Maybe it is. Just 
thought posting more details might help others to help you. For example 
what was the command that got you the above gdb output and what's the full 
stack trace?

Probably you are right that it should use 64 bit value for pointers 
instead of 32 bit but I have no idea why it doesn't. Recent changes in 
this area seem to be:

1f52358fed8fc785e26539a3efce816cf36ee61e bootstrap: don't include files 
from target/include as system includes

that remove some typedefs added earlier by

4415741789e3acd525c265c641041c4fd60c3541 PPC: Add kernel header style 
typedefs

but I don't know if that's related.

Regards,
BALATON Zoltan

[BALATON Zoltan]

On Mon, 25 Jan 2016, Programmingkid wrote:
> The forthstrap command is what is producing the error message. I assume 
> it is 64 bit, but that assumption could be wrong. Could you report the 
> output of this command: file ./config/scripts/obj-ppc/forthstrap

Well, another idea, maybe we should compile this always as 32 bit in case 
it has problems with being 64 bit, although that seems to work on x86_64 
at least.

Regards,
BALATON Zoltan

[BALATON Zoltan]

On Mon, 25 Jan 2016, BALATON Zoltan wrote:
> of 32 bit but I have no idea why it doesn't. Recent changes in this area seem 
> to be:
>
> 1f52358fed8fc785e26539a3efce816cf36ee61e bootstrap: don't include files from 
> target/include as system includes
>
> that remove some typedefs added earlier by
>
> 4415741789e3acd525c265c641041c4fd60c3541 PPC: Add kernel header style 
> typedefs

I've realised these hashes from git svn might not be too meaningful, so 
the corresponding svn revisions are 1358 and 1171 respectively.

Regards,
BALATON Zoltan

[Programmingkid]

On Jan 25, 2016, at 12:48 PM, BALATON Zoltan wrote:
> On Mon, 25 Jan 2016, Programmingkid wrote:
> > The forthstrap command is what is producing the error message. I assume it is 64 bit, but that assumption could be wrong. Could you report the output of this command: file ./config/scripts/obj-ppc/forthstrap
>
> Well, another idea, maybe we should compile this always as 32 bit in case it has problems with being 64 bit, although that seems to work on x86_64 at least.

I suppose we could add code that detects ppc64 and print a message that says "64 bit PowerPC is not supported. Please use 32 bit instead". But I think correcting the problem might be better. The 64 bit code would have full access to the 64 bit CPU and might be faster.

My forthstrap is 64 bits. Here is the 'file' output on the file (no pun intended):
Mach-O 64-bit executable x86_64

What does the file command say about your forthstrap file? 
file ./config/scripts/obj-ppc/forthstrap

Are you using a 32 bit or 64 bit kernel? 
"uname -a" will tell.

[Programmingkid]

On Jan 25, 2016, at 12:25 PM, Laurent Vivier wrote:
> Le 25/01/2016 18:08, BALATON Zoltan a écrit :
> > On Mon, 25 Jan 2016, Laurent Vivier wrote:
> > > > > > > $ ./config/scripts/switch-arch ppc64
> > > > > > > Configuring OpenBIOS on ppc64 for ppc64
> > > > > > > Initializing build tree
> > > > > > > /home/laurent/Projects/openbios/obj-ppc64...ok.
> > > > > > > Creating target config.mak...ok.
> > > > > > > Creating target rules.mak...ok.
> > > > > > > Creating config files...ok.
> > > > > > > [laurent@pmacg5-1 openbios]$ make
> > > > > > > Building OpenBIOS for ppc64
> > > > > > > Building...
> > > > > > > error:
> > > > > > > HOSTCC host/kernel/dict.o
> > > > > > > HOSTCC host/kernel/bootstrap.o
> > > > > > > HOSTCC host/kernel/forth.o
> > > > > > > HOSTCC host/kernel/stack.o
> > > > > > > HOSTCC forthstrap
> > > > > > > GEN   bootstrap.dict
> > > > > > > panic: segmentation violation at 0x87a1062c
> > > > > > > dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628)
> > > > > > > pc=0x0(dict+0x785efff0)
> > > > > > > dstackcnt=0 rstackcnt=0 instruction=deadbeef
> > > > > > > dstack: 0x0
> > > > > > > rstack: 0x0
> > > > > > > Writing dictionary core file
> > > > > > > rules.mak:69: recipe for target 'bootstrap.dict' failed
> > > > > > > make[1]: *** [bootstrap.dict] Error 1
> > > > > > > make[1]: Leaving directory
> > > > > > > '/home/laurent/Projects/openbios/obj-ppc64'
> > > > > > > Makefile:19: recipe for target 'build' failed
> > > > > > > make: *** [build] Error 1
> >
> > Does running 'make V=1' reveal more errors? Or maybe you could check
> > bootstrap.dict-console.log or some other console.log files if they are
> > created for some more clues whay it fails.
>
> There isn't more detail with V=1
>
> With gdb:
> Program received signal SIGSEGV, Segmentation fault.
> findword (s1=0x10007b80 "(semis)")
>    at /home/laurent/Projects/openbios/kernel/dict.c:118
> 118			tmplfa = read_ucell(cell2pointer(tmplfa));
>
> (gdb) whatis tmplfa
> type = ucell
> (gdb) whatis ucell
> type = uint32_t
>
> and in include/kernel/stack.h:
>
> #ifdef NATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH
>
> static inline ucell pointer2cell(const void* x)
> {
>    return (ucell)(uintptr_t)x;
> }
>
> static inline void* cell2pointer(ucell x)
> {
>    return (void*)(uintptr_t)x;
> }
>
> #endif
>
> So I guess using an uint32_t to store a pointer on a 64bit machine can
> cause some troubles.
>
> I have no "include/arch/ppc64/types.h", is that normal ?

I think we just found the problem. It looks like we need this file for the ppc64 target.

The include/arch/amd64/types.h file could be used as a template for the include/arch/ppc64/types.h file. Actually you can get away with copying and pasting the file since nothing in it is amd64 specific.

[Mark Cave-Ayland]

On 25/01/16 17:25, Laurent Vivier wrote:
> Le 25/01/2016 18:08, BALATON Zoltan a écrit :
> > On Mon, 25 Jan 2016, Laurent Vivier wrote:
> > > > > > > $ ./config/scripts/switch-arch ppc64
> > > > > > > Configuring OpenBIOS on ppc64 for ppc64
> > > > > > > Initializing build tree
> > > > > > > /home/laurent/Projects/openbios/obj-ppc64...ok.
> > > > > > > Creating target config.mak...ok.
> > > > > > > Creating target rules.mak...ok.
> > > > > > > Creating config files...ok.
> > > > > > > [laurent@pmacg5-1 openbios]$ make
> > > > > > > Building OpenBIOS for ppc64
> > > > > > > Building...
> > > > > > > error:
> > > > > > > HOSTCC host/kernel/dict.o
> > > > > > > HOSTCC host/kernel/bootstrap.o
> > > > > > > HOSTCC host/kernel/forth.o
> > > > > > > HOSTCC host/kernel/stack.o
> > > > > > > HOSTCC forthstrap
> > > > > > > GEN   bootstrap.dict
> > > > > > > panic: segmentation violation at 0x87a1062c
> > > > > > > dict=0x3fff87a10010 here=0x3fff87a10638(dict+0x628)
> > > > > > > pc=0x0(dict+0x785efff0)
> > > > > > > dstackcnt=0 rstackcnt=0 instruction=deadbeef
> > > > > > > dstack: 0x0
> > > > > > > rstack: 0x0
> > > > > > > Writing dictionary core file
> > > > > > > rules.mak:69: recipe for target 'bootstrap.dict' failed
> > > > > > > make[1]: *** [bootstrap.dict] Error 1
> > > > > > > make[1]: Leaving directory
> > > > > > > '/home/laurent/Projects/openbios/obj-ppc64'
> > > > > > > Makefile:19: recipe for target 'build' failed
> > > > > > > make: *** [build] Error 1
> >
> > Does running 'make V=1' reveal more errors? Or maybe you could check
> > bootstrap.dict-console.log or some other console.log files if they are
> > created for some more clues whay it fails.
>
> There isn't more detail with V=1
>
> With gdb:
> Program received signal SIGSEGV, Segmentation fault.
> findword (s1=0x10007b80 "(semis)")
>     at /home/laurent/Projects/openbios/kernel/dict.c:118
> 118			tmplfa = read_ucell(cell2pointer(tmplfa));
>
> (gdb) whatis tmplfa
> type = ucell
> (gdb) whatis ucell
> type = uint32_t
>
> and in include/kernel/stack.h:
>
> #ifdef NATIVE_BITWIDTH_EQUALS_HOST_BITWIDTH
>
> static inline ucell pointer2cell(const void* x)
> {
>     return (ucell)(uintptr_t)x;
> }
>
> static inline void* cell2pointer(ucell x)
> {
>     return (void*)(uintptr_t)x;
> }
>
> #endif
>
> So I guess using an uint32_t to store a pointer on a 64bit machine can
> cause some troubles.

Hmmm yeah that definitely doesn't seem right.
> I have no "include/arch/ppc64/types.h", is that normal ?

Good question - I think Andreas was the person who added 64-bit support,
and from memory it may be sharing the 32-bit PPC types. If you use a
separate ppc64 types.h then do you get any further?


ATB,

Mark.

[Programmingkid]

Did you ever figure out how to make OpenBIOS on your PowerPC64 system?

[Mark Cave-Ayland]

On 22/01/16 15:05, Andreas Färber wrote:
> Am 22.01.2016 um 14:59 schrieb Mark Cave-Ayland:
> > On 20/01/16 08:33, Laurent Vivier wrote:
> > > Le 19/01/2016 21:33, Mark Cave-Ayland a écrit :
> > > > Great! If we go with Segher's suggestion for 64-bit then we end up with
> > > > this:
> > > >
> > > > 32-bit: -mcpu=604
> > > > 64-bit: -mcpu=970 -mno-altivec
> > >
> > > I think you can use "-mcpu=power4" here, this is the old default value
> > > for gcc.
> >
> > It seems they are effectively the same, so I don't have any strong
> > preference either way.
>
> I prefer Mark's explicit variant, ideally with some explanatory comment.

There hasn't been any further discussion, so I've just posted an updated
version of the patch based on Andreas' comments. Barring any objections,
I'll commit this to SVN trunk tomorrow evening.


ATB,

Mark.