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?
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?
On Jan 25, 2018, at 10:14 AM, Natalia Portillo claunia@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:
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?
Thanks, it’s been so many years since I looked at these sources, I forgot I could navigate the site that way.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Jan 25, 2018, at 10:01 AM, Jd Lyons lyons_dj@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?
On Jan 25, 2018, at 10:18 AM, Programmingkid programmingkidx@gmail.com wrote:
On Jan 25, 2018, at 10:01 AM, Jd Lyons lyons_dj@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?
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 26, 2018, at 3:32 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Jan 25, 2018, at 10:18 AM, Programmingkid programmingkidx@gmail.com wrote:
On Jan 25, 2018, at 10:01 AM, Jd Lyons lyons_dj@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?
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.
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 26, 2018, at 10:37 AM, Programmingkid programmingkidx@gmail.com wrote:
On Jan 26, 2018, at 3:32 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Jan 25, 2018, at 10:18 AM, Programmingkid programmingkidx@gmail.com wrote:
On Jan 25, 2018, at 10:01 AM, Jd Lyons lyons_dj@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?
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.
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.
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
============================================================= 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
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
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan balaton@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.
On Jan 27, 2018, at 8:41 AM, Programmingkid programmingkidx@gmail.com wrote:
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan balaton@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.
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 9:34 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Jan 27, 2018, at 8:41 AM, Programmingkid programmingkidx@gmail.com wrote:
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan balaton@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.
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.
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 9:41 AM, Programmingkid programmingkidx@gmail.com wrote:
On Jan 27, 2018, at 9:34 AM, Jd Lyons lyons_dj@yahoo.com wrote:
On Jan 27, 2018, at 8:41 AM, Programmingkid programmingkidx@gmail.com wrote:
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan balaton@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.
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.
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 ;
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 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
On Jan 27, 2018, at 1:23 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
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?
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.
Regards, BALATON Zoltan
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
On Jan 27, 2018, at 5:50 PM, BALATON Zoltan balaton@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
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.
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.
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.
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?
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
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
On Jan 27, 2018, at 7:50 PM, BALATON Zoltan balaton@eik.bme.hu wrote:
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.
Did you patch Openbios to support the 7447a?
If not you’re likely getting the unknown PVR message, and Openbios will halt.
Regards, BALATON Zoltan
Thanks Balaton, I’ll see what info I can yield from -d.
On Sun, 28 Jan 2018, Jd Lyons wrote:
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.
On Jan 28, 2018, at 9:00 AM, BALATON Zoltan balaton@eik.bme.hu wrote:
On Sun, 28 Jan 2018, Jd Lyons wrote:
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
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)")
On Jan 29, 2018, at 7:04 PM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
On Jan 28, 2018, at 9:00 AM, BALATON Zoltan <balaton@eik.bme.hu mailto:balaton@eik.bme.hu> wrote:
On Sun, 28 Jan 2018, Jd Lyons wrote:
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
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
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 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
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan balaton@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?
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.
Regards, BALATON Zoltan
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan balaton@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.
On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan balaton@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/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 01/30/2018 11:14 AM, Jd Lyons wrote:
On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan balaton@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?
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.
-- OpenBIOS http://openbios.org/ Mailinglist: http://lists.openbios.org/mailman/listinfo Free your System - May the Forth be with you
On 31.01.2018 21:59, James Lyons via OpenBIOS wrote:
On 01/30/2018 11:14 AM, Jd Lyons wrote:
On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan balaton@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?
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 Feb 1, 2018, at 1:13 AM, Thomas Huth thuth@redhat.com wrote:
On 31.01.2018 21:59, James Lyons via OpenBIOS wrote:
On 01/30/2018 11:14 AM, Jd Lyons wrote:
On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS openbios@openbios.org wrote:
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan balaton@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?
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
Ok, thanks Thomas, that makes sense, I’ll see if I can make heads or tails of the code.
-- 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
On Tue, Jan 30, 2018 at 10:47:32AM -0500, Jd Lyons via OpenBIOS wrote:
It looks like in TCG mode that it tries to read these invalid spr’s
1018 1011 1016 1012
1018 is L3CR 1011 is ICTRL 1016 is LDSTCR 1012 does not exist on any 74xx
Segher
On 01/30/2018 10:47 AM, Jd Lyons wrote:
On Jan 30, 2018, at 9:10 AM, BALATON Zoltan balaton@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.
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 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.
On Jan 27, 2018, at 7:33 AM, BALATON Zoltan balaton@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
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?
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/nwtmang4ma...
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.
Regards, BALATON Zoltan
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=13... 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.
On Jan 25, 2018, at 4:52 PM, Mark Cave-Ayland mark.cave-ayland@ilande.co.uk wrote:
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=13... 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.
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.
On Jan 25, 2018, at 10:01 AM, Jd Lyons via OpenBIOS openbios@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?
-
BALATON Zoltan -
James Lyons -
Jd Lyons
-
Mark Cave-Ayland -
Natalia Portillo -
Programmingkid -
Segher Boessenkool -
Thomas Huth