Apple's BootX

[Jd Lyons]

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?

[Natalia Portillo]

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?

[Jd Lyons]

 On Jan 25, 2018, at 10:14 AM, Natalia Portillo
<claunia(a)claunia.com&gt; 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

[Programmingkid]

 On Jan 25, 2018, at 10:01 AM, Jd Lyons <lyons_dj(a)yahoo.com&gt;
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?

[Jd Lyons]

 On Jan 25, 2018, at 10:18 AM, Programmingkid
<programmingkidx(a)gmail.com&gt; wrote:
 
 
> On Jan 25, 2018, at 10:01 AM, Jd Lyons <lyons_dj(a)yahoo.com&gt; 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.

[Programmingkid]

 On Jan 26, 2018, at 3:32 AM, Jd Lyons <lyons_dj(a)yahoo.com&gt;
wrote:
 
 
 
> On Jan 25, 2018, at 10:18 AM, Programmingkid <programmingkidx(a)gmail.com&gt;
wrote:
> 
> 
>> On Jan 25, 2018, at 10:01 AM, Jd Lyons <lyons_dj(a)yahoo.com&gt; 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.

[Jd Lyons]

 On Jan 26, 2018, at 10:37 AM, Programmingkid
<programmingkidx(a)gmail.com&gt; wrote:
 
> 
> On Jan 26, 2018, at 3:32 AM, Jd Lyons <lyons_dj(a)yahoo.com&gt; wrote:
> 
> 
> 
>> On Jan 25, 2018, at 10:18 AM, Programmingkid <programmingkidx(a)gmail.com&gt;
wrote:
>> 
>> 
>>> On Jan 25, 2018, at 10:01 AM, Jd Lyons <lyons_dj(a)yahoo.com&gt; 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

[BALATON Zoltan]

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

[Programmingkid]

 On Jan 27, 2018, at 7:33 AM, BALATON Zoltan
<balaton(a)eik.bme.hu&gt; 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.

[Jd Lyons]

 On Jan 27, 2018, at 8:41 AM, Programmingkid
<programmingkidx(a)gmail.com&gt; wrote:
 
> 
> On Jan 27, 2018, at 7:33 AM, BALATON Zoltan <balaton(a)eik.bme.hu&gt; 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

[Programmingkid]

 On Jan 27, 2018, at 9:34 AM, Jd Lyons <lyons_dj(a)yahoo.com&gt;
wrote:
 
 
 
> On Jan 27, 2018, at 8:41 AM, Programmingkid <programmingkidx(a)gmail.com&gt; wrote:
> 
>> 
>> On Jan 27, 2018, at 7:33 AM, BALATON Zoltan <balaton(a)eik.bme.hu&gt; 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 ;

[Jd Lyons]

 On Jan 27, 2018, at 9:41 AM, Programmingkid
<programmingkidx(a)gmail.com&gt; wrote:
 
> 
> On Jan 27, 2018, at 9:34 AM, Jd Lyons <lyons_dj(a)yahoo.com&gt; wrote:
> 
> 
> 
>> On Jan 27, 2018, at 8:41 AM, Programmingkid <programmingkidx(a)gmail.com&gt;
wrote:
>> 
>>> 
>>> On Jan 27, 2018, at 7:33 AM, BALATON Zoltan <balaton(a)eik.bme.hu&gt;
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.

[BALATON Zoltan]

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

[Jd Lyons]

 On Jan 27, 2018, at 1:23 PM, BALATON Zoltan
<balaton(a)eik.bme.hu&gt; 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

[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

[Jd Lyons]

 On Jan 27, 2018, at 5:50 PM, BALATON Zoltan
<balaton(a)eik.bme.hu&gt; 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

[BALATON Zoltan]

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

[Jd Lyons]

 On Jan 27, 2018, at 7:50 PM, BALATON Zoltan
<balaton(a)eik.bme.hu&gt; 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.

[BALATON Zoltan]

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.

[Jd Lyons]

 On Jan 28, 2018, at 9:00 AM, BALATON Zoltan
<balaton(a)eik.bme.hu&gt; 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)")

[Jd Lyons]

 On Jan 29, 2018, at 7:04 PM, Jd Lyons via OpenBIOS
<openbios(a)openbios.org&gt; wrote:
 
 
 
> On Jan 28, 2018, at 9:00 AM, BALATON Zoltan <balaton(a)eik.bme.hu
<mailto:[e-mail]>> 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.

[BALATON Zoltan]

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

[Jd Lyons]

 On Jan 30, 2018, at 9:10 AM, BALATON Zoltan
<balaton(a)eik.bme.hu&gt; 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

[Jd Lyons]

 On Jan 30, 2018, at 9:10 AM, BALATON Zoltan
