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 laurent@vivier.eu --- 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" ;;
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 laurent@vivier.eu
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 crobinso@redhat.com
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 laurent@vivier.eu
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.
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 laurent@vivier.eu
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.
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 laurent@vivier.eu
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
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 laurent@vivier.eu
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.
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
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
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.
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
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
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
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
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é
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.
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.
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.
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
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.
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
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?
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
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?
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
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
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
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
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
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.
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.
Did you ever figure out how to make OpenBIOS on your PowerPC64 system?
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.
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
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.
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.
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