2:01 a.m.
In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated and
KVM CPU’s, I suppose it would be good to enter some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
<https://opensource.apple.com/tarballs/BootX/>
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
There are few other useful debugging tech- niques. Setting "auto-boot?" to false
will cause the system to enter the OpenFirmware User In- terface by default. Changing
kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on error, so
that it will return to Open- Firmware. Finally, calling Enter(), will cause BootX to drop
back into the OpenFirmware User Interface. This can be used as a break point. The
"dumpl" word will dump some memory, by en- tering the address, then the length,
then "dumpl". By calling printf in BootX immediately before En- ter(), the
address can be easily determined, and the variable can then be examined and altered from
OpenFirmware. Finally typing the "go" command will resume BootX’s execution.
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends some
info to the screen, seemingly via open firware, while displaying the “Apple Logo” boot
graphic. The info show some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I
might be able to do that?
2:14 a.m.
Hi,
Instead of going directly, go thru
https://opensource.apple.com/
then you can choose the Mac OS X version and see only the tarballs
applicable to that specified version like this:
https://opensource.apple.com/release/mac-os-x-1013.html
gives BootX-36 for Mac OS X 10.1.3.
On 25/01/18 15:01, Jd Lyons via OpenBIOS wrote:
In an effort to figure out why qemu-system-ppc hangs
at BootX when using
some emulated and KVM CPU’s, I suppose it would be good to enter some
breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m
looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
*There are few other useful debugging tech- niques. Setting "auto-boot?"
to false will cause the system to enter the OpenFirmware User In-
terface by default. Changing kFailToBoot to 0 in include.tproj/sl.h will
alter BootX’s default be- havior on error, so that it will return to
Open- Firmware. Finally, calling Enter(), will cause BootX to drop back
into the OpenFirmware User **Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the
address, then the length, then "dumpl". By calling printf in BootX
immediately before En- ter(), the address can be easily determined, and
the variable can then be examined and altered from OpenFirmware. Finally
typing the "go" command will resume BootX’s execution. *
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding
command+v BootX sends some info to the screen, seemingly via open
firware, while displaying the “Apple Logo” boot graphic. The info show
some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has
any idea how I might be able to do that?
7:24 p.m.
On Jan 25, 2018, at 10:14 AM, Natalia Portillo
<claunia(a)claunia.com> wrote:
Hi,
Instead of going directly, go thru
https://opensource.apple.com/
then you can choose the Mac OS X version and see only the tarballs
applicable to that specified version like this:
https://opensource.apple.com/release/mac-os-x-1013.html
gives BootX-36 for Mac OS X 10.1.3.
On 25/01/18 15:01, Jd Lyons via OpenBIOS wrote:
Thanks, it’s been so many years since I looked at these sources, I forgot I could navigate
the site that way.
In an effort to figure out why qemu-system-ppc
hangs at BootX when using
some emulated and KVM CPU’s, I suppose it would be good to enter some
breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m
looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
*There are few other useful debugging tech- niques. Setting "auto-boot?"
to false will cause the system to enter the OpenFirmware User In-
terface by default. Changing kFailToBoot to 0 in include.tproj/sl.h will
alter BootX’s default be- havior on error, so that it will return to
Open- Firmware. Finally, calling Enter(), will cause BootX to drop back
into the OpenFirmware User **Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the
address, then the length, then "dumpl". By calling printf in BootX
immediately before En- ter(), the address can be easily determined, and
the variable can then be examined and altered from OpenFirmware. Finally
typing the "go" command will resume BootX’s execution. *
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding
command+v BootX sends some info to the screen, seemingly via open
firware, while displaying the “Apple Logo” boot graphic. The info show
some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has
any idea how I might be able to do that?
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
2:18 a.m.
On Jan 25, 2018, at 10:01 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated
and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
There are few other useful debugging tech- niques. Setting "auto-boot?" to
false will cause the system to enter the OpenFirmware User In- terface by default.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution.
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends
some info to the screen, seemingly via open firware, while displaying the “Apple Logo”
boot graphic. The info show some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I
might be able to do that?
Have you tried adding "-prom-env boot-args=-v" to QEMU's arguments yet?
7:32 p.m.
On Jan 25, 2018, at 10:18 AM, Programmingkid
<programmingkidx(a)gmail.com> wrote:
Yes, I usually use -prom-env 'boot-args=-v debug=0xffe kdp=2’.
On a real PPC Mac BootX seems to give some extra debug in fo with command+V, tho most of
the time it goes by so fast that it’s unreadable. Booting from a slower drive like USB
yield the kind of info I’m looking for, to be able to tell at what stage BootX is
hanging.
Unfortunately, this debug info is no sent to the screen, or stdio in OpenBios, or I just
haven’t figured out how to do that yet.
On Jan 25, 2018, at 10:01 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated
and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
There are few other useful debugging tech- niques. Setting "auto-boot?" to
false will cause the system to enter the OpenFirmware User In- terface by default.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution.
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends
some info to the screen, seemingly via open firware, while displaying the “Apple Logo”
boot graphic. The info show some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I
might be able to do that?
Have you tried adding "-prom-env boot-args=-v" to QEMU's arguments yet?
2:37 a.m.
On Jan 26, 2018, at 3:32 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
There is another way to see what boots sends to the screen. That is to record the output
of the screen. I use to do this when I had to read the output from Mac OS X when it was
booting. I used Quicktime X to record the screen. Since you are on Linux there may be
other options. You could take the output of your computer and send it to a a DVD recorder,
VCR, DVR, Camcorder, etc... You might even want to try aiming your camera phone at the
screen and record what Bootx is displaying.
https://itsfoss.com/best-linux-screen-recorders/
This page list several programs that can record your screen on Linux. I just don't
think it would help on a PowerPC Mac.
On Jan 25, 2018, at 10:18 AM, Programmingkid
<programmingkidx(a)gmail.com> wrote:
Yes, I usually use -prom-env 'boot-args=-v debug=0xffe kdp=2’.
On a real PPC Mac BootX seems to give some extra debug in fo with command+V, tho most of
the time it goes by so fast that it’s unreadable. Booting from a slower drive like USB
yield the kind of info I’m looking for, to be able to tell at what stage BootX is
hanging.
Unfortunately, this debug info is no sent to the screen, or stdio in OpenBios, or I just
haven’t figured out how to do that yet. On Jan 25, 2018, at 10:01 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated
and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
There are few other useful debugging tech- niques. Setting "auto-boot?" to
false will cause the system to enter the OpenFirmware User In- terface by default.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution.
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends
some info to the screen, seemingly via open firware, while displaying the “Apple Logo”
boot graphic. The info show some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I
might be able to do that?
Have you tried adding "-prom-env boot-args=-v" to QEMU's arguments yet?
8:39 p.m.
On Jan 26, 2018, at 10:37 AM, Programmingkid
<programmingkidx(a)gmail.com> wrote:
Here is what is happening with the emulated 7448( failed boot ):
/home/jam/Tiger/qemu-install/bin/qemu-system-ppc -M mac99 -m 768 -cpu 7410 -hda
'/home/jam/os9/Tiger.img' -bios '/home/jam/Documents/openbios-qemu.elf'
-netdev user,id=mynet0 -device sungem,netdev=mynet0 -prom-env 'auto-boot?=false'
-cpu 7448 -nographic
On Jan 26, 2018, at 3:32 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote:
There is another way to see what boots sends to the screen. That is to record the output
of the screen. I use to do this when I had to read the output from Mac OS X when it was
booting. I used Quicktime X to record the screen. Since you are on Linux there may be
other options. You could take the output of your computer and send it to a a DVD recorder,
VCR, DVR, Camcorder, etc... You might even want to try aiming your camera phone at the
screen and record what Bootx is displaying.
On Jan 25, 2018, at 10:18 AM, Programmingkid
<programmingkidx(a)gmail.com> wrote:
Yes, I usually use -prom-env 'boot-args=-v debug=0xffe kdp=2’.
On a real PPC Mac BootX seems to give some extra debug in fo with command+V, tho most of
the time it goes by so fast that it’s unreadable. Booting from a slower drive like USB
yield the kind of info I’m looking for, to be able to tell at what stage BootX is
hanging.
Unfortunately, this debug info is no sent to the screen, or stdio in OpenBios, or I just
haven’t figured out how to do that yet. On Jan 25, 2018, at 10:01 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated
and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
There are few other useful debugging tech- niques. Setting "auto-boot?" to
false will cause the system to enter the OpenFirmware User In- terface by default.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution.
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends
some info to the screen, seemingly via open firware, while displaying the “Apple Logo”
boot graphic. The info show some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I
might be able to do that?
Have you tried adding "-prom-env boot-args=-v" to QEMU's arguments yet?
>
=============================================================
> OpenBIOS 1.1 [Jan 22 2018 11:12]
> Configuration device id QEMU version 1 machine id 1
> CPUs: 1
> Memory: 768M
> UUID: 00000000-0000-0000-0000-000000000000
> CPU type PowerPC,MPC86xx
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
0 > boot hd:10,\ppc\bootx >> switching to new context:
Mac OS X Loader
depthbytes isn't unique.
rowbytes isn't unique.
FILL-RECTANGLE isn't unique.
Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
HFSInitPartition: 2fc5b254
Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
Loading HFS+ file: [\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7]
from 2fc5b254.
Call Kernel!
FailToBoot: 6
ENTER
Here is a successful boot on a 7410:
/home/jam/Tiger/qemu-install/bin/qemu-system-ppc -M mac99 -m 768 -cpu 7410 -hda
'/home/jam/os9/Tiger.img' -bios '/home/jam/Documents/openbios-qemu.elf'
-netdev user,id=mynet0 -device sungem,netdev=mynet0 -prom-env 'auto-boot?=false'
-cpu 7410 -nographic -prom-env 'boot-args= -v debug=0xffe kdp=2'
>
=============================================================
> OpenBIOS 1.1 [Jan 22 2018 11:12]
> Configuration device id QEMU version 1 machine id 1
> CPUs: 1
> Memory: 768M
> UUID: 00000000-0000-0000-0000-000000000000
> CPU type PowerPC,74xx
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
0 > boot hd:10,\ppc\bootx >> switching to new context:
Mac OS X Loader
depthbytes isn't unique.
rowbytes isn't unique.
FILL-RECTANGLE isn't unique.
Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
HFSInitPartition: 2fc5b250
Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b250.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
Reading HFS+ file: [\\mach_kernel] from 2fc5b250.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
Loading HFS+ file: [\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7]
from 2fc5b250.
Call Kernel!
Trying to read invalid spr 1015 (0x3f7) at 00092744
kprintf initialized
max_mem: 768 M
version_variant = 0
version = Darwin Kernel Version 8.11.0: Wed Oct 10 18:26:00 PDT 2007;
root:xnu-792.24.17~1/RELEASE_PPC
proc version = 800c1104
initialize_screen: b=00000000, w=00000000, h=00000000, r=00000000
initialize_screen: No video - forcing serial mode
standard timeslicing quantum is 10000 us
pmap_steal_memory: 00AAE000 - 00AAF000; size=00001000
pmap_steal_memory: 00AAF000 - 00BB2000; size=00103000
pmap_steal_memory: 00BB2000 - 00BB5000; size=00003000
pmap_steal_memory: 00BB5000 - 00CB5000; size=00100000
pmap_steal_memory: 00CB5000 - 014B0694; size=007FB694
vm_page_bootstrap: 190223 free pages
mig_table_max_displ = 70
And here is a failed boot on an emulated 970:
qemu-system-ppc64 -M mac99 -m 768 -hda '/home/jam/os9/Tiger.img' -bios
'/home/jam/Documents/openbios-qemu.elf' -netdev user,id=mynet0 -prom-env
'auto-boot?=false' -cpu 970 -nographic
Warning: netdev mynet0 has no peer
>
=============================================================
> OpenBIOS 1.1 [Jan 22 2018 11:12]
> Configuration device id QEMU version 1 machine id 3
> CPUs: 1
> Memory: 768M
> UUID: 00000000-0000-0000-0000-000000000000
> CPU type PowerPC,970
milliseconds isn't unique.
Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
0 > boot hd:10,\ppc\bootx >> switching to new context:
Mac OS X Loader
depthbytes isn't unique.
rowbytes isn't unique.
FILL-RECTANGLE isn't unique.
Opening partition [/pci@f0000000/mac-io@c/ata-3@20000/disk@0:10]...
HFSInitPartition: 2fc5b250
Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b250.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
Reading HFS+ file: [\\mach_kernel] from 2fc5b250.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
Reading HFS+ file: [\mach_kernel] from 2fc5b250.
Reading HFS+ file: [\mach_kernel] from 2fc5b250.
FileLoadDrivers: Loading from
[/pci@f0000000/mac-io@c/ata-3@20000/disk@0:10,\System\Library\Extensions.mkext]
Reading HFS+ file: [\System\Library\Extensions.mkext] from 2fc5b250.
Reading HFS+ file: [\System\Library\Extensions.mkext] from 2fc5b250.
Call Kernel!
Trying to write invalid spr 276 (0x114) at 00000000000afc14
Trying to read invalid spr 277 (0x115) at 00000000000afc18
Trying to read invalid spr 276 (0x114) at 00000000000afc1c
Trying to write invalid spr 277 (0x115) at 00000000000afc38
Trying to write invalid spr 276 (0x114) at 00000000000afc3c
Trying to read invalid spr 276 (0x114) at 00000000000afc40
Trying to write invalid spr 277 (0x115) at 00000000000afcec
Trying to write invalid spr 276 (0x114) at 00000000000afcf0
Trying to read invalid spr 276 (0x114) at 00000000000afcf4
Trying to write invalid spr 304 (0x130) at 0000000000003d28
Trying to read invalid spr 304 (0x130) at 0000000000003d4c
Trying to write invalid spr 304 (0x130) at 0000000000003d28
Trying to read invalid spr 304 (0x130) at 0000000000003d4c
Trying to write invalid spr 304 (0x130) at 0000000000003d28
Trying to read invalid spr 304 (0x130) at 0000000000003d4c
Trying to write invalid spr 304 (0x130) at 0000000000003d28
Trying to read invalid spr 304 (0x130) at 0000000000003d4c
Trying to write invalid spr 304 (0x130) at 0000000000003d28
Trying to read invalid spr 304 (0x130) at 0000000000003d4c
Trying to write invalid spr 304 (0x130) at 0000000000003d28
Trying to read invalid spr 304 (0x130) at 0000000000003d4c
https://itsfoss.com/best-linux-screen-recorders/
<https://itsfoss.com/best-linux-screen-recorders/>
This page list several programs that can record your screen on Linux. I just don't
think it would help on a PowerPC Mac.
--
OpenBIOS http://openbios.org/ <http://openbios.org/>
Mailinglist: http://lists.openbios.org/mailman/listinfo
<http://lists.openbios.org/mailman/listinfo>
Free your System - May the Forth be with you
11:33 p.m.
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
0 > boot hd:10,\ppc\bootx >> switching to new context:
Mac OS X Loader
depthbytes isn't unique.
rowbytes isn't unique.
FILL-RECTANGLE isn't unique.
Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
HFSInitPartition: 2fc5b254
Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
Loading HFS+ file: [\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7]
from 2fc5b254.
Call Kernel!
FailToBoot: 6
ENTER
So maybe you're looking for the problem at the wrong place when debugging
BootX. It says it has transferred execution to the loaded kernel and it's
the kernel which failed. Does the kernel version you're trying to boot
support this CPU type at all?
Regards,
BALATON Zoltan
12:41 a.m.
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
> Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
>
> 0 > boot hd:10,\ppc\bootx >> switching to new context:
>
>
> Mac OS X Loader
> depthbytes isn't unique.
> rowbytes isn't unique.
> FILL-RECTANGLE isn't unique.
> Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
> HFSInitPartition: 2fc5b254
> Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
> setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
> setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
> non-root file owner detected: 501
> Loading HFS+ file:
[\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7] from 2fc5b254.
>
> Call Kernel!
> FailToBoot: 6
> ENTER
Excellent job with capturing Bootx's output.
So maybe you're looking for the problem at the wrong place when debugging BootX. It
says it has transferred execution to the loaded kernel and it's the kernel which
failed. Does the kernel version you're trying to boot support this CPU type at all?
Back when I would build the Mach kernel I would place a bunch of printf statements to see
what it is doing. This is an easy way to debug the kernel. What version of Mac OS X are
you currently trying to boot? If you want help with building and running a custom kernel
just let me know.
1:34 a.m.
On Jan 27, 2018, at 8:41 AM, Programmingkid
<programmingkidx(a)gmail.com> wrote:
Yes, I think a custom kernel maybe what’s needed, there is some magic that qemu-ppc is not
doing. A custom kernel can boot on the 7448, as I have already confirmed. I was hoping to
avoid that, but until someone that is familiar with how qemu-ppc boot OS X, I’ll just have
to try the custom kernel route.
For the 7448, I used the kernel linked in these tread:
https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/
<https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/...
If we can figure out what changes were made that allowed qemu-ppc to boot with it, we
should be able to figure out how to get the 7447a/7450/7455 to boot with it.
I never had any luck building mach_kernel, but I have’t tried in years, so you’ll have to
walk me trough it.
I’ll ask LightBulbFun if he can get us a diff of his changes for 604 support, or at least
give us an overview of how to add cpu support to the kernel.
There is still one thing I’d like to do with bootx, if you can help with that.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution.
I don’t understand how, or where in the code to call Enter(), or printf?
All I changed was kFailToBoot to 0 in the sl.h. That was enough to get BootX to output
some debug info for us, but if you say that we’re done with bootx when it calls the
kernel( jumping to the memory where it loaded the kernel in real mode? ), then we can skip
this.
Balaton, I was trying to boot 10.4.11 with the 7448, so the kernel should support it.
Thanks,
James
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
> Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
>
> 0 > boot hd:10,\ppc\bootx >> switching to new context:
>
>
> Mac OS X Loader
> depthbytes isn't unique.
> rowbytes isn't unique.
> FILL-RECTANGLE isn't unique.
> Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
> HFSInitPartition: 2fc5b254
> Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
> setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
> setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
> non-root file owner detected: 501
> Loading HFS+ file:
[\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7] from 2fc5b254.
>
> Call Kernel!
> FailToBoot: 6
> ENTER
Excellent job with capturing Bootx's output.
So maybe you're looking for the problem at the wrong place when debugging BootX. It
says it has transferred execution to the loaded kernel and it's the kernel which
failed. Does the kernel version you're trying to boot support this CPU type at all?
Back when I would build the Mach kernel I would place a bunch of printf statements to see
what it is doing. This is an easy way to debug the kernel. What version of Mac OS X are
you currently trying to boot? If you want help with building and running a custom kernel
just let me know.
1:41 a.m.
On Jan 27, 2018, at 9:34 AM, Jd Lyons
<lyons_dj(a)yahoo.com> wrote:
I think dumpl isn't defined in OpenBIOS. dump is defined. From the description you
send it sounds exactly like dump. I'm thinking defining dumpl like this might be of
use to you:
: dumpl dump ;
On Jan 27, 2018, at 8:41 AM, Programmingkid
<programmingkidx(a)gmail.com> wrote:
Yes, I think a custom kernel maybe what’s needed, there is some magic that qemu-ppc is
not doing. A custom kernel can boot on the 7448, as I have already confirmed. I was hoping
to avoid that, but until someone that is familiar with how qemu-ppc boot OS X, I’ll just
have to try the custom kernel route.
For the 7448, I used the kernel linked in these tread:
https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/
If we can figure out what changes were made that allowed qemu-ppc to boot with it, we
should be able to figure out how to get the 7447a/7450/7455 to boot with it.
I never had any luck building mach_kernel, but I have’t tried in years, so you’ll have to
walk me trough it.
I’ll ask LightBulbFun if he can get us a diff of his changes for 604 support, or at least
give us an overview of how to add cpu support to the kernel.
There is still one thing I’d like to do with bootx, if you can help with that.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution.
I don’t understand how, or where in the code to call Enter(), or printf?
All I changed was kFailToBoot to 0 in the sl.h. That was enough to get BootX to output
some debug info for us, but if you say that we’re done with bootx when it calls the
kernel( jumping to the memory where it loaded the kernel in real mode? ), then we can skip
this.
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
> Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
>
> 0 > boot hd:10,\ppc\bootx >> switching to new context:
>
>
> Mac OS X Loader
> depthbytes isn't unique.
> rowbytes isn't unique.
> FILL-RECTANGLE isn't unique.
> Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
> HFSInitPartition: 2fc5b254
> Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
> setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
> setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
> non-root file owner detected: 501
> Loading HFS+ file:
[\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7] from 2fc5b254.
>
> Call Kernel!
> FailToBoot: 6
> ENTER
Excellent job with capturing Bootx's output.
So maybe you're looking for the problem at the wrong place when debugging BootX. It
says it has transferred execution to the loaded kernel and it's the kernel which
failed. Does the kernel version you're trying to boot support this CPU type at all?
Back when I would build the Mach kernel I would place a bunch of printf statements to see
what it is doing. This is an easy way to debug the kernel. What version of Mac OS X are
you currently trying to boot? If you want help with building and running a custom kernel
just let me know.
3:36 a.m.
On Jan 27, 2018, at 9:41 AM, Programmingkid
<programmingkidx(a)gmail.com> wrote:
Here was LightbulbFun’s reply:
"indeed I noticed that it lets OS X boot on QEMUs 7448 as well
and that OS X acts the same as it does on a 604 CPU (doing generic PPC rather then
anything PPC750 7400 7450 or 970)
it makes me all the more eiger to get ahold of real 7448 hardware to play with (id like to
know if the reason OS X wont boot on the 7448 option in QEMU is because the emulation is
incompleat or if the 7448 really is not compatible with OS X)
here is the the pice of source code I modified
https://mega.nz/#!YRBjiSDJ!7wGiXz49VaFl6i8UPn4VkZxyg9EPTt6cv0Z08CA7JZQ
<https://mega.nz/#!YRBjiSDJ!7wGiXz49VaFl6i8UPn4VkZxyg9EPTt6cv0Z08CA7JZQ>
its basically commenting out the line which says Bail/halt if unknown CPU, by commenting
it out it no longer bails and continues to boot using the generic PowerPC config (this is
how it was up until the G5 build of 10.2.8 where they added the line to bail)
Apple still hosts the Darwin source code for almost every version of OS X
its well worth having a look through
like for example how Apple added Penryn support to 10.4.11 even tho the first Penryn macs
shipped with 10.5”
PK, I wonder why removing Bail/halt if unknown CPU doesn’t make the 7447a cpu boot this
kernel.
Anyway, if you could give me so tips on building a new kernel, I’ll play around with it
and see if I can get some more cpu’s in qemu-ppc to boot.
On Jan 27, 2018, at 9:34 AM, Jd Lyons <lyons_dj(a)yahoo.com> wrote:
I think dumpl isn't defined in OpenBIOS. dump is defined. From the description you
send it sounds exactly like dump. I'm thinking defining dumpl like this might be of
use to you:
: dumpl dump ; On Jan 27, 2018, at 8:41 AM, Programmingkid
<programmingkidx(a)gmail.com> wrote:
Yes, I think a custom kernel maybe what’s needed, there is some magic that qemu-ppc is
not doing. A custom kernel can boot on the 7448, as I have already confirmed. I was hoping
to avoid that, but until someone that is familiar with how qemu-ppc boot OS X, I’ll just
have to try the custom kernel route.
For the 7448, I used the kernel linked in these tread:
https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/
If we can figure out what changes were made that allowed qemu-ppc to boot with it, we
should be able to figure out how to get the 7447a/7450/7455 to boot with it.
I never had any luck building mach_kernel, but I have’t tried in years, so you’ll have to
walk me trough it.
I’ll ask LightBulbFun if he can get us a diff of his changes for 604 support, or at least
give us an overview of how to add cpu support to the kernel.
There is still one thing I’d like to do with bootx, if you can help with that.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution.
I don’t understand how, or where in the code to call Enter(), or printf?
All I changed was kFailToBoot to 0 in the sl.h. That was enough to get BootX to output
some debug info for us, but if you say that we’re done with bootx when it calls the
kernel( jumping to the memory where it loaded the kernel in real mode? ), then we can skip
this.
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
> Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12
>
> 0 > boot hd:10,\ppc\bootx >> switching to new context:
>
>
> Mac OS X Loader
> depthbytes isn't unique.
> rowbytes isn't unique.
> FILL-RECTANGLE isn't unique.
> Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
> HFSInitPartition: 2fc5b254
> Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
> setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> non-root file owner detected: 501
> Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
> setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
> non-root file owner detected: 501
> Loading HFS+ file:
[\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7] from 2fc5b254.
>
> Call Kernel!
> FailToBoot: 6
> ENTER
Excellent job with capturing Bootx's output.
So maybe you're looking for the problem at the wrong place when debugging BootX. It
says it has transferred execution to the loaded kernel and it's the kernel which
failed. Does the kernel version you're trying to boot support this CPU type at all?
Back when I would build the Mach kernel I would place a bunch of printf statements to see
what it is doing. This is an easy way to debug the kernel. What version of Mac OS X are
you currently trying to boot? If you want help with building and running a custom kernel
just let me know.
5:23 a.m.
On Sat, 27 Jan 2018, Jd Lyons wrote:
Yes, I think a custom kernel maybe what’s needed,
there is some magic
that qemu-ppc is not doing. A custom kernel can boot on the 7448, as I
have already confirmed. I was hoping to avoid that, but until someone
that is familiar with how qemu-ppc boot OS X, I’ll just have to try the
custom kernel route.
For the 7448, I used the kernel linked in these tread:
https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/
If we can figure out what changes were made that allowed qemu-ppc to
boot with it, we should be able to figure out how to get the
7447a/7450/7455 to boot with it.
I'm just missing the point doing this. If it already works with the CPU
type called G4 in QEMU (which seems to be an alias to 7400_v2.9) what
would it bring to make it also boot with all these other CPU types that
seem to be newer versions of the same G4 but were not normally found in
real Macs?
I don't know these CPUs too well but if you're hoping to achieve faster
emulation by emulating chips that were faster in hardware I'm not sure it
works that way. Emulation is different than hardware so what's faster in
hardware may actually be slower in emulation if it's more complex and thus
there're more things to emulate versus one that's simple to emulate (that
is the simplest G4 chip in this case). It may only be useful to emulate
more complex G4 CPUs if those have additional instructions which QEMU has
(or can have) optimised emulation for (and even then only when OS X
actually uses them which is not likely if it wasn't optimised for these
CPUs). But I'm not sure this is the case here. Does the later G4 chips
have any ISA differences that could bring more speed in emulation or are
they just different in hardware implementation? If it's the latter than I
think making them work in QEMU would not bring any performance improvement
and the reason they don't work is likely that QEMU does not (or not
correctly) emulate some of the added complexity these chips have. But
someone correct me if I'm wrong, I don't know much about these CPUs but
I'd like to first see the point of this work. Otherwise there might be
better places to put effort than fixing emulation of rare CPUs with OSes
not meant to work with them.
Balaton, I was trying to boot 10.4.11 with the 7448,
so the kernel
should support it.
Why do you think so? According to
https://everymac.com/systems/by_processor/powerpc-g4-powerpc-7400-macs.html
this CPU was not used in any Mac. Why would've Apple added support for it?
Regards,
BALATON Zoltan
7:40 a.m.
On Jan 27, 2018, at 1:23 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 27 Jan 2018, Jd Lyons wrote:
As I stated, the 7448 was used in upgrade cards for a Powermac G4, and the PDF I linked
says OS 9.2.2 or 10.3.5 or later. The point is Qemu builds for PowerPC too, and I’d like
to use -enable-kvm -cpu host on my Powerbook6,8 with 7447a, my iBook6,7 with 7447a, and my
Quicksilver with 7450/7455, but these CPU’s can’t boot OS X in qemu.
Why would we want an emulator that supports a wide range of CPU’s, used in real Macs, that
only boots a few of them.
Adding support for them help me to better understand how qemu works, how kvm works, and
how the cpus themselves work.
This hardware won’t last forever, it’s components will fail. Qemu will last as long as
it’s maintained, and it will be maintained as long as it’s useful. As it stands OS X
support for PPC stopped at 10.5 and most, if not all Linux distributions, are dropping
support for PPC32, and I don’t think anyone plans on building anything for PPC64 other
than Little Endian.
I was think of maintaining my own Linux distribution for PPC, and I want Qemu and KVM to
work correctly.
There is also a project to build a new PowerPC notebook, based on the NXP T208X e6500
64-bit Power Architecture® Core Technology
<http://www.freescale.com/webapp/sps/site/overview.jsp?code=E6500>;.
https://www.powerpc-notebook.org/en/
I’d like to buy one of these, if it ever comes to fruition, and I’d like to be able to
emulate the Mac OS on it.
Also, my two notebooks can’t boot OS 9, and I’m trying to figure out how to make that work
native on these old 7447a’s. It’s just much easier to use Qemu to debug this.
Yes, I think a custom kernel maybe what’s needed,
there is some magic that qemu-ppc is not doing. A custom kernel can boot on the 7448, as I
have already confirmed. I was hoping to avoid that, but until someone that is familiar
with how qemu-ppc boot OS X, I’ll just have to try the custom kernel route.
For the 7448, I used the kernel linked in these tread:
https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/
If we can figure out what changes were made that allowed qemu-ppc to boot with it, we
should be able to figure out how to get the 7447a/7450/7455 to boot with it.
I'm just missing the point doing this. If it already works with the CPU type called
G4 in QEMU (which seems to be an alias to 7400_v2.9) what would it bring to make it also
boot with all these other CPU types that seem to be newer versions of the same G4 but were
not normally found in real Macs?
I don't know these CPUs too well but if you're hoping to achieve faster emulation
by emulating chips that were faster in hardware I'm not sure it works that way.
Emulation is different than hardware so what's faster in hardware may actually be
slower in emulation if it's more complex and thus there're more things to emulate
versus one that's simple to emulate (that is the simplest G4 chip in this case). It
may only be useful to emulate more complex G4 CPUs if those have additional instructions
which QEMU has (or can have) optimised emulation for (and even then only when OS X
actually uses them which is not likely if it wasn't optimised for these CPUs). But
I'm not sure this is the case here. Does the later G4 chips have any ISA differences
that could bring more speed in emulation or are they just different in hardware
implementation? If it's the latter than I think making them work in QEMU would not
bring any performance improvement and the reason they don't work is likely that QEMU
does not (or not correctly) emulate some of the added complexity these chips have. But
someone correct me if I'm wrong, I don't know much about these CPUs but I'd
like to first see the point of this work. Otherwise there might be better places to put
effort than fixing emulation of rare CPUs with OSes not meant to work with them.
Balaton, I was trying to boot 10.4.11 with the
7448, so the kernel should support it.
Why do you think so? According to
https://everymac.com/systems/by_processor/powerpc-g4-powerpc-7400-macs.html this CPU was
not used in any Mac. Why would've Apple added support for it?
Regards,
BALATON Zoltan
9:50 a.m.
On Sat, 27 Jan 2018, Jd Lyons wrote:
As I stated, the 7448 was used in upgrade cards for a
Powermac G4, and
the PDF I linked says OS 9.2.2 or 10.3.5 or later. The point is Qemu
It also says a firmware patch is needed too. I wonder what those patches
do but this suggests an unpatched OS X would not boot without some
additional things.
builds for PowerPC too, and I’d like to use
-enable-kvm -cpu host on my
Powerbook6,8 with 7447a, my iBook6,7 with 7447a, and my Quicksilver with
7450/7455, but these CPU’s can’t boot OS X in qemu.
Do you mean it does not boot when you're using QEMU with kvm on those CPUs
or when you try to boot with an emulated 7447a CPU with TCG (no kvm)?
These may be two different cases and I'm not sure which one you've tested.
Why would we want an emulator that supports a wide
range of CPU’s, used
in real Macs, that only boots a few of them.
The Mac emulation in QEMU is far from perfect. In fact what it emulates is
not even a real Mac just some random hardware that resembles a PowerMac
enough that with some combinations some OS X versions work more or less.
But if you wander off these tried path problems are expected as probably
no-one have tried that yet or haven't fixed it yet. There's a lot to
improve and your effort in this is greatly appreciated, I'm just saying
that it's not expected to be ready and working with all the processors
even if those appear in the list of emulated CPUs as you've already found.
But back to the problem, from your previous messages it seems it booted
with a kernel that disabled the check for unknown CPUs so the problem
seems to be that the kernel cannot recognise the CPU as supported or it
tries to do something for these CPUs that does not work as expected in
QEMU. You may need to check what the mach_kernel does after started by
BootX and how it detects the CPU and if it would accept the CPU you've
specified (maybe it would with 7447a which was used in Macs but for 7448 I
would not expect that). The start.s you've linked seems to be the
processor detection that runs. Maybe you could try to enable the -d in_asm
debug option of QEMU that prints what guest code it runs and try to
correlate that to the mach_kernel source to find what it does and where it
fails.
Regards,
BALATON Zoltan
10:39 a.m.
On Jan 27, 2018, at 5:50 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 27 Jan 2018, Jd Lyons wrote:
For whatever reason, the 7448 boots and work just fine with the hypervisor, and TCG mode.
Tho I did note that Altivec doesn’t seem to work, but I only tested SkidmarksGT, so more
testing is needed.
As I stated, the 7448 was used in upgrade cards
for a Powermac G4, and the PDF I linked says OS 9.2.2 or 10.3.5 or later. The point is
Qemu
It also says a firmware patch is needed too. I wonder what those patches do but this
suggests an unpatched OS X would not boot without some additional things. builds for PowerPC too, and I’d like to use
-enable-kvm -cpu host on my Powerbook6,8 with 7447a, my iBook6,7 with 7447a, and my
Quicksilver with 7450/7455, but these CPU’s can’t boot OS X in qemu.
Do you mean it does not boot when you're using
QEMU with kvm on those CPUs or when you try to boot with an emulated 7447a CPU with TCG
(no kvm)? These may be two different cases and I'm not sure which one you've
tested.
I’m unable to boot openbios on TCG with the 7447a, 7450, 7455, or the 750fx, even tho I’ve
added support for them. Not sure the issue there.
However Openbios will boot with KVM with the -cpu 7447a, 7450, and 7455. Not the 750fx, I
have an old iBook with a 750fx, just got done putting a HD in it, so I’ll be installing
Linux to see if KVM works, I read that the G3 should support KVM, I just don’t know if KVM
support the G3.
With the 7450/7455( —enable-kvm -cpu 7450/7455 ), even with KVM, they can’t boot the Linux
Kernel from the Debian 8.10 installer.
Seems to fail the same way BootX fails, at the point where the “jump” to the machine
booting the kernel, meaning where the kernel should take over.
With the 7447a ( -enable-kvm -cpu 7447a ), boots the linux kernel and proceeds to the
installer. Never installed it, but I have no reason to believe that it won’t work after
install.
With -enable-kvm -cpu host, Debian install, runs and boots fine, no issues, other than the
L2 cache is not active, but that an issue with openbios, and I’m not sure how to deal with
that yet. Maybe just enable it in software while the OS is running, maybe add the code to
Openbios, that if it detects the hypervisor it should enable the L2/L3.
All the test were done on my Powerbook6,8 with 7447a.
Why would we
want an emulator that supports a wide range of CPU’s, used in real Macs, that only boots a
few of them.
The Mac emulation in QEMU is far from perfect. In fact what it emulates is not even a
real Mac just some random hardware that resembles a PowerMac enough that with some
combinations some OS X versions work more or less. But if you wander off these tried path
problems are expected as probably no-one have tried that yet or haven't fixed it yet.
There's a lot to improve and your effort in this is greatly appreciated, I'm just
saying that it's not expected to be ready and working with all the processors even if
those appear in the list of emulated CPUs as you've already found.
But back to the problem, from your previous messages it seems it booted with a kernel
that disabled the check for unknown CPUs so the problem seems to be that the kernel cannot
recognise the CPU as supported or it tries to do something for these CPUs that does not
work as expected in QEMU. You may need to check what the mach_kernel does after started by
BootX and how it detects the CPU and if it would accept the CPU you've specified
(maybe it would with 7447a which was used in Macs but for 7448 I would not expect that).
The start.s you've linked seems to be the processor detection that runs. Maybe you
could try to enable the -d in_asm debug option of QEMU that prints what guest code it runs
and try to correlate that to the mach_kernel source to find what it does and where it
fails.
How would I enable -d in the in_asm debug options?
Is it a runtime option, or do I need to enable it when I build?
Regards,
BALATON Zoltan
Thanks Balaton, I do appreciate your help and input.
James
11:50 a.m.
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
I’m unable to boot openbios on TCG with the 7447a,
7450, 7455, or the
750fx, even tho I’ve added support for them. Not sure the issue there.
However Openbios will boot with KVM with the -cpu 7447a, 7450, and 7455.
I'm not sure what could cause this but it seems to be an OpenBIOS problem
if if cannot start on other 74xx CPUs than the default 7400.
With -enable-kvm -cpu host, Debian install, runs and
boots fine, no
issues, other than the L2 cache is not active, but that an issue with
openbios, and I’m not sure how to deal with that yet. Maybe just enable
it in software while the OS is running, maybe add the code to Openbios,
that if it detects the hypervisor it should enable the L2/L3.
I don't know how KVM works but do you need to enable L2/L3 caches in the
guest OS as well? Isn't the host kernel that enables it when it boots,
then it should be working even if the guest does not know about it? (I
mean what counts is the caches of the physical CPU, what the guest sees or
thinks likely does not matter for speed so this may be only a cosmetic
problem.) Maybe adding the info about caches to the device tree could let
the guest know that there are some caches and make something to think they
are enabled but not sure about it an if this would help other than seeing
caches enabled in the guest.
On that note, my patch to qemu for 7447a v1.5 is
incomplete, it doesn’t
show up in the list of CPU’s when I invoke -cpu help, and I can’t chose
-cpu 4747a_v1.5.
Do you know where in the sconce code that list is propagated, I need to
patch that too?
I don't know, try searching for 7447a and see where it pops up and then
search for the structures it's defined in to see where those are used.
How would I enable -d in the in_asm debug options?
Is it a runtime option, or do I need to enable it when I build?
It's a normal command line option. See 'qemu-system-ppc -d help'. Other
interesting options are int,unimp,guest_errors (although on PPC maybe only
int does something). I've tried if qemu-system-ppc gets to OpenBIOS prompt
with 'qemu-system-ppc -cpu G4 -d int' and 'qemu-system-ppc -cpu 7447a -d
int' and I see it takes different exceptions in these cases:
$ ppc-softmmu/qemu-system-ppc -d int
Raise exception at fff08978 => 00000003 (40000000)
Raise exception at fff2a380 => 00000003 (40000000)
Raise exception at fff2a380 => 00000002 (00)
Raise exception at fff2a384 => 00000002 (00)
[and so on]
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Raise exception at fff08978 => 0000004e (00)
[hangs here]
With adding in_asm you can see that at first exception G4 goes to:
0x00000400: 48002028 b 0x2428
which is ISI, that is OK and handled in OpenBIOS,
but with the 7447a it goes to
0x00001000: 4bfff105 bl 0x104
which is "implementation specific", not sure what it means for 7447a and
likely unhandled in OpenBIOS. Indeed, as I see it's defined as:
ILLEGAL_VECTOR( 0x1000 ) in openbios/arch/ppc/qemu/start.S which goes to
trap_error which is supposed to call unexpected_excep() that is supposed
to print "openbios panic" (in openbios/arch/ppc/qemu/init.c) but probably
it's too early for printk to work so the message was not displayed.
That's what I could figure out but not sure where to go from here. You
should find out what is 0x1000 exception on 7447a and why is it fired here
and how to avoid or handle it in OpenBIOS.
Regards,
BALATON Zoltan
10:58 p.m.
On Jan 27, 2018, at 7:50 PM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
Did you patch Openbios to support the 7447a?
If not you’re likely getting the unknown PVR message, and Openbios will halt.
I’m unable to boot openbios on TCG with the
7447a, 7450, 7455, or the 750fx, even tho I’ve added support for them. Not sure the issue
there.
However Openbios will boot with KVM with the -cpu 7447a, 7450, and 7455.
I'm not sure what could cause this but it seems to be an OpenBIOS problem if if
cannot start on other 74xx CPUs than the default 7400.
With -enable-kvm -cpu host, Debian install, runs
and boots fine, no issues, other than the L2 cache is not active, but that an issue with
openbios, and I’m not sure how to deal with that yet. Maybe just enable it in software
while the OS is running, maybe add the code to Openbios, that if it detects the hypervisor
it should enable the L2/L3.
I don't know how KVM works but do you need to enable L2/L3 caches in the guest OS as
well? Isn't the host kernel that enables it when it boots, then it should be working
even if the guest does not know about it? (I mean what counts is the caches of the
physical CPU, what the guest sees or thinks likely does not matter for speed so this may
be only a cosmetic problem.) Maybe adding the info about caches to the device tree could
let the guest know that there are some caches and make something to think they are enabled
but not sure about it an if this would help other than seeing caches enabled in the
guest.
On that note, my patch to qemu for 7447a v1.5 is
incomplete, it doesn’t show up in the list of CPU’s when I invoke -cpu help, and I can’t
chose -cpu 4747a_v1.5.
Do you know where in the sconce code that list is propagated, I need to patch that too?
I don't know, try searching for 7447a and see where it pops up and then search for
the structures it's defined in to see where those are used.
How would I enable -d in the in_asm debug
options?
Is it a runtime option, or do I need to enable it when I build?
It's a normal command line option. See 'qemu-system-ppc -d help'. Other
interesting options are int,unimp,guest_errors (although on PPC maybe only int does
something). I've tried if qemu-system-ppc gets to OpenBIOS prompt with
'qemu-system-ppc -cpu G4 -d int' and 'qemu-system-ppc -cpu 7447a -d int'
and I see it takes different exceptions in these cases:
$ ppc-softmmu/qemu-system-ppc -d int
Raise exception at fff08978 => 00000003 (40000000)
Raise exception at fff2a380 => 00000003 (40000000)
Raise exception at fff2a380 => 00000002 (00)
Raise exception at fff2a384 => 00000002 (00)
[and so on]
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Raise exception at fff08978 => 0000004e (00)
[hangs here]
With adding in_asm you can see that at first exception G4 goes to:
0x00000400: 48002028 b 0x2428
which is ISI, that is OK and handled in OpenBIOS,
but with the 7447a it goes to
0x00001000: 4bfff105 bl 0x104
which is "implementation specific", not sure what it means for 7447a and likely
unhandled in OpenBIOS. Indeed, as I see it's defined as: ILLEGAL_VECTOR( 0x1000 ) in
openbios/arch/ppc/qemu/start.S which goes to trap_error which is supposed to call
unexpected_excep() that is supposed to print "openbios panic" (in
openbios/arch/ppc/qemu/init.c) but probably it's too early for printk to work so the
message was not displayed.
That's what I could figure out but not sure where to go from here. You should find
out what is 0x1000 exception on 7447a and why is it fired here and how to avoid or handle
it in OpenBIOS.
Regards,
BALATON Zoltan
Thanks Balaton, I’ll see what info I can yield from -d.
11:04 a.m.
On Jan 28, 2018, at 9:00 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sun, 28 Jan 2018, Jd Lyons wrote:
Seems 7445/7450 emulation is incomplete, if you want to run the 7447a in TCG mode you’ll
have to patch it to point to a working CPU.
IE:
POWERPC_DEF("7447a_v1.0", CPU_POWERPC_74x7A_v10, 7445,
"PowerPC 7447A v1.0 (G4)")
POWERPC_DEF("7457a_v1.0", CPU_POWERPC_74x7A_v10, 7455,
"PowerPC 7457A v1.0 (G4)")
POWERPC_DEF("7447a_v1.1", CPU_POWERPC_74x7A_v11, 7445,
"PowerPC 7447A v1.1 (G4)")
POWERPC_DEF("7457a_v1.1", CPU_POWERPC_74x7A_v11, 7455,
"PowerPC 7457A v1.1 (G4)")
POWERPC_DEF("7447a_v1.2", CPU_POWERPC_74x7A_v12, 7445,
"PowerPC 7447A v1.2 (G4)")
POWERPC_DEF("7447a_v1.5", CPU_POWERPC_74x7A_v15, 7445,
"PowerPC 7447A v1.5 (G4)")
POWERPC_DEF("7457a_v1.2", CPU_POWERPC_74x7A_v12, 7455,
"PowerPC 7457A v1.2 (G4)”)
TO:
POWERPC_DEF("7447a_v1.0", CPU_POWERPC_74x7A_v10, 7410,
"PowerPC 7447A v1.0 (G4)")
POWERPC_DEF("7457a_v1.0", CPU_POWERPC_74x7A_v10, 7455,
"PowerPC 7457A v1.0 (G4)")
POWERPC_DEF("7447a_v1.1", CPU_POWERPC_74x7A_v11, 7410,
"PowerPC 7447A v1.1 (G4)")
POWERPC_DEF("7457a_v1.1", CPU_POWERPC_74x7A_v11, 7455,
"PowerPC 7457A v1.1 (G4)")
POWERPC_DEF("7447a_v1.2", CPU_POWERPC_74x7A_v12, 7410,
"PowerPC 7447A v1.2 (G4)")
POWERPC_DEF("7447a_v1.5", CPU_POWERPC_74x7A_v15, 7410,
"PowerPC 7447A v1.5 (G4)")
POWERPC_DEF("7457a_v1.2", CPU_POWERPC_74x7A_v12, 7455,
"PowerPC 7457A v1.2 (G4)")
Did you patch Openbios to support the 7447a?
If not you’re likely getting the unknown PVR message, and Openbios will halt.
No I haven't but it did not seem to get to where it would check the PVR so that may
not matter.--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
11:58 a.m.
On Jan 29, 2018, at 7:04 PM, Jd Lyons via OpenBIOS
<openbios(a)openbios.org> wrote:
Ok, with a little help for Paul at the kvm-ppc mailing list, it seems the issue maybe that
the BootX or more likely mach_kernel it trying to write something to or probe for an L3
cache.
On Jan 28, 2018, at 9:00 AM, BALATON Zoltan
<balaton(a)eik.bme.hu <mailto:balaton@eik.bme.hu>> wrote:
On Sun, 28 Jan 2018, Jd Lyons wrote:
Seems 7445/7450 emulation is incomplete, if you want to run the 7447a in TCG mode you’ll
have to patch it to point to a working CPU.
IE:
POWERPC_DEF("7447a_v1.0", CPU_POWERPC_74x7A_v10, 7445,
"PowerPC 7447A v1.0 (G4)")
POWERPC_DEF("7457a_v1.0", CPU_POWERPC_74x7A_v10, 7455,
"PowerPC 7457A v1.0 (G4)")
POWERPC_DEF("7447a_v1.1", CPU_POWERPC_74x7A_v11, 7445,
"PowerPC 7447A v1.1 (G4)")
POWERPC_DEF("7457a_v1.1", CPU_POWERPC_74x7A_v11, 7455,
"PowerPC 7457A v1.1 (G4)")
POWERPC_DEF("7447a_v1.2", CPU_POWERPC_74x7A_v12, 7445,
"PowerPC 7447A v1.2 (G4)")
POWERPC_DEF("7447a_v1.5", CPU_POWERPC_74x7A_v15, 7445,
"PowerPC 7447A v1.5 (G4)")
POWERPC_DEF("7457a_v1.2", CPU_POWERPC_74x7A_v12, 7455,
"PowerPC 7457A v1.2 (G4)”)
TO:
POWERPC_DEF("7447a_v1.0", CPU_POWERPC_74x7A_v10, 7410,
"PowerPC 7447A v1.0 (G4)")
POWERPC_DEF("7457a_v1.0", CPU_POWERPC_74x7A_v10, 7455,
"PowerPC 7457A v1.0 (G4)")
POWERPC_DEF("7447a_v1.1", CPU_POWERPC_74x7A_v11, 7410,
"PowerPC 7447A v1.1 (G4)")
POWERPC_DEF("7457a_v1.1", CPU_POWERPC_74x7A_v11, 7455,
"PowerPC 7457A v1.1 (G4)")
POWERPC_DEF("7447a_v1.2", CPU_POWERPC_74x7A_v12, 7410,
"PowerPC 7447A v1.2 (G4)")
POWERPC_DEF("7447a_v1.5", CPU_POWERPC_74x7A_v15, 7410,
"PowerPC 7447A v1.5 (G4)")
POWERPC_DEF("7457a_v1.2", CPU_POWERPC_74x7A_v12, 7455,
"PowerPC 7457A v1.2 (G4)")
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you Did you patch Openbios to support the 7447a?
If not you’re likely getting the unknown PVR message, and Openbios will halt.
No I haven't but it did not seem to get to where it would check the PVR so that may
not matter.--
OpenBIOS http://openbios.org/ <http://openbios.org/>
Mailinglist: http://lists.openbios.org/mailman/listinfo
<http://lists.openbios.org/mailman/listinfo>
Free your System - May the Forth be with you
1:10 a.m.
On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
Ok, with a little help for Paul at the kvm-ppc mailing
list, it seems
the issue maybe that the BootX or more likely mach_kernel it trying to
write something to or probe for an L3 cache.
With kvm could be but on TCG it doesn't seem that way. Enabling some SPR
debug options in target/ppc/translate_init.c I see this (with qemu git
HEAD without other patches):
$ ppc-softmmu/qemu-system-ppc -cpu G4 -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 000c0209
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 000c0209
Raise exception at fff08978 => 00000003 (40000000)
Write SPR 273 111 <= 07df7ff0
Write SPR 274 112 <= 20000004
Read SPR 272 110 => 07e00000
Read SPR 273 111 => 07df7ff0
Read SPR 274 112 => 20000004
Read SPR 26 01a => fff08978
Read SPR 27 01b => 40000030
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 80030102
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 80030102
Raise exception at fff08978 => 0000004e (00)
So OpenBIOS gets unexpected exception very early right after reading the
PVR so maybe it's a problem in OpenBIOS before it gets to what you're
describing. Is this already fixed?
Regards,
BALATON Zoltan
1:34 a.m.
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
I’m not sure the question you’re asking, sorry, a lot of this stuff is over my head, but
I’m trying to understand it.
A lot of the CPU’s in Qemu seem to link back to the 7445 and 7455, and it just doesn’t
seem to me that emulation is complete for these cpu’s. Changing 7445/7455 to
7400/7410/604/750 as I said earlier seems to work on some level. It will at least get TCG
working. Linking the 7447a to 7400/7410 allows this CPU to boot the Mac OS, but sadly not
with KVM. KVM still raise the L3 cache exception. Oddly using the 7448 linked to 7400, as
is done in the master now, with KVM doesn’t raise this exception, with the mach_kernel
that has had the CPU “check” removed. 10.4.11 boots happily away.
I’m just not sure what to make of it.
Ok, with a little help for Paul at the kvm-ppc
mailing list, it seems the issue maybe that the BootX or more likely mach_kernel it trying
to write something to or probe for an L3 cache.
With kvm could be but on TCG it doesn't seem that way. Enabling some SPR debug
options in target/ppc/translate_init.c I see this (with qemu git HEAD without other
patches):
$ ppc-softmmu/qemu-system-ppc -cpu G4 -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 000c0209
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 000c0209
Raise exception at fff08978 => 00000003 (40000000)
Write SPR 273 111 <= 07df7ff0
Write SPR 274 112 <= 20000004
Read SPR 272 110 => 07e00000
Read SPR 273 111 => 07df7ff0
Read SPR 274 112 => 20000004
Read SPR 26 01a => fff08978
Read SPR 27 01b => 40000030
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 80030102
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 80030102
Raise exception at fff08978 => 0000004e (00)
So OpenBIOS gets unexpected exception very early right after reading the PVR so maybe
it's a problem in OpenBIOS before it gets to what you're describing. Is this
already fixed?
Regards,
BALATON Zoltan
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
2:47 a.m.
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
It looks like in TCG mode that it tries to read these invalid spr’s
1018
1011
1016
1012
This doesn’t cause a halt, as the kernel boots.
Ok, with a little help for Paul at the kvm-ppc
mailing list, it seems the issue maybe that the BootX or more likely mach_kernel it trying
to write something to or probe for an L3 cache.
With kvm could be but on TCG it doesn't seem that way. Enabling some SPR debug
options in target/ppc/translate_init.c I see this (with qemu git HEAD without other
patches):
$ ppc-softmmu/qemu-system-ppc -cpu G4 -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 000c0209
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 000c0209
Raise exception at fff08978 => 00000003 (40000000)
Write SPR 273 111 <= 07df7ff0
Write SPR 274 112 <= 20000004
Read SPR 272 110 => 07e00000
Read SPR 273 111 => 07df7ff0
Read SPR 274 112 => 20000004
Read SPR 26 01a => fff08978
Read SPR 27 01b => 40000030
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 80030102
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 80030102
Raise exception at fff08978 => 0000004e (00)
So OpenBIOS gets unexpected exception very early right after reading the PVR so maybe
it's a problem in OpenBIOS before it gets to what you're describing. Is this
already fixed?
Regards,
BALATON Zoltan
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
3:14 a.m.
On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS
<openbios(a)openbios.org> wrote:
What I’m assuming is the kernel is trying to read the state of spr 1018 (r13), but it
can’t read it. It does seem to exist for the 7447a it’s value is just zero( 0x00000000 )
and of course you can’t write anything there.
I don’t think the kernel is trying to write anything there, I think it’s just probing the
state of the register to determine if the L3 cache exists. There are just too many
references to the r13 in the xun source for me to figure out how to stop the kernel from
trying to make a read here. Paul seems to suggest it could be fixed in KVM, but it seems
like I could fix it in Qemu if I knew how to get Qemu to pass that spr( 1018 ) to the
guest as readable with the value 0x00000000.
Would anyone be able to help me do that?
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
It looks like in TCG mode that it tries to read these invalid spr’s
1018
1011
1016
1012
This doesn’t cause a halt, as the kernel boots.
Ok, with a little help for Paul at the kvm-ppc
mailing list, it seems the issue maybe that the BootX or more likely mach_kernel it trying
to write something to or probe for an L3 cache.
With kvm could be but on TCG it doesn't seem that way. Enabling some SPR debug
options in target/ppc/translate_init.c I see this (with qemu git HEAD without other
patches):
$ ppc-softmmu/qemu-system-ppc -cpu G4 -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 000c0209
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 000c0209
Raise exception at fff08978 => 00000003 (40000000)
Write SPR 273 111 <= 07df7ff0
Write SPR 274 112 <= 20000004
Read SPR 272 110 => 07e00000
Read SPR 273 111 => 07df7ff0
Read SPR 274 112 => 20000004
Read SPR 26 01a => fff08978
Read SPR 27 01b => 40000030
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 80030102
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 80030102
Raise exception at fff08978 => 0000004e (00)
So OpenBIOS gets unexpected exception very early right after reading the PVR so maybe
it's a problem in OpenBIOS before it gets to what you're describing. Is this
already fixed?
Regards,
BALATON Zoltan
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
7:59 a.m.
On 01/30/2018 11:14 AM, Jd Lyons wrote:
Ok, I tried like this:
spr_register_kvm(env, SPR_L3CR, "L3CR",
SPR_NOACCESS, SPR_NOACCESS,
&spr_read_generic, &spr_write_generic,
KVM_REG_PPC_L3CR, 0x00000000);
And I defined:
#define KVM_REG_PPC_L3CR (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x3fa)
Not sure, that likely should be KVM_REG_SIZE_U32?
I always get confused by that, I'm assuming it should be U32, as it's a
32bit register?
Tried it both ways, hoping KVM would allow a read at spr 1018, but no
dice, system still hangs after Call Kernel! and I still get:
KVM: invalid SPR read: 1018
I'm running out of ideas.
On Jan 30, 2018, at 10:47 AM, Jd Lyons via
OpenBIOS <openbios(a)openbios.org> wrote:
What I’m assuming is the kernel is trying to read the state of spr 1018 (r13), but
it can’t read it. It does seem to exist for the 7447a it’s value is just zero( 0x00000000
) and of course you can’t write anything there.
I don’t think the kernel is trying to write anything there, I think it’s just probing the
state of the register to determine if the L3 cache exists. There are just too many
references to the r13 in the xun source for me to figure out how to stop the kernel from
trying to make a read here. Paul seems to suggest it could be fixed in KVM, but it seems
like I could fix it in Qemu if I knew how to get Qemu to pass that spr( 1018 ) to the
guest as readable with the value 0x00000000.
Would anyone be able to help me do that?
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
It looks like in TCG mode that it
tries to read these invalid spr’s
1018
1011
1016
1012
This doesn’t cause a halt, as the kernel boots.
Ok, with a little help for Paul at the kvm-ppc
mailing list, it seems the issue maybe that the BootX or more likely mach_kernel it trying
to write something to or probe for an L3 cache.
With kvm could be but on TCG it
doesn't seem that way. Enabling some SPR debug options in target/ppc/translate_init.c
I see this (with qemu git HEAD without other patches):
$ ppc-softmmu/qemu-system-ppc -cpu G4 -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 000c0209
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 000c0209
Raise exception at fff08978 => 00000003 (40000000)
Write SPR 273 111 <= 07df7ff0
Write SPR 274 112 <= 20000004
Read SPR 272 110 => 07e00000
Read SPR 273 111 => 07df7ff0
Read SPR 274 112 => 20000004
Read SPR 26 01a => fff08978
Read SPR 27 01b => 40000030
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 80030102
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 80030102
Raise exception at fff08978 => 0000004e (00)
So OpenBIOS gets unexpected exception very early right after reading the PVR so maybe
it's a problem in OpenBIOS before it gets to what you're describing. Is this
already fixed?
Regards,
BALATON Zoltan
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you >
> --
> OpenBIOS http://openbios.org/
> Mailinglist: http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you
5:13 p.m.
On 31.01.2018 21:59, James Lyons via OpenBIOS wrote:
On 01/30/2018 11:14 AM, Jd Lyons wrote:
Ok, I tried like this:
spr_register_kvm(env, SPR_L3CR, "L3CR",
SPR_NOACCESS, SPR_NOACCESS,
&spr_read_generic, &spr_write_generic,
KVM_REG_PPC_L3CR, 0x00000000);
And I defined:
#define KVM_REG_PPC_L3CR (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x3fa)
Did you also patch the kernel accordingly? The KVM code in the kernel
needs to be aware of this, too. grep for KVM_REG_PPC_ in
arch/powerpc/kvm/ to see some examples.
Thomas
On Jan 30, 2018, at 10:47 AM, Jd Lyons via
OpenBIOS
<openbios(a)openbios.org> wrote:
What I’m assuming is the kernel is trying to read the state of spr
1018 (r13), but it can’t read it. It does seem to exist for the 7447a
it’s value is just zero( 0x00000000 ) and of course you can’t write
anything there.
I don’t think the kernel is trying to write anything there, I think
it’s just probing the state of the register to determine if the L3
cache exists. There are just too many references to the r13 in the xun
source for me to figure out how to stop the kernel from trying to make
a read here. Paul seems to suggest it could be fixed in KVM, but it
seems like I could fix it in Qemu if I knew how to get Qemu to pass
that spr( 1018 ) to the guest as readable with the value 0x00000000.
Would anyone be able to help me do that?
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
> Ok, with a little help for Paul at the kvm-ppc mailing list, it
> seems the issue maybe that the BootX or more likely mach_kernel it
> trying to write something to or probe for an L3 cache.
With kvm could be but on TCG it doesn't seem that way. Enabling some
SPR debug options in target/ppc/translate_init.c I see this (with
qemu git HEAD without other patches):
$ ppc-softmmu/qemu-system-ppc -cpu G4 -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 000c0209
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 000c0209
Raise exception at fff08978 => 00000003 (40000000)
Write SPR 273 111 <= 07df7ff0
Write SPR 274 112 <= 20000004
Read SPR 272 110 => 07e00000
Read SPR 273 111 => 07df7ff0
Read SPR 274 112 => 20000004
Read SPR 26 01a => fff08978
Read SPR 27 01b => 40000030
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 80030102
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 80030102
Raise exception at fff08978 => 0000004e (00)
So OpenBIOS gets unexpected exception very early right after reading
the PVR so maybe it's a problem in OpenBIOS before it gets to what
you're describing. Is this already fixed?
Regards,
BALATON Zoltan
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
It looks like in TCG mode that it
tries to read these invalid spr’s
1018
1011
1016
1012
This doesn’t cause a halt, as the kernel boots.
2:12 p.m.
On Feb 1, 2018, at 1:13 AM, Thomas Huth
<thuth(a)redhat.com> wrote:
On 31.01.2018 21:59, James Lyons via OpenBIOS wrote:
Ok, thanks Thomas, that makes sense, I’ll see if I can make heads or tails of the code.
On 01/30/2018 11:14 AM, Jd Lyons wrote:
Ok, I tried like this:
spr_register_kvm(env, SPR_L3CR, "L3CR",
SPR_NOACCESS, SPR_NOACCESS,
&spr_read_generic, &spr_write_generic,
KVM_REG_PPC_L3CR, 0x00000000);
And I defined:
#define KVM_REG_PPC_L3CR (KVM_REG_PPC | KVM_REG_SIZE_U64 | 0x3fa)
Did you also patch the kernel accordingly? The KVM code in the kernel
needs to be aware of this, too. grep for KVM_REG_PPC_ in
arch/powerpc/kvm/ to see some examples.
Thomas
On Jan 30, 2018, at 10:47 AM, Jd Lyons via
OpenBIOS
<openbios(a)openbios.org> wrote:
> On Jan 30, 2018, at 9:10 AM, BALATON Zoltan <balaton(a)eik.bme.hu> wrote:
>
> On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
>> Ok, with a little help for Paul at the kvm-ppc mailing list, it
>> seems the issue maybe that the BootX or more likely mach_kernel it
>> trying to write something to or probe for an L3 cache.
> With kvm could be but on TCG it doesn't seem that way. Enabling some
> SPR debug options in target/ppc/translate_init.c I see this (with
> qemu git HEAD without other patches):
>
> $ ppc-softmmu/qemu-system-ppc -cpu G4 -d int
> Write SPR 272 110 <= 07e00000
> Read SPR 287 11f => 000c0209
> Read SPR 25 019 => 07e00000
> Read SPR 25 019 => 07e00000
> Read SPR 287 11f => 000c0209
> Raise exception at fff08978 => 00000003 (40000000)
> Write SPR 273 111 <= 07df7ff0
> Write SPR 274 112 <= 20000004
> Read SPR 272 110 => 07e00000
> Read SPR 273 111 => 07df7ff0
> Read SPR 274 112 => 20000004
> Read SPR 26 01a => fff08978
> Read SPR 27 01b => 40000030
>
> $ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
> Write SPR 272 110 <= 07e00000
> Read SPR 287 11f => 80030102
> Read SPR 25 019 => 07e00000
> Read SPR 25 019 => 07e00000
> Read SPR 287 11f => 80030102
> Raise exception at fff08978 => 0000004e (00)
>
> So OpenBIOS gets unexpected exception very early right after reading
> the PVR so maybe it's a problem in OpenBIOS before it gets to what
> you're describing. Is this already fixed?
>
> Regards,
> BALATON Zoltan
>
> --
> OpenBIOS http://openbios.org/
> Mailinglist: http://lists.openbios.org/mailman/listinfo
> Free your System - May the Forth be with you
It looks like in TCG mode that it tries to read these invalid spr’s
1018
1011
1016
1012
This doesn’t cause a halt, as the kernel boots.
What I’m assuming is the kernel is trying to read the state of spr
1018 (r13), but it can’t read it. It does seem to exist for the 7447a
it’s value is just zero( 0x00000000 ) and of course you can’t write
anything there.
I don’t think the kernel is trying to write anything there, I think
it’s just probing the state of the register to determine if the L3
cache exists. There are just too many references to the r13 in the xun
source for me to figure out how to stop the kernel from trying to make
a read here. Paul seems to suggest it could be fixed in KVM, but it
seems like I could fix it in Qemu if I knew how to get Qemu to pass
that spr( 1018 ) to the guest as readable with the value 0x00000000.
Would anyone be able to help me do that?
--
OpenBIOS http://openbios.org/ <http://openbios.org/>
Mailinglist: http://lists.openbios.org/mailman/listinfo
<http://lists.openbios.org/mailman/listinfo>
Free your System - May the Forth be with you
4:17 a.m.
On 01/30/2018 10:47 AM, Jd Lyons wrote:
I went ahead an added these spr's to the 74xx cpu, hoping that adding
the L3CR would allow me to boot in KVM mode with -cpu host or -cpu
7447a_v1.5, but It didn't now the kernel hangs and I get the dmesg:
KVM: invalid SPR read: 1018
So I'm not doing it correctly or I'll have to do it in KVM and recompile
the kernel for my host.
Here is the code I used for the L3CR, can anyone tell me a better way of
doing it?
/* L3CR */
/* XXX : not implemented */
spr_register(env, SPR_L3CR, "L3CR",
SPR_NOACCESS, SPR_NOACCESS,
&spr_read_generic, &spr_write_generic,
0x00000000);
In TCG( -cpu 7447a_v1.5 without enable-kvm ) mode I no longer get
invalid spr reads between BootX( Call Kernel! ) and mach_kernel .
loading.
If I set the value of the register to 0x80000000 the guest mach_kernel
tries to make a write there in TCG mode, and booting halts.
So, I'm guessing that mach_kernel expects the value here to be
0x00000000, and if it isn't it tries to write something there.
In KVM mode the Kernel is unable to read the register. So I've got to
figure some way around that. Or figure out why the kernel is trying to
read this register for a CPU that doesn't support an L3 cache?
I don't know if this is an issue with Qemu, or the kernel reads this
register when I boot native on the bare metal. Anyone know a way of
getting a dump of register access on the bare metal?
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Mon, 29 Jan 2018, Jd Lyons via OpenBIOS wrote:
It looks like in TCG mode that it
tries to read these invalid spr’s
1018
1011
1016
1012
This doesn’t cause a halt, as the kernel boots. Ok, with a little help for Paul at the kvm-ppc
mailing list, it seems the issue maybe that the BootX or more likely mach_kernel it trying
to write something to or probe for an L3 cache.
With kvm could be but on TCG it
doesn't seem that way. Enabling some SPR debug options in target/ppc/translate_init.c
I see this (with qemu git HEAD without other patches):
$ ppc-softmmu/qemu-system-ppc -cpu G4 -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 000c0209
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 000c0209
Raise exception at fff08978 => 00000003 (40000000)
Write SPR 273 111 <= 07df7ff0
Write SPR 274 112 <= 20000004
Read SPR 272 110 => 07e00000
Read SPR 273 111 => 07df7ff0
Read SPR 274 112 => 20000004
Read SPR 26 01a => fff08978
Read SPR 27 01b => 40000030
$ ppc-softmmu/qemu-system-ppc -cpu 7447a -d int
Write SPR 272 110 <= 07e00000
Read SPR 287 11f => 80030102
Read SPR 25 019 => 07e00000
Read SPR 25 019 => 07e00000
Read SPR 287 11f => 80030102
Raise exception at fff08978 => 0000004e (00)
So OpenBIOS gets unexpected exception very early right after reading the PVR so maybe
it's a problem in OpenBIOS before it gets to what you're describing. Is this
already fixed?
Regards,
BALATON Zoltan
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
12:58 p.m.
On that note, my patch to qemu for 7447a v1.5 is incomplete, it doesn’t show up in the
list of CPU’s when I invoke -cpu help, and I can’t chose -cpu 4747a_v1.5.
Do you know where in the sconce code that list is propagated, I need to patch that too?
The list of CPU models that is listed by "-cpu ?" for qemu-system-ppc is found
in the file target/ppc/cpu-models.c.
Hope this helps.
1:11 a.m.
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan
<balaton(a)eik.bme.hu> wrote:
On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:
I’m not sure with the 7448, it was used it some upgrades for Powermac G4’s from third
parties. I’ll have to check what OS’s there where compatible with. I think it’s just a
7447a with double the L2 cache.
Compatible OS Versions::
Mac OS 9.2.2 or Mac OS X 10.3.5 (oor later)) is required for all models..
Mac OS X 10.3.8 or later is recommended..
This package contains::
• Newer Technology MAXPower G4 upgrade card,, heat sink with fan and power connector
• CD--RROM with manual and frmware installation
• A magnetized Phillips screwdriver
Firmware Update::
IMPORTANT::
This upgrade
REQUIRES
the
Newer Technology 7447A//77448 Firmware Update
provided on CD or it WILL NOT WORK..
https://eshop.macsales.com/tech_center/manuals/newertech/maxpower/nwtmang...
So I wondering if someone used an old firmware as the reference in qemu-ppc when support
for booting OS X was added. Maybe there is some magic we need to boot from the
7450/7455/7447a/7448.
I was able to boot a custom kernel that someone had added 604 support for Tiger( 10.4.8 ),
with the 7448 in qemu-ppc.
Welcome to OpenBIOS v1.1 built on Jan 22 2018
11:12
0 > boot hd:10,\ppc\bootx >> switching to new context:
Mac OS X Loader
depthbytes isn't unique.
rowbytes isn't unique.
FILL-RECTANGLE isn't unique.
Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
HFSInitPartition: 2fc5b254
Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
Loading HFS+ file: [\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7]
from 2fc5b254.
Call Kernel!
FailToBoot: 6
ENTER
So maybe you're looking for the problem at the wrong place when debugging BootX. It
says it has transferred execution to the loaded kernel and it's the kernel which
failed. Does the kernel version you're trying to boot support this CPU type at all?
Regards,
BALATON Zoltan
8:52 a.m.
On 25/01/18 15:01, Jd Lyons via OpenBIOS wrote:
In an effort to figure out why qemu-system-ppc hangs
at BootX when using
some emulated and KVM CPU’s, I suppose it would be good to enter some
breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m
looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
*There are few other useful debugging tech- niques. Setting "auto-boot?"
to false will cause the system to enter the OpenFirmware User In-
terface by default. Changing kFailToBoot to 0 in include.tproj/sl.h will
alter BootX’s default be- havior on error, so that it will return to
Open- Firmware. Finally, calling Enter(), will cause BootX to drop back
into the OpenFirmware User **Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the
address, then the length, then "dumpl". By calling printf in BootX
immediately before En- ter(), the address can be easily determined, and
the variable can then be examined and altered from OpenFirmware. Finally
typing the "go" command will resume BootX’s execution. *
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding
command+v BootX sends some info to the screen, seemingly via open
firware, while displaying the “Apple Logo” boot graphic. The info show
some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has
any idea how I might be able to do that?
Steve Troughton-Smith has previously custom built BootX from source in
order to boot older versions of Rhapsody (see
https://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start...
and https://github.com/steventroughtonsmith/BootX for more information).
If the instructions in the forum post don't give enough detail then it
might be worth a direct email?
ATB,
Mark.
7:53 p.m.
On Jan 25, 2018, at 4:52 PM, Mark Cave-Ayland
<mark.cave-ayland(a)ilande.co.uk> wrote:
On 25/01/18 15:01, Jd Lyons via OpenBIOS wrote:
Thanks Mark, I’ve tried Steve’s custom BootX to boot from the 10.1 cd, but it yields the
same result with BootX just hanging, and no useful debug output.
I raised the issue with Steve last year, that BootX would hang with the emulated 970 CPU
in qemu-system-ppc64, and he did reply that it maybe the issue he addressed in his custom
bootx, tho my attempts didn’t yield any better results. His version of BootX isn’t valid
for versions of the kernel beyond 10.1, so there e is no support for the G5.
The 604. G3, 7400, 7410 seem to be the only valid cpu choice that can boot a stock
BootX/mach_kernel in qemu-system-ppc, I did use a custom kernel that had been modified to
allow 10.4.8 to boot on the 604 cpu, and with that kernel, I was able to boot with these
cpu’s as well as the 7448.
Yahboot/Linux PPC, seems to be unaffected by this issue. I’ve had no trouble installing
and booting linux within qemu-syustem-ppc with any cpu I’ve tried, or added to Openbios.
I added a few more CPU’s to Openbios, tho with some odd results. With the same .elf on the
x86 the 7450 and 7455 seem to hang Openbios, system never boots. Tho on ppc with kvm
selecting these cpu’s yields booting, and openbios has no trouble with them, tho bootx
just hangs. When I remove the kvm option openbios fails to boot, same as it does on these
cpu’s on x86.
Haven’t figured that issue yet.
In an effort to figure out why qemu-system-ppc
hangs at BootX when using some emulated and KVM CPU’s, I suppose it would be good to enter
some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
*There are few other useful debugging tech- niques. Setting "auto-boot?" to
false will cause the system to enter the OpenFirmware User In- terface by default.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User **Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution. *
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends
some info to the screen, seemingly via open firware, while displaying the “Apple Logo”
boot graphic. The info show some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I
might be able to do that?
Steve Troughton-Smith has previously custom built BootX from source in order to boot
older versions of Rhapsody (see
https://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start... and
https://github.com/steventroughtonsmith/BootX for more information).
If the instructions in the forum post don't give enough detail then it might be worth
a direct email?
ATB,
Mark.
11:29 p.m.
On Jan 25, 2018, at 10:01 AM, Jd Lyons via OpenBIOS
<openbios(a)openbios.org> wrote:
In an effort to figure out why qemu-system-ppc hangs at BootX when using some emulated
and KVM CPU’s, I suppose it would be good to enter some breakpoints in the code.
I found some BootX sources at:
https://opensource.apple.com/tarballs/BootX/
<https://opensource.apple.com/tarballs/BootX/>
Tho I’m not sure what versions correspond to which release of OS X?
And it’s not clear how to build them, tho I haven’t tried yet.
I found some info on BootX as well as some idea how to do what I’m looking to do:
https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
<https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf...
There are few other useful debugging tech- niques. Setting "auto-boot?" to
false will cause the system to enter the OpenFirmware User In- terface by default.
Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on
error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause
BootX to drop back into the OpenFirmware User Interface. This can be used as a break
point. The "dumpl" word will dump some memory, by en- tering the address, then
the length, then "dumpl". By calling printf in BootX immediately before En-
ter(), the address can be easily determined, and the variable can then be examined and
altered from OpenFirmware. Finally typing the "go" command will resume BootX’s
execution.
I noted when I boot from boot usb0/disk:3,\\:tbxi while holding command+v BootX sends
some info to the screen, seemingly via open firware, while displaying the “Apple Logo”
boot graphic. The info show some of the boot process and what stage it’s loading” loading
mach_kernel’ “ loading the .mkext”
It would be nice to get this output going via Open Bios, if anyone has any idea how I
might be able to do that?
--
OpenBIOS http://openbios.org/
Mailinglist: http://lists.openbios.org/mailman/listinfo
Free your System - May the Forth be with you
I downloaded the source of bootx and made a few changes, but issuing make seems to create
mach0 binary, rather than a :tbxi resource?
658
days inactive
666
days old
34 comments
8 participants
participants (8)
-
BALATON Zoltan -
James Lyons -
Jd Lyons
-
Mark Cave-Ayland -
Natalia Portillo -
Programmingkid -
Segher Boessenkool -
Thomas Huth