On Jan 27, 2018, at 9:41 AM, Programmingkid <programmingkidx@gmail.com> wrote:

On Jan 27, 2018, at 9:34 AM, Jd Lyons <lyons_dj@yahoo.com> wrote:

On Jan 27, 2018, at 8:41 AM, Programmingkid <programmingkidx@gmail.com> wrote:

On Jan 27, 2018, at 7:33 AM, BALATON Zoltan <balaton@eik.bme.hu> wrote:

On Sat, 27 Jan 2018, Jd Lyons via OpenBIOS wrote:

Welcome to OpenBIOS v1.1 built on Jan 22 2018 11:12

0 > boot hd:10,\ppc\bootx >> switching to new context:


Mac OS X Loader
depthbytes isn't unique.
rowbytes isn't unique.
FILL-RECTANGLE isn't unique.
Opening partition [/pci@f2000000/mac-io@c/ata-3@20000/disk@0:10]...
HFSInitPartition: 2fc5b254
Loading HFS+ file: [\\com.apple.Boot.plist] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
non-root file owner detected: 501
Reading HFS+ file: [\\mach_kernel] from 2fc5b254.
setting boot-uuid to: CF9C6A60-A576-362A-A46B-5CF31493B8F0
non-root file owner detected: 501
Loading HFS+ file: [\System\Library\Caches\com.apple.kernelcaches\kernelcache.D57A14F7] from 2fc5b254.

Call Kernel!
FailToBoot: 6
ENTER

Excellent job with capturing Bootx's output. 

So maybe you're looking for the problem at the wrong place when debugging BootX. It says it has transferred execution to the loaded kernel and it's the kernel which failed. Does the kernel version you're trying to boot support this CPU type at all?

Back when I would build the Mach kernel I would place a bunch of printf statements to see what it is doing. This is an easy way to debug the kernel. What version of Mac OS X are you currently trying to boot? If you want help with building and running a custom kernel just let me know.

Yes, I think a custom kernel maybe what’s needed, there is some magic that qemu-ppc is not doing. A custom kernel can boot on the 7448, as I have already confirmed. I was hoping to avoid that, but until someone that is familiar with how qemu-ppc boot OS X, I’ll just have to try the custom kernel route.

For the 7448, I used the kernel linked in these tread:

https://forums.macrumors.com/threads/os-x-tiger-on-a-603-604-cpu.1908276/

If we can figure out what changes were made that allowed qemu-ppc to boot with it, we should be able to figure out how to get the 7447a/7450/7455 to boot with it.

I never had any luck building mach_kernel, but I have’t tried in years, so you’ll have to walk me trough it.

I’ll ask LightBulbFun if he can get us a diff of his changes for 604 support, or at least give us an overview of how to add cpu support to the kernel.

There is still one thing I’d like to do with bootx, if you can help with that.

Changing kFailToBoot to 0 in include.tproj/sl.h will alter BootX’s default be- havior on error, so that it will return to Open- Firmware. Finally, calling Enter(), will cause BootX to drop back into the OpenFirmware User Interface. This can be used as a break point. The "dumpl" word will dump some memory, by en- tering the address, then the length, then "dumpl". By calling printf in BootX immediately before En- ter(), the address can be easily determined, and the variable can then be examined and altered from OpenFirmware. Finally typing the "go" command will resume BootX’s execution. 

I don’t understand how, or where in the code to call Enter(), or printf?

All I changed was kFailToBoot to 0 in the sl.h. That was enough to get BootX to output some debug info for us, but if you say that we’re done with bootx when it calls the kernel( jumping to the memory where it loaded the kernel in real mode? ), then we can skip this.

I think dumpl isn't defined in OpenBIOS. dump is defined. From the description you send it sounds exactly like dump. I'm thinking defining dumpl like this might be of use to you:

: dumpl dump ;