<balaton(a)eik.bme.hu&gt; 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.

[Jd Lyons]

 On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS
<openbios(a)openbios.org&gt; wrote:
 
 
 
> On Jan 30, 2018, at 9:10 AM, BALATON Zoltan <balaton(a)eik.bme.hu&gt; 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

[James Lyons]

On 01/30/2018 11:14 AM, Jd Lyons wrote:
> On Jan 30, 2018, at 10:47 AM, Jd Lyons via OpenBIOS <openbios(a)openbios.org&gt;
wrote:
>
>
>
>> On Jan 30, 2018, at 9:10 AM, BALATON Zoltan <balaton(a)eik.bme.hu&gt; 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

[Thomas Huth]

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(a)openbios.org&gt; wrote:
>>
>>
>>
>>> On Jan 30, 2018, at 9:10 AM, BALATON Zoltan <balaton(a)eik.bme.hu&gt;
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

[Jd Lyons]

 On Feb 1, 2018, at 1:13 AM, Thomas Huth <thuth(a)redhat.com&gt;
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(a)openbios.org&gt; wrote:
>>> 
>>> 
>>> 
>>>> On Jan 30, 2018, at 9:10 AM, BALATON Zoltan <balaton(a)eik.bme.hu&gt;
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

[Segher Boessenkool]

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

[James Lyons]

On 01/30/2018 10:47 AM, Jd Lyons wrote:
> On Jan 30, 2018, at 9:10 AM, BALATON Zoltan <balaton(a)eik.bme.hu&gt; 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?

[Programmingkid]

 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.

[Jd Lyons]

 On Jan 27, 2018, at 7:33 AM, BALATON Zoltan
<balaton(a)eik.bme.hu&gt; 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/nwtmang...



So I wondering if someone used an old firmware as the reference in qemu-ppc when support
for booting OS X was added. Maybe there is some magic we need to boot from the
7450/7455/7447a/7448.




I was able to boot a custom kernel that someone had added 604 support for Tiger( 10.4.8 ),
with the 7448 in qemu-ppc.


 


 
 Regards,
 BALATON Zoltan

[Mark Cave-Ayland]

On 25/01/18 15:01, Jd Lyons via OpenBIOS wrote:

 In an effort to figure out why qemu-system-ppc hangs at BootX when
using 
 some emulated and KVM CPU’s, I suppose it would be good to enter some 
 breakpoints in the code.
 
 I found some BootX sources at:
 
 https://opensource.apple.com/tarballs/BootX/
 
 Tho I’m not sure what versions correspond to which release of OS X?
 
 And it’s not clear how to build them, tho I haven’t tried yet.
 
 I found some info on BootX as well as some idea how to do what I’m 
 looking to do:
 
 https://people.ffii.org/~zoobab/bh.udev.org/filez/apple/mac6100/BootX.pdf
 
 *There are few other useful debugging tech- niques. Setting "auto-boot?" 
 to false will cause the system to enter the OpenFirmware User In- 
 terface by default. Changing kFailToBoot to 0 in include.tproj/sl.h will 
 alter BootX’s default be- havior on error, so that it will return to 
 Open- Firmware. Finally, calling Enter(), will cause BootX to drop back 
 into the OpenFirmware User **Interface. This can be used as a break 
 point. The "dumpl" word will dump some memory, by en- tering the 
 address, then the length, then "dumpl". By calling printf in BootX 
 immediately before En- ter(), the address can be easily determined, and 
 the variable can then be examined and altered from OpenFirmware. Finally 
 typing the "go" command will resume BootX’s execution. *
 
 
 I noted when I boot from boot usb0/disk:3,\\:tbxi while holding 
 command+v BootX sends some info to the screen, seemingly via open 
 firware, while displaying the “Apple Logo” boot graphic. The info show 
 some of the boot process and what stage it’s loading” loading 
 mach_kernel’ “ loading the .mkext”
 
 It would be nice to get this output going via Open Bios, if anyone has 
 any idea how I might be able to do that?
Steve Troughton-Smith has previously custom built BootX from source in 
order to boot older versions of Rhapsody (see 
https://www.emaculation.com/forum/viewtopic.php?f=34&t=7047&start... 
and https://github.com/steventroughtonsmith/BootX for more information).

If the instructions in the forum post don't give enough detail then it 
might be worth a direct email?


ATB,

Mark.

[Jd Lyons]

 On Jan 25, 2018, at 4:52 PM, Mark Cave-Ayland
<mark.cave-ayland(a)ilande.co.uk&gt; 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... 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.

[Jd Lyons]

 On Jan 25, 2018, at 10:01 AM, Jd Lyons via OpenBIOS
<openbios(a)openbios.org&gt; 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